What is the most critical problem of Grin?

53

This is how i see RSR vs RSRS:

imagine you’re trying to make amazon use grin. Buying from amazon is just like buying from a store, so using the invoice flow makes sense, example of how it could work:

  1. user adds a new payment method (basically just states his grin address, this address includes a way to reach you - currently that’s TOR address)
  2. you fill up your basket and click “checkout” (or complete purchase or whatever phrase they’re using)
  3. you get notification on mobile of an incoming invoice, you check it (memo, amount, receiver) and click “pay”
  4. you wait for confirmations

That’s how user experience should work if they’re using TOR for example.

RSR

  1. you click “checkout”, amazon creates new transaction contract (step1 slatepack) whose memo has contents of your basket and sends it to you
  2. in your mobile app you click “pay”, this signs the contract and sends signed contract (step2 slatepack) to amazon
  3. amazon receives signed contract, signs it and broadcasts it

RSRS

  1. you click “checkout”, amazon creates an offer for transaction contract creation (i don’t know if this is how you imagine first step of RSRS to be, but i’m asuming that smth like step0 slatepack is used, so that the SRS code can be reused - correct me if i’m wrong) whose memo has contents of your basket and sends it to you
  2. in your mobile app you click “pay” but you actually don’t sign the contract since it doesn’t exist, instead you create a new transaction contract (step1 slatepack) and send it to amazon
  3. amazon verifies that the contract matches the state of when you clicked “checkout” and then signs the contract and sends it to you (step2 slatepack)
  4. your mobile app receives the slatepack, secretly signs it and broadcasts (without you knowing that - well you can show notifications etc but it seems a little weird to me)

Downsides of RSRS:

  • when you click “pay” in your mobile app you don’t actually sign anything, it’s just a “trick” because we wanted to have an easier implementation
  • the one broadcasting the transaction is the buyer, which is bad imo. Yes, there can be attacks (even when safe-cancel is implemented) if the user doesn’t understand contract/sign/sign procedure, but he will need to understand it in any case since SRS can also be attacked, just a little more work is needed. Now why is it bad if the user is the one who broadcasts in this situation? because it’s easier to make broadcasting work on the amazon side (they would understand mw, have high availability, is not moving/relying on phone battery etc) than to rely that each buyer will not lose connection before he broadcasts or to rebroadcast it if it got dropped in the dandelion phase. Also if amazon finalizes they know more about the state of the transaction (eg. it was already broadcasted) and they can easily rebroadcast it because they can automate that part
  • if one of the parties can’t use transport protocol (eg. tor) then you have 4 steps instead of 3, which is annoying. I also don’t think that a flow should be used based on where on earth the transacting parties are (eg. have physical contact or are on the opposite side of the world) but instead a flow should be used if it describes well what parties are trying to do. So if someone is saying “please pay me X for Y” then that’s an invoice flow, random sends (eg. sending some money to someone we know) or donations are payment flow

I generally like code reuse, i just don’t think the downsides outweigh the benefits in this case

3 Likes