Ty Everett (ty@projectbabbage.com)

Abstract

We define a mechanism for requesting and receiving digital signatures over the abstract communications channel first described by BRC-1. We rely on the BRC-43 invoice numbering and permission scheme on top of BRC-42 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 BRC-42 shared secret, no third parties can discover the correct child public key, making then unable to validate the signature.

Motivation

The increasing use of Bitcoin wallets has highlighted the need for a secure and interoperable digital signature standard that can be used across different applications. Digital signatures provide a vital aspect of data authentication, allowing for the verification of information and secure transactions, and are critical to ensuring the integrity of the Bitcoin network.

While other solutions have proposed digital signatures within a wallet, none of them have provided a unified and open standard that supports both privately and publicly verifiable signatures, while also incorporating proper BRC-42 key derivation. The lack of such a standard has created a fragmentation within the ecosystem, with each application requiring its own solution, thus hindering interoperability and leading to duplicated effort.

To address this issue, the BRC-3 standard has been created to enable the creation and verification of digital signatures using BRC-43 invoice numbering and permission scheme on top of BRC-42 for key derivation. This allows for the creation of private digital signatures that can only be verified by the intended counterparty, while maintaining security against third-party tampering.

The BRC-3 standard not only provides a secure and interoperable solution for wallet implementations, but it also enables new use cases and experiences that were previously not possible. With a unified standard, different wallets can create and verify each other's digital signatures seamlessly, reducing friction and enabling greater innovation.

Specification

We start with the same constructs defined in BRC-43: users with clients, protocols and applications. We stipulate the use of BRC-43 invoice numbers in the context of BRC-42 key derivation, and we build on top of the permissions architecture defined by BRC-43.

When an application sends a message to a client requesting that data be signed, the message comprises:

• The BRC-43 security level, protocol ID, key ID and counterparty to facilitate BRC-42 key derivation and permissioning

• The data to sign

We stipulate the following process for digital signature creation:

• The message signer begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID

• The message signer uses BRC-42 key derivation with the computed invoice number to derive their own child private key

• The message signer computes the digital signature using ECDSA with their derived child private key (this specification is silent about ECDSA k-value utilization)

We stipulate the following process for message verification:

• The verifier somehow comes to know the signature, the counterparty (signer), the security level, protocol ID, and key ID. The mechanism for conveying this information to the verifier is beyond the scope of this specification.

• The verifier begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID

• The verifier uses BRC-42 key derivation with the computed invoice number, their own private key and the public key of the sender, to compute the signer's child public key

• The verifier uses ECDSA to verify the signature against the message using the signer's child public key

We build upon the abstract messaging layer first described in BRC-1. Specifically, we define five new BRC-1 messages to facilitate requests and responses for signatures and verification operations, and error handling. For each of the messages, we stipulate that there exists some out-of-band mechanism for the parties to communicate which of the messages are being exchanged, removing the need for a message type field. Finally, specifically for the request messages, we stipulate that the message comprises a header and a payload, with the payload containing the data (ciphertext or plaintext), and the header containing the other information. For the response messages, no message header is defined and the payload simply contains the specified data.

Signature Creation Request

The signature creation request is a message sent by the BRC-43 application to the client. It contains a header with the following information:

The message payload comprises the data to sign.

Signature Creation Response

The response message comprises the ECDSA digital signature in DER format.

Signature Verification Request

The signature verification request is a message sent by the application to the client. It contains a header with the following information:

The message payload comprises the data to verify.

Signature Verification Response

The response message comprises a JSON payload containing the following fields:

Signature Error

If the client is unable to fulfill the signature creation or verification requests for any reason, we specify that it should respond with a JSON-formatted Signature Error. The fields for the object are specified as follows:

One example of a Signature Error is given below:

{
  "status": "error",
  "code": "ERR_PERMISSION_DENIED",
  "description": "You have denied permission for signing this data."
}

Test Vectors

For compatibility with this signature scheme, we stipulate the following:

Any user who knows the following identity private key (counterparty=anyone)...

0000000000000000000000000000000000000000000000000000000000000001

...should be able to use security level 2, the BRC3 Test protocolID with keyID 42 and the following counterparty (signer)...

0294c479f762f6baa97fbcd4393564c1d7bd8336ebd15928135bbcf575cd1a71a1

...to verify the message with the following digital signature (DER format)...

[48, 68, 2, 32, 43, 34, 58, 156, 219, 32, 50, 70, 29, 240, 155, 137, 88, 60, 200, 95, 243, 198, 201, 21, 56, 82, 141, 112, 69, 196, 170, 73, 156, 6, 44, 48, 2, 32, 118, 125, 254, 201, 44, 87, 177, 170, 93, 11, 193, 134, 18, 70, 9, 31, 234, 27, 170, 177, 54, 96, 181, 140, 166, 196, 144, 14, 230, 118, 106, 105]

The message that was signed is:

BRC-3 Compliance Validated!

Implementations

• This digital signature capability is incorporated into the Babbage SDK

A repository for submitting, discussing, sharing, and indexing technical proposals for use across the Bitcoin ecosystem. Data models, user interfaces, script templates, encoding formats, communication protocols, and constructive critique of existing industry practice are all welcome. The goal is to provide a platform for sharing ideas without any bureaucratic overhead.

Contributing

To participate in discussions about existing proposals, simply open an issue and link back to the BRC file in question.

Iterative improvement

We believe in encouraging discussion and iterative improvement of proposals, resulting in incremental improvement within the bounds of the Bitcoin protocol. We welcome suggestions for improvement and are committed to working with contributors to improve proposals and ensure that they align with our guidelines.

Note that substantial revisions to standards (beyond fixing typos, adding context or wording) should go into a new standard that extends or revises the old one, so as not to disrupt existing implementations.

We look forward to your contributions and helping to create a world where transactions are seamlessly formed, and applications interact with each other with ease.

Structure

The BRCs repository is organized into directories, each representing a different category of proposal. Categories may include, but are not limited to:

• Transaction Templates

• Bitcoin Script Templates

• Communication Protocols

Each proposal should be written as a markdown file and should loosely adhere to the following:

• Title: A descriptive title for the standard being defined.

• Author(s): Who wrote the standard and where did it come from? How can they be reached?

• Abstract: A brief description of the proposed standard or template.

• Motivation: The reasoning behind the proposal and why it is needed.

• Specification: A detailed technical specification of the proposal.

• Implementations: Information on how the proposal has been or can be implemented.

• References: Any relevant literature or external resources related to the proposal.

Note that additional relevant content, identifiers or other information may be added to the document. Documents that already existed before the repository may not follow these requirements.

Things that help depict and understand the document, such as media, may also be added in a media subdirectory where appropriate.

Standards

License

Ty Everett (ty@projectbabbage.com)

Abstract

Motivation

Specification

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

Jane Doe (jane.doe@example.com)

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)1 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'.

4. To ensure wallet security, any unauthorized squeezes will cause the banana to emit a loud, defensive "peel screech" to deter potential attackers.

5. Wallets will be recharged by leaving them in direct sunlight for a minimum of 2 hours per day.

6. The protocol must support a minimum of 2 bananas connected simultaneously to avoid a single point of failure2.

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.

5. Web-based applications must visually display the connection and energy status of each banana wallet.

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.

Brayden Langley (brayden@projectbabbage.com)

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 BRC-9. The required message structure and fields are defined below in the Payment Submission Message section, and the expected response to provide is defined in the Payment Acknowledgment Message 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.

Motivation

BRC-50 standardizes payment submission to a wallet, improving the user experience for incoming Bitcoin payments. This enables higher-layer applications to add funds to a user's wallet without needing to maintain their own external balance. By standardizing payment submission, developers can create interoperable, extensible, and SPV compliant applications. This ensures a seamless and secure payment process, benefiting both wallet providers and end-users.

Specification

For this specification, we assume that there exists a wallet that facilitates a channel by which communication can occur with an application, such as over HTTP as defined in BRC-5. Based on this premise, we specify a standard by which payments can be submitted from an application to a wallet which then receives and processes the payment.

Payment Submission Message

We define an extension to the abstract BRC-1 messaging layer as the Payment Submission Message which comprises a JSON object with the following fields:

Several of the same fields as defined in BRC-29 are present in this message. This standard essentially facilitates an implementation of BRC-29 over an abstract, wallet-to-application interface.

The transaction field is a JSON object that conforms to the BRC-8, with the BRC-29 Outputs Extension. Only one transaction can be submitted per request.

This provides the wallet with enough information to verify and receive payments from an application.

Here is an example of a simple Payment Submission Message:

{
  "protocol": "3241645161d8", // Simple Authenticated BSV P2PKH Payment Protocol
  "transaction": {
    "rawTx": "01000000017...",
    "inputs": {
        "b7d1297158f01bfc3fdace31f62a0d4634e9471d11b2a99f0784621cedb9367c": {
        "proof": {...},
        "rawTx": "01000000011..."
        }
    },
    "mapiResponses": [...],
    "txid": "737a1e90af9745da3f22ef74bc71a089c5e2a76e9662a0c9fa5b7cf94fe32e75"
  },
  "senderIdentityKey": "031d903f5b32a6121f29c59c547d2ea41ee8157ab0f0c2b5190be24a032816f827",
  "note": "Payment for spelling fix pull request.",
  "amount": 1033,
  "derivationPrefix:": "8217bb4e7fa0541e0f5e04fea764ab91"
}

