I built a 2-of-3 multisig vault without buying anything from anyone. Three seeds generated from dice rolls, on a machine that never touches the internet, with software I verified myself. Then I tested the whole thing on mainnet: deposit, cold sign with two keys, broadcast, confirmed.

I wrote down every step. But the part worth posting here isn't the procedure. It's the three errors I found in the guides I was following, because two of them fail silently.

1. A GPG fingerprint that circulates everywhere is wrong

Several guides tell you to import the Tails signing key with fingerprint 4FDE1D06…C9CD2979.

That value is an expired and revoked signing subkey, not the primary key. Some keyservers resolve it to the parent key, so the command appears to work. But from keys.openpgp.org it arrives without a User ID. And without a User ID, gpg never prints Good signature from "Tails developers", which is the exact line those same guides tell you to look for.

So you end up with a verification step that cannot produce the output it promises, and no criterion for aborting. On a step whose entire purpose is deciding whether to trust the OS you'll generate keys on.

The primary key is A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F, and it should come from tails.net/tails-signing.key over HTTPS, not from a keyserver.

2. "99 dice rolls = 256 bits" is false in practice

The arithmetic is right: log2(6) ≈ 2.585 bits per roll, × 99 ≈ 256.

But the tool doesn't credit you theory. It measures the actual distribution of your rolls and discounts entropy when they come out uneven. In my run, 100 rolls showed 163 bits credited, not 256. It took me around 140 rolls to reach 256 real bits.

This one is nasty because the failure is invisible. If you stop at 99 because a guide told you to, the tool still hands you 24 perfectly valid words. The wallet works. You just have less entropy than you think, and nothing on screen ever tells you.

The correct rule is: roll until the counter reads 256 real bits, not until you hit a fixed number of rolls. And if the counter stalls and stops climbing, your die is biased. That's the diagnostic.

3. The recovery drill asks you to do something impossible

Multiple guides have you do a recovery rehearsal before funding: wipe the wallets, rebuild from paper, then "build a transaction and sign it to confirm it works."

You can't. The vault is empty. No UTXOs means no transaction to build: Sparrow won't even construct one. Anyone following the guide literally hits a wall at the most confidence-critical moment and has no idea whether they failed or the guide did.

What the drill can prove, and what's sufficient, is that every reconstruction path lands on the same addresses. If the descriptor rebuilds address #0 and the seeds rebuild address #0 and both match your reference, the keys are correct, and in a 2-of-3 with correct keys, any pair signs. Signing gets tested later, with real sats.

Smaller traps I hit

• Tor Browser in Tails cannot read ~/Persistent (AppArmor). Guides that tell you to open file:///home/amnesia/Persistent/seedtool.html fail. The file has to be copied to ~/Tor Browser/ and opened with Ctrl+O: typing the path fails too, because the folder name has a space.
• Sparrow ships two tar.gz files per release. sparrowwallet- is the app; sparrowserver- is a headless server. Guides say "the Linux tar.gz."
• dd reporting 800 MB/s on a USB 3.0 stick is not good news, it's a lying buffer. Verify with cmp after dropping the kernel cache, or you're comparing the file against itself in RAM.
• Building a PSBT in Sparrow needs an intermediate Finalize Transaction for Signing step before Save appears. Same on the signing side.

Why I did it this way

Not because hardware wallets are insecure. For most people they're better than the realistic alternative, and I'd still recommend one to someone setting up their first wallet.

The reason is narrower: "not your keys, not your coins" solved custodial risk, and nobody solved vendor risk.

In May 2023, Ledger announced Recover. When people objected that the device could exfiltrate the seed, the official account replied that it "is and always has been possible to write firmware that facilitates key extraction," then deleted the tweet. That wasn't a hack. It was a product decision, applied by firmware update, across millions of devices at once.

That's correlated failure: structurally the same shape as the exchange collapses we already learned from, moved one layer up. I wanted to know whether I could remove the manufacturer from my trust model entirely.

Turns out you can. It costs a die and some patience.

What's in the guide

• Dice entropy to 3 seeds, with the bias-corrected rule
• Tails offline from first boot (tools pre-downloaded and GPG-verified, so it never connects at all)
• 2-of-3 P2WSH multisig, m/48'/0'/0'/2'
• Optional Diceware passphrase, with an honest section on why it can lose you everything
• Cross-verification of every address across three independent implementations (Sparrow, Bitcoin Core deriveaddresses, and a separate multisig generator)
• Audit and hardening of the online machine
• Full spend cycle, tested on mainnet
• An appendix with the commands to re-verify every fingerprint in the guide against two independent sources, including mine

That last one matters to me. I published an earlier version with a wrong fingerprint in it. Corrected it, and the guide now tells you how to check my work rather than take it.

Guide: https://github.com/NoaSEED/bitcoin-vault-2of3

Corrections welcome, especially on the entropy and descriptor-backup sections. If something in there is wrong I'd rather hear it here than have someone find out during a recovery.