Mimblewimble has the nice property that funds can only be received after proving the ability to spend them. Or as I’ve seen someone say “You can’t lose Grin”.
Bitcoin lacks this property, but users often jump through loops with additional transactions of tiny amounts to try emulate this property and reduce their fear of funds ending up lost.
Non-interactive transactions are a departure from Mimblewimble in giving up this property.
I think the main culprit of current poor usability is the failure of exchanges to support TOR and slatepacks.
With regards to a finalize step being non-intuitive, I would prefer that the we see more use of the invoice workflow, where the three rounds can be called Request, Send, and Receive.
The initial slate sent in request can be accompanied by the wallet address, giving the sender a choice whether to complete the tx over TOR or by sending back a slate over whatever medium was used for the request.
One problem we have with invoice workflow is lack of payment proof, but that can be solved using the techniques of Integrated Payment Proofs.
The main inconvenience I see with this method is that receiver has to initiate the transaction and pick amount, instead of just leaving his address on the table. Although I do agree it could work well for some types of transactions and be a usability improvement.
Note the Suggest step does not need to be part of the protocol, it can be “out of band”.
One example might be checking out on an online store. The process of checking out with a given cart would Suggest the amount to be paid.
Another example might be a simple “I’d like to donate 100 grin” web form etc.
Suggest is simply some mechanism that provides the recipient with an expected amount.
I would like to add that interactive transactions make it possible to break the common-input-ownership heuristic at the transaction building scope - with payjoins. It is possible to break this heuristic with non-interactive transactions as well, but only through transaction aggregation which is after transaction has been constructed and it requires that the transaction is aggregated before it is observed by an information seeking observer - this can’t be guaranteed in the current MW model as far as I can tell. This means that if we want to improve privacy by breaking this heuristic in the scope of a single transaction, then we have no choice but to improve the usability of interactive txs.
I do agree we need to promote slatepacks a bit more when we stabilize whatever changes we plan.
Not practical for all scenarios. Imagine a medium article with a donation address at the bottom. Or a twitter account with a receiving address. The author can’t use a web form to automatically suggest an amount.
Even where it is possible, in a dedicated website, this solution will likely just not be implemented if the owner has to create a new web form just to accept grin. Accepting grin should be as easy as adding a line of text, otherwise who’s going to bother?
It does seem worthy specifically for stores tho, as the suggest step is practically built in already.
Another downside compared to eliminating finalize step, is that slatepacks are transferred 3 times instead of 2. Giving an ugly wall of text along with an address isn’t very cool.
Donations to charities are deducible for taxes. Hence the need for payment proofs when doing donations to them. Also better to use an ELS scheme that uses one kernel rather than two.
Donations might actually be one of the things that Grin would be used for most right now. I think there’s a great overlap between people who would donate to a good cause and people who are interested in Grin.
You are living in the netherlands and maintain a blog that covers various topics with displaying a GRIN-Address for donations. At night you turn your wallet off. Someone from the USA reads a blog-article and want to donate some GRIN. He can’t, the Wallet is not reachable since the blog-writer shut his PC down at night.
You’re on your way to College and have your Laptop with you. Your Mom calls and tells you she tried to send you some GRIN so you can buy the new edition of “Applied Cryptography: Protocols, Algorithms and Source Code in C”, but the transaction fails because your wallet is unreachable. “How that?” your Mom asks. “Well i have my Laptop with my GRIN-Wallet in my Backpack, sorry Mom, we can try another time.”
You’re sitting in the office and Work, there’s currently nothing left to do, someone tries to transfer some GRIN to your account, can’t because you shut down the PC before going to…
and so on, the examples could be continued forever.
GRIN currently relies on that the participants are online at the same time. The only device that might provide this property in scale at all times might be mobile devices (smartphones) that are rarely shut down. Interestingly there is no such official mobile wallet provided by grin.
Success for projects that aim for consumers is always tied to accessability. Thats how smartphones made computers mostly obsolete (in india way more people own a smartphone than a PC): Everyones Grandma understand to press some icons on a dashboard to open up Whatsapp.
As a contender GRIN should have made it easier to do transactions than Bitcoin does. It achieved this only partly: As @tromp pointed out you cannot lose funds due to a typo when you choose a wrong receiving-address. This is really great. But these cannot be all advantages in terms of usability. It lacks behind Bitcoin from a user-perspective because it is more complicated to use.
Non-interactive transactions are a departure from Mimblewimble in giving up this property.
It should be elaborated if the hit on usability - that i consider substantial - that comes with the requirement to be online can be drummed down.
Examples:
The Blog-Writer opens up his PC and GRIN-Wallet next morning. He sees a List of 5 transaction-requests that have been made in the night. He just clicks on “approve” and receives the funds.
The Student arrives finally at collage, opens up his Laptop and GRIN-Wallet and clicks on “accept” and receives the payment of his mom.
and so forth…
All together i really appreciate it that the usability-issues that come with interactive transactions are being way more discussed and i cannot wait to see what technical answers to this issues you will find, so keep up the good work.
You think reducing scalability by doubling the kernels is simple and minimalist? This isn’t a one sided tx, it’s just an expensive way to use the blockchain to store the slate instead of a message relay system.
Adding public spending keys to outputs also enables transparent outputs, using blinding factor 0.
This makes it more like Zcash, with privacy being optional.
Just as with Zcash, one can imagine exchanges supporting only transparent outputs, to better satisfy their KYC/AML requirements.