Study Notes: Chapter 6 – The Blockchain

1. Why a Blockchain Instead of a Spreadsheet?

Q1: What limitation did the old spreadsheet-based system still have?

Lisa could silently delete or revert transactions without verifiers being able to prove it. Although users could confirm the validity of transactions, they couldn't prove Lisa hadn't removed any after the fact.

Figure 1. The blockchain replaces the old spreadsheet and deters tampering.

Q2: How does a blockchain help if Lisa tries to remove or replace transactions?

Each block references the previous block’s ID (hash) and signs a "merkle root" of its transactions, so tampering would invalidate signatures in that block and all subsequent blocks. This makes fraud cryptographically provable.

2. Building the Blockchain

Q3: What is a "block" in the blockchain?

A block is a file containing:

• Block header: - The previous block's hash, - The merkle root of current transactions, - A timestamp, - A block signature (or proof of work in Bitcoin).
• Transactions included in this block.

Figure 4. Each block references the previous block, forming a chain.

Q4: How does the block header "commit" to all transactions in the block?

Through the merkle root, which is a single hash derived from recursively hashing all transactions in a merkle tree. Changing any transaction changes the merkle root, invalidating the block.

3. Lisa's Role in Creating Blocks

Q5: What are the steps Lisa takes to create (confirm) a new block?

1. Create a block template: gather unconfirmed transactions, form the merkle root, reference the previous block’s ID, and set a timestamp.
2. Sign the block header: using her private key (or proof of work in Bitcoin).
3. Publish the block file: add it to the shared folder (or broadcast over the network).

Figure 6. Lisa signing a block header.

Q6: How does this signature help prevent Lisa from removing transactions later?

If she changes or removes any transaction in a past block, she must alter the block header and re-sign it, creating a new version of that block. Now there are two signed versions of the same height, proving fraud.

4. Lightweight Wallets (SPV)

Q7: Why do some wallets prefer not to download the full blockchain?

For bandwidth and storage reasons. Mobile or low-capacity devices often use "lightweight" or SPV (Simplified Payment Verification) wallets that trust a full node to filter and provide relevant transaction data.

Figure 15. Lightweight wallets connect to a full node (or multiple nodes) for relevant data.

Q8: How do lightweight wallets verify that a transaction is in a block without downloading the full block?

They use a merkle proof. The full node sends:

• The block header (with merkle root)
• A partial merkle tree
• The actual transactions in question

5. Bloom Filters & SPV Privacy

Q9: How do bloom filters help preserve privacy while fetching relevant transactions?

A bloom filter is a bit array that matches multiple addresses with some probability. The wallet sends this filter to the full node, which checks if various parts of each transaction match the filter. Because it can produce false positives, the node can’t tell exactly which addresses the wallet is interested in.

Figure 17. Creating a bloom filter for multiple addresses.

Q10: What are the downsides of bloom filters?

• Privacy leaks: With enough queries or analysis, the node can often deduce which addresses belong together.
• Load on full nodes: They must scan large sections of the blockchain, potentially causing DoS vulnerabilities.

6. Merkle Trees & Verifying Transaction Inclusion

Q11: What is a merkle tree in this context?

A binary tree of hash pairs that merges all transaction hashes into a single "merkle root". Each transaction is hashed, then concatenated pairwise, hashed again, and so on until only one hash remains.

Figure 23. Constructing the merkle root from four transactions.

Q12: Why not just hash all transactions in one big concatenation?

A tree structure allows selective proofs (partial merkle proofs) for only a subset of transactions, without revealing or sending the entire block of transactions. This saves a lot of data.

7. Are We Fully Trustless Now?

Q13: Can Lisa still cheat in any way despite the blockchain preventing removal or alteration?

She can still censor transactions by refusing to include them in blocks. She also controls which transactions appear at all. Additionally, she can revert old transactions by building alternative blocks (though that reveals her fraud if the blocks are already distributed).

Figure 13. Changing old blocks requires rebuilding and re-signing all subsequent blocks.

Q14: What’s next for removing Lisa’s power to censor and controlling who builds blocks?

We introduce miners and proof of work in Chapter 7, distributing the block-building process among many nodes so no single party can decide unilaterally which transactions to include.

8. Key Takeaways / Summary

• Blockchain Replaces Spreadsheet: Blocks are chained via hashes; tampering one block invalidates all subsequent blocks.
• Merkle Trees: Efficiently commits to all transactions while allowing lightweight proofs for partial sets of transactions.
• Lightweight Wallets (SPV): Save bandwidth by only downloading block headers + merkle proofs. They trust full nodes for full transaction validation.
• Bloom Filters: Provide an obfuscated way to request relevant transactions, at the expense of partial privacy leaks and heavier node load.
• Remaining Trust in Lisa: She can’t delete transactions but can still censor them. Proof of work (next chapter) removes single-authority control.
• Security vs. Convenience: Running your own full node is the only guaranteed way to verify the rules you want; SPV wallets must trust one or more nodes.

End of Study Notes for Chapter 6. We’ve replaced the spreadsheet with a blockchain, ensuring public verifiability of the transaction history and paving the way for decentralized consensus in the upcoming chapters!