Multicast Extended Transaction Frame Format

Jeff Harris ([e-mail])

Abstract

This BRC specifies a payload variant for the BRC-124 multicast frame format in which the transaction payload uses the BRC-30 Extended Format (EF) instead of the BRC-12 raw transaction format. The 92-byte BRC-124 header is unchanged; the payload is self-identifying via the BRC-30 EF marker. This enables multicast receivers and broadcast services to fully validate transaction signatures and fee amounts without external UTXO lookups.

Copyright

This BRC is licensed under the Open BSV License.

Motivation

BRC-124 frames carry BSV transactions in BRC-12 raw format, which omits the locking scripts and satoshi amounts of spent inputs. Validating signatures or computing fees from a BRC-12 payload requires an external UTXO lookup — a bottleneck that BRC-30 was specifically designed to eliminate.

By defining BRC-124 frames with BRC-30 Extended Format payloads, multicast infrastructure gains:

1. Self-contained validation — receivers can verify all input signatures and compute exact fee amounts from the frame payload alone, with no UTXO index dependency.

2. Zero header changes — the BRC-124 header (Frame Version 0x02, 92 bytes) is reused as-is. The EF marker embedded in the payload provides unambiguous format detection. No frame version bump is required.

3. Transparent infrastructure — proxies, retry endpoints, and listeners treat the payload as opaque bytes. Existing multicast infrastructure forwards BRC-128 frames without modification.

4. Coexistence — BRC-124 frames with BRC-12 payloads and BRC-128 frames with BRC-30 EF payloads share the same multicast groups, frame version, and processing pipeline.

Specification

Frame Structure Overview

A BRC-128 frame consists of a standard 92-byte BRC-124 header followed by a variable-length payload containing a BRC-30 Extended Format transaction. The header is identical to BRC-124 in every respect — same field layout, same Frame Version byte (0x02), same alignment.

Header Format (92 bytes)

The header is defined by BRC-124 and reproduced here for reference:

Offset	Size	Alignment	Field	Description
0	4	—	Network Magic	0xE3E1F3E8 (BSV mainnet P2P magic)
4	2	—	Protocol Version	0x02BF (703, BSV large-block baseline)
6	1	—	Frame Version	0x02
7	1	—	Reserved	Must be 0x00
8	32	8-byte	Transaction ID	Raw 256-bit TXID (internal byte order)
40	8	8-byte	HashKey	Stable per-flow XXH64 identifier; 0 = unstamped
48	8	8-byte	SeqNum	Monotonic per-flow counter (starts at 1); 0 = unstamped
56	32	8-byte	Subtree ID	32-byte batch identifier; zeros = unset
88	4	8-byte	Payload Length	uint32 BE
92	*	—	Payload	BRC-30 Extended Format transaction bytes

All header fields retain the semantics defined in BRC-124. The only difference from a BRC-124 frame is the payload format.

Payload Format (BRC-30 Extended Format)

The payload is a BSV transaction serialized in the BRC-30 Extended Format. The format is summarized here; see BRC-30 for the full specification.

EF Transaction Structure

Field	Description	Size
Version no	Transaction version, currently 2	4 bytes (LE)
EF marker	Extended Format marker	6 bytes: 0x00 0x00 0x00 0x00 0x00 0xEF
In-counter	Number of inputs (VarInt)	1–9 bytes
list of inputs	Extended Format input structures	variable
Out-counter	Number of outputs (VarInt)	1–9 bytes
list of outputs	Standard output structures	variable
nLocktime	Lock time	4 bytes (LE)

Extended Format Input Structure

Each input in an EF transaction appends the spent output's satoshi value and locking script after the standard input fields:

Field	Description	Size
Previous Transaction hash	TXID of the transaction the output was created in	32 bytes
Previous Txout-index	Index of the output (non-negative integer)	4 bytes
Txin-script length	VarInt	1–9 bytes
Txin-script / scriptSig	Unlocking script	bytes
Sequence_no	Sequence number	4 bytes
Previous TX satoshi output	Satoshi value of the spent output	8 bytes (LE)
Previous TX script length	VarInt	1–9 bytes
Previous TX locking script	Locking script of the spent output	bytes

Payload Format Detection

Receivers distinguish BRC-128 (EF) payloads from BRC-124 (BRC-12 raw) payloads by inspecting the first 10 bytes of the payload:

Payload bytes 0–3:   Transaction version (4 bytes LE) — typically 0x02000000
Payload bytes 4–9:   EF marker check
  - BRC-30 EF:       0x00 0x00 0x00 0x00 0x00 0xEF
  - BRC-12 raw:      VarInt input count (never matches the EF marker)

The 6-byte EF marker 0x000000000000EF is placed immediately after the 4-byte version number. In a BRC-12 raw transaction, bytes 4–9 contain the input count VarInt followed by the first bytes of the first input — a sequence that cannot produce the EF marker pattern. This makes detection unambiguous without any header-level signaling.

Why No Frame Version Bump

The Frame Version byte remains 0x02 for the following reasons:

1. Self-identifying payload — BRC-30 was explicitly designed with the EF marker for format detection. A header-level signal is redundant.

2. Consistent BSV precedent — BRC-62 (BEEF), BRC-95 (Atomic BEEF), and BRC-96 (BEEF V2) all use payload-level markers for format discrimination rather than outer envelope version numbers.

3. Non-breaking — existing infrastructure (frame.Decode, TCP reader, proxy forwarder, retry endpoint cache) treats the payload as opaque bytes. A new frame version would cause all deployed components to reject frames (ErrBadVer) until updated, with no structural benefit.

4. Version semantics — Frame Version 0x01 → 0x02 changed the header from 44 to 92 bytes. A version bump should signal a header structure change, not a payload format change.

Compatibility

BRC-128 frames are fully compatible with the existing multicast infrastructure:

• Proxy — forwards BRC-128 frames verbatim, stamps HashKey and SeqNum as usual. The proxy does not inspect the payload.

• Listener — decodes the BRC-124 header, applies shard and subtree filters, tracks gaps via SeqNum per flow. Payload format is irrelevant to these operations.

• Retry endpoint — caches and retransmits BRC-128 frames identically to BRC-124 frames. The cache indexes by (HashKey, SeqNum), not payload content.

• Downstream consumers — applications that receive forwarded frames inspect payload bytes 4–9 to determine whether to parse as BRC-12 raw or BRC-30 EF.

BRC-124 (BRC-12 payload) and BRC-128 (BRC-30 EF payload) frames can be intermixed on the same multicast group without conflict.

TCP Transport

TCP transport is unchanged from BRC-124. The reader:

1. Reads 44 bytes (sufficient for legacy header or BRC-124 header start)

2. Inspects byte 6 (Frame Version)

   • Version 0x01 (legacy): header complete; read PayLen at bytes 40–43

   • Version 0x02 (BRC-124/BRC-128): read 48 more bytes; read PayLen at bytes 88–91

3. Reads exactly PayLen bytes

4. Processes the complete frame

The receiver determines the payload format (BRC-12 vs BRC-30 EF) after reading the payload, not from the header.

Examples

BRC-128 Frame Hex Dump

A frame carrying a BRC-30 EF transaction. The payload begins with the 4-byte version and 6-byte EF marker:

// Header (92 bytes) — identical to BRC-124
E3E1F3E8                                                          // Network Magic
02BF                                                              // Protocol Version
02                                                                // Frame Version (0x02 — same as BRC-124)
00                                                                // Reserved
11c6900eee6e68d191cd25034a5f872ed29e3b69273906a10e021f39ed866471  // TXID
A1B2C3D4E5F6A7B8                                                  // HashKey (XXH64 of flow)
0000000000000001                                                  // SeqNum (1)
baadf498a00ca5a44d1c4d9d103b49017f53cd8cb2a70a9c67fc884ecdd622b5  // Subtree ID
00000130                                                          // Payload Length (304)

// Payload (304 bytes of BRC-30 Extended Format transaction)
02000000                                                          // TX version (2, LE)
0000000000EF                                                      // EF marker
01                                                                // Input count (1)
// Extended Format input:
aabb...0000                                                       // Previous TX hash (32 bytes)
00000000                                                          // Previous Txout-index
6a47...3e76                                                       // scriptSig (VarInt length + script)
FFFFFFFF                                                          // Sequence number
3E66000000000000                                                  // Previous TX satoshi output (LE, 26174 sats)
1976...c288                                                       // Previous TX locking script (VarInt + script)
// Outputs:
01                                                                // Output count (1)
3C66000000000000                                                  // Output value (LE, 26172 sats)
1976...c288                                                       // Locking script (VarInt + script)
00000000                                                          // nLocktime

BRC-124 Frame Hex Dump (for comparison)

The same transaction in BRC-12 raw format (without extended input data):

// Header (92 bytes)
E3E1F3E8                                                          // Network Magic
02BF                                                              // Protocol Version
02                                                                // Frame Version
00                                                                // Reserved
11c6900eee6e68d191cd25034a5f872ed29e3b69273906a10e021f39ed866471  // TXID
A1B2C3D4E5F6A7B8                                                  // HashKey (XXH64 of flow)
0000000000000001                                                  // SeqNum (1)
baadf498a00ca5a44d1c4d9d103b49017f53cd8cb2a70a9c67fc884ecdd622b5  // Subtree ID
000000C8                                                          // Payload Length (200)

// Payload (200 bytes of BRC-12 raw transaction)
0200000001...00000000

Note that the headers are byte-identical; only the payload differs.

References

• BRC-12: Raw Transaction Format — Standard transaction payload format

• BRC-30: Transaction Extended Format (EF) — Extended Format payload used by this specification

• BRC-74: BSV Unified Merkle Path (BUMP) Format — Merkle proof format for transaction verification

• BRC-119: SubTree Unified Merkle Path (STUMP) Format — Defines the Subtree ID concept referenced in the frame header

• BRC-124: Multicast Transaction Frame Format — Header format reused by this specification