Bitcoin improvement proposal BIP461, a draft specification for a deterministic ECDSA signing procedure, was merged into the Bitcoin BIPs repository on Sept. 16 via pull request #2224. The proposal, authored by Liam Gilligan, defines a standardized way to produce ECDSA signatures so that two independent compliant signers handling the same secret key and message hash must generate identical signatures. That property gives manufacturers, auditors and users a benchmark: any deviation from the expected output flags a signer that is not following the specification.

The proposal targets a class of attacks in which malicious wallet firmware leaks secret key material through the signatures themselves. ECDSA permits the signer several degrees of freedom when constructing a valid signature, most notably the choice of the nonce, a temporary value used during signing. Compromised firmware can abuse that freedom to embed fragments of the seed or key inside signatures that still pass ordinary verification. Bitcoin's consensus rules accept any valid ECDSA signature, so acceptance alone says nothing about whether the signing process protected the key.

BIP461 removes that ambiguity operationally rather than through a consensus change. It fixes the free parameters through a specified deterministic procedure, and the resulting signatures remain valid under existing Bitcoin consensus rules. Wallet vendors and hardware manufacturers can adopt it without any protocol-level coordination. The prescribed algorithm also keeps signatures to at most 70 bytes in standard DER encoding, excluding Bitcoin's one-byte sighash flag.

The threat model is not hypothetical. The Dark Skippy disclosure, published by researchers who demonstrated that corrupted firmware can embed seed material in transaction signatures, drew attention to this exact channel. In their original disclosure, the researchers said they had not observed the technique being used in the wild, but they warned that a malicious signer could leak only on a selected transaction — meaning a device could produce compliant signatures during a test and still leak on a different transaction later. BIP461's comparison framework inherits that limitation: a matching signature pair confirms compliance only for that single sample.

There are practical costs and caveats. Reproducing a signature for comparison requires identical inputs, the same standard, and access to the secret key on a second independent signer — an additional exposure of sensitive material that constitutes a real operational risk. A mismatch also warrants investigation rather than a verdict: an honest implementation using a different valid ECDSA procedure can produce different results, so divergence proves noncompliance with BIP461 but cannot identify a malicious device or demonstrate theft.

Scope is another boundary worth noting. The Dark Skippy demonstration used Schnorr signing, while BIP461 specifies ECDSA. Taproot outputs use the separate BIP340 Schnorr scheme, so this draft does not directly standardize a remedy for the original Schnorr-based demonstration. Coverage of the leak channel across Bitcoin's two active signature schemes remains incomplete.

For wallet vendors and custodians, the business implications are concrete. Hardware wallet makers can implement BIP461 as a verifiable compliance target, allowing resellers, auditors or even sophisticated customers to cross-check device behavior against a reference implementation. Exchanges and custodians running multi-signature or parallel-signing infrastructure can integrate deviation checks into their signing workflows. Any such deployment must weigh the detection benefit against the operational risk of exposing keys to a second signing environment and the inherent limits of point-in-time sampling.

The proposal remains marked Draft in the BIPs repository. At the September merge, a reviewer stated that test vectors and a reference implementation are required before BIP461 can advance to Complete status, which sets a clear technical roadmap: until reference code and vectors land, the specification offers a benchmark without a canonical way to verify against it.