Skip to content

Latest commit

 

History

History
56 lines (43 loc) · 4.75 KB

0077.md

File metadata and controls

56 lines (43 loc) · 4.75 KB
Raw

BRC-77: Message Signature Creation and Verification

Ty Everett ([email protected])

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

42423301 # version
032e5bd6b837cfb30208bbb1d571db9ddf2fb1a7b59fb4ed2a31af632699f770a1 # signer
02e5e1a150745253aff65cdbcef722873110d89c396223e3d8715f018e72f7d4f8 # verifier
8166f775e9128dfea9ddb8fc92c655cfaae6795e18911d7d1b6d981ac8664e36 # key ID
30450221009fd5c15bb289bd3a26454131b269b4f550f32dca4c21fde29cef3ebaa913363c022052d421eae633c363b1dad674a1da4821c885425cc636147388b8b08b439721be # signature
42423301 # version
032e5bd6b837cfb30208bbb1d571db9ddf2fb1a7b59fb4ed2a31af632699f770a1 # signer
00 # verifier (anyone)
e8ff1624ede8d6ca5303badb68dec8f226284385bed3bc7c19b578a905866587 # key ID
3045022100b304d38e25106c732f0247fab70b9cf47d5434c08d7a94ef4ad7069bae9a9a0e02202f4e3b4e5d7d698cfebe64f643dbcddc1631e6f09aece0850613f602ec4d50e6 # signature