Multicast Transaction Frame Format

Jeff Harris ([email protected])

Abstract

This BRC specifies the wire format for transporting BSV transactions over IPv6 multicast and TCP/UDP unicast. The format extends the legacy BRC-12 frame with additional fields for sequence tracking, subtree identification, and sender attribution. All fields are 8-byte aligned for efficient memory access on 64-bit architectures.

Copyright

This BRC is licensed under the Open BSV License.

Motivation

As BSV transaction throughput scales to billions of transactions per second, efficient distribution infrastructure becomes critical. IPv6 multicast provides a scalable one-to-many transport mechanism, but globally scalable transaction distribution requires:

1. Deterministic sharding — routing transactions to specific multicast groups based on transaction ID

2. Sequence tracking — detecting and recovering from frame loss via NACK-based retransmission

3. Subtree identification — filtering batches of related transactions at the network layer

4. Sender attribution — identifying the original sender for per-sender gap tracking

This frame format addresses these requirements while maintaining compatibility with the existing BRC-12 transaction payload format. It uses a 92-byte header that provides the metadata necessary for high-throughput multicast distribution with best-effort reliability, complementing the legacy 44-byte header defined in BRC-12.

Specification

Frame Structure Overview

A frame consists of a 92-byte header followed by a variable-length payload containing a BRC-12 raw transaction. All multi-byte integers are big-endian. Fields at offsets 8, 48, 56, and 88 are 8-byte aligned; other fields maintain 4-byte alignment or natural alignment.

Header Format (92 bytes)

| 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     | 4    | 8-byte    | Sender ID             | CRC32c of source IPv6 address; `0` = unset     |
| 44     | 4    | —         | Sequence ID           | Random temporal flow identifier; `0` = unset   |
| 48     | 4    | 8-byte    | Sequence Number       | Monotonic sender counter; `0` = unset          |
| 52     | 4    | —         | Reserved              | Must be `0x00`                                 |
| 56     | 32   | 8-byte    | Subtree ID            | 32-byte batch identifier; zeros = unset        |
| 88     | 4    | 8-byte    | Payload Length        | `uint32` BE                                    |
| 92     | *    | —         | Payload               | BRC-12 raw transaction bytes                   |

Field Definitions

Network Magic (bytes 0–3)

The value 0xE3E1F3E8 (BSV mainnet P2P network magic). This enables standard BSV firewall rules and network monitoring tools to correctly classify shard frames. Frames with incorrect magic are rejected.

Protocol Version (bytes 4–5)

The value 0x02BF (703 in decimal), representing the BSV node protocol version that introduced the large-block policy. This field is informational; receivers do not validate it.

Frame Version (byte 6)

The value 0x02 for frames following this specification. The legacy format defined in BRC-12 uses 0x01 (see Compatibility section). Any other value causes the frame to be rejected.

Reserved (byte 7)

Must be 0x00. Reserved for future protocol extensions.

Transaction ID (bytes 8–39)

The 32-byte transaction hash in internal byte order (as used in BSV P2P protocol), not the reversed display order used by block explorers.

Sender ID (bytes 40–43)

A 32-bit CRC32c checksum of the source IPv6 address, computed using the Castagnoli polynomial (0x1EDC6F41). The checksum enables per-sender gap tracking and retransmission request routing while minimizing header overhead.

Computation:

senderID = CRC32c(ipv6AddressBytes)

Where ipv6AddressBytes is the 16-byte IPv6 address in net.IP.To16() format:

• Native IPv6 sources: the 16-byte IPv6 address

• IPv4 sources: IPv4-mapped IPv6 address (::ffff:a.b.c.d)

This field is stamped in-place by senders, ingress proxies, or retry endpoints before forwarding. A value of 0 indicates the field is unset.

Collision Risk: With 4 bytes (32 bits), the probability of collision among n senders is approximately n²/2³³. Given BSV's mining economics (10-minute block interval, difficulty retargeting), the network supports at most ~1,000 concurrent miners, with 12–20 core transaction processor nodes handling the majority of traffic. At 1,000 senders, collision probability is ~0.01% (1 in 10,000); at 100 senders, it is negligible (~0.0001%). Operators should use per-sender Sequence ID spaces to further disambiguate transaction flows.

Sequence ID (bytes 44–47)

A 32-bit unsigned integer (big-endian) containing a random temporal flow identifier assigned by the sender. Combined with Sender ID and Sequence Number, it uniquely identifies a sequenced flow for retransmission requests. Senders reset this value periodically (e.g., every ~4 million frames or ~10 minutes). All-zero bytes indicate the field is unset.

Sequence Number (bytes 48–51)

A 32-bit unsigned integer (big-endian) containing a monotonic counter assigned by the sender. Increments by 1 for each frame in a flow, wrapping at 2³²−1 (4,294,967,295). Used by receivers to detect gaps and trigger NACK-based retransmission. A value of 0 indicates the field is unset.

