An open discussion on Non-interactive transactions

Ok; so you’re saying that currently, the non-inflation proof (the single Grin equation) also serves as authentication proof, but if we adopt nitx, then the new recipient signatures become a part of the authentication proof that must be preserved beyond one week to make for trustless historical verification?!

That’s my current understanding, yes. The current grin equation captures all the authentication keys because they’re just blinding factors. This is no longer true for NITX because the blinding factors are only a part of the authentication key. I think it weakens the model of trustless historical transaction validation of tx authentication from “I know the receivers correctly signed all the past transitions” to “I know that either the receiver or the sender correctly signed all the past transitions” because both of them know the blinding factors. To get to the same verification you need to trust people telling you no funny things happened in the past.

P.S. Perhaps this is also good to have to avoid any FUD from competing chains saying that we had such an event or something. With the current model, we can simply prove that this could not have happened. Just like Bitcoin.

1 Like

It seems Pieter Wuille (as well as fiatjaf) also prefers interactive transactions on chain and calls them out for having a better UX than the “send to address” transactions https://twitter.com/pwuille/status/1475173933334859781

2 Likes

i wonder if that’s because (imo) vast majority of transactions are “pay to service” where invoices are preferred and with itx invoices are more natural

Today I spent some time thinking about scripting and made some writeup. I don’t guarantee it works, and am not motivated enough to research this further because as mentioned in the document, I don’t think it’s a good fit for Grin - perhaps other projects would find it interesting. The reason for it being mentioned in this topic is because I want to document a different path for anyone that may be interested in this and because this may allow getting NITX (and other spending conditions) while preserving the MW/Bitcoin security model. Again, I don’t think we want this, we want interactive transactions made simpler because they are, in my opinion, the bread and butter of MW.

3 Likes

Very interesting. Would you mind sharing what makes this a bad fit for grin? It does complicate things and effectively doubles the amount of kernel data that must be stored forever, but I cant think of any other problems.

Perhaps some would argue that enabling non interactive TXs is a bad idea, because of the ability to lose coins with a bad destination/script/etc, but that is a holistic opposition to NITXs and not really a criticism of your (non)proposal.

I’m one such guy, but the problem with enabling nitx isn’t only that you can send to the wrong address (even with auto-receive you can do that now), the main problem is that you lose the advantages that come if you only have itx (eg. “everything that is in your wallet has been approved by you” no longer holds, people can spam you, send 1million tokens in your wallet which you can exchange only on a scam site - yes, grin has no tokens today but maybe it will get them in the future, who knows)

Those are good points (which I agree with), but I was wondering the criticisms specific to @oryhp’s non-proposal, and not just general arguments agains NITXs

It adds substantial complexity and bloat. I’m not a fan of what is going on over at Bitcoin even though I think they have the best gatekeepers one can have, it seems impossible to stop constant arguments over op_codes and similar scripting related opinions. Opening a “Virtual machine/Scripting language” vector invites all the unnecessary drama on L1 that nobody really needs or wants. I believe there are more downsides than benefits in the long run. The less L1 can be politicized, the better off, more stable and more predictable it will be. I have no doubt we will live in a multichain world and each chain will be good at some things. I would prefer having scripting either done with something like improved scriptless scripts or simply atomic swaps on other chains or wrapped Grin. Grin is already really good at what it does, but we need to push for simpler interactive transacting. I don’t think noninteractivity or scripting will be that important in the long run, at least not as much as people tend to believe. I may be wrong, but we have time to research all the paths and improve Grin experience in many other ways before making any such drastic changes. Besides, I have a feeling scripting could be explored a bit further, potentially in a more powerful scriptless way.

1 Like

Well said. If a project was interested in scripting or NITXs, the approach you describe certainly seems interesting. Thanks for sharing.

1 Like

Thanks for reading. Btw, I was hesitant about sharing this gist because I was afraid this could be interpreted as all rainbows by some that may be less technical and/or may not value some strengths of Grin as much as some of us do. The alternative is to hide the ideas which is worse. I guess my strategy here is to convince people Grin does not need this particular feature.

1 Like

I’ve seen a lot of people invest time and energy into solving the NITX “problem” only to get shot down for various technical or philosophical reasons (I’ve even spent a few hours exploring the subject myself), but I never realized until now, that the community/core had come to conesnus that NITXs are not wanted.

If consensus is that NITXs are not desired, regardless of whatever hypothetical solutions people devise, it might be a good idea to advertize that loud and clear somewhere, so others don’t invest time on solving a “problem” nobody wants solved.

