Every ECDSA signature spends a one-time secret called the nonce. If a wallet's random number generator ever repeats one, two signatures by the same key end up sharing the same r — and the blockchain publishes it. Paste a Bitcoin address to check its recent signatures for that fingerprint.
This tool queries the public mempool.space API — the address you enter is sent to our server and on to mempool.space. No keys or signatures of yours are involved.
What a nonce is. Signing with ECDSA needs one fresh secret number per signature, the nonce k. The signer computes the curve point kG and takes its x-coordinate as r, then s = k⁻¹(h + r·d) mod n, where h is the message hash and d is the private key. The pair (r, s) is what gets published. k itself is never published — but r is derived from k alone, so r acts as a public fingerprint of the nonce.
Why a repeated r matters. Two signatures from the same key with the same r mean the same k was used twice. That gives two equations, s₁ = k⁻¹(h₁ + r·d) and s₂ = k⁻¹(h₂ + r·d), with only two unknowns — k and d. Subtracting eliminates d, k = (h₁ − h₂)/(s₁ − s₂), and substituting back yields the private key. It takes a few lines of arithmetic and no computing power worth mentioning, using only data that is already public in the blockchain. This is why nonce reuse is treated as a total compromise rather than a weakness.
Where it came from. This is a defect of implementation, not of the algorithm. The best-known case is the August 2013 Android wallet incident: Android's SecureRandom could be initialised without proper entropy, several Bitcoin wallets on the platform produced repeating nonces, and the affected coins were swept by whoever noticed first. The standing fix is to stop relying on randomness at all: RFC 6979 derives k deterministically from the private key and the message hash via HMAC, so the same signer produces the same nonce only for the same message, and a broken RNG cannot leak the key. Every maintained Bitcoin wallet, and libraries such as libsecp256k1, sign this way today. Bitcoin also tightened signature encoding in BIP-62 and BIP-66, and Taproot signatures follow BIP-340, which mandates a deterministic nonce outright. Deterministic derivation of the keys themselves is a separate matter, standardised in BIP-32.
What this page actually does. It asks the public mempool.space API for the address's most recent transactions, keeps the inputs that spend from that address, and pulls the signatures out of them: a scriptSig push for P2PKH and P2SH, witness items for P2WPKH and P2WSH. Each signature is ASN.1 DER — SEQUENCE { INTEGER r, INTEGER s } — followed by a one-byte sighash flag. The extracted signatures are grouped by (public key, r); a group holding more than one distinct s is the defect. If one is found, the tool says so and tells you to move the funds. It stops there: the key-recovery step is deliberately not implemented here.
Limits worth knowing. The public API returns at most 50 transactions per address, so this is a check of recent history, not an audit of the whole chain — a clean result is reassuring, not a proof that the wallet's randomness was ever sound. Signatures in m-of-n multisig inputs cannot be attributed to a specific key from the script alone and are counted but excluded. Taproot inputs carry Schnorr signatures, which have no ECDSA r to compare. And an address that has only ever received coins has published no signatures at all.
Privacy. This is the one tool on this site that is not purely local. The address you enter is sent to our server, which forwards it to mempool.space and returns the aggregated report; mempool.space sees the request from our server rather than from your browser. Nothing else is transmitted — no keys, no signatures of yours, no wallet data — and the address is not stored. If you would rather not disclose the address at all, run your own mempool instance or an Electrum server and query it directly.