Message Signing

What Is Message Signing?

Message signing is a cryptographic operation where a Bitcoin holder uses their private key to produce a digital signature over an arbitrary text message. Anyone can then verify that signature against the corresponding public key or address, confirming that the signer controls the key associated with that address. The process never broadcasts a transaction or moves any funds on the blockchain.

Satoshi Nakamoto included basic message signing functionality in the original Bitcoin Core software through the signmessage and verifymessage RPC commands. That original implementation only supported legacy P2PKH (1...) addresses. As Bitcoin evolved to include SegWit and Taproot address types, new standards emerged to extend message signing to the full range of Bitcoin address formats.

How It Works

At its core, message signing relies on the same elliptic curve cryptography that secures Bitcoin transactions. The signer proves knowledge of a private key without revealing it. The process differs depending on which standard is used.

Legacy Message Signing

The original Bitcoin message signing format works exclusively with P2PKH addresses and uses a recoverable ECDSA signature scheme. The steps are:

1. The message is prefixed with a magic string: "Bitcoin Signed Message:\n", preceded by its length byte (0x18, or 24 in decimal)
2. The length of the user's message is encoded as a variable-length integer, followed by the message itself
3. The entire buffer is hashed twice with SHA-256 (double SHA-256) to produce a 32-byte digest
4. The private key signs this digest, producing a 65-byte recoverable ECDSA signature: 1 byte for the recovery flag plus 32 bytes each for the r and s values
5. The signature is base64-encoded for easy transport and display

The "recoverable" property is what makes verification possible without separately providing the public key. Given the message and the signature, anyone can mathematically recover the public key, derive the corresponding address, and compare it to the claimed address.

# Sign a message with Bitcoin Core
bitcoin-cli signmessage "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" "Hello, I own this address"

# Verify the signature
bitcoin-cli verifymessage "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" \
  "H+F5M6..." \
  "Hello, I own this address"
# Returns: true or false

BIP-137: SegWit Address Support

When SegWit introduced new address types (P2SH-P2WPKH and P2WPKH), the legacy format could not distinguish which address type a signature corresponded to. BIP-137 solved this by defining specific header byte ranges in the recovery flag:

BIP-137 extended message signing to SegWit addresses, but it still relies on ECDSA key recovery and cannot support Taproot (P2TR) addresses. Schnorr signatures do not support public key recovery, so a fundamentally different approach was needed.

BIP-322: Generic Signed Message Format

BIP-322, authored by Karl-Johan Alm, defines a generic message signing format that works with any Bitcoin script type, including Taproot. Instead of relying on key recovery, it uses a pair of virtual transactions:

1. A to_spend transaction is constructed with an output whose scriptPubKey corresponds to the address being proven. This transaction contains the message commitment via a tagged hash labeled BIP0322-signed-message.
2. A to_sign transaction spends the output of to_spend. Its witness data constitutes the proof.

Because to_sign has an invalid input (referencing a non-existent transaction), it can never be broadcast on the actual network. But the signature is structurally identical to a real Bitcoin transaction signature, which means existing hardware wallets and signing devices can produce BIP-322 proofs using their standard transaction signing flow.

BIP-322 requires BIP-174 (PSBT), BIP-340 (Schnorr), and BIP-341 (Taproot). It also supports proof of funds, where a signer demonstrates control over a set of UTXOs rather than just an address.

Use Cases

Proof of Address Ownership

The most common use case is proving that you control a specific Bitcoin address. Exchanges, OTC desks, and counterparties may require this before processing withdrawals, establishing trade relationships, or resolving disputes. The signer produces a signature over an agreed-upon message (often including a timestamp or challenge string), and the verifier confirms it matches the claimed address.

Proof of Reserves

Exchanges and custodians can use message signing to demonstrate they control the Bitcoin they claim to hold. By signing a timestamped statement with the keys that control their on-chain holdings, they provide cryptographic evidence of solvency. BIP-127 formalized a simple proof-of-reserves transaction format, and BIP-322's proof-of-funds mode extends this further. For a deeper look at proof-of-reserves constructions, see the proof of reserves standards research article.

Identity Verification and Authentication

Message signing can serve as a form of authentication: a user signs a server-provided challenge with their Bitcoin key, proving they control a known address without revealing the private key or sending a transaction. This pattern appears in peer-to-peer marketplaces, domain ownership verification, and Nostr identity linkage. The Spark message signer tool provides a simple interface for generating and verifying these proofs.

Dispute Resolution

In peer-to-peer transactions or legal proceedings, message signing provides cryptographic proof of address control at a specific point in time. A party can demonstrate they were the intended recipient of a payment, or that they controlled the sending address when a transaction was made.

Contract and Agreement Signing

Parties can use message signing to cryptographically commit to the text of an agreement. By signing the agreement text with their Bitcoin key, each party creates a non-repudiable record tied to a specific public key. This does not replace legal signatures, but it provides a tamper-evident record that can supplement traditional documentation.

Risks and Considerations

Signature Does Not Equal Ownership

A valid message signature proves that someone had access to the private key at the time of signing. It does not prove legal ownership of the Bitcoin, exclusive control, or that the funds are unencumbered. A custodian, for example, might sign on behalf of many depositors. This distinction is critical when using message signing for proof of reserves or legal proceedings.

Replay and Reuse

A signed message can be shown to anyone at any time. Without a challenge string, timestamp, or other freshness guarantee, an old signature could be presented as current proof. Verifiers should always include a unique challenge (a nonce or timestamp) in the message text to prevent replay attacks.

Address Type Limitations

Legacy message signing only works with P2PKH addresses. BIP-137 extends support to SegWit addresses but not Taproot. Only BIP-322 covers all current address types. Wallet and verifier support for BIP-322 is still being adopted across the ecosystem, so compatibility should be confirmed before relying on it.

Signing Risks

Users should be cautious about what they sign. Malicious actors could craft messages designed to be misleading when taken out of context. The magic prefix ("Bitcoin Signed Message:\n") in the legacy format exists specifically to prevent signed messages from being confused with signed transactions. BIP-322's tagged hash serves the same purpose, ensuring that a message proof can never be mistaken for a valid on-chain transaction.

Privacy Implications

Signing a message with an address publicly links that address to the signer's identity. This can undermine fungibility and privacy by creating a verifiable connection between a real-world identity and on-chain activity. Users who value privacy should consider using addresses not linked to their main holdings, or use address rotation practices to limit exposure.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.