Spending the Output

• Amount to send: The # of Grin Alice wants to send Bob (in this case, 25).
• TX UUID: A unique identifier Alice and Bob use to identify this transaction as they send data back and forth.
• TX fee: The transaction fee (which we will not cover in this tutorial).
• lock_height: The block number at which this transaction becomes valid.
• TX Inputs: The unspent output(s) Alice uses as inputs for her transaction to Bob.
• co: Alice’s change output.
• ks • G: Alice’s nonce ks becomes a commitment to that nonce when multiplied by generator point G.
• rs • G: The sum of all of Alice’s blinding factors rs becomes a commitment to that value when multiplied by generator point G.

Bob’s Turn

• The message of the transaction.
• The sum of the commitment to the nonces used by Alice and Bob.
• The sum of the commitment to Bob’s blinding factor (for his output of 25 Grin) and Alice’s sum of all her blinding factors.
• sr: Bob’s partial signature.
• kr • G: Bob’s commitment to his nonce.
• rr • G: Bob’s commitment to his blinding factor for the 25 Grin he expects to receive.

Last Step: Back to Alice

1. Bob knows how much Grin he will receive (25).
2. Bob knows his nonce.
3. Bob knows his blinding factor for the 25 Grin he expects to receive.
• The sum of Alice and Bob’s partial signatures.
• The sum of Alice and Bob’s commitment to their nonces (neither of them know the other’s true nonce).

Completing the Transaction

`3 dollars to cashier (output) + 2 dollars in change back to me (output) - 5 dollar bill (input) = 0`
`(34•G) + (15•H) + (11•G) + (25•H) - (20•G) - (40•H) = (25•G) + (0•H)`
`sr•G + ss•G = (kr • G) + (ks • G) + (e • (rr•G + rs•G))`
`sr•G + ss•G = (k•G) + (e • (r•G))`
`sr•G + ss•G = (k•G) + (e • (25•G))`
1. No money was created from thin air in spending Alice’s previous input.
2. Alice and Bob both knew the blinding factors for their outputs when they created this transaction. This means the new outputs are spendable by them, and not lost to the abyss.

The Transaction Kernel

• The signature of the transaction (s, k • G).
• The public key associated with the “excess blinding factor” (in this case, 25•G). As described above, this can be used to validate s.
• The transaction fee and lock_height of the transaction. (Note: if this was a Coinbase transaction, neither of these would be present).

Summary

• The inputs used.
• The new outputs.
• The transaction kernel.
• The kernel offset (which I didn’t cover here).

--

--

--

More from Brandon Arvanaghi

Building something new! Bitcoin, security, mining. Former early @Gemini.

Love podcasts or audiobooks? Learn on the go with our new app.

Brandon Arvanaghi

Building something new! Bitcoin, security, mining. Former early @Gemini.