Advanced techniques

BYOE: Bring Your Own Entropy

The Workshop turns coin flips, dice rolls or a shuffled deck into a wallet you can hold against your device. What it does with what you give it, what it refuses to do, and how to check it before you believe a word of it.

Intermediate About 16 minutes to read Updated Aug 27, 2026
EntropySeed generationOpen source

A wallet is one enormous secret number. The Entropy Workshop will not make that number for you — there is no random number generator anywhere in it, and that absence is the whole design. You bring the randomness in from the physical world, and the page does the arithmetic in front of you: the same arithmetic your signing device does privately, so you can hold the two side by side and see whether they agree.

This guide is about reading that tool. What each control changes, what comes out the other end, and how to check the page itself before you trust anything it tells you.

1It cannot generate anything, and that is the feature

Most "seed generator" pages you will find offer a button that produces a phrase. This one does not have that button, because it does not have anything to put behind it. There is no call to the browser’s random number generator in the conversion path at all. Every bit that ends up in a wallet came off a coin, a die or a card that you handled.

The second absence matters just as much: there is nowhere on the page to type a recovery phrase you already own. The tool converts physical events into words, and only in that direction. A page that has no field for your phrase cannot be tricked into sending your phrase somewhere, which is a stronger guarantee than any promise about what it does with the field.

A tool that cannot accept your recovery phrase cannot leak it. That is worth more than a promise not to.

2Pick the source you actually have

Step one asks what you are going to flip, roll or draw. The three sources are not interchangeable — they differ in how much each event is worth, and therefore in how long you will be sitting there.

  • Coins. One bit a flip, packed straight into the seed with nothing hashed. That makes it the only source you can check entirely by hand: heads is a 1, tails a 0, in the order you flipped them. It also makes it the longest — a 12-word seed takes exactly 128 flips, and a 24-word seed exactly 256.
  • Six-sided dice. Each roll carries log2(6) = 2.585 bits, so 50 rolls fill a 12-word seed and 99 fill a 24-word one. The rolls are hashed rather than packed, which is why the count is not a round number.
  • Octal and hex dice. One eight-sided die and two sixteen-sided dice throw 3 + 4 + 4 = 11 bits between them, which is exactly one recovery word. Nothing is hashed: the three faces name the word the way the printed dictionary does.
  • Cards. A shuffled deck, drawn without replacement, so each card is worth slightly less than the last — log2(52) = 5.70 bits for the first, then log2(51), and so on. Twenty-five cards carry enough for 12 words. Twenty-four needs fifty-eight, which is more than a deck holds: draw all 52, shuffle them back together, and draw six more. The Workshop counts it the same way — it greys out the cards already drawn, and once the deck is finished it tells you to shuffle and carry on.
Two white dice caught in mid-air above a navy felt runner on a scarred wooden table, beside a whisky glass, a brass oil lamp, a leather notebook and a scatter of coins
The part the page cannot do for you. Everything downstream is arithmetic; this is the only step that produces anything unpredictable.

Whichever you choose, the page counts events rather than characters, and refuses to count a half-entered one — a card rank with no suit yet is not a card.

3The conversion is the part that has to match your device

Here is the fact that sends most people to a tool like this in the first place: the same dice rolls produce different recovery words on different devices. Not because any of them is wrong, but because they made different reasonable choices about how to turn digits into bits.

So step two asks which convention to follow. For six-sided dice there are four:

  • Hash the rolls — SHA-256 over the digits exactly as typed. COLDCARD, SeedSigner and Krux.
  • Hash, with 6 as 0 — the same, after rewriting every 6 as a 0 first. Keystone and the BIP39 HTML tool.
  • The bit table — each face contributes one or two bits, so no fixed number of rolls fills a seed.
  • The BitBox lookup — five four-sided dice and a coin name a word outright, with nothing hashed.

Cards have three: hash a compact ASCII transcript, hash the Ian Coleman tool’s spaced suit-symbol transcript, or use that tool’s variable-length card codes. Coins have one, because there is only one sensible thing to do with a bit.

If the words disagree with your device

Change the conversion before you conclude anything. A mismatch between this page and your hardware is far more likely to be two different conventions than a dishonest device — and the page names which devices use which convention precisely so that you can check that first.

4The last word, and when you get to choose it

A recovery phrase is not purely random. In a 12-word phrase, the first 11 words and part of the twelfth carry 128 bits of entropy, and the last four bits of the final word are a checksum computed from everything before them. In a 24-word phrase it is 256 bits and eight checksum bits. That is what makes a mistyped phrase detectable rather than silently wrong.

The tool always shows you whether the checksum holds, and it will open up and explain what the last word is made of if you ask it to. Where the interesting difference lies is whether you get a say in that last word:

  • Hashing methods leave you no choice. Hashing fixes all 128 or 256 entropy bits at once, so exactly one final word fits, and the tool fills it in.
  • Lookup methods do. The octal-and-hex dictionary gives you 11 words from 11 throws, which is 121 bits — seven short of 128. Those seven unrolled bits are yours to pick, which means 128 valid endings to choose from at 12 words, and eight at 24. The checksum itself is never a choice; it is computed either way.

5What comes out

