Digital Signature Creation and Verification

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.

Status Note

The key-derivation signature scheme in this document remains the basis for wallet createSignature and verifySignature, but the BRC-1 message framing and legacy SDK references are historical. Current implementations expose these operations through BRC-100, using protocolID, keyID, counterparty, optional privileged controls, seekPermission, and byte-array payloads.

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 current bsv-blockchain/ts-sdk BRC-100 wallet interfaces and bsv-blockchain/wallet-toolbox permission enforcement. Older Babbage SDK references are retained only for historical context.