BEEF V2 Txid Only Extension
Two parties who have already exchanged proofs for a transaction resend all of it every time it comes up again. This lets a bundle name a transaction the other side already has instead of repeating it.
Summary
- Why
- Re-sending full transaction data and proofs for transactions both parties already trust wastes space and time, especially in fast-moving or large transaction chains.
- What
- BRC-96 is an extension to the BEEF transaction bundle format that lets a transaction be represented by just its 32-byte transaction hash (txid) instead of its full raw data and proof.
- How
- A developer marks a transaction entry in the bundle with a Tx Data Format byte of 02 and writes only the 32-byte txid in reverse byte order, skipping the raw transaction bytes and any merkle proof, while still keeping parent transactions ordered before the children that spend their outputs.
What this lets you do
- Reference a transaction by txid only, skipping raw bytes and proof data
- Treat txid-only transactions as already validated by both parties
- Build bundles containing multiple transaction trees instead of just one
- Avoid re-transmitting large or previously verified transaction data
- Chain new inputs to txid-only parents while keeping valid ordering
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-96 accurately, including what it depends on.
The specification
Abstract
The BEEF serialization format (as defined in BRC-62) is essentially two things:
- An array of mined transaction proof validation data (BUMPS BRC-74)
- An array serialized Bitcoin transactions
In practical use, BEEFs are exchanged between parties to build and process new transactions as well as validate arbitrary data recorded on the blockchain.
The extension proposed here is to allow for "agreed upon transactions" to be represented in the array of transactions as just their transaction hash (txid),
This avoids the need to include potentially significant amounts of data already known to the parties exchanging BEEFs.
In addition, this extension formally acknowledges that a BEEF may contain mulitple transaction "roots".
Motivation
Consider when two parties cooperate over a short amount of time to construct one or more transactions.
Inputs may be added by either party. New inputs may come from unmined and mined transactions.
At each exchange of information along this process, one party sends a BEEF to the other to validate the new inputs or transaction(s) they originate.
The BEEF standard is well suited to this with two extensions:
- In the general case, a BEEF does not need to be a single transaction tree.
- A method of referencing what the process has previously validated.
For example, when adding new inputs to an incomplete transaction, the set of source transactions for these inputs may need to be transmitted to a second party. A BEEF of this validation information might include multiple trees of unmined transactions.
Furthermore, some of these inputs might be from transactions created earlier in the process for which complete validation data - back to mined transactions - has already been shared.
Consider in particular if some of these transactions are truly large or if the rate of linked transaction generation is high.
Specification
The serialized format for the transaction array is updated and the BEEF version number is incremented to 0200BEEF.
For each serialized transaction, the byte previously used to indicate BUMP (01) or no BUMP (00) is renamed the Tx Data Format,
it is now the first thing written for each transaction,
and the value of (02) is now used when only a 32 byte txid is serialized.
| Field | Description | Size |
|---|---|---|
| Version no | Version number starts at 4022206466, encoded Uint32LE => 0200BEEF | 4 bytes |
| nBUMPs | VarInt number of BSV Unified Merkle Paths which follow | 1-9 bytes |
| BUMP data | All of the BUMPs required to prove inclusion of inputs in longest chain of blocks BRC-74 | many bytes x nBUMPs |
| nTransactions | VarInt number of transactions which follow | 1-9 bytes |
| Tx Data Format | 00 raw transaction without BUMP index; 01 raw transaction followed by BUMP index; 02 txid only | 1 byte |
| BUMP index | Format 01: VarInt index number indicating the BUMP to which Raw Transaction belongs. | 1-9 bytes |
| Raw Transaction | Format 00 or 01: RawTx bytes as in standard format BRC-12 | many bytes |
| txid only | Format 02: 32 byte transaction hash in reverse byte order | 32 bytes |
Validation Semantics
A txid only transaction is treated as implicitly valid, no raw transaction or BUMP index is included and no BUMP data is required.
Additional transactions that consume outputs from a txid only transaction treat those inputs as fully validated.
The ordering of transactions obeys the V1 rules: Parents, including txid only, must occur before children.
Discussion of Alternatives
A1: Why not just send multiple beefs with one rooted transaction in each?
The essential function of the BEEF format is to efficiently represent transaction validation data.
When multiple beefs are merged, all common BUMPS, merkle paths, and parent transactions are collapsed to a single copy.