Pressing the button gives you rather more than a phrase, because a phrase on its own is hard to check against anything:

  • The recovery words, numbered, with the checksum verdict beneath them.
  • The account private key — the half that spends, shown openly beneath the words because the words are the more powerful secret and are already on screen. Where the address type has a SLIP-132 prefix, its twin is shown beside it, so a wallet displaying one and a device displaying the other do not look like a disagreement.
  • The account public key, which is what a watch-only wallet means when it asks for your xpub.
  • A watch-only descriptor, written the way a wallet wants to be handed one — script type named so it cannot be imported as the wrong address type, receiving and change covered together, and eight characters of checksum after the hash so a wallet can tell you that you mistyped rather than silently watching the wrong account.
  • The first addresses on both the receiving and change branches, which is usually the fastest thing to compare against a device screen.

The address type you pick changes the derivation path underneath all of it: legacy sits at m/44’/0’/0’, nested SegWit at m/49’/0’/0’, native SegWit at m/84’/0’/0’, and taproot at m/86’/0’/0’. Restoring the right words down the wrong path is the single most common reason a correctly restored wallet looks empty.

6The meter, and why more rolls stop helping

As you enter events the page tracks how many bits they carry against how many the seed can hold. It is worth watching once, because the arithmetic is not intuitive: ninety-nine rolls of a six-sided die come to 255.9 bits, just under the 256 a 24-word seed holds, which is exactly why those rolls are hashed rather than packed in.

Keep rolling past the target and the count keeps climbing, because the count is honest about the source. What it will also tell you is that the extra lands nowhere: a seed holds what it holds, and everything above that is hashed down into the same number of bits. More rolls past the line change which wallet you get. They do not make it harder to guess.

7It checks itself, and it checks you

Three separate guards run, and it is worth knowing what each one does and does not mean.

It tests itself on load. The page carries published test vectors and runs them before it will show you anything. If any of them fail, it refuses to render results at all, because a conversion tool that is quietly wrong is worse than no tool.

It refuses obviously typed input. Ninety-nine 1s, a walk up and down the faces, a neat repeating block — these get turned away. Cards get stricter treatment still, because a deck has rules: a rank must be followed by a suit, and one deck cannot deal the same card twice, so an impossible transcript is refused rather than quietly hashed.

Neither of those is a randomness test. Passing the fabrication check means "nothing here is obviously fabricated". It does not mean the dice were fair, that you shuffled properly, or that the result is good randomness. No page can tell you that from the digits alone.

  • A passing fabrication check is not a verdict on your dice or your shuffle.
  • The tool cannot detect a loaded die, a sticky coin, or a deck that was not really shuffled.
  • If you find yourself re-rolling because a sequence looks wrong, stop — that instinct is the bias the entropy guides describe, and it makes the result worse rather than better.

8Check the file before you trust it

The whole tool is one self-contained HTML file. It embeds its own fonts, styles, script and wordlist, carries a restrictive content-security policy, and makes no automatic network request of any kind. That is what makes it possible to carry it to a machine that has never been online.

Its SHA-256 is published beside it, and the page shows you how to check it:

  • certutil -hashfile entropy-offline.html SHA256 on Windows
  • shasum -a 256 entropy-offline.html on macOS or Linux

Be clear about what that proves. It proves the file arrived intact — a truncated download, a proxy that rewrote something, a bad USB stick all change the hash and you will see it. It does not prove the file is genuine, because the checksum is served from the same place as the file it describes. Anyone able to replace one could replace the other. Same-origin checksums catch accidents, not adversaries. If a result is going to change what you believe about a wallet, compare a copy fetched over a different network or taken from the repository’s history, and read the file — it is one unminified document, specifically so that reading it is possible.

9Where to run it, and the limit it will not pretend past

Download it, check the hash, and open it from disk on a machine with no network. The page will tell you which copy you are running and how it was loaded, and it is careful about the wording, because there is a thing it genuinely cannot know.

It cannot tell whether your machine is offline. From inside a browser, a local file on a fully connected laptop is indistinguishable from the same file on an air-gapped one. No badge on any page is proof of an air gap — only how you set the machine up is.

What this tool is for

It is experimental, and it is for testing. Do not rely on it to secure real bitcoin, and never test with funds you cannot afford to lose. Use it to check that a device produced what it should have, with a sequence you are content to throw away — not to manufacture the wallet you are going to live on.

This is the instrument, not the procedure

Worth being plain about where this page sits. Everything above describes a tool for checking work — it is not the method, and it is not the part that keeps bitcoin safe. The full dice procedure lives in one guide and the rules that outrank all of this live in another, and if you only read one more thing, read those rather than coming back here.

Roll the dice: the full procedure, and the rules people break

Intro to Self Custody: back it up and prove you can recover it

Why you cannot think of a random number

Conversions follow BIP32, BIP39, BIP44/49/84/86 and SLIP-132; the descriptor follows BIP380 with the multipath notation of BIP389 . Device conventions are taken from each vendor’s own documentation and reproduced as published test vectors.

Do not guess

Stuck on a step?

If the screen in front of you does not match the guide, stop. Review the related walkthroughs or get a second set of eyes before exposing recovery words or approving a transaction.