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. Finding yours by guessing means picking one marked atom out of about 1.6 billion galaxies the size of the Milky Way. The observable universe holds an estimated 1080 atoms, so it has roughly 860 atoms to spare for every private key that could ever exist.
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 09 explains why 24 words does not give you twice the on-chain security you might expect.
Yes — but almost never where people think, and the honest answer depends entirely on what the attacker already has.
The passphrase isn't mixed into the word list. It's a separate secret used at a later stage, when the words are stretched into the actual wallet seed:
The consequence is unusual and worth internalising: every passphrase produces a different, perfectly valid wallet. There is no "incorrect passphrase" error, because there is nothing to check against. Type one character wrong and you land in an empty wallet that looks exactly as legitimate as the real one.
| Situation | What is actually protecting you | Effective entropy |
|---|---|---|
| Words secret, no passphrase | The seed itself | 128 bits already the curve's ceiling |
| Words secret, passphrase set | The seed — the passphrase is spare capacity | 128 bits no practical gain; see below |
| Words exposed, no passphrase | Nothing at all | 0 bits funds gone the moment they're read |
| Words exposed, passphrase set | The passphrase, alone | exactly its own entropy and you chose it, so probably 25–50 bits |
So a passphrase does not make a strong seed stronger. Your seed already carries 128 bits and section 09 shows the curve caps you near there anyway — stacking another 40 bits on top of an unbreakable secret buys nothing. What it does is create a second, independent secret, so that losing the first one isn't fatal. That is a completely different kind of protection, and a valuable one: it is what limited the damage for Coldcard owners whose words were generated weakly.
This is the number that matters, and it is smaller than people assume. The KDF helps — 2048 rounds of PBKDF2 turn a fast hash rate into a much slower guess rate, worth about 11 bits — but it cannot rescue a passphrase you invented.
Rates are candidate passphrases per second, with the cost of the 2048-round KDF already priced in — that is why even a large farm manages far fewer guesses per second than raw hashing would suggest.
Generate the passphrase the same way you'd generate a seed — from dice or a machine, not your imagination. Five or more random words gets you past any realistic offline attack on leaked words.
There is no recovery. The passphrase is never stored, never checked, never hinted. Forget it and the coins are as lost as if you'd burned the words. More people have lost funds to forgotten passphrases than have been saved by them.
A related trick: because every passphrase yields a valid wallet, you can fund the passphrase-free wallet with a small decoy balance. Someone who finds only your words sees a real, plausible, modestly-funded wallet — and no indication that anything else exists.
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 08 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.
Your seed can hold 256 bits, but a signature on the blockchain is what decides how much of it matters. Until you spend, your key hides behind a hash. The signature is what tears that layer away — and it never comes back for that address.
| Layer | Cost to break | When it applies |
|---|---|---|
| Guess the seed directly | 2128 / 2256 | Always. Never the cheapest path. |
| Grind keys against a single-sig address hash HASH160 is 160 bits wide | ≈2160 | Only while the public key is hidden |
| Find a preimage of a multisig script hash P2WSH commits to a 256-bit SHA-256 | ≈2256 | Only while the script is hidden |
| Solve the curve from a revealed public key Pollard's rho on secp256k1, per key | ≈2128 | The moment a public key is visible |
| Shor's algorithm on a revealed public key | polynomial | Quantum only, public key visible |
1. Spending is a one-way reveal. An unspent single-sig output shows the world only HASH160(pubkey). To attack it you must grind private keys, derive each public key, hash it and hope for a match — about 2160 attempts. Sign one transaction and the public key enters the witness data permanently, and the attack becomes 2128 on the curve. That address never recovers its hash layer. Reuse it and you are simply living at 128 bits.
2. If you don't reuse addresses, multisig really is stronger. This is the part that gets flattened in most explanations. A 2-of-3 P2WSH output commits to a 256-bit SHA-256 of the whole witness script, not a 160-bit hash of one key. An attacker can't grind toward it the way they can with single-sig, because they'd have to guess three public keys at once. While it stays unspent, the practical bound is a 2256 preimage rather than 2160. Modern wallets generate a fresh address for every receive, so for the coins sitting in your wallet right now, multisig is meaningfully harder to attack — not one bit harder, dramatically harder.
3. That advantage is spent along with the coins. The moment you sign, the script and all its public keys go on-chain, and everything converges: 2 × 2128 = 2129 for 2-of-3. So multisig's brute-force edge is large before you spend and one bit afterwards. Both statements are true; they just describe different moments. And the enduring reason to run multisig was never the arithmetic — it's redundancy: surviving the loss, theft, or coercion of a single key. Section 08 showed the caveat that matters most, which is that the keys must not share a failure mode.
4. Taproot is always "spent." A P2TR output is a public key, in plain sight from the moment it's created — no hash layer, single-sig or multisig, ever. That's a deliberate trade for smaller, more private, more flexible transactions, and 128 bits remains far beyond any classical attacker. It only changes the quantum conversation.
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 preparation is behavioural rather than technical — don't reuse addresses, and treat coins sitting at addresses with already-exposed public keys as the first thing you would 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 09, 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 09, 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.