Payment Acknowledgment Message

The Payment Acknowledgment Message is the response that should be returned from the wallet to the calling application with the status of the request, and a reference number for the transaction submitted.

Here is an example response from a successful payment submission:

{
  "reference": "cd5b1e4947e304476c788cd474fb579a"
}

Payment Error Message

If an error occurs during submission, an internal error should be thrown which can be caught and handled by the application code.

Implementation

Wallets can implement this specification by providing access to a submitDirectTransaction route over a given BRC-1 communications substrate, such as BRC-5, BRC-6 or BRC-7.

A specific implementation of this BRC can be seen in the Babbage Dojo/Ninja architecture.

Ty Everett (ty@projectbabbage.com)

Abstract

We define an extension to BRC-1 that enables a wallet to facilitate the tracking of specific application-defined transaction outputs within baskets. A new set of messages across the abstract messaging interface facilitates applications' access to unspent outputs stored in these baskets, with a permission system similar to that described in BRC-43 employed to regulate access by applications. Spending an output stored in a basket removes it, while new outputs can be added by specifying their basket as part of BRC-1 transaction creation requests.

Motivation

Transaction outputs in Bitcoin take many forms, and serve many purposes. While BRC-1 defines a way for applications to request the creation of transaction outputs by wallets, there is no way for applications to request that a wallet tracks these outputs. Enabling applications to request that wallets track outputs provides a number of advantages: First, applications may no longer need to rely on external data storage and retrieval systems, simplifying their architecture. Second, there is the potential to represent different types of Bitcoin-native tokens within specific baskets, and define protocols for manipulating specific types of tokens based on which baskets they are stored in. Finally, when permission to access a basket is decided by the user on a per-application basis, it facilitates a greater degree of control for users over their tokens, enabling multiple applications to access and use the same tokens.

Specification

We extend the BRC-1 Transaction Creation Request message so that, in addition to the normal script and satoshis fields defined in each element of the outputs array, there is another basket field. The new basket field is a string comprising the name of the basket into which this output is to be inserted and tracked by the wallet. We specify that, when a wallet creates a transaction responsive to the Transaction Creation Request, it utilizes some internal storage and retrieval system (beyond the scope of this specification) to associate the specified output with the specified basket.

To allow applications to specify information that would later be needed to unlock and use outputs that are stored in baskets, an optional customInstructions field can also be added when basket is given. This field is retained by the wallet and included as part of the Transaction Outputs Response (defined below).

To facilitate permissioned access to baskets by applications, we stipulate that the wallet, upon receiving a transaction creation request, may prompt the user to grant permission for the application to use the basket. The method by which the wallet seeks the consent of the user is out-of-scope for this standard, but the process, if it occurs, must be facilitated by the wallet asynchronously between the receipt of the Transaction Creation Request and the furnishment of any Transaction Creation Response or Transaction Creation Error messages.

To facilitate access to the tokens stored within baskets by applications, we define a new set of messages across the abstract communications channel between the wallet and the application, as follows:

Transaction Outputs Request

This message constitutes a request by the application for a list of Bitcoin UTXOs that are responsive to the request. The message contains the following information:

This provides the wallet with enough information to furnish the outputs requested by the application. Here is an example of a simple Transaction Outputs Request in JSON:

{
  "basket": "todo tokens",
  "includeEnvelope": true,
  "limit": 25,
  "offset": 0,
  "spendable": true
}

In this example, the application is stipulating that a maximum of 25 outputs from the todo tokens basket are to be returned, including their BRC-8 transaction envelopes.

Transaction Outputs Response

The response comprises a list of transaction outputs currently in the specified basket. This is an array of objects where each object has the following fields:

Here is an example of a simple Transaction Outputs Response:

[{
  "amount":1000,
  "customInstructions":null,
  "envelope":{
    "rawTx":"010000000135620d3a8fb626b763cb7b9a3c3197eda9bd6709ef1e4ebc2b359607800eaa95020000006b483045022100c3ec1792f1780e453c6ea692271bcc5388fb179d6455897f4b4200706e8b9f150220352cc2ff81a5c698e4626aec8976643134efab91ca1c80729670c2d007c77cfd4121037798f038cb7fc18b9d67baa87ed33122eb7be65b95b0dd304dc476c60043773dffffffff03e803000000000000c4210399322f558d92ced9c45d3bfe7dc5c01b830a4b61d71695ab0a1fa2cd90aba8b9ac2131546f446f44744b7265457a6248594b466a6d6f42756475466d53585855475a473462812d4eeb030fa496c2965f7e0f0b0e825d0547aceb7a9d4c76fd17e795753d8e2e0e82274ab36744a7968a43dc45b1cbdfab6c473045022100a58914da5346960ecb4de964f0f1e1be43a7645a11449c3a209f3fd69b34209b02205d4d4294d04c5f87fb16c2cdc3d9b41f9866fb3d7a690da08089c972d1393d816d75c8000000000000001976a91473a95c0b12e33b3d79f80508200a075bbab0906588ac4ea80200000000001976a91478daf10df51b3ea4c9292a72bf2e1e1d48ebe11288ac00000000",
    "mapiResponses":[{
      "publicKey":"030d1fe5c1b560efe196ba40540ce9017c20daa9504c4c4cec6184fc702d9f274e",
      "payload":"{\"apiVersion\":\"1.5.0\",\"timestamp\":\"2023-04-07T08:19:10.2186219Z\",\"txid\":\"900b7e9ced44f8a7605bd4c1b7054b8fb958385998954d772820a8b81eabb56f\",\"returnResult\":\"success\",\"resultDescription\":\"\",\"minerId\":\"030d1fe5c1b560efe196ba40540ce9017c20daa9504c4c4cec6184fc702d9f274e\",\"currentHighestBlockHash\":\"000000000000032b2a17b3003b5cbb484b284bda4ffd7c15edd6c038429840ed\",\"currentHighestBlockHeight\":1545664,\"txSecondMempoolExpiry\":0,\"warnings\":[],\"failureRetryable\":false}",
      "signature":"30440220066e711073f08d6302a33acb2863557b13465f5381a3355eaee9a5e08909abfc0220695fedf9800226d9f430f8a0177c1e4bde8134d350a8eb3bfd0d5d77925cac4d"
    }],
    "inputs":{
      "95aa0e800796352bbc4e1eef0967bda9ed97313c9a7bcb63b726b68f3a0d6235":{
        "rawTx":"0100000001ce31fcf049468a1e3a2cd56c598d5452f6bfbc95bac036eda769531795e3198c020000006a4730440220721e1e12c2540cccf01fed09560daf2dddebec959e39481c6f27bf366d8b3c5d0220040562db8f91b13b7ad33ac9f01adbbfa748c375ff2c8201929828537e7fb81841210306d6a463a7f204b050ffeba596fe9a2466f416b008d6954ce425304660abe450ffffffff0322020000000000001976a914268b68eb0ee5ed10decbf38fa47cdc2e3df7af2b88acc8000000000000001976a91426db399bdfe2ff5e413c60930b3f760a4db625db88ac30ad0200000000001976a9149cbb583bcc1d80d37669e930dca22655d621990088ac00000000",
        "proof":{
          "txOrId":"95aa0e800796352bbc4e1eef0967bda9ed97313c9a7bcb63b726b68f3a0d6235","target":"a4f45102baefabafb1ad7376f754c219411e45439fd31c2b082051f0e58e08e3",
          "targetType":"merkleRoot",
          "nodes":[
            "8d8403f47e3e9a461848b5d45ee173d49ef4afb2c952e26ff2ffa95e2ae96a7c",
            "04f653cc1e2e5376600ec83c93d3ac7309dd29662b69f329511a020c9ecf5b67",
            "3c8a8b183008fa56dfe432ab7ccb10e47e36537c21a152466de7e1a3572a5286",
            "cb798749f39ce21c360cea90973a2eeb4740a7db05b7f42f1b33b81448369753",
            "3fb4036561bb38c0c2096512818bcfc425ead33f0a10272def77d8bf6243ae94"
          ],
          "index":15
        }
      }
    }
  },
  "outputScript":"210399322f558d92ced9c45d3bfe7dc5c01b830a4b61d71695ab0a1fa2cd90aba8b9ac2131546f446f44744b7265457a6248594b466a6d6f42756475466d53585855475a473462812d4eeb030fa496c2965f7e0f0b0e825d0547aceb7a9d4c76fd17e795753d8e2e0e82274ab36744a7968a43dc45b1cbdfab6c473045022100a58914da5346960ecb4de964f0f1e1be43a7645a11449c3a209f3fd69b34209b02205d4d4294d04c5f87fb16c2cdc3d9b41f9866fb3d7a690da08089c972d1393d816d75",
  "spendable":true,
  "txid":"900b7e9ced44f8a7605bd4c1b7054b8fb958385998954d772820a8b81eabb56f",
  "vout":0
}]

