Bitcoin puzzle transaction

The puzzle

One transaction in January 2015 funded 254 addresses. Puzzles 1 and 2 were already there, funded in 2013 and 2014. The author said what the keys were in the one post the account ever made, on bitcointalk in April 2017: "There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty)." That mask puts the key of puzzle n somewhere in [2^(n-1), 2^n - 1]. That quote is the collection's hint, so every record inherits it through bits.hintsFor(n) and puzzles_hints, with the post as its source and a Wayback capture of the thread as what confirms it. The low ones fell in hours. Puzzle 1 is key 1. The high ones are out of reach for anyone without a very specific budget. The middle is where the scanning community lives. The prizes were raised in 2017 and again in 2023, so bits/71 holds 7.1 BTC today for a key of 71 bits.

An open record declares its width with bits(n). A solved one carries it as the second argument of hex(key, n). Either way keyRange() turns it into the two bigint bounds. The width marks a search space and nothing else, so it's absent on every other collection.

const puzzle = bits.require(71);

puzzle.keyRange(); // [2n ** 70n, 2n ** 71n - 1n]
puzzle.hasPubkey(); // false by design: no public key, so nothing beats scanning the range

Why bits

The key used to be b1000, a number you couldn't explain from any record, on prizes that got raised twice anyway. Now it says the one thing that never moves: puzzle n hides a key n bits wide. So bits/71 tells you the width before you open it. Well, 70 unknown bits, because the top one is always set.

The old key still resolves. get("b1000/71") lands on bits/71, and old links to these pages redirect here. Keep two names apart, though. The root's bits(n) writes a record's width, while this collection's bits holds the puzzles. Same word, two jobs. Need both in one file? An import alias settles it.

Solved, swept, unsolved

A solved puzzle has its key on the record as hex(…, n).wif(…). The data gate derives the address from it on every test run. The highest published key is 135 bits, solved in July 2026 for 13.5 BTC.

swept is the other large group. Once a puzzle's public key became known, through an earlier spend or a reveal, its address could be attacked with Pollard's kangaroo instead of brute force. And people did. Those records carry the sweep transaction and, where the sweeper published it, the key. The status is written down because the transaction list alone can't tell a sweep from a solve.

bits.solved().length; // keys published by whoever found them
bits.unsolved().length; // still funded, still waiting
(await selectPuzzles({ collection: "bits", status: Status.Swept })).length; // emptied once the public key leaked

The record

export const bits1 = puzzle({
  id: "bits/1",
  chain: "bitcoin",
  address: "1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH",
  sourceUrl: "https://bitcointalk.org/index.php?topic=5218972",
  startedAt: "2013-01-09 11:59:15",
  status: Status.Solved,
  pubkey: compressed("0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798"),
  key: hex("0000000000000000000000000000000000000000000000000000000000000001", 1).wif(
    "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn",
  ),
  prize: 0.001,
  solvedAt: "2013-01-10 02:54:44",
  solveTime: 53729,
  preGenesis: true,
  transactions: [
    funding("9223…808e", "2013-01-09 11:59:15", 0.03),
    claim("3da9…4277", "2013-01-10 02:54:44", 0.03),
  ],
});

preGenesis: true marks puzzles 1 and 2, funded in 2013 and 2014 before the January 2015 transaction. That's why puzzle 1 moves 0.03 BTC in its transactions while the recorded prize is the 0.001 the series assigns it. The collection is a NumericCollection. bits.get(71), bits.get("71") and bits.get("bits/71") all land on the same record.

Every puzzle

One page each: the record, the transactions and the live balance.