I can’t speak for others, but in my case, my view on that matter evolved over time. I was excited about the first NITX proposals, but as I started researching transactions in general, I discovered that Mimblewimble is the only design that can require interactivity. This is a very unique chain feature that can differentiate the project in the sea of copy/paste projects. It brings some new properties to the space and comes with a single method of transacting that can express any kind of transactions (unlike NITX which can’t do payjoins or commit to a memo etc.). I’m not sure how long you’ve been around, but there have been quite a few discussions around that (on forum and also on keybase if I recall correctly) and the community, at least those still active here, have gotten more and more supportive of the interactive path. That’s just my view/observation though.

1 Like

i don’t think it’s that clear that they don’t want nitx, it’s just that if they do implement them now then there’s no way back. So until there are some obvious reasons as to why nitx are needed alongside itx it doesn’t make much sense to commit to them now imo.

1 Like

Thinking about this some more, and I wonder if this is true. @oryhp’s proposal would only expose users to that risk optionally. A user could choose not so share an address (or shared secret, or whatever mechanism to enable nitx) if they didn’t want that risk. They could continue to use ITX only without the risk of dust attacks etc.

So then the question becomes: is it better to give the user the choice what risk profile he prefers? Or limit all users to what the community deems “safest”?

1 Like

You’re right, if a user never shares their “address”, nobody can create a “script output” with their signature as a spending condition in the script. I’d say options with sane defaults are good, but it shouldn’t make too big of a tradeoff. There are more problems than I mentioned. This breaks the nice uniformity our outputs/transactions have. We get different output types which will reveal patterns in the graph and reduce anonymity sets because people will be reusing the same NITX/ITX patterns. We also have a new kernel type which can be connected to the script output although I’m not sure of the consequences of this. For NITX we would also have to communicate the amount and the blinding factor, as well as the merkle tree of the spending script with the receiver and probably find a way to scan our outputs. I didn’t dive into how these things would be handled, but all of these are a source of their own complexity and even then we have yet to touch script evaluation and opcodes. I think it’s very cool our outputs look the same, they can’t leak information by design (apart from coinbase label). This alone is something probably worth preserving.

2 Likes

Not a ‘core’ member whatever that might even mean (I was guilty of proposing that name long time ago to lehnberg, mea culpa). My opinion right now is that NITX are not needed for Grin to strive. There is a lot to like and still to explore in Interactive Transactions.

This does not mean that NITX are not interesting, just not for Grin in the current phase of the project. Other projects can play with these ideas and perhaps they will even at some point be included in Grin. Personally, I would only be in favour of incorporation in the format of extension blocks, side chains, merged mining etc. So not part of the grin main chain which should stay minimal, uniform and scalable IMO. The only exception would be if NITX would be uniform with ITX transactions, this is however technical not possible I think. All solutions so far add bloat and complexity,

I think in the past the misconception has arisen that people that do not want to implement NITX within Grin are therefore against NITX in general. Many, including myself find NITX fascinating, this however does not mean they are the best fit for Grin as a project in this phase of the project. There are other projects that might be better fits. Take Litecoin for example, I applaud their implementation of MimbleWimble Extension blocks. The solution of NITX transactions in Litecoin are a perfect fit for Litecoin, less so for Grim.

2 Likes

My view is that

  1. simplicity is underrated in most projects and Grin’s value will increase as people realize this more and more.

  2. Requiring interactive txns seems to make Grin more simple

  3. Slatepacks can provide as-good or better experience to non-interactive txns. Combine slatepacks with a decentralized messaging protocol and we have a killer app.

for these reasons, I think it is worth holding off for a while on non-interactive ideas and letting things breathe a little longer.

4 Likes

Slatepacks provide already a synchronous transport method via tor and a asynchronous transport method via copy and paste. I would like to have chat messages included as an optional feature in grin wallets / slatepacks. Direct chat messages between grin addresses (wallets) for informal talk about payment conditions would be a nice feature. I would like it more to integrate this into the existing slatepack protocol and wallets, than to include slatepacks into existing messaging protocols like matrix and xmmp or applications like keybase. Also for an interactive grin transaction it would be very nice to have the ability to optional include a text description, what the payment is about, in the final paymentproof.

Tightly coupling wallets to a specific messaging protocol increases size of codebase, increases things that can break, decreases decentralization and freedom. But it could be a faster solution…

Leaving it agnostic in terms of which messaging protocol it uses would probably remain the best option in terms of freedom.

In any case, there are some threads about this

2 Likes