A Bitcoin private key, recovered from its public key
A Bitcoin private key is normally unfindable. But when the key is known to sit inside a narrow range, handing over the matching public key changes the problem completely: the work drops to roughly the square root of a brute-force sweep. This page does it to a key it makes in front of you, so you can watch how quickly it happens.
This has really happened, more than once. Bitcoin Puzzles 66 and 69 were both front-run and stolen by bots in the seconds between their solvers broadcasting a spend and it being mined. The bots read the public key out of the mempool, recovered the private key, and rebroadcast at a higher fee. The two puzzles solved since are both reported to have been claimed without a public broadcast, though their solvers have not said so.
The demonstration
Runs in this tabRange
This demo runs as a WebGPU compute shader and this browser did not offer one, so nothing here will run. The explanation on this page still holds; you just cannot watch it happen. Chrome, Edge and Safari 18 support WebGPU, and on Linux it usually means Vulkan is switched off rather than the hardware being incapable.
The target
- Range
- 0x to 0x
- Private key
- generated when you press the button
- Address
- generated when you press the button
- Public key
- generated when you press the button
Result
- Recovered
- Generated above
- Jumps taken
- Time
- Brute force
01 With only the address
An address reveals nothing but a hash. The only way in is to try keys one at a time and hash each one, which is what the main Krackpot search does. Let us find out how fast your machine does that.
That figure is a reference card rather than yours, and it is calculated rather than run. The kangaroo runs on your hardware, so the two sides are not measured the same way. Measure your machine to make them match.
02 With the public key
Now the attacker gets what a spend would publish. Pollard's kangaroo walks two herds through the range, one from a known position and one from the target, until their paths collide on the secp256k1 curve. It needs about jumps against the keys above, which is times less work for the same key.
That is what happened to Puzzle 66. Its solver published a spend, which handed a watching bot the public key and so the work above. The coins moved before the original transaction confirmed.
That ratio counts operations, so it is the same on any machine. What changes with your hardware is how long each side takes.
03 What this does not show
The attack above depends on conditions that ordinary Bitcoin keys do not meet.
Ordinary Bitcoin keys are not affected by any of this
A properly generated private key is spread across roughly 2to the power of 256 possibilities. The square root of that is 2to the power of 128, which is not attackable by anyone, with any budget, ever. The kangaroo only helps when the range is already known and already narrow. It solves the interval discrete logarithm problem, so with no interval there is nothing for it to walk.
Publishing a public key is normal and safe
Every reused address, every pay-to-public-key output, and every Lightning channel exposes a public key, and none of them are in danger. The risk here needs two things at once: a range that is known and narrow, and an exposed public key. One without the other is nothing.
The danger is anything that shrinks the range
Puzzle addresses shrink it deliberately, which is the whole design of the puzzle. The real lesson is the accidental case: a broken or low-entropy random number generator produces keys from a range far smaller than it should, and if one of those keys ever exposes its public key, the same arithmetic applies. That is a genuine class of wallet bug, and it is the reason this demo is worth publishing.
Nothing here implies that Bitcoin is broken, that quantum computers are involved, or that your wallet is at risk. The claim is narrower than that.
The same WGSL engine, pointed at a real 7.1 BTC target: krackpot.io