Bitcoin improvement proposal BIP461 could simplify detection of a covert channel that leaks wallet secrets. The draft introduces a uniform signing process for ECDSA, the existing Bitcoin signature algorithm.
When signers follow the specification, they will generate identical signatures for the same private key and message hash, providing a baseline to spot anomalies that might hide key leakage.
Authored by Liam Gilligan, the proposal was merged into the BIPs repository on September 16 and remains a draft. Because it operates under Bitcoin’s current consensus rules, adopting this signing method does not require any consensus change.
Comparing signatures for deviations
ECDSA permits signers to make certain choices when crafting a valid signature, such as selecting the nonce—a temporary value used during signing. Malicious firmware can abuse this flexibility to embed key material in signatures that still verify, while BIP461 eliminates those degrees of freedom by prescribing a deterministic procedure.
A signature’s acceptance by the network does not guarantee that the key remained secure during signing. A shared specification offers an expected output against which a signer’s behavior can be measured.
Performing the comparison demands identical inputs and the exact same standard, including access to the private key on a separate independent signer. This additional key exposure is a practical cost of reproducing the signature. Divergent results for the same key and message hash indicate that at least one signer deviated from BIP461.
Even an honest implementation that uses a different valid ECDSA approach could produce a mismatch. A discrepancy triggers a compliance investigation, though the underlying cause remains unclear. The comparison alone cannot pinpoint a malicious device or prove that funds were stolen.
The algorithm also limits signatures to no more than 70 bytes in standard DER encoding, not counting Bitcoin’s one‑byte sighash flag.
The Dark Skippy disclosure revealed that compromised firmware could embed seed material into transaction signatures. In their original paper, the researchers noted they had not observed this technique in the wild.
Dark Skippy’s original demonstration relied on Schnorr signatures, whereas BIP461 focuses on ECDSA. Since Taproot employs the separate BIP340 Schnorr scheme, this draft does not directly provide a fix for that demonstration.
The researchers’ mitigation discussion warned that a malicious signer might leak only on a specific transaction, allowing a device to pass compliance tests while leaking on another transaction.
During the September merge, a reviewer commented that test vectors and a reference implementation are necessary for BIP461 to progress to the ‘Complete’ status.
For wallet holders, the proposal’s value lies in offering a shared benchmark that could make deviations visible. Realizing that benefit depends on compliant implementations and comparisons that consider both detection limits and the risks associated with handling secret keys.
