Ty Everett ([email protected])

Abstract

The BRC-9 specification defines a process for Simplified Payment Verification (SPV) that allows payment recipients to verify the validity of a transaction without downloading and verifying the entire blockchain. The process involves verifying the headers and proofs of a BRC-8 Transaction Envelope, ensuring that all SPV proofs link back to the genesis block and the chain with the most proof of-work, and confirming that the transaction is valid according to the rules of Bitcoin. This standard aims to facilitate fast, secure, and efficient payment processing for merchants and users.

Motivation

The Bitcoin blockchain is a decentralized, distributed ledger that records every transaction on the network. However, downloading and verifying the entire blockchain can be time-consuming and resource-intensive, making it impractical for users who want to make quick, simple transactions. Simplified Payment Verification (SPV) provides a way for payment recipients to verify the validity of a transaction without the need for a full blockchain download. This protocol is essential for enabling fast and efficient payment processing, especially for small, casual transactions.

Specification

The steps for verifying the validity of a payment transaction using the BRC-9 SPV protocol are as follows:

1. Ensure that the received Envelope is in the correct format

2. Add any previously-unknown headers provided in the Envelope to the chain of headers

3. Ensure that all SPV proofs link back to the genesis block and the chain with the most proof of-work

The above steps ensure that the transaction is valid and secure according to the Bitcoin protocol. Merchants may take additional measures to increase security, such as subscribing to mAPI status updates and double spend notifications, verifying the identity of the sender, waiting for confirmations, or using an escrow service.

Implementation

Any wallet that has access to a source of block headers is capable of verifying merkle proofs, and any computer with the resources needed to execute the Bitcoin script programs from the chain of spends is capable of verifying the chain of custody. This means that almost any modern digital computer can easily perform Simplified Payment Verification by following the steps outlined in this document.

Ty Everett ([email protected])

Abstract

The BRC-46 architecture for digital assets stored within wallet baskets enables a wide range of use cases. However, it lacks support for more than a rudimentary permission system. Wallets can grant applications blanket access to basketed assets, or deny access entirely, but cannot make insightful decisions based on the specific assets stored, their output scripts, or the tokenized value they represent. To support the future development of new permission schemes covering fungible and non-fungible digital assets within wallets, we propose reserving certain basket identifiers to prevent their use by applications and ensure compatibility with future standards.

Motivation

The motivation for this proposal is to future-proof the architecture by enabling the seamless integration of new permission schemes applicable to assets stored in or retrieved from wallet-managed UTXO baskets. By specifying reserved identifiers, we can ensure that new security and permission paradigms can be implemented without conflicts or unintended behavior.

Specification

To accommodate future basket permission schemes, wallets must reject any operation requests made under basket IDs beginning with p (a lowercase “p” followed by a space).

Future Scheme Identifiers

Future permission schemes must define their ID formats, as follows:

• The scheme IDs cannot contain spaces.

• The basket IDs must start with p , followed by the scheme ID, a space, and the rest of the basket identifier.

Example Format

A basket ID such as p dollarToken xxxxx could represent a specific token type (e.g., tokenized dollars), where:

• p designates an alternative permission scheme.

• dollarToken identifies the permission scheme.

• xxxxx forms the basket ID under the alternative scheme.

Basket ID Parsing and Rules

Wallets must differentiate between standard and alternative permission schemes by recognizing the p prefix followed by a distinct, space-free scheme ID. To ensure unambiguous parsing.

Upon recognizing a basket ID structured as p <scheme ID> <rest of the ID>, wallets may apply the specific rules defined by the scheme associated with the scheme ID. These rules could define:

• Constraints based on specific locking scripts or script templates of UTXOs.

• The conditions under which operations can be executed.

• Mechanisms for allowing applications to access only a certain set number of only a specific asset type, according to the rules of some tokenization protocol, overlay service or script template.

• Specific counterparty requirements and other customizable permission attributes.

Reserved Structure

To maintain clarity and prevent conflicts:

• Basket IDs beginning with p must be reserved for future use.

• Wallets must reject operations involving such IDs unless they explicitly support the scheme ID.

• A space must immediately follow the scheme ID to separate it from other elements.

Extensibility Beyond Current Paradigms

This specification allows future permission schemes to extend beyond current models (e.g. paradigms), enabling flexible and innovative wallet permissions that evolve with user and application needs.

For example, a wallet could allow access to a maximum of 10 dollars of tokenized fiat money per month within an application.

Conclusion

By reserving basket IDs starting with p and specifying rules for future permission schemes,this specification ensures forward compatibility and robust wallet permission functionalities. It enables seamless integration of new schemes without disrupting existing applications or introducing parsing ambiguities.

Jane Doe ([email protected])

Abstract

This proposal introduces an absurd, humorously impractical method for controlling embedded Bitcoin wallets in web-based applications using the power of bananas.

The Abstract section should concisely describe your proposal at a high-level.

Motivation

The purpose of this proposal is to provide a lighthearted example of how to create a standard that adheres to the BRC format while sparking laughter and enjoyment among readers.

The Motivation section should let people know the context for your proposal, and why it was written.

Specification

1. Wallets must be embedded within a real banana fruit, using cutting-edge bio-organic engineering techniques.

2. Web-based applications must communicate with the banana-embedded wallet using a Banana Communication Protocol (BCP) involving a series of gentle squeezes.

3. Squeezes will be translated into binary code, with a short squeeze representing '0' and a long squeeze representing '1'.

The Specification section of your proposal should stipulate all information needed to implement the standard, and make up the bulk of the document. Generally, people should be able to create a compatible implementation with only the specification.

Implementations

1. Wallet developers must carefully select the finest bananas available, ensuring they are both ripe and durable.

2. A custom JavaScript library, BananaJS, must be developed for web-based applications to interact with the wallet using the BCP.

3. Wallet applications must include a sophisticated squeeze detection system to ensure accurate communication.

4. Wallet developers must implement a "peel screech" alarm system for added security.

The Implementations section should contain information about places where the standard is implemented, or examples of its implementation.

References

• 1: Doe, J. (2023). Banana-Powered Bitcoin Wallet Control Protocol: A Humorous Guide. Bananaverse Press.

• 2: Smith, T. (2022). The Art of Banana Communication (Volume IV): Avoiding Single Points of Failure in Banana Communications. FruitTech Publishing.

The References section should contain any footnotes used throughout the document.

Ty Everett ([email protected])

Abstract

This standard provides a script template that enables data-rich tokens on the Bitcoin SV blockchain, while still allowing for the representation of transfers of ownership. By pushing arbitrary data into stack elements and subsequently dropping them, followed by adding a simple P2PK lock, this script template allows for the creation of tokens with metadata, which can be exchanged on overlay networks. This standard facilitates improved scalability by representing tokens as UTXOs, which can be easily modeled and used in graph structures.

Motivation

The need for this standard arises from the growing demand for data-rich tokens in the ecosystem. Current tokenization methods such as OP_RETURN lack output spendability and representation of ownership, making them unsuitable for many use cases. This standard allows developers to push arbitrary data onto the stack, while still enabling ownership transfer with a simple P2PK lock. This feature facilitates improved scalability by representing tokens as UTXOs, which can be more easily modeled and used in graph structures. Use-cases for these tokens are numerous, ranging from deeds to cars to metadata-rich digital assets. While it does not purport to solve every use-case, such as those requiring complicated spending constraints, this standard is a crucial step in the direction of enabling more sophisticated data-rich tokenization on the Bitcoin network.

Specification

We specify that output scripts must first push data onto the stack, followed by using OP_DROP and OP_2DROP to drop the pushed data. Next, the public key of the owner of the token is pushed, followed by OP_CHECKSIG. The unlocking script comprises a digital signature from the owner's public key, which facilitates spending of the token. Each token output must contain at least one satoshi. This standard does not define specific forms of tokens or specific requirements for higher-order overlays with validation rules for their transfer and conveyance.

Example Output Script:

The following is an example output script for a token as defined by this standard:

Implementations

This script template has been implemented within the .

How it Works

This script template enables tokenization on the Bitcoin SV blockchain by providing a simple and effective way to create data-rich tokens that are still spendable and locked to their owners. This is achieved by pushing arbitrary data onto the stack, dropping it with OP_DROP or OP_2DROP, and then adding a simple P2PK lock with a public key and OP_CHECKSIG.

When a token is created using this template, it is represented as an unspent transaction output (UTXO) that contains at least one satoshi. This UTXO can then be transferred to another user by creating a transaction that spends the UTXO and includes the owner's digital signature in the unlocking script.

The template facilitates tokenization by allowing developers to specify any number of stack elements with arbitrary data, representing tokens on overlays, while still enabling spending and ownership with simple locks. This makes it easier to model and use tokens in graph structures, improving scalability and enabling a wide range of use-cases.

Abstract

Defining Simplified Payment Verification (SPV) without external reference for sake of clarity.

Motivation

Ty Everett ([email protected])

Abstract

We propose a peer-to-peer token exchange protocol under which two parties can securely exchange digital tokens (assets) within Bitcoin SV's BRC-22 UTXO-based Overlay Networks.

Ty Everett ([email protected])

Abstract

