BA-09 · LESSON 03

Initial block download

KEY DEFINITIONS

Terms used in this lesson

IBD: Initial block download: the process of downloading and validating historical headers and blocks to build a node's current chainstate.
UTXO: Unspent transaction output: one discrete chunk of bitcoin that can be used as a transaction input.
Proof-of-work target: The maximum header-hash value accepted for a block; lowering it makes valid hashes harder to find.

A new node downloads and validates historical headers and blocks before reaching the current tip.

55 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · p2p propagationIndependent peers relay claims, then verify locallySelect any state to inspect its exact role.

RELATIONSHIP MAPIndependent peer relationships

01
ORIGINWallet or peer
A node receives a transaction, header, block, or request from an untrusted connection.
02
PARSEBounded message
Length, command, encoding, and resource limits are checked before deeper work.
03
VALIDATEInitial block download
The Initial block download stage applies local policy or consensus rules as appropriate.
04
STOREMempool or chainstate
Accepted data enters a local view that can differ temporarily from another node's view.
05
RELAYSelected peers
Relay spreads a valid candidate; it does not make the candidate final or universally known.

Rule shown: Network messages are invitations to verify, never authority to accept state.

STAGE 1 OF 5ORIGIN: Wallet or peer

A node receives a transaction, header, block, or request from an untrusted connection.

Governing relationship: Network messages are invitations to verify, never authority to accept state. Complete path: 1. ORIGIN, Wallet or peer. A node receives a transaction, header, block, or request from an untrusted connection. 2. PARSE, Bounded message. Length, command, encoding, and resource limits are checked before deeper work. 3. VALIDATE, Initial block download. The Initial block download stage applies local policy or consensus rules as appropriate. 4. STORE, Mempool or chainstate. Accepted data enters a local view that can differ temporarily from another node's view. 5. RELAY, Selected peers. Relay spreads a valid candidate; it does not make the candidate final or universally known.

1. State transitionWhat exists, what changes, and what results

BEFORE

Peer A advertises height 900,000 but sends a header chain with invalid proof at 850,010. Peer B advertises 899,500 with valid greater accumulated work.

MECHANISM

The node requests batches of headers from peers and checks structure, target transitions, proof, timestamps, and linkage.

AFTER

IBD moves trust from a remote balance service to locally reproduced history, at the cost of time and resources.

Text equivalent: Starting from Peer A advertises height 900,000 but sends a header chain with invalid proof at 850,010. Peer B advertises 899,500 with valid greater accumulated work. The mechanism begins when The node requests batches of headers from peers and checks structure, target transitions, proof, timestamps, and linkage. The resulting lesson is IBD moves trust from a remote balance service to locally reproduced history, at the cost of time and resources.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Acquire header chains

The node requests batches of headers from peers and checks structure, target transitions, proof, timestamps, and linkage.

Complete path: 1. Acquire header chains: The node requests batches of headers from peers and checks structure, target transitions, proof, timestamps, and linkage. 2. Select best valid headers: Accumulated work identifies the candidate chain to fetch. A peer's claimed height or peer count does not replace this calculation. 3. Download blocks in parallel: The node requests blocks from multiple peers while controlling in-flight work and preserving dependency order for connection. 4. Validate and build chainstate: Every block and transaction is checked before its UTXO effects are committed. An assume-valid setting is a configured historical checkpoint that can skip some earlier signature checks under constrained conditions; it does not permit invalid proof or arbitrary state. 5. Approach the current tip: IBD optimizations change as the node nears recent time. Wallets should wait for an appropriate synchronization state before treating balances as complete.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Headers must pass linkage, proof, target, and work selection before block requests; downloaded blocks then validate in order before their UTXO effects become chainstate.

CHANGED CONDITION

Invalid or stalled peers are excluded, and complete headers or block bytes do not make the node ready while validation remains behind.

Important distinction: Headers-first sync trusts headers and validates only recent blocks. Headers are validated for their own consensus rules, then corresponding blocks are downloaded and validated. Optimizations have defined bounds rather than turning headers into trusted state.

Text equivalent: The accepted path is enforced by Headers must pass linkage, proof, target, and work selection before block requests; downloaded blocks then validate in order before their UTXO effects become chainstate. If the required condition changes, Invalid or stalled peers are excluded, and complete headers or block bytes do not make the node ready while validation remains behind.

Loading lesson visuals...

Learn the idea

Initial block download, or IBD, is the process by which a new node obtains and validates historical chain data before treating itself as current. Headers-first synchronization downloads compact headers, validates proof and linkage, chooses the best valid header chain by work, then downloads and validates the corresponding blocks to build chainstate.

GUIDED EXPLANATION1/5 ideas inspected

Acquire header chains

The node requests batches of headers from peers and checks structure, target transitions, proof, timestamps, and linkage.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Headers-first sync trusts headers and validates only recent blocks.”

Headers are validated for their own consensus rules, then corresponding blocks are downloaded and validated. Optimizations have defined bounds rather than turning headers into trusted state.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.