Chapter 8 Quiz: Bitcoin Network: Nodes, Propagation, and the Peer-to-Peer Architecture

Multiple Choice

Q1. Which type of Bitcoin node validates every transaction and every block against the complete consensus rules?

A) SPV node B) Light node C) Full node D) Mining node only

Answer: C) Full node. Full nodes (including mining nodes, which are full nodes with added mining capabilities) independently validate every transaction and block. SPV/light nodes only verify block headers and Merkle proofs.

Q2. A pruned Bitcoin node differs from a full archival node in that it:

A) Does not validate historical blocks during initial sync B) Validates all blocks but discards old block data after validation C) Only stores block headers, not full blocks D) Cannot relay new transactions or blocks to peers

Answer: B) Validates all blocks but discards old block data after validation. Pruned nodes perform the exact same validation as archival nodes during IBD — they check every transaction in every historical block. After validation, they discard the raw block data they no longer need, retaining only the UTXO set and recent blocks.

Q3. Bitcoin's gossip protocol works by:

A) Sending every transaction directly to every other node in the network B) Broadcasting transactions to a central relay server that distributes them C) Having nodes announce transaction hashes to peers, who request full transactions if needed D) Using a distributed hash table (DHT) to store and retrieve transactions

Answer: C) Having nodes announce transaction hashes to peers, who request full transactions if needed. Nodes send inv (inventory) messages containing transaction hashes. Peers that don't already have the transaction respond with getdata to request the full transaction.

Q4. Which of the following is NOT a mechanism Bitcoin Core uses for initial peer discovery?

A) DNS seeds operated by community members B) A central peer directory maintained by the Bitcoin Foundation C) Hardcoded IP addresses of stable nodes D) Address messages (addr) from already-connected peers

Answer: B) A central peer directory maintained by the Bitcoin Foundation. Bitcoin has no central peer directory. It uses DNS seeds (A), hardcoded seed addresses as a fallback (C), and addr messages from connected peers (D).

Q5. The fee rate for Bitcoin transactions is measured in:

A) BTC per transaction B) Satoshis per byte (sat/B) C) Satoshis per virtual byte (sat/vB) D) USD per kilobyte

Answer: C) Satoshis per virtual byte (sat/vB). Since the adoption of SegWit, the relevant metric is satoshis per virtual byte, which accounts for SegWit's witness data discount. The older "sat/B" metric does not properly account for SegWit.

Q6. Replace-By-Fee (RBF) allows:

A) A miner to replace a transaction in a block that has already been confirmed B) A sender to replace an unconfirmed transaction with a new version paying a higher fee C) A recipient to reject a transaction and return the funds to the sender D) A node to override another node's mempool policy

Answer: B) A sender to replace an unconfirmed transaction with a new version paying a higher fee. RBF (BIP 125) enables fee bumping by replacing unconfirmed transactions. It requires spending at least one of the same inputs and paying a higher fee rate.

Q7. Compact block relay (BIP 152) improves block propagation by:

A) Compressing block data using standard compression algorithms B) Sending only transaction IDs instead of full transactions, leveraging the receiver's mempool C) Sending blocks only to the 3 closest peers D) Reducing the maximum block size

Answer: B) Sending only transaction IDs instead of full transactions, leveraging the receiver's mempool. Since most transactions in a new block are already in the receiver's mempool, compact blocks send short transaction IDs that the receiver matches against their mempool to reconstruct the full block, reducing data by 90-99%.

Q8. An SPV client verifies transaction inclusion using:

A) Downloading and checking the full block containing the transaction B) Requesting a Merkle proof from a full node and checking it against the block header's Merkle root C) Trusting the full node's assertion that the transaction is valid D) Checking the transaction against a local copy of the UTXO set

Answer: B) Requesting a Merkle proof from a full node and checking it against the block header's Merkle root. SPV clients download block headers (80 bytes each), then verify transaction inclusion by requesting Merkle proofs — the sibling hashes along the path from the transaction to the Merkle root.

Q9. An Eclipse attack on a Bitcoin node involves:

A) Exploiting a software vulnerability to crash the node B) Monopolizing all of the target node's peer connections with attacker-controlled nodes C) Overwhelming the node with invalid transactions to fill its mempool D) Cutting the node's internet connection entirely

Answer: B) Monopolizing all of the target node's peer connections with attacker-controlled nodes. If an attacker controls every peer a node connects to, they can filter which transactions and blocks the node sees, potentially enabling double-spend attacks or transaction censorship against that specific node.

Q10. If a mining pool controlling 30% of hash power refuses to include transactions from a specific address, those transactions:

A) Can never be confirmed on the Bitcoin blockchain B) Will be confirmed approximately 30% slower, as the remaining 70% of miners still process them C) Will be automatically rerouted to a different blockchain D) Will cause the mining pool to be removed from the network

Answer: B) Will be confirmed approximately 30% slower, as the remaining 70% of miners still process them. Below the 51% threshold, miner censorship is merely a delay — other miners will include the censored transactions. Permanent exclusion would require controlling more than 50% of hash power and actively orphaning blocks from non-compliant miners.

Short Answer

Q11. Explain why the statement "miners control Bitcoin" is misleading. What is the actual relationship between miners and full nodes in Bitcoin's security model?