Transaction Outputs Error

If the Bitcoin wallet is unable to fulfill the Transaction Outputs Request for any reason, we specify that it should respond with a JSON-formatted Transaction Outputs Error. The fields for the object are specified as follows:

One example of a Transaction Outputs Error is given below:

{
  "status": "error",
  "code": "ERR_PERMISSION_DENIED",
  "description": "You have denied permission for accessing this output basket."
}

Implementations

This functionality is implemented as part of the Babbage SDK, via the getTransactionOutputs function.

Ty Everett (ty@projectbabbage.com)

Abstract

We define methods for an application to request that a wallet create and prove BRC-52 identity certificates. We define a set of additional messages that extend the BRC-1 application-to-wallet messaging layer with this functionality. We specify the functionality to be performed by the wallet as part of these processes, including a standard methodology for wallets to contact identity certificate certifiers over HTTP and carry out the signing of these documents. To keep users in control over how their data is processed and used, we allow for the wallet to obtain user consent prior to carrying out these operations.

Motivation

The BRC-52 identity certificate standard provides a decentralized, privacy-centric solution to digital identity, allowing users to selectively reveal their identity data. However, without a standard method for applications to create and prove these certificates, wallet support will be limited. BRC-53 provides a set of standardized methods for applications to request and interact with BRC-52 certificates, enabling wider adoption and integration of BRC-52 certificates within the ecosystem.

Specification

We define two new sets of messages to be sent over the abstract BRC-1 messaging layer:

Certificate Creation Request

An application may request a wallet to create a BRC-52 certificate by providing the following parameters:

The wallet will then carry out the following steps:

1. Initialize a BRC-53 client with the primary identity key of the wallet.

2. Generate a client nonce.

3. Request the validationKey and serialNumber from the certifier by making a BRC-53-enabled HTTPS POST request to the certifierUrl's /initialRequest endpoint with the client nonce.

4. Validate the received serialNumber and validationKey using the client and server nonces.

5. Encrypt the fields of the fieldObject using BRC-2 encryption and store the concealed fields and encrypted field revelation keys in the fields and keyring objects, respectively.

6. Create a Certificate Signing Request (CSR) containing the certificate type, nonces, validation key, serial number, fields, and keyring.

7. Send the CSR to the certifier's /signCertificate endpoint via an HTTP POST request.

8. Receive and verify the signed certificate's authenticity.

9. Store the signed certificate in the wallet's data store (how the wallet stores its data is beyond the scope of this specification).

Certificate Creation Response

The response sent back over the abstract messaging layer from the wallet to the application will constitute a valid, fully-signed BRC-52 identity certificate with no keyring.

Certificate Creation Error

If the Bitcoin wallet is unable to fulfill the Certificate Creation Request for any reason, we specify that it should respond with a JSON-formatted Certificate Creation Error. The fields for the object are specified as follows:

One example of a Certificate Creation Error is given below:

{
  "status": "error",
  "code": "ERR_CERTIFIER_REJECTED_CSR",
  "description": "The certifier has rejected the CSR and refused to sign the certificate."
}

Certificate Proof Request

An application may request a wallet to prove a BRC-52 certificate by providing the following parameters:

The wallet will then carry out the following steps:

1. Verify the authenticity of the provided certificate.

2. Ensure that the application and the verifier have been granted access to the requested certificate fields (optional permissions checks).

3. Decrypt the encrypted field revelation keys using the wallet's primary identity key.

4. Encrypt the decrypted field revelation keys for the verifier using the verifierPublicIdentityKey.

5. Add the encrypted field revelation keys to the certificate field revelation keyring (as defined in BRC-52) object.

6. Attach the field revelation keyring to the certificate.

7. Return the certificate with the attached field revelation keyring for presentation to the verifier for field examination.

Certificate Proof Response

The response sent back over the abstract messaging layer from the wallet to the application will constitute a valid, fully-signed BRC-52 identity certificate with the attached field revelation keyring for the verifier.

Certificate Proof Error

If the Bitcoin wallet is unable to fulfill the Certificate Proof Request for any reason, we specify that it should respond with a JSON-formatted Certificate Proof Error. The fields for the object are specified as follows:

One example of a Certificate Proof Error is given below:

{
  "status": "error",
  "code": "ERR_PERMISSION_DENIED",
  "description": "The user denied the request to reveal these fields to this verifier at this time."
}

Wallet-to-Certifier Interface

The wallet and certifier communicate in a standard way over a BRC-31 protected HTTPS interface to facilitate the requesting and signing of a certificate. Here, we specify the requirements and fields for these communications.

We require that the wallet engages in the BRC-31 authentication process with the certifier, and we further require that the wallet authenticate using the same key which is the subject of the certificate issuance process. This provides a way for the certifier to know that the person making the request is the person who will be receiving the identity certificate.

Initial Request

The wallet initiates the communication with the certifier by sending an initial request. The initial request includes a client nonce, generated randomly by the wallet. The request is sent to the /initialRequest endpoint using the HTTP POST method.

Request fields

• clientNonce: A randomly generated 32-byte string in base64 format.

The certifier processes the initial request and generates two nonces: serialNonce and validationNonce. The certifier calculates the serialNumber and validationKey by hashing the concatenation of clientNonce with the respective nonces. The certifier then returns these values in the response.

Response fields

• validationKey: A base64 encoded string calculated by hashing the concatenation of clientNonce and validationNonce using SHA256.

• serialNumber: A base64 encoded string calculated by hashing the concatenation of clientNonce and serialNonce using SHA256.

• validationNonce: A base64 encoded nonce generated by the certifier.

• serialNonce: A base64 encoded nonce generated by the certifier.

Certificate Signing Request

After receiving and validating the values from the initial request, the wallet creates a Certificate Signing Request (CSR) and sends it to the /signCertificate endpoint using the HTTP POST method.

Request fields

• messageType: The string "certificateSigningRequest".

• type: The type of certificate to create.

• clientNonce: The client nonce generated by the wallet during the initial request.

• serverSerialNonce: The serial nonce received from the certifier in the initial request.

• serverValidationNonce: The validation nonce received from the certifier in the initial request.

• validationKey: The validation key received from the certifier in the initial request.

• serialNumber: The serial number received from the certifier in the initial request.

• fields: An object containing encrypted fields of the certificate.

• keyring: An object containing encrypted field revelation keys, revealed from the subject to the certifier.

The certifier processes the CSR and signs the certificate using its private signing key. The signed certificate is then returned to the wallet in the response.

Response fields

• status: The status of the signing process, either "success" or "error".

• description: A description of the error, if applicable.

• code: An error code, if applicable.

• certificate: The signed BRC-52 certificate, if the signing process is successful.

Implementations

These processes have been implemented into the createCertificate and proveCertificate functions of the Babbage SDK. The Computing with Integrity kernel (currently proprietary) implements the wallet-to-certifier communications protocol, and CoolCert implements the certifier side of the protocol.

Ty Everett (ty@projectbabbage.com)

Abstract

We define a concise, transport-independent method by which applications can request the creation of Bitcoin transactions. We specify the use of BRC-8 transaction envelopes, and provide an open-ended and extensible approach to output stipulation by the requesting application. We define the formats for request, response and error messages exchanged between application and wallet software.

Motivation

The motivation behind this Bitcoin wallet transaction creation specification is to provide a standardized method for third-party applications to communicate with Bitcoin wallets. This specification aims to enable applications to request the creation of Bitcoin transactions in a concise and transport-independent way, and to allow wallets to focus on wallet and Bitcoin infrastructure, rather than application-specific functionality — conversely, applications can avoid re-inventing the wheel and the need to become their own Bitcoin wallet and infrastructure providers.

By standardizing the communication protocol between applications and wallets, this specification aims to simplify the development of Bitcoin-related applications, reduce development time and costs, and improve the user experience of Bitcoin-powered applications. Additionally, this specification aims to promote interoperability between different wallets and applications, making it easier for users to switch between wallets and for applications to work with multiple wallets.

Implementing this specification will provide a standard way for web and mobile applications to interface with on-device Bitcoin wallets, improving the security of Bitcoin-related operations and enabling users to better control their Bitcoin transactions. With this specification, applications can avoid the overhead of creating their own Bitcoin wallets, and wallets can focus on their core functionality of managing Bitcoin keys, signing transactions, and interacting with the Bitcoin network.

Overall, this specification aims to provide a simple, open-ended, and extensible approach to Bitcoin transaction creation, with a transport-independent method of communication that enables wallets and applications to work together seamlessly.

Pre-Requisites

In order to implement this specification, Bitcoin wallet software must be able to perform the following functions:

• Create Bitcoin transactions with any number of outputs that use arbitrary Bitcoin scripts and amounts.

