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 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.
That only gets you up to 1 grin. So then is the explorer expected to subtract 1 Grin *H for up to 10k+ times per output and check the index? This doesn’t sound very practical, and shouldn’t be considered to be on the same page as Zcash.