BIP461 sets ECDSA signing standard to spot covert key leaks

BIP461, authored by Liam Gilligan and merged into the Bitcoin Improvement Proposals repository on Sept. 16, defines a deterministic ECDSA signing procedure. The document remains marked Draft in the repository.

The procedure specifies how an ECDSA signer must choose internal values, including the signing nonce, so that two compliant implementations using the same private key and the same message hash produce identical signatures. The signatures produced by the procedure are valid under current Bitcoin consensus rules and require no consensus change.

The proposal creates a single expected signature output for a given secret key and message hash. Comparing a device’s signature to that expected output can reveal deviations that may signal covert leakage of wallet key material, because Bitcoin’s network validation checks only that a signature is mathematically correct.

To reproduce a signature for verification, a second independent signer must have access to the same secret key and the exact same inputs. That requirement introduces an operational risk by exposing the key to another device or environment for comparison.

A mismatch between signatures indicates at least one signer did not follow the specified procedure, but it does not identify which device is at fault or prove that a key has been stolen. An honest implementation that follows a different valid ECDSA procedure can also produce a different signature. The September merge record notes that test vectors and a reference implementation are needed to reduce ambiguity and allow meaningful comparisons.

The draft constrains signature length, limiting standard DER-encoded signatures to at most 70 bytes, excluding Bitcoin’s one-byte sighash flag. BIP461 applies to the ECDSA scheme used by legacy and many existing Bitcoin scripts. It does not standardize Schnorr signatures, which Taproot uses under BIP340.

Prior research demonstrating covert signature leakage, referred to as Dark Skippy, used Schnorr signing in its original demonstration and warned that a signer could leak only on selected transactions. Sampling a device’s signatures for comparison can miss conditional or selective leaks.

Reviewers at the September merge said further technical work is required before the draft can advance beyond Draft. Implementers and wallet users must balance the potential for detecting deviations against the operational risks involved in reproducing signatures with exposed keys.