• Prompt the user for acceptance of transactions requested by third-party applications.

• Unlock a sufficient number of UTXOs to fund the transaction and capture left-over change outputs.

• Provide merkle proofs on all inputs to build the BRC-81 formatted response.

Wallets that meet these pre-requisites will be able to fulfill the requirements of this specification.

Scope

The scope of this specification is the definition of standard JSON formats for requesting the creation of a Bitcoin transaction, providing the completed transaction once created, and any errors that prevent the transaction from being created.

The specification is intended to be transport-independent, so considerations related to how these messages are communicated, or matters related to the security or authenticity of such communications, are beyond the scope of this specification.

We have sought to keep the base version of this specification as minimal as possible, while still providing all the information needed by applications. Therefore, we have decided to exclude arbitrary input redemption from this specification, and move it to an extension — namely, BRC-4. We have also chosen to exclude transaction output tracking from the base specification, moving it to BRC-46.

Specification

We specify that there are two relevant parties: an application and a Bitcoin wallet. The application is software that runs on an end-user device (such as a webpage, mobile app, or desktop app) that wants to make use of Bitcoin without building wallet infrastructure themselves. The wallet is software that runs on an end-user device that specializes in the management of a user's Bitcoin-related identity information, private keys, facilitates the transaction creation and signing process, and communicates with the Bitcoin network.

We specify that there exists some abstract communications channel (beyond the scope of this specification) that enables the application and the Bitcoin wallet to communicate in a secure and authenticated manner. This mechanism must facilitate the application making a request to the Bitcoin wallet, and the wallet providing a response back to the application.

We specify that JSON is the format that will be used for the messages exchanged in accordance with this specification. We further specify that there exists some out-of-band means for the application to indicate to the Bitcoin wallet that it intends to invoke and utilize this BRC-1 protocol, as opposed to some other protocol.

For example, if the underlying communications method was HTTP (BRC-5), the application could indicate its intention to use this protocol by sending requests to /v1/createAction instead of /v1/foobar. In effect, this means that there is no need for JSON fields in this specification denoting the message type, since both parties have already established that they are exchanging messages according to the BRC-1 protocol. Specific communication mechanisms that facilitate this are defined by other standards such as BRC-5, BRC-6 and BRC-7.

Transaction Creation Request

We specify that the first message exchanged under this BRC-1 protocol originates from the application, and constitutes a request by the application that a Bitcoin transaction be created by the Bitcoin wallet, as specified by the application.

The Transaction Creation Request comprises a JSON object with the following fields, all of which are required:

Output Objects are JSON objects that have the following fields:

This provides the wallet with enough information to create the transaction requested by the application. Here is an example of a simple Transaction Creation Request:

{
  "description": "Pay John Galt 3,301 satoshis",
  "outputs": [{
    "script": "76a914b10f7d6c7fda3285e9b98297428ed814374cbd4088ac",
    "satoshis": 3301
  }]
}

In this example, the application is stipulating that one output should be created, containing 3301 satoshis, and that the output should be locked using a pay-to-public-key-hash (BRC-16) locking script.

The application also provides a simple description that can be used by the wallet when prompting the user for authorization to proceed with the creation of the transaction, or later when showing the transaction in a list.

Transaction Creation Response

If the transaction is successfully created by the Bitcoin wallet according to the instructions provided by the application, we specify that the Bitcoin wallet assembles a BRC-8 Transaction Envelope and returns it to the user. We specify that, in addition to the required BRC-8 envelope fields, a txid field is also included in the returned Envelope Object for the convenience of the application.

For added clarity, we denote a table comprising the standard BRC-8 Transaction Envelope fields with our additional txid field:

Here is an example of a simple Transaction Creation Response:

{
  "rawTx": "01000000017c36b9ed1c6284079fa9b2111d47e934460d2af631ceda3ffc1bf0587129d1b7020000006b483045022100c655d8c0bfc895c861dda240010c23d5267fd4414894794d3f3591fb7d59fe090220627246ff28e1776c34fd09fbbcfc5bb2efa8090350b35192f1638dd9143ea2a8412102c6848b9988deb921e645fbac47f196e7bec44a6f8612874632240aadc4a35b5bffffffff03e50c0000000000001976a914b10f7d6c7fda3285e9b98297428ed814374cbd4088acc8000000000000001976a914652138f4b89dd615def2c3aa7e13bc1900b5cff588ac1f450000000000001976a91428e5b6157e4a72d8bc8d2374f7acec1388be52f988ac00000000",
  "inputs": {
    "b7d1297158f01bfc3fdace31f62a0d4634e9471d11b2a99f0784621cedb9367c": {
      "proof": {
        "index": 16349,
        "txOrId": "b7d1297158f01bfc3fdace31f62a0d4634e9471d11b2a99f0784621cedb9367c",
        "targetType": "header",
        "target": "00c0322ac50d5e7f9cb2f9be53a34f78fe1cdd7029a03eeeb50b780000000000000000002cb6066c3101dddf29a7853051487bada9adeb9807d2ab4360ca47d3c30581138d9a1264eb370d1802029180",
        "nodes": [
          "95733f96fa3a1f0ba779627d7dc62891f6eee8a13eb0e5a5610bf0d5d1686401",
          "ac95afde3cb7d2f639e3a36d07db7b0becc4bbcb393dce51e322adc38f78c5a1",
          "4054dae1209fa48797dc459239eb396b6220618c9a8bd93776f7485f14759fb7",
          "8f6327bf637241b3e5b029475f3bf5856b263248fa18272e04ec8dae35131351",
          "4da5d84ccde803ba4515ee1f8912b49c738bbc145850d1f88885474ff57d1f58",
          "ec1e6e5c0f50ac2eb8e493c1c372aedde359cbf706643a6bdfaa3aebf4996f01",
          "cedf75aa7314f898121bccdf27eb8b6769262324460a98bf84cdaa6a0379895e",
          "246a798ac6e7e3a5893cb24aa26ca92f71309f41200e1fafbad33a138ea709d6",
          "a5df0501e2c74677b0201fa2b2a6b9cf4156f8266bbc73767e4a784d0793d557",
          "774bdbf5a5992baf1aea1cb80afb68ed93d03aba37b16b57c9fb4cf596e522e6",
          "b621a1f5f431843ed450a09c9a09f245290db204ffe2068732b7c278f4fa2605",
          "93dd7a58841fa52e8d1ac8e5d4bef852450a716c79a603dd4b85772abd0cc0db",
          "57860c6a1f278979fc4540c98f43dc41d64c6f52dffa6aaaf7b07d206e8ca5b5",
          "5de27bdb3b0123c2149d3cc8a54cab926ddc50f93639b02be0885ff9c4365fc8",
          "5cdd1beb2c59b2dbf9be5790633c0a58ea274e2669f52226343648c1a1ca31cc",
          "560490ecae5c1d075dbaf6ee26b61bd758bfbadd09a6cee475156f1b0a3fc9c7"
        ]
      },
      "rawTx": "01000000011a348074d8fe477dec48fe3c07b493371c9fa8b5a49d5d0424916a65b65e77be020000006b4830450221009acfd97f48c819d0fe0ae59df2110eb8a7f6defe948bcf556562b4d1f5e7129602202586aa5f2cb767eba3978aa3185f09e8ec745fcb1111296ca42fb384f7355b6c412102466ef576171e0e0684081f2a99b5e6b5786dac80b5d6d64fec3b033628763a4fffffffff0394070000000000001976a914d75cf5dc3ce0767b005b71b2a8705809ba4b815088acc8000000000000001976a914931c8716ddfb85f4ea4bbdad395d27bd6323b57688acea520000000000001976a914dbdbf9c3216c9cf526e18bc9f976018881972fff88ac00000000"
    }
  },
  "mapiResponses": [
    {
      "payload": "{\"apiVersion\":\"\",\"timestamp\":\"2023-03-17T05:09:51.554Z\",\"txid\":\"737a1e90af9745da3f22ef74bc71a089c5e2a76e9662a0c9fa5b7cf94fe32e75\",\"returnResult\":\"success\",\"resultDescription\":\"\",\"minerId\":\"03ad780153c47df915b3d2e23af727c68facaca4facd5f155bf5018b979b9aeb83\",\"currentHighestBlockHash\":\"00000000000000000138b377cab18dc72cc7ac38d6631949c9694071855bcce8\",\"currentHighestBlockHeight\":783508,\"txSecondMempoolExpiry\":0}",
      "publicKey": "03ad780153c47df915b3d2e23af727c68facaca4facd5f155bf5018b979b9aeb83",
      "signature": "304402201529238a9cf64b02dad0d4573ef5a0780bddb2fe6d6afdca1473e340a6e1512202204845c0721bdb8b6b8ec0e255f120e5749c373a8e2fe13fed208c3154197846c0"
    },
    {
      "payload": "{\"apiVersion\":\"1.5.0\",\"timestamp\":\"2023-03-17T05:09:51.7263993Z\",\"txid\":\"737a1e90af9745da3f22ef74bc71a089c5e2a76e9662a0c9fa5b7cf94fe32e75\",\"returnResult\":\"success\",\"resultDescription\":\"\",\"minerId\":\"030d1fe5c1b560efe196ba40540ce9017c20daa9504c4c4cec6184fc702d9f274e\",\"currentHighestBlockHash\":\"00000000000000000138b377cab18dc72cc7ac38d6631949c9694071855bcce8\",\"currentHighestBlockHeight\":783508,\"txSecondMempoolExpiry\":0,\"warnings\":[],\"failureRetryable\":false}",
      "publicKey": "030d1fe5c1b560efe196ba40540ce9017c20daa9504c4c4cec6184fc702d9f274e",
      "signature": "3044022013546dbe4b9f402ae684f3ac51bbdef5ebe5a1b1abd646b04b9a35e94515a29e022041f4b047caa6d49d1fc4ff202646939d91abd661776d75d9e5dee6b2b355645a"
    }
  ],
  "txid": "737a1e90af9745da3f22ef74bc71a089c5e2a76e9662a0c9fa5b7cf94fe32e75"
}

