> 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/brc/transactions/0135.md).

# Multicast Block Header Format

Jeff Harris (<jeff@lightweb.net>)

## Abstract

This BRC specifies a lightweight wire format for distributing standalone 80-byte BSV block headers over IPv6 multicast and unicast transport. BRC-135 frames are produced by splitting the block header from a BRC-131 `BlockAnnounce` payload and wrapping it in a minimal 172-byte frame. The format reuses the 92-byte BRC-124 header layout, ensuring compatibility with existing infrastructure classifiers and firewall rules.

## Copyright

This BRC is licensed under the Open BSV License.

## Motivation

BRC-131 `BlockAnnounce` frames distribute block headers alongside CoinbaseTxID and a variable-length list of subtree root hashes. Many downstream consumers need only the 80-byte block header:

1. **SPV clients** require only the header chain to verify proof-of-work and compute chain state; subtree hashes and CoinbaseTxID are irrelevant.
2. **Mining coordinators** need the previous-block hash and timestamp to build new templates; the remaining announce payload adds unnecessary latency on constrained links.
3. **Header-chain archival services** store and index raw 80-byte headers and discard everything else.

Delivering the full `BlockAnnounce` payload to these consumers wastes bandwidth and increases processing overhead. BRC-135 defines a fixed-size, minimal frame that any node receiving a `BlockAnnounce` can produce by extracting the 80-byte header and re-emitting it to downstream consumers. A node that produces BRC-135 frames is referred to as an **emitter** throughout this specification.

## Specification

### Terminology

| Term          | Definition                                                                                                |
| ------------- | --------------------------------------------------------------------------------------------------------- |
| **Emitter**   | Any node that receives a BRC-131 `BlockAnnounce` frame and produces a BRC-135 block header frame from it. |
| **Consumer**  | A downstream node that receives and processes BRC-135 frames.                                             |
| **BlockHash** | The SHA256d hash of the 80-byte block header, in internal byte order.                                     |

### Multicast Group

BRC-135 frames are emitted to the emitter's configured multicast egress group or unicast egress address. They MUST NOT be re-injected onto the primary fabric group `FF0E::B:FFFE` — doing so would create a feedback loop as other fabric subscribers would receive the split frame on the control channel they already subscribe to.

When multicast egress is enabled, the emitter sends BRC-135 frames to the `GroupBlockHeader` index (`0xFFFA`) on the egress scope, typically a different scope or group-id from the ingress fabric:

| Index  | Scope           | Compressed Address | Notes                            |
| ------ | --------------- | ------------------ | -------------------------------- |
| 0xFFFA | egress (varies) | FF05:::FFFA        | Emitter multicast egress channel |

The egress group-id is set independently of the fabric group-id. This ensures BRC-135 frames reach only downstream consumers, not peer fabric subscribers or retry endpoints on the ingress fabric.

### Frame Header Format (92 bytes)

The BRC-135 header is layout-identical to BRC-124. All infrastructure components that inspect Magic, HashKey, or SeqNum read correct values at the same offsets. All multi-byte integers are big-endian.

| Offset | Size | Alignment | Field         | Description                                               |
| ------ | ---- | --------- | ------------- | --------------------------------------------------------- |
| 0      | 4    | —         | Network Magic | 0xE3E1F3E8 (BSV mainnet P2P magic)                        |
| 4      | 2    | —         | Protocol Ver  | 0x02BF (703, BSV large-block baseline)                    |
| 6      | 1    | —         | Frame Version | 0x07 — BRC-135 block header                               |
| 7      | 1    | —         | Reserved      | 0x00                                                      |
| 8      | 32   | 8-byte    | BlockHash     | SHA256d of the 80-byte block header (internal byte order) |
| 40     | 8    | 8-byte    | HashKey       | XXH64(emitterIPv6 ∥ 0xFFFE ∥ zeros); stamped by emitter   |
| 48     | 8    | 8-byte    | SeqNum        | Monotonic per-emitter counter; stamped by emitter         |
| 56     | 32   | 8-byte    | LayoutPad32   | All zeros (no subtree scope for block headers)            |
| 88     | 4    | —         | PayloadLen    | 0x00000050 (80 = fixed block header size, uint32 BE)      |
| 92     | 80   | —         | Payload       | Raw 80-byte BSV block header                              |

**Total frame size:** 172 bytes (92 header + 80 payload). Always fits in a single UDP datagram — no fragmentation is required.

### Field Definitions

#### Network Magic (bytes 0–3)

The value `0xE3E1F3E8` (BSV mainnet P2P network magic). This enables standard BSV firewall rules and network monitoring tools to correctly classify BRC-135 frames. Frames with incorrect magic MUST be rejected.

#### Protocol Version (bytes 4–5)

The value `0x02BF` (703 in decimal). Informational; receivers do not validate it.

#### Frame Version (byte 6)

The value `0x07` identifies a BRC-135 block header frame. Any other version is handled by other decoders.

#### Reserved (byte 7)

Must be `0x00`. Unlike BRC-131 which uses this byte for MsgType, BRC-135 has no message subtypes — the frame always carries exactly one block header.

#### BlockHash (bytes 8–39)

The SHA256d of the 80-byte block header in internal byte order. This value is identical to the `ContentID` field in a BRC-131 `BlockAnnounce` frame for the same block.

#### HashKey (bytes 40–47)

A stable per-emitter flow identifier computed as:

```
HashKey = XXH64(emitterIPv6 [16 bytes] ∥ 0x0000FFFE [4 bytes BE] ∥ zeros [32 bytes])
```

The `0xFFFE` group index is `GroupBlockBroadcast`, the same control-plane index used by BRC-131/133/134. The 32 zero bytes correspond to the absent SubtreeID. The HashKey is constant for the lifetime of the emitter process.

A value of `0` indicates the field is unset.

#### SeqNum (bytes 48–55)

A 64-bit unsigned integer (big-endian) containing a monotonic counter starting at 1, incremented for each BRC-135 frame emitted. Each emitter maintains a single counter for all block header frames.

A value of `0` indicates the field is unset.

#### LayoutPad32 (bytes 56–87)

All zeros. This field is retained to keep the header at 92 bytes, maintaining layout uniformity with BRC-124 and other frame versions. Block header frames have no subtree scope.

#### PayloadLen (bytes 88–91)

Always `0x00000050` (80 in decimal). A frame with any other PayloadLen MUST be rejected.

#### Payload (bytes 92–171)

The raw 80-byte BSV block header, byte-for-byte identical to the first 80 bytes of a BRC-131 `BlockAnnounce` payload:

| Offset | Size | Encoding  | Field         | Description                             |
| ------ | ---- | --------- | ------------- | --------------------------------------- |
| 0      | 4    | int32 LE  | Version       | Block version                           |
| 4      | 32   | bytes     | PrevBlockHash | Hash of previous block (internal order) |
| 36     | 32   | bytes     | MerkleRoot    | Merkle root of the block's tx tree      |
| 68     | 4    | uint32 LE | Timestamp     | Block timestamp (Unix epoch seconds)    |
| 72     | 4    | uint32 LE | Bits          | Compact difficulty target               |
| 76     | 4    | uint32 LE | Nonce         | Proof-of-work nonce                     |

No additional framing or envelope is applied. The block header is copied verbatim from the BRC-131 `BlockAnnounce` payload bytes `[0:80]`.

### Frame Production

Any node that receives a BRC-131 `BlockAnnounce` frame (`FrameVer=0x04`, `MsgType=0x01`) MAY produce a BRC-135 frame:

1. Extract the 80-byte block header from `BlockAnnounce` payload bytes `[0:80]`.
2. Copy the `BlockHash` from the BRC-131 frame's `ContentID` field (bytes 8–39).
3. Stamp `HashKey` using the emitter's own IPv6 address per the formula above.
4. Increment and stamp `SeqNum`.
5. Emit the 172-byte frame to the configured egress.

The emitter stamps `HashKey` and `SeqNum` using its own identity — not the proxy's. This reflects that the emitter is the originator of the split frame. Each emitter produces an independent sequence stream.

### Sequencing

BRC-135 frames carry their own independent `HashKey`/`SeqNum` flow:

* Each emitter maintains a single SeqNum counter for all block headers.
* Downstream consumers that track gaps identify the emitter via HashKey.
* If a consumer receives BRC-135 frames from multiple emitters (e.g., via anycast or failover), each emitter produces an independent sequence stream.

### Retransmission

BRC-135 frames are **not retransmitted** via the standard BRC-126 NACK path on the primary fabric. They are a derived product — if a downstream consumer misses a BRC-135 frame, it can recover from a different source:

