6 The blockchain
This chapter replaces the fragile “shared spreadsheet” with a blockchain to harden transaction history against undetectable edits. Transactions are grouped into blocks, and each block header commits to two things: the previous block’s header hash (chaining history) and the block’s transactions via a merkle root, along with a timestamp and, in the narrative system, Lisa’s block signature. Because every new block signs the one before it, changing any past transaction would force changes to that block and all successors, yielding conflicting, signed histories that expose fraud. Compared with periodically signing an ever-growing transaction list, block-by-block commitments scale better for creators and verifiers and clearly delimit “what’s new” for updating the UTXO set. (In real Bitcoin, digital signatures on blocks are replaced by proof-of-work, introduced later.)
To serve users who can’t or won’t download everything, the chapter introduces lightweight (SPV) wallets alongside full nodes. Full nodes keep the entire blockchain and validate scripts, signatures, and UTXO state. SPV wallets, in contrast, fetch only block headers and a subset of transactions from full nodes, using bloom filters to request “possibly relevant” data without revealing their exact addresses. Inclusion is verified with merkle proofs: the full node sends the block header plus a compact partial merkle tree that lets the wallet recompute the merkle root and prove that a transaction is in the block. These proofs grow only logarithmically with block size, saving bandwidth while preserving inclusion verifiability.
SPV comes with trade-offs. While it can verify that a transaction appears in a properly signed block, it cannot by itself validate scripts, detect double-spends against the full UTXO set, ensure it received every relevant transaction, or guarantee that the serving node follows the expected consensus rules. Users can mitigate risk by connecting to multiple independent full nodes or to a self-run trusted node. The chapter also highlights privacy and performance limits of bloom filters (false positives, potential deanonymization, heavy server-side scanning) and notes newer filter approaches designed to improve privacy and efficiency. Overall, the blockchain structure secures integrity against deletion or alteration, while SPV techniques reduce bandwidth at the cost of additional trust and some privacy leakage.
The Bitcoin blockchain
Lisa buys a cookie and then reverts the transaction. She just stole a cookie from the cafe. The cafe and Lisa now have different spreadsheets.
A blockchain is a chain of blocks. The blocks contain transactions and each block references its predecessor.
Each block header protects the integrity of the contained transactions and the blockchain before the block.
Lisa creates a new block. It’s called a block template because it’s not yet signed.
Lisa signs a block with her block signing private key. The public key is well known among the coworkers.
Lisa has signed her new block and saves it into a new file in the shared folder.
Transactions must be ordered in "spending" order, otherwise there are no restrictions
Invalid block because a transaction spends an output that "doesn’t yet exist"
Lisa creates a block containing her payment for a cookie.
Lisa needs to create alternative versions of the block containing her transaction and all subsequent blocks.
Each block signs all transactions ever made thanks to the previous block id field of the headers.
Information exchange between a lightweight wallet and a full node. The full node sends all block headers and a fraction of the transactions to the wallet.
The lightweight wallet creates a bloom filter to send to the full node. Each address in the wallet is added to the bloom filter.
The block to send contains three transactions of which only one actually concerns John.
The full node uses the information in each transaction to determine if the transaction is "interesting" to the wallet.
The full node feeds the lightweight wallet with the block header and potentially relevant transactions
Lisa creates a merkle root from the transactions in a block.
A change in the transactions will cause a change in the merkle root, making the signature invalid.
The lightweight wallet verifies that Tx2 is in the block by reconstructing the merkle root.
The full node constructs a partial merkle tree that connects Tx2 to the merkle root in the block header.
The wallet verifies the partial merkle tree
The wallet checks that the merkle roots match and that Tx2 is included in the list of hashes. If so, Tx2 is proven to belong to the block.
Constructing a partial merkle tree from 12 transactions and two interesting transactions.
John’s wallet is connected to multiple full nodes. Hopefully they don’t all collude to fool John.
John has setup a trusted node that his lightweight wallet connects to.
The blockchain connects the blocks by the previous block id value in the block headers. The merkle root commits to the transactions in the block.
Recap
In this chapter you learned that
- Transactions are placed in blocks that are signed by Lisa to hold her accountable if she tries to delete transactions.
- Each block signature commits to the transactions in that block and all previous blocks so that history can’t be tampered with without re-signing the fraudulent block and all subsequent blocks.
- The transactions in a block are collectively hashed in a merkle tree structure to create a merkle root that is written in the block header. This makes it possible to create a lightweight wallet.
- Lightweight wallets are used to save bandwidth, but at the cost of reduced security.
- Lightweight wallet security is reduced because they cannot fully verify a transaction and because a full node can hide transactions from the wallet.
- The only way to be absolutely sure that the block rules are followed is to run your own full node.
- The security of a lightweight wallet can be improved by connecting to multiple full nodes or a trusted node.
- Lisa can still censor transactions.
FAQ
Why switch from a shared spreadsheet to a blockchain?
The spreadsheet let Lisa delete or replace past transactions without anyone being able to prove it. The blockchain chains blocks with cryptographic hashes and a block signature so that any change to a past block invalidates that block and all that follow. If Lisa tries to alter history, verifiers can detect it and even prove fraud by showing conflicting signed blocks.
What is inside a block header and what is a block ID?
Each block header contains: (1) the double-SHA256 hash of the previous block header, (2) the merkle root (combined hash of all transactions in the block), (3) a roughly accurate timestamp, and (4) Lisa’s digital signature over the header. The block ID is the hash of the block header. Note: in Bitcoin, blocks are not signed by a person; proof-of-work replaces Lisa’s signature.
How does chaining blocks protect against tampering or deletion?
The previous-block hash in every header links blocks into a chain. Changing any transaction changes the merkle root, which changes the header, invalidating the signature and the block ID. That in turn breaks every subsequent block. To rewrite history, Lisa would need to re-create and re-sign the altered block and all following ones. If two different signed versions appear at the same height, verifiers can prove Lisa cheated.
What is a merkle tree and merkle root, and why are they used?
A merkle tree combines the hashes of all transactions in a block into a single 32-byte value called the merkle root. Transactions are double-SHA256 hashed, then concatenated and hashed pairwise up the tree; if the number of leaves is odd, the last item is duplicated for hashing. The merkle root commits to the exact set and order of transactions: change any transaction and the merkle root changes.
What is a merkle proof and how does it prove a transaction is in a block?
A merkle proof is a partial merkle tree plus the block header. It contains just enough sibling hashes and flags to let a lightweight wallet recompute the path from a given transaction hash to the merkle root in the header. If the recomputed root matches the header’s merkle root and the target txid is present in the proof, the wallet knows that transaction is included in that block without downloading the whole block.
How does Lisa build and publish a block?
Every ~10 minutes, Lisa: (1) creates a block template by choosing valid unconfirmed transactions (ordered so inputs appear before spends), computes the merkle root, and sets the time; (2) signs the header with her private key; (3) publishes the block as a new file in the shared folder, which others can read but not alter. In Bitcoin, a peer-to-peer network replaces this shared folder.
What is a coinbase transaction and how are new cookie tokens created?
The first transaction in each block is the coinbase transaction. It creates new money as a block reward: in the cookie token system, 50 CT per block (7200 CT/day spread over ~144 blocks). In Bitcoin terms, this newly created portion is the block subsidy; fees are discussed later. The coinbase is how new units enter the system.
What is a lightweight (SPV) wallet and how does it save bandwidth?
A lightweight wallet does not download or validate full blocks and the entire UTXO set. Instead, it connects to full nodes, downloads only block headers and transactions that might involve its addresses, and relies on merkle proofs to confirm inclusion. To avoid revealing its exact addresses, it sends a bloom filter so the node forwards matching and some unrelated transactions (false positives) to obfuscate interest.
What are bloom filters, and what are their privacy/performance trade-offs?
Bloom filters let a wallet specify “possibly interesting” items (addresses, txids, script data) without listing them explicitly. They deliberately allow false positives to improve privacy, at the cost of extra unrelated transactions sent to the wallet. However, collected filters can still leak wallet clusters, and initial scanning can burden full nodes (DoS risk). Proposals BIP157/158 invert the model by having nodes send per-block filters that clients match locally.
What can’t an SPV wallet verify, and how can users mitigate the risks?
SPV wallets verify headers and inclusion proofs, but not full transaction validity or consensus rules: they can’t fully check scripts/signatures, double-spend status, or whether a node is enforcing the right rules. They must trust the connected full nodes to be honest and complete. Mitigations include connecting to multiple independent full nodes and/or using a trusted full node you run yourself.
Grokking Bitcoin ebook for free
