Bitcoin Message Signer: Sign and Verify Messages with Your Address

What Is Bitcoin Message Signing?

Bitcoin message signing is a cryptographic technique that allows the owner of a Bitcoin address to prove they control that address without moving any funds or revealing their private key. The signer produces a digital signature over an arbitrary text message using the private key associated with their address. Anyone who has the address, the message, and the signature can verify that the message was genuinely signed by the key holder.

This mechanism relies on the same elliptic curve cryptography (ECDSA) that secures Bitcoin transactions. When you sign a Bitcoin transaction, your wallet uses your private key to create a signature that authorizes spending. Message signing works identically, except the signed data is a text message rather than a transaction. The result is a compact, base64-encoded string that serves as cryptographic proof of address ownership.

Message signing was introduced early in Bitcoin's history and is supported by most major wallets including Bitcoin Core, Electrum, Sparrow, BlueWallet, and Ledger. The feature is particularly useful for establishing identity on the blockchain: you can prove you own a specific address without broadcasting any on-chain transaction.

How Message Signing Works

The Bitcoin message signing process follows a precise sequence of cryptographic steps designed to produce a deterministic, verifiable signature.

Step 1: Message Preparation

Before signing, the message is prefixed with a standardized header known as the "Bitcoin Signed Message magic prefix." This prefix is the string \x18Bitcoin Signed Message:\n, where \\x18 is a single byte representing the length of the text "Bitcoin Signed Message:\n" (24 bytes). The length of the actual message is then encoded as a variable-length integer, followed by the message itself.

This prefix serves a critical security purpose: it prevents a malicious party from tricking you into signing a valid Bitcoin transaction when you think you are signing a simple text message. Since the prefix is always prepended, the resulting data can never be interpreted as a valid transaction.

Step 2: Double SHA-256 Hashing

The prefixed message is then hashed using double SHA-256, the same hashing scheme Bitcoin uses for transaction IDs and block headers. The first SHA-256 pass produces a 32-byte digest, and that digest is hashed a second time. The resulting 32-byte hash is the data that gets signed by the private key.

Step 3: ECDSA Signing

Using the private key associated with the Bitcoin address, an ECDSA signature is computed over the 32-byte hash. The signature consists of two 256-bit integers (r and s) plus a recovery flag byte. The recovery flag encodes whether the public key is compressed or uncompressed and which of the two possible public keys corresponds to the signature. This allows the verifier to recover the public key directly from the signature without needing it as a separate input.

Step 4: Base64 Encoding

The 65-byte signature (1 byte recovery flag + 32 bytes r + 32 bytes s) is encoded as a base64 string for easy sharing. This produces a compact 88-character string that can be copied, pasted, or published alongside the original message and address.

Use Cases for Signed Messages

Message signing has a wide range of practical applications in the Bitcoin ecosystem. Any situation where someone needs to prove they control an address, without spending from it, is a candidate for message signing.

• Proof of ownership: Exchanges and services may ask you to sign a message to prove you own a withdrawal address before whitelisting it
• Authentication: Some platforms allow passwordless login by signing a challenge message with your Bitcoin address, functioning like a decentralized identity credential
• Contract signing: Parties to an agreement can sign the contract text with their Bitcoin addresses, creating a timestampable cryptographic record of consent
• Audit trails: Companies holding Bitcoin reserves can prove control of specific addresses during audits by signing messages with a predefined text
• Domain verification: Website owners can prove Bitcoin address ownership by publishing a signed message on their site, linking an on-chain identity to a web domain
• Dispute resolution: In peer-to-peer trading, a signed message can serve as evidence that a specific party controls the address involved in a transaction
• Community governance: Token holders or address-based voting systems can use message signing to cast verifiable votes without moving funds

Message Format and Standards

The Bitcoin message signing standard produces a three-part output that contains everything needed for verification: the Bitcoin address, the original message text, and the base64-encoded signature.

BIP-137 Signature Formats

BIP-137 standardizes how the recovery flag byte in the signature encodes information about the key type and address format used for signing. The first byte of the decoded 65-byte signature indicates the signing mode:

The recovery flag allows the verifier to determine which address format was used without additional metadata. This is important because the same public key can be represented as different address types (legacy, wrapped SegWit, or native SegWit), and the verifier needs to know which derivation to use when checking the signature against the provided address.

Verification Process

Verifying a signed Bitcoin message reverses the signing process. The verifier does not need the signer's public key or private key: the public key is recovered mathematically from the signature itself.

