I created a straightforward dice-to-seed-phrase worksheet. I had a (non bitcoin savvy) friend check it out, and fixed a few UI issues that came up from that.
I, along with a lot of others, will be upping my security in the near future with dice. No more trust in entropy from hardware wallets!
I'd love to get some feedback on it, in terms of:
- is it easy to follow?
- any holes in the logic?
Here's the first page. The instructions and worksheet are at the end.
Do you imagine Satoshi telling you to dice to generate a wallet?
Don't be stupid.
Coldcard failed because it was an inside job, and probably a psyop. Not because of something the user didn't do well.
I agree with this, and look at at many areas in Bitcoin that people don't understand but they use it, on good faith I assume, which is a terrible security flaw
Just look at the constant admonishment Darth delivers daily, he must get tired of saying the same things over and over lol
I will just make fun and memes and go back to my mountains...
What advice do you think Satoshi would give, for generating a wallet?
Just use a proper random number generator, like the one used in all but Coldcards. Because coldcards are bad it doesn't mean all the other ones are too.
I don't trust any HW anyway, and any other non FOSS program btw.
Just went through some dice methods for my own article. I decided to use binary but thought BitBox's lookup-table approach was a neat alternative.
Yours entropy looks sound.
Well put together. You can just do things.
Thanks. Let us know when your article is written!
I would still be personally worried about bias from dice (but I may be biased hahaha).
To avoid that, I would not buy used dice or someone else's dice. There are people who put it into ovens to cheat on Dungeons and Dragons (https://www.reddit.com/r/statistics/comments/3246r7/where_to_buy_loaded_dice_for_teaching/).
I would still be paranoid about dice so I would buy those advertised for casinos. And even then I would still be worried so I would use the idea of Ava Chow I saw on Nitter to use the von Neumann skew-correction algorithm or a variant. And I would do my own research about the different algorithms used, although the one you shared seems perfectly fine.
Everything written above could be overthinking. Also factually people who used dice with the coldcard were safe. So factually those who used dices were proven right to do so. However I would still keep diluting risk by using multisig because this is where I feel confident and have put thought and effort into.
At the end of the day, the diversity of ideas to secure bitcoins is interesting to see and I learned something new from the way Bitkey does it. Although I didn't like the aggressive marketing they did and I would not use it myself. For those who prefer dice, I think they should go for it.
If you do a little searching you'll find a method of testing dice for randomness. It involves letting them float in water, or something similar. Check it out...
Thank you, I will take a look.
Trying to find what could possibly go wrong I was wondering also if the assumption of independence of events is still valid if two dice collide. So I would toss the dice one after the other just in case, as the math behind assume rolls are independent events.
If you look at lottery events they probably use a machine to roll dice to guarantee independence of events. I don't want to be too paranoid there too and discourage you though.
I should have said this in the first post, but the idea for doing the dice rolls like this came from a post on the SeedSigner telegram group (which, btw, is outstanding).
Somebody uploaded a pdf called diceseed.pdf (originally from https://en.bitcoin.se/diceseed, but looks like the site has changed). I thought it was very promising, but majorly flawed. So I and came up with this idea, which I believe makes the whole process of entropy generation VERY understandable.
You all were talking about dice rolls - thoughts?
@john_doe
@kepford
@Undisciplined
@SimpleStacker
@siggy47
@optimism
@CruncherDefi
@billytheked
@0xbitcoiner
@ACYK
I like it. It does make the actual mapping more intuitive.
It's basically doing 4 dice rolls and 1 "coin toss" (using 1-2-3 and 4-5-6 from the dice to give 50/50 odds). That's why there has to be some blanks.
From the Notes section, on the Instructions page
Why are there blank ROLL AGAIN areas? Every single word needs to have the same chance of getting picked. The 5 rolls lead to 2592 different possible combinations (roll 5 only picks left or right), more than the 2048 words. So 544 places are blank.
The one I originally looked at (diceseed) did the "coin toss" at the beginning. This gives you fewer pages to look at, but to me it also made the whole thing kind of muddled and confusing.
There is a real logic gap in Step 4. The final word is not only a checksum calculated from the earlier words.
For a 12-word BIP-39 phrase, words 1–11 provide 121 entropy bits. Word 12 contains 7 more entropy bits + 4 checksum bits, so the first 11 words admit 128 different valid final words. For 24 words, word 24 contains 3 entropy bits + 8 checksum bits, leaving 8 valid final words after words 1–23.
That matters to the guide’s central claim that the entropy comes from dice alone. If the hardware wallet/tool chooses a valid last word randomly, part of the entropy comes from that tool’s RNG. If it always chooses one deterministically, the phrase has 121/253 dice-derived bits rather than the intended 128/256.
I would change the worksheet so the user also generates the remaining 7 bits (12 words) or 3 bits (24 words) with an unbiased dice-to-bit step, then uses the offline tool only to append/verify the checksum. A tiny diagram — 121 dice bits | 7 dice bits | 4 checksum bits — would make this click immediately.
The rejection layout for selecting the first 11/23 words looks clear and unbiased; this final-word step is the one substantive hole I see. I’d also add a final wipe/restore + matching receive-address check before meaningful funds.
Canonical bit-length table: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki