An open discussion on Non-interactive transactions

Development and Technical Discussion
#65

That there is a shortage of Devs I get, but dwindling user community, I do not think that is the case?

Well, sure Grin was hard to use in the beginning, which might have led to some users giving up because although minimal in desing the user experience was complex. However, that is currently not the case. Basically the “problem” with interactivity is ever decreasing, especially with two mobile phone wallet implementations.

Although I agree that there is e a strong “defensive reaction” from some developers like @tromp, this reaction originates from the equally strong “pushy” attitude to claim that Grin needs to have nitx, which is accompanied with a lot of overly negative statements that Grin is unusable, difficult to use etc. etc. This is simply not the case, Grin has become way more usable in the past few years, and we live an age of continous connection (IoT, 5G etc), which means the need for interactivity is an ever decreasing problem.

I agree however with @david and @davidtavarez, that the discussion, the research into nitx should continue. If anything, this community is always searching for better, smarter, more minimal/elegant solutions. Research into nitx is part of that same quest for better and more elegant solutions which is in line with Grin’s spirit.

Regarding the RSR workflow, how would this work when withdrawing from an exchange, should I as user innitiate a transaction in my wallet and copy that online? If that is the case, I do think this is less inuitive than SRS for users and should not be pushed unless there are some major befits.
In a store, this would be different and RSR would fit since for fiat transactions it also is the store owner who innitiate a transaction, by requesting it (entering amount in the payment terminal).

#66

I would like to remind everyone that SRS and RSR are technical terms we use. The end game should not be such that users use these words. Both SRS and RSR share this:

  1. party A proposes a contract
  2. party B signs
  3. party A signs

so the flow might be the same e.g. propose, sign, sign. You can propose a contract where you receive money or where you send it The only annoying difference I see between the two is that RSR has a more annoying play attack scenario. The play scenario in RSR where the receiver doesn’t broadcast should be obvious when thinking of a transaction as a contract that you have signed. They can sign it at any point and publish it on the chain. I’m using the word “contract” just to make things obvious in this example.

#67

Actually, for a user it simply:

Withdraw

  1. Press a button to Withdraw and copy the shown slatepack (if tor fails) into the wallet
  2. Copy back the slatepack
  3. Press a buton to finish the transaction

Deposit

  1. Press a button to deposit and copy the shown slatepack (if tor fails) into the wallet
  2. Copy back the slatepack
  3. Press a buton to finish the transaction

Therefore, the difference is not important at all for the user, as long as we make the user only perform a single step (SRS for withdrawel and RSR for deposit).
So using both should not be any problem for a user, he or she will most likely not know or care which flow is making the magic work under the hood and will indeed be happy that it only involves a single action to perform. @vegycslol.

2 Likes
#68

I’m not so sure if they won’t need to know, they probably will need to. When creating a new tx they would pick either payment or invoice, so imo it would be best if they understand both flows (no magic since it’s not needed imo)

#69

I think as a fan, what Grin needs is a simple goal, at first, which is a unique private transaction, A sends to B and both of them must be online. From this simple rule, there will be many supporting facilities for transactions either on wallets, or special types of exchangers that can support them and so on, making it even more complex. Grin should be built in this way, and in addition to that Grin ambition is to replace fiat, must interact with fiat not interact with other cryptos, well unless stablecoins.

#70

The play scenario in RSR where the receiver doesn’t broadcast should be obvious when thinking of a transaction as a contract that you have signed.

I think this can largely mitigated either by using a (multiparty?) timelock to the transaction, where the sender is able to reclaim funds after a certain number of blocks (10?). Will write something up on @tromp’s PR to see what they think.

#71

I’m not sure I understand correctly what you mean. The case I mentioned is prior to the tx landing on the chain, which means that the sender can always just spend the input they provided in a new transaction which invalidates the one the receiver did not broadcast - this is the solution in safe-cancel RFC.
If you mean solving this by making 2 transactions instead of just 1, then I believe this may have 2 possible problems:

  1. Uses 2 kernels which doubles the size of the chain
  2. Payment proofs might be an issue
#72

No, you’re right, I was thinking of a situation where the tx was already on-chain.

The safe-cancel RFC would also require the user to:

  1. monitor the chain to ensure the tx posted
  2. use some kind of watchtower to watch the chain for them, automatically notifying the wallet the next time it is online to do a self-spend

I still think I agree with those in this thread that suggest having one standardized tx flow (SRS), and making exchanges/pools build on that.

For example, the exchange could put a form for “please create a transaction for X Grin, and post here”. The exchange’s wallet does its part of the tx, and instructs the user “please import the tx to your wallet, verify everything is correct, and finalize”.

The above flow would work for exchanges / pools / stores that do not want to implement TOR sending for whatever reason.

For those implementing TOR sends, the flow is even simpler “please send X GRN to this Slatepack address.”