Transaction Creation Error

If the Bitcoin wallet is unable to fulfill the Transaction Creation Request for any reason, we specify that it should respond with a JSON-formatted Transaction Creation Error. The fields for the object are specified as follows:

One example of a Transaction Creation Error is given below:

{
  "status": "error",
  "code": "ERR_PERMISSION_DENIED",
  "description": "You have denied permission for creating this Bitcoin transaction."
}

Implementations

This specification has been implemented into various wallets and applications:

• The Babbage MetaNet Client implements BRC-5, the local HTTP substrate including this specification. Transaction Creation Request objcts are sent to the client, which then returns either a Transaction Creation Response or a Transaction Creation Error, after prompting the user.

• Babbage has implemented a ToDo List application that creates Transaction Creation Request objects which are then received and processed by any wallet software running on a user device that implements this specification.

• The Ninja Bitcoin wallet, through its getTransactionWithOutputs function, accepts a Transaction Creation Request and returns either a Transaction Creation Response or a Transaction Creation Error.

References

• 1: Transaction responses are BRC-8 Transaction Envelopes

• Brayden Langley (brayden@projectbabbage.com)

• Ty Everett (ty@projectbabbage.com)

Abstract

The Bitcoin Wallet HTTP Interface is a standard interface that enables applications to connect with Bitcoin wallets to facilitate certain functionality. The interface provides a unified way for applications to request the creation of a Bitcoin transaction, encryption, digital signature creation, and other features provided by the wallet. By standardizing the interface, applications can support multiple wallets and give the user greater control over their Bitcoin-related activities.

Motivation

The motivation for this standard interface is to provide a common way for applications to connect with Bitcoin wallets. Currently, many Bitcoin wallets provide their own APIs, which makes it difficult for applications to support multiple wallets. The Bitcoin Wallet HTTP Interface standardizes the way that applications can interact with wallets, enabling them to be more easily integrated into various applications. This interface is designed to be flexible enough to support a range of wallets and use cases, while also providing a secure and standardized method of communication.

Specification

We define a standard HTTP substrate by which wallets can provide a communication channel to applications for the necessary tasks such as creating transactions, creating certificates, signature verification, and more.

All implementors of the HTTP substrate should conform to the following standard for the wallet HTTP API that allows applications to communicate in a predefined and standard way.

Host

We define the wallet HTTP server to support communication over localhost on port 3301. New API versions can be specified as needed using the standard of v1, v2, etc.

Host URL: http://localhost
Standard Port: 3301
Versioning Standard: v1, v2, etc

Example Encrypt Request URL: http://localhost:3301/v1/encrypt

Standard HTTP Requests

We define standardized HTTP requests that applications can use to communicate with wallets for performing various tasks.

JavaScript Code Example

const httpResult = await makeHttpRequest(
      'http://localhost:3301/v1/<routeName>',
      {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json'
        },
        body: JSON.stringify({
          <requestBody>
        })
      }
    )

Implementation

Implementers of applications and wallets will need to create and process HTTP requests in the manner described, according to the various fields and properties as required by BRC-56, and in a manner consistent with the reference implementation, which is the Babbage SDK's HTTP substrate functionality.

Brayden Langley (brayden@projectbabbage.com)

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.

Motivation

The motivation behind this standard is to enable web browsers to directly integrate Bitcoin wallet functionality without relying on an additional application running on the client's device.

Although BRC-5 defines a standard for local communication over HTTP, integrating wallet functionality in the browser eliminates the need for external wallet applications, reducing the overhead of inter-process communication and network requests.

This also eliminates the need for users to switch between multiple applications when approving permissions, creating transactions, etc. They can perform all wallet-related tasks within the web application they are already using, resulting in a more cohesive and convenient user experience.

Specification

We define a specification for providing access to Bitcoin wallet functionality via the global window object that is directly available in all standard browser implementations.

Once the browser has verified that the user is authenticated, an object labeled CWI should be added to the window object to provide access to the standard wallet functionality as defined by BRC-56.

Standard CWI Functions Associated with Various Message Types

For each of the message pairs (request and response) incorporated into BRC-56, we specify the existence of a corresponding message type with a specific function name:

This will allow applications to call functions with the following syntax:

window.CWI.<functionName>

Parameter Format Specification

We specify that all required parameters are provided in an object to the CWI functions.

Example Identity Key Request

const identityKey = await window.CWI.getPublicKey({ 
    identityKey: true 
})

Example Encrypt Function

const ciphertext = await window.CWI.encrypt({
  plaintext: Buffer.from('Hello BRCs!'),
  protocolID: [0, 'Hello World'],
  keyID: '1'
})

Implementation

Implementors of this BRC should follow the abstract messaging layer as defined by BRC-56 to provide support for standard messaging types, and then modify the window object created to include this functionality in a CWI object.

Ty Everett (ty@projectbabbage.com)

Abstract

This specification outlines the architecture and structure of permissions granted to apps. It focuses on the grouping of permissions to provide a concise overview for users. The key permissions include Protocol Permissions, Spending Authorizations, Basket Access, and Certificate Field Access Grants.

Motivation

As applications become more integrated with user data and cryptographic operations, the need for a clear and concise permission system has never been greater. This specification seeks to simplify user decisions by grouping permissions, ensuring transparency and user autonomy over their identities, their data and their digital assets.

Specification

Overview of Permission Types

There are four primary permission types that apps can be granted by users, each with its significance, function, and associated specifications:

1. Protocol Permissions (BRC-43): This permission grants an application the ability to utilize a user's keys to execute cryptographic operations (such as BRC-2 encryption or BRC-3 digital signatures).

2. Spending Authorizations (BRC-1): As the name suggests, this allows apps to transact or spend a predefined number of satoshis over a specified time frame, within BRC-1 transactions.

3. Basket Access (BRC-46): This pertains to the app's capability to insert into and spend UTXO-based tokens from specific BRC-46 Output Baskets. The significance of this permission is to manage token operations within the app ecosystem. Each "basket" can be thought of as a container or grouping for tokens, and BRC-46 provides the framework for how apps can interact with these baskets, ensuring a structured approach to token management.

4. Certificate Field Access Grants (BRC-52): This is about identity verification. The permission allows an app to reveal specific fields from a BRC-52 identity certificate to designated verifiers. It's a crucial step in processes that require identity verification or authentication.

Group Permission Trigger Methodology

• Applications initiate the permission request process via a new requestGroupPermission function, which is added to the BRC-56 suite.

• Wallets determine the group permissions from the application's manifest.json file. Alternatively, the groupPermissions object can be provided by the application to the requestGroupPermission function.

• The user receives a prompt detailing the permissions. They can choose to accept or deny each or all permissions. The wallet then applies their choices.

Manifest File - manifest.json

• The file is to be served over HTTPS and requested from the application by the wallet. HTTP is only accepted when running on localhost for development purposes.

• The existing babbage key is expanded to include the groupPermissions key.

• The groupPermissions key holds four subsequent keys representing the categories of permissions: protocolPermissions, spendingAuthorization, basketAccess, and certificateAccess.

Definition for groupPermissions key in manifest.json

The groupPermissions key is an object that encompasses various types of permissions, which the app might request from a user. This key contains four sub-keys: protocolPermissions, spendingAuthorization, basketAccess, and certificateAccess.

1. protocolPermissions is an array of objects, where each object defines a specific Protocol Permission. Each object contains three fields: protocolID (a protocol ID array with two elements, the first a security level and the second a protocol string), counterparty (a string in hexadecimal format representing a public key, required only if the security level of the protocolID is 2), and description (a short text explaining the purpose of this request).

2. spendingAuthorization is an object that provides details about the satoshis an app is requesting authorization to spend. It has three fields: amount (a number indicating the amount in satoshis), duration (a number representing the time in seconds for the authorization's validity), and description.

3. basketAccess is an array of objects, where each object denotes the access to a specific BRC-46 basket. The objects here have two fields: basket (the name of the BRC-46 basket) and description.

4. certificateAccess is an array of objects that represent the different certificate types an app wants access to. Each object here consists of type (indicating the certificate type), fields (an array of strings naming the fields the app wants to reveal), verifierPublicKey (a string in hex format, representing the public key of the verifier), and description.

With this structured approach, app developers can seamlessly integrate their permission requests within their manifest.json, and users can be assured of a clear understanding of the permissions they're granting.

For the avoidance of doubt, the following sections provide tables that define each specific field, and example data structures.

Table 1: General Structure

Table 2: Protocol Permissions Object Structure

Table 3: Spending Authorization Object Structure

Table 4: Basket Access Object Structure

Table 5: Certificate Access Object Structure

Examples

1. protocolPermissions Example:
2. spendingAuthorization Example:
3. basketAccess Example:
4. certificateAccess Example:
5. Full manifest.json Example:

App developers should prioritize user understanding and transparency when requesting permissions. The description field must be utilized effectively to convey the reason for the request, allowing users to make informed decisions.

This approach ensures a streamlined and transparent process for apps to request and for users to grant permissions. It promotes a higher level of trust and clarity between applications and their users.

Ty Everett (ty@projectbabbage.com)

Abstract

Motivation

Specification

When an application sends a message to a client requesting that data be encrypted, the message comprises:

• The data to encrypt

We stipulate the following process for encryption:

• The message sender computes the ECDH shared secret between the two derived child keys

• The resulting elliptic curve point's X and Y values are hashed with SHA256 to create an AES-256-GCM symmetric encryption key

• The resulting 256-bit value is used in conjunction with a randomly-generated 256-bit initialization vector to encrypt the message with AES-256-GCM

We stipulate the following process for message decryption:

• The recipient somehow comes to know the ciphertext (prepended with the initialization vector), the counterparty, the security level, protocol ID, and key ID. The mechanism for conveying this information to the recipient is beyond the scope of this specification.

• The recipient uses the same process to compute his own child private key

• The recipient computes a shared secret between the two child keys, using the hash of the X and Y values as an AES-256-GCM symmetric key

• The recipient then uses the symmetric key to decrypt the ciphertext with the provided initialization vector

Encryption Request

The message payload comprises the data to encrypt.

Encryption Response

The response message comprises a payload containing the encrypted ciphertext, prepended with the 32-byte initialization vector.

Decryption Request

The decryption request is a message sent by the application to the client. It contains a header with the following information:

The message payload comprises the data to decrypt, prepended with the 32-byte initialization vector.

Decryption Response

The response message comprises a payload containing the decrypted plaintext.

Cryptography Error

If the client is unable to fulfill the encryption or decryption requests for any reason, we specify that it should respond with a JSON-formatted Cryptography Error. The fields for the object are specified as follows:

One example of a Cryptography Error is given below:

Test Vectors

For compatibility with this encryption scheme, we stipulate the following:

A user who has the following identity private key...

...which implies the followign identity public key for that user...

...should be able to use security level 2, the BRC2 Test protocolID with keyID 42 and the following counterparty...

...to decrypt the message with the following ciphertext (with prepended initialization vector)...

... and receive the following plaintext:

...and to validate the message with the following HMAC...

... the message whose HMAC is above as being:

Implementations

References

• Ty Everett (ty@projectbabbage.com)

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 (ty@projectbabbage.com)

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 BRC-46 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 BRC-46 models (e.g. BRC-73 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.

Ty Everett (ty@projectbabbage.com)

Abstract

The BRC-43 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.

Motivation

The motivation for this proposal is to future-proof the BRC-43 architecture by enabling the seamless integration of new protocol permission schemes. 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 protocol permission schemes, wallets must reject operation requests using protocol IDs beginning with p (a lowercase “p” followed by a space), regardless of security level.

Future Scheme Identifiers

Future permission schemes must define their ID formats as follows:

• Scheme IDs cannot contain spaces.

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

Example Format

A protocol ID like p 222 xxxxx could represent a specific invoice number (e.g., 2-p 222 xxxxx-kkkkk), where:

• 2 indicates the BRC-43 security level.

• p designates an alternative permission scheme.

• 222 identifies the permission scheme.

• xxxxx forms the remainder of the protocol ID under the alternative scheme.

• kkkkk denotes the key ID.

Protocol 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 protocol 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:

• Permitted protocols and key IDs.

• Conditions for operation execution.

• Counterparty requirements and customizable permission attributes.

Reserved Structure

To maintain clarity and prevent conflicts:

• Protocol 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 BRC-43 models (e.g., security levels or BRC-73 paradigms), enabling flexible and innovative wallet permissions that evolve with user and application needs.

Conclusion

By reserving protocol 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.

Tone Engel (tone@kizmet.org), 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": TSC Merkle proof standardised format

Motivation

The Spec implies that a compatible implementation support the capability to lookup block hash and merkle root values, to confirm that they correspond to actual mined blocks.

The Project Babbage team has implemented a block header management system called Chaintracks primarily to support validating merkle proofs as defined in the Spec.

We have a focus on space efficiency as we target the full range of client application deployment scenarios, including mobile and IoT.

You hear that a full set of block headers is only 50MB and only grows at 4MB per year - and this is true - but it refers to the serialized binary space required for just the headers, without the indices required to implement the Spec.

Because the required indices are hash values (merkle root and block header hash), which together make up 64 of the 80 block header bytes, it is likely unavoidable that any implementation will be approximately the size of the headers themselves: To turn a hash into a height, the indices must list all the hash values paired with their height values.

While it is possible to use partial indices and trade index size for IO operations, the indices are not actually needed at all. As Elon says, "the best part is no part."

Stepping Back: What's the Point of Merkle Proofs?

The purpose of a merkle proof is to prove that a particular bit of data, a bitcoin transaction, was recorded at a particular location in the block chain.

The nodes in the proof enable the computation of what the merkle root should be for a block containing the transaction at a particular index position.

To complete the proof, it must be verified that the computed merkle root matches the actual merkle root of the target block.

Being given a merkle root value as part of the proof does NOT complete the proof.

The only thing that completes the proof is to confirm from a trusted copy of block headers that one exists with the computed merkle root value.

Being given a merkle root, block hash, or block header as part of the proof is only useful as an identifier for which block header to check in the trusted copy. If a matching block header isn't found, the proof is invalid, no matter what additional target values are provided.

Furthermore, if the trusted copy includes a merkle root index, then proof can be completed directly from the computed merkle root value: Look it up in your own index, if it is found, the proof is valid and the block is identified.

It is therefore the case, that the existing target and targetType values in a proof per the Spec are unnecessary.

It may actually be the case, that the only useful targetType would be height. With a height value, no indices are needed at all, the target block header can be found directly since all headers are exactly 80 bytes long. The trusted copy does not require any indices.

Specification

1. Add height as a supported targetType

In "Binary form", proofs reserve two bits of "flags" bytes (bits 1 and 2) to identify what the "JSON form" calls the targetType of the proof.

Here are the current and proposed values for targetType:

2. Deprecate targetType Other Than height

As discussed in Motivation above, the existing target types and target values are irrelevant to being able to complete a merkle proof given the remaining values.

Implementations

The Project Babbage Chaintracks package currently implements the Spec with this extension.

A comparison of Chaintracks and the Pulse block header packages is listed under References.

References

• The "Spec": TSC Merkle proof standardised format

• Bitcoin VarInt

• Review of Pulse and Comparison With Chaintracks

Ty Everett (ty@projectbabbage.com)

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

Motivation

The use of Bitcoin as a means of payment and store of value has gained significant traction in recent years. As the adoption of Bitcoin continues to increase, there is a need for a standard format for the envelopes that contain Bitcoin transactions. The lack of a standardized format for envelopes can lead to interoperability issues and hinder the development of new Bitcoin-native applications.

The SPV process, outlined in BRC-9, allows payment recipients to verify the validity of a transaction without downloading and verifying the entire blockchain. However, without a standard methodology for exchanging the required merkle proofs and input transactions, applications and businesses are unable to fully benefit from adopting SPV. BRC-8 addresses this issue by providing a consistent format for transaction envelopes that can be used for SPV.

Specification:

We specify that the Everett-style Transaction Envelope is a JSON object that consists of the following fields:

• rawTx (required): The BRC-12 hex transaction contained in the envelope in serialized hex string format.

• inputs (required unless proof is provided): An object whose keys are TXIDs of each of the outpoints spent by the transaction. The values are objects containing:

  • rawTx (required): The transaction that was spent in serialized hex string format.

  • proof (required unless inputs is provided): If the transaction is confirmed in a block, the SPV proof of the transaction's inclusion is given in BRC-10 format as a JSON object.

  • mapiResponses (optional): An array of signed mAPI response objects, each of which is an object conforming to the mAPI specifications (either a successful broadcast acknowledgment or an affirmative status response).

  • inputs (optional): If the transaction is not yet confirmed in a block, this field is the same as the field from the root object, except referring to the previous transaction instead of the root transaction. The field nests recursively back in the tree of the previous unconfirmed transactions until each of the branches can ultimately be traced back to the chain of blocks with a proof at the end.

• proof (optional): If the root transaction in the envelope is already confirmed in a block, the SPV proof of the transaction’s inclusion is given in BRC-10 format as a JSON object.

• mapiResponses (optional): An array of signed mAPI response objects, each of which is an object conforming to the mAPI specifications (either a successful broadcast acknowledgment or an affirmative status response).

• headers (optional): An array of 80-byte block header strings in hex format, starting with the block after the recipient's latest known block (indicated and communicated out-of-band) and ending with the latest header known to the sender.

• pruned: true (optional): Indicates references to the same TXID are omitted in the inputs object, known as deduplication.

The inputs object is required unless the proof field is provided for the transaction. The inputs object can be used to create a tree data structure that nests recursively back in the tree of the previous unconfirmed transactions until each of the branches can ultimately be traced back to the chain of blocks with a proof at the end. The inputs object is optional when the transaction is already confirmed in a block and proof field is provided. The proof field serves as the proof of the transaction's inclusion in a block and is given in BRC-10 format as a JSON object.

The mapiResponses field is an array of signed mAPI response objects that are optional as per this specification, but may be required by higher-layer payment protocols such as BRC-29. If included, it should be omitted if proof is given. mAPI responses provide assurance that the transaction has been accepted and broadcast to multiple miners, making double-spend attacks harder to achieve.

The headers field is an optional array of 80-byte block header strings in hex format. This field can be omitted if no new headers are necessary for verification. The mechanism by which the parties negotiate about which headers are to be provided is beyond the scope of this specification.

Tree Structure

The Everett-style Transaction Envelope uses a tree structure instead of a flat list structure to avoid providing information for the same transaction more than once. The tree structure has advantages as it can easily be validated with a simple recursive function, allowing parallelized processing of nodes further back in the tree at the same time as parents without needing to keep and reference a copy of the entire envelope while validating each node. This approach also allows for a degree of modularity because each node in the tree is itself a fully-valid envelope, and there is no need to re-scan and re-calculate which other transactions would be required to get a valid sub-envelope (very efficient for adding/removing/working with chains of dependent transactions).

A special case can be added when nodes at different depths in the tree depend on a common transaction, to remove tree-level duplications. The first time a transaction appears, it can be included as normal. Subsequent references to the same TXID can be omitted where they appear in the inputs object. To indicate that an envelope has been deduplicated in this way, the root object MUST contain pruned: true. With the issue of duplication solved, we believe a tree structure is the most intuitive and efficient approach.

The use of mAPI is optional and can be disabled by those who do not wish to use it in their implementations. Disabling mAPI allows “receiver-only broadcast” implementations to work. By not allowing mAPI as part of the data structure, the control is taken away from application developers and stakeholders who have widely varying requirements.

Extensions and Added Fields

There are a wide array of potential applications, higher-layer payment protocols and use-cases for these envelopes. We stipulate that many systems will append (or even remove) certain fields from various nodes in these structures. This specification defines a baseline, and deviations from this baseline need only be documented by other standards which inherit from this one, such as BRC-29.

Implementations

A web tool has been implemented which, given any TXID, will produce a valid Everett-style Transaction Envelope.

Developers are encouraged to create their own implementations and contribute to the ecosystem by sharing their work with the community. By doing so, they can help improve the interoperability between different Bitcoin wallet software and services, and further promote the adoption of the BRC-8 standard.

In addition to the web tool, developers should consult the BRC-9 and BRC-10 specifications for more information on implementing the Simplified Payment Verification (SPV) process and the format for SPV proofs, respectively. By adhering to these specifications, developers can ensure their implementations are compatible with existing and future Bitcoin wallet software and services that also follow the BRC standards.

Future Work

While this standard provides a solid foundation for Everett-style Transaction Envelopes, there is always room for improvement and expansion. Future work could include:

• Developing more efficient algorithms for constructing and validating the tree structure of transaction envelopes.

• Expanding on the negotiation process for providing block headers, making it more seamless and efficient.

• Creating additional tools and libraries to simplify the implementation of the BRC-8 standard in various programming languages and platforms.

• Defining higher-layer protocols for live-updating non-final transactions, peer-to-peer data exchange, and efficient tree state reconciliation.

Abstract

Regular Bitcoin transactions do not contain all the data that is needed to verify that the signatures in the transactions are valid. To sign an input of a Bitcoin transaction, the signer needs to know the transaction ID, output index, output satoshis and the locking script of the input transaction. When sending a Bitcoin transaction to a node, only the previous transaction ID and the output index are part of the serialized transaction, the node will look up the locking script and output amount of the input transaction.

We propose an Extended Format (EF) for a Bitcoin transaction, that includes the locking script and the amount in satoshis of all inputs of the transaction. This allows a broadcast service to validate all aspects of a transaction without having to contact a node or an indexer for the utxos of the inputs of a transaction, speeding up the validation.

Copyright

This BRC is licensed under the Open BSV license.

Motivation

Verifying that a transaction is valid, including all signatures, is not possible at the moment without getting the unspent transaction outputs (utxos) from the transactions that are used as inputs from a Bitcoin node (or a Bitcoin indexer). This lookup of the utxos always happens inside a Bitcoin node when validating a transaction, but for a broadcast service to be able to fully validate a transaction (including the fee being paid) it also needs to look up the utxos being spent, which complicates scalability, since this lookup needs to happen on a node (via RPC), that might be too busy to react within an acceptable time frame.

A broadcast service would be able to validate a transaction almost in full if the sender would also send the missing data (previous locking scripts and satoshi outputs) from the utxos being used in the transaction. When creating a new transaction, the previous locking scripts and satoshi outputs are needed to be able to properly sign the transaction, so the missing data is available at the time of the transaction creation. Serializing the transaction to Extended Format, instead of the standard format, is at the point of creating the transaction no extra work, but does make it much easier for a broadcast service to validate the transaction when being received, before sending the transaction to a node.

The main motivation for this proposal is therefore scalability. When incoming transactions contain all the data that is needed to validate them, without having to contact an external service for missing data, the broadcast service becomes much more scalable.

Specification

Current Transaction format:

The Extended Format adds a marker to the transaction format:

The Extended Format marker allows a library that supports the format to recognize that it is dealing with a transaction in extended format, while a library that does not support extended format will read the transaction as having 0 inputs, 0 outputs and a future nLock time. This has been done to minimize the possible problems a legacy library will have when reading the extended format. It can in no way be recognized as a valid transaction.

The input structure is the only additional thing that is changed in the Extended Format. The current input structure looks like this:

In the Extended Format, we extend the input structure to include the previous locking script and satoshi outputs:

Backward compatibility

The Extended Format is not backwards compatible, but has been designed in such a way that existing software should not read a transaction in Extend Format as a valid (partial) transaction. The Extended Format header (0000000000EF) will be read as an empty transaction with a future nLock time in a library that does not support the Extended Format.

Implementation

The Extended Format has been implemented in go-bt and a standalone JavaScript library bitcoin-ef.

  BIP: 239
  Layer: Applications
  Title: Transaction Extended Format (TEF)
  Author: 
      Simon Ordish (@ordishs)
      Siggi Oskarsson (@icellan)
  Comments-Summary: No comments yet. 
  Comments-URI: - 
  Status: Proposal 
  Type: Standards Track 
  Created: 2022-11-09

• Ty Everett (ty@projectbabbage.com)

• Brayden Langley (brayden@projectbabbage.com)

Abstract

The importance of a standard interface by which Bitcoin applications can communicate with wallets and underlying infrastructure cannot be overstated. We propose an identity interface facilitating the creation of Bitcoin transactions, the use of user-held keys for encryption and digital signatures, and the employment of identity certificates to authenticate users with their counterparties. We set a baseline standard and create a versioning system that facilitates continued expansion and extensibility over time.

Motivation

Computing has long been subject to shortfalls in the areas of information centralization and architectural cross-compatibility. Users on the internet struggle with complex and insecure authentication systems which leave them vulnerable and leak their data. Websites rely on advertising to monetize their offerings, but ads warp the incentives of platforms and creators in ways that ultimately harm everyone involved. By defining a standard interface by which users can identify themselves, protect their data and engage in e-commerce with Bitcoin, this standard offers a solution to problems that have long plagued the existing model.

Specification

We specify a baseline standard for an abstract messaging layer which facilitates an identity interface between an application and an underlying MetaNet Client. As part of this messaging layer, we incorporate various message types defined by other BRC standards:

• BRC-1: We incorporate by reference the message types relating to Bitcoin transaction creation as specified by BRC-1. This facilitates micropayment-based interactions as part of applications, enabling new monetization models that are not subject to the same problematic incentives as internet-based advertising.

• BRC-2: We incorporate by reference the message types relating to encryption as specified by BRC-2. This facilitates user privacy and provides a secure foundation for user-to-user communication, enabling applications which protect privacy to emerge and gain traction.

• BRC-3: We incorporate by reference the message types relating to digital signatures as specified by BRC-3. This facilitates generalized message sender attestation and endorsement, solving problems such as fake AI-generated content by allowing relevant parties or the entire world to check whether something has been endorsed by its purported originator.

• BRC-4: We incorporate by reference the extension to BRC-1 as defined by BRC-4, providing for the consumption and utilization of arbitrary UTXO-based Bitcoin tokens as part of transactions. This facilitates the creation and transfer between users of tokenized assets without restrictions beyond those set by their respective output locking scripts.

• BRC-46: We incorporate by reference the extension to BRC-1 as defined by BRC-46, providing for the tracking and management of Bitcoin UTXOs in baskets. This facilitates the storage and retrieval of single-party tokens and digital assets in the user's wallet while removing the need to rely on a single trusted application for asset management.

• BRC-50: We incorporate by reference the message types relating to incoming transaction submission as specified by BRC-50, ensuring users have a way to receive funds into their wallets from within applications. This gives them a way to receive payment for the value they create as part of their interactions within applications.

• BRC-53: We incorporate by reference the message types relating to digital identity certificate creation and revelation, as specified by BRC-53. This provides a way for users to maintain and selectively reveal their identities with specific counterparties in the digital world, facilitating an increased level of trust and accountability.

With these core components in place, we are left only with the need to specify a few other messages that are necessary to facilitate versioning, user network checking and user-to-wallet authentication status discovery. We now proceed to the specification of those auxiliary messages.

HMACs

The introduction of HMACs are the most significant addition aside from the core message types. HMACs facilitate authenticating messages sent between users, and are generally useful for a wide range of applications.

We stipulate the following process for HMAC creation:

• The message sender begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID

• The message sender uses BRC-42 key derivation with the computed invoice number to derive a child public key for the recipient

• The message sender uses BRC-42 key derivation with the computed invoice number to derive their own child private key

• The message sender computes the ECDH shared secret between the two derived child keys

• The resulting elliptic curve point's X and Y values are hashed with SHA256 to create a SHA-256 HMAC key

• The resulting 256-bit value is used to compute the SHA-256 HMAC for the message

• The HMAC value is returned by the client to the application over the abstract BRC-1 communications substrate.

We stipulate the following process for HMAC verification:

• The recipient somehow comes to know the HMAC, the message, the counterparty, the security level, protocol ID, and key ID. The mechanism for conveying this information to the recipient is beyond the scope of this specification.

• The recipient begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID

• The recipient uses BRC-42 key derivation with the computed invoice number, their own private key and the public key of the sender, to compute the sender's child public key

• The recipient uses the same process to compute his own child private key

• The recipient computes a shared secret between the two child keys, using the hash of the X and Y values as a SHA-256 HMAC key

• The recipient then uses the HMAC key to compute the HMAC of the message, checking that the computed value matches the provided value

HMAC Creation Request

The HMAC Creation Request is a message sent by the BRC-43 application to the client. It contains a header with the following information:

The message payload comprises the data to HMAC.

HMAC Creation Response

The response message comprises a payload containing the computed HMAC value.

HMAC Verification Request

The HMAC Verification Request is a message sent by the application to the client. It contains a header with the following information:

The message payload comprises the data to verify against the HMAC provided in the header.

HMAC Verification Response

The response message comprises a payload containing a boolean that indicates whether the HMAC was successfully verified.

HMAC Error

If the client is unable to fulfill the HMAC Creation or Verification Requests for any reason except failed verification, we specify that it should respond with a JSON-formatted HMAC Error. The fields for the object are specified as follows:

One example of an HMAC Error is given below:

{
  "status": "error",
  "code": "ERR_PERMISSION_DENIED",
  "description": "The user has denied permission for computing an HMAC over this data."
}

Public Key and Certificate Retrieval

Facilitating access to public keys and certificates are a crucial part of the wallet messaging layer as they provide the necessary components for identity verification. BRC-43 is used for defining the protocolID and keyID formats, and BRC-52 defines the format of certificates requested.

Public Key Request

To request a public key, we define the following standard request fields:

When the wallet receives this request from the application, after obtaining requisite permission from the user, we stipulate the following process for key derivation:

1. If identityKey is true, the wallet returns its root public identity key to the application without proceeding to the other steps.

2. The wallet checks the BRC-43 invoice number based on the security level, protocol ID, and key ID

3. If forSelf is false, the wallet uses BRC-42 key derivation with the computed invoice number to derive a child public key for the counterparty, returning the public key.

4. Otherwise, if forSelf is true, the wallet uses BRC-42 key derivation with the computed invoice number to derive their own child private key. The wallet then multiplies the private key by the generator point, G, to arrive at their own child public key, as would be derived by a counterparty. The computed public key is returned.

Public Key Response

The response message comprises a 33-byte, DER-encoded public key X coordinate value.

Public Key Error

If the client is unable to fulfill the Public Key Request for any reason, we specify that it should respond with a JSON-formatted Public Key Error. The fields for the object are specified as follows:

One example of a Public Key Error is given below:

{
  "status": "error",
  "code": "ERR_PERMISSION_DENIED",
  "description": "The user has denied permission for revealing their identity public key."
}

Certificate List Request

To request a list of BRC-52 identity certificates belonging to the user, we define these standard request fields:

When the wallet receives this message from the application, the wallet will ascertain based on user preferences and the information provided which certificates will be returned. The wallet is by no means required to return all responsive certificates, if for example the user does not want to reveal a particular affiliation in a particular context. The wallet composes a list, which may be empty, of responsive certificates.

Certificate List Response

The response from the wallet to the application comprises an array of BRC-52 identity certificates, which may be empty.

Certificate List Error

If the client is unable to fulfill the Certificate List Request for any reason except an empty list, we specify that it should respond with a JSON-formatted HMAC Error. The fields for the object are specified as follows:

One example of a Certificate List Error is given below:

{
  "status": "error",
  "code": "ERR_PERMISSION_DENIED",
  "description": "The user has denied permission for obtaining a list of certificates."
}

Network, Versioning and Authentication

Another important aspect of the wallet messaging layer is allowing applications the ability to check which Bitcoin network is in use, and whether or not a user has been authenticated.

Bitcoin Network Request

To determine which Bitcoin network a user's MetaNet Client is currently using, applications can make requests to a standardized endpoint to ensure compatibility.

We define that the request message has no content (beyond the fact of it being a Bitcoin Network Request) and simply returns a string of either "test" or "main" indicating the current network in use.

Client Version Request

We define the standard client version request to contain no parameters (beyond the fact of it being a Client Version Request) and to simply return the version of the MetaNet Client in use as a string.

For historical reasons, to denote compatibility with these specifications, we stipulate that the version should be in the range 0.3.x. For example, 0.3.80.

Authentication Status Request

The authentication status request requires no parameters and returns a boolean indicating whether the current user is "authenticated" or not.

The purpose of this functionality is to facilitate software where the user can "log in" once in their client, and never need a separate login for MetaNet applications. When not authenticated, the application should assume that none of the other functionality, aside from client version checks, will work. It provides a way for applications, when they load, to ensure that the communication system with the client is operational, as a sort of "ping" request that also ensures the user is set up with a wallet.

Asynchronous Authentication Request

The asynchronous authentication request requires no parameters and waits until the user is authenticated before returning a response of true.

Implementations

Implementations of this specification will need to decide on a concrete transport layer (referred to as a "substrate") to facilitate communication between the wallet and applications. Application developers will then need to write their applications in a way that facilitates communication over the substrate, and wallets will need to properly handle incoming requests from applications.

Some examples of communication substrates include:

• BRC-5, for operating a wallet over HTTP on a local machine, enabling applications on that machine to interact with the running wallet.

• BRC-6, for cross-document messaging between a parent page which runs a wallet and a set of child pages which run various applications.

• BRC-7, for exposing an identity interface via the window object in web browsers.

The BRC-56 functions and messages, across these three substrates, have been implemented by the Babbage team in the Babbage SDK.

Abstract

Motivation

Specification

Discussion

As with any other BRC, feel free to open issues in the BRC repository that discuss extensions of BRC-10.

• Ty Everett (ty@projectbabbage.com)

• _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

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)

• blk (block): contains:

  • i (block index)

  • h (block hash)

  • t (block time)

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.

  • Opcodes: stored as a JSON object with a single key op and the Bitcoin opcode value (e.g., {"op": 106} for the 'return' opcode).

  • Non-Opcodes: stored as a base64 encoded string.

• lb0, lb1, lb2, ...: base64 encoded string, used when the push data size is larger than 512 bytes.

• s0, s1, s2, ...: UTF8 encoded representation of the push data, used for full-text search and simple string matching.

• ls0, ls1, ls2, ...: UTF8 encoded representation, used when the push data size is larger than 512 bytes.

• str: full string representation of the script.

• e: contains the graph structure of each transaction.

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

4. Ensure compatibility with the TXO format by including all specified fields and adhering to the defined structure.

Deggen (deggen@kschw.com)

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

Specification

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