1. **Redundant emitters** — multiple emitters produce the same block header; downstream consumers subscribe to more than one for reliability.
2. **Re-request from upstream** — the consumer re-requests the full BRC-131 `BlockAnnounce` via BRC-126 NACK to a retry endpoint, then extracts the header locally.
3. **Application-level retry** — the downstream consumer requests the block header by hash from any BSV peer using the standard `getheaders` protocol.

If a deployment requires NACK-based retransmission for BRC-135 frames on the egress network, a secondary retry endpoint can be deployed on the egress segment that joins the egress multicast group and caches BRC-135 frames by `HashKey ∥ SeqNum`. This is an optional deployment topology, not a protocol-level requirement.

### Error Handling

| Condition                       | Action                                 |
| ------------------------------- | -------------------------------------- |
| raw\[6] != 0x07                 | Not BRC-135; handled by other decoders |
| Bad magic                       | Silent drop                            |
| PayloadLen != 80                | Drop; ErrBadBlockHeaderLen             |
| Datagram shorter than 172 bytes | Drop; ErrTooShort                      |
| BlockHash mismatch (optional)   | Drop; integrity verification failed    |

### Consumer Processing

A consumer receiving BRC-135 frames:

1. **Validate** — Check `raw[0:4] == 0xE3E1F3E8`, `raw[6] == 0x07`, `PayloadLen == 80`.
2. **Extract** — Read the 80-byte block header from `raw[92:172]`.
3. **Verify** — Optionally compute `SHA256d(raw[92:172])` and compare against `BlockHash` (bytes 8–39) to confirm integrity.
4. **Gap track** — If consuming from a single emitter, monitor `SeqNum` continuity on the `HashKey` flow to detect missed headers.

## Examples

### BRC-135 Frame Hex Dump

A BRC-135 frame carrying the block header for block hash `00000000000000000...`:

```
// Header (92 bytes)
E3E1F3E8                                                          // Network Magic
02BF                                                              // Protocol Version
07                                                                // Frame Version (BRC-135)
00                                                                // Reserved
00000000000000000001a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3  // BlockHash
00112233AABBCCDD                                                  // HashKey (XXH64 of emitter flow)
0000000000000001                                                  // SeqNum (1)
0000000000000000000000000000000000000000000000000000000000000000  // LayoutPad32 (zeros)
00000050                                                          // PayloadLen (80)

// Payload (80 bytes — raw BSV block header)
20000000                                                          // Version (LE)
00000000000000000...                                              // PrevBlockHash (32 bytes)
aabbccdd00112233...                                               // MerkleRoot (32 bytes)
665B1A00                                                          // Timestamp (LE)
1D00FFFF                                                          // Bits (LE)
12345678                                                          // Nonce (LE)
```

## References

* [BRC-124: Multicast Transaction Frame Format](/brc/transactions/0124.md) — Base header layout reused by BRC-135
* [BRC-131: Block Announcement Frame Format](/brc/transactions/0131.md) — Source of the 80-byte block header extracted by the emitter
* [BRC-133: Coinbase Transaction Frame Format](/brc/transactions/0133.md) — Companion control-plane frame type
* [BRC-134: Anchor Transaction Frame Format](/brc/transactions/0134.md) — Companion control-plane frame type
* [BRC-126: Retransmission Protocol](/brc/transactions/0126.md) — NACK/ACK/MISS used for upstream block frame retransmission
* [BRC-129: Multicast Group Address Assignments](/brc/transactions/0129.md) — Control-plane group index allocations

## Constants Reference

| Name                 | Value | Hex    | Description                                       |
| -------------------- | ----- | ------ | ------------------------------------------------- |
| FrameVerV7           | 7     | 0x07   | BRC-135 block header frame version                |
| BlockHeaderPayload   | 80    | 0x50   | Fixed payload size (standard BSV block header)    |
| BlockHeaderFrameSize | 172   | 0xAC   | Total frame size (92 + 80)                        |
| GroupBlockHeader     | 65530 | 0xFFFA | Block header egress channel (BRC-135 mc-egress)   |
| GroupBlockBroadcast  | 65534 | 0xFFFE | Control group index (shared with BRC-131/133/134) |
| HeaderSize           | 92    | 0x5C   | BRC-135 header size (identical to BRC-124)        |


---

# 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:

```
GET https://hub.bsvblockchain.org/brc/transactions/0135.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.