Decentralized on Nostr: An unpopular opinion, offered as exactly that, a personal one. A lot of people are ...
An unpopular opinion, offered as exactly that, a personal one.
A lot of people are saying this week that multisig is the answer.
Let me concede the strongest version of that argument up front: multisig across different manufacturers would have protected every single person affected by this. That's true, and it matters.
But here's what I keep coming back to.
Multisig doesn't remove a single point of failure. It trades one for another.
Lose your descriptor, the file holding every participant's xpub, the script type, the derivation paths, and your funds are gone even if all three seeds are sitting safely in your hands.
Two of three seeds without a descriptor is not a recoverable wallet.
Most people who set up multisig back up their keys religiously and their descriptor nowhere.
So the honest question isn't "is multisig more secure?"
It's "more secure for whom, set up by whom, recoverable by whom in five years?"
For someone who has never done a full recovery, a well-generated seed with a strong passphrase, backed up in metal, split across locations, beats a multisig they don't fully understand.
Not because multisig is worse, because a setup you can't operate isn't a setup, it's a liability with extra steps.
And if you're going to use a passphrase: back it up physically, separately from the seed. Never rely on memory.
A typo produces a valid, empty wallet, not an error message.
The real lesson from this week isn't multisig. It's independent failure domains. Don't let one manufacturer's mistake reach all your keys. Dice-generated entropy does that.
A passphrase does that. Multisig across vendors does that. Pick the one you can actually execute.
Start at kilometre zero. Nobody walked a thousand in a second.
Published at
2026-07-31 21:42:07 UTCEvent JSON
{
"id": "6f90089db389d1a4aaf1cf547207be4a4a99d6afdf54feaf877705f64bd4d98d",
"pubkey": "00000000abb6793b6b7da89bf42eb9e659e0d31aac9bb0fa34a99e268e708f47",
"created_at": 1785534127,
"kind": 1,
"tags": [
[
"client",
"Yakihonne",
"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
]
],
"content": "An unpopular opinion, offered as exactly that, a personal one.\nA lot of people are saying this week that multisig is the answer.\n\nLet me concede the strongest version of that argument up front: multisig across different manufacturers would have protected every single person affected by this. That's true, and it matters.\n\nBut here's what I keep coming back to.\nMultisig doesn't remove a single point of failure. It trades one for another.\nLose your descriptor, the file holding every participant's xpub, the script type, the derivation paths, and your funds are gone even if all three seeds are sitting safely in your hands.\nTwo of three seeds without a descriptor is not a recoverable wallet.\nMost people who set up multisig back up their keys religiously and their descriptor nowhere.\nSo the honest question isn't \"is multisig more secure?\"\nIt's \"more secure for whom, set up by whom, recoverable by whom in five years?\"\nFor someone who has never done a full recovery, a well-generated seed with a strong passphrase, backed up in metal, split across locations, beats a multisig they don't fully understand. \nNot because multisig is worse, because a setup you can't operate isn't a setup, it's a liability with extra steps.\nAnd if you're going to use a passphrase: back it up physically, separately from the seed. Never rely on memory.\nA typo produces a valid, empty wallet, not an error message.\n\nThe real lesson from this week isn't multisig. It's independent failure domains. Don't let one manufacturer's mistake reach all your keys. Dice-generated entropy does that. \nA passphrase does that. Multisig across vendors does that. Pick the one you can actually execute.\n\nStart at kilometre zero. Nobody walked a thousand in a second.",
"sig": "378c3e5bafbab112d3919e4ded3f7e77d5f0ca21db29c37f720ae05abfeb9d06e18f39d0b262d066bad5fe10a05f6d6770b81b3058c967348bee84eca6c960eb"
}