This document serves to clarify that there is no BRC-20 standard for tokenization on Bitcoin SV. While Ethereum has the ERC-20 standard for account-based tokens, there is no equivalent for UTXO-based systems such as Bitcoin SV. In order to avoid confusion and prevent people from conflating ERC-20 with BRC-20, it is necessary to clarify that BRC-20 does not exist on Bitcoin SV. Instead, proposals for tokenization should be judged on their own merits. Being associated with ERC-20 will not make any specific tokenization proposal better, and there is not a desire to confer greater legitimacy to one proposal or another.

Abstract

This BRC serves as a reference point for the TSC Merkle Proof Standardized Format. It is identified as BRC-10 and is used to avoid ambiguity in referring to the TSC standard, just like other proposals like (which revise or extend this proposal) are referenced by their BRC numbers.

Ty Everett ([email protected])

Abstract

In BRC-22 overlay networks, various forms of state tracking for UTXOs can be incorporated. Servers can track UTXOs according to many criteria, enabling many use-cases. There is no fundamental requirement that a server relies on strictly on-chain data for these operations. In this document, we explore the use of off-chain secrets and offset values, enabling private overlay networks to be tracked among transactions that, on the surface, appear only to be normal P2PKH spends. Various models will be explored, from overlay network secrets to data linkages revealed off-chain. All of these methodologies rely on the isomorphic properties of the curve, enabling the owners of the UTXOs to retain spendability rights even when the P2PKH outputs also contain other information stored within offsets from the root key. This information is used to make on-chain record of private, off-chain data, which can later be revealed.

Ty Everett ([email protected])

Abstract

This document proposes a solution for tracking transaction histories within UTXO-based overlay networks by extending the BRC-22 standard to include transaction inputs and the BRC-24 standard's query responses to include such data in extended BRC-36 input envelopes. By associating previous transaction inputs with topic-specific UTXOs and facilitating history traversal, it allows network participants to access a more complete record of UTXO histories. This standard outlines the parameters and steps needed to capture, maintain, and access historical transactional data in overlay networks.

Motivation

BRC-22 successfully enables the tracking and synchronization of UTXOs across various topics in overlay networks, yet it does not accommodate the preservation of UTXO histories which can hold valuable network data. Transaction histories are key to understanding the full lifecycle of UTXOs, acting as a crucial component for certain applications in areas like network analysis and auditability. The absence of a history tracking standard leads to information gaps, preventing a comprehensive understanding of network state changes. This document presents a solution to this problem by providing a clear and standardized mechanism for maintaining and accessing transaction histories in UTXO-based overlay networks.

Specification

We introduce extensions to the BRC-22 and BRC-24 standards to encapsulate the input history of network transactions. Topic managers in BRC-22 can now prescribe which transaction inputs should be conserved and linked with the admitted transaction outputs, designating inputs that are pertinent for tracking. The BRC-24 standard, meanwhile, is adjusted to support the retrieval of past renditions of UTXOs.

Changes to the BRC-22 Standard

Topic managers in overlay networks now perform the following additional steps:

• Verify the inputs from the transaction tagged with their topic labels to determine their relevance.

• Provide a return value back to the Confederacy node directing it to retain these relevant transaction inputs, so that the node can maintain them alongside admitted transaction outputs for the specified topic.

• Relative location metadata and other associated data should be stored by the Confederacy node along with these inputs, enabling efficient topic-specific historical data retrieval.

Changes to the BRC-24 Standard

The lookup services specified under BRC-24 can now:

• Accept queries for the previous renditions of specific UTXOs (formats for these queries depend on the specific lookup service).

• Assemble and return a responsive list comprising of the series of transactions that involve the queried UTXOs along their states across the network's history.

• Extend the BRC-36 envelope return format, including transactions as inputs when they contribute to the history of the queried UTXOs.

Implementation

Developers should adapt their existing BRC-22 based systems to collect and preserve pertinent transaction inputs when admitting new transaction outputs. Lookup services following the BRC-24 standard must be updated to handle queries for prior renditions of UTXOs and effectively traverse transactional histories, extending their BRC-36 envelope returns to incorporate key transaction input data for the queried UTXOs. By adhering to the changes specified in this document, network participants can ensure interoperability, efficient data access and complete historical tracking of UTXOs across overlay networks.

Ty Everett ([email protected])

Currently, there are only HTTPS URLs within SHIP and SLAP advertisements

This https: scheme indicates that, according to pre-defined rules (like headers and the /submit or /lookup paths), submission or lookups are facilitated over the HTTPS protocol.

However, sometimes we want to do things like:

• Authenticate users before accepting transactions or facilitating lookup

• Charge a payment for transaction submission, or pay the sender if a transaction is accepted

• Charge a payment for lookup queries

• Submit private or off-chain values alongside a transaction

• Submit non-final transactions that deal with interim states

• Facilitate real-time lookups with WebSocket or based on live / non-final transactions

• Advertise certain IPv6 capabilities and bridges

• Advertise non-HTTPS or non-internet communications systems like radio / JS8 Call

In these scenarios, other schemes can be used within the "protocol" portion of the URL.

For example, current SHIP/SLAP only contemplates URL schemes like https://example.com.

However, a new URL might be something like:

SHIP https+bsvauth+smf://example.com (HTTPS with BSV Auth and Service Monetization Framework enabled)

SHIP https+bsvauth+scrypt-offchain://example.com (HTTPS with BSV Auth and sCrypt off-chain values for transaction submission)

SHIP https+rtt://example.com (HTTPS with real-time transacting support, e.g. non-finals accepted)

SLAP wss://example.com (real-time event-listening live web-socket lookup response streaming)

