An open discussion on Non-interactive transactions

Development and Technical Discussion
1

Hi all, long time lurker, first time poster hah.

I want to start by saying that I enjoy, and I am passionate about blockchains for what they fundamentally allow: “freedom of transaction.” That is to say, an “Open, Neutral, Decentralized, Borderless, censorship-resistant” conveyance of value from one party to another.

I fell in love with grin when I understood this value proposition, and what Grin offers the ecosystem by virtue of scalability. On top of that, add transactional privacy on base layer with amounts. Objectively, this is a “break-through,” and we should be excited about it. Admittedly, I feel a bit “late to the party,” as everyone has contributed so much, but my passion speaks.

I have over the months become dismayed about the fact there is so much contention over the vision of this opportunity.

What I aim to do is extend the dialogue regarding a feature many in this community desire, and one that would add conventional usability: Non-interactive transactions. This of course would not dismiss the opportunity for interactive (and all the future possibility it could entail); as I understand, interactive as “opt-in” maintains many of these benefits of interactive if implemented correctly.

I’m not asking for a rash judgment, or a mutiny of code/fork or anything of the sort.

I am asking that the voices of the many who feel disenfranchised in the process to be heard.

Let us as a community, of which each of us is a member, allow for a fair and robust analyses of the Non-interactive proposals’ merits. There are a few proposals which many feel have not been given the proper diligence in discussion, or “air time.”

Let’s do it.

With the community funding paradigm shifting, my desire would be we have all options on the table, fund a 3rd-party team of cryptographers (who may even improve it on simplicity, let a lone on security.)

I could be way off base, so please let your voice be heard. I want to stress that this is not to take away from any of the efforts of the “core” team, or any contributions yet-to-come that may deviate in vision. I do, however, believe it’s a valuable, necessary option for a blockchain that scales as a more-private, decentralized cryptocurrency. We are the community, and we owe it to the future to try.

5 Likes
2

No cryptographer here, but what I think is the most realistic approach is to use some modified stealth transactions (Diffie Hellman) as Tromp and others discuss here and in many other posts, se the bottom of this linked post for all links:

Or Mingle Jingle:

A second approach which is a more wallet based, is to use HD wallet key derivation to generate and share derived public key m’/44’/Use/n. E.g. The exchange can use this derived public key to derive more next level public keys with an exchange to allow one sided transaction for that exchange. For each such gateways a separate use key is shared derived from a hardened ancestor from which children keys can be derived. Such transactions are probaly not private, so their only use is to facilitate communication with gateways, e.g. exchanges and mining pools to stubborn to implement slate packs.

The added advantage of having transparant gateway transactions would be that they make Grin complient with government rules for having KYC endpoint for the receiving wallet. From there on, the user can obsfuscate all transaction that come in by sending the funds to him or herself using normal Mimble Wimble transactions, so the privacy leak is not that big. Because such transactions are not normal Mimble Wimble transaction they could be put in a side chain, extention blocks, or possibly a whole separate Grin-Gate or Grin++ chain that preferably shares its proof of work with the Grin main chain. The idea is that only a fraction of the transactions, e.g. 5-10% would be these kind of transactions. I am only not sure if such an approach could be linked to normal Mimble Wimble transactions, e.g. by burning on the main chain and creating on the side chain with the proof that all coins are togther equivalent to (time-(time0+1))*60. To avoid slowing down validation on the main chain, maybe the total amount of Grin on the side chain can be put in each block header of the main chain.

Now again, not cryptographer here, so probably the above solution is not even technically possible or making sence :upside_down_face:.

3

I let my voice be heard previously [1] [2] [3]. In summary, I’m strongly opposed to departing from the beautiful simplicity of Mimblewimble and turn it into some ugly hybrid in order to save 1 or 2 cut&pastes.

As the original MW implementation, Grin should embrace its unique properties rather than subvert them for the sake of conformance. Interaction allows us to

  • transact with the assurance that the funds end up with the recipient able to spend them [4]
  • agree to a payment proof stating the purpose of payment
  • use payjoins for obfuscating direction of payment
  • have a seamless migration to use of payment channels and a 2nd layer that will be critical to improving scalability by orders of magnitude.

