Multicast Coinbase Transaction Frame Format

Jeff Harris ([e-mail])

Abstract

This BRC defines the policy and wire mechanism for distributing coinbase transactions over the IPv6 multicast fabric. Coinbase transactions are carried as a dedicated message type within BRC-131 block control frames and delivered to all subscribers via the control-plane multicast group, independently of the shard groups used for ordinary transaction distribution.

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 transaction's TxID. Coinbase transactions cannot be sharded this way because:

1. Universal relevance — the coinbase TxID is included in every block announcement and is required to verify the block's Merkle root.

2. Fee aggregation — coinbase outputs pay the block subsidy and miner fee aggregations that downstream systems need to validate template construction.

3. Unpredictable placement — no subscriber can predict which shard a coinbase TxID would hash to before the block is found.

BRC-133 addresses this by routing coinbase frames to the GroupBlockBroadcast group (FF0E::B:FFFE), a global control channel that all subscribers join unconditionally.

Specification

Control-Plane Multicast Group

Coinbase frames are delivered on the GroupBlockBroadcast group:

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

The global scope (FF0E) ensures coinbase transactions cross site boundaries. 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).

Wire Format

Coinbase transactions are carried as BRC-131 frames (FrameVer 0x04) with MsgType = 0x02 (BlockMsgCoinbase).

Offset	Size	Field	Value
6	1	FrameVersion	0x04 (BRC-131)
7	1	MsgType	0x02 = BlockMsgCoinbase
8	32	ContentID	CoinbaseTxID — SHA256d of the raw coinbase tx bytes
40	8	HashKey	XXH64(senderIPv6 ∥ 0xFFF8 ∥ zeros); stamped by proxy
48	8	SeqNum	Monotonic per-sender counter; stamped by proxy
56	32	LayoutPad32	All zeros
88	4	PayloadLen	Length of the raw coinbase transaction bytes
92	*	Payload	Raw serialised coinbase transaction (no P2P envelope)

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

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

• The proxy stamps HashKey = XXH64(senderIPv6 ∥ 0xFFF8 ∥ zeros) and SeqNum (monotonic per sender on the coinbase flow) in-place before forwarding. The virtual index 0xFFF8 (GroupCoinbaseFlow) is never used as an actual multicast destination — it appears only in the HashKey computation to give coinbase frames an independent flow identity from BRC-131 block announces, which share the same egress multicast group. If the frame arrives pre-stamped (SeqNum != 0), it is forwarded verbatim.

• Listeners observe (coinbaseFlowIdx=0xFFF8, zeroSubtreeID, HashKey, SeqNum, ContentID) for gap detection and dispatch NACKs to retry endpoints on gap.

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

Relationship to BRC-131 Block Announcements

A BlockAnnounce frame (BRC-131, MsgType 0x01) is sent first and carries the CoinbaseTxID in its payload. The separate BlockMsgCoinbase frame then carries the full raw coinbase bytes. Subscribers that only need to verify the Merkle root may use the CoinbaseTxID from the announce frame without waiting for the coinbase frame itself.

BlockAnnounce and BlockMsgCoinbase form separate flows on the proxy. BlockAnnounce frames use a HashKey derived from (sender, 0xFFFE, zeros); Coinbase frames use a HashKey derived from (sender, 0xFFF8, zeros). Each flow therefore has its own monotonic SeqNum counter, its own HashKey value, and is gap-tracked independently by listeners — even though both egress to the same FF0E::B:FFFE multicast destination.

Constants Reference

Name	Value	Description
FrameVerV4	0x04	BRC-131 block control frame version
BlockMsgCoinbase	0x02	MsgType: raw coinbase transaction
GroupBlockBroadcast	0xFFFE	Block control multicast group index (egress)
GroupCoinbaseFlow	0xFFF8	Virtual HashKey ingredient; coinbase flow identity (never a multicast address)

References

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

• BRC-134: Chained Anchor Transaction Frames — another control-group transaction type