An open discussion on Non-interactive transactions

Development and Technical Discussion
#63

True, but what I would like to see is a commitment of taking at least one potential solution and invest effort on making it secure, and feasible.

The kind of support we give on the Grin++ Telegram Support Group. When a question turns to be repeatable I tend to write and publish something to then point the users to that write-up. Some users record videos to help other users. And to be fair, after implementing the Slatepack RFC, support questions have been reduced, but before that, it was a painful headache; now what we see is Pools and the few exchanges implementing different solutions. We even haven’t improved the current situation, but now we want to push another flow, why? because is better? sure, it might be, but the same argument that is being use to keep exploring and experimenting the current MW implementation in order to discover its full potential, which is reasonable enough, can be used to keep exploring and improving the SRS flow, but again, what do we get? a big: “let’s push the RSR flow because without using tor even if we spent hours and hours, maybe years, trying to educate users on using tor with grin, and even without payment proof… let’s switch and explore that”… for me, and without any intention of attacking anyone, it doesn’t makes sense, it is confusing and it will confuse users.

If we keep hurting users, we won’t have any users, we won’t have miners, pools, or even exchanges and this yellow experiment that we all do love and care about will vanish.

#64

RSR is not better than SRS, they complement each other. The way i see it is that SRS is mostly better when sending from userA to userB (in this case one person needs to do 2 steps and SRS seems like a good choice here). When a service wants to integrate grin then (to receive payment) then RSR seems better since the user only needs to do one step. I’m totally for advancing the SRS (not sure what exactly you mean by that, but since in my view grin needs SRS I applaud such things). Tor is a separate thing, whether exchanges should support it or not is not clear to me. Do you really think it’s hard for the users to understand invoices? I think people just need a quality material to learn from. You’re not attacking anyone (your behaviour is exemplary), we’re just all passionate about this project and are discussing things. Sorry if some of my answers seem like attacks, they’re not meant as such :slight_smile:

#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