We have yet to fully realized the advantages that interaction offers, and should not be disincentivizing progress on that path by getting most people to revert to non-interactive transacting. Especially not when that comes with big downsides of hugely complicating the consensus model, adding bloat to the chain, changing the security model, and having to support two different forms of transacting.

[1] Pep Talk for one sided transactions - #8 by tromp
[2] https://forum.grin.mw/t/non-interactive-txs-and-usability
[3] Minglejingle: Scalable blockchain with non-interactive transactions - #13 by tromp
[4] [bitcoin-dev] BIP70 is dead. What now?

11 Likes
4

I really appreciate the reply! I want to say thank you for all the work you have put into the protocol, and I would not see it “subverted” for conformance! However, as stated, many disagree with this approach (hence the post!)

We should at least investigate the proposals for non-interactive (with interactive opt-in) if that is what the community desires, and we can subsequently find interested developers to approach.

Is it your position (barring any other security concerns proving non-interactive viable) that even-so you would not be interested in developing on this approach? If so, that’s fine!

What my intent with this post is to discover and give voice to those that disagree. I am still very-much interested in this answer though: What is your primary desired objective for grin as a block-chain? As I understand, blockchains are really only useful for securing the transport of UTXOs from one party to the next trustlessly. Can you please let me know your (personal) objective?

Thank you!

5

Payjoins by default also make utxo set increase a lot slower. Also interactive transactions allow each party to pay for their own fees.
I think it would be a shame to force nitx without fully exploring itx. I also think we have a lot of time before any such decisions are made (because of grin’s emission model).

6

Personally I feel no need to add non-interactive transactions to Grin unless they are fitting. What would be good though is to think as a thought experiment what would be the least ugly approach of doing such an experiment without forking? Forking is not an option I am open to since the ‘problem’ we are trying to solve is not worth it in my opinion. Or should we simply have online wallets like Grinbox again for those who experience the need for interactivity as a ‘problem’?

1 Like
7

Okay, perhaps I am mistaken then, so please correct me: With interactive as “opt in” how would that not allow each party to party to pay his or her own fees? Genuinely confused here. As I understand, non-interactive w/ opt in can preserve these benefits? Am I mistaken? Thx in adv

8

I think this is the central divide so please: Pray-tell, what problem are you trying to solve?

9

Problem = interactivity, the need to be ofline.
Some hate it, some love it. From a practical point of vieuw it is a disadvantage since many exchanges do not want to put in the effort to support interactive transactions which is different from what they are used to. So actually the problem migh not even be the interactivity itself, but the perception that interactivity is to blame for having few exchanges that support Grin, that interactivity is to blame for the price if Grin falling the first few years. So maybe the true problem is wrong expectations, disapointments and blaming that on interactivity, which is at the heart of Grin. For those not happy with Grin, always good to analyse what the root cayse is of this unhappyness for yourself🤔.

Hence I am trying to think of the least ugly workaround to make those who hate or blame interactivity to become happy with Grin again.

10

Hmm. Well, it would seem that if a proven-secure mode of offline transport (non-interactive w/ interactive opt-in) might be the way to go then.

11

If you keep itx as opt-in then each can still pay for their own fees when doing itx. However I think opt-in is a mistake, doesn’t matter if itx are opt-in or if nitx are opt-in. It creates 2 possible transaction creation ways which devs need to pay attention to and it complicates the design. It also complicates understanding for wallet users since there are 2 ways now. To me it’s either one or the other (note that if i saw a solution which doesn’t complicate that i could change my mind). I honestly prefer itx over nitx when I’m the one sending the transaction. I do understand if it’s harder for a regular user to understand itx process but i think UX and guides can be improved

3 Likes
12

Great! Thanks for your honesty. I would disagree on the premise of “one or the other” I think a lot of people that say that rely on others’ talk. As I try to stress, if it’s proven secure right? So now we have a way where we can both! It has been hazard tested from all angles time and time agian, and guess what? Still secure! Can you imagine how formidable grin is then?

My idea will see a fitness test as well as a bounty test (similar to LTC w/ segwit) and afterwards… still secure? Would you support or you are like “nah, one or the other”?

13

I really want to stress, this isn’t a discussion on the merits of “one or the other” but IF both are proven secure. Please do not reduce replies to attacking “only” non-interactive. Thanks!

