Multicast Coinbase Transaction Frame Format

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.

Status Note

Deprecated, and retained deliberately. Standalone coinbase carriage, the mechanism this BRC specifies (BRC-131 MsgType 0x02, BlockMsgCoinbase), is deprecated. It is kept on purpose and is not withdrawn.

• Not produced. A coinbase transaction is invalid to a node unless it is connected to its block, so current implementations never emit standalone coinbase frames. The coinbase travels inline in the block body defined by BRC-144, where it inherits the proof of work of the block it belongs to.
• Dropped by default. A standalone coinbase frame carries no proof of work of its own, so nothing about it can be validated in isolation. A listener that gates block-control frames before fan-out (the reference listener's block-control gate, which is on by default) drops such a frame; the reference implementation counts it under the drop reason coinbase_legacy.
• Retained deliberately. A future design may need to carry blocks and their coinbase separately across the multicast fabric and recombine them at the edges. This specification keeps that option open, so it remains the reference for such a design, for deployments that disable the gate, and for decoding archived traffic.
• Reserved. The BRC-133 number, BRC-131 MsgType 0x02, and the virtual flow index 0xFFF8 (GroupCoinbaseFlow) remain reserved for standalone coinbase carriage. They must not be reused for any other purpose.

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:

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).

The address is shown in ASM form (FF0E::B:FFFE), intra-domain only under RFC 8815; inter-domain delivery uses the SSM address FF3E::B:FFFE (see BRC-129). The frame format and NACK path are unchanged. Coinbase and block-announce frames are separate flows but share the same egress source (the emitting proxy, senderIPv6), so SSM receivers (S,G)-join 0xFFFE once; block-broadcast sources are distributed per BRC-129.

Wire Format

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

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

References

• BRC-124: Multicast Transaction Frame Format — base header layout reused by BRC-131
• BRC-129: Multicast Group Address Assignments — SSM/ASM addressing, scopes, and (S,G) source discovery
• BRC-134: Chained Anchor Transaction Frames — another control-group transaction type
• BRC-144: Block Frame Format: the block body that carries the coinbase inline, superseding standalone coinbase carriage