I see how non-inflation is a verifiable property of a grin history, but I
don’t see how proof of authentication is a separate property. How would you have the former without the latter?
I may be wrong about this, but I’ll share my current understanding. The two are separate also in Bitcoin. In Bitcoin you can prove chain noninflation at the tip of the chain by summing the amounts of the outputs in the utxo set. This alone doesn’t tell the historical authentications are valid. The MW equivalent is by checking the grand balance oneliner formula. In Bitcoin you can get proof of authentication by replaying the whole history. In MW this is again verified with the grand formula. But this doesn’t mean they are the same thing, it’s just a “coincidental elegance” of MW that both properties are achieved with a signed kernel because one is proven with the H part being 0 and the other with the G part. I believe the nitx proposals (apart from @tevador MingleJingle whose main purpose I believe is to fix this issue that both David’s and Gary’s proposals have) have only trustless non-inflation verification. My understanding is that trustless proof of authentication gets lost because a new node can only verify (in a trustless manner) the transactions that are in the last week of blocks (I think). It cannot tell with only mathematical assumption (as is today in MW) that any other NITX had a valid state transition as would be defined if you were processing it live (due to the reorg problem mentioned in the nitx spec). It can only tell that the receiver or the sender spent it which doesn’t prove the receiver signed the transition. This means that a new node must trust people that no shady stuff happened in the past. So you have the former and don’t have the latter. And the issue comes from pruning a part of the authentication proof. This may sound like only a practical concern, but afaict it’s a really important property of the blockchains if we aim to be trustless/trust-minimized.
Perhaps another example of having proof of non-inflation but not proof of authentication would also be the original CT where blinding factors are not authentication keys. If you pruned the signatures in a pure CT setting, you can prove non-inflation of a transaction, but you can’t prove authentication without the signatures. The NITX proposals as I understand, like original CT, require external signatures for authentication but then prune these.
P.S. yes, in Bitcoin a full replay also proves noninflation, but that’s besides the point.
P.S.2. I have not read Gary’s proposal, so I’m trusting the MingleJingle proposal that this one loses this property as well.
1 Like
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
-
simplicity is underrated in most projects and Grin’s value will increase as people realize this more and more.
-
Requiring interactive txns seems to make Grin more simple
-
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