#73

Just reposting what i’ve posted on keybase some time ago, so that it doesn’t get lost.

let’s say amazon integrates grin. You have a cart with items in it and then click “checkout”. Now you have 2 different flows:
SRS:

  1. user copies the total amount of his cart and also copies amazon’s grin address to create step1 slatepack
  2. user enters the generated slatepack on the amazon page, amazon generates next slatepack
  3. user copies this new slatepack and finalizes the transaction
    Here amazon doesn’t know if the user has signed the tx or if the transaction didn’t reach the chain etc.
    User had to copy the amount, amazon’s grin address, create the first slatepack, copy next slatepack and finalize.

RSR:

  1. user enters his grin address (so that exchange can encrypt for him), amazon generates the new slatepack which the user copies
  2. user generates the next slatepack through the “pay” subcommand
  3. user pastes slatepack on the amazon page
    Here amazon knows exactly the state of the transaction.
    User had to paste his grin address, copy slatepack, pay to create the second slatepack and paste it

From my understand of early payment proofs, memo would need to be created in the first step of SRS (well at least that makes sense to me although it might be possible to push it to step 3 but it makes less sense), which means the user would also need to take care of the memo, instead of letting amazon automate this process - amazon has the digital cart data, so it can either populate the memo with it or generate hash of it and send you the receipt or smth. I might be wrong, but i don’t see real services being happy with the SRS flow integration

2 Likes
Let's create the ultimate Grin Wallet experience! (Grin++ UX/UI)
#74

Here’s how bitcoin developers advertize the advantages of interactive (payjoin) transactions:

2 Likes
#75

Interactivity in building payments, what a brilliant idea. How come this sounds somewhat familiar :wink:
Having the input’s and output’s amount blinded makes life much easier for Grin. Only need to adopt the part where both parties contribute inputs and the total amount of outputs equals the number of inputs to obfuscate direction to have our own privacy enhancing, blockchain bloat avoiding special payjoin.

#76

next they will say they fixed the ‘‘sending btc to wrong adress problem’’ :laughing:

#77

let’s say amazon integrates grin. You have a cart with items in it and then click “checkout”. Now you have 2 different flows:
…
From my understand of early payment proofs, memo would need to be created in the first step of SRS (well at least that makes sense to me although it might be possible to push it to step 3 but it makes less sense), which means the user would also need to take care of the memo, instead of letting amazon automate this process - amazon has the digital cart data, so it can either populate the memo with it or generate hash of it and send you the receipt or smth.

Fair enough. I’m still wrapping my head around how a receiver could block payment in the second round of SRS. At that point the receiver doesn’t have a fully signed tx, do they? How does spamming an unsigned output block anything? Anyway, still reading through the papers and code to figure this out.

To me the two flows are about shifting responsibility for tx finality from one party to another. RSR flow is like handing a signed check over to Amazon, saying “I hope you cash this.” Then having to constantly monitor your bank account until the check clears. If users already struggle getting used to SRS flow, RSR seems much more complex when things go wrong.

On the other hand, when things go right, I agree that RSR is a simpler flow for the sender, and potentially the receiver. Like I said, I still have more research to do.

#78

Thanks for looking into it. Here’s an example of how you could block it. Suppose the sender and the receiver create a transaction T through SRS. Receiver in step 2 added his output O1 so T contains O1. Receiver creates a new self-spend transaction T' which also creates O1. If they are able to push T' to the mempool/chain before T gets there, then T is invalid because it would create the same output O1. Consensus rules say that UTXO set can’t have the same output twice in it.

1 Like
#79

And this is why custodial wallets currently offer the best user experience on Bitcoin Lightning Network. Obviously that’s not great for a decentralized currency. Admittedly always online wallets are a bigger issue for Lightning because of the whole channel closing fee.

In general the comparisons of MW and Lightning are quite apt, as others here have pointed out already, they struggle with very similar UX issues. But as far as I’m aware those hurdles haven’t been overcome on the Lightning side either and I’d imagine they have a lot more People working on it.

2 Likes
#80

After having some discussions today on discord, I decided to write things up in a document in case anyone wants to read what I was trying to explain. Here’s one of the big tradeoffs that the current NITX proposals make (both David’s and Gary’s).

Trustless node sync. While it’s true that Mimblewimble has a weaker model than Bitcoin, it preserves these two properties. Proof of authentication is preserved because there cannot exist any state transition in the past for which a party that owns any input/output of the state transition did not inject their blinding factor into the kernel. Replay attacks are bad and should be addressed, but they don’t break this property as the owner signed the transition for the original transaction prior to replay.

A good explanation of this problem is also in the Introduction section of MingleJingle which addresses this problem but introduces many more tradeoffs.

1 Like
The (non-)existing problem with interactive transactions & UX - Rant
#81

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?

#82

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
#83

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?!

#84

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