Multicast Anchor Transaction Frame Format

Jeff Harris ([e-mail])

Abstract

This BRC defines a new frame version (0x06) for distributing chained anchor transactions over the IPv6 multicast fabric. An anchor transaction is the root (first) transaction in a chain of dependent transactions. Because all subsequent transactions in the chain reference the anchor as an input, every subscriber must receive it regardless of which shard its TxID would otherwise hash to.

Copyright

This BRC is licensed under the Open BSV License.

Motivation

The multicast fabric shards ordinary transactions across per-shard multicast groups based on the top bits of each TxID. Chained anchor transactions cannot be sharded this way because:

1. Dependency root — all dependent (chained) transactions in the set reference the anchor's TxID as an input. A subscriber that misses the anchor cannot validate any dependent transaction in the chain.

2. Unpredictable placement — the anchor's TxID is not known in advance by subscribers; they cannot pre-join the correct shard group.

3. Cross-shard span — the chain may span many shards. The anchor itself might hash to shard 0 while dependents are spread across shards 1–15. Every subscriber needs the anchor irrespective of which shards they follow.

4. Visibility over confirmation — anchor transactions do not need to be confirmed before use; they need only to be visible and valid. Wide visibility is the primary requirement.

BRC-134 addresses this by routing anchor frames to the GroupBlockBroadcast group (FF0E::B:FFFE), the same global control channel used for block headers and coinbase transactions (BRC-131, BRC-133). All subscribers join this group unconditionally.

Specification

Control-Plane Multicast Group

Anchor frames are delivered on the GroupBlockBroadcast group:

Index	Scope	Compressed Address	Constant
0xFFFE	global	FF0E::B:FFFE	GroupBlockBroadcast

The global scope (FF0E) ensures anchor transactions cross site boundaries and reach all geographically distributed subscribers. The group index 0xFFFE is in the reserved control-plane range and never overlaps with data-plane shard groups (maximum shard group index is 0x0FFF for shard_bits=12).

Frame Header Format (92 bytes)

The BRC-134 header is layout-identical to BRC-124. Infrastructure components that inspect the Magic, HashKey, or SeqNum fields read correct values at the same offsets.

Offset	Size	Align	Field	Value / Notes
0	4	—	Network Magic	0xE3E1F3E8 (BSV mainnet P2P magic)
4	2	—	Protocol Ver	0x02BF (703, BSV large-block baseline)
6	1	—	Frame Version	0x06 — BRC-134 anchor transaction
7	1	—	Reserved	0x00
8	32	8B	TxID	SHA256d of the anchor transaction (internal byte order)
40	8	8B	HashKey	XXH64(senderIPv6 ∥ 0xFFF9 ∥ zeros); stamped by proxy
48	8	8B	SeqNum	Monotonic per-sender counter; stamped by proxy; 0 = unset
56	32	8B	LayoutPad32	All zeros (no subtree scope for anchor frames)
88	4	—	PayloadLen	Size of anchor transaction payload in bytes (uint32 BE)
92	*	—	Payload	Raw serialised anchor transaction (no P2P envelope)

Key distinction from BRC-124: the version byte at offset 6 is 0x06 rather than 0x02. All other field offsets and sizes are identical. The LayoutPad32 field at bytes 56–87 is always zeros — anchor frames have no subtree scope. The field is kept for layout uniformity: the proxy TCP reader, stamping path, listener, and retry endpoint all share the single HeaderSize constant.

Payload encoding: The payload is a raw BSV serialised transaction — version (4 bytes LE), input vector, output vector, locktime (4 bytes LE) — identical to the encoding used in BRC-12/BRC-124 frames.

Sequencing and Retransmission

BRC-134 frames participate in the same NACK-based reliability mechanism as BRC-124 shard frames:

• The proxy stamps HashKey = XXH64(senderIPv6 ∥ 0xFFF9 ∥ zeros) and SeqNum (monotonic per sender) in-place before forwarding. The virtual index 0xFFF9 gives anchor frames an independent flow identity from BRC-131 block frames, which both travel on the same GroupBlockBroadcast multicast address. If the frame arrives pre-stamped (SeqNum != 0), it is forwarded verbatim.

• Listeners observe (anchorGroupIdx=0xFFF9, zeroSubtreeID, HashKey, SeqNum, TxID) for gap detection and dispatch NACKs to retry endpoints on gap.

• Retry endpoints join FF0E::B:FFFE and cache BRC-134 frames by HashKey ∥ SeqNum. On NACK, the frame is retransmitted to FF0E::B:FFFE.

Constants Reference

Name	Value	Description
FrameVerV6	0x06	BRC-134 chained anchor transaction frame version
GroupBlockBroadcast	0xFFFE	Control-plane multicast group index (shared with BRC-131/BRC-133)
GroupAnchorFlow	0xFFF9	Virtual HashKey ingredient; anchor flow identity (never a multicast address)

References

• BRC-124: Multicast Transaction Frame Format — base header layout reused by BRC-134

• BRC-133: Coinbase Transaction Delivery — another control-group transaction type using BRC-131