@LukeDashjr Maybe Errors and Omissions coverage but “retro date” would need to be older than the date of the bad code deployment. Then there’s the whole “was the bad code deployed intentionally”? Obvi intentional acts excluded….. This could take a while
I’ve been very quiet on the coldcard hack, but as this situation is unfolding it’s getting harder and harder not to say something.
I’ve never used a coldcard – not because I dislike anyone, or because I like someone else better, which seems to be much of the discussion here – but because I felt like coldcard was for very advanced users, and if anything went wrong, I’d be left to myself to clean up the mess.
What I find incredibly sad about this situation is that this is exactly what seems to be happening.
Who is posting updates on the hacks, which are still ongoing? Block. Galaxy. Developers that have their own projects to worry about, yet they are worrying about coldcard users.
Who is helping the affected make sense of what just happened? Everyone I know is busy helping others who lost funds, 24h around the clock.
Who is thinking of ways to return funds if the hackers are caught? Literally engineers on X and spaces that have no affiliation to the project.
*All of this* should be coldcard’s responsibility. And it makes me incredibly angry.
If there is any learning in this imo, it’s not that AI gets better and the script kiddies will get you next.
It’s that you should not be building hardware wallets that you sell to people who entrust you with their life savings when you don’t have the team in place to take care of them and make sure that they are safe.
Honestly quite speechless at this level of carelessness.
Much love to anyone who is affected.
@zackbshapiro@HaileyLennonBTC Negligence at a minimum and tough to believe CC were carrying any sort of cyber/commercial general liab insurance to respond to something like this...
ugh.
> dismiss early warning signs as fud
> victim blame early Reddit posts
> 500 btc lost at this point
> only issue alert for mk3. Claim all later models safe
> only later issue unclear alert for all models, with unclear migration steps
This communication approach prioritized profit from device sales over existing customers.
Step after step @COLDCARDwallet downplayed an attack as it was unfolding online.
This prioritization is unacceptable for centralized custodians. It should be unforgivable for a security hardware vendor.
This is such a bad look @nvk
Please focus every free second on helping your customers. You shouldn’t have time to throw stones from a glass house and try to cause further panic.
Obviously, as a community, we should not trust, but verify. But, this is tone deaf.
On the Coldcard entropy bug:
- It was never hidden, public source for 5+ years. Source-available ≠ audited.
- The regression rode in on a licensing-driven swap: from the mature, many-forks-depend-on-it Trezor-derived GPL crypto to a single-author libNgU under a bespoke "Bitcoin only" license.
- Root cause is a one-word bug (ifndef vs if). The most catastrophic bugs are boring.
- XOR-ing two broken seeds is theater, two reproducible streams stay reproducible.
32 bits is the recurring curse — Trust Wallet, libbitcoin bx, now Coldcard's Mk4/Q/Mk5 reseed. 2³² ≈ a weekend on one GPU. This is the same as doing twelve dice rolls and stopping. That's why dice rolls can be very dangerous!
- Coinkite says Mk4/Q/Mk5 are safe; Block says ≤2³². Same code, opposite conclusions.
- Reproducible builds guaranteed everyone got the same wrong binary. Verifying the artifact ≠ verifying the behavior.
- They punished the fork (@FoundationHQ) by licensing, then the bug entered on the same commit that evicted the forkable code.
-"Not your keys, not your coins" now gets prepended with "not your entropy, not your coins."
Sovereignty is a verb.
If I was head of Coldcard, I would probably take a slightly more humble approach than reposting FUD against competing hardware wallets WHILE my own customers wallets are getting drained because of incompetence on your own company’s part.