Checking my understanding of transaction flow

Tech Support
#1

To my understanding, a grin transaction happens in three steps:

  1. Sender → Receiver
  2. Receiver → Sender
  3. Sender → Chain

Also to my understanding, if Step 3 is lost and never gets to the chain, the transaction never happened, and so to cancel the transaction, “recover” the grin, and invalidate Steps 1 & 2, the Sender needs to re-send the same Step 1 message, but to a different receiver. Once that re-sent transaction is confirmed, if the old Step 3 data then reappears and tries to get confirmed, it will fail.

Is this correct? Am I using any terms incorrectly? Thanks!

2 Likes
#2

The “resend same message” actually means spending an input that was also in that slatepack message. If you spend that input, then this will invalidate the previous transaction because the input will no longer exist. There’s an open RFC that we need ro challenge which addresses this self-spending called Safe-cancel. There is another flow which is supported by grin-wallet called “invoice”. The difference is that the process gets started by the receiver:

  1. The receiver enters the senders grin address and amount and sends the step1 slatepack msg to the sender
  2. The sender signs this and sends the next slatepack message to the receiver
  3. The receiver finalizes and broadcasts

We call the flow where the sender starts SRS/regular (sender-receiver-sender) and the flow where the receiver starts RSR/invoice.
In RSR the sender MUST manually input the value in step2 to confirm how much they are sending.

The same “sender signed tx did not land on the chain” can happen in the RSR flow. In this case, the sender again needs to spend the input to invalidate that transaction from ever getting on the chain.

2 Likes
#3

Thank you! Further questions:

  1. I’m guessing a “wallet” consists of an arbitrary set of unspent inputs and associated keys. Are there other fundamental components?

  2. Are these inputs and keys connected in any way beyond where they happen to be stored?

  3. Where is this “address” idea coming from?

  4. Safe-cancel is a grin-wallet feature, not an additional protocol-level feature, correct?

#4

I’ll try to answer some of these.

  1. An output in Grin is a Pedersen commitment. This commitment has a form v*H + r*G where v is the amount and r is the blinding factor. However r is also the spending secret of that output, so I believe this may be the associated key you’re refering to (the amount and owner secret are merged into a single public key).
  2. I’m not sure.
  3. Addresses come from this standard Slatepack . It is a bech32 encoded ed25519 public key. This is used to encrypt slates and to derive the Tor address of the other party if they choose to exchange slatepacks via Tor.
  4. Yes, but I believe that since it is crucial to avoid some type of attacks (we call them play attacks), it is made through an RFC.
1 Like
#5

Receiver also sends Rr (his public nonce) and Xr (his public excess), so that the sender can compute the schnorr challenge and sign the transaction