MASTERING-BITCOIN · Interactive Practice | Unit 11 · Video 3
| Concept | Key Detail |
|---|---|
| DNS seeds | Hardcoded hostnames returning lists of live node IPs (a phone book, not the network) |
| TCP port | Bitcoin nodes communicate on port 8333 |
| Handshake | version → version → verack → verack (then connection is live) |
| Gossip | addr announces yourself; getaddr requests more peers |
| Block header size | 80 bytes (vs. up to ~4 MB for a full block) |
| Headers-first sync | Phase 1: download headers from one peer. Phase 2: download full blocks in parallel |
| Parallel download window | Up to 1024 blocks queued across ~8 peers |
A fresh node starts with one peer (from a DNS seed). It then sends getaddr to learn about more peers, connects to some of them, and asks them too. This is called gossip.
Use the slider to advance through rounds of gossip and see how the peer set grows from a single bootstrap link into a resilient mesh.
⚙ interactive visualization — coming to this page format soon
Notice: At round 0 the node has only the bootstrap peer. Each round it asks its current peers for more addresses (getaddr) and opens new connections. Within a few rounds a single bootstrap link blooms into a mesh — no coordinator required.
Phase 1 of sync downloads only the 80-byte headers — a verified skeleton of the chain. Phase 2 then fetches the full blocks.
Move the slider to see how much data each phase represents at different chain heights. Note the dramatic difference between header bytes and full block bytes.
⚙ interactive visualization — coming to this page format soon
Reflect: Why is it worth doing two phases instead of just downloading everything? Headers are tiny and can be validated to form a trusted skeleton quickly — then the node knows exactly which block hashes it needs and can request them in parallel from many peers.
In Phase 2, the node opens a queue of up to 1024 blocks and farms slices out to multiple peers simultaneously. More peers means more throughput — but blocks must still be validated in order, so if one peer stalls the node must time it out and re-request from someone else.
Use the slider to vary the number of peers and see how the estimated download time scales.
⚙ interactive visualization — coming to this page format soon
Notice: Doubling peers roughly halves the time — until you run out of healthy peers. Also note the key constraint: blocks are delivered in parallel but validated in order. A single stalled peer at the front of the queue blocks the entire pipeline, which is why the protocol times out and replaces slow peers.
Question 1
When a fresh Bitcoin node queries a DNS seed during bootstrap, what does the seed return?
✅ Correct! DNS seeds are a phone book, not the network.
❌ Not quite. DNS seeds don't hold blockchain data or run Bitcoin — they only return addresses where Bitcoin nodes can be reached.
Solution:
DNS seeds act like a phone book: when a node queries them, they reply with a list of IP addresses of currently-live Bitcoin nodes. The seeds are not Bitcoin nodes themselves, do not hold the blockchain, and do not coordinate the network — they just hand out entry points.
Once a node has at least one peer, it can gossip its way to many more and stop relying on seeds entirely.
Question 2
True or False: DNS seeds are central servers that every Bitcoin node depends on for normal operation. If they all disappeared, the network would stop working.
✅ Correct! Seeds are a fallback, not a dependency — nodes remember peers across restarts.
❌ Not quite. Nodes cache peer addresses on disk after the first successful connection and reuse them on later restarts.
Solution:
False. DNS seeds are only a fallback bootstrap mechanism:
-seednode flag or any manually-supplied peer address.The network would continue to operate normally — the seeds are a convenience for first-time joiners, not a dependency.
Question 3
Why does Bitcoin use a headers-first sync (Phase 1: headers, Phase 2: full blocks) instead of just downloading full blocks from start to finish?
✅ Correct! Tiny headers first, then parallel full-block download.
❌ Not quite. Think about the size difference (80 bytes vs. ~1 MB) and what that enables in Phase 2.
Solution:
A block header is just 80 bytes: version, previous hash, Merkle root, timestamp, difficulty, and nonce. A full block can be megabytes.
By downloading headers first, the node:
Headers do not contain transaction signatures (those live in the block body), and they are not encrypted.
Question 4
During Phase 2 (parallel full-block download), the node has farmed out a queue of 1024 blocks across 8 peers. One peer becomes very slow and stalls on the oldest block in the queue. What does the node do, and why?
✅ Correct! Timeout, evict, re-request — the network self-tunes around slow peers.
❌ Not quite. Remember: blocks arrive in parallel but must be validated in order, because each block references the previous one's hash.
Solution:
Blocks must be validated in strict order, because each block references the hash of the previous one. So even though many blocks arrive in parallel, the front of the queue is a bottleneck: if the oldest pending block stalls, the whole pipeline blocks.
The node's response:
This is part of how the network self-tunes: slow peers get evicted automatically, parallel downloads route around bottlenecks, and the sync stays healthy.
❌ Skipping blocks and validating out of order is impossible — you can't verify a block without its predecessor.
❌ Restarting from genesis would throw away all completed work.
Solved: 0 / 4