1. The verifier takes the message text and prepends the same Bitcoin Signed Message magic prefix
2. The prefixed message is double SHA-256 hashed to produce the same 32-byte digest the signer used
3. Using the ECDSA recovery algorithm and the recovery flag from the signature, the verifier extracts the public key that produced the signature
4. The recovered public key is converted to a Bitcoin address using the format indicated by the recovery flag (P2PKH, P2SH-P2WPKH, or P2WPKH)
5. The derived address is compared to the address provided with the signed message. If they match, the signature is valid

Full cryptographic verification requires implementing ECDSA public key recovery on the secp256k1 curve, which is computationally intensive. Bitcoin Core's verifymessage RPC command performs this verification natively. Most wallet software that supports signing also supports verification.

Limitations and Security

While message signing is a powerful tool, it comes with several important limitations and security considerations that users should understand.

• Legacy address restriction: The original message signing standard was designed for P2PKH addresses (starting with 1). Support for SegWit addresses (starting with 3 or bc1) was added later via BIP-137, but not all wallets implement it consistently
• Taproot addresses (bc1p): As of 2026, there is no widely adopted standard for message signing with P2TR (Taproot) addresses. BIP-322 proposes a generic message signing framework that would cover all address types, but adoption remains limited
• No timestamping: A signed message does not include a timestamp. The signature proves key ownership at the time of signing, but cannot prove when it was created. For timestamp guarantees, the signed message can be embedded in a Bitcoin transaction using OP_RETURN
• Phishing risk: Be cautious about what messages you sign. A signed message is a permanent, irrevocable proof that you controlled a specific address. Never sign messages that could be used to impersonate you or authorize actions you did not intend
• Multisig incompatibility: Standard message signing does not work with multisignature addresses because the signing process requires a single private key. BIP-322 aims to solve this by supporting script-based signing
• Address reuse implications: Signing a message with an address reveals the public key associated with that address. For addresses that have never spent funds on-chain, the public key was previously unknown, providing an extra layer of quantum resistance. Message signing removes this protection

Frequently Asked Questions

Can I sign a message without a private key?

No. Signing a Bitcoin message requires the private key associated with the address. This is by design: the entire purpose of message signing is to prove that you control the private key. Without it, you cannot produce a valid signature. This tool does not generate signatures; it provides an educational walkthrough and format validation.

Is message signing the same as signing a transaction?

The underlying cryptography is identical: both use ECDSA on the secp256k1 curve with a private key. The difference is what gets signed. A transaction signature authorizes the movement of Bitcoin. A message signature proves address ownership over arbitrary text. The Bitcoin Signed Message magic prefix ensures a message signature can never be confused with a transaction signature.

What wallets support Bitcoin message signing?

Bitcoin Core, Electrum, Sparrow, BlueWallet, Ledger (via Ledger Live), Trezor, Coldcard, and many other wallets support message signing. The specific menu location varies by wallet, but it is typically found under an "Advanced" or "Sign Message" option associated with a specific address.

Can I verify a signed message without a Bitcoin node?

Yes. Many wallets and online tools can verify signed messages without running a full node. The verification only requires the ECDSA public key recovery algorithm, not access to the blockchain. However, for maximum security, verifying with your own Bitcoin Core node using the verifymessage RPC ensures you are not trusting a third-party implementation.

Does message signing work with SegWit addresses?

BIP-137 extends the original signing standard to support P2SH-P2WPKH (addresses starting with 3) and P2WPKH (addresses starting with bc1q) by encoding the address type in the signature's recovery flag. However, not all wallets implement BIP-137. Some wallets sign with SegWit keys but produce legacy-format signatures, which can cause verification failures across different software.

What about Taproot (bc1p) message signing?

There is no widely adopted standard for Taproot message signing as of 2026. BIP-322, titled "Generic Signed Message Format," proposes a universal approach that uses transaction-like proofs to support any script type, including Taproot. Some wallets have begun implementing BIP-322 experimentally, but cross-wallet compatibility is not yet reliable.

Can a signed message be forged?

No. Forging a Bitcoin message signature would require either breaking the ECDSA algorithm on the secp256k1 curve or knowing the private key. ECDSA on secp256k1 offers approximately 128 bits of security, meaning an attacker would need roughly 2^128 operations to forge a signature: far beyond the capability of any existing or foreseeable classical computer.

Why is the signature always 88 characters long?

The raw signature is exactly 65 bytes: 1 byte for the recovery flag and 64 bytes for the r and s values of the ECDSA signature. When base64-encoded, 65 bytes produce exactly 88 characters (including the padding character). This fixed length makes it easy to validate the basic format of a signature before attempting full cryptographic verification.

This tool is for educational purposes only. It does not generate real signatures and does not perform full cryptographic verification. For signing messages, use a Bitcoin wallet that controls the relevant private key. For full verification, use Bitcoin Core's verifymessage command or a trusted wallet application.