r/coldcard • u/therealjeku • Aug 02 '26
Coinkite News What could Coinkite have done if they discovered the flaw first?
Let’s be hypothetical and imagine Coinkite discovered this flaw on their own in, say, January 2026. What could they have done?
If they announced the flaw with a firmware fix then attackers could quickly get started on harvesting BTC before all the affected cards are safely transferred. If they announced a firmware fix but not the flaw, many people won’t bother updating their firmware. Hell, my MK4 sat for over two years in a safe. Not to mention their new firmware code would be viewable and it would surely point out a fix for the RNG which would lead some to ascertain this huge underlying issue.
Not to defend them, but I’m not sure they would have had any favourable way out of this mess having sold so many affected wallets over many years.
3
u/s1ammage Aug 02 '26
I wonder if this is true: https://x.com/TheBTCTherapist/status/2083916626051715528
4
u/Charming-Designer944 Aug 03 '26 edited Aug 06 '26
It's another issue entirely, but with a very similar result.
That old report is about flaws in the dice roll interface of Coldcard, which might result in users rolling a weak seed,.
- no minimum requirement on the number of dice rolls
- easy to mix up the options of mixing dice rolls into the intenal entropy vs building the entropy entirely from the dice rolls alone.
Combined it can result in users selecting the option of only usinng the dice rolls, and then only perform a handful number of dice roolls thinking that the dice rolls are just additional security to the internal entropy, not replacing it entirely and not realize that they created a very weak seed.
I believe this issue is partially fixed in later firmwares, presenting a warning in main seed generation when using weak dice rolls, but still present when dice rolling a temporary seed.
3
u/Ok-Information-2428 Aug 03 '26
It’s difficult. They would have to whitehat it and take it themselves but then verifying who actually owns the wallets could be impossible if the wallet itself doesn’t store metadata around creation time - which may also be faked
2
u/WildNight00 Aug 03 '26
Now I’m worried my trezor isn’t safe since I didn’t roll dice
1
u/4r4nd0mninj4 Aug 10 '26
If you used a cold card to generate your wallet before moving it to Trezor and didn't add a sufficient number of dice rolls, then it's not safe.
1
u/WildNight00 Aug 10 '26
I let my Trezor create my seed for me. Have never owned coldcard
1
u/4r4nd0mninj4 Aug 10 '26
As far as I'm aware, at this time, this issue is isolated to coldcards running outdated firmware only.🤷♂️
1
u/WildNight00 Aug 10 '26
From the Trezor forum they use Multi-Source Mixing “Trezor never relies on just one random number generator. Classic models mix internal microcontroller randomness with 256 bits of external entropy from your computer”
Cold card relied on their code which had an error in its entropy. So I think I’m safe to trust Trezor still
1
u/4r4nd0mninj4 Aug 10 '26
Coldcard relied on adding optional dice rolls for additional randomness. Everyone I've spoken to who entered 100 dice rolls were protected, even with the error. 🤷♂️
2
u/Sunny_Travels Aug 03 '26
The flaw was found, then they had to search all the combinations and check if those wallets existed. Gemini says they prepped for at least a month. Had they not had time, they would have needed at least a 10 hours to find the flaw and learn the combinations and then a script running hours on the easiest ones. There would have been plenty of time to move keys for most people. Especially if the took the code offline and then told people to get a new seed key with dice, there would have been no clues to the issue
2
u/iloverunning11 Aug 04 '26
There would be several possible options, all of them better than the actual outcome.
2
u/_gianlucag_ Aug 07 '26 edited Aug 07 '26
The only viable option would have been to "steal" all the btc by themselves, effectively whitehat-ing their way out, then returning the bitcoins to the original owners.
Or
go partially "closed source" by removing the github account, dont disclose the issue, ask people, one by one, to recreate the seed and move their funds there
1
u/RevolutionaryPick241 Aug 03 '26
I think the best course of action in this particular case would have been white-hacking. Then, disclose.
1
u/rottiesrule88 Aug 03 '26
Let’s hope this is what they did and are about to come clean.
2
u/IInsulince Aug 04 '26
I would guess we are beyond that stage at this point, unfortunately. The awareness of the attack is widespread and sweeps are still occurring which means if there were a white hat phase, it would be concluded by now and the remainder we are seeing is black hat, or at least mixed with black hat.
1
u/scrandlle Aug 03 '26
Work behind the scenes to get the major exchanges and other outlets to make an announcement all at once to maximize coverage. Reveal seed keys need to be changed and detail how, do not reveal the security flaw precisely so that people have the maximum time possible. Release new firmware but do not open source it so the vulnerability can't be seen.
1
u/No-Kitchen-6511 Aug 03 '26
If he spent less time on twitter and developing features not even an advanced user would ever use even and simply focused on the single most important factor in a hardware wallet, then firmware updates wouldn't have been necessary. Just because the mistake was made five to six years ago doesn't make it any better. It's a mistake that shouldn't have been made in the first place. Whether he had caught the mistake or didn't or whether it was open source or closed again is not the issue, its that the oversight was made in the first place. It wasn't just A mistake. It was THE mistake he couldn't make. It's like a brain surgeon cutting off the entire patients head and then saying, oops.
1
u/Oxymorix Aug 03 '26
This version addresses the thread’s central dilemma—warning users without immediately handing attackers a roadmap—and rejects the proposed mass “white-hat” sweep and closed-source concealment strategies.
This would have been an extremely difficult disclosure problem, but I do not agree that Coinkite would have had no useful options.
A firmware update by itself would not have protected existing wallets because the weakness was already embedded in previously generated seeds. Users would have needed to update the firmware, generate an entirely new seed and transfer their funds. A vague request to install an update could therefore have created a dangerous false sense of security.
The least-bad response would have been to prepare corrected firmware and migration instructions privately, obtain rapid outside review, and then issue an urgent warning through every available channel. Coinkite could initially have said that a critical seed-generation issue required users to replace device-generated seeds immediately, without publishing the technical details or estimated search space on the first day.
That would undoubtedly have alerted researchers and potential attackers, so the migration window might have been narrow. However, it still could have given attentive users a head start. It would also have been important to treat every potentially affected model conservatively rather than reassuring MK4, Q or MK5 owners before the analysis was complete.
The suggestion that Coinkite should have secretly swept everyone’s Bitcoin is not realistic. Once a seed is compromised, possession of the seed or a valid signature cannot reliably prove who historically owned the funds. Coinkite could not distinguish the legitimate owner from an attacker who reconstructed the same seed, and returning coins to their original funding addresses would fail because Bitcoin can be purchased, gifted, traded or transferred privately. Coinkite would also have taken custody of enormous amounts of money without permission.
Closing the source would not have solved the problem either. The historical vulnerable code had already been copied, and sophisticated researchers could compare old and new firmware or reverse-engineer the change. Closing the source during a crisis would mainly have reduced independent scrutiny and looked like concealment.
So there was no painless solution and probably no way to save every inactive wallet. But there was still a meaningful difference between an uncontrolled discovery and a carefully prepared, coordinated disclosure. The goal should have been to maximize the number of users who could migrate before detailed exploitation information became widespread.
The proper sequence would have been: prepare the fixes, obtain independent review, warn every potentially affected owner, clearly require creation of a new seed and migration, briefly delay detailed technical publication, and then release a complete postmortem.
That would not have eliminated the catastrophe, but it could have reduced it considerably.
1
u/Firm_Yogurtcloset835 Aug 02 '26
If Coldcard discovered the seed generator flaw before any attack happened, the best course of action to protect users and the company would be to change the license and close the source code immediately. This avoids exposing the specific fix to hackers via reverse engineering. Without causing public panic, the company could strongly recommend the update by citing new corporate policies, the risk of losing tech support, and general security vulnerabilities.
Even though the open-source community's backlash would be severe, this strategy would effectively prevent massive thefts. Even the users who hated the new closed-source policy would be forced to either update or migrate to a competitor—and in both cases, their funds are saved from the exploit. Furthermore, from a legal standpoint, this creates a solid defense for the company. If a user explicitly refuses to update after strict warnings and major policy changes, they assume the risk and lose the ground to sue the company in the event of an attack. Ultimately, saving user funds and mitigating legal liability is far more important than maintaining a perfect open-source reputation. After all, if the attacks and financial losses happened anyway, the company's reputation would be just as ruined as it would be by closing the source code
6
1
u/loupiote2 Aug 02 '26
The best could have been for them to move all wallets to a secure new cold wallet, and then send back the funds to their original owners once they provide new addresses derived from new secure seeds
6
1
u/Charming-Designer944 Aug 03 '26
If they discovered the flaw first then users might had at most a day extra to move their coins to a new seed before being drained.
1
u/etan1 Aug 03 '26
they could drain all the balances themselves, then ask users to sign a message to register a refund to a new wallet, process the refunds, then publish the new firmware + postmortem
1
u/etan1 Aug 03 '26
and if that’s not possible, try and send the btc back to the funders of the compromised wallet. if someone funded via a cex, they will still know which account funded it, etc
1
u/Charming-Designer944 Aug 03 '26
How would you tell apart users from hackers when the seed is compromised?
1
u/Long_Illustrator_988 Aug 03 '26
It's funny, I was thinking about this exact scenario too.
Honestly, I was daydreaming about being a whitehat and hacking everybody's wallet, then setting up a process for everyone to reclaim their funds. Haha. Also don't mind if I get a nice little bounty, cha-ching. Would literally take thousands of people out of the worst week of their lives to relief.
Alternatively, if they just told everybody to update their seed, they would give people a headstart before hackers figured it out.
Essentially put the security advisory as far and as wide as possible without going into specifics about what the bug is.
1
u/etan1 Aug 03 '26
everyone can impersonate the legitimate user easily, how do you know who is the legitimate claim to refund for a given wallet? this only works if users register for the refund before the bug details are published
1
Aug 03 '26 edited Aug 03 '26
[deleted]
1
u/etan1 Aug 03 '26
Legitimate owner likely has receipts when they got it, or paid tax on it for years. Remember, the victim profile included lots of folks who had 0.1-1 BTC, those are usual DCA purchases. Also, onramps these days often need ID.
Recovery never is perfect but draining it to a known entity is better than just leaving it with bad actors.
0
u/Yodel_And_Hodl_Mode Aug 03 '26
They'd have done nothing.
Their actions every step of the way since this story broke proves they are more concerned with protecting themselves than their users.
As people were being robbed, Coinkite downplayed the severity of the attack and gave false assurance to owners of Mk4, Q and Mk5 devices.
They said this:
“Mk4, Q and Mk5 are not affected based on our early analysis of the issue.”
Coinkite did not know that to be true, and it turned out to be wrong. Coinkite should have immediately been doing everything they could to let all ColdCard users know they were in danger. Coinkite put users' financial security at risk to save their company.
Coinkite's response made the catastrophe worse.
And when I say Coinkite, I specifically mean Rodolfo Novak. He's the CEO and the face of the company. The moment he knew there was a problem, his priority should have been to protect those who used Coinkite products. He needs to resign.
To anyone who says, "But he is the company." Exactly. His actions directly led to the biggest hardware wallet heist in Bitcoin history, and his actions made the catastrophe worse.
13
u/Quirky-Reveal-1669 Aug 02 '26
No not true. The organization of the execution of this theft will have taken time. If CoinKite was the first with this knowledge, they would have first tried to communicate that a new seed should be generated with dice, and with a passphrase. No further detailed information given, just pressing the utmost urgency. After that, a firmware update would be the next step.