Liam Gilligan

A new Bitcoin Improvement Proposal gives wallet makers a way to catch hardware that secretly leaks private keys inside otherwise valid signatures. For custodians and exchanges that rely on hardware signing devices to secure institutional bitcoin holdings, a shared, checkable standard narrows a blind spot that has existed since ECDSA signing began.

• BIP461, authored by developer Liam Gilligan, was merged into the Bitcoin BIPs repository as a Draft on Sept. 16.
• The proposal forces two independent signers holding the same secret key to produce byte-identical ECDSA signatures for the same message.
• A Bitcoin Core reviewer said test vectors and a reference implementation are still required before BIP461 can advance to Complete status.

• 70 bytes maximum size of a BIP461 signature
• Sept. 16 date Gilligan’s draft was merged into Bitcoin’s BIPs repository

Bitcoin developer Liam Gilligan’s proposal, filed as BIP461, specifies a fully deterministic version of ECDSA, the signature scheme Bitcoin has used since its launch to authorize transactions. Under existing rules, a signer has latitude over a value called the nonce, a one-time number chosen during signing, and that freedom lets compromised firmware encode fragments of a secret key inside a signature that still passes verification. Gilligan’s draft closes that gap by fixing every choice in the signing process, so any two honest, compliant signers given the same key and message must output the identical result.

The document was merged into the BIPs repository on Sept. 16. It remains marked Draft, the earliest formal stage in the BIP process.

According to its report on the proposal, CryptoSlate noted that BIP461 requires no change to Bitcoin’s consensus rules, since the resulting signatures remain valid under existing validation logic. The fix operates entirely at the signer level, meaning wallet and hardware vendors can adopt it without any network upgrade or soft fork.

Standardization Turns a Signature Into a Checkable Benchmark

The vulnerability BIP461 targets was formalized by the Dark Skippy disclosure, which showed that corrupted wallet firmware could embed seed material inside transaction signatures without failing verification. Dark Skippy’s original demonstration used Schnorr signatures, the scheme behind Taproot, while BIP461 covers ECDSA; Taproot uses the separate BIP340 Schnorr scheme, so the new draft does not directly standardize a remedy for that specific demo.

Detection works by loading the same key into two independent signers, signing the same message on both, and comparing the output. A mismatch proves at least one signer deviates from BIP461, though it does not by itself prove theft or identify which device is malicious.

Another important motivation is that signatures produced according to a standardised approach will be byte-identical. This means signers can be compared to ensure they are not leaking secrets by embedding them in signatures (e.g. Dark Skippy).

Sjors, reviewer on the related Bitcoin Core pull request

The proposal’s mitigation discussion warns the check has a real limit: a malicious device could pass a test signature while leaking only on a selected real transaction, so a single matching comparison confirms nothing beyond that one sample. The document itself states that standardization alone “is what enables leak detection,” since a nonstandard algorithm has no reference to cross-check against. Our Crypto Coin Show coverage of a separate post-quantum signing proposal for Lightning shows developers are tackling signer-security gaps across multiple layers of the Bitcoin stack this year, not just at the base layer.

Test Vectors and Reference Code Remain Unbuilt

BIP461 carries a secondary benefit: its deterministic algorithm also grinds signatures to a maximum of 70 bytes in DER encoding, by enforcing low-r and low-s forms, with the side effect that a non-grinding signer becomes identifiable on-chain by its high-r signatures.

At the September merge, a reviewer said reference implementation code and test vectors were still listed as “TODO” and necessary before BIP461 could progress from Draft to Complete.

The CCS read. For institutional custodians, this draft matters less as a protocol change than as an audit tool for vendor firmware. Firms with large on-chain reserves, like the one disclosed in Strategy’s 8-K filing, could eventually require hardware signers to pass BIP461 comparisons as a procurement condition, shifting signer verification from a trust assumption to a contractual one once compliant implementations exist.

BIP461 cannot advance beyond Draft until someone publishes the missing reference implementation and test vectors, work the jeanpablojp offer on the pull request has proposed but not yet delivered. Until that code lands and hardware vendors adopt the deterministic algorithm, the detection benchmark Gilligan designed exists on paper only.