5 Transactions

This chapter replaces the old “email to Lisa” payment flow with formal, verifiable transactions to eliminate the need to trust a single operator. Transactions are data structures that specify what coins are spent and how new coins are created, and they are stored verbatim so anyone can audit them. The system moves from an account-based model to a value-based UTXO model, which solves balance-check inefficiency, supports spending from multiple prior payments at once, and prevents Lisa from altering others’ payments because signatures commit to the entire transaction. From the user’s perspective wallets behave the same, but under the hood the lifecycle is create, confirm, and verify, with universal transparency enabling independent validation.

Transactions consist of inputs that reference unspent transaction outputs (UTXOs) by txid and index, and outputs that lock values to spending conditions. Wallets assemble enough inputs, add change outputs because outputs are spent in full, and sign each input; signatures exclude other signatures but commit to all other transaction data, and public keys are revealed on spend, making address reuse a security and privacy risk. Lisa confirms by checking existence and uniqueness of the spent outputs and by validating signatures, efficiently enforced via a maintained UTXO set that any verifier can rebuild. Script, a simple stack-based language, defines spending rules as a pubkey script (in the output) satisfied by a signature script (in the input); if each input’s combined program ends in “OK,” the transaction is valid and appended, allowing any full node to reproduce Lisa’s checks.

Beyond pay-to-public-key-hash, Script enables programmable money: multi-signature policies such as 2-of-3, pay-to-hash, and especially pay-to-script-hash (p2sh), which lets senders pay a short script hash while recipients provide the full redeeming script when spending (commonly recognized by addresses starting with 3). Transactions also carry version, locktime, and per-input sequence numbers, and the ledger’s money supply grows through special coinbase transactions that create new coins; all spending traces through a transaction graph back to such coinbases. While automation can handle Lisa’s duties, the only remaining trust is that she neither censors valid transactions nor reverts confirmed ones—issues addressed later—whereas everything else is now publicly verifiable thanks to transactions and signatures.

  . Bitcoin transactions

  Bad stuff Lisa could do. She wouldn’t, but she could.

  The payment process is the same for users, but very different for Lisa and the spreadsheet.

  John’s wallet prepares to pay 10 CT for a cookie. He uses both his keys with funds to cover the cost. He pays himself the change of 3 CT to a fresh address. The transaction is not yet signed.

  John’s wallet signs the transaction. Each input gets its own signature. The public key is also needed in the inputs because anyone should be able to verify the signature.

  Lisa verifies that John doesn’t double spend by using her UTXO set.

  Lisa verifies the first signature of John’s transaction.

  Lisa adds the transaction to the spreadsheet and removes the spent outputs from the UTXO set.

  Lisa cannot steal someone else’s money anymore. The signatures will become invalid and disclose her immoral act.

  The input reveals the public key. We made extra effort to avoid just that in chapter 3.

  The signature script is the first part of a program. The pubkey script in the spent output is the second part. If the complete program results in "OK", then the payment is authorized to spend the output.

  The first input is verified.

This chapter covers transactions. Right now we are exploring different ways to authenticate transactions.

Multisignature setup between Faiza, Ellen and John. Two of the three keys are needed to spend money.

  A program that enforces 2 signatures out of 3 possible keys. The secret sauce is OP_CHECKMULTISIG.

  Overview of pay-to-script-hash. The pubkey script is very simple. The signature script is special, because it contains a data item that contains program.

  Create a p2sh address. The difference from normal addresses is the version which is 5 for p2sh addresses instead of 0.

  Encode a versioned and checksummed script hash with base58. The result will always start with the character 3.

  Lisa rewards herself every day with a coinbase transaction.

  The transaction graph. All transactions descend from one or more coinbase transactions.

  The payment process. A wallet creates a transaction that Lisa verifies and appends to the spreadsheet.

  A transaction spending output 1 of another transactions. The program consists of a signature script followed by a pubkey script.

• Transactions have inputs and outputs, which lets you spend multiple "coins" and pay to multiple recipients in a single transaction.
• The outputs of the transactions are "programmable". The sender wallet decides what program to put in the output. This dictates what’s needed to spend the money.
• Anyone can verify the whole spreadsheet, because all signatures are public. This greatly reduces trust in Lisa.
• Scripts can be used to enable multisignature capabilities, for example 3-of-7 capabilities. Great for companies and charities.
• A new address type, p2sh address beginning with 3, is used to simplify the payment process for a lot of fancy payment types, for example multisig.
• All transactions descend from one or more coinbase transactions. Coinbase transactions are the only way in which money is created.
• Money creation is verified by any coworker, to make sure Lisa creates exactly as much as agreed. 7,200 CT per day.
• Lisa can still censor and revert transactions. We still have to trust her with that.

FAQ