# Non-interactive txs and usability **URL:** \ **Category:** Development and Technical Discussion\ **Created:** [September 11, 2020, 9:50am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818 "2020-09-11T09:50:52Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 11, 2020, 9:50am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/1 "2020-09-11T09:50:52Z")
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. ---
**Author:** ![Paouky](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/paouky/32/513_2.png) [@Paouky](https://forum.grin.mw/u/Paouky)\ **Post date:** [September 11, 2020, 10:32am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/2 "2020-09-11T10:32:43Z")
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. ---
**Author:** ![MerlinsBeard](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/merlinsbeard/32/2863_2.png) [@MerlinsBeard](https://forum.grin.mw/u/MerlinsBeard)\ **Post date:** [September 11, 2020, 11:24am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/3 "2020-09-11T11:24:26Z")
Can this not be solved by adding an additional step where the sender sets the amount before the receiver requests? Suggest, Request, Send, Receive ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [September 11, 2020, 11:36am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/4 "2020-09-11T11:36:05Z")
> [@MerlinsBeard](#): > > Suggest, Request, Send, Receive 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. ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [September 11, 2020, 11:38am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/5 "2020-09-11T11:38:08Z")
I would like to add that interactive transactions make it possible to break the [common-input-ownership heuristic](https://en.bitcoin.it/wiki/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. ---
**Author:** ![Paouky](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/paouky/32/513_2.png) [@Paouky](https://forum.grin.mw/u/Paouky)\ **Post date:** [September 11, 2020, 11:47am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/6 "2020-09-11T11:47:54Z")
> [@MerlinsBeard](#): > > Can this not be solved by adding an additional step where the sender sets the amount before the receiver requests? > > Suggest, Request, Send, Receive > [@antioch](#): > > 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. 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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 11, 2020, 11:50am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/7 "2020-09-11T11:50:50Z")
> [@antioch](#): > > Another example might be a simple “I’d like to donate 100 grin” web form etc. The most used example will be entering on an exchange website how much you want to deposit. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 11, 2020, 12:03pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/8 "2020-09-11T12:03:11Z")
> [@Paouky](#): > > 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. For those situations, where payment proofs are not needed, the non-interactive transactions described in [https://github.com/mimblewimble/grin-rfcs/blob/a2d9f25cdccf29904ef241df5b608ca3fd16ed61/text/0000-onesided.md](https://github.com/mimblewimble/grin-rfcs/blob/a2d9f25cdccf29904ef241df5b608ca3fd16ed61/text/0000-onesided.md) should suffice. ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [September 11, 2020, 12:13pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/9 "2020-09-11T12:13:30Z")
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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 11, 2020, 12:18pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/10 "2020-09-11T12:18:54Z")
I’m not sure that our current payment proofs are acceptable for the IRS. You probably need some statement from the charity for tax purposes. ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [September 11, 2020, 12:19pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/11 "2020-09-11T12:19:45Z")
We cannot count on the fact that it will never ever happen (it probably will, if not already the case for some). ---
**Author:** ![MerlinsBeard](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/merlinsbeard/32/2863_2.png) [@MerlinsBeard](https://forum.grin.mw/u/MerlinsBeard)\ **Post date:** [September 11, 2020, 12:29pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/12 "2020-09-11T12:29:28Z")
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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 12, 2020, 7:03am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/14 "2020-09-12T07:03:34Z")
> [@Grundkurs](#): > > GRIN currently relies on that the participants are online at the same time. It does not. It relies on slatepacks send back and forth, which can happen at different times. ---
**Author:** ![johndavies24](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/johndavies24/32/1828_2.png) [@johndavies24](https://forum.grin.mw/u/johndavies24)\ **Post date:** [September 12, 2020, 3:17pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/15 "2020-09-12T15:17:49Z")
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. ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [September 12, 2020, 3:40pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/16 "2020-09-12T15:40:37Z")
> [@johndavies24](#): > > it’s just an expensive way to use the blockchain to store the slate instead of a message relay system. It’s also insecure (no payment proofs) and requires a fork in order to store the diffie-hellman secret as part of the output. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 12, 2020, 4:52pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/17 "2020-09-12T16:52:49Z")
Good point. I updated the RFC with said additional drawback and declared it unacceptable. I guess Grin remains unsuitable for donations until we figure out a secure reduced round protocol. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 13, 2020, 10:31pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/18 "2020-09-13T22:31:21Z")
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. ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [September 13, 2020, 10:41pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/19 "2020-09-13T22:41:00Z")
How? I don’t see how observers would know the blinding factor is 0, unless they decided to grind through all possible coin values. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [September 14, 2020, 6:44am UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/20 "2020-09-14T06:44:24Z")
It would not be hard to make a block explorer that has an index of a billion unblinded commitments to easily recognize them. ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [September 14, 2020, 5:27pm UTC](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818/21 "2020-09-14T17:27:29Z")
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. [Next page](https://forum.grin.mw/t/non-interactive-txs-and-usability/7818.md?page=2)