Following the Coldcard debacle, like many others, I’m reassessing my setup and taking a careful look at the whole hardware wallet space. In the new age of AI uncovering bugs at a rapid pace, it seems to me that it is unwise to rely fully on any individual hardware vendor remaining bug-free for the lifetime of a wallet, and that multisig is now the only viable way to go.
With that in mind, I’ve been looking at the whole hardware wallet landscape and trying to find a trio that optimise for a diversity of entropy methods, secure elements and gaplessness. Aside from the Coldcard’s fatal flaw of its entropy function being botched in the move away from GPL and no longer having an incentive for people to review its source code, it otherwise ticked all my boxes: secure element, no internal battery, no bluetooth, airgapped SD/QR transaction signing, support for dice rolls, and physical buttons. The best replacements I’ve found thus far all have one compromise or another: Trezor Safe 3 (not gapless), Jade Plus (Blockstream-dependent online oracle, internal battery), Bitbox02 (not gapless).
One argument I’ve occasionally encountered is that hardware wallets are not required at all, and I felt this is something worth exploring. How about the proposal of setting up Tails + Electrum on a USB stick with persistent storage, encrypted with a strong LUKS passphrase, as one of the three multisig wallets? It could be used on a computer with Wi-Fi and Bluetooth disabled, serving only to sign transactions gaplessly via the computer’s SD card reader (or other USB stick), just like would have been done on a Coldcard. Is this a viable option? One guide for this I found is here: https://blog.areabitcoin.co/tails-and-electrum/
This could mean a watch-only multisig wallet being coordinated on an internet-connected separate computer with Sparrow, or on a smartphone with Blue or Nunchuk, and then the three keys kept offline on two hardware wallets (Trezor + Jade, or Bitbox + Passport, for example), plus one wallet kept on the Tails+Electrum USB stick. It seems to me that this would provide the diversity of entropy/secure elements/gaplessness that I seek (Electrum perhaps created with dice rolls; 2x HWWs using their own entropy). As with all multisigs, of course the descriptor would be kept backed up digitally in multiple locations, and each of the three wallets backed up to steel. Having Tails+Electrum as one of the three would also mean not having to buy yet another hardware wallet, using items already in my possession, and not relying on any particular vendor (other than Electrum developers) for that wallet.
I think we’re all looking for solutions and options after all the revelations of the last week. Does the above sound reasonable, or are there some aspects that I’m very much missing? Or is there something else that the “don’t need a hardware wallet” crowd tend to allude to instead?
Please read:
and this additional quick guide: #1539482
But the most important thing is: do not keep all your sats into just ONE wallet.
Always use the 3 levels stash: vault, cache, spending. with multiple wallets on each level.
THINK like a bank. Compartmentalization is key.
btw multisig will not help you too much but only complicate things too much. Multisig should be used only when are more than one user for the same wallet
Even if you don't want to read anything, check anything, do anything. Just say this every night before you go to sleep, and when you wake up. Make it your mantra.
Noted!
Excellent, and I've read (and zapped!) some of your earlier guides previously. The ones on mobile devices and lnurl come to mind! Great to see you have covered this too and will be sure to give all those three of these a good read. I appreciate it!
On the last comment, multisig is for the instance that any one of the signatures becomes compromised, if we were to see anything of the likes of Coldcard on other wallets (could be a vulnerability other than entropy; there are all kinds of ways firmware could go wrong). I'm going through the consideration of whether the additional complexity is worth it, but relying on just one wallet/passphrase seems insufficient at the moment. The Coldcard case was just too close for comfort!
Wasabi Wallet supports Tails. It has better privacy than Electrum/Sparrow.
I have always felt that multi-sig was just not right for me and that it is misclassified as a "security system" when really it is a "quorum system".
For a company, organisation, or group quorum can be useful. You need to 2/3 directors to sign the company chequebook to authorise a payment etc. There is of course an internal security component to this (stopping a rogue director / family member stealing the funds), but primarily it is about enforcing a procedural quorum over a bearer asset: "Do we all agree to send these funds? OK - let's sign".
This gets conflated with redundancy and hardened security against an external adversary. Practically, I don't think multi-sig gives any real redundancy from the kinds of situations in most people's threat profiles: natural disasters, misplacing a seed, losing a device, general screwups, medical emergency, $5 wrench.
If anything the logistics of it all is just such a pain that it becomes more of a risk: do you seperate the keys, or keep them together? Do you have the descriptor also stored securely in a way that can be recovered in an emergency? Can you rotate out of the keys easily and quickly? In an emergency can you sign on all the devices at night while in the middle of nowhere with shitty wifi?
IMO multi-sig creates a much more fragile and complex system. It has its use cases, but they come with the added overhead of keeping track of several seeds, several signing devices, backups of those seeds and devices, the wallet descriptor, and remembering all of this. It gets even more complicated if you become incapacitated or in a power of attorney situation and have to explain to someone WTF you actually did.
Running an air-gapped laptop
As individuals not operating in an institution / quorum environment, what we are after is a genuine second layer of security, right? Something that would save our funds in the worst case.
In the Coldcard situation, a strong passphrase and / or rolling your own dice would have had the same protective effect as a multi-sig but without the complexity.
Functionally, I thought the Coldcard was pretty easy to use, feature-packed, etc. Obviously I was wrong, and the reality that is dawning on me is that all of the hardware wallets really do suck – they are all missing something.
Looking through the pile of different signing devices they all have something about them that is not right, the Jade has its oracle thing, the BitBox has the shittiest touch buttons, the Bitkey has no screen, the Ledger screens all eventually fail...
So going back to basics: I like the idea of a simple old laptop with wifi and bluetooth disabled, with a linux distro and Sparrow or Electrum and then using something like Coleman's BIP39 tool to generate the mnemonic locally with dice, with the addition of a strong Passphrase on top.
That means you get:
What am I missing?
It absolutely gives you real redundancy to misplacing a seed and losing a device. General screwups, no. Medical emergency, no. Wrench attack yes if you have to go to multiple public places to get signatures. It can also help with natural disasters over single seed if your signers are geographically distributed.
I don't think the logistics are that hard. Why keep them together? The point is redundancy. It's not hard to keep track of 3 places. I don't understand why people act like rolling dice or remembering three locations are some kind of insurmountable obstacles. Descriptors are held with each device/seed or encrypted online or anywhere else you want to keep them. They can only leak privacy they can't sign anything. Key rotation, pain in the ass that's true. Also not great in an emergency that's true.
It is more complex that's true but it's much easier than it was in the past. Just following along with a BTCSessions multisig guide a couple times and you will get the hang of it. I really don't think it's that much to remember.
These are just my thoughts, of course it's up to everyone to decide what setup works best for them!
Thank you for the reply.
I understand the theory of what you say, but when I think about what a practical setup might look like it is still tricky to me:
Hiding 3 multi-sig seeds in 3 locations is a lot of real work. Can you access them all within an hour if an emergency comes up? Are they hidden enough to not be disturbed, but also not so well hidden that they may be accidentally lost?
Do you keep the 3 signing devices in the same place or distributed? If the wallets are together then wrench attack is still a real issue.
Do the multisig seeds share any common faults that could mean a majority become inaccessible? For example, we just had a big earthquake here in Japan the other day. It did not impact me - but it is quite possible that a safe deposit box, your own home, and a family member's home could all simultaneously become inaccessible in an earthquake = no way to get the seeds or devices together.
The hard piece for redundancy is that we want to maximise both distribution (going so far as having seeds in different continents...) but also something that can be quickly accessed if need be. There is an inherent contradiction there.
A single sig seed with passphrase duplicated in two places is more redundant and self-contained to me than than a multi-sig distributed over three places.
In the case of wrench attack, a passphrase does similar work as the multisig - there is at least some additional "thing" required to access the funds.
I am pushing and pursuing this topic as my goal is to find the best way for myself even, really just trying to wrap my head around all of this.
I wonder if we simply don't have the right language to practically describe this kind of security / redundancy stuff properly – It is all "geeky" theory focussing on the signatures and the devices, but fails to account for the way Shit Actually Goes Wrong in the world.
Real life is messy and people forget things, nature lashes out, life is unpredictable etc. IMO the fragility of multisig is not in the initial setup - that is a straight-forward process, but in the active practical maintenance of that setup for years / decades.
P.S. My other recent post tries to explore another mechanism for maintaining failsafe redundancy by using unbroadcast signed transactions – Request for comment: Unbroadcast Bitcoin transactions as failsafe
CE
I actually agree with this, and the mental burden of where to split the different parts of the multisig is probably the main thing that has prevented me from using it so far. For me (and I think many), coming up with more than one safe-but-hidden location over a long term is more difficult than is often acknowledged.
With single-sig + passphrase, you have only one off-site location to worry about for the seed phrase, and then the passphrase can be portable, stored in a password manager or whatever, just for the case that the seed phrase location is uncovered or there turns out to be a vulnerability in the seed's original generation.
With multi-sig, you have three seeds plus a data descriptor. If the three seeds are kept together, then the wallet can be spent from immediately if somebody were to uncover their location, making it less secure than the single-sig + remote passphrase would have been. So if we wanted to retain the same convenience of the single-sig setup, but with the additional security of a multi-sig against a compromised wallet, then could we keep two of the signatures together in the same location, and then the third signature (and descriptor) made effectively as your "passphrase", kept as portable copies in a password manager or encrypted USB? This is assuming that it is absolutely impossible to spend from two signatures without the descriptor, which I believe to be the case but have not yet tested personally.
In that scenario, keeping the mental location burden the same:
There the number of words and data to keep track of is essentially the same, but are we any more secure in the multisig setup to make it worth storing an opaque descriptor too? Unless we want to introduce additional complexity of multiple seed locations, then a strong passphrase may be enough to negate the need for all the extra gymnastics. With a 12-word passphrase typed into a PC on Tails+Electrum rather than a weak passphrase fumbled into a hardware wallet, you basically have the security of a second required signature regardless.
Or am I missing something new?
Thanks for the thoughtful reply, and it sounds like we're landing in a similar place.
I've always felt that multi-sig is overkill and can go wrong in too many ways, and it is only the realisation that all hardware wallets are flawed in one way or another that has been pushing me reluctantly in the multi-sig direction. Since none of them can be trusted now to be bug-free for the lifetime of the wallet, are we forced into a complex multisig future?
The Tails+Electrum solution was proposed as one way to make one of the three less bad, and to ask the crowd whether it is indeed considered a viable option. Perhaps due to the whole influencer crowd and the incentives of the manufacturers in prominent places, I've heard very little of the "offline laptop+wallet" solution over the years. But the more I look at the ways multisig can go wrong (all the ways you cite, plus lost descriptors and the varying wallet derivation paths mentioned by @billytheked earlier), plus all the ways in which every hardware wallet is flawed, then the more I think that a single-signature offline laptop + wallet (Sparrow, Electrum, Wasabi) could be a way forward through all of this. Create your own entropy or use the battle-tested entropy of Linux; full control and ownership without outsourcing any security to a HWW maker; as many cheap backups as you like from multiple USB copies (presumably Clonezilla or dd could do this; would need to check).
Perhaps this is the way to go? Single sig plus passphrase, but on our own airgapped hardware.
I wonder what the preferred way to generate the passphrase is? The issue with something like a Coldcard or Bitbox was that it takes ages to enter a long passphrase.
I wonder if a different approach could be employed between the entrop for the base seed and the passphrase? E.g. Use Dice and the Iancoleman BIP39 tool to generate the base seed, and then something else to generate a 12 word BIP39-compatible passphrase on top of that "just in case"?
Even if your base seed is totally compromised, you still have your funds.
Having it on a computer means it would be way easier to type it out...
You can use dice and use the list(s) provided at Diceware for a passphrase if you want to use a different list than the BIP39 one.
Yeah, one thing I've learned over the last few days is that for a passphrase to save you, it needs to be much longer than what can be comfortably (and reliably, repeatedly) be typed into any of these signing devices. But with a laptop keyboard at our disposal, or KeepassXC installed, it would be trivial to generate a passphrase with the appropriate entropy, and for it to be easily tested.
I think there is a lot to be said for the tails option. The way you describe it sounds reasonable (although I wouldn't count on the USB stick lasting very long -- I know that sometimes they can last 5 - 10 years, but I've also had a lot of USB drives crap out on me sooner than this, so I'd try to set up a system persistent storage on a USB isn't necessary).
When signing, couldn't you import the seed for that wallet from steel backups and use a fresh instance of tails you create on a new usb stick? If you want to avoid wireless/bluetooth, you could take the device on which you run tails to some place where signals are not so good. Boot into tails, import seed into electrum, sign a psbt, save the psbt to a usb, and then move on to the next signing device.
In general, I love psbts and I have used something very like the tails instance you describe in the past. It's worth exploring!
To just highlight something from earlier discussions: the idea that a seed is like a password or a physical key, especially if it is your raw entropy, is simply poor process.
Derive a hardened
xprv1'. Encrypt it with a good passphrase. Now you never expose your seed, only a password that, if you fuck up, can be reset through a restore from seed and sweep intoxprv2'. Minimum touching seed phrase. All this BIP-39 hacking is cringe af because you're literally interacting with a root key. BIP-32 (that you're using to derive the keys and addresses with) was made so that you don't need the root key all the time. So that you can have funds in account (a) and (b) and if (b) gets compromised you still have everything (a). Walking around with your root key is completely negating that.I think I will probably need to spend a couple solid days working through this comment. I have a rough idea of what you are saying, but I definitely couldn't implement a scheme like this with confidence right now.
Nevertheless, in the above scheme, I wasn't thinking of basing everything off a single root key.
In the case of a multisig, wouldn't using child keys to make the multisig add complexity to the whole setup?
If I have 5 root keys (not sure if that's what they should be called, but let's say they are all of equal privilege in the setup, and signatures from any 3 can spend, it is a pretty simple setup to treat each of them like a physical key.
Keep them in separate places. Import them to separate signing devices. The only thing that gets carried around is a psbt. I may be misunderstanding what you are describing though.
If you have a 3/5 descriptor where you specify 1 xprv and 4 xpubs (i.e. a core descriptor like
sh(multi(3,xprv.../84'/0'/0'/*,xpub1,xpub2,xpub3,xpub4)), then you don't need the seed to withdraw. you only need the derivedxprv.../84'/0'/0', and with that key you can sign subkeys0/0,0/1,1/0,1/1as you go through your multisig addresses each time you make a withdrawal, exactly like you do with the xpubs to generate that address to deposit into.You can then later derive (from seeds) a target for
xprv.../84'/0'/1'/*for another segregated multisig.What I really don't understand is that you're juggling 5 root keys. It's almost like BIP-32 becomes an afterthought, the hardened derivation becomes a nice-to-have and every time you interact with any signer, you expose everything (but segregated into 5 devices.) Sounds like a nightmare.
Do you have a video explaining this? I'm a bit lost here, haha.
nope, lol. But let me make a device real quick and give some of them podcasters a refcode in exchange for a tutorial.
TOP
Possibly something else is being discussed here but just to be clear, I'm referring to three independently generated seeds, not multiple accounts generated from one seed. And the seed plate backups themselves would live elsewhere as a cold "emergency" backup, while remaining imported into the two hardware wallets' secure enclaves and the Tails Electrum's persistent LUKs storage. As I say though, this may be a separate discussion – if so, pardon the intrusion!
I didn't quote what you wrote, so I wasn't referring to what you wrote, sorry if I made that impression.
What I was calling out was a growing narrative that continuously using the seed (i.e. it not being a cold emergency backup like you describe) to re-derive something that could have been encrypted with a password, is good, while in fact it is exposing something that should only be exposed in emergencies (like you say too.)
I have seen this whole "stateless device, just insert seed" narrative for years now, and we also see a lot of "directly roll seed". With that, more and more safety measures get pushed aside without speaking to what those are, which bothers me. Not criticism of people, but more of a trend that calls for simplicity without understanding what is lost by ignoring guardrails.
Perfect, that makes sense! And no worries at all – I'm brand new to Stacker News today so some conventions may be sailing past me; apologies for that. I completely agree, and it's also why I haven't jumped aboard the Seed Signer train thus far. Good to call these things out! For Tails, the persistent LUKS storage seems a very clever feature for this use case.
True.
Also, if you do, make sure your tails instance is kept up to date.
There's one more thing about this which that you might want to beware also, which is Electrum does not use the same seed derivation scheme as most other wallets, which I think causes you to get a mismatched descriptor messsge if you upload another wallet's descriptor in the setup wizard. I think you can change the derivation path on setup, but I cannot remember and I wouldn't trust me anyway.
I'd keep the Tails instance up to date through the instructions on https://tails.net/doc/upgrade/, though it may be less critical for an instance which is never connected to the internet. Something to keep up with for sure though (much like firmware updates on HWWs).
The Electrum seed derivation is a real footgun and this is indeed the kind of thing I hoped to uncover through this post. I've heard previously of Electrum's non-standardness so that would be something to thoroughly explore and test out first, before making a multisig with it. Perhaps using Sparrow on the persistent storage would be just as good, and then I'd be using a wallet that I'm more familiar with? Wasabi has also been mentioned below.
Look into it. To my knowledge, the native tails wallet is the most straightforward if you want to keep it offline. Spectre desktop lets you add different derivation paths in your wallets, which tells me there probably is a way.
Good point on the USB stick durability – so keeping a copy/backup may be wise. I don't think I'd want to import the seed fresh from steel every time, also because the physical backup may be elsewhere. If I were going to go that route of importing each time, then a Seed Signer or uninitialised Jade would suffice. But a LUKS-encrypted persistent storage partition on the USB seems like something close enough to what a "secure element" would provide on a HWW.
Obviously it's not but this is what people are being driven to, with the absolutely absurd complexities of this
I mean, I thought Darth's tails electrum was a good idea, until Scoresby said the usb dies after a few years lol
Noobs are utterly cooked 😭
I set up my wallet using Ian Coleman's website offline, on an Ubuntu PC I installed just for that purpose on some old laptops I have at home. I generated the keys and imported them to a Blue Wallet, and soon enough, I printed some sheets to generate the key on metal, and soon enough. Now I'm going to generate two more when I have some new UTXOS. I think complexity kills people.
PS: I generated entropy with some Monopoly dice.
How will yiu sign tx if you want to spend in future? Use BW normally (hot)?
P.S props for using Ian Coleman, I looked at his site, very cool, after an overload of data, I actually learnt stuff about bip39 and derivation paths
I only use the BW to receive payments and view the balance, but you can easily sign with a dedicated phone. You leave one phone with the app and the PK (Payment Key), send a transaction from your WO phone, and then scan the QR code and sign the transaction from your other phone with the PK. Finally, scan the generated QR code again from the WO phone and the transaction is transmitted.
I didn't notice properly and Google Translate put "Private Key" as "Payment Key", sorry
Shuffle PSBTs between the online watch-only wallet and the offline laptop wallet using a second USB drive, or an SD card, or QR codes via the webcam.
Indeed, and that's the tragedy of all this. One seed with a half-decent passphrase is easy enough to conceptualise, but once pushed to multisig the footguns and anxieties intensify. As we all know, leaving sats on an exchange carries its own risks. It's really a tough time for bitcoin right now, so in part this is me figuring out where we go from here and where others might be looking.
I feel like the more you read about these things, the more paranoid you become these days.
Sounds like a complicated setup. You might want to look into how you sign the TX using tails+electrum when on an air gapped computer.
Perhaps complicated, yes. It feels like the fast-moving vulnerability uncovering by the likes of Kimi K3 is making multi-vendor multi-sig a near necessity though, so I'm just looking here at one of those signatures being something other than yet another flawed hardware wallet. At the same time though, we do not want to trap ourselves in overly complicated setups, so looking for all the pitfalls before making a drastic change.
On how to sign the TX, it would be an SD card PSBT dance between the internet-connected Sparrow computer and the non-internet-connected Tails+Electrum computer, much like the previous PSBT SD card swapping between Sparrow and a Coldcard. Between computers, a separate USB stick could also be used in place of an SD card, so that would be the "air gapped" part. Or I guess QR codes would even work with the webcams, though clumsy on laptops!
I kinda had the same thoughts three years ago with #354651 but I sort of got shot down in the comments.
I like the idea and have been thinking along the same lines. If the concern, though, is trusting third party HWW’s, wouldn’t you only want to use 1 and have two such tails based wallets? Otherwise your multisig quorum could be achieved with just HWW’s. Having 2 tails wallets would require at least one to be used to sign a transaction.
The concern is trusting one HWW. With the feature set of the Coldcard before last week, that seemed reasonable (if not for the entropy bug and view-only source which proved to be its downfall). But as I outlined a little in the post, all of the other HWWs on the market seem to have one compromise or other, whether that's being non-airgapped or being tied to an online Oracle, or something else. So this Tails+Electrum alternative (or Tails+Wasabi as @Kruw mentioned) is a way for the third wallet to also be diversified in some way, if it's a viable option.
I certainly take the point though. The quorum could be reached with the other two HWWs, but I'd be making those two different enough (Jade+Bitbox for example) that it ought to be fine.
Making two Tails-based wallets, on the other hand, would take me back to a quorum of two similarly-generated seeds with identical security profiles, rather than three diverse ones.
I could be way over-complicating things of course, but that's my thinking.
This is basically the setup I ended up building, except I went all-software for all three keys instead of keeping two HWWs. For what it's worth, your hybrid is arguably better diversified than mine: two independent secure elements plus one airgapped software signer covers more failure modes than three software keys do.
A few things from actually doing it end to end (deposit, cold sign, broadcast, confirmed on mainnet):
I used Sparrow instead of Electrum on the Tails stick. Same idea, but the multisig UX is cleaner, the PSBT-over-USB flow is exactly the gapless signing you're describing, and it let me cross-check every receive address against Bitcoin Core's deriveaddresses and a third generator before funding. That cross-check is five minutes and it's the only step that catches a silently wrong descriptor.
On the dice entropy: watch out for one thing no guide I found gets right. The seed tool applies bias correction, so "99 rolls = 256 bits" isn't true in practice. In my run, 100 rolls credited 163 bits, not 256. The rule has to be "roll until the counter shows 256 real bits," which took me around 140. Stop at 99 and you still get 24 valid words and a working wallet, you just quietly have less entropy than you think.
The design decision I'd think hardest about: do you want that software key at rest or not? Your proposal (Electrum in LUKS persistent storage) keeps the seed on the stick, encrypted. I went the other way: nothing persists, the seed lives only on paper and steel, and I retype it into a freshly rebuilt wallet each time I sign. More annoying per signature, but there's no key at rest whose safety rides on the LUKS passphrase plus that machine never being compromised. Both are defensible, it depends on your threat model. Worth deciding on purpose rather than by default.
I documented the whole procedure, including the three mistakes I made and a fingerprint I got wrong in an earlier version: https://github.com/NoaSEED/bitcoin-vault-2of3 , the entropy and descriptor-backup sections are the ones I'd most want eyes on. I also wrote up the vendor-risk reasoning behind the whole thing here on SN, which is basically your starting point after Coldcard: #1545677