Hardware wallets are designed to keep private keys offline. But compromised firmware could still leak information through the signatures it creates. Bitcoin BIP-461 proposes a standard way to generate ECDSA signatures, making it possible to compare the output of independent signing devices.
The proposal is a draft for wallet software. It would not change Bitcoin’s consensus rules or add a new transaction type. Wallet makers would need to implement the standard before users could use it to compare signatures.
What Bitcoin BIP-461 proposes
ECDSA uses a temporary secret number called a nonce to create each signature. A weak or reused nonce can expose a private key. Malicious firmware could also manipulate the nonce to hide secret information in an otherwise valid signature.
BIP-461 specifies a deterministic signing process: given the same private key and message hash, compliant signers should produce the same signature. The proposal uses RFC 6979 to derive nonces, then applies low-R grinding and low-S normalization. In simple terms, the signer follows a defined process to produce a repeatable signature in a standard format.
Deterministic nonce generation is already used in Bitcoin software. BIP-461’s aim is to define the full procedure precisely, so independent implementations have a common result to check.
The process also limits signature size. BIP-461 signatures can be up to 70 bytes in DER form, or 71 bytes with the sighash flag. That is smaller than the maximum size for other valid ECDSA signatures and can slightly reduce transaction input size.
How comparing signatures could help
A user could create a test key with no funds, load it onto two independent signers, and have both sign the same message hash. Matching signatures show that both devices produced the same output for that test. If they differ, at least one signer did not follow the specification—or the test inputs may not have matched.
A mismatch is a reason to investigate, not proof of malicious behavior. It could result from a software bug, a different message hash, or another testing error. And users should avoid copying a funded wallet’s private key onto multiple devices just to run a comparison.
What BIP-461 does not protect
A successful comparison cannot prove a wallet is safe in every situation. Malicious firmware could behave correctly during a test and leak information only under specific conditions. BIP-461 also addresses ECDSA signatures, not Taproot’s Schnorr signatures.
The issue BIP-461 tackles is separate from quantum computing. Our’s ECDSA Fail explainer covers research into possible future quantum attacks on ECDSA; it does not mean Bitcoin signatures are currently broken.
What comes next for BIP-461
BIP-461 remains a draft. A numbered proposal is not the same as adoption: wallet makers still need to implement it, and independent implementations need to be reviewed and tested against one another.
BIP-461 could give users and auditors a practical way to flag unexplained differences in ECDSA signing. It is a useful check, but it cannot replace firmware review or prove that a device is trustworthy.
Fact-check note, not part of the article: The current BIP draft lists its status as Draft, specifies RFC 6979 nonce derivation with low-R grinding and low-S normalization, and states that signatures remain valid under existing consensus rules. Its size limit is 70 bytes in DER form, or 71 with the sighash flag. GitHub Taproot signatures use Schnorr as specified by BIP-340.
