> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/transactions/0144.md). # Block Frame Format Jeff Harris () ## Abstract This BRC specifies the push wire form of a **block** — the 80-byte block header, block-level counts, the ordered list of subtree roots the block references, the full coinbase transaction, the block height, and the coinbase merkle path — for delivery and ingest over a byte stream. It carries everything a receiver needs to assemble and validate the block without a follow-up fetch. All frame integers are fixed-width big-endian; consensus-defined payloads (the header, the coinbase transaction, the BUMP) keep their native serialisation. ## Copyright This BRC is licensed under the Open BSV License. ## Motivation A block commits to its transactions through a header and names the subtrees it references in order — the block↔subtree association that binds independently delivered subtrees ([BRC-143](/transactions/0143.md)) into a block and fixes their order for merkle assembly. In an announce/pull system a node is *notified* of a block (hash, height, a fetch URL) and then pulls the full block on demand. A **push** delivery has no fetch URL: the block arrives whole and unsolicited, so the frame carries the complete block body inline. Its field sequence mirrors the block serialisation a node already ingests — header, counts, subtree roots, the full coinbase, height, and the coinbase BUMP — with each variable-length integer replaced by a fixed-width big-endian field. The coinbase is carried **in-band** because it cannot be delivered as a loose transaction (a node rejects a standalone coinbase on its transaction path) and the block assembly needs its bytes. ## Specification ### Frame layout All frame integers are big-endian. Hashes are in internal byte order. The embedded block header, coinbase transaction, and coinbase BUMP keep their native serialisations. ``` | Size | Field | Notes | |--------|-------------------|--------------------------------------------------------------------| | 80 | BlockHeader | Standard 80-byte block header (below). | | 8 | TransactionCount | uint64 BE. Total transactions committed by the block. | | 8 | SizeInBytes | uint64 BE. Total serialized block size. | | 8 | SubtreeCount (M) | uint64 BE. Number of subtree roots that follow. | | 32 × M | SubtreeHashes | Ordered subtree merkle roots, each 32 bytes. | | * | Coinbase | Full coinbase transaction (BRC-12), self-delimiting by structure. | | 8 | Height | uint64 BE. Block height. | | 8 | CoinbaseBUMPLen | uint64 BE. Byte length of the coinbase BUMP that follows. | | * | CoinbaseBUMP | BRC-74 merkle path of the coinbase; present only when `CoinbaseBUMPLen > 0`. | ``` Fixed prefix through `SubtreeCount` is **104 bytes**; `SubtreeHashes`, `Coinbase`, and `CoinbaseBUMP` are variable. The `Coinbase` has no length prefix — it is self-delimiting by transaction structure (version, input/output vectors, locktime), so a reader parses it and resumes at `Height`. The field order and semantics mirror the block body a node serialises natively; this frame is that body with fixed-width big-endian counts in place of variable integers. ### Block header (80 bytes) The standard block header, consensus byte layout: | Offset | Size | Field | Encoding | | ------ | ---- | ------------------- | ------------------------------------------------ | | 0 | 4 | Version | uint32 little-endian | | 4 | 32 | Previous block hash | SHA256d, internal byte order | | 36 | 32 | Merkle root | SHA256d of the tx tree, internal byte order | | 68 | 4 | Timestamp | uint32 little-endian (Unix seconds) | | 72 | 4 | nBits | uint32 little-endian (compact difficulty target) | | 76 | 4 | Nonce | uint32 little-endian | `BlockHash = SHA256d(BlockHeader)` — the receiver computes it from the 80 bytes; there is no separate block-hash field. The previous-block hash (bytes 4–35) gives chain context intrinsically. Block height is not present in a block header (it appears in the coinbase per BIP-34) and is carried explicitly as the `Height` field so the receiver need not extract it. ### Coinbase and subtree association `SubtreeHashes` is ordered to match the producer's subtree enumeration — the order used to assemble the block merkle root from the subtree roots. A block's **first** subtree ([BRC-143](/transactions/0143.md)) carries the `0xFF × 32` coinbase placeholder at its first node; the receiver substitutes the coinbase transaction carried here into that slot when it reconstructs the block. The coinbase is the full transaction, not just its identifier: a node rejects a loose coinbase on its transaction-ingest path, so it is delivered only here, and block assembly consumes its bytes directly. ## Identity Block identity is `BlockHash = SHA256d(BlockHeader)`. The block's committed merkle root (header bytes 36–67) is the value a receiver reproduces from the ordered subtree roots and the coinbase; there is no separate identifier field. ## References * [BRC-143: Subtree Data Frame Format](/transactions/0143.md) — the subtrees this block orders; the block↔subtree association lives here, not in the subtree frame * [BRC-74: BSV Unified Merkle Path (BUMP) Format](/transactions/0074.md) — the `CoinbaseBUMP` payload * [BRC-12: Raw Transaction Format](/transactions/0012.md) — the coinbase transaction body ## Constants Reference | Name | Value | Description | | ---------------- | ----- | ---------------------------------------------------------------- | | BlockFramePrefix | 104 | Header + TransactionCount + SizeInBytes + SubtreeCount, in bytes | | BlockHeaderSize | 80 | Block header, in bytes | --- # 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://bsv.brc.dev/transactions/0144.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.