Ty Everett ([email protected])
This document outlines the BRC-8 standard for Everett-style Transaction Envelopes. The standard defines the structure and format of the envelopes used to send Bitcoin transactions. The primary goal of this standard is to ensure interoperability between different Bitcoin wallet software and services, allowing them to exchange transaction data in a consistent manner. This standard also aims to facilitate the implementation of the Simplified Payment Verification (SPV) process, as defined in BRC-9, by providing a standardized methodology for exchanging merkle proofs and input transactions.
The use of Bitcoin as a means of payment and store of value has gained significant traction in recent years. As the adoption of Bitcoin continues to increase, there is a need for a standard format for the envelopes that contain Bitcoin transactions. The lack of a standardized format for envelopes can lead to interoperability issues and hinder the development of new Bitcoin-native applications.
The SPV process, outlined in BRC-9, allows payment recipients to verify the validity of a transaction without downloading and verifying the entire blockchain. However, without a standard methodology for exchanging the required merkle proofs and input transactions, applications and businesses are unable to fully benefit from adopting SPV. BRC-8 addresses this issue by providing a consistent format for transaction envelopes that can be used for SPV.
We specify that the Everett-style Transaction Envelope is a JSON object that consists of the following fields:
rawTx(required): The BRC-12 hex transaction contained in the envelope in serialized hex string format.inputs(required unlessproofis provided): An object whose keys are TXIDs of each of the outpoints spent by the transaction. The values are objects containing:rawTx(required): The transaction that was spent in serialized hex string format.proof(required unlessinputsis provided): If the transaction is confirmed in a block, the SPV proof of the transaction's inclusion is given in BRC-10 format as a JSON object.mapiResponses(optional): An array of signed mAPI response objects, each of which is an object conforming to the mAPI specifications (either a successful broadcast acknowledgment or an affirmative status response).inputs(optional): If the transaction is not yet confirmed in a block, this field is the same as the field from the root object, except referring to the previous transaction instead of the root transaction. The field nests recursively back in the tree of the previous unconfirmed transactions until each of the branches can ultimately be traced back to the chain of blocks with aproofat the end.
proof(optional): If the root transaction in the envelope is already confirmed in a block, the SPV proof of the transaction’s inclusion is given in BRC-10 format as a JSON object.mapiResponses(optional): An array of signed mAPI response objects, each of which is an object conforming to the mAPI specifications (either a successful broadcast acknowledgment or an affirmative status response).headers(optional): An array of 80-byte block header strings in hex format, starting with the block after the recipient's latest known block (indicated and communicated out-of-band) and ending with the latest header known to the sender.pruned: true(optional): Indicates references to the same TXID are omitted in the inputs object, known as deduplication.
The inputs object is required unless the proof field is provided for the transaction. The inputs object can be used to create a tree data structure that nests recursively back in the tree of the previous unconfirmed transactions until each of the branches can ultimately be traced back to the chain of blocks with a proof at the end. The inputs object is optional when the transaction is already confirmed in a block and proof field is provided. The proof field serves as the proof of the transaction's inclusion in a block and is given in BRC-10 format as a JSON object.
The mapiResponses field is an array of signed mAPI response objects that are optional as per this specification, but may be required by higher-layer payment protocols such as BRC-29. If included, it should be omitted if proof is given. mAPI responses provide assurance that the transaction has been accepted and broadcast to multiple miners, making double-spend attacks harder to achieve.
The headers field is an optional array of 80-byte block header strings in hex format. This field can be omitted if no new headers are necessary for verification. The mechanism by which the parties negotiate about which headers are to be provided is beyond the scope of this specification.
The Everett-style Transaction Envelope uses a tree structure instead of a flat list structure to avoid providing information for the same transaction more than once. The tree structure has advantages as it can easily be validated with a simple recursive function, allowing parallelized processing of nodes further back in the tree at the same time as parents without needing to keep and reference a copy of the entire envelope while validating each node. This approach also allows for a degree of modularity because each node in the tree is itself a fully-valid envelope, and there is no need to re-scan and re-calculate which other transactions would be required to get a valid sub-envelope (very efficient for adding/removing/working with chains of dependent transactions).
A special case can be added when nodes at different depths in the tree depend on a common transaction, to remove tree-level duplications. The first time a transaction appears, it can be included as normal. Subsequent references to the same TXID can be omitted where they appear in the inputs object. To indicate that an envelope has been deduplicated in this way, the root object MUST contain pruned: true. With the issue of duplication solved, we believe a tree structure is the most intuitive and efficient approach.
The use of mAPI is optional and can be disabled by those who do not wish to use it in their implementations. Disabling mAPI allows “receiver-only broadcast” implementations to work. By not allowing mAPI as part of the data structure, the control is taken away from application developers and stakeholders who have widely varying requirements.
There are a wide array of potential applications, higher-layer payment protocols and use-cases for these envelopes. We stipulate that many systems will append (or even remove) certain fields from various nodes in these structures. This specification defines a baseline, and deviations from this baseline need only be documented by other standards which inherit from this one, such as BRC-29.
A web tool has been implemented which, given any TXID, will produce a valid Everett-style Transaction Envelope.
Developers are encouraged to create their own implementations and contribute to the ecosystem by sharing their work with the community. By doing so, they can help improve the interoperability between different Bitcoin wallet software and services, and further promote the adoption of the BRC-8 standard.
In addition to the web tool, developers should consult the BRC-9 and BRC-10 specifications for more information on implementing the Simplified Payment Verification (SPV) process and the format for SPV proofs, respectively. By adhering to these specifications, developers can ensure their implementations are compatible with existing and future Bitcoin wallet software and services that also follow the BRC standards.
While this standard provides a solid foundation for Everett-style Transaction Envelopes, there is always room for improvement and expansion. Future work could include:
- Developing more efficient algorithms for constructing and validating the tree structure of transaction envelopes.
- Expanding on the negotiation process for providing block headers, making it more seamless and efficient.
- Creating additional tools and libraries to simplify the implementation of the BRC-8 standard in various programming languages and platforms.
- Defining higher-layer protocols for live-updating non-final transactions, peer-to-peer data exchange, and efficient tree state reconciliation.