An open discussion on Non-interactive transactions

True, but the biggest complain about itx is that you need to be online. For nitx, you do not need to be online because you respond whenever you feel like it/whenever you come online.

1 Like

Even if we have two transaction modes, regular users can safely ignore it if we have a perfect UX design which hides all these complexities in the background. When the user is online, use the interactive transaction while when he is offline, simply falls back to the non-interactive mode. Users can be even unaware of all these background tasks which are handled properly and silently by the UX wallet.

1 Like

I think you’re confusing things. Interactive transactions are transactions which can’t be built by only 1 party, that’s why interaction is needed (to create a valid transaction). When and how this interaction happens (immediately over tor or you send slatepack over email) is a separate thing. For nitx you don’t need to be alive since the sender can create a valid transaction by himself and broadcast it

@vegycslol I understand the difference between itx an nitx. I am just pointing out what some perceive as disadvantage of itx, the need to have a wallet online all the time, is less of an issue with slatepacks even though they are itx’s since you can use these side channels.

1 Like

I think you’re missing an important point. You don’t need to have your wallet online all the time. In fact, you don’t want to have it. If you want to be reachable online via tor or something, it’s best to come online “just in time”. But you don’t need this because you can just grab the slatepack, sign it and pass it back whenever you want (not really, it may have a ttl). This didn’t come with slatepacks, the old slates had the same option.

Exactly, that is the point I was trying to make. You are right, this was also possible with the old slates.
Anyhow, I think we are actually all preeching for the same church, meaning we all think that living with itx is not all that bad and that nitx are not a cure it all. See my rant:

This is not great for privacy. Connecting to tor, using it, and then disconnecting makes it easier for those monitoring tor to identify you. Also, if you have a full node and you come online just long enough to transact, anyone can monitor your onion address, see when it comes online, and check which node just joined the network. That’s a fairly trivial way for anyone to identify your IP.

1 Like

I totally agree with this:

I’m completely opposed to this:

Let me be clear, I think that Grin should embrace its unique properties. I believe this will pay off at the long term. That being said…

We must, not only should, we must improve Grin’s usability. Removing “1 or 2 cut & paste” is a huge improvement, a big win, and a statement saying: we do care about simplicity. Of course, we should no push for an ugly hybrid, but even at least one cut & paste that we remove would be a big difference, a truly piece or art.

Let’s imagine a scenario where a user could pay using Grins. The user makes click on “Checkout”, the site generates an Invoice that can be scanned or copied by the user, and after this, the user clicks on “Send”, and done: purchase made.

Another scenario. We’re at the Späti, you paid a beer for me because I only use Grin, no other currency. You open your Android wallet, I open mine, “take the amount of grins out of my wallet” (by setting the amount) and sent the transaction to you. You’re connected to the internet so you can confirm the transaction.

This is like sending literally cash by digital means.

Please, let’s do not undermine the UX because… What will Grin be without users, or miners?


You seem to have misunderstood me, David.

I’m totally in favor of trying to save 1 or 2 cut&pastes.
We must strive to make transacting as smooth as possible.

But not at ANY price. I’m totally opposed to the current hybrid MW proposals to support non-interactive transactions. For me, the costs of departing from MW, hugely complicating the consensus model, bloating the chain, and compromising the security model, are just too high.

Any less draconian methods of improving usability, I wholeheartedly support.

We just need to make sure we get it right. We can spend a year or two iterating on the design and hiring auditors. Complexity just means more upfront work to ensure it’s secure. Once we’re confident the design and implementation are secure, and the code is sufficiently modular (which both node implementations are), then the existence of the complexity has very little lasting effect outside of its impact on throughput (which in this case is relatively minimal).

There is no permanent chain bloat with the LTC proposal. Outputs grow by 15-20%, but are pruned when spent.

As you’ve admitted before, it’s only an “ugly wart” of theoretical interest. It has no practical effect on security.

I spent a lot of time thinking about a 2step solution (disclaimer: I’m not a cryptographer nor an einstein). If you need to manually confirm the transaction and have a permanent address then people can spam you. My issue with 2 step is: it can only work with permanent addresses afaik. So how do you prevent a spam in this case?

Why would you need to manually confirm? You would no more need to manually confirm 2 step transactions than you would 3 step. That’s a completely orthogonal concern.

This should not be an issue, transaction fees are high to protect against spam and as David mentioned the same applies for regular transactions.
Is there a way to try out 2 step transactions or nit without making them part of the regular concensus model? So basicaly experiment with them withou f*ing up Grin?

With auto-receive you don’t need to but in some cases you don’t want auto-receive (eg if you want to generate a payment proof which commits to a memo then you can’t do that with auto-receive)

Okay, but 2 step doesn’t seem to change that problem any. 3-step txs can just as easily be “spammed”.

I think theoretically 3 step can have new address per tx, i believe 2 step is only possible with permanent addresses. I think new address per tx prevents spam

I don’t know if that’s true, but assuming it is, any wallet can just choose to only use an address once anyway.

A coin should be as simple as an 80-year-old woman, and it will be successful as soon as it is downloaded, but grin, don’t mention the small white outside the circle, the old leeks in the coin circle may not be understood, I hope it will get better in the future, otherwise the learning threshold is too high to be popularized easily.

If bitcoin lightning can be made easy-to-use, then so can Grin.

Grin is unique in its simplicity [1]. That is something worth preserving. A simpler coin is easier to study, understand, and explain to others.
And simpler to implement in your favorite programming language.
Grin’s lack of non-interactive transactions is a temporary hurdle. A complication of its essential operation is going to hamper its long term prospects.

Let’s keep Grin simple!



You’re proposing to make a controversial change to the consensus model, which will likely lead to a fork of Grin, just as the Bitcoin big blockers forked away due to irreconcilable differences.
This is not in the best interest of Grin.

I can imagine a future where many people don’t download the kernel history, but a zero knowledge proof of its existence [1]. Then the IBD is linear in the UTXO set, and the bloat is not insignificant.

A clean security model is an integral part of Grin’s appeal.
We shouldn’t have to explain to peple why “year old coins can be stolen by a week-deep reorg” is acceptable.

[1] Cryptology ePrint Archive: Report 2020/1618 - Proof-Carrying Data without Succinct Arguments