BA-08 · LESSON 09

Raw block anatomy and blk.dat

KEY DEFINITIONS

Terms used in this lesson

Coinbase transaction: The special first transaction in a Bitcoin block, which claims permitted subsidy and fees and has no ordinary prior-output input.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
HASH256: Bitcoin's name for applying SHA-256 twice to the same byte sequence.
Outpoint: A transaction ID plus output number that identifies one exact prior output.
Block subsidy: New bitcoin that consensus permits a block's coinbase transaction to create at a particular height.
Transaction ID: The identifier produced by hashing a Bitcoin transaction’s non-witness serialization.
SegWit: Segregated Witness: a Bitcoin upgrade that separates authorization data from the transaction identifier and introduces versioned witness programs.
Witness transaction ID: An identifier that commits to a transaction including its witness data.
BIP34: The consensus rule requiring a block's coinbase transaction to begin its ScriptSig with the block height.

Decode disk framing, the 80-byte header, CompactSize transaction count, coinbase, ordinary transactions, witness commitment, and neighbouring block links.

35 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 · raw block recordblk.dat framing wraps a separately hashed blockSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
DISK FRAMEF9beb4d9 followed by size
The eight framing bytes are outside the block hash.
02
HEADER80 exact bytes
Version, parent, root, time, nBits, and nonce commit the candidate.
03
TX COUNTCompactSize n
The payload must contain exactly the declared complete transactions.
04
COMMITMENTSMerkle and witness roots match
Nodes recompute both roots from ordered transaction data.
05
CHAINParent known, connect
Height derives from the parent relationship rather than a header height field.

Rule shown: Disk magic and size bound storage parsing; the 80-byte header and transaction list define the consensus object.

STAGE 1 OF 5DISK FRAME: F9beb4d9 followed by size

The eight framing bytes are outside the block hash.

Governing relationship: Disk magic and size bound storage parsing; the 80-byte header and transaction list define the consensus object. Complete path: 1. DISK FRAME, F9beb4d9 followed by size. The eight framing bytes are outside the block hash. 2. HEADER, 80 exact bytes. Version, parent, root, time, nBits, and nonce commit the candidate. 3. TX COUNT, CompactSize n. The payload must contain exactly the declared complete transactions. 4. COMMITMENTS, Merkle and witness roots match. Nodes recompute both roots from ordered transaction data. 5. CHAIN, Parent known, connect. Height derives from the parent relationship rather than a header height field.

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

BEFORE

A mainnet blk.dat record begins f9beb4d9 followed by a four-byte size and then a block whose header version is 1.

MECHANISM

Read the network-specific four-byte magic and four-byte payload length, reject the wrong network or oversized length, then consume exactly that many block bytes before seekin…

AFTER

Block files wrap consensus objects, so a correct reader keeps storage framing, block serialization, and chain validation separate.

Text equivalent: Starting from A mainnet blk.dat record begins f9beb4d9 followed by a four-byte size and then a block whose header version is 1. The mechanism begins when Read the network-specific four-byte magic and four-byte payload length, reject the wrong network or oversized length, then consume exactly that many block bytes before seeking the next frame. The resulting lesson is Block files wrap consensus objects, so a correct reader keeps storage framing, block serialization, and chain validation separate.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Parse blk.dat framing

Read the network-specific four-byte magic and four-byte payload length, reject the wrong network or oversized length, then consume exactly that many block bytes before seeking the next frame.

Complete path: 1. Parse blk.dat framing: Read the network-specific four-byte magic and four-byte payload length, reject the wrong network or oversized length, then consume exactly that many block bytes before seeking the next frame. 2. Decode the header: Read version, previous-block hash, Merkle root, time, nBits, and nonce. The six fields total 80 bytes. HASH256 of those bytes produces the block hash displayed in reverse digest order. 3. Decode transaction count and coinbase: CompactSize states the number of transactions. Transaction zero must be exactly one coinbase with a null previous outpoint, a height commitment when required, and output value no greater than subsidy plus fees. 4. Verify block commitments: Recompute txids in order and build the transaction Merkle root. For SegWit blocks, reconstruct wtxids and verify the coinbase witness commitment and reserved value. 5. Connect neighbouring blocks: The header previous-block hash must identify a known valid parent. Height comes from the parent relationship, not from a general header field. Connecting applies transactions atomically to chainstate.

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

ACCEPTED PATH

Frame magic and size bound storage parsing, while header proof, parent, Merkle root, transactions, issuance, witness commitment, and chain context bound consensus acceptance.

CHANGED CONDITION

Hashing the disk magic or size as part of the header creates the wrong block identifier. Trusting the frame length without independent limits enables resource abuse.

Important distinction: Block height is stored in every block header. Height is derived from the linked chain. Modern coinbase ScriptSig commits the height under BIP34, but the 80-byte header has no height field.

Text equivalent: The accepted path is enforced by Frame magic and size bound storage parsing, while header proof, parent, Merkle root, transactions, issuance, witness commitment, and chain context bound consensus acceptance. If the required condition changes, Hashing the disk magic or size as part of the header creates the wrong block identifier. Trusting the frame length without independent limits enables resource abuse.

Loading lesson visuals...

Learn the idea

A raw block on the Bitcoin peer-to-peer network begins with an 80-byte header followed by a CompactSize transaction count and complete transactions. Bitcoin Core block files add an eight-byte disk frame before each block: four network-magic bytes and a four-byte little-endian block size. Disk framing is storage metadata and is not part of the block hash.

GUIDED EXPLANATION1/5 ideas inspected

Parse blk.dat framing

Read the network-specific four-byte magic and four-byte payload length, reject the wrong network or oversized length, then consume exactly that many block bytes before seeking the next frame.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Block height is stored in every block header.”

Height is derived from the linked chain. Modern coinbase ScriptSig commits the height under BIP34, but the 80-byte header has no height field.

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.