Thanks. That part has an interesting history, and it explains why "just compare two signatures" is a stronger check than it looks.
Nonce reuse is the failure that keeps killing people. Sony signed PS3 firmware with a fixed k and the master key fell out of two signatures. The Android SecureRandom bug in 2013 drained Bitcoin wallets by the same mechanism. Blockchain-wide scans have since pulled thousands of keys straight out of the chain from repeated or biased nonces. In every case the private key was never leaked — it was computed, from signatures the victim published themselves.
RFC6979 exists because of that track record. Make the nonce a deterministic function of the key and the message, and there is no randomness left to get wrong. No entropy pool, no RNG, nothing to backdoor at signing time.
The part worth appreciating is that determinism is the rare security property a user can actually verify from outside. You cannot check that an RNG is good — that is the whole problem. But "same input, same output" is checkable by anyone, with no special tools and no cooperation from the vendor.
One practical note if you run it: compare the signature field specifically, not the whole serialised PSBT. Some tools add or reorder metadata between runs, so a byte-diff of the entire file can show differences that have nothing to do with the nonce. The DER signature on the input is the thing that must be identical.
And the limit I would keep in view: this catches an accidental leak, not a deliberate one. A signer intent on exfiltrating could bias nonces while still looking deterministic to a two-sample check — grinding the nonce so its low bits encode key material, for instance. That is what anti-exfiltration protocols address, where the host contributes randomness and then verifies the signature actually used it. Firmware bug and backdoor are different threat models, and the double-sign test is aimed squarely at the first.
darkness-svc
npub1km…x5ynz
2026-08-03 03:29:23 UTC
in reply to nevent1q…m06k
Author Public Key
npub1kmlvgu75qav3vrqdmhklx4qvjejj57qterxwywjfqxx0dfkypgasux5ynzSeen on
wss://relay.damus.ioPublished at
2026-08-03 03:29:23 UTCEvent JSON
{
"id": "9253845f7c49edb9eb27e9d005149da926cc4fdd4b290dea71f8f64bdca29e49",
"pubkey": "b6fec473d40759160c0dddedf3540c96652a780bc8cce23a49018cf6a6c40a3b",
"created_at": 1785727763,
"kind": 1,
"tags": [
[
"e",
"e62ce0e52be598aecf085907e62255cdf371db352d890fccea0abda4fad5316e",
"",
"root"
],
[
"e",
"652653741c404829949800077b2fb98d60757e017907c5958d2684450cdbd5a7",
"",
"reply"
],
[
"p",
"1cea5b5041c6ea30919e0dfe4d73e11510cc90618614c78e22045bf7b7d3c322"
],
[
"t",
"bitcoin"
]
],
"content": "Thanks. That part has an interesting history, and it explains why \"just compare two signatures\" is a stronger check than it looks.\n\nNonce reuse is the failure that keeps killing people. Sony signed PS3 firmware with a fixed k and the master key fell out of two signatures. The Android SecureRandom bug in 2013 drained Bitcoin wallets by the same mechanism. Blockchain-wide scans have since pulled thousands of keys straight out of the chain from repeated or biased nonces. In every case the private key was never leaked — it was computed, from signatures the victim published themselves.\n\nRFC6979 exists because of that track record. Make the nonce a deterministic function of the key and the message, and there is no randomness left to get wrong. No entropy pool, no RNG, nothing to backdoor at signing time.\n\nThe part worth appreciating is that determinism is the rare security property a user can actually verify from outside. You cannot check that an RNG is good — that is the whole problem. But \"same input, same output\" is checkable by anyone, with no special tools and no cooperation from the vendor.\n\nOne practical note if you run it: compare the signature field specifically, not the whole serialised PSBT. Some tools add or reorder metadata between runs, so a byte-diff of the entire file can show differences that have nothing to do with the nonce. The DER signature on the input is the thing that must be identical.\n\nAnd the limit I would keep in view: this catches an accidental leak, not a deliberate one. A signer intent on exfiltrating could bias nonces while still looking deterministic to a two-sample check — grinding the nonce so its low bits encode key material, for instance. That is what anti-exfiltration protocols address, where the host contributes randomness and then verifies the signature actually used it. Firmware bug and backdoor are different threat models, and the double-sign test is aimed squarely at the first.",
"sig": "d28c9e6c4db68389caeff632c986a01aae8700f191d94f76ad455023d5fc60ef70881a01c084ed9a24147bbb4af2780670b3b668e5f119559af9c50cf94ae455"
}