Reserved/Padding (bytes 52–55)

Must be 0x00000000. Reserved for future protocol extensions. Provides 8-byte alignment for Subtree ID field.

Subtree ID (bytes 56–87)

A 32-byte opaque batch identifier. A subtree is an ordered set of related transactions sharing a common batch context. This field enables downstream subscribers to filter frames by batch at the application layer. All-zero bytes indicate the field is unset.

Payload Length (bytes 88–91)

A 32-bit unsigned integer (big-endian) specifying the number of payload bytes immediately following the header. It is up to the application to determine the maximum allowed payload size.

Payload (byte 92 onward)

Raw serialized BSV transaction in BRC-12 format: version (4 bytes LE) + input vector + output vector + locktime (4 bytes LE). No additional envelope wraps the transaction.

Alignment Verification

| Field                 | Offset | Offset % 8 |
|-----------------------|--------|------------|
| Transaction ID        | 8      | 0 ✓        |
| Sender ID             | 40     | 0 ✓        |
| Sequence ID           | 44     | 4          |
| Sequence Number       | 48     | 0 ✓        |
| (Reserved/Padding)    | 52     | 4          |
| Subtree ID            | 56     | 0 ✓        |
| Payload Length        | 88     | 0 ✓        |
| Payload               | 92     | 4          |

Compatibility with BRC-12 Legacy Format

Legacy BRC-12 frames (Frame Version 0x01) use a 44-byte header with no sequence or subtree fields:

| Offset | Size | Field                           |
|--------|------|---------------------------------|
| 0      | 4    | Network Magic                   |
| 4      | 2    | Protocol Version                |
| 6      | 1    | Frame Version (`0x01` = legacy) |
| 7      | 1    | Reserved                        |
| 8      | 32   | Transaction ID                  |
| 40     | 4    | Payload Length                  |
| 44     | *    | Payload                         |

TCP Transport

When transported over TCP, frames are concatenated end-to-end with no additional envelope. 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): read 48 more bytes; read PayLen at bytes 88–91

3. Reads exactly PayLen bytes

4. Processes the complete frame

Error Handling

| Condition                | UDP Behavior  | TCP Behavior      |
|--------------------------|---------------|-------------------|
| Bad magic                | Silent drop   | Connection closed |
| Unknown frame version    | Silent drop   | Connection closed |
| Payload length too large | Silent drop   | Connection closed |
| Truncated datagram       | Silent drop   | Connection closed |

Examples

BRC-124 Frame Hex Dump

A frame following this specification carrying a 200-byte transaction:

// Header (92 bytes)
E3E1F3E8                                                          // Network Magic
02BF                                                              // Protocol Version
02                                                                // Frame Version
00                                                                // Reserved
11c6900eee6e68d191cd25034a5f872ed29e3b69273906a10e021f39ed866471  // TXID
A1B2C3D4                                                          // Sender ID (CRC32c of IPv6)
00000001                                                          // Sequence ID (flow identifier)
000004D2                                                          // Sequence Number (1234)
00000000                                                          // Reserved/Padding
baadf498a00ca5a44d1c4d9d103b49017f53cd8cb2a70a9c67fc884ecdd622b5  // Subtree ID
000000C8                                                          // Payload Length (200)

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

Legacy Frame Hex Dump

The same transaction in legacy (BRC-12) format:

// Header (44 bytes)
E3E1F3E8                                                          // Network Magic
02BF                                                              // Protocol Version
01                                                                // Frame Version (0x01 = legacy)
00                                                                // Reserved
11c6900eee6e68d191cd25034a5f872ed29e3b69273906a10e021f39ed866471  // TXID
000000C8                                                          // Payload Length (200)

// Payload (200 bytes)
0200000001...00000000

References

• BRC-12: Raw Transaction Format — Payload format for transaction data

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

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

• bitcoin-shard-common — Reference implementation (Go)

Constants Reference

| Name               | Value      | Hex          | Description                   |
|--------------------|------------|--------------|-------------------------------|
| `MagicBSV`         | 3811983336 | `0xE3E1F3E8` | BSV mainnet P2P magic         |
| `ProtoVer`         | 703        | `0x02BF`     | Protocol version              |
| `FrameVerLegacy`   | 1          | `0x01`       | Legacy BRC-12 frame version   |
| `FrameVerBRC124`   | 2          | `0x02`       | Current BRC-124 frame version |
| `HeaderSizeLegacy` | 44         | `0x2C`       | Legacy header size in bytes   |
| `HeaderSize`       | 92         | `0x5C`       | BRC-124 header size in bytes  |

Implementations

• Go: bitcoin-shard-common/frame — Encode(), Decode(), wire constants

• Services: bitcoin-shard-proxy, bitcoin-shard-listener, bitcoin-multicast — Network multicast infrastructure