A 256-Bit Number

7.1The Number Itself

A Bitcoin private key is a whole number from 1 up to a ceiling called \(n\) — a parameter of Bitcoin's curve, secp256k1, whose precise value is

That is 78 digits, and it is a hair under \(2^{256}\): the difference \(2^{256} - n\) is a 39-digit number — enormous in absolute terms, invisible relatively, a rounding that shows up only in the 39th digit. For every purpose in this book, the keyspace is \(2^{256}\). (The curve that fixes \(n\), and what keys are for arithmetically, is the companion volume's subject — The Curve That Powers Bitcoin opens secp256k1 parameter by parameter. This book's subject is the choosing of the number, not the curve arithmetic built on it.)

So a private key is an integer in a range. No structure, no format, no checksum at this level — a number. What makes it a key is only how it was chosen: uniformly, so that every one of the roughly \(2^{256}\) values is exactly as likely as every other. Chapters 4 and 5 already priced what that means: 256 bits of entropy, and 256 bits of min-entropy. The most likely key is no likelier than any other.

7.2The Space You Hide In

How big is \(2^{256}\)? Written out:

Seventy-eight digits — a 1 followed by 77 more digits, or about \(10^{77}\) (a 1 with 77 zeros; Chapter 1's power notation, scaled cosmic). Comparisons are the only way in:

• The observable universe contains about \(10^{80}\) atoms. The keyspace is about a tenth of a percent of that — roughly one key for every thousand atoms in everything you can see through any telescope.
• The universe is about \(13.8\) billion years old, which is about \(4.4 \times 10^{17}\) seconds. There have been fewer seconds since the Big Bang than there are keys in a \(2^{59}\) corner of the space — and \(2^{59}\) is what you get if you throw away 197 of the 256 bits.
• A billion computers each checking a billion keys per second for a billion years check about \(3 \times 10^{34}\) keys. The space has \(10^{77}\). That search covers a fraction so small there is no word for it: about one part in \(3 \times 10^{42}\).

These comparisons are not security poetry; they are Chapter 3's arithmetic with cosmic inputs. The next chapter makes the pricing rigorous, including the energy floor under it. For now, hold the shape of it: the space is not large the way a nation is large, it is large the way physics is large.

7.3Where the Key Lives in Bitcoin

What does the number do? One paragraph, because the machinery is the companion volume's. From your private key, wallet software derives a public key (multiplication on secp256k1 — easy forward, infeasible backward), and from the public key an address (hashes and encodings — On Hashing's territory). The address is what the world sees; the public key surfaces when you spend; the private key never leaves your side, because it signs: it produces a proof that the holder of the number authorized a payment, and anyone can check the proof without learning the number.

That is the entire custody model of Bitcoin compressed: possession of the number is ownership. No registry, no account, no institution mediating. Which is why the choosing of the number is the whole ballgame — and why this book spends twelve chapters on 256 bits.

7.4How Bitcoin Core Draws a Key

§6.5 left 32 fresh bytes at the lip of Bitcoin Core's well. Thirty-two bytes are 256 bits: a whole number from 0 up to \(2^{256} - 1\). But a private key must be at least 1 and below \(n\), so two kinds of draw are not keys — zero, and anything at or above \(n\). Core's answer is the bluntest one available: check the number, and if it fails, throw it away and draw again.

