LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Specification
  • Validation Semantics
  • Discussion of Alternatives
  • A1: Why not just send multiple beefs with one rooted transaction in each?

Was this helpful?

Edit on GitHub
Export as PDF
  1. Transactions

BEEF V2 Txid Only Extension

PreviousAtomic BEEF TransactionsNextBitcoin Script Binary, Hex and ASM Formats

Last updated 5 months ago

Was this helpful?

Tone Engel (tone@projectbabbage.com)

Abstract

The BEEF serialization format (as defined in ) is essentially two things:

  1. An array of mined transaction proof validation data (BUMPS )

  2. 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:

  1. In the general case, a BEEF does not need to be a single transaction tree.

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

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

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.

All of the BUMPs required to prove inclusion of inputs in longest chain of blocks

Format 00 or 01: RawTx bytes as in standard format

BRC-62
BRC-74
BRC-74
BRC-12