# Message Signature Creation and Verification Ty Everett () ### Abstract This document defines a protocol for creating and verifying digital message signatures in the Bitcoin ecosystem. It leverages the BRC-42 key derivation and BRC-43 invoice numbers to facilitate privately-verifiable signatures, increasing security and privacy in Bitcoin message interactions. ### Motivation While Bitcoin Signed Messages (BSM) offer a simplistic solution for digitally signing Bitcoin messages, they lack capabilities for privately-verifiable signatures and they re-use keys, potentially compromising security and privacy. By incorporating BRC-42 key derivation, this standard enhances the security and private signing capabilities, providing a robust and unified standard for the Bitcoin ecosystem. Private signing enables a specific verifier to check the signature, without revealing its validity to the rest of the world. ### Scope The scope of this specification is to convey a message signature. The message data (the thing being signed) is not serialized as part of this signature structure. One notable aspect of BSM is the need to prefix all messages with "Bitcoin signed message" to avoid inadvertently signing a Bitcoin transaction. However, since the new approach utilizes a new signing key for each message, there is no danger of signing Bitcoin transactions with a key capable of spending locked coins. ### Specification The protocol employs the BRC-3 digital signature process and makes use of the BRC-42 key derivation and BRC-43 invoice numbering scheme. We specify `message signing` as the BRC-43 protocol ID, with security level 2. We specify that the signer generates a random 256-bit value to be used as the key ID when the signature is computed for a given counterparty. The system operates in the following way: 1. Message sender computes the BRC-43 invoice number based on the security level (`2`), protocol ID (`message signing`), and their 256-bit key ID. We specify the key ID is in base64 format when added to the invoice number. 2. Message sender derives a child private key for the counterparty (or `anyone`) with the computed invoice number using the BRC-42 key derivation process. 3. Message sender then computes the digital signature using the ECDSA with the derived private key. 4. 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. 5. A message recipient can then deserialize the structure to learn the sender's public key and the correct key ID for verification. 6. 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 ```sh 42423301 # version 032e5bd6b837cfb30208bbb1d571db9ddf2fb1a7b59fb4ed2a31af632699f770a1 # signer 02e5e1a150745253aff65cdbcef722873110d89c396223e3d8715f018e72f7d4f8 # verifier 8166f775e9128dfea9ddb8fc92c655cfaae6795e18911d7d1b6d981ac8664e36 # key ID 30450221009fd5c15bb289bd3a26454131b269b4f550f32dca4c21fde29cef3ebaa913363c022052d421eae633c363b1dad674a1da4821c885425cc636147388b8b08b439721be # signature ``` ```sh 42423301 # version 032e5bd6b837cfb30208bbb1d571db9ddf2fb1a7b59fb4ed2a31af632699f770a1 # signer 00 # verifier (anyone) e8ff1624ede8d6ca5303badb68dec8f226284385bed3bc7c19b578a905866587 # key ID 3045022100b304d38e25106c732f0247fab70b9cf47d5434c08d7a94ef4ad7069bae9a9a0e02202f4e3b4e5d7d698cfebe64f643dbcddc1631e6f09aece0850613f602ec4d50e6 # signature ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://hub.bsvblockchain.org/brc/peer-to-peer/0077.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.