SLAP js8c+bsvauth+smf:?lat=40&long=130&freq=40meters&radius=1000miles (lookup is advertised using JS8 Call protocol at a given set of GPS coordinates, a given frequency and radius, with BSV Auth and Service Monetization Framework enabled.

These new SHIP and SLAP schemes allow for the advertisement of new Overlay Services that have more advanced capabilities, including real-time updates from lookup services, non-final transaction submission, mutual authentication, payment, off-chain / private value submission, non-HTTP transport mechanisms, and much more.

Compared to plain HTTPS, they make a significant improvement. Facilitators for each of these custom "protocol" fields in the advertised SHIP/SLAP URLs can be implemented into standard libraries, the associated lookup services can be updated to facilitate querying by them, and new default SLAP trackers can be added so that users are able to stay connected in more ways than one.

Ty Everett ([email protected])

Abstract

We define a mechanism by which BRC-1 applications can denote UTXOs to be unlocked and redeemed by wallets as part of new Bitcoin transactions. We extend the message format defined by BRC-1 with information about the inputs requested by the application, including all information needed for a wallet to check the veracity of any inputs being redeemed.

Motivation

defines a mechanism for an application to request the creation of a Bitcoin transaction by a wallet, but it is incomplete without a way for applications to consume and use tokens that previously existed. Allowing applications to unlock and redeem inputs as part of their transactions also facilitates their ability to update, extend or delete assets that are tokenized within Bitcoin UTXOs.

Specification

We extend the Transaction Creation Request message with an additional field, the inputs field. This is an object whose keys are the TXIDs of transactions that contain outputs which are to be spent as part of this transaction, and whose values comprise extended transaction envelopes.

In addition to the normal envelope fields, we specify that these input envelopes contain an additional field called outputsToRedeem, which is an array of objects. Each of the objects comprises an output from the subject transaction that is to be redeemed and used as input to the transaction being requested by the application.

We specify that each of the objects in the array contains index and unlockingScript. The index value is an integer that denotes which output to redeem from the transaction, and the unlockingScript comprises a hex-formatted input script.

We further specify that each of the elements in each of the outputsToRedeem arrays may contain an additional spendingDescription string that describes the redemption of the tokens being used.

Example

Here is an example of a Transaction Creation Request object that contains an input:

Implementations

This functionality has been implemented as part of the , in the createAction function.

• Ty Everett ([email protected])

Abstract

BRC-65 extends the functionality of BRC-56 by introducing the ability to label Bitcoin transactions when they are created using the BRC-1 Transaction Creation Request. This extension allows applications to organize and categorize transactions for different purposes. BRC-65 also introduces the capability to list labeled transactions, providing applications with an easy way to retrieve specific sets of transactions based on their labels. This standardization improves interoperability between wallets and applications and enhances the user experience by enabling the display of transaction lists relevant to specific categories or actions.

Motivation

The motivation behind BRC-65 is to enhance the functionality of the Bitcoin wallet messaging layer defined in BRC-56 by introducing the ability to label transactions. This functionality allows applications to categorize and organize transactions based on specific criteria. By labeling transactions, applications can easily retrieve and display transaction lists that are relevant to specific actions or categories. This simplifies the user experience and enables users to quickly find, review, and analyze specific sets of transactions.

By defining a standard mechanism for labeling transactions and listing labeled transactions, BRC-65 promotes interoperability between wallets and applications. With this standardization, applications can expect consistent behavior across different wallets, making it easier for developers to create Bitcoin-powered applications without having to build custom wallet functionality. Furthermore, users can switch between wallets seamlessly without losing access to their labeled transactions.

Specification

BRC-65 extends the functionality of BRC-56 by introducing the concept of transaction labels and the ability to list labeled transactions. This extension adds two new features to the wallet-to-application messaging layer: labeling transactions at the point of creation and retrieving labeled transactions.

Transaction Labels

The labels field is introduced as an optional parameter next to the outputs array and description of the BRC-1 Transaction Creation Request in BRC-56. This field allows applications to label transactions. Each label must be no longer than 300 characters and can only contain letters, numbers, and underscores.

The updated Transaction Creation Request with the labels field is as follows:

In this example, the application is creating a transaction with the labels "payment" and "personal". These labels can be used to categorize and organize the transaction in a way that is meaningful to the application.

List Actions

BRC-65 introduces the listActions message (the Actions List Request) to retrieve a list of Bitcoin transactions based on their labels. The Actions List Request message takes the following parameters:

The Actions List Request message retrieves Bitcoin transactions that have been labeled with the specified label. The skip parameter allows applications to retrieve a subset of transactions by skipping a certain number of transactions from the beginning of the list. The limit parameter defines the maximum number of transactions to return. If skip and limit are not provided, the request will return all transactions with the specified label.

The Actions List Response comprises an array of BRC-8 Transaction Envelopes as defined in BRC-56, representing the labeled transactions, along with a totalActions field denoting the total number of transactions with the specified label.

An example Actions List Request message with the label "payment" and a limit of 10 transactions is as follows:

The corresponding Actions List Response would contain an array of BRC-8 Transaction Envelopes as well as the totalActions field:

In this example, the actions list response includes an array of BRC-8 Transaction Envelopes representing the labeled transactions with the label "payment". The totalActions field indicates that there are a total of 42 transactions with the "payment" label.

Implementations

Implementations of this specification will need to extend the existing wallet software in order to support the labeling of transactions and the listing of labeled transactions. Wallets will need to ensure that they can create transactions with labeled outputs and store the labels for future retrieval. Applications will need to handle the labeling of transactions and make use of the Actions List Request to retrieve labeled transactions.

Some existing implementations of BRC-56 may already support the labeling and listing of transactions, while others may need to update their software to include this additional functionality. The Babbage MetaNet Client, for example, has already implemented the Transaction Labels and List Actions functionality.

Ty Everett ([email protected])

Abstract:

This document proposes an examination of Unspent Transaction Outputs (UTXOs) as the central framework of tokenization in Bitcoin, justifying their usage based on their inherent simplicity, efficiency, and secure transfer processes. Through UTXOs, Bitcoin allows the delineation of rules governing the transfer of valuable tokens via scripting. In contrast to alternative tokenization proposals, UTXOs render the need for comprehensive, trusted indexing and chain scanning systems obsolete. Instead, transaction parties require only to validate transactions pertinent to them, employing miners to mitigate double-spend attempts, thus achieving tokenization of assets at scale.

Background:

Tokenization, in the realm of digital assets, represents the process of substituting valuable, real-world assets with digital tokens on a blockchain. Within the context of Bitcoin, tokenization predominantly revolves around Unspent Transaction Outputs (UTXOs).

Unspent Transaction Outputs (UTXOs) are remnants of Bitcoin transactions yet to be spent or used as inputs for newer transactions. Each UTXO in Bitcoin can be seen as a distinct token. Unlike other tokenization methods, UTXOs are directly transferred from sender to recipient, the legitimacy of which can be independently verified, thus significantly reducing computational and time complexities.

Scripts in Bitcoin define the conditions under which UTXOs can be spent. These conditions form the essence of token transfer rules, ensuring secure transactions of digital tokens.

Simplified Payment Verification (SPV) is a method used in Bitcoin for lightweight clients to verify transactions without requiring the entire blockchain's download. The process for SPV enables recipients to verify transfers quickly.

Argument: Benefits of UTXOs as the Fundamental Unit of Tokenization:

UTXOs offer a unique advantage as the foundational unit of tokenization in Bitcoin due to their inherent characteristics and the robustness they bring to the transaction system:

1. Decentralization and Trust Minimization: With UTXOs, parties need only to validate transactions that concern them, eliminating the necessity for a trusted intermediary to index and scan every transaction on the blockchain. This process enhances the decentralized nature of Bitcoin and minimizes trust requirements.

2. Scalability: By treating UTXOs as the base unit of tokenization, we can facilitate efficient asset tokenization at scale. With direct transfers, the UTXO model bypasses complex indexing systems, thus reducing computational overhead and increasing transaction speed.

3. Double-Spend Protection: Miners play an integral role in UTXO transactions by preventing double-spending. As each UTXO can only be spent once, miners verify and confirm that no UTXO is duplicated or spent twice, preserving the security of the blockchain.

In summary, the UTXO model provides an efficient and scalable framework for tokenization in Bitcoin, while upholding the principles of decentralization and trust minimization. Its distinctive attributes such as direct transfer, double-spend prevention, and simplified verification lend themselves to a secure and streamlined tokenization process, validating the assertion that UTXOs are the fundamental unit of tokenization in Bitcoin.

Abstract

The OP_FALSE OP_RETURN script template is a method for storing data on the Bitcoin SV blockchain. It creates a non-spendable output and appends the desired data to the end of the script for storage. This standard aims to define the rules and best practices for using this script template.

Motivation

The low transaction fees and high capacity of the Bitcoin SV network make it an attractive option for storing data on the blockchain. The OP_FALSE OP_RETURN script template is a widely used method for achieving this goal due to its simplicity and ease-of-use.

Specification

To use the OP_FALSE OP_RETURN script template, an output must be included in a Bitcoin transaction with a locking script comprising OP_FALSE followed by OP_RETURN, followed by the data to store in the script. The data can be pushed into one or multiple stack elements after the OP_RETURN opcode.

For example:

Implementations

Several implementations and protocols make use of the OP_RETURN script template, including the and .

Limitations

The main limitation of using OP_FALSE OP_RETURN is the non-spendability of these outputs and their ability to be pruned by miners. They are records rather than tokens. Artefacts predominantly as a proof of existence of data at a certain time - timestamped by the Bitcoin system as a hash with a merkleproof to a block, even if miners themselves prune the data.

• Ty Everett ([email protected])

Abstract

This BRC extends by adding the ability to remove specific outputs from a basket and delete digital certificates that are no longer required. Applications can request that a wallet remove outputs from a basket by providing the transaction ID (txid) and the output index (vout

Tone Engel ([email protected])

Abstract

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

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

Ragnar Friedman

Abstract

GASP is designed to synchronize transaction data between two parties in a blockchain environment. It ensures the legitimacy and completeness of transaction data using a recursive reconciliation method.

Abstract

This BRC specifies the format used for raw hex Bitcoin transactions, which are a widely-used way of representing Bitcoin transactions on the network. The specification includes details on the layout and various fields within Bitcoin transactions.

Motivation

Ty Everett ([email protected])

Abstract

Bitcoin uses scripts to control transactions, and three of the most common ways to represent a script are binary, hexadecimal, and ASM. This standard aims to provide a detailed description of these formats to facilitate their use in BSV transactions.

Ty Everett ([email protected])

Abstract

This document describes the Universal Hash Resolution Protocol (UHRP), a standard framework for content availability advertisement implemented with a UTXO-based overlay network. UHRP enables content hosts to advertise the availability of a particular file by creating a UTXO-based advertisement token, which is then submitted to the UHRP overlay and tracked by overlay network nodes. UHRP provides resilience to single points of failure and ensures content accessibility even if one host is offline, because multiple entities can be paid by content providers to keep content available.

Deggen ([email protected])

Abstract

We specify a paymail capability extension which supports the passing of BEEF Transactions between hosts. The procedure for service discovery and requesting outputs is not detailed, rather this proposal contains only a recommendation to replace hex data with hex data.

Ty Everett ([email protected])

Abstract

This document proposes standardized naming conventions for topic managers in BRC-22 and lookup services in BRC-24 to ensure clarity, interoperability, and uniformity across different implementations. The goal is to provide consistent and easily understandable names that facilitate efficient communication and integration between overlay network nodes and services within the BSV ecosystem.

Abstract

This BRC standard outlines the implementation and use of bare multi-signature (multi-sig) transaction output scripts within the Bitcoin SV digital asset ecosystem. By employing OP_MULTISIG opcodes directly, this approach offers simplicity and ease of implementation while providing enhanced security and access control for transactions. However, it also highlights the trade-offs in terms of privacy for participants. The standard comprises a motivation section, detailing the benefits of bare multi-sig transactions; a specification section, explaining the structure of these transactions; an example section, demonstrating a 2-of-3 multi-signature locking and unlocking script; and a "how it works" section, delving into the fundamentals of bare multi-sig transactions and their role in the Bitcoin SV ecosystem.

Ty Everett ([email protected])

Abstract

In one view of Bitcoin, only spendable output scripts with satoshis attached constitute valid Bitcoin tokens, because Bitcoin tokens are UTXOs. Since traditional scripts are not compatible with this view, we propose a methodology for creating OP_RETURN scripts that are spendable and contain satoshis. This provides a way for software to automatically convert non-compliant OP_RETURNs into proper Bitcoin tokens while encouraging developers to consider the spendability constraints that govern their tokens.

Ty Everett ([email protected])

Abstract

This document builds upon the insights of and proposes a scalable, efficient IPv6 multicast protocol specifically designed for the broadcast of blockchain transactions and the delivery of transaction status updates, such as merkle proofs and double-spend attempt notifications. Recognizing the limitations of existing IPv6 multicast protocols, including Multicast Listener Discovery (MLD), this protocol addresses the needs for massive scalability, efficient data delivery, and economic sustainability required by modern blockchain networks. This protocol employs a layered approach using MLDv2 at the edges, multicast Border Gateway Protocol (mBGP) at the core, and introduces an intermediate aggregation/summarization layer to ensure global scalability and efficiency.

This document is intended for network engineers and architects familiar with IPv6 and multicast technologies but may not have extensive knowledge of blockchain technology. The technical details provided aim to bridge the knowledge gap and foster understanding of the specific network demands and solutions in blockchain operations.

Ty Everett ([email protected])

Abstract

We define a set of reserved protocol namespaces that can be employed by clients utilizing the invoice numbering scheme to be set aside for administrative and internal use by the client software itself. This enables client software to manage its own internal state without the risk that application software will utilize the same internal protocols.

Ty Everett ([email protected])

Abstract

We define a comprehensive and authoritative specification of the deployment-info.json schema. It is intended to serve as a reference for developers building BSV blockchain applications that integrate with the LARS (Local Automated Runtime System) and CARS (Cloud Automated Runtime System) tooling and beyond. By following this specification, projects can ensure a standardized and interoperable structure that other tools and workflows can rely upon.

Specification

The deployment-info.json file defines the structure and metadata of a BSV-based application for both local development (via LARS) and cloud deployment (via CARS). It describes the app’s topic managers, lookup services, frontend build configuration, contract compilation requirements, and various deployment configurations.

Top-Level Schema

Example:

Fields

schema (string)

• Required: Yes

• Valid Values: "bsv-app"

• A fixed string identifying the schema type for this file. Must be "bsv-app".

schemaVersion (string)

• Required: Yes

• Indicates the version of this schema. Example: "1.0".

• As the schema evolves, this can help tooling handle backward compatibility.

topicManagers (object)

• Required: No (You may have no Topic Managers if your app does not define an overlay.)

• Maps topic manager names (strings) to paths of their implementing modules.

• Key (Topic Manager Name): A unique name (string) identifying the Topic Manager within the app. For example, "tm_meter", as per BRC-87.

lookupServices (object)

• Required: No (Only if your app needs overlay retrieval/lookup functionalities.)

• Maps lookup service names (strings) to configuration objects describing how to instantiate them.

• Key (Lookup Service Name): A unique name (e.g., "ls_meter"), as per BRC-87.

frontend (object)

• Required: No (Only if your project has a frontend.)

• Describes how the frontend portion of the app is set up.

• Fields:

  • language (string): The frontend tech stack. Common values:

Example:

contracts (object)

• Required: No (Only if your project uses on-chain contracts.)

• Describes contract language and location for source and artifacts.

• Fields:

  • language (string): The contract language. Common values:

Example:

If contracts is present and language is "sCrypt", LARS/CARS can trigger automatic contract compilation steps when contracts change.

configs (array)

• Required: Yes (although it can be empty initially)

• An array of configuration objects defining different deployment targets or modes for the project.

• Each config object corresponds to either:

  • LARS

Common Fields in Each Config:

• name (string, required): A human-readable name for the configuration. E.g., "Local LARS", "production", "staging".

• provider (string, required): Indicates whether this config uses LARS or CARS. Common values:

LARS-Specific Fields:

• run (array of strings, optional): Which parts of the project to run locally. Usually ["backend"], may include "frontend" if supported, but often the frontend is served separately. Example:

CARS-Specific Fields:

• CARSCloudURL (string, required for CARS): URL of the CARS cloud service. E.g., "https://cars-cloud.example.com".

• projectID (string, required for CARS): The Project ID on the CARS Cloud. Used for managing deployments, logs, admins, etc.

• deploy (array of strings, required): Which parts of the application to deploy to the cloud. E.g., ["frontend", "backend"]

Example CARS Config:

Additional Notes on configs:

• Multiple CARS configs can coexist (e.g., one for "staging", one for "production", different networks, resilient deployment across clouds).

• Only one LARS config is typically present (local dev environment). Tools like LARS assume a single local configuration.

• Tools like CARS will prompt or require the user to pick a configuration if multiple apply.

Integration With LARS and CARS

• LARS uses deployment-info.json to:

  • Determine which topic managers and lookup services to load locally.

  • Compile contracts if specified under contracts.

By maintaining a consistent deployment-info.json schema, both local and cloud tools can parse and understand the application’s structure, enabling smooth transitions from local dev (LARS) to production deployments (CARS).

Compatibility and Future-Proofing

• schema and schemaVersion: Future updates to the schema may introduce new fields or optional properties. Always check if your tools (LARS, CARS, or others) support the version you’re using.

• Optional Fields: Many fields are optional, allowing minimal setups. For example, you can omit frontend if you have no frontend. You can omit lookupServices if you have no shared state coordination needs.

Example Minimal deployment-info.json

No frontend, no contracts, no lookup services, and a single LARS config.

Example More Complex deployment-info.json

Conclusion

This reference provides a complete specification of the deployment-info.json schema used by LARS, CARS, and related tooling. By adhering to this schema, developers create a consistent and predictable environment, enabling a smooth, automated workflow from local development to production deployment.

• Ty Everett ([email protected])

• _unwriter

Abstract

This document presents the technical standard for the TXO (Transaction Object) format, a structured representation of Bitcoin transactions that enables powerful queries, processes, and filters. The TXO format captures transaction data in a hierarchical structure, facilitating its storage in document databases (e.g., MongoDB) and enabling real-time filtering with JSON filter libraries (e.g., JQ).

Motivation

Traditional raw one-dimensional Bitcoin transactions, as described in , are challenging to process and filter, which hinders the development of applications that rely on transaction data. The TXO format overcomes these limitations by transforming raw Bitcoin transactions into a structured, queryable, and hierarchical format, thereby enabling developers to build powerful applications and services using transaction data.

Specification

The TXO format represents a Bitcoin transaction as a JSON object with the following high-level structure:

Level 1: Transaction

At the top level, the TXO format includes two objects: tx and blk.

• tx (transaction): contains:

  • h (transaction hash)

  • r (raw transaction)

Level 2: Script

The next level of the TXO format includes two arrays: in (input scripts) and out (output scripts).

Each input and output is essentially a Bitcoin script. Attributes for each script include:

• i: the index of the current script within the in (input) or out (output) array.

• b0, b1, b2, ...: the script's push data.

Level 3: Graphs

The third level of a TXO interpreted transaction focuses on the graphs that represent the relationships between transactions. Graphs play a crucial role in understanding the flow of transactions in the Bitcoin network. Each item in the in and out arrays has an attribute called e (edge), which represents the graph structure of each transaction. The edge attribute helps in connecting the inputs and outputs of a transaction, as well as tracking the flow of satoshis between addresses.

For inputs, the edge is an "incoming edge" that represents the outputs from the previous linked transaction. It contains the following fields:

• h: The hash of the transaction that contains the previous output.

• i: The index of the previous output within its transaction output set.

• a: The sender address if it can be parsed into an address.

For outputs, the edge is an "outgoing edge" that represents the outputs to the next linked transaction. It contains the following fields:

• v: The amount of satoshis sent.

• i: The output index within the transaction.

• a: The receiver address if the output is linking to an address.

Implementation

To implement the TXO format, follow these steps:

1. Deserialize the raw Bitcoin transaction into its input and output scripts.

2. Parse the input and output scripts into a JSON object following the TXO schema described in the specification section. This includes constructing the transaction, script, and graph levels for each transaction.

3. If applicable, store the TXO JSON object in a document database (such as MongoDB) to enable powerful queries, or filter the transactions in real-time using JSON filter libraries (such as JQ).

The reference implementation was written by _unwriter of the 21st Century Motor Company and is available .

Deggen ([email protected])

Abstract

We propose a binary format for a Single Merkle Path optimized for storage in a key value database.

Copyright

This BRC is licensed under the Open BSV license.

Motivation

The includes oddities in it for future extensions which are no longer necessary since they are covered by the compound merkle path format defined in . So now we attempt to specify the smallest possible encoding of a simple merkle path.

Specification

We take the JSON version from eg.

Encoding in bytes we start with a VarInt for index, followed by nPath being the number of leaves to follow, followed by 32 byte leaves.

Data Types

Example

Hex

Bytewise Breakdown

Implementation

Let's start by dumping this format as hex into a Buffer and parsing it into an object with a Buffer Reader. Then we construct an object

Ty Everett ([email protected])

Abstract

Bitcoin script is a programming language used in Bitcoin transactions to control the spending of coins. While the Bitcoin script opcodes are machine-readable, they are not easily human-readable. We define an assembly language that provides a human-readable format for expressing Bitcoin script opcodes, making it easier for developers to understand and write Bitcoin scripts. This specification defines the rules for expressing Bitcoin script opcodes in assembly format, including indentation, comments, expressing text strings and numbers, templating and other guidelines.

Motivation

Bitcoin script is a powerful tool for controlling the spending of coins, but its opcodes can be difficult for developers to read and understand. By providing a human-readable assembly format for expressing Bitcoin script opcodes, developers can more easily write and debug Bitcoin scripts. This specification aims to standardize the assembly format for Bitcoin script opcodes, making it easier for developers to work with Bitcoin transactions.

This specification is intended to start the discussion and propose an initial format for representing Bitcoin scripts in an assembly language. Iterative improvement through future BRCs will help improve this standard.

Specification

We specify an assembly language for Bitcoin script programs as follows:

Syntax

• Opcodes should be expressed in uppercase and without OP_ prefixing, e.g. CHECKSIG.

• Data to push on the stack is represented by strings, hex values, or template variables.

• Whitespace should be used for indentation and to separate tokens.

For example:

Data types

• Numeric values should be expressed as their corresponding opcodes, or in hexadecimal format.

• String values should be enclosed in single quotes.

• Hex values should be expressed in lowercase, without 0x prefixing.

For example:

Flow control

Conditional statements should use the IF opcode, followed by the conditional expression and the ELSE or ENDIF opcodes.

For example:

File Extension

We specify that .basm files can be used to represent Bitcoin assembly language programs.

Implementation

The process of assembling programs written in this assembly language comprises:

• Obtaining the values for template variables, either programmatically or by seeking user input

• Substituting template variable placeholders for the actual values

• Removing comments

• Computing and adding the correct PUSHDATA opcodes for adding string and hexadecimal values to the stack

Abstract

Push TX is a technique that enables users to enforce and access transactional states and conditions within Bitcoin script using ECDSA signature messages. It allows for the enforcement of several transaction elements, such as the number of inputs, nSequence values, input and output values, and script conditions, as well as the ability to specify the script into which tokens will be spent. The Push TX algorithm works by pushing the transaction pre-image message that generates the signature onto the stack as part of the input's unlocking script. This message can be pushed as a single contiguous blob, multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's locking script. The signature is then computed on-chain within the script and checked against the public key using OP_CHECKSIG to ensure the current transaction is valid. This standard outlines the motivation and specifications for implementing the Push TX technique within Bitcoin script.

Motivation

The Push TX technique offers several benefits to Bitcoin users and developers. Firstly, it allows for the enforcement of complex transactional states and conditions at the consensus layer, making it easier to create Turing complete machines within the Bitcoin ecosystem. This is achieved by enabling users to specify the script into which tokens will be spent, which can be used to enforce next state conditions. Additionally, it enables users to specify and enforce various transaction elements, such as input and output values, nSequence values, and the nLocktime condition. This improves the security and efficiency of Bitcoin transactions by ensuring that all transactional conditions are met and enforced at the consensus layer.

Specification

The Push TX algorithm works as follows:

1. The user or process that is using the UTXO pushes the transaction pre-image message that generates the signature onto the stack as part of the unlocking script. This message can be pushed as a single contiguous blob, multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's locking script.

2. The algorithm pushes the current transaction onto the stack.

3. The algorithm pushes a dummy private key onto the stack.

The Push TX algorithm can be used to enforce several elements of the transaction, including but not limited to the number of inputs, nSequence values, input and output values, and script conditions, as well as the ability to specify the script into which tokens will be spent.

Implementations

This has been .

Commentary

Bitcoin script is often misunderstood as being limited to the data provided in the locking and unlocking scripts. However, the Push TX technique allows for the inspection of the entire transaction within a contract itself, including all inputs and outputs. This opens up boundless possibilities for smart contracts on Bitcoin.

The ability to place arbitrary constraints on inputs and outputs within a contract means that a wide range of use cases can be implemented on Bitcoin. For example, contracts that enforce multi-signature transactions or time-based restrictions can be easily created using Push TX. Additionally, the technique enables the creation of more complex contracts that can enforce next state conditions, making it possible to create Turing complete machines within the Bitcoin ecosystem.

The high-level functionality of Push TX is relatively simple: it allows for the inspection and enforcement of transactional states and conditions within Bitcoin script. However, the implications of this functionality are far-reaching, as it enables the creation of a wide range of smart contracts and decentralized applications on the Bitcoin blockchain. This is important for Bitcoin because it expands its use cases and makes it a more versatile platform for developers and businesses looking to leverage blockchain technology.

References

Ty Everett ([email protected])

Abstract

This standard describes PacketPay, a mechanism for facilitating micropayments using Bitcoin SV within HTTP requests. It relies on the BRC-29 payment protocol for processing payments, and BRC-31 Authrite for authenticating communications between the API provider and consumer. PacketPay enables secure, per-request monetization of APIs, allowing API providers to charge consumers on a pay-per-use basis. This standard defines the required HTTP headers, the process of making and verifying payments, and the necessary steps to implement PacketPay in API interactions.

Motivation

The rapid growth of web services and APIs has created a need for efficient, secure, and scalable methods of monetizing these services. Traditional payment methods are often cumbersome and impose high fees, making them unsuitable for micropayments. PacketPay addresses this need by providing a secure, efficient, and low-cost solution for facilitating micropayments in HTTP requests. By leveraging Bitcoin SV's capabilities, PacketPay enables API providers to monetize their services on a per-request basis, and API consumers to pay only for the resources they use.

Specification

HTTP Headers

PacketPay uses the following HTTP headers for facilitating payments between API consumers and providers:

1. x-bsv-payment-satoshis-required: Sent by the API provider in a 402 response, it indicates the number of satoshis required for the requested resource.

2. x-bsv-payment: Sent by the API consumer in a request to a payment-enabled API endpoint, it contains a JSON stringified object representing a payment.

3. x-bsv-payment-satoshis-paid: Sent by the API provider in the response to a successfully paid API request, it indicates the number of satoshis paid for the requested resource.

PacketPay Process

The PacketPay process is divided into the following stages:

1. Authentication: The API consumer and provider exchange Authrite requests and responses to authenticate their identities and share necessary identity information.

2. Initial Request: The API consumer sends an HTTP request to the API provider without a payment. If the requested resource requires a payment, the API provider responds with a 402 status code and includes the x-bsv-payment-satoshis-required header, indicating the required payment amount.

3. Payment Processing: The API consumer reads the x-bsv-payment-satoshis-required

Implementation

To implement PacketPay, API providers and consumers must follow these steps:

1. Implement for processing payments and for authenticating communications between parties.

2. For API providers, implement logic to determine the payment required for each request and include the x-bsv-payment-satoshis-required header in the 402 response.

3. For API consumers, implement logic to read the x-bsv-payment-satoshis-required header, construct a payment, and include the x-bsv-payment

By following the above implementation steps, API providers and consumers can ensure secure and efficient micropayments using the PacketPay system. This will enable a new revenue model for APIs, allowing for greater flexibility and scalability in the ever-growing world of web services.

The PacketPay and have been implemented in JavaScript by the Babbage Team.

Ty Everett ([email protected])

Abstract

This document outlines the Overlay Services Synchronization Architecture, detailing the Services Host Interconnect Protocol (SHIP) and Services Lookup Availability Protocol (SLAP). These protocols enable efficient peer discovery and data synchronization across UTXO-based overlay networks. This BRC defines the components, interactions, and responsibilities of nodes running these protocols to maintain reliable and up-to-date overlay services.

Motivation

The proliferation of UTXO-based overlay networks necessitates robust mechanisms for peer discovery and data synchronization. While defines transaction submission and processing, SHIP and SLAP extend this by providing standardized methods for discovering the overlay hosts that run particular services. This architecture ensures seamless interaction between network participants, improving the efficiency and reliability of data propagation. It can also enable the users of services to find hosts that are interested in their transactions.

Background

Readers of this document should be familiar with BRCs 45, 59, 22, 24, 23, and 25.

Specification

Overview

The Overlay Services Synchronization Architecture comprises two fundamental protocols:

1. Services Host Interconnect Protocol (SHIP)

2. Services Lookup Availability Protocol (SLAP)

Each node running overlay services will implement topic managers and lookup services for both SHIP and SLAP, ensuring alignment between advertised services and their actual configuration.

Components

• SHIP/SLAP Topic Managers: Manage topic-specific transaction admittance.

• SHIP/SLAP Lookup Services: Provide mechanisms for querying UTXO states within topics.

• Advertiser: Handles the creation and revocation of SHIP and SLAP advertisements.

• Overlay Services Engine: Coordinates the processing of transactions, alignment of advertisements, and synchronization of data across various services.

Key Responsibilities

1. Ensuring Alignment

Each node must ensure alignment between the SHIP and SLAP advertisements it has sent out and the current set of topic managers and lookup services it is configured with.

2. Hosting SHIP/SLAP Overlay Networks

Nodes host copies of the SHIP and SLAP overlay networks, ensuring they are updated with new advertisements or revocations.

• Submission: Any node can submit SHIP/SLAP advertisements to another node if it knows its domain name, updating the overlay network.

• Internal Updates: Nodes submit their own advertisement transactions to themselves to update the overlay networks about new advertisements or revocations, thereby ensuring their hosted copies are always current and propagating them to other nodes.

3. Transaction Propagation

As part of the transaction submission process, nodes notify each other about transactions on topics they host and care about.

When new transactions are submitted to a node, the Engine:

• Ensures transactions are propagated to relevant nodes based on SHIP/SLAP advertisements made by them.

• Updates lookup services with new or spent UTXOs.

• Delegates transaction submission, verification, and output admittance to the SHIP/SLAP topic managers.

SHIP and SLAP Token Formats

SHIP Token Format

SLAP Token Format

Token Creation and Submission

The advertiser creates a transaction output containing the token and submits it to known nodes, including their own. The process involves:

1. Deriving the locking key using the advertiser's identity key.

2. Computing the signature over the token fields.

3. Creating and submitting the transaction output containing the token.

Token Validation and Admission

Nodes validate the identity key's link to the signature-producing key before admitting the output. The steps include:

1. Extracting token fields.

2. Verifying the SHIP/SLAP identifier.

3. Verifying the locking key and signature.

4. Admitting the token if valid.

Implementation

Developers should implement an HTTPS server that hosts the SHIP and SLAP topic managers and lookup services. The server should be responsible for notifying other nodes of relevant transactions and maintaining synchronization.

Abstract

This technical standard describes a method for hierarchical key derivation called BIP32. Hierarchical key derivation enables the generation of a large number of public-private key pairs from a single master seed, and the ability to derive child keys from parent keys in a deterministic manner. BIP32 is a widely used standard in various fields such as wallets, but has various limitations and drawbacks that should be considered carefully before further adoption.

Motivation

In many applications, it is necessary to generate a large number of public-private key pairs. However, generating and securely storing many keys can be challenging. Hierarchical key derivation solves this problem by generating an unlimited number of keys from a single master seed. This reduces the complexity of managing multiple keys and enhances security. BIP32 provides a standard for implementing hierarchical key derivation, ensuring interoperability between different systems.

Overview

BIP32 is a method for hierarchical key derivation that enables the generation of a virtually unlimited number of public-private key pairs from a single master seed. The master seed is used to generate the master private key, which is used to derive child keys. Child keys can in turn be used to derive grandchildren keys, great-grandchildren keys, and so on, forming a hierarchical tree-like structure.

Each key in the hierarchy is determined using a combination of its parent key and an index value. The index value determines the position of the key in the hierarchy, and the parent key serves as a starting point for deriving the child key. The combination of the parent key and the index value is used to generate a new private key, which can then be used to derive a new public key.

BIP32 specifies the use of a deterministic algorithm for deriving keys. This means that given the same master seed and index value, the same key will be generated every time. This is important for ensuring that different systems can generate the same keys, and for enabling secure backup and recovery of keys.

BIP32 also provides a standard for deriving hardened keys, which are child keys that cannot be derived from their parent public key alone. Hardened keys provide an additional layer of security, as they can only be derived using the parent private key.

BIP32 is a widely used standard for implementing hierarchical key derivation. It enables the generation of a large number of public-private key pairs from a single master seed, and ensures interoperability between different systems.

BIP32 Derivation Paths

BIP32 defines a hierarchical tree-like structure for generating an unlimited number of public-private key pairs from a single master seed. This structure is organized using a derivation path, which is a sequence of index numbers and hardened/not-hardened markers that uniquely identify a particular key in the hierarchy.

A derivation path always starts with the letter "m", which stands for "master", followed by a forward slash ("/") and then a series of numbers and markers that specify the child keys to be derived. For example, the path "m/0/1/2" indicates that the third child private key should be derived from the second child private key of the first child private key of the master key.

In addition to simple index numbers, BIP32 allows for "hardened" derivation, which means that the derived key can only be generated using the parent's private key. Hardened keys are denoted with an apostrophe (') after the index number. For example, the path "m/44'/0'/0'/0/0" is commonly used for generating the first receiving address of a Bitcoin wallet using BIP44 standard (discussed below).

BIP44 Wallet Addressing

BIP44 is a widely used standard for generating hierarchical deterministic wallets with a specific structure for addressing different cryptocurrencies. This standard provides a consistent method for generating and organizing addresses across different wallets and platforms.

The BIP44 structure uses a derivation path that starts with "m/44'/<coin_type>'/", where <coin_type> is a numeric identifier for the cryptocurrency being used. For example, "m/44'/0'/" is the path for generating Bitcoin keys, and "m/44'/60'/" is the path for generating Ethereum keys.

Following the coin_type index, BIP44 specifies several other indices to organize keys, including account, change, and address indices. Account indices are used to manage multiple accounts within a single wallet, change indices are used to differentiate between incoming and outgoing transactions, and address indices are used to generate unique receiving addresses.

For example, the path "m/44'/0'/0'/0/0" generates the first receiving address for the first account of a Bitcoin wallet. The "0'" after the coin_type index indicates a hardened key, ensuring that the derived key can only be generated using the parent's private key. The "0" after the hardened index specifies the first account, and the "0" after that specifies the first address in the account.

Drawbacks and Alternatives

While BIP32 is a widely used standard for hierarchical key derivation, there are several potential drawbacks that should be considered before further adoption.

One major limitation is that BIP32 lacks privacy guarantees. Since it is common for all child keys in a wallet to be derived from a single node, any knowledge of the root public key could compromise the privacy of the entire key hierarchy for the wallet — since public keys can be derived from parent public keys, there is a risk of linkability between addresses that use the same parent key.

Additionally, BIP32 is limited to a maximum of 2^31 possible child keys per parent, which may not be sufficient for applications that require a very large number of keys.

To address these limitations, other key derivation schemes adopt various alternative approaches. By incorporating a shared secret between the sender and the recipient into the key derivation process, we can protect privacy even when the root public key becomes known. enables this functionality, and allows an unlimited number of child keys to be derived.

References

• 1:

Ty Everett ([email protected])

Abstract

This document describes a protocol for a portable message encryption and description scheme. It follows the BRC-42 key derivation and BRC-43 invoice number standards to protect the confidentiality of message content, without requiring the added complexity of agreeing on a specific BRC-43 protocol for the parties to use.

Motivation

Message encryption is a fundamental requirement as it ensures the privacy and confidentiality of the content transmitted between parties. The current standards like Electrum ECIES don't provide a comprehensive solution for message encryption by integrating with BRC-42 and BRC-43. This document aims to enhance security by developing a protocol for message encryption and decryption, utilising the BRC-43 invoice numbers. The protocol facilitaes a way to exchange encrypted data in a general way.

Specification

The protocol employs the BRC-2 encryption process and makes use of the BRC-42 key derivation and BRC-43 invoice numbering scheme.

The encryption procedure follows these steps:

1. The sender employs BRC-43 with security level 2, protocol ID message encryption, and a randomly generated 256-bit key ID to compute the invoice number to facilitate BRC-42 key derivation. We specify the key ID is in base64 format when added to the invoice number.

2. The sender derives their own child private key and the child public key of the recipient using BRC-42 key derivation.

3. The sender then computes an ECDH shared secret between the two child keys which is used in symmetric encryption with AES-256-GCM.

For decryption:

1. The recipient computes their own private key and the public key of the sender using BRC-42 key derivation.

2. The recipient computes the same Shared Secret and uses it along with the received initialization vector to decrypt the ciphertext.

Serialization format

The serialized data for transmission includes a version number, the identity key of the sender, the identity key of the recipient, and the AES-256-GCM ciphertext (with the initialization vector prepended). Note that anyone is not permitted for encrypted data:

This standard serialization format contributes towards a standardized way of securely transmitting and decrypting encrypted messages.

Hex Examples

Abstract

BRC-27 defines an abstract messaging protocol that facilitates payments on the Bitcoin SV network. This specification extends the protocol with the specifics required for a concrete HTTPS implementation that includes message size limits and HTTPS-specific implementation details.

Motivation

HTTPS is one of the most widely used transport mechanisms for internet traffic. Enabling users of HTTPS to benefit from the use of the DPP will facilitate increased industry adoption and growth. Defining implementation-specific stipulations for HTTPS-based DPP will address problems and ambiguities specific to this communications substrate.

Specification

Below is the table with messages requested from client (wallet) to merchant (server).

The paymentID parameter is assumed to be known as a result of request between client-server before DPP protocol operation.

PaymentTerms messages larger than 10 MB should be rejected by the wallet application, to mitigate denial-of-service attacks.

Payment messages larger than 10 MB should be rejected by the payment host’s server, to mitigate denial-of-service attacks.

PaymentACK messages larger than 11 MB bytes should be rejected by the wallet application, to mitigate denial-of-service attacks. This is larger than the limits on Payment and PaymentTerms messages as PaymentACK contains a full Payment message within it.

Implementations

The BRC-55 API is implemented .

Deggen ([email protected])

Abstract

We present a data model and JSON format for a Merkle Path which will be passed from a Transaction Lookup service to a Lite Client via web API.

Tone Engel ([email protected]), TonesNotes

Abstract

This is an argument for using block height as the standard for indexing block headers within merkle proofs.

It argues for a backward compatible protocol extension in the short term and through deprecation, a long term reduction in the space cost of a usable local copy of block headers by a factor of two.

The referenced specification, the "Spec":

Ty Everett ([email protected])

Abstract

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 , by providing a standardized methodology for exchanging merkle proofs and input transactions.

Ty Everett ([email protected])

Abstract

The Pay-to-Public-Key-Hash (P2PKH) output script is a commonly used script in the Bitcoin network that allows users to send funds to a specific Bitcoin address. This standard provides a detailed specification of the P2PKH output script, providing detail on the operations performed, and giving examples for serialized Bitcoin addresses.

Ty Everett ([email protected])

Abstract

This document outlines a protocol that allows an entity to publish trust anchor details, including a public key, at a location on the internet. The information is stored in the /manifest.json file of the domain. This approach provides a user-friendly method for individuals to easily retrieve a trusted entity's public key by entering a known domain name.

Ty Everett ([email protected])

Abstract

The architecture for wallet protocol permissions enables a wide range of use cases. By reserving protocol identifiers and preventing their use by applications, we ensure compatibility with future standards, supporting the future development of new protocol permission schemes.

Ty Everett ([email protected])

Abstract

The R-puzzle technique is a powerful cryptographic tool that can be used to create Bitcoin output scripts that can be unlocked by anyone who is able to solve for a value k, without revealing k to the world. The technique relies on the fact that in an ECDSA digital signature, the R component is computed by multiplying a generator point on the elliptic curve with this k-value. By constructing a Bitcoin output script that requires knowledge of this value, it is possible to create puzzles that can be solved by anyone who is able to compute the correct value for k. The R-puzzle technique is flexible and can be used for a variety of applications, including those that benefit when the solver does not reveal their solution to the world, only proving knowledge of it. R-puzzles also provide a way to create Bitcoin output scripts that can be unlocked without requiring knowledge of a specific private key, while still maintaining a high level of security and cryptographic strength. By serializing short-hand script templates in a standard way, implementers can maintain ecosystem-wide compatibility.

Motivation

The creation of puzzles that can be unlocked by anyone who is able to solve a complex problem has become increasingly popular in recent years, particularly in the field of distributed computing. However, it is important to ensure that these puzzles are designed in such a way that they maintain a high level of security and cryptographic strength, while still allowing anyone to solve them without revealing any sensitive information.

To achieve this, it is valuable to create a script template that enables the solver to prove knowledge over a value, k, without revealing the k-value to the world. This provides a way to create puzzles that are secure and difficult to solve, while still allowing anyone to claim the solution and the associated rewards. In addition, it is desirable to employ a script template that does not require the creator of the puzzle to know which key will be used by the solver in claiming the solution, at the time the puzzle was created. Finally, there is also a need to standardize the way these scripts are expressed and exchanged between users of the Bitcoin network, to enable greater cross-compatibility and wider adoption.

Specification

We specify the following Bitcoin script template for R-puzzles:

We specify that the same private key and k-value must NEVER EVER be used, and that steps MUST be taken to prevent the same private key and k-value from ever being used to sign different messages in ECDSA. Failure to follow this provision will result in leakage of private keys and k-values.

Serialization Format (Base58)

We specify that the P2RPH output script is serialized using Base58 encoding. The serialized format is as follows:

Where:

• [Version Bytes] is a prefix that identifies the network and the script type. The value of the version byte is 0x0e00 for the mainnet and 0x1c00 for the testnet.

• [PubKeyHash] is a 20-byte RIPEMD160 hash of the SHA256 hash of the R-value.

Examples

P2RPH Bitcoin addresses for mainnet always start with an R because the [Version Bytes] we selected are 0x0e00. On testnet, they will always start with lowercase r because the [Version Bytes] are 0x1c00.

Mainnet example P2RPH address: RsQphNVccTzET8zwMNESLmTeJ4cJYxyc9cx

Testnet example P2RPH address: rjQPANNiecDK1a6jedyCsQ6UND4SnK6rJNe

How it Works

The locking script is the script that is attached to the Bitcoin output that is being locked with the R-puzzle. When a Bitcoin transaction is created that spends this output, the unlocking script must provide the correct input to satisfy this locking script.

The locking script essentially creates a puzzle that can only be unlocked by providing an ECDSA digital signature that satisfies certain conditions. Specifically, the signature must have an R component that, when hashed with SHA256 and then RIPEMD160, produces the same value as the <hash> specified in the script. The S component of the signature can be computed using any key of the solver's choosing.

The unlocking script essentially satisfies the conditions set out by the locking script by providing a valid ECDSA digital signature with an R component that matches the hash specified in the locking script, and an S component that is computed using the solver's chosen private key.

The locking and unlocking scripts for the R-puzzle comprise a powerful and flexible tool for creating puzzles that can be solved by anyone who is able to compute the correct value for the k parameter used in the ECDSA digital signature. By using this technique, it is possible to create Bitcoin outputs that can be unlocked by anyone who is able to solve the puzzle, without requiring knowledge of a specific private key.

Security Considerations

It is crucial to emphasize the importance of never using the same private key and k-value for different messages in ECDSA. Doing so can compromise the security of the digital signatures and result in the leakage of private keys and k-values, which can lead to the loss of funds or assets associated with those signatures.

Therefore, it is essential to take steps to ensure that private keys and k-values are never reused. One way to achieve this is by using a secure random number generator to generate new values for each signature. It is also important to store private keys securely and to use secure communication channels when transmitting them.

To further emphasize the importance of this provision, it is advisable to include clear warnings and instructions in any documentation or educational material related to the R-puzzle technique. This will help ensure that users understand the potential risks of reusing private keys and k-values and take the necessary precautions to prevent such incidents from occurring.

Implementations

The first-known implementation for R-puzzles was created by .

Ty Everett ([email protected])

Abstract

This document defines a protocol for creating and verifying digital message signatures in the Bitcoin ecosystem. It leverages the BRC-42 key derivation and BRC-43 invoice numbers to facilitate privately-verifiable signatures, increasing security and privacy in Bitcoin message interactions.

Motivation

While Bitcoin Signed Messages (BSM) offer a simplistic solution for digitally signing Bitcoin messages, they lack capabilities for privately-verifiable signatures and they re-use keys, potentially compromising security and privacy. By incorporating BRC-42 key derivation, this standard enhances the security and private signing capabilities, providing a robust and unified standard for the Bitcoin ecosystem. Private signing enables a specific verifier to check the signature, without revealing its validity to the rest of the world.

Scope

The scope of this specification is to convey a message signature. The message data (the thing being signed) is not serialized as part of this signature structure.

One notable aspect of BSM is the need to prefix all messages with "Bitcoin signed message" to avoid inadvertently signing a Bitcoin transaction. However, since the new approach utilizes a new signing key for each message, there is no danger of signing Bitcoin transactions with a key capable of spending locked coins.

Specification

The protocol employs the BRC-3 digital signature process and makes use of the BRC-42 key derivation and BRC-43 invoice numbering scheme.

We specify message signing as the BRC-43 protocol ID, with security level 2. We specify that the signer generates a random 256-bit value to be used as the key ID when the signature is computed for a given counterparty.

The system operates in the following way:

1. Message sender computes the BRC-43 invoice number based on the security level (2), protocol ID (message signing), and their 256-bit key ID. We specify the key ID is in base64 format when added to the invoice number.

2. Message sender derives a child private key for the counterparty (or anyone) with the computed invoice number using the BRC-42 key derivation process.

3. Message sender then computes the digital signature using the ECDSA with the derived private key.

Serialization format

The standard serialization format encapsulates all the necessary information required for message verification into a binary representation. The format starts with a version number, followed by the identity key of the signer, the identity key of the recipient (or 0x00 to represent anyone if it's publicly verifiable), the 256-bit key ID used for the signature, and the ECDSA signature over the message. This structure ensures a standardized way for efficiently and securely transmitting and verifying signatures:

Hex Examples

Ty Everett ([email protected])

Abstract

The BSV network is designed to process transactions at scale, leveraging a robust, distributed system of miners, validators, and aggregators. This system balances parallel processing with sequential validation, ensuring transactions are both processed rapidly and recorded in the correct order. Below, we document the detailed processes by which BSV miners will come to handle transactions at scale.

1. Transaction Submission

Users and services across the globe create and sign Bitcoin transactions, broadcasting them to the network. The network's miners collect these transactions at numerous Points of Presence (PoPs), which act as edge nodes in the BSV ecosystem. The following steps outline the process:

• Preliminary Checks: Upon receiving a transaction, miners at PoPs verify its scripts, ensuring they comply with network standards and contain valid signatures. If valid, the transaction proceeds to the next stage.

• Batching: After initial verification, the miners batch transactions, preparing them for forwarding to regional aggregators. This batching process occurs periodically, facilitating efficient transfer and further processing.

2. Transaction Stripping

After initial verification, transactions undergo a stripping process, which reduces each transaction to its essential elements:

• Stripped Data: The remaining data includes:

  • The TXID and output indices of the consumed outputs.

  • The TXID of the transaction itself.

  • The number of new outputs it creates.

3. Edge-Level Stripped Transaction Graph Summarization

Where possible, edge validators summarize stripped transaction graphs before sending them to regional aggregators. This process is crucial in reducing the workload of higher-level aggregators:

• Internal Transactions: The summarized graph only needs to include:

  • The TXIDs and output indices of previously consumed outputs.

  • The newly created outputs.

  • A merkle root for the transactions it includes.

4. Regional Aggregation

After receiving stripped transactions and summarized graphs, regional aggregators build subtrees of transactions:

• Subtree Formation: Subtrees are groups of transactions or graphs, each forming a summarized graph with a merkle root and lists of outputs consumed and created.

• Multi-Level Aggregation: Multiple levels of regional aggregation may occur in parallel, gradually integrating more of the completed transaction graph into larger structures.

• Fee Tracking: Fees from child graphs are aggregated to track the total fees collected by the parent graph.

5. Global Aggregation and Block Assembly

Regional aggregators send subtree summaries to global aggregation systems, which then prepare the final block:

• Graph Consistency: The system checks graph edges for consistency, ensuring no edge is consumed by one graph before being created by another.

• Block Template: The block assembler combines these subtrees, including the coinbase transaction with the correct amount of fees, forming a finalized block template ready for hashing.

• Proof of Work: Upon finding a valid proof-of-work header, the new block header is immediately propagated throughout the network for parallel validation by all systems.

6. Proof Completion

Once a valid header is found, it triggers a cascading parallel proof completion process:

• Downstream Propagation: The header propagates down to all regional aggregators, who append the upper layers of the merkle tree to their subgraph roots.

• Notifier Chain: Each regional aggregator notifies its child aggregators or edge validators, which in turn notify their children. This chain of notifications continues until all edge validators have completed proofs for all transactions they submitted.

• End-User Notification: Finally, edge validators notify network end-users of the completed proofs available for their transactions.

7. Summary

The BSV network effectively balances parallel processing and sequential validation to achieve scalable transaction processing. By employing edge-level validation, regional aggregation, and global assembly, the system reduces the workload at higher levels, ensuring rapid, consistent processing. This layered, hierarchical approach to aggregation, alongside the use of transaction stripping and summarization, makes the BSV network a robust solution for scalable blockchain processing.

8. Future Work: Modeling the BSV Network

To model and describe the BSV network quantitatively, it is essential to focus on the parameters and metrics that influence the performance and scalability of the system. Here are some key components and steps to construct a quantitative model of the BSV transaction processing system:

8.1. Parameters and Metrics

Key Parameters

• Transaction Arrival Rate: The rate at which transactions are received at edge nodes, typically expressed in transactions per second (tps).

• Batch Size: The number of transactions processed together in batches at edge nodes before being sent to regional aggregators.

• Transaction Processing Time: Time taken to verify and strip a single transaction.

• Propagation Delay

Performance Metrics

• Throughput: The total number of transactions processed per unit time across the network.

• Latency: The total time taken from when a transaction is submitted until it is included in a validated block.

• Resource Utilization: Measures how efficiently resources (computational, bandwidth) are used.

• Scalability: The ability of the network to handle increasing transaction loads without a proportional increase in latency or resource costs.

8.2. Modeling Steps

Step 1: Transaction Input Modeling

• Model the transaction inputs as a Poisson process or another suitable stochastic process that reflects real-world arrival patterns.

Step 2: Process Modeling at Edge Nodes

• Model the batch processing as a queue where transactions are collected, verified, and stripped. Queuing theory, specifically a batch service queue model, can be applied here.

• Calculate the processing rate of batches based on the transaction processing time and batch size.

Step 3: Summarization and Aggregation Modeling

• Use a hierarchical tree model to represent the multi-level aggregation process. Each node in the tree represents an aggregation point (edge, regional, global).

• Model the propagation of transaction summaries through this tree, accounting for delays and processing times at each node.

Step 4: Block Assembly and Propagation

• Model the final block assembly as a sequential process that only begins once all necessary summaries and proofs are available.

• Consider the proof-of-work process and its impact on block propagation and finality.

Step 5: Analytical Model Construction

• Construct a series of equations or a simulation model that integrates these components. For example, use differential equations to represent the rate of change in the queue sizes, or develop a discrete-event simulation to model the dynamic interactions and delays.

Step 6: Validation and Simulation

• Validate the model against real data or simulated data to ensure it accurately represents the BSV network's behavior.

• Use the model to simulate different scenarios, such as increased transaction loads, changes in batch sizes, or different network delays, to study their impacts on throughput, latency, and scalability.

8.3. Utilizing the Model

• Optimization: Use the model to find optimal parameters (e.g., batch size, number of edge nodes) that maximize throughput or minimize latency.

• Capacity Planning: Estimate the resources needed to achieve certain performance metrics under expected future loads.

• Scenario Analysis: Assess the impact of network changes or growth on performance and resource needs.

By quantitatively modeling these processes, the BSV network's design and operation can be better understood, optimized, and scaled to meet the demands of a high-volume, real-time transaction processing environment.

Ty Everett ([email protected])

Abstract

This BRC defines Atomic Background Evaluation Extended Format (Atomic BEEF) Transactions, a variant of the BEEF transaction format (as defined in BRC-62) that focuses on atomicity—specifically, ensuring that all the data within a BEEF structure relates to a single "subject transaction." This format disallows unrelated transactions within the BEEF structure, reinforcing a clear, minimalistic data set for transaction validation while maintaining efficiency in bandwidth usage.

Atomic BEEF is designed to solve problems arising from multiple graphs of unrelated transactions being aggregated into a single BEEF, which can complicate validation and increase data complexity. Atomic BEEF introduces a strict structure optimized for single-transaction use cases, ensuring that every transaction in the BEEF relates to a defined subject transaction. This format is particularly suited for applications where the verification of a singular transaction and its direct ancestry is critical.

Motivation

The introduction of the BEEF format (BRC-62) provided a solution for transmitting transaction data in a binary format to allow (SPV) with minimal bandwidth. However, BEEF allows the inclusion of multiple, potentially unrelated transactions aggregated within the same structure, making it flexible but not ideal for cases where strict atomicity is needed.

Atomic BEEF is motivated by the following challenges:

1. Transaction Ambiguity: In BEEF, there is no explicit constraint to keep transactions related to a single subject transaction. This can lead to ambiguity when unrelated transaction graphs are included in the same BEEF structure, making validation and verification more complex.

2. Simplified Use Cases: Many use cases of SPV revolve around validating a single payment or transaction, not multiple. Atomic BEEF optimizes for this by focusing entirely on the recursive transaction graph relevant to a specific transaction.

3. Data Minimalism: For micropayments or systems requiring highly efficient data transfer, limiting the number of transactions included in the BEEF to only the required set for validation of a single subject transaction reduces unnecessary overhead.

In response to these motivations, Atomic BEEF introduces a new mechanism for enforcing the atomicity of BEEF transactions.

Specification

Atomic BEEF is an extension of BEEF (BRC-62) with specific structural and validation rules that ensure atomicity. It adheres to the same encoding and transaction structure principles, with the following additional constraints:

Header Structure

Atomic BEEF introduces a unique header prefix that ensures the atomicity of the BEEF structure. The Atomic BEEF format starts with a constant prefix followed by the TXID of the "subject transaction." This TXID serves as the reference transaction that the entire BEEF structure must relate to.

• Prefix: The first 4 bytes of the Atomic BEEF structure must be 0x01010101, a fixed constant to indicate Atomic BEEF.

• Subject TXID: The next 32 bytes are the TXID of the "subject transaction"—the primary transaction that the rest of the structure must validate and verify.

Transaction Inclusion Rules

Atomic BEEF strictly enforces that all transactions included in the structure must be part of the subject transaction's dependency graph. This means that every transaction in the BEEF structure must either be:

1. The subject transaction itself, or

2. An ancestor transaction required to validate the inputs of the subject transaction.

Transactions that fall outside of this graph, or are unrelated, are not allowed in Atomic BEEF. This ensures that the BEEF is entirely focused on a single, verifiable transaction and its direct dependencies.

Validation Process

The validation of an Atomic BEEF structure follows these steps:

1. Subject Transaction Identification:

   • The first step in validation is to extract the subject TXID from the header. If the BEEF structure does not include the subject transaction or if any unrelated transactions are present, the validation fails.

2. Transaction Graph Validation:

Error Conditions

Atomic BEEF introduces two specific error conditions that must cause validation to fail:

1. Missing Subject Transaction: If the BEEF structure does not include the subject transaction identified by the subject TXID in the header, validation fails.

2. Unrelated Transactions: If any transactions within the BEEF structure fall outside the dependency graph of the subject transaction, validation fails.

These error conditions ensure that Atomic BEEF maintains strict atomicity and avoids the ambiguity and complexity of unrelated transactions within the same structure.

Bytewise Breakdown:

Ty Everett ([email protected])

Abstract

We define a mechanism for requesting and receiving digital signatures over the abstract communications channel first described by . We rely on the invoice numbering and permission scheme on top of for key derivation, enabling the creation of private digital signatures that can only be verified by the counterparty. A signer derives their own child private key and uses it to compute an ECDSA signature, which is then communicated to the verified, together with the signer's identity key, the message, and the protocol ID and key ID used. The verifier uses this information to derive the corresponding child public key for the signer, which is then checked against the signature and message with ECDSA. Without the shared secret, no third parties can discover the correct child public key, making then unable to validate the signature.

Brayden Langley ([email protected])

Abstract

The Window Wallet Communication Substrate is a standardized interface that enables seamless integration between web applications and browser embedded Bitcoin wallets. It serves as a unified gateway for applications to access various wallet functionalities, including the creation of Bitcoin transactions, encryption, digital signature creation, and more. By establishing this standardized interface, applications gain the ability to support multiple wallet providers, enhancing flexibility and choice for users in managing their Bitcoin-related tasks. This interface empowers users with greater control and accessibility while maintaining compatibility across different applications and wallets.

Ty Everett ([email protected])

Abstract

This BRC specifies a protocol for exchanging simple P2PKH payments between a sender and a recipient in a way that is SPV-compliant and cross-compatible. The protocol makes use of key derivation to derive public and private keys between users, transaction envelopes to relay SPV-related information between the sender and the recipient, and a SPV implementation to enable the recipient to obtain confidence that the transactions are valid and legitimate. This BRC specifies the JSON version of the payment message format used by the sender when exchanging the payment with the recipient, and the steps and processes involved in constructing and validating a payment message.

Darren Kellenschwiler ([email protected]) Damian Orzepowski ([email protected])

Abstract

Allowing humans to securely exchange public keys using web apis and an off channel sharing of TOTPs.

Brayden Langley ([email protected])

Abstract

To ensure a seamless process for submitting payments to a wallet, there must be a standardized method by which this process takes place. Wallets that implement this standard will be able to support the direct submission of transactions from applications to a user's wallet along with the associated SPV information as defined by . The required message structure and fields are defined below in the section, and the expected response to provide is defined in the section. Wallets that choose to implement this specification will allow applications that facilitate the exchange of payments to be built in a way that is interoperable, extensible, and SPV compliant.