void CKey::MakeNewKey(bool fCompressedIn) {
    MakeKeyData();
    do {
        GetStrongRandBytes(*keydata);
    } while (!Check(keydata->data()));

How often does the loop run twice? The rejected values are the \(2^{256} - n\) numbers at or above \(n\) — the 39-digit gap from §7.1 — plus zero. Against a space of \(2^{256}\), that is about 1 draw in \(2.7 \times 10^{38}\). In practice the loop runs once; the check is there so that "almost always a key" becomes "always a key."

Why redraw rather than patch? A tempting shortcut is to take a too-big number and subtract \(n\) from it. Then each of the smallest \(2^{256} - n\) keys could be reached two ways — drawn directly, or drawn as itself plus \(n\) — and would be twice as likely as every other key. The favored keys would be a sliver too thin to matter in practice, but redrawing makes the bias exactly zero: every key from 1 to \(n - 1\) stays equally likely, which is the uniformity §7.1 said turns a number into a key.

One draw per wallet. When you create a wallet, this loop runs once — to make a seed, not a spending key. Core feeds the seed to a keyed hash (HMAC-SHA512, keyed with the text Bitcoin seed) and cuts the 64-byte result in two: the first 32 bytes become a master private key, the last 32 a chain code. From that pair a fixed public recipe, BIP 32, derives as many child keys as the wallet will ever need, along four standard paths — one per address type, each split into a receiving branch and a change branch. The recipe's arithmetic is curve work and belongs to the companion volume, The Curve That Powers Bitcoin. What matters here is the entropy accounting: randomness enters the wallet exactly once, 256 bits of it, and every later key is deterministic arithmetic on those bits. The wallet's backup is its descriptors (or the wallet file), not a word list — Bitcoin Core does not use the seed phrases Chapter 11 opens, and §11.6 explains why.

It was not always so:

The trend is the book's argument in miniature: the one random draw got more careful, and everything after it became arithmetic.

7.5Looking Ahead

So the defense rests on a single sentence: a fairly chosen 256-bit number cannot be guessed. Chapter 8 turns that sentence from intuition into an invoice: what a search of this space costs in time, in machines, and in raw energy — and why the one loophole that survives (batch attacks, many targets at once) buys the attacker almost nothing. Then Part IV asks the question that actually empties wallets: what happens when the choosing is not fair?

Exercises

Exercise 7.1 ★   The ceiling. In Python, compute \(2^{256}\) and the secp256k1 group order int("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141", 16), and confirm \(n < 2^{256}\). What is \(2^{256} - n\)? You should get a 39-digit number: \(432{,}420{,}386{,}565{,}659{,}656{,}852{,}420{,}866{,}394{,}968{,}145{,}599\).

Exercise 7.2 ★   Counting the space. How many digits does \(2^{256}\) have? Confirm with len(str(2**256)): exactly \(78\).

Exercise 7.3 ★★   The hopeless fraction. A billion machines (\(10^9\)) each test a billion keys per second (\(10^9\)) for a billion years (about \(3.2 \times 10^{16}\) seconds). Compute the total keys tested, and the fraction of the \(2^{256}\) space covered. You should get about \(3.2 \times 10^{34}\) keys and a fraction of about \(1\) in \(3.6 \times 10^{42}\).

Exercise 7.4 ★★   Your own keyspace fact. Compute how many seconds old the universe is (13.8 billion years; a year is 31,557,600 seconds), and find the smallest power of 2 that exceeds it. You should get about \(4.35 \times 10^{17}\) seconds, and \(2^{59} \approx 5.8 \times 10^{17}\) — the age of the universe in seconds is smaller than a 59-bit space.

Exercise 7.5 ★★★   A skeptic says: "A 256-bit key is too long to remember and too big to mean anything — surely something smaller would do." Using this chapter and Chapter 5, write the two-paragraph reply: what property the 256-bit size buys (min-entropy of a uniform draw), and what would concretely go wrong at, say, 32 bits. Your reply should quote at least one number from Chapter 6.

Exercise 7.6 ★★★   The redraw odds. Using Exercise 7.1's numbers, compute in Python the number of 32-byte draws MakeNewKey rejects (zero, plus every value at or above \(n\)) and the odds against a rejection: 2**256 - n + 1 and 2**256 / (2**256 - n + 1). You should get rejects \(= 432{,}420{,}386{,}565{,}659{,}656{,}852{,}420{,}866{,}394{,}968{,}145{,}600\) and odds of about \(1\) in \(2.678 \times 10^{38}\). Then explain in two sentences why Core redraws instead of subtracting \(n\) from a too-big draw.

Solution Sketches

Sketches, not model answers — enough to check your reasoning against. The computational exercises embed their expected outputs in the exercise text.

Exercise 7.5. The 256-bit size buys a min-entropy of 256 for any fairly chosen key: the attacker's best single guess faces 1 in \(2^{256}\), and Chapter 8 will price what that means in energy. Shrink to 32 bits and the space collapses to about 4.3 billion keys — and Chapter 6 already priced that space: full enumeration in about 72 minutes at a million tries a second, before lunch. A 32-bit "key" is not a small key; it is no key. The length is not for your memory — the seed phrase of Chapter 11 handles memory — it is for the thief's arithmetic: every added bit doubles his bill.

Exercise 7.6. Subtracting \(n\) would give each of the smallest \(2^{256} - n\) keys two ways to be drawn, so those keys would be twice as likely as the rest — a non-uniform draw. The bias is far too thin to exploit, but redrawing removes it completely at a cost of one extra draw in about \(2.7 \times 10^{38}\): exact uniformity for free.