14

I don’t follow, which “way” are you referring to here?

15

Sorry, I mean to say if a proposal w/ both (non-interactive w/ interactive opt-in) “both” modes of transport are deemed secure. We deserve the opportunity to know.

16

Still one or the other for me. Having both tells me “they don’t know where to go so they’ve complicated the system to support both ways” which doesn’t sound good to me (sure it can be interpreted differently but that’s my view on the grin situation). I’ll stop here to not spam this thread anymore.
Edit: btw if we have a proof that it’s secure you still require a secure implementation of this idea

17

Yea, that makes sense, “me too” as they say. What we would need then, in my estimation, is a robust testing of some proposals to deem them “secure.” Ugly? Not so sure on that one, but I get your point. Code does evolve, and it can become complicated, although both the benefits and testing (w/ proposed "bounty and cryptographer testing) I hope to overcome this hurdle. The community will never get the chance to know unless we try. Defaulting to “ugly” and “unsecure” seems kind of knee-jerk imo

18

Yep! and security will be deemed by the testing, which is the idea :slight_smile:

19

This assumes that more options = better. I believe the opposite to be true. You want to achieve as much as you can with the minimal set of functionality. Blockchains are different that usual software systems because they can’t forget (even MW!) and need all the old rules to stay around forever so adding only minimal changes to the consensus sounds like a way to move things forward. If you look at a transaction in isolation, every non-interactive transaction can be created with an interactive flow, but not every interactive transaction can be created with a non-interactive flow - a prime example being PayJoin transactions. This is only from the transaction perspective where interactive transactions seem to be superior with regards to which transactions can be built. The set of interactive transactions is a superset of non-interactive transactions. So the question then is why would you add another system which adds the possibility of creating a subset of transactions which can all already be created? I think some of the answers may be that there may be cases where:

  1. the receiver can’t sign the transaction (or doesn’t want to)
  2. the sender and the receiver can’t communicate (I don’t expect this to realistically be an issue with e2e encrypted chat apps).

The example of 1. would be donations, where the receiver doesn’t want to have a receiving wallet listening for every transaction because the time at which they would be contacted is unknown. How do we solve this with interactive transactions? We don’t know yet, but I’m leaning towards not adding a whole new system and drastic changes to the consensus model to cover this use case. I believe there may be 2-step schemes which unfortunately don’t come with a payment proof so perhaps they’re not really useful.

There may be other issues as well, but I don’t think interactive flow we have with slatepack copy/paste is a horrible UX. I personally would prefer to use this flow in Bitcoin when I’m withdrawing from an exchange. So my view is that focusing on making these cases a smaller problem over time might be a better step than restructuring the whole MW to fill for these edge-cases. Are all people going to like interactive transactions? No, they won’t. Is it worth restructuring MW for it? It seems like people have a different opinion on this. Interactive transactions do come with some challenges, one of which is that the exchange integration needs to be done more carefully and takes more time. This is a valid concern, but (again), I’d prefer if we made it simpler using the existing tools and not restructure most of the MW because of it.

I also see some advantages that @tromp did not mention - maybe he doesn’t value them as much as I do. One is that interactivity can allow the receiver to manually confirm what they are receiving. Some say this is a horrible UX, I’m saying it’s a very interesting feature. It’s impossible to control incoming traffic to your wallet in Bitcoin and likewise, it is impossible to control it if you “auto-sign” a receiving transaction. As @vegycslol also mentioned on keybase, it also seems impossible to add a reference hash/memo to the payment proof when the receiver is auto-signing. The second benefit was already mentioned by @vegycslol which is that 2-2 payjoins could be thought of as transactions that have no possibility of changing the UTXO set size. I’m not going to dive into payjoins here but perhaps this would be an option sometime down our road.

My view on this whole thing is that we cover some edge-cases by introducing non-interactive variant, but at the cost of a drastic change of MW itself. To be clear, I don’t know which flow is superior, but I’m personally leaning towards interactive transactions and researching these further. One thing I’m sure of, is that not a single person understands Grin’s interactivity fully. It’s an area that has yet to be explored.

1 Like
20

A secure interactive txs always beats a less secure ,more usable nitx.

Slatepacks are nitx,it is user friendly.

No problem.