Austin Griffith Demonstrates How Fast Bots Can Drain Weak Ethereum Keys

Introduction

In a recent demonstration, Austin Griffith of the Ethereum Foundation placed roughly $1 (0.0004 ETH) into a wallet whose private key was the simple number 6969. Within seconds, automated bots detected the transaction and swept the funds, paying most of the amount in network fees. The experiment underscores how easily guessable private keys—especially those under 256—are already being targeted on Ethereum’s mainnet.

Why Small Keys Are Already Compromised

Griffith’s test builds on a broader finding: every private key from 1 to 255 has at least one transaction recorded on Ethereum. This means that bots continuously scan the blockchain for low‑entropy keys and instantly act when they spot a funded address. The speed of the response—three pending transactions appeared in the mempool almost immediately after the deposit—demonstrates that the ecosystem is saturated with automated agents ready to exploit any weak key.

The Context: A Recent Certificate Authority Failure

The experiment was prompted by a security incident at eMudhra, an Indian certificate authority. A disclosure site set up by Mozilla’s Dennis Jackson revealed that eight intermediate certificates issued by eMudhra in April 2025 used private keys that were simple numbers below 256, one of them being 4. Browsers quickly revoked the compromised certificates, but the episode highlighted a broader issue: low‑entropy keys are not just a theoretical risk; they appear in real‑world security infrastructure.

Testing Longer Keys – Early Results

Griffith extended the experiment beyond three‑digit keys. He seeded wallets with 10‑digit, 12‑digit, 14‑digit, and 16‑digit private keys, each funded with about a dollar. Early observations show:

• 10‑digit keys were drained almost immediately, mirroring the behavior seen with the 6969 key.
• 12‑digit keys had not yet been drained at the time of reporting.
• 14‑ and 16‑digit keys were also seeded, but their status remains unknown; the hosts plan to revisit the data next week.

On‑chain records indicate that after the initial 6969 transaction, the address slop.atg.eth (funded by austingriffith.eth) created four additional addresses about 14 minutes later. One of these was emptied within 12 seconds, while the other three still held their funds as of Oct 23. The exact key lengths associated with each address were not disclosed, preventing independent verification.

Practical Takeaways for Developers and Users

1. Never use low‑entropy private keys – Even a three‑digit number is already known to the network. Always generate keys with sufficient randomness using reputable wallet software.
2. Monitor new address activity – If you must fund a newly created address, watch the mempool for unexpected pending transactions.
3. Consider additional safeguards – Multi‑signature wallets, hardware wallets, and time‑locked contracts can add layers of protection against automated theft.
4. Stay informed about broader security incidents – The eMudhra case shows that weak keys can appear outside the crypto space, potentially affecting downstream blockchain interactions.

Conclusion

Griffith’s live experiment provides a stark, real‑time illustration of how bots dominate the search for weak Ethereum private keys. The fact that every key under 256 has already been used on mainnet suggests a pervasive, ongoing threat. As the community continues to explore the limits of automated key‑guessing, developers, custodians, and everyday users must prioritize strong key generation practices and consider additional security mechanisms to protect even the smallest amounts of value.