> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/bitcoin-protocol-documentation/specification/blocks.md). # Blocks A block is an 80-byte header followed by an ordered list of transactions. The header commits to the block's transactions through the Merkle root and to the previous block through its hash, linking blocks into a chain. This page specifies the exact serialization and the consensus rules that make a block's structural fields valid. **Ground truth.** The layouts below derive from `CBlockHeader`/`CBlock` in [`src/primitives/block.h`](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/primitives/block.h), Merkle construction from [`src/consensus/merkle.cpp`](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/consensus/merkle.cpp), and proof-of-work from [`src/pow.cpp`](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/pow.cpp). All citations are pinned to release **v1.2.2** (commit `879fc8b`). ## Block header (80 bytes) The header is a fixed **80 bytes**: six fields, in this exact order (`CBlockHeader::SerializationOp`, [`block.h` L36–L46](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/primitives/block.h#L36-L46)): | # | Field | Type | Size (bytes) | Encoding | Notes | | - | ---------------- | ------ | ------------ | --------------------- | ---------------------------------------------------------------------------------------------------------------- | | 1 | `nVersion` | int32 | 4 | little-endian, signed | Block version. Must be ≥ 2 at/after the BIP34 activation height (see [Coinbase height](#coinbase-height-bip34)). | | 2 | `hashPrevBlock` | hash | 32 | internal byte order | Double-SHA-256 of the previous block's 80-byte header. | | 3 | `hashMerkleRoot` | hash | 32 | internal byte order | Merkle root of the block's transactions (see [Merkle root](#merkle-root-construction)). | | 4 | `nTime` | uint32 | 4 | little-endian | Block timestamp (Unix epoch seconds). | | 5 | `nBits` | uint32 | 4 | little-endian | Compact-form proof-of-work target (see [Proof of work](#proof-of-work)). | | 6 | `nNonce` | uint32 | 4 | little-endian | Nonce varied during mining. | The **block hash** is the double-SHA-256 of these 80 bytes, displayed as big-endian hex. Only the header is hashed for proof of work; the transactions are bound to it through `hashMerkleRoot`. ## Block body A full block is the header followed by its transactions (`CBlock::SerializationOp`, [`block.h` L97–L102](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/primitives/block.h#L97-L102)): | # | Field | Type | Size (bytes) | Encoding | Notes | | - | ----------------- | ----------------- | ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | header | `CBlockHeader` | 80 | see above | The 80-byte header. | | 2 | transaction count | CompactSize | 1–9 | little-endian | Number of transactions that follow. | | 3 | `vtx` | `CTransaction`\[] | variable | — | The transactions, back to back (see [Transactions](/bitcoin-protocol-documentation/specification/transactions.md)). The **first** transaction must be the coinbase. | The CompactSize count uses the same encoding as elsewhere in the protocol (1, 3, 5, or 9 bytes; see [Transactions](/bitcoin-protocol-documentation/specification/transactions.md#compactsize-varint)). ## Merkle root construction `hashMerkleRoot` commits to every transaction. It is built bottom-up (`ComputeMerkleRoot` / `BlockMerkleRoot`, [`merkle.cpp` L150–L184](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/consensus/merkle.cpp#L150-L184)): 1. The leaves are the transaction IDs (TxIDs), in block order. 2. At each level, adjacent nodes are paired and each pair is hashed with **double-SHA-256** of the two 32-byte values concatenated. 3. If a level has an **odd** number of nodes, the last node is paired **with itself**. 4. This repeats until a single 32-byte root remains. A block with one transaction has that transaction's TxID as the root. **Mutation guard (CVE-2012-2459).** Because the odd-node rule duplicates the last hash, an attacker could once craft two different transaction lists producing the same root. The builder detects any duplicated adjacent subtree hash and sets a `mutated` flag (`mutated |= (inner[level] == h)`, [`merkle.cpp` L89](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/consensus/merkle.cpp#L89)); a block whose Merkle computation is flagged mutated is treated as having an invalid Merkle root and is rejected. The calculator is limited to **2³² leaves**. ## Coinbase height (BIP34) At and after the BIP34 activation height, the coinbase transaction's `scriptSig` must **begin** with the block height, serialized as a Script number push. The node builds the expected prefix as `CScript() << nHeight` and requires the coinbase `scriptSig` to start with exactly those bytes ([`validation.cpp` L6039–L6048](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/validation.cpp#L6039-L6048)); a mismatch is rejected as `bad-cb-height`. From the same height, blocks with `nVersion < 2` are rejected. ## Proof of work A block header is valid under proof of work when its hash meets the target encoded in `nBits` (`CheckProofOfWork`, [`pow.cpp` L150–L171](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/pow.cpp#L150-L171)): 1. Decode `nBits` from its **compact form** to a 256-bit target. 2. Reject if the target is negative, zero, overflows, or exceeds the chain's `powLimit` (the maximum/easiest allowed target). 3. Require `blockHash ≤ target` (both interpreted as 256-bit big integers). `nBits` itself must equal the value required by the difficulty-adjustment algorithm for that height (`GetNextWorkRequired`, [`pow.cpp` L95](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/pow.cpp#L95)). BSV's history here is: the original retarget, then the **Emergency Difficulty Adjustment (EDA)** introduced at the UAHF fork, replaced by the current **Difficulty Adjustment Algorithm (DAA)** at the `daaHeight` (mainnet **504,031**), which retargets each block from a 144-block window. Target block spacing is 10 minutes. The details of *how* the next target is computed are consensus (they determine whether a block's `nBits` is valid); the mining machinery that searches for a nonce is not part of the protocol. ## Block size by era | Rule | Pre-UAHF | UAHF → Genesis | Genesis onward | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ------------------------------------------------------------ | | Maximum block size | `LEGACY_MAX_BLOCK_SIZE` = 1,000,000 bytes (1 MB), consensus ([`consensus.h` L31](https://github.com/bitcoin-sv/bitcoin-sv/blob/879fc8b42168dd0e608dafd51b39c6dabad37d4d/src/consensus/consensus.h#L31)) | raised, miner-configurable consensus cap | miner-configurable consensus cap (no fixed protocol maximum) | From the UAHF onward the block-size limit became a value miners set rather than a single hard-coded constant. There **is** a consensus limit at any moment (a block exceeding the active cap is invalid); the specific number a node uses is an operator-chosen **policy** value (e.g. `MAIN_DEFAULT_MAX_BLOCK_SIZE`) and is not itself part of the validity contract. See [Protocol Upgrade History](/bitcoin-protocol-documentation/specification/upgrade-history.md) for the activation timeline. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hub.bsvblockchain.org/bitcoin-protocol-documentation/specification/blocks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.