The guess is just very, very unlikely. How unlikely depends entirely on one thing: the quality of the randomness used to make your key.
Forget the physics. In security, entropy measures how many things an attacker would have to try. One coin flip = 2 possibilities = 1 bit. Every bit you add doubles the pile.
Physical randomness is verifiable — you can watch it happen. That is the entire argument for dice. 99 rolls of a fair six-sided die gives 255.9 bits, which is why hardware wallets that support dice ask for exactly 99.
Bits are deceptive. 256 is only twice 128, but the number of possibilities is the 128-bit number squared. Drag to feel it.
A private key is a random number below about 1.158 × 1077. The observable universe holds an estimated 1080 atoms — so there are roughly 860 atoms in the universe for every private key that could ever exist. Finding yours by guessing means picking one marked atom out of about 890 septillion Earths.
Pick an attacker. Pick a key size. The answer stops being a number and starts being a geological era very quickly.
These rates are deliberately generous to the attacker. The "whole Bitcoin network" row pretends every mining ASIC on Earth could check a full elliptic-curve key as cheaply as it computes one SHA-256 hash. It can't — real key-checking is thousands of times slower. Even with that fantasy, 128 bits holds for billions of years. Network hashrate ≈ 920 EH/s (Aug 2026).
That's it. There's no vault, no password database, no server. Your key is a number, and math turns it into an address in one direction only.
Every arrow going right takes microseconds. Every arrow going left takes longer than the universe has existed. The math is not the weak point. The weak point is whether those first 256 bits were actually random.
A seed phrase isn't a password protecting a key. It is the key, re-encoded so a human can copy it onto paper without typos. This generator runs in your browser and produces genuinely valid BIP39 phrases.
Never use a phrase generated on a web page for real funds, including this one. It exists to show the mechanism.
132 bits stored: 128 entropy + 4 checksum.
264 bits stored: 256 entropy + 8 checksum.
Both are beyond brute force. Section 08 explains why 24 words does not give you twice the on-chain security you might expect.
Computers are deterministic machines. They are, by design, bad at being unpredictable. So they have to go get unpredictability from somewhere physical.
A wall of ~100 lava lamps in a San Francisco lobby, filmed continuously. The camera feed — blobs, shadows, people walking past, sensor noise — is hashed into an entropy pool. It's real, it's charming, and it is one input among several, not the sole source. Cloudflare runs similar rigs elsewhere using a double pendulum and a radioactive source.
The gold standard for the paranoid, because it's the only method you can fully audit with your own eyes. 99 rolls of a d6 = 255.9 bits. Casino-grade dice matter here; cheap dice are measurably biased.
52! orderings = 225.6 bits. Enough for a 128-bit key with room to spare, not quite enough for a full 256. Requires a genuinely thorough shuffle — seven riffles minimum.
Thermal noise across a resistor, avalanche noise in a diode, clock jitter, radioactive decay. Excellent physics — but you are trusting that the chip was actually wired up and actually called. In July 2026 a Coldcard build silently bypassed its hardware RNG for five years. Section 07 has the details.
/dev/urandom, getrandom(), CryptGenRandom. These are software CSPRNGs seeded from hardware events: interrupt timing, keystrokes, disk latency, the CPU's own RDSEED. Excellent once properly seeded. The historic failures were all seeding failures, not algorithm failures.
Humans are terrible entropy sources and confidently believe otherwise. A "random" sentence you invent carries maybe 20–40 bits. A memorable one carries far less. This is the single most reliable way people have lost bitcoin.
Watch for the seeding trap: a freshly booted virtual machine or container has almost no entropy in its pool yet. Keys generated in the first moments of a VM's life have been predictable in real incidents. Any server-side key generation should block until the kernel pool is properly seeded.
Type anything. The estimate is rough but the lesson isn't: human-chosen inputs land in the red zone, and attackers have pre-computed every phrase anyone has ever thought was clever.
"Brain wallets" hashed a memorised phrase straight into a private key. Researchers who scanned the blockchain found tens of thousands of them, drained within seconds of first funding by bots watching for exactly this. The phrases came from song lyrics, scripture, movie quotes, and famous passwords. Every one of them was already in a list.
Bad entropy is not only a user problem. The most expensive entropy failure in Bitcoin's history happened on a dedicated, well-regarded, security-focused hardware wallet — to users who did everything they were told.
In March 2021 a build-configuration mistake quietly redirected seed generation away from the STM32 hardware random number generator and into a software fallback. Coldcard's config sets MICROPY_HW_ENABLE_RNG to zero because Coinkite supplies its own hardware-RNG wrapper. A library checked whether that macro existed rather than whether it was enabled — so the build silently bound to MicroPython's Yasmarang PRNG, seeded from the chip's unique ID and timer registers, collecting no fresh entropy afterwards.
Coinkite estimates the effective entropy at roughly 40 bits on the Mk3 and 72 bits on the Mk4, Mk5 and Q — against the 128 bits a 12-word seed is supposed to carry. Go back to section 03 and set the slider to 72 with a GPU rig selected. That is the whole story.
On 30 July 2026 an attacker drained 1,196 addresses in 41 minutes. Galaxy Research has since traced further waves totalling 1,367 BTC across 4,585 addresses. Patched firmware shipped the next day, but a firmware update cannot repair a seed that was already generated weakly — affected users have to generate a new seed and move their coins.
Coinkite states that a seed built from at least 50 fair, independent, private dice rolls is not at risk from this bug alone. A strong BIP39 passphrase also creates a separate wallet the weak words cannot reach on their own.
Multisig helped only where the quorum was not built entirely from affected devices. Three Coldcards in a 2-of-3 is one failure mode wearing three hats. Diversity of implementation is the point, not the number of keys.
The same month, separate research ("Ill Bloom") found another weak-PRNG flaw in older software wallets, tied to more than $5M drained across several chains. These are not freak events. Entropy generation is the part of the stack least visible to users and least often independently tested.
This is the part almost nobody explains. Your seed can hold 256 bits, but the curve Bitcoin uses caps practical key security at about 128 bits — and the first time you spend, you give up the one layer that was doing better than that.
| Layer | Cost to break | When it applies |
|---|---|---|
| Guess the seed directly | 2128 / 2256 | Always. Never the cheapest path. |
| Find a key matching an address hash | ≈2160 | Only while the public key is still hidden |
| Solve the curve from a public key (Pollard's rho on secp256k1) | ≈2128 | The moment the public key is visible |
| Shor's algorithm on a public key | polynomial | Quantum only, public key visible |
1. Spending is a reveal. An unspent legacy or SegWit address shows the world only HASH160(pubkey) — 160 bits of hash standing in front of your key. Sign one transaction and the public key goes into the witness data forever. Your protection drops from ~160 bits to ~128. Reusing that address afterwards means it stays at 128.
2. Multisig adds one bit, not double. An attacker breaking 2-of-3 doesn't face 2128 × 2128. They attack each key independently and only need two: 2 × 2128 = 2129. One extra bit of brute-force resistance. Multisig is not an entropy multiplier — it's a redundancy and trust-distribution tool, and that's a completely valid reason to use it. It removes the single point of failure for theft, loss, coercion, and your own mistakes. Just don't buy it expecting more randomness.
3. Taproot is always "spent." A P2TR output is a public key, sitting in plain sight from the moment it's created. No hash layer, ever. That's a deliberate trade for smaller, more private transactions, and 128 bits is still far beyond any classical attacker. It only matters in the quantum discussion.
Practical note on quantum: no machine capable of this exists today, and estimates for one that could break secp256k1 range from years to decades. The relevant preparation is behavioural — avoid address reuse, and treat coins sitting at addresses with exposed public keys as the first thing you'd migrate.
Lightning uses the same curve, the same key sizes and the same 128-bit floor as everything above. A Lightning channel is not a weaker kind of Bitcoin key. Here is that claim measured against the benchmarks you've already been using.
Read the middle two rows together. A Lightning channel is marginally harder to brute-force than a cold-storage wallet you have already spent from — 2 × 2128 versus 2128, because the attacker needs both channel keys instead of one. If you are comfortable with a 12-word cold wallet that has sent a transaction, the arithmetic on Lightning is not what should worry you.
What Lightning gives up is the hash layer, not key strength. An unspent on-chain address hides behind 160 bits of hash. A publicly announced channel gossips both funding public keys in channel_announcement so routing nodes can verify the channel is bound to a real UTXO. That moves you from ~160 bits to ~129 — the same trade you make the first time you spend from any address, and 129 bits is still billions of years.
Four things, in the order they should concern you. None of them is the key size.
A routing node signs constantly and unattended, so key material lives in memory on an internet-connected machine. This is availability, not strength: the key is exactly as unguessable as a cold key, but there is now a running process that can be attacked. Every serious Lightning loss has come from host compromise, not cryptography. Harden the machine, and size the hot balance to what you would accept losing.
This is the difference that genuinely has no on-chain equivalent, and it catches people. With a normal wallet, the seed is sufficient — it recovers everything, forever. On Lightning the seed recovers your on-chain funds but not your channels, because channel balances live in state that changes with every payment.
Worse, restoring a stale copy of that state is actively dangerous: broadcasting an old channel state looks identical to attempted theft, and your counterparty can take the whole channel balance via the penalty mechanism. This is why static channel backups exist — they let you ask peers to force-close so you can sweep your side, rather than replaying old state. Never restore an old node database and start it up. Back up the seed and keep channel backups current.
LND uses aezeed, not BIP39. It is 24 words, but the plaintext is 1 byte of version, 2 bytes of wallet birthday and 16 bytes of entropy — 128 bits, the same as twelve BIP39 words. The extra length is metadata and a MAC, not extra randomness. Given section 08, that costs you nothing: 128 bits was already the ceiling.
One genuine advantage over BIP39: the words are ciphertext, enciphered with AEZ under a key derived from your passphrase. With a passphrase set, someone who photographs your backup cannot spend from it. The trade-off is that aezeed words will not restore into a BIP39 wallet. Core Lightning uses a 32-byte hsm_secret; LDK uses a 32-byte seed.
Channel funds sit in a 2-of-2 output with your counterparty. As in section 08, that adds one bit rather than doubling anything. Its purpose is enforcement — it makes the channel a mutually-signed agreement neither side can unilaterally rewrite — not extra randomness. Do not count it toward your security margin, and do not discount it either: it is what makes the whole thing trust-minimised.
Bottom line: the entropy question on Lightning is identical to the one everywhere else, and the answer is just as strong. Generate the seed well, verify it if you can, keep channel backups current, and right-size the hot balance. The cryptography is not the part that needs your attention.
"Buy a reputable hardware wallet" was the standard advice for a decade. Coldcard was reputable, Bitcoin-only, and security-focused, and it shipped predictable seeds for five years. Reputation is not a security property. Here is the version that survives that fact.