Answer: Miners propose blocks, but full nodes determine whether those blocks are valid. Every full node independently validates blocks against the complete set of consensus rules. If miners produce a block that violates any rule (e.g., creating more coins than allowed, including an invalid transaction), full nodes reject it regardless of how much proof of work was expended. Miners control which valid transactions to include and the order of inclusion, but they cannot change the rules (block reward, supply cap, script validation rules) without the consent of the full nodes that validate their work. The power relationship is better described as: miners propose, nodes dispose.

Q12. What is the difference between a stale block and the impact on the transactions it contains? Why do stale blocks occur, and how has their rate changed over time?

Answer: A stale block is a valid block that loses a chain-tip race when two miners find blocks at approximately the same time. The network resolves the fork by following the chain with the most cumulative proof of work, and the block on the losing side becomes stale. Transactions in a stale block are not lost — they return to the mempool and can be included in a future block. However, the miner who produced the stale block loses the block reward (subsidy + fees). Stale blocks occur because of non-zero block propagation time — the window between when one miner finds a block and when other miners learn about it. The stale rate has decreased over time (from several percent in Bitcoin's early years to roughly 0.1-0.5% today) due to improvements like compact block relay (BIP 152) and better network infrastructure.

Q13. Describe the Child-Pays-For-Parent (CPFP) fee bumping mechanism. In what scenario is CPFP preferable to RBF?

Answer: CPFP works by creating a new "child" transaction that spends an output of the stuck "parent" transaction and attaches a high enough fee to make the combined (parent + child) ancestor fee rate attractive to miners. Miners must include the parent to collect the child's fee, so both transactions get mined together. CPFP is preferable to RBF when the sender did not opt into RBF (so the original transaction cannot be replaced), or when the recipient wants to accelerate a payment without requiring the sender's cooperation. This is common for exchanges accelerating incoming deposits — the exchange creates a child transaction spending the deposit output with a high fee, pulling the stuck parent transaction into a block.

Q14. Compare the privacy properties of BIP 37 bloom filters and BIP 157/158 compact block filters for SPV clients. Why was the newer approach developed?

Answer: BIP 37 bloom filters have the client send a filter to the full node server, asking the server to only send transactions matching the filter. Research showed that a malicious server can deduce exactly which addresses the client cares about by analyzing the filter's false positive rates and parameters, providing far less privacy than intended. BIP 157/158 compact block filters invert the model: the server constructs a deterministic filter for each block summarizing which addresses/scripts are affected, and the client downloads the same filter everyone else does. The client checks locally whether any of their addresses match without revealing their addresses to the server. When a match is found, the client downloads the full block. This is a fundamental privacy improvement because the server never learns which specific addresses the client is interested in.

Q15. A user is running Bitcoin Core for the first time. Explain the Initial Block Download (IBD) process. What is the node doing during this time, and why does it take so long?

Answer: During IBD, the new node downloads every block ever produced in Bitcoin's history (from the genesis block in 2009 to the current tip) from its peers and validates each one fully. For each block, the node verifies the proof-of-work, validates every transaction (checking signatures, confirming no double-spends, verifying amounts), and updates its UTXO set. The process takes 6-12 hours on modern hardware because the node is downloading approximately 570 GB of data and performing millions of cryptographic verifications. The CPU bottleneck is signature verification (particularly for older blocks with complex scripts), and the I/O bottleneck is writing the blockchain database and UTXO set to disk. Once IBD is complete, the node only needs to validate new blocks as they arrive (one every ~10 minutes), which is trivial by comparison.

True/False

Q16. Every Bitcoin node's mempool contains exactly the same set of transactions at any given time.

Answer: FALSE. Each node maintains its own local mempool, and mempools can differ due to propagation delays, different relay policies, different minimum fee thresholds, different maximum mempool sizes, and the order in which nodes receive transactions. There is no single canonical "mempool."

Q17. A pruned Bitcoin node cannot relay new blocks and transactions to peers.

Answer: FALSE. Pruned nodes can relay new transactions and new blocks just as effectively as archival nodes. The only limitation is that they cannot serve old historical blocks to peers performing IBD, because they have already discarded that data.

Q18. The Bitcoin network's security depends on a majority of nodes being honest.

Answer: FALSE. Bitcoin's security depends on a majority of hash power being honest, not a majority of nodes. An attacker with many nodes but no hash power cannot produce invalid blocks that full nodes would accept. Conversely, an attacker with majority hash power could potentially reorganize the chain regardless of how many honest nodes exist.

Q19. BIP 324 provides encryption for Bitcoin P2P connections, making it harder to identify Bitcoin traffic through deep packet inspection.

Answer: TRUE. BIP 324 (v2 transport protocol), deployed in Bitcoin Core 26.0, encrypts P2P connections by default. This makes it significantly harder for network observers and DPI systems to identify Bitcoin protocol traffic, improving resistance to network-level censorship.

Q20. An SPV node can detect if a mining pool is censoring specific transactions by excluding them from blocks.

Answer: FALSE. An SPV node can only verify that a transaction is included in a block (via Merkle proof), not that a transaction has been excluded. Since SPV nodes don't download full blocks or maintain the full mempool, they cannot detect censorship by omission. Only full nodes that monitor the mempool and compare it against mined blocks can potentially detect systematic transaction exclusion.