> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/brc/transactions/0128.md). # Multicast Extended Transaction Frame Format Jeff Harris () ## 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](/brc/transactions/0124.md) 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](/brc/transactions/0030.md) 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](/brc/transactions/0012.md) — Standard transaction payload format * [BRC-30: Transaction Extended Format (EF)](/brc/transactions/0030.md) — Extended Format payload used by this specification * [BRC-74: BSV Unified Merkle Path (BUMP) Format](/brc/transactions/0074.md) — Merkle proof format for transaction verification * [BRC-119: SubTree Unified Merkle Path (STUMP) Format](/brc/transactions/0119.md) — Defines the Subtree ID concept referenced in the frame header * [BRC-124: Multicast Transaction Frame Format](/brc/transactions/0124.md) — Header format reused by this specification --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://hub.bsvblockchain.org/brc/transactions/0128.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.