Multicast Subtree Data Frame Format

Abstract

This BRC defines frame version 0x05 for distributing complete Merkle subtree contents — transaction hashes and optional per-transaction metadata — over the IPv6 multicast fabric. Subtree data frames are delivered to all subscribers via the dedicated GroupSubtreeDataAnnounce multicast group (FF0X::B:FFFB), independently of the per-shard groups used for individual transaction distribution.

Copyright

This BRC is licensed under the Open BSV License.

Motivation

The multicast fabric distributes individual transactions shard-by-shard (BRC-124) and block-level metadata (BRC-131). BRC-132 fills the remaining gap: delivering the contents of each Merkle subtree so that subscribers can:

1. Reconstruct the subtree Merkle tree locally.
2. Verify block inclusion without fetching individual transactions.
3. Power block-assembly tooling and downstream analytics without per-transaction retrieval.

BRC-132 complements BRC-127, which maps SubtreeIDs to GroupIDs for shard-level filtering. BRC-127 announces where a subtree lives; BRC-132 delivers what it contains.

Specification

Multicast Group

Subtree data frames are sent to the GroupSubtreeDataAnnounce group (index 0xFFFB):

Scope selection follows the GroupBeacon pattern defined in BRC-129. Operators select one or more scopes via the -announce-scope flag on listening components.

Addresses are shown in ASM (FF0x) form; under SSM, substitute the FF3x prefix per BRC-129 (FF3E::B:FFFB for inter-domain scope, SSM-only per RFC 8815). The frame format and NACK/fragmentation paths are unchanged. Under SSM, receivers (S,G)-join using the subtree-data source (the emitting proxy, senderIPv6); the source set is distributed per BRC-129 (data-plane sources via the shard manifest).

Frame Header Format (92 bytes)

The BRC-132 header is layout-identical to the BRC-124 header. All infrastructure components that inspect Magic, HashKey, or SeqNum read correct values at the same offsets. The header is read using the same 44+48 two-step protocol as BRC-124 and BRC-131.

Key distinctions from BRC-124:

• Byte 7 carries MsgType rather than Reserved = 0x00.
• Bytes 8–39 carry SubtreeID (the Merkle root), not a TxID.
• LayoutPad32 (bytes 56–87) is always zero. SubtreeID already serves as content identifier and flow scope; no secondary field is needed. The field is retained so that HeaderSize = 92 remains uniform across V2/V4/V5.
• HashKey is computed as XXH64(senderIPv6 ∥ 0xFFFB ∥ SubtreeID). Each distinct subtree from the same sender has an independent sequence stream, so loss in one subtree does not create false gaps in another.

MsgType Values

Any other MsgType value causes the frame to be rejected with ErrBadSubtreeMsg.

Payload Format

Both MsgType variants share a 24-byte metadata prefix followed by N node entries and a conflict set.

Common Prefix (24 bytes)

MsgType 0x01 — HashesOnly

Maximum size at 1M nodes, 0 conflicts: 24 + 32 × 1,048,576 + 8 ≈ 32 MB.

MsgType 0x02 — FullNodes

Maximum size at 1M nodes, 0 conflicts: 24 + 48 × 1,048,576 + 8 ≈ 48 MB.

Fragmentation

Payloads of 32–48 MB exceed any path MTU. The proxy fragments each BRC-132 frame using BRC-130:

• OrigFrameVer = 0x05 in each BRC-130 fragment header (byte 100).
• MsgType is preserved in fragment header byte 7 (same pattern as BRC-131 fragmentBlock).
• Fragment reassembly is keyed by SubtreeID (bytes 8–39), matching the TxID slot used by BRC-124 fragments.
• SHA256d hash verification does not apply — SubtreeID is a Merkle root, not a payload double-hash. The verifyHash flag must be false for V5 reassembly slots.
• Optional post-reassembly Merkle-root verification is available (see §Merkle Verification).

Fragment counts at MTU 9000 (fragDataSize = 8848 bytes):

Both fit within the uint16 FragTotal limit of 65,535.

Sequence Tracking and Retransmission

BRC-132 frames participate in the same NACK-based reliability mechanism as BRC-124 and BRC-131:

• The proxy stamps HashKey and SeqNum in-place before forwarding. Each (senderIPv6, SubtreeID) pair owns an independent monotonic sequence stream.
• If SeqNum is already non-zero on arrival, the frame is forwarded verbatim (pre-stamped path).
• Listeners detect gaps on the (HashKey, 0xFFFB, SubtreeID) flow and dispatch BRC-126 NACKs to retry endpoints.
• Retry endpoints join FF0X::B:FFFB and cache BRC-132 frames and BRC-130 fragments (OrigFrameVer = 0x05) by HashKey ∥ SeqNum. On NACK, the frame is retransmitted to FF0X::B:FFFB. The retry endpoint TTL for BRC-132 frames defaults to 120 s (compared to 60 s for transaction frames) to accommodate large reassembly windows.

Merkle Verification

After reassembly, optional Merkle-root recomputation verifies the SubtreeID:

• Enabled by -subtree-data-verify-merkle / SUBTREE_DATA_VERIFY_MERKLE=true on the listener.
• The listener decodes the payload into nodes and computes SHA256d pairwise up the binary tree, then compares the root to SubtreeID.
• Computationally significant at 1M nodes (~1M double-SHA256 operations); disabled by default.
• On mismatch: drop the reassembly slot; increment bsl_reassembly_merkle_mismatch_total.

Error Handling

Constants Reference

References

• BRC-119: SubTree Unified Merkle Path (STUMP) Format — SubtreeID definition and Merkle subtree structure
• BRC-124: Multicast Transaction Frame Format — Base header layout reused by BRC-132
• BRC-126: BSV Multicast NACK Retransmission Protocol — NACK-based reliability used for subtree frame retransmission
• BRC-127: Multicast Subtree Group Announcement Frame Format — SubtreeID→GroupID metadata; distinct from BRC-132 data delivery
• BRC-129: IPv6 Multicast Group Address Assignments — Group index allocations; 0xFFFB = GroupSubtreeDataAnnounce
• BRC-130: Multicast Frame Fragmentation — Fragmentation for large subtree payloads; OrigFrameVer = 0x05
• BRC-131: Block Announcement Protocol — FrameVerV4 pattern followed by BRC-132