To those who dismissed the ColdCard fiasco as a result of the code merely being 'source-available' and not fully 'open-source', let this serve as a reminder that ultimately there is no distinction as long as no one is bothering to audit the code either way. View quoted note →

View quoted note → CORRECTION: View quoted note →

🤔View quoted note →

HOW TO BE YOUR OWN BANK: Step 1: Do your own due diligence. Get a really good safe. This step is not simple. There is a bottomless pit of things to consider. And ultimately, there is no perfect safe. Step 2: Do your own due diligence. Don't be satisfied with using a combination that the safe manufacturer provides you. Instead, generate your own combination that you can verify by yourself has in fact been generated as randomly as can reasonably be achieved. This step is very simple. So simple it's not even worth considering skipping. In fact, it should be viewed as borderline malpractice for safe manufactures to be offering to choose a combination for you in the first place.

A GUIDE FOR MANUALLY GENERATING A SEED PHRASE OFFLINE, OFF-DEVICE FROM COIN FLIPS (no conversion from binary to decimal required): *assistance from some form of hardware will be necessary for checksum calculation (see opening note of the Instructions): Instructions:

Google Docs

Coin Flip Instructions 0.2.pdf

Small print (more compact) version: Worksheet:

Google Docs

Coin Flip Worksheet - for small print table.pdf

Lookup Table:

Google Docs

Coin Flip Lookup Table - small print 0.2.pdf

Larger print version (for those of us with less than supernatural vision): Worksheet:

Google Docs

Coin Flip Worksheet - for larger print table.pdf

Lookup Table

Google Docs

Coin Flip Lookup Table - larger print 0.2.pdf

I'm sure this video is making the rounds (which I assume is why YouTube put it in my recommendations). Regardless, fascinating re-watching of this blast from the past. Andreas is the GOAT!, but some of this didn't age so well... most notably, specifically identifying ColdCard as his favorite due to its efforts to remove reliance on trust in the manufacturer. He also expresses a commonly held assumption that has been proven false that we should feel comfortable with hardware wallet seed generation more generally due to heavy scrutiny by experts... *though, he does caveat that perfect trust isn't possible. Regardless, he does come to the correct ultimate conclusion (IMO): in cases where it's really important to not be relying on trust, you really should be generating your own seed offline with cards, dice, etc. (PS. IMO, there are vanishingly few use-cases where it's not really important to not be relying on trust).

You may not be able to *fully* trust a seed generated from the entropy by rolling dice. You may not be able to fully trust (or at all) the seed supposedly generated by the RNG of a hardware device. The cool thing is you can benefit from the entropy of both by combining them with a simple XOR. In fact, you can XOR as many seeds together as you want and benefit from the entropy that each provides - verifiably by hand reasonably simply. For example, even if unbeknownst to you, the ColdCard RNG were to provide zero entropy (i.e. if it were to produce the same seed every single time), by XORing it with a seed you manually generate with dice, you would still at least be benefiting from the dice entropy. PS. ColdCard did provide the option to combine RNG with dice rolls... but there was no way to verify it actually combined anything (AFAIK). It also provided an option for seed generation by dice rolls alone. This was verifiable; but, the verification process required you to expose seed material to another device... which I kind of thought was what a hardware wallet was supposed to allow you to avoid.

Can someone who knows please enlighten me (a non-expert)? Are there any mission-critical basic functions of a cold storage signing device that absolutely require the use of RNG? A signing nonce comes to mind; but, it's my understanding that deriving it deterministically with a hash of the transaction content (or something along those lines) instead of using an RNG is now considered best practice. Is this correct? Are there any other absolutely necessary reasons for a signing device to use RNG. If not, since seed generation could instead be achieved reasonably safely, and *verifiably* with dice or coins, etc, doesn't that necessarily mean that signing devices that even offer an inherently unverifiable RNG seed generation option are subjecting unsuspecting users to an unnecessary risk?

View quoted note → View quoted note →

Hello Friends! All of the entropy generation talk has inspired me to put together what I hope is a useful aid for generating seed words from coin flips. I suspect something similar already exists; but, I wanted to make my own exactly as I wanted it; and I thought I'd share it. If you think you might be interested in doing this, but it's not exactly clear to you what this process entails, I highly recommend reading the note at the start of the instructions section before going any further. It may easily turn out that this process is not for you. If you already know what you're getting into, I hope to have made the rest of it intuitive enough so that you should be fine to skip the instructions. Instructions:

Google Docs

Coin Flip Instructions.pdf

Small print (more compact) version: Worksheet:

Google Docs

Coin Flip Worksheet - for small print table.pdf

Lookup Table:

Google Docs

Coin Flip Lookup Table - small print.pdf

Larger print version (for those of us with less than supernatural vision): Worksheet:

Google Docs

Coin Flip Worksheet - for larger print table.pdf

Lookup Table

Google Docs

Coin Flip Lookup Table - larger print.pdf

If you find this aid useful or know someone you think might, feel free to share, download, improve, or do whatever else you want to with it.

Taking responsibility vs convenience... and knowing the trade-offs. IMO, this is supposed to be the ethos of Bitcoin. It seems it should be clear now that the Bitcoin community in general has been too eager to abstract away responsibility to the user for the sake offering convenience in order to recruit new adoption more quickly - without sufficient emphasis on the trade-offs. This needs to change. It's laudable to provide a mechanism for making it more convenient for a user to take responsibility; but that's completely different from abstracting a responsibility away altogether. At the very least, maintain a reasonably useful path for a user to choose to retain that responsibility. View quoted note →