Message Signature Creation and Verification
Signing a plain message is not the same problem as signing a transaction, and doing it ad hoc leads to signatures nobody else can check. This defines how messages are signed and verified, including signatures only the intended recipient can confirm.
Summary
- Why
- Reusing one signing key for every message makes signatures traceable across contexts and offers no way to limit verification to a single chosen recipient.
- What
- BRC-77 defines a binary format and process for creating a digital signature over a message using a freshly derived key, optionally verifiable only by one chosen recipient.
- How
- The sender picks a random key ID, derives a one-time private key for the recipient (or for anyone) using BRC-42 and a BRC-43 invoice number built from a fixed protocol ID and security level, signs the message with ECDSA, then packages their public key, the recipient's public key (or a flag for anyone), the key ID, and…
What this lets you do
- Sign a message with a freshly derived key instead of a reused identity key
- Restrict signature verification to one named recipient
- Produce a publicly verifiable signature by targeting anyone instead of a specific recipient
- Serialize signer, recipient, key ID, and signature into a fixed binary format
- Recover the correct key ID from a received signature to verify it
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-77 accurately, including what it depends on.
The specification
Abstract
This document defines a protocol for creating and verifying digital message signatures in the Bitcoin ecosystem. It leverages the BRC-42 key derivation and BRC-43 invoice numbers to facilitate privately-verifiable signatures, increasing security and privacy in Bitcoin message interactions.
Motivation
While Bitcoin Signed Messages (BSM) offer a simplistic solution for digitally signing Bitcoin messages, they lack capabilities for privately-verifiable signatures and they re-use keys, potentially compromising security and privacy. By incorporating BRC-42 key derivation, this standard enhances the security and private signing capabilities, providing a robust and unified standard for the Bitcoin ecosystem. Private signing enables a specific verifier to check the signature, without revealing its validity to the rest of the world.
Scope
The scope of this specification is to convey a message signature. The message data (the thing being signed) is not serialized as part of this signature structure.
One notable aspect of BSM is the need to prefix all messages with "Bitcoin signed message" to avoid inadvertently signing a Bitcoin transaction. However, since the new approach utilizes a new signing key for each message, there is no danger of signing Bitcoin transactions with a key capable of spending locked coins.
Specification
The protocol employs the BRC-3 digital signature process and makes use of the BRC-42 key derivation and BRC-43 invoice numbering scheme.
We specify message signing as the BRC-43 protocol ID, with security level 2. We specify that the signer generates a random 256-bit value to be used as the key ID when the signature is computed for a given counterparty.
The system operates in the following way:
- Message sender computes the BRC-43 invoice number based on the security level (
2), protocol ID (message signing), and their 256-bit key ID. We specify the key ID is in base64 format when added to the invoice number. - Message sender derives a child private key for the counterparty (or
anyone) with the computed invoice number using the BRC-42 key derivation process. - Message sender then computes the digital signature using the ECDSA with the derived private key.
- Message sender serializes their own public key, the recipient public key, the selected key ID, and the ECDSA signature according to the serialization format below.
- A message recipient can then deserialize the structure to learn the sender's public key and the correct key ID for verification.
- The recipient can then use their own private key, the public key of the sender, and the computed invoice number to verify the signature over the message.
Serialization format
The standard serialization format encapsulates all the necessary information required for message verification into a binary representation. The format starts with a version number, followed by the identity key of the signer, the identity key of the recipient (or 0x00 to represent anyone if it's publicly verifiable), the 256-bit key ID used for the signature, and the ECDSA signature over the message. This structure ensures a standardized way for efficiently and securely transmitting and verifying signatures:
| Field | Field Length | Description |
|---|---|---|
| Version | 4 bytes | Defines the version of the standard used. Currently 0x42423301 |
| Signer ID | 33 bytes | Identity key of the signer (DER, compressed) |
| Verifier ID | 1 or 33 bytes | Identity key of the recipient (DER, compressed), or 0x00 if anyone |
| Key ID | 32 bytes | The specific key ID used for the signature |
| Signature | Variable | The ECDSA signature of the message, in DER format |
Hex Examples
42423301 # version
032e5bd6b837cfb30208bbb1d571db9ddf2fb1a7b59fb4ed2a31af632699f770a1 # signer
02e5e1a150745253aff65cdbcef722873110d89c396223e3d8715f018e72f7d4f8 # verifier
8166f775e9128dfea9ddb8fc92c655cfaae6795e18911d7d1b6d981ac8664e36 # key ID
30450221009fd5c15bb289bd3a26454131b269b4f550f32dca4c21fde29cef3ebaa913363c022052d421eae633c363b1dad674a1da4821c885425cc636147388b8b08b439721be # signature
42423301 # version
032e5bd6b837cfb30208bbb1d571db9ddf2fb1a7b59fb4ed2a31af632699f770a1 # signer
00 # verifier (anyone)
e8ff1624ede8d6ca5303badb68dec8f226284385bed3bc7c19b578a905866587 # key ID
3045022100b304d38e25106c732f0247fab70b9cf47d5434c08d7a94ef4ad7069bae9a9a0e02202f4e3b4e5d7d698cfebe64f643dbcddc1631e6f09aece0850613f602ec4d50e6 # signature