There were some discussions on keybase around transaction interactivity/noninteractivity. I think it’s partly my fault for these continuous disagreements because I started these discussions but have never presented a somewhat clean document that would try to present the key differences in one place. This post is an attempt at creating such a document. Please take the time to challenge the document and try to find the pros and cons of all the approaches. The purpose of this is to share and learn as much as we can and write down all the differences we find. Only after we truly understand these options can we make an informed decision when they are appropriate.
As most of you are aware, I like interactive transactions so read the document with this in mind. It’s quite possible I missed some things that were discussed before or made some errors so I’m expecting some comments to pop up, but nothing was omitted on purpose, so please let me know if you find anything and I’ll add the to the table if they belong there. Also keep in mind that this is research more than anything else as I’m still learning about this.
Network/protocol - Transaction creation between two parties requires exchange of information over the wire
User/UX - Transaction creation between two parties requires user interaction usually in the form of transaction acceptance confirmation
Bitcoin has noninteractive transactions which don’t have Network or User level interactivity (at least not by default).
Mimblewimble comes with interactivity at the protocol level which means that the transaction creation process MUST be interactive on the network layer, but we may be able to avoid interactivity on the UX layer. Let’s call this User level noninteractivityUserNITX. Similarly, we name user level interactivityUITX. Grin performs an automated receive today which makes it a UNITX flow. This document tries to describe the difference between these flows as are understood by some. The table below likely contains mistakes and is probably missing a couple of points. It’s a table that will be updated over time.
Action
UITX
UNITX (Grin)
NITX (Bitcoin)
Full wallet control
✓
X
X
Payment proofs (value commitment)
✓
✓
✓
Payment proofs (content commitment)
✓
X
X
Custom payjoins
✓
X
X
Unified SRS/RSR flow
✓
X
/
JIT seed decryption (fingerprint/password)
✓
X
/
Doesn’t require scanning the chain upon opening the wallet
✓
✓
X
Wallet level labeling of created outputs
✓
X/✓
X
No permanent address spam issue
X
✓
✓
Doesn’t require communication between parties
X
X
✓
Users already understand this
X
✓
✓
Explanations:
Full wallet control - In NITX setting, the receiver can only control which outputs are spent, but has no control over which are received. This opens a lot of unwanted state injections like dusting attacks or “dark/illegal” outputs to the wallet. Controlling the incoming traffic is easier to reason, easier to regulate and eliminates these issues completely at the cost of a click on “Confirm” and a little wait time for the other party. This wait time may require asynchronous transaction building which would mean that the party performing step1 would need to add the Tor address to the slatepack.
Payment proofs (value commitment) - The sender can prove the value was sent to the receiver by showing the payment proof.
Payment proofs (content commitment) - UITX allows for a more powerful version of payment proofs which allows the transaction parties to commit to an arbitrary statement/document by signing the hash of the document. Signing documents requires their review prior to signing which makes it only possible in the UITX setting. An example of such a document could be an actual invoice from a store.
Custom payjoins - The receiver could pick manually which input should be contributed for a payjoin transaction in SRS flow
Unified SRS/RSR flow - RSR flow requires user-level interactivity. This means that if SRS has UITX flow, the two become very similar.
JIT seed decryption - The receiver needs to be able to build an output. To minimize the time the seed is in memory, the user could just-in-time decrypt the seed to create the output. This could be done either by entering a password or through a fingerprint on mobile phones.
Doesn’t require scanning the chain upon opening the wallet - We usually need to scan the outputs to see if they belong to us. If our wallet created the output and then sent it off to the chain, then we never require scanning whether the outputs on the chain are ours (unless we reuse the seed on a different device). We can simply check if the outputs we created exist on the chain.
Wallet level labeling of created outputs - The receiver could label the output on the wallet level at the output creation time. The current UNITX could also achieve this if the label information was added to a one-time grin address when it was generated.
No permanent address spam issue - Since UITX requires manual confirmation, this means that someone could spam the wallet by repeatedly sending step1. This can be solved with one-time addresses (I believe this does not require multiple Tor addresses).
Doesn’t require communication between parties - Creating a protocol-level ITX transaction requires some form of contact between the sender and the receiver. This can only be avoided through pure NITX.
Users already understand this - This isn’t a flow people are used to in the crypto world because ITX.
ITX are generally thought of as strictly inferior transactions. My point is that it is at least not obvious as to why that would be the case. ITX have their own unique properties that may be worth exploring further.
Exchanges
UITX is possible even for 3rd party services. The service would need to use the flow such that the user always has step2 which is done manually. An example would be the user selecting which items they want to buy, the exchanges provides the document and memo to sign in step1 which are both manually confirmed and signed by the user at step2.
It does under our current slatepack standard. But with a change to the address format, onetime addresses with a single tor listener is possible.
Not strictly inferior, but I’d say strictly more difficult to use. Few people dispute that there are some advantages to ITX, as you point out here. But what a chart like this doesn’t portray very well is the importance of each item. To many of us, the fact that NITX are more natural (10) and don’t require communication with the receiver (9) far outweigh the importance of everything else in this list for most everyday transactions.
Regardless, this is a very well written and useful resource to point people to. Thanks for writing it!
U(N)ITX doesn’t require scanning the chain upon opening the wallet; only when it has signed for a tx that it hasn’t see confirmed (assuming the wallet knows it’s the only one using its private keys).
This is another contrast with NITX.
In the majority of cases, when one party pays another, they are already in communication, be it on a website, or some chat forum, or messenger. If only to agree on the amount to be paid.
Nice overview @oryhp.
One thing I still feel that is under-explored is hybrid interactive transactions of sorts. Lets call them HITX
With hybrid-ITX I mean something like a special interactive transaction that has all the benefits of ITX and still requires a party (e.g. third party) to perform the ITX, but contains some additional marker or lock part that marks the transactions as being locked, requiring some additional signature for spending. Possibly some other proof part the sender commits to that is included in the address.
If such hybrid transactions would be technically possible, a user could simply use an exchange wallet as always online wallet without having the risks normally part of using exchange wallets. Such hybrid transaction would also allow cold-storage and the use of hardware wallets without the need to be continuous online with your leger/trezor plugged in.
I think I argued for such a hybrid-option many times. Since no one ever entertained the concept I assume there are technical reasons that make such hybrid transactions impossible. Unfortunately I lack the knowledge to explore anything resembling a proof of concept. Intuitively I do still think that such hybrid transactions might end up being the best way to implement something resembling NIXT with all the advantages of ITX’s as close as possible to pure Mimble Wimble.
If you want all the benefits of ITX I listed, then I think that you must have interactivity because some of the items on the list require human review prior to signing off the tx.
When you add such elements to the output, then to preserve the same security model, you’d need to keep the signatures around forever. This is actually similar to what NITX proposal from David does except that the signatures are dropped after a week iirc.
My hunch is this is impossible. MW achieves cut-through under the same security model because the creation and spending require the same information which allows for cancellation of these events and thus pruning of historical transition. As soon as you add another piece of information to the spending part, it becomes asymmetric and requires new rules and validation that new nodes would need to do.
Probably you are right. I am always pondering if something like a second receiver blinding factor (private-key) could be used that is somehow linked to/proof ownership of the first blinding factor of the receiver without the need to be explicitly on chain (so just as part of the normal Mimble Wimble transaction or somehow linked to the excess or the value part after the comma). Although I think this part is possible, it probably would mean that the third blinding-factor has to be interactive as well in order for it to be pure mimble-wimble, meaning it just a multi-sig ITX.
The alternative is probably indeed what David already proposed.
I think this idea keeps on pestering my mind until I take the time to write if out and once and for all proof to myself it is impossible.
I’m assuming you’re talking about the rust wallet.
yes
You sent me a slatepack so I have it somewhere as a string of characters. This could be on google hangouts private chat where you pasted it to me or publicly on a forum.
yes, I call the receive command with grin-wallet receive and it asks me to paste the slatepack you sent me. After I do this, the wallet outputs a slatepack message which I then copy to you.
yes. The finalize also broadcasts the transaction to the network.
In the flow you described, there is no Tor. But we didn’t describe how the slatepacks are exchanged, we just said “I send the slatepack to you”. The docs mention “This interaction could even take place over email or Signal (or carrier pigeons )”. Tor is just one of the possible transport layers and the Slatepack RFC chose Tor as the layer through which people exchange slatepacks. It describes where information about the transport layer is stored and how the slatepacks look like so that the parties have a standardized way of sending slatepacks.
The UITX copy/paste of strings does not use Tor. But UITX can use Tor with all the Tor benefits which is to exchange the slatepack in an encrypted way and masking the source and the destination by bouncing around the network of nodes. In fact, the rust grin-wallet can do that today because it tries to contact the Tor address by default. The only reason I’m not using this is because I want to manually confirm (UITX, not UNITX) and right now the grin-wallet doesn’t support Tor exchange in this way, but I don’t think there are any major obstacles for having this supported at some point.
UNITX could use Tor the same way it does now (UNITX is basically auto-receive). So i’m guessing you meant the benefits of Tor for UITX, which would imo go like this:
We agree on performing the transaction.
You share your address with me.
I start the transaction, which is not finalized yet, and I share the slatepack message with you through Tor address, which is included in your grin address.
You receive the transaction information, add it to the database
You either accept or reject this transaction. If you reject it, then the flow ends here (you can set rejected flag in db or whatever). If you accept it, you sign it and send through Tor this newly generated slatepack (you have sender’s tor address in his grin address, which is part of the slatepack that he sent you)
I finalize the transaction.
If Tor address of one party is not being used anymore then you default to outputing slatepack string and it’s user’s job to deliver it to the other party
From my understanding the difference is basically just “accept/reject” button click, so in theory you’re right, in practice people already do that every day in the stores
I’m not convinced they’re more natural. Are they more used in the crypto world? Yes, but in real world both methods are being used every day, so I don’t think people really need to learn something new.
I fail to see other UX difficulties, so in your opinion this confirmation is such a horrible UX that it’s not worth the pros you get?
I think UITX can have a check mark here, i’ve described how it’s possible to filter spam here. Maybe No wallet disk space spam issue would be easier to understand
