Nonce-Wiederverwendungs-Checker für Ethereum

Why one repeated value exposes a key

Every Ethereum transaction is signed with ECDSA over secp256k1. Each signature uses a fresh secret nonce k; its public trace is r, the x-coordinate of the point k·G, which is written into the transaction next to s. The signing equation is s = k⁻¹ · (z + r · d) mod n, where z is the hash of the signed transaction and d the private key.

Two signatures by the same key with the same r but different messages give two such equations with the same two unknowns, k and d. Subtracting them yields k = (z₁ − z₂) / (s₁ − s₂), and then d follows from either signature. Anyone who sees both transactions on chain can do this arithmetic; that is how the PlayStation 3 signing key leaked in 2010 and how wallets with broken random number generators were drained, including Android Bitcoin wallets in 2013. Even partial bias in k is enough for lattice attacks (the hidden number problem), which is why modern signers derive k deterministically with RFC 6979 or mix randomness into it (hedged signatures).

What the checker reports

The checker decodes every transaction — legacy, EIP-2930, EIP-1559, blob and EIP-7702 envelopes — recovers each signer with the same arithmetic as ecrecover, and groups the signatures by signer and r:

• Key exposed — one signer, one r, two or more different signed messages. The private key can be computed from any two of them.
• Predictable nonce — an r that comes from a tiny nonce, k ≤ 1024 (or n − k, which gives the same r) or k = 1/2 mod n. The checker precomputes those points once; a signature that uses one exposes its key on its own.
• Shared between keys — different signers with the same r. That exposes neither key by itself, but it points at a shared broken generator, or at keyless deployments such as "Nick's method", where r and s are chosen by hand so that nobody holds the key at all (ethereum/tests uses the same trick for its vectors, which is why its example shows this finding).
• Harmless repeats — the same transaction listed twice, or its malleated twin with s′ = n − s (malleability; nodes reject the high-s form since EIP-2). The message is the same, so nothing leaks.

Exposed signers come first, with the two transactions that prove the leak. Unsigned transactions, undecodable items and signatures with no recoverable signer are listed separately with the reason they were skipped.

How an address scan works

To check an account rather than a list, the scan collects the transactions it sent. Blockscout's API v2 lists them newest first (/api/v2/addresses/<address>/transactions?filter=from), following its pagination up to the limit you choose; its lists carry no signatures, so each transaction is then fetched with eth_getTransactionByHash from a public JSON-RPC node of the same network, four at a time, and rebuilt into bytes — the hash the node reports is checked against the rebuilt one. The scan is available on the networks whose Blockscout instance answers browsers directly (Ethereum, OP Mainnet, Gnosis, Scroll and three testnets); for other chains, paste the transactions instead.

Only the newest transactions within the limit are checked. A key leaked by two old transactions is found only if both are within that window — the result says when older transactions were left out.

Why it never computes the key

Computing the private key from two signatures would turn a diagnostic into a theft tool, and a page that holds a recovered key is one more place it can leak from. The checker therefore stops at the proof that a key is exposed and names the transactions; it does not solve the equations above, and nothing it shows or puts into a share link is secret. If your account is listed, assume the key is known and move every asset to a new key generated by a different wallet.

What runs locally, and what is sent

Pasted transactions are decoded and compared in your browser and never sent anywhere. A scan, started only by its button, sends the address to the Blockscout explorer of the chosen network and each transaction hash to a public RPC node of that network; both are public data. Bitcoin addresses are covered by the Bitcoin nonce reuse checker; to read a single transaction field by field, use the Ethereum transaction decoder. The background is in the article on ECDSA nonce reuse and the comparison of deterministic and randomized ECDSA.