Large-scale Coldcard compromise (1596 BTC stolen so far)

[KiaKia]

COLDCARD wave 3 attackers have, for the first time, transferred the stolen Bitcoins and exchanged the BTC for ETH via the THORchain cross-chain DEX. This marks the movement of the Coldcard hackers, as the stolen BTC has been transferred onchain from the original hacker address during Waves 1, 2, or 3.
https://x.com/intangiblecoins/status/2095297452681158840

By the way why isn't any of the addresses freezed yet? They need some kind of permission? I think ColdCard people are too slow for my liking, I still don't like how they handled the attack.

In this days hardware companies should be having some backup plans in case something very ugly happens, something like what just happened to ColdCard itself..

Just in case something bad happen what can we do to limit the impact? in as much as I don't like CZ of Binance he is a critical thinker who planned for damaged funds too. They need to up their game and I'm sure that alot of people already lost interest in them.

[Meuserna]

COLDCARD wave 3 attackers have, for the first time, transferred the stolen Bitcoins and exchanged the BTC for ETH via the THORchain cross-chain DEX. This marks the movement of the Coldcard hackers, as the stolen BTC has been transferred onchain from the original hacker address during Waves 1, 2, or 3.
https://x.com/intangiblecoins/status/2095297452681158840

By the way why isn't any of the addresses freezed yet? They need some kind of permission? I think ColdCard people are too slow for my liking, I still don't like how they handled the attack.

In this days hardware companies should be having some backup plans in case something very ugly happens, something like what just happened to ColdCard itself..

Just in case something bad happen what can we do to limit the impact? in as much as I don't like CZ of Binance he is a critical thinker who planned for damaged funds too. They need to up their game and I'm sure that alot of people already lost interest in them.

Who do you want to freeze the addresses? ColdCard can't. Addresses are on the blockchain, not the device.

Surely, you're not advocating for censorship on the blockchain, where some governing authority decides which addresses can be used and who can use them.

~snip~
But I believe that hardware wallets will learn from their mistakes. Perhaps they’ll use powerful AI for audits or something like that.

I don't think they will learn anything, because in the end they can always shift the responsibility to someone else, as is the case now. Instead of taking care of customer data themselves, they leave it to others so they don't have to be responsible when something like this happens.

You're exactly right.

People always want to trust someone else instead of themselves. We're already seeing it. Instead of asking "How can I learn to keep my Bitcoin safe" people are asking "Which company will keep my Bitcoin safe?" This makes them likely to jump from one bad situation to another.

Part of the reason people do this is... most people are followers and too many are drawn to slick marketing (Ledger and ColdCard) and strongman-style bluster (Ledger execs and NVK).

Another reason people do this is because they foolishly think the device is the wallet, so they want a new device.

Even in a forum like this where people have a better understanding of Bitcoin and how it works... even here, too many people think the device is the wallet. IT'S NOT.

For anyone who doesn't understand what I mean: Your wallet is something like this:

5b578bd04ecceee2bf8120124e747daaa4b5eb1dfef0c776bd72eb4352c56e6b1c979f26746cda9 bd15a28fe31871d0417704b83e2ee60d3d05dc69c61da4cff

That's a seed. It was generated by this seed phrase:

hawk sunset alarm rigid question laugh fine mass tiger jazz stadium rich

That seed generates millions of addresses and keys, all of which are the wallet.

That is one of the most important concepts to understand about modern Bitcoin wallets (in other words, wallets made after BIP39 and deterministics became the norm).

So... the question should not be "Which company's stuff do I trust?" People should be asking: "What's the best way for me to protect my coins?"

I think the best way is to keep your Bitcoin safe is to learn how to generate your own random seed phrase by hand. One way is dice, but I recommend something like Entropia. You can easily make your own by printing the BIP39 worldlist on paper and chopping it up. Also, learn how to create a strong passphrase.

Then, use your seed phrase and passphrase on a hardware wallet that is:

- airgapped (online hackers can't reach it)
- stateless (your seed & wallet aren't saved on it)
- offers encrypted seed entry (encrypted seed QR)
- offers instant passphrase entry (passphrase QR)
- fully open source (protects you from shady devs)
- and runs on off the shelf hardware (protects you from supply chain attacks)

Right now, ShieldSigner and Krux are the best options for all of those. Kern soon will be too. And any QR that works with one will work with the others, which means you can always double-check everything on a separate device, which I recommend doing.

The sad thing is, everything I just listed is easy to do, but it doesn't come with a cool marketing campaign, so it isn't going to catch on the way the next for-profit gadget will. Most hardware wallets are just overpriced gadgets that limit your security rather than expand it because the company wants to lock you into their gadget.

Self custody means self-responsibility. I wish more people understood that trusting companies is not the answer.

[fillippone]

A new update has been released; they continue to improve security:

<…>
Btw, they closed the commenting feature for the post in X 

There must be a special place in hell for those who decided to hodl their satoshis in a Coldcard device after all that happened.
It’s not only stupidity, it is also allowing a bad actor in the Bitcoin ecosystem.

[mabji1]

A new update has been released; they continue to improve security:

View TRNG Words is back. We also added an offline tool to verify dice-roll or coin-flip mixing, USB ncry v3, and more transaction, Virtual Disk, firmware and wallet-state fixes.

Full note:
https://blog.coinkite.com/coldcard-firmware-update-5.6.2-1.5.2q/

Btw, they closed the commenting feature for the post in X 

After this incident, many users may find it difficult to trust Coldcard again.

[Stalker22]

COLDCARD wave 3 attackers have, for the first time, transferred the stolen Bitcoins and exchanged the BTC for ETH via the THORchain cross-chain DEX.
~

OK, so we definitely learned some thing today - That attacker is a total idiot.  I really do hope they catch his dumb ass soon.

[LoyceV]

By the way why isn't any of the addresses freezed yet?

You should ask the Bitcoin CEO to freeze those addresses.
/sarcasm

[tvbcof]

A new update has been released; they continue to improve security:

View TRNG Words is back. We also added an offline tool to verify dice-roll or coin-flip mixing, USB ncry v3, and more transaction, Virtual Disk, firmware and wallet-state fixes.

Full note:
https://blog.coinkite.com/coldcard-firmware-update-5.6.2-1.5.2q/

Btw, they closed the commenting feature for the post in X 

After this incident, many users may find it difficult to trust Coldcard again.

I feel it a bit of a public service duty to mention my personal experience here again (and expand on it a little.)

I have used three ColdCard Q devices.

I still use the first, but both 2 and 3 broke after probably 40-ish on-off cycles.  Unit 2 with a pin issue, and I'm around 99.9% sure I did not forget the pin nor did anyone access and fuck with the device.  Unit 3 experienced on-off defects, power issues, and eventually quit completely.

Notably, devices 2 and 3 helped sign very significant transactions early in their life cycles.

Just on hardware quality alone, 66% failure rates suck pretty badly.  Badly enough to where I have at least consider the possibility that the devices were configured to have 'issues' in certain situations which could have the effect of locking into the blockchain large amounts of unspent funds if the user didn't take certain precautions (like ensuring the function of the initial seed phrase configuration), or if those precautions also had some mysterious failures.

I did contact CoinKike once early on about unit 2, but they were completely dismissive of the possibility of any fault with their hardware and accusatory toward me.  At that point their 'support' bumped up (from non-zero) my suspicions about them and I decided to contact them no more so as not to give them any more information about me.

I would also mention that if someone finds themselves with significant value stuck on one of these devices, try a good hardware shop.  From what a little birdie told me, the devices may not be quite as secure as the sellers would want you to believe.

At this point I would be suspicious of ANY hardware which has any 'secrets' stored.  Even the likes of Seedsigner, Krux, etc ('stateless') should probably be analyzed carefully to make double-dog sure that there is no possibility of any info being cached; even if by accident.  Also check for unexpected EMF from the signing device if you have the ability to do so, and turn off you wi-fi router.  For large sets of transactions, for now at least, I would suggest to use cheap hardware and destroy it if used in a systematic way once the job is done.

[Cricktor]

That's quite an arrogant stance from Coinkite support. Apparently customers after sales are a nuisance in their eyes. I wonder where that comes from...

I would also mention that if someone finds themselves with significant value stuck on one of these devices, try a good hardware shop.  From what a little birdie told me, the devices may not be quite as secure as the sellers would want you to believe.

Out of curiosity: how could any "significant value" be "stuck on one of these devices"? Coins move on the blockchain, hardware wallets commonly only store, and hopefully secure, private keys of a wallet which enable a user to move those coins. Unless someone is so stupid to not have ALL details in redundant backup, therefore wouldn't likely be able to recover a wallet, how can "values" be stuck on flaky hardware wallets? I'm a bit out of imagination here.

I haven't ever used Coldcard stuff, but I'm pretty sure, when you setup a wallet on those, you get and should have all details to perfectly recreate and recover such a wallet, be it on the same device or on another software or hardware wallet which are compatible with BIP39.

At this point I would be suspicious of ANY hardware which has any 'secrets' stored.  Even the likes of Seedsigner, Krux, etc ('stateless') should probably be analyzed carefully to make double-dog sure that there is no possibility of any info being cached; even if by accident.

Feels a bit like overreacting to me, but who am I to judge.

Open-source stateless signing devices allow you to audit the code and verify no persistant details are stored outside of RAM. When you turn those devices off, typically RAM content gets destroyed and vanishes quickly. (A liquid nitrogen attack freezing RAM cell state is overkill and needs access to the device, where a 5$ wrench attack is cheaper and likely more accessible.)

Also check for unexpected EMF from the signing device if you have the ability to do so, and turn off you wi-fi router.  For large sets of transactions, for now at least, I would suggest to use cheap hardware and destroy it if used in a systematic way once the job is done.

Really? Are you moving hundreds or thousands of Bitcoins to justify somewhat that level of paranoia?

Don't get me wrong, it's not my intention to mock you. It's perfectly reasonable to want to have firmware code to mitigate side-channel attacks that could reveal secrets. Mitigating e.g. timing attacks should be common for crypto related code stuff. But stateless signing devices are not supposed and designed to keep secrets on them. I don't think such a device reveals enough EMF noise while signing a bunch of transactions that even sophisticated attackers could exploit remotely by capturing EMF emissions.

[tvbcof]

...
Out of curiosity: how could any "significant value" be "stuck on one of these devices"? Coins move on the blockchain, hardware wallets commonly only store, and hopefully secure, private keys of a wallet which enable a user to move those coins. Unless someone is so stupid to not have ALL details in redundant backup, therefore wouldn't likely be able to recover a wallet, how can "values" be stuck on flaky hardware wallets? I'm a bit out of imagination here.

Private key controlling an address exists only in the device's secure elements...in theory.  And cannot be pulled out...in theory.

I haven't ever used Coldcard stuff, but I'm pretty sure, when you setup a wallet on those, you get and should have all details to perfectly recreate and recover such a wallet, be it on the same device or on another software or hardware wallet which are compatible with BIP39.

Coldcard supports 'seedXOR' which is a wonderful technology IMHO, but complicates and confuses certain fairly standard things.  Aggressive auto-complete can also cause issues with some words (unwisely in my opinion) having become standard for BIP-39 implementations.  To Coinkite's credit, they did label seedXOR as 'experimental' or something like that IIRC.

At this point I would be suspicious of ANY hardware which has any 'secrets' stored.  Even the likes of Seedsigner, Krux, etc ('stateless') should probably be analyzed carefully to make double-dog sure that there is no possibility of any info being cached; even if by accident.

Feels a bit like overreacting to me, but who am I to judge.

Open-source stateless signing devices allow you to audit the code and verify no persistant details are stored outside of RAM. When you turn those devices off, typically RAM content gets destroyed and vanishes quickly. (A liquid nitrogen attack freezing RAM cell state is overkill and needs access to the device, where a 5$ wrench attack is cheaper and likely more accessible.)

Coinkite offered the ability to 'audit the code', and I've not yet heard of any credible evidence that they did not build the binaries to the codebase.  At the end of the day, this ability to 'audit' the code did not translate into it happening.

It's worth note that when using most closed-ISA (or open-ISA for that matter) processors, and most graphics processing modules, it's well beyond problematic to audit what is actually going on in there.  I would suspect that if anything is, it's mostly on a per-user basis depending on whether 'the algorithms' decide that the user is an interesting person in some way.  Then, if one is using Linux, that itself is hardly a trivial block of code to go through as well as being a moving target.  Both issues impact ras-pi and pretty much any other system which is why I favor very old/weak hardware and operating systems for security when possible.   In short, I'm of the opinion that 'audit the code' is mainly a buzz phrase...one of those things tossed out by ignorant people trying to sound smart.  But not you of course

...
I don't think such a device reveals enough EMF noise while signing a bunch of transactions that even sophisticated attackers could exploit remotely by capturing EMF emissions.

Come to find out that pretty much all household routers which support the beam-forming standard can out-of-the-box identify individual humans with 99.5% accuracy.  Even paranoidiac tin-foil hatters like yours truly who were more than a little bit concerned about 802.11ac were a bit surprised at the implantation rate before discovery I'll bet.  I've long suspected that a variety of devices that just 'by accident' can perform TEMPEST operations of various types are kicking around almost everyone's home these days, and probably have been for quite some time.  The technical challenges of exploiting such a capability mostly revolve around effective exfiltration I suspect.  Catagorizers (such as the NPU's required by certain software these days) would have gone a long distance toward helping with that problem.

[Meuserna]

...
Out of curiosity: how could any "significant value" be "stuck on one of these devices"? Coins move on the blockchain, hardware wallets commonly only store, and hopefully secure, private keys of a wallet which enable a user to move those coins. Unless someone is so stupid to not have ALL details in redundant backup, therefore wouldn't likely be able to recover a wallet, how can "values" be stuck on flaky hardware wallets? I'm a bit out of imagination here.

Private key controlling an address exists only in the device's secure elements...in theory.  And cannot be pulled out...in theory.

Ledger proved that to be false. Ledger is literally selling key extraction out of the secure element over the internet as a service called Ledger Recover. In theory, Ledger Recover must be activated on device by the user. In reality, it's just code, waiting to be exploited.

[tvbcof]

Private key controlling an address exists only in the device's secure elements...in theory.  And cannot be pulled out...in theory.

Ledger proved that to be false. Ledger is literally selling key extraction out of the secure element over the internet as a service called Ledger Recover. In theory, Ledger Recover must be activated on device by the user. In reality, it's just code, waiting to be exploited.

I paid attention to 'Ledger' for about 10 seconds a couple of years ago when I was researching viable solutions; I was speaking specifically about ColdCard Q since that is the only thing I've direct hands-on experience with.

I kinda don't like that I have to use difficult-to-audit certified tools to initially configure the Krux thing, and I'm much more interested in the idea of hacking a kid's cam, and figuring out how I can make durable 'seed plates', than any particular signer solution at this moment.  Almost certainly when I do, I'll choose the risc-v hardware or if necessary, the ARM one for a solution which at least works-alike with the ShieldSigner you promote.

[Cricktor]

Private key controlling an address exists only in the device's secure elements...in theory.  And cannot be pulled out...in theory.

Hm, frankly it doesn't matter if private keys are securely locked in device's secure element(s) and ideally can't be extracted out of those. When you have all necessary wallet details to recover the wallet one-to-one e.g. in a software wallet which allows you to reveal any of the private keys of a specific derivation path. I fail to see a lock-in here.

Coldcard supports 'seedXOR' which is a wonderful technology IMHO, but complicates and confuses certain fairly standard things.

I know the 'seedXOR' feature and to my understanding it doesn't change anything of the above, because for the ability of a true backup, a user has to backup every mnemonic recovery words set that goes into the seedXOR procedure. If a user fails to document everything, it's their fault, no (rhetorical question)?

Doesn't matter if the device generated the additional random bit string (converted to a set of mnemonic recovery words) or the user provided its own entropy via a set of mnemonic recovery words that gets XORed with the initial entropy of the wallet. In both cases you should document and backup everything anyway.

Aggressive auto-complete can also cause issues with some words (unwisely in my opinion) having become standard for BIP-39 implementations.

If aggressive auto-complete yields wrong mnemonic recovery words, then it's an implementation and/or UI failure. To my knowledge BIP39 words should be unambiguous with at most the fourth typed character.

To Coinkite's credit, they did label seedXOR as 'experimental' or something like that IIRC.

IIRC, Advanced/Tools > Danger Zone > Seed Functions > Seed XOR
...or was that with Foundation Devices so? Blurry memories... anyway, a bit hidden in a corner of a dungeon, lol.

I guess, nowadays you have to hide any advanced stuff behind some Danger Zone fence, because stupids try out stuff they don't understand and blame someone else when they shot themselves in their foot. Sane thinking became a rarity?


I'm likely in another (lighter) paranoia camp just to keep my sanity straight. I close my eyes and don't believe that my router, access points, network gear, Raspies or Linux boxes spy on me. Way too large code base to audit alone, for sure. As long as one uses a modern mobile phone, don't expect privacy. I'd rather turn off my mobile phone than my router when dealing with crypto seed stuff.

[suzanne5223]

By the way why isn't any of the addresses freezed yet?

This can only happened in shitcoin. This is because BTC is decentralized and censorship resistance.

Also, there is an ethical point.
Bybit heist came to the disadvantage of people holding their coins on an exchange. A frowned upon practice.
Coldcard hack came to the damage of people doing self custody.

Something that is very different and could shift the balance here.

I believe the balance is not shift, why did i have the impression?
If Coldcard wallet which their team was not honest and careless about their service could still experience huge demand it mean Bitcoiners still have trust in self-custody.
As you said "There must be a special place in hell for them" because once bitten, twice shy is what i know i dont about try again.

https://x.com/COLDCARDwallet/status/2096007685850222853?s=20

[tvbcof]

Private key controlling an address exists only in the device's secure elements...in theory.  And cannot be pulled out...in theory.

Hm, frankly it doesn't matter if private keys are securely locked in device's secure element(s) and ideally can't be extracted out of those. When you have all necessary wallet details to recover the wallet one-to-one e.g. in a software wallet which allows you to reveal any of the private keys of a specific derivation path. I fail to see a lock-in here.

Having private keys in a software wallet is actually what I wished to avoid.  The real problem is thinking one has all the necessary details and has tested things sufficiently only to learn later that it doesn't seem to be the case.  At least at the later date when needed.  Perhaps the user XORs the input plates then matches it against the displayed fingerprint as a test and everything seems OK.  The failure is probably that amidst the various temporary notes, tmp seed re-boots, etc and it could just be user error.  If I were evil and had decided to build up a retirement account, and pretty sure that almost nobody looked at the code much less tried to build their own firmware (if they even understood what that is) I could think of a number of ways to create the potential for 'errors'.

I cannot say that 'my friend' did everything perfectly.  He was working late and on his way to a trans-continental flight in the morning which is not good working conditions.  I also cannot rule out that it was in someone within coinkite's interest for certain kinds of errors to occur.  I mean they had people sock-puppeting with themselves to credibly include defective cryptographic code so they were very probably also up to no good.  There are a number of possibilities here which are not fully explored, and I doubt they ever will be.

Coldcard supports 'seedXOR' which is a wonderful technology IMHO, but complicates and confuses certain fairly standard things.

I know the 'seedXOR' feature and to my understanding it doesn't change anything of the above, because for the ability of a true backup, a user has to backup every mnemonic recovery words set that goes into the seedXOR procedure. If a user fails to document everything, it's their fault, no (rhetorical question)?

Have you used it in the context of doing initial configuration of a new CCQ device?  If so, you could validate your proficiency by outlining a set of working procedures and test procedures which would be coherent and realistic.

Doesn't matter if the device generated the additional random bit string (converted to a set of mnemonic recovery words) or the user provided its own entropy via a set of mnemonic recovery words that gets XORed with the initial entropy of the wallet. In both cases you should document and backup everything anyway.

I have and will continue to NOT document any more than needed according to the theoretical necessity of whatever solution I cooked up.  I suspect that sometime before the earth stops cooling it will be clear to a lot of people why doing so opened up some pretty glaring security gaps which will ultimately be exploited in a lot of cases.  When one gets done with dice rolls, hammering seed plates, moving funds around in planned manner, etc, etc, one can end up with a stack of papers and notes.  You can stuff them in a box and put them on a shelf if you like.  It's not my style.

Aggressive auto-complete can also cause issues with some words (unwisely in my opinion) having become standard for BIP-39 implementations.

If aggressive auto-complete yields wrong mnemonic recovery words, then it's an implementation and/or UI failure. To my knowledge BIP39 words should be unambiguous with at most the fourth typed character.

To Coinkite's credit, they did label seedXOR as 'experimental' or something like that IIRC.

IIRC, Advanced/Tools > Danger Zone > Seed Functions > Seed XOR
...or was that with Foundation Devices so? Blurry memories... anyway, a bit hidden in a corner of a dungeon, lol.

I guess, nowadays you have to hide any advanced stuff behind some Danger Zone fence, because stupids try out stuff they don't understand and blame someone else when they shot themselves in their foot. Sane thinking became a rarity?

I'll look forward to what you think is the right way.  From what I can see, most people cannot even conceptualize why one wouldn't put their entire hoard under one signing key much less have even tried 'new technology' such as SeedXOR.  I mean, I saw no discussion of it whatsoever among the general population when I was doing research and experiments.

For my part, using the CCQ (and remembering that at the time I had had no issues with any such device in my past experience) was a somewhat temporary thing with the device used mostly to split a block of BTC into smaller parts since the device is quite a bit more usable than the competition.  To lose funds two things, both unlikely, would have to occur.  1) Malfunction of the CCQ, and 2) failure of the recovery phrases would have to not work.  I thought 2) to be reasonable well tested (and it was not.)  Anyway, am willing to take the hit for the mistakes which I may have made, but I don't disagree with my assessments of the risks known at the time.  It was, after all, still in the experimental phase from my perspective.

I'm likely in another (lighter) paranoia camp just to keep my sanity straight. I close my eyes and don't believe that my router, access points, network gear, Raspies or Linux boxes spy on me. Way too large code base to audit alone, for sure. As long as one uses a modern mobile phone, don't expect privacy. I'd rather turn off my mobile phone than my router when dealing with crypto seed stuff.

Fine.  You do you.

Funny story.  My proverbial friend decided to put things related to a loss on the back-burner and focus on more fun stuff for a year or so.  When this 'large-scale hack' happens, he saw an opportunity to perhaps get his funds back due to CoinKite's 'error'.  In seeking help on work from that angle (on an emergency basis), he enlisted the help of professionals.  The project was a success, though not via an attack on the baked in entropy deficiency...for what it's worth...

Far from losing money, this friend came out very far ahead monetarily due to the event.  In my part of the world, we call this 'Falling down in shit and coming up smelling like a rose.'

[Cricktor]

Having private keys in a software wallet is actually what I wished to avoid.  The real problem is thinking one has all the necessary details and has tested things sufficiently only to learn later that it doesn't seem to be the case.  At least at the later date when needed.

Sure, I'm not promoting to expose private keys in a software wallet as a preferred way of handling those. I'm simply highlighting that BIP39 compliant wallets don't lock in private keys as long as you can fully recover such a wallet with all details necessary (mnemonic recovery words, optional mnemonic passphrase, derivation path, maybe BIP85 further derivation, whatever).

Well, self-custody has some responsibilities attached. Thinking something should work, isn't enough for me, at least. From my share of fails in the past, I hope I've learned a thing or two. For me it's mandatory to thoroughly verify that I'm able to recover a wallet from scratch and what I've documented about it. If I can't, I have no working backup and then I'm playing with fire and desaster is likely inevitable. I don't intend to go this route ever again.

Have you used it in the context of doing initial configuration of a new CCQ device?

No, I have never used a Coldcard device in real. I thoroughly studied claimed capabilities and functions of those devices before I finally decided I don't want those because I don't like how Coinkite acts. This company doesn't deserve my money for their products and I'm happy to have avoided their maldoing.

Due to early dismissing Coinkite as a company worth my money, I didn't even bother to try out their device/firmware simulator.

Likely someone already said this, too. It strikes me, that Coldcard developers apparently never really debugged or analysed their firmware binary properly. The faulty firmware didn't have a code path where proper and sufficiently good entropy could have been generated for a device generated wallet, if I'm not wrong. I find this disturbing and utterly unprofessional.


I can't really give more advise here. It's quite some time ago when I ran into issues due to not quite well understanding how Bitcoin works (certain things) and how some wallets work in particular. And I don't like such a situation. This triggered me to go out on a learning journey that's far from being finished. As long as things are not beyond my mental capacities, I want to understand and solve stuff on my own. This feels better to me than relying on others.

My approach is to make a loss risk assessment and pick to cover the most relevant risks and try to mitigate them with a least complicated setup. One of these loss risks is me. I mean if something happened to me, what about my coins and my family? I want to take care of this properly and this needs proper documentation. Not going into details here as this already digresses from the topic here.

[tvbcof]

...

A rigorous test would have been to buy a 2nd CCQ and test out a new 'SeedXOR' configuration just to make sure that the UI were properly rendering inputs (and it should be a very simple operation and in my thought process, not very likely to fail in a algorithmic sense.)  Next would have been to test a hand generated XOR result on another (hopefully secure) machine and double-check that the fingerprints all matched up.  Then destroy all testing devices.  No, I didn't do this.  My bad.  I'm probably not alone in applying insufficient rigor to similar problems, especially when everything is working fine.

All bets are off if one's chosen vendor has decided to be crooked since there are a ton of nasty tricks they could employ and it would be very difficult to detect them.  The best defense against such a thing wiping one out is diversification, and I've done that right enough for the past lotsa years.

---

My reluctance to do seed operations on occasionally connected devices is the driving force behind my hope to have a whole 'air-gapped ecosystem' with such things as card creation tools, converters, signers, etc being always air-gapped but trusting one another for sensitive operations...one seed at a time.  Also, each being as simple as possible including having disposable control boards if not being completely disposable where it makes sense.  It would be nice to be able to share machine tools to make robust cards, but very tricky.  These would only be even potentially safe if a 'friend' always supplied their own controller.

On BIP-39, I don't think I'll use it going forward.  It's not supported by some entities whom I have some confidence in (Bitcoin Core, Electrum, etc.)  Probably will use BIP-32 though, at least for most stuff.

According to some, one of the main battles for quantum resistance comes from the hardware seed guys since it promises to fuck up their current product lines.  I'm watching how this proceeds before coming to any conclusions on what sort of over-arching seed solutions are going to have staying power.

---

I'm also thinking that it make sense to have well protected seeds for addresses which don't yet exist, and corresponding signed transactions to be released driven by events (dead-man type switches, desire to cash out, etc.)  In this way, an address to target (for tracking, collation, brute-force attacks, etc) will be unavailable to the world via blockchain analysis.  Yet another reason to have a feasible way of reliably generating and protecting a large number of seeds vs. a small number protecting large values.

[Pmalek]

If aggressive auto-complete yields wrong mnemonic recovery words, then it's an implementation and/or UI failure. To my knowledge BIP39 words should be unambiguous with at most the fourth typed character.

That's correct. The Cryptotag Loki titanium seed plate, for example, only allows users to stamp the first four letters per word. You don't need to punch in the whole word and there isn't even place on the plate to do it. The first four characters are enough. No two words from the BIP39 wordlist can have the same beginning letters.

[tvbcof]

If aggressive auto-complete yields wrong mnemonic recovery words, then it's an implementation and/or UI failure. To my knowledge BIP39 words should be unambiguous with at most the fourth typed character.

That's correct. The Cryptotag Loki titanium seed plate, for example, only allows users to stamp the first four letters per word. You don't need to punch in the whole word and there isn't even place on the plate to do it. The first four characters are enough. No two words from the BIP39 wordlist can have the same beginning letters.

They can share three letters with another word, and may be complete in three-letter form.  'air' and 'airplane' come to mind.  This can cause entry problems if an algorithm aggressively solves near the end of a phrase entry cycle due to the existence of the checksum word.  If a UI moves on once a valid solution is achieved without offering the user a chance to cross-check it can be problematic, and, of course, if backing up and re-editing is mis-coded to improperly reflect a state, the results will always be disaster.  There is a pretty famous error of this nature in a machine that administered radiation in the medical field which killed some people.

But that is not the reason I'm getting cold-feet about BIP-39.

[EstherBtc]

https://x.com/americanhodl8/status/2095893749151011088

Coldcard on X is blocking anyone who comments negatively or asks for a refund of their stolen btc. The comments section of their recent posts on the Coldcard X account has also been disabled.

So how will they be able to get honest feedbacks if they disable the comments section? This goes to show that they lack empathy for the victims of this attack.

[Pmalek]

They can share three letters with another word, and may be complete in three-letter form.  'air' and 'airplane' come to mind.

They can share the same three letters, yes, but I was talking about four letters being needed. 'Air' and 'airplane' share the same first three letters but the fourth letter, 'p' isn't present in 'air' or in any other word of the BIP39 wordlist. Therefore, the moment you start typing 'airp' to recover a wallet created on that standard, 'airplane' is the only word that fits in that position.