On 15 January 2015 a single bitcoin transaction paid 256 addresses in ascending amounts, from 0.001 BTC to 0.256 BTC, 32.9 BTC in all. The private key of each address was generated so that its top bits are zero: the key of address n has exactly n significant bits. Put another way, it is a whole number from 2n-1 up to 2n minus 1. The person who built it has described it as a rough gauge of how many bits the world can search. The amounts were later topped up, more than once, and as low addresses were claimed the attention moved up the row.
The first 160 addresses are the puzzle proper. The id of the transaction is on the paper's public record table, and the site reads its outputs to learn the addresses.
A bitcoin private key is a number. Its public key is that number times a fixed point on a curve called secp256k1, which is easy to compute forward and, for a full size key, not feasible to run backward. The public key is written in 33 bytes: a first byte that is 02 or 03 depending on whether the point's y coordinate is even or odd, and then the 32 bytes of x. That is hashed with SHA-256, the result is hashed with RIPEMD-160, and the 20 bytes that come out are called the hash160. An address is the hash160 with a version byte in front and a four byte checksum behind, written in base 58.
The scanner never builds the address string. It decodes the target address once to recover its 20 bytes and compares hash160 with hash160, which is the same test with less work.
Two hash functions stand between the address and the public key, and neither can be run backward. Given only the address, the one thing a searcher can do is try a key and see. Each try is independent of the last. There is no getting warmer, no partial credit and no clever ordering. The expected number of tries is half the range and the worst case is all of it.
Once an address has spent, its public key is on the chain for anyone to read. Then the hashes are out of the way and the question becomes: which number in this range, times the generator, gives this point. Pollard's kangaroo method answers that in about two times the square root of the range in curve operations. A range of 134 bits becomes a job of about 268 steps. That is still enormous, but it is why the amber cells on the paper are being worked by other people with other tools, and why this machine leaves them alone.
For each of the 160 addresses the site keeps three facts from the chain: how much it holds, how many times it has been paid, and how many times it has spent. Holding nothing means claimed. Holding something and never having spent means open with only the address known. Holding something and having spent means open with the public key known. The target is the lowest numbered address of the second kind. The rule is applied again every time a balance is read.
The machine keeps one running figure, keys owed. Each trade of the coin that the site sees adds to it.
Here usd is the dollar size of the swap as reported by the market data source. Buys and sells count alike. A trade whose size cannot be determined adds nothing. Each chunk the scanner completes takes 1,024 off the figure. The scanner runs whenever the figure is at least 1,024 and rests when it is not. There is no calendar anywhere in this. Work begins with a trade and ends when that trade's work is done.
Take the target's number N. Its keys have N minus 1 free bits. The top 12 of those name a sector, so there are 4,096 sectors. The bottom 10 count keys within a chunk, so a chunk is 1,024 keys. The bits in between number the chunks inside a sector.
Any chunk the machine reports can be rebuilt from its sector and chunk number with that line, and anyone with a laptop can run the same 1,024 keys and compare.
The first time a sector is opened, the scanner needs a chunk to start at. It takes the signature of the newest trade of the coin, joins it to the sector number, hashes that with SHA-256, and reads the leading bits as the starting chunk. After that the sector goes forward one chunk at a time and wraps at the end. The signature that opened each sector is listed on the machine page with a link, so the starting point of every sector traces back to a Solana transaction that the site did not write.
One. Compute the curve point of the chunk's first key. Two. Add the generator point to it 1,023 times, keeping every result. Three. Convert all 1,024 points to plain coordinates in one batch, which shares a single costly division across the whole chunk. Four. For each point, form the 33 byte public key and take its hash160. Five. Compare with the target's 20 bytes. Six. Remember the key that matched the most leading bits. Seven. Write the chunk down: where it started, how long it took, and its nearest miss.
The rate shown on the site is keys divided by time over the newest hundred chunks. It is a measurement, and it is small. This is a scanner that runs on ordinary server time bought by trading, not a hall of graphics cards.
A scanner that derives addresses wrongly would report misses forever and nobody would know. So before anything else it is run against the first twelve puzzles with nothing but their addresses, and has to find all twelve keys by counting. Those keys are listed on the machine page as numbers. The first is 1. If the scanner cannot find them, nothing else on the site is worth reading, and the self test count on the paper would show it.
The director is a Mythos model called through its maker's ordinary public interface. It is woken when the work owed since its last call reaches 220 keys. It is given the target, the range, the prize, the rate, the best match so far, a list of every open sector with its chunk count, and its own last three notes. It must answer with a sector number and a short note. A fixed check accepts or refuses the answer, and both outcomes are recorded with the model's own reported name and the tokens the call used.
If the model is not reachable, or its answer is refused, the sector is taken from the hash of the newest trade signature. The scanner never waits on the model.
The model is told the truth about its position: no sector is better than another. Its job is coverage and record keeping. If you are looking for the place where a clever machine outsmarts a hash function, it is not here and it is not anywhere.
For each chunk the scanner keeps the key whose hash160 shared the longest run of leading bits with the target. After k keys the longest run should be near log2 k. The machine page prints the measured best beside that expectation. The figure exists so the work can be audited from outside. It says nothing about where the real key is.
The scanner writes the key to a private table, marks the address as found, and moves on to the next target. The key is not shown, not logged and not sent to any browser. The site does not hold bitcoin and does not make bitcoin transactions.
Spending from an address reveals its public key in the transaction, and a transaction is public from the moment it is announced, before any block includes it. For a key of seventy odd bits, the square root method recovers the private key from the public key in very little time. A watcher can do that, write a competing transaction with a higher fee, and take the prize. The defence is to hand the transaction straight to a miner so that it is never announced at all.
Two values sit at the top: what the whole coin is worth, which is its price times its supply, and the price of bitcoin. Both are read once a second. Under each is a plate of 64 columns, one for each of the last 64 minutes, newest on the right. A column is sixteen cells tall. The value in that minute is placed on a scale from the lowest to the highest value in the window and rounded to one of sixteen levels, and the column is filled up to that level. The top cell is green if the value was at or above the minute before and red if it was below.
Sixteen levels is one hexadecimal digit, so each column has a digit printed under it and the whole plate spells a string of 64 digits, the same length as a bitcoin private key written out. It changes every minute and its last digit changes with the price. It is a picture of the last hour and nothing more.
| WHAT | SOURCE | HOW OFTEN |
|---|---|---|
| Coin price, bitcoin price | Birdeye, read on the server | every second |
| Supply, holders, 24 hour volume | Birdeye | every 15 seconds |
| Minute history for both plates | Birdeye | every 20 seconds, last column every second |
| Trades of the coin | Birdeye | every second |
| Puzzle addresses | outputs of the puzzle transaction, via mempool.space | once |
| Puzzle balances | mempool.space, blockstream.info as a second source | one address every 3 seconds, the target more often |
| Chunks, sectors, nearest misses, self test | computed by the scanner | as each chunk completes |
| Director notes | the model's reply, checked by code | as each wake completes |
The bitcoin price is taken from a bitcoin backed token on Solana because that is what the market data source prices. Its mint is on the paper's public record table.
The machine is slow next to dedicated hardware and says so in its own rate. The share of the range it will ever cover is a number with many zeros after the decimal point, and the paper prints it. A sector's starting chunk is drawn from a hash and two sectors never overlap, but other hunters around the world are working the same range and nobody shares a map, so some of these keys have certainly been checked before by someone else. And the director is only as available as the interface it is called through.
Will it find the key?
Almost certainly not, and the table on the paper shows why in years.
Then why run it?
Because the attempt is real, the count is public, and a key checked is a fact that stays true.
Does holding the coin give me a claim on a prize?
This paper makes no such promise. It describes a machine. Read the section on what bithos is not.
Can I point the scanner somewhere?
No. Trades set how much it works. Trade signatures and the director set where. Nobody types anything into it.
Can the model cheat?
It can only name a sector, and a sector outside 0 to 4,095 is refused. It never sees a key that matters, because a found key goes to a table it is not shown.
Why does the count stop sometimes?
Nobody traded. No trade, no work owed, nothing to scan.
How do I check a chunk myself?
Take its sector and chunk number from the machine page, apply the first key formula, derive 1,024 addresses, and compare the best match with the one printed.