Study Notes: Chapter 5 – Transactions

1. Overview & Motivations

Q1: Why did the system need to replace the old “email to Lisa” approach with transactions?

Because in the old approach, only Lisa saw the email requests, giving her the power to modify entries and potentially steal. Transactions store signatures and payment details publicly, so everyone can verify they haven’t been altered, reducing trust required in Lisa.

Figure 1. Bitcoin/cookie token transactions provide a standardized and verifiable way of paying.

Q2: What key problems do transactions solve?

• They let the system handle multiple coins and recipients in a single payment (more efficient than multiple spreadsheet rows).
• All signatures become public, so anyone can audit the ledger and detect tampering.
• They enable flexible “programmable money” with scripts, accommodating multi-signature or other advanced features.

2. What Is a Transaction?

Q3: How does a transaction replace the old “From, To, CT” approach?

A transaction includes inputs (referencing specific previously unspent outputs) and outputs (new “coins” created by the transaction). Each output specifies a script that must be satisfied to spend it. This formalizes and records the payment, and can’t be changed without invalidating the signatures.

Figure 4. Example transaction with two inputs (two UTXOs) and two outputs (the actual payment + change).

Q4: Why do we often have a “change output”?

Because outputs in Bitcoin-like systems must be spent entirely. If you only need 8 out of a 10 “coin” output, you’ll consume the whole 10 in your transaction and create one output for 8 (the payment) plus one for 2 (change) going back to you.

Q5: Where does Lisa store these new transactions?

In the shared ledger (the “spreadsheet”). Each confirmed transaction is appended exactly as created by the sender, ensuring full transparency and auditability.

3. Creating and Confirming Transactions

Q6: How is a transaction created and confirmed?

1. Create – The wallet gathers inputs (previous unspent outputs), calculates total value, adds outputs (payment + change), then signs each input with the relevant private key.
2. Confirm – Lisa (or a node) checks references to ensure they exist and aren’t already spent, verifies signatures, and if valid, appends the transaction to the ledger.
3. Verify – Anyone can re-check the transaction in the ledger for correctness, ensuring Lisa hasn’t tampered with it.

Figure 6. Lisa uses a UTXO set to detect double spends and quickly confirm or reject transactions.

Q7: What is the UTXO set, and why is it useful?

The UTXO (Unspent Transaction Output) set is a list of all currently spendable outputs. It allows quick checks to confirm that a transaction’s inputs are valid and unspent, avoiding full balance calculations for each PKH.

4. The Script Language

Q8: Why is there a programmable aspect in each transaction output?

Each output holds a small script (the pubkey script) dictating how it can be spent. The input that spends it provides the matching script data (the signature script). If the combined script checks out (returns OK), the spending is authorized.

Figure 10. The spending input must provide the correct public key and signature to match the PKH in the output script.

Q9: How do multi-signature transactions work?

Instead of “pay-to-public-key-hash,” you can use OP_CHECKMULTISIG and require M-of-N signatures from multiple participants, which is great for shared accounts or more secure storage.

Figure 19. Example 2-of-3 multi-sig script

Q10: What if the recipient’s script is large, but the sender doesn’t want to pay the higher fee for a bigger output script?

They can use pay-to-script-hash (p2sh), which hides the actual script behind a script hash. The sender only sees and pays to the short hash, while the detailed script is provided (and paid for in bytes) by whoever later spends it.

Figure 22. p2sh: The spender ultimately reveals the full redeem script.

Q11: How can we identify a p2sh address?

p2sh addresses (base58check with version byte 0x05) typically start with 3 (e.g., 3ABC...), distinguishing them from p2pkh addresses (which start with 1).

5. Coinbase & Money Creation

Q12: If all money is tracked in unspent outputs, how does new money enter the system?

Through a special coinbase transaction, which has a special input (“coinbase”) and no previous txid. This transaction can create new funds for Lisa (or miners in Bitcoin) as a reward for maintaining the ledger.

Figure 28. Lisa awarding herself daily cookie tokens via a coinbase transaction.

6. What Trust Remains in Lisa?

Q13: Can Lisa still cheat if all transactions are publicly verified?

She can’t forge or alter individual transactions without invalidating signatures. However, she can still:

• Refuse to confirm (censor) certain transactions
• Potentially remove (“revert”) past transactions from the ledger

7. Key Takeaways

• Transactions replace the old single row of “From, To, CT.” They have inputs (which UTXOs are being spent) and outputs (who receives how much).
• Everyone can verify transactions because they include all necessary signatures and scripts. This drastically reduces trust in Lisa—she can’t secretly alter payments.
• UTXO set: Lisa (and any full verifier) maintains a list of unspent outputs for fast checks of double spending.
• Script: A flexible, minimal programming language for specifying spending conditions. Basic form is p2pkh, but more advanced forms include multisig (OP_CHECKMULTISIG) or p2sh (pay-to-script-hash).
• New addresses: p2sh addresses start with 3, hiding the script until spending time.
• Coinbase transactions are how new money enters the system (replacing the old daily “row for Lisa”).
• Lisa can’t forge or alter transactions, but she can still censor or revert them, which future chapters address with the concept of a blockchain and distributed consensus.

End of Study Notes for Chapter 5. We’ve seen how transactions provide publicly verifiable payments, forming the basis for the trustless Bitcoin system once the blockchain is introduced!