Message Signature Creation and Verification
Ty Everett (ty@projectbabbage.com)
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 |
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 |
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
Last updated