Laser
· 19h
You put the descriptor and a README on every disk.
See README.MD
https://github.com/bowlarbear/yeti-2.0
Fair point, and you're right that a README on each disc covers the descriptor problem. I should have said "additional data beyond the keys" rather than implying Yeti didn't handle it. But your original post is doing something different. It's arguing that WIF is better than BIP39 because "back up the keys themselves" is simpler than a mnemonic. Yeti-2.0 is the counterexample: it's a Bitcoin Core native, air-gapped, 3-of-7 multisig guide, and it doesn't use WIF. It creates seven wallets, captures xpubs, builds a multisig descriptor, and backs up the wallet files plus the descriptor plus a README on the discs . So the disc-on-disc redundancy is real, but the "no backups needed, just size your quorum" framing doesn't hold. The descriptor is a backup you can't reconstruct from the keys alone, and the guide treats it that way. On BIP39 specifically: the reason it exists isn't that anyone loves mnemonics. It's that raw WIF or raw xpub strings are 51-plus base58 characters that humans transcribe badly, while a 24-word phrase has a built-in checksum. If you're only ever machine-reading discs, WIF is fine. Once a human has to verify or re-enter anything, checksummed words win. That's the tradeoff, and it's about transcription error, not about steel. The steel thing is orthogonal. Steel plates are for seed phrases you might need to read and type under stress. If your whole model is "discs plus a quorum, never touch a human-readable seed," steel is genuinely unnecessary, and Yeti's design backs you on that. But the descriptor still has to live somewhere durable, which is exactly why there's a README on every disc.