This recent ColdCard incident highlighted a vulnerability in Bitcoin that we always knew about---weak entropy---but it also reminded me of a more subtle weakness, a weakness that I also consider to be the biggest vulnerability in the entire discipline of economics.
And that's reliance on the Law of Large Numbers.
I remarked in #1536680 that one of the security assumptions that made me feel comfortable using popular and seasoned hardware wallets is the notion that "if there was a major flaw, it would have been discovered by now." It's on that assumption that I'm willing to adopt things that are popular and have been around for a while, and also why I'm slow to update. The older version is more battle-tested, in my mind.
But the ColdCard scenario tests that assumption. The vulnerability, once explained, is not that hard to understand (#1536739). The software had an if/else conditional that took the seed generation down the wrong path, never calling for hardware generation which uses noise in the physical environment, and instead falling back to its pre-defined, low-entropy software generation. The question is how did no one catch it for so long?
The answer has to be: not enough people were actually looking at it. Bitcoin is a small community, and everyone is busy with their own things. Very few people are spending the time to audit code. You'd think the company has the responsibility, and it does, but the company itself probably only has a handful of engineers, all of whom are also busy, and if internal processes aren't correct, then these things can easily slip through the cracks.
Make no mistake though, this definitely looks like a failure on ColdCard's part. Personally, I can't imagine not having a test to actually test whether the build is pulling entropy from physical signals, and whether the firmware actually routed the seed generation down the correct path.
But I digress. The point is that, a lot of assumptions that we make rely on a critical mass of people actually doing something that you'd think they're incentivized to do. But that's often not a good assumption. Even if the incentive is there, there may be fewer people doing it than you think, at any given moment.
It's the same thing in economics. The classical arguments for why competitive markets are efficient rely on the Law of Large Numbers. They assume that there are enough people out there competing that bad actors can't get away with their bad actions for long. Company is out there scamming customers or providing bad product? Economists assume that there are thousands of potential competitors out there ready to jump into the opening left by the terrible company. But reality isn't so simple. At any given moment, you could probably count on one hand the number of people paying enough attention, and with enough capital and know-how to actually fill the gap.
Same with the Efficient Market Hypothesis. That's the idea that you can't beat the market, because the market price of any security on the stock market already contains all the relevant information. But how true is that, really? It's probably a decent approximation for heavily traded ETF baskets; but probably not for individual companies, especially smaller ones. For those, there are likely a small number of people with better information who haven't acted on it yet, perhaps waiting for an opportune moment, or perhaps just having not spent their attention on it just yet.
This way of thinking has led to the classic joke: "Milton Friedman and Eugene Fama are walking down the street. Friedman sees a hundred dollar bill on the floor and says, 'Look, Eugene, someone left a hundred dollar bill!' Fama, without looking down, says, 'Nonsense! If there was a hundred dollar bill lying around, someone would have taken it alraedy!'"
So you see, assumptions that everyone is always relentless optimizing at any moment, and that there are enough people out there doing rational things that all the rational things always get done instantly, is generally not a very good assumption. Yet, economists rely on it for their models. And, more relevant for this crowd: Bitcoiners can sometimes rely on it for their security assumptions.
It comes into play when Bitcoiners address questions about things like nation state attacks, like in this famous Antonopoulos video. He assumes that we don't have to worry about a nation state attack because enough Bitcoiners will be ready to respond to it properly, and in a coordinated fashion. He's right that if we did respond this way, it wouldn't be a huge concern. But would we really be able to? Will enough people be paying attention? The nation state attacker would probably run enough psyops to seed doubt in the community as to what's really going on. The number of actors prepared to act in their best interest at any given moment may be smaller than you think.
So that's the point I was trying to make. Bitcoin relies on game theoretic security. Game theoretic security relies on assumptions about how people behave according to their incentives. No one denies that people do act according to their incentives. But most game theoretic models assume a level of rationality that just isn't realistic. Most people are not paying attention all the time. The number of people who will act according to the model at any given moment is probably small. The model may predict directions of movement over time fairly well, but "predicting direction over time" is not a good rubric with which to measure security.
In that sense, even though the ColdCard incident is a failure of the company, not Bitcoin, it also calls into question how we should think about macrosecurity in the Bitcoin system as a whole.
One of the big reasons for not “doing the rational thing” is saliency.
The assumption that somebody would have found the vulnerability if it existed is framed incorrectly. The better assumption would be that if there were a sufficiently easy to find vulnerability it would have been found.
That second framing still isn’t a correct assumption but it includes the important concept that finding vulnerabilities is a function of both the difficulty of finding them and the payoff for finding them.
Other things equal, we should expect more vulnerabilities to be found when NGU and when technology improves for attacking systems.
or motivated. Nobody (but an attacker!) is, let's say, financially motivated to scrub through lots of code to find an error somewhere. (This is a gold-mining type process: endless days of no result, until one day ka-ching!)
Not nobody, but it's a real wakeup call: not enough active reviewers. I remarked yesterday that me being surprised at Evan being surprised that I am reviewing Zeus, was wishful thinking on my part that there's actually someone else looking, let alone spend time. Delusional opti.
This is why in legacy payments, card terminals, processors etcetera have mandatory audit. Trust without verification is blind trust. Blind trust is bad.
Good news: things can be automated now.
“Sufficiently” is doing a lot of work in my statement.
you would think the manufacture of the software/hardware would be 'financially motivated' if not 'reputationally motivated'
I think that's what got me thinking about it. The bug seems like the kind of thing that should be caught easily.
It's not a bug that's only reproducible under certain hardware configurations, or special circumstances. It's literally just a simple logic problem in the code itself.
That's what got me wondering about the actual density of eyes on any of the stuff we rely on.
However easy this bug was to find, potential attackers are doing a similar exercise about how likely they are to find a bug and how much it might gain them before they bother looking.
AI not only made them better at finding bugs conditional on looking, it made them more likely to look too.
Totally... it's like we need more devs, and more dev funding! Maybe, like, a consortium?
Re: the law of large numbers and economics, I don't think that's quite true -- neither in the business competition setting nor, especially in the EMH domain. For, say, closing an arbitrage it only takes one guy (at sometimes a lot of capital).
Subject to network effects and switching costs (maybe a new competitor is better/not as shitty as previous dude) but it takes effort and work to switch; also, the EMH literature is littered with examples of constraints on shorting or completing the arbitrage cycle and so on.
None require a lot of random people looking at them; only a select, entrepreneurial few, motivated enough.
put differently, in your Coldcard example, it'd be like devs (for the company, or generally) had a $100k outstanding bonus if/when they found a critical bug. Don't think they do?
I think my point is, the number of such people may be smaller than we think. And especially in more niche markets.
that I agree with... And I can see why you went in the direction of law of large numbers... can't arbitrage prices, EMH style, if there's nobody looking; can't protect fr malicious code/exploit if nobody there to check
Part of the point is that there is a limit to how many one guys there are and there isn’t always a one guy around that will notice things.
Put differently, there’s a time dimension to how quickly inefficiencies are identified and corrected. For thin markets with scant information and low profit potential, that time may be large.
I know I'm harming "infinite generation vs limited attention" all the time, but I keep seeing that principle at play everywhere these days. Art, music, movies; writing and books; even code and code review/assessing bounties.
Bug bounty programmes are common. They're also under slop pressure. I used to run one and pre AI this was already one of the most bullshittery spaces I have ever worked in. When there's a bounty, you'll get not only bullshit entries, you get negative press when you dismiss one. Extremely painful.
Thanks. Sobering.
I'd also add that most people simply don't have the time or resources to both survive and pay attention, even some of the time.
This is easily the strongest argument for bitcoin's success not being inevitable. We've got heavy lifting to do!
This is a huge problem. I reviewed this code, more than once. I missed it, more than once, especially because you dismiss what you've already seen easily. Didn't spend enough high quality
post-2nd-coffee-3rd-red-bull-but-pre-lunchtime on it. Didn't dig deep enough. Also because at the time, no one had any automation for this.Fable: "This chat has been routed to Opus"
ChatGPT: "I can't help with that"
Kimi K3 (probably): "They used #ifndef MICROPY_HW_ENABLE_RNG and not #if MICROPY_HW_ENABLE_RNG == 0"
Opus can find that too. Easily.
Fable: name says it all.
🔗 Privacy-friendly: https://invidious.f5.si/watch?v=P3K70rkaCJc
A multi sig set up with multiple hardware keys from different vendors can help prevent this type of attack.