Quis verificat ipsos verificatores? Community criteria

Over the past few days, I prepared a meetup presentation for

about the Coldcard incident. Like many others, I began exactly where the discussion had already begun: reading about the entropy bug, the pseudo-random number generator, vulnerable firmware versions, and the technical details behind the flaw. I assumed I was preparing a talk about cryptography.

Check the presentation for Bitcoin Para Todos [SPA]

Instead, I ended up giving a talk about economics. Somewhere along the way, I found myself asking a question that seemed far more interesting than the vulnerability itself: who actually had an incentive to review that code? That single question completely changed the direction of my presentation.

That's me, showing the Coldcard (RIP) and talking about licenses

Bitcoin is first...incentives

One of Bitcoin's greatest innovations isn't purely technical. We often describe it as a breakthrough in cryptography or distributed systems, but I think its true achievement lies elsewhere. Bitcoin is an incentive machine. Miners secure the network because they're economically rewarded for doing so. Nodes enforce consensus rules because rejecting invalid blocks ultimately protects their own interests. Users are encouraged to protect their private keys because nobody else can recover their funds.

Bitcoin works because it aligns incentives remarkably well. Yet when we discuss the software ecosystem surrounding Bitcoin, we often stop applying the same reasoning. Developers respond to incentives. Auditors respond to incentives. Companies respond to incentives. Communities respond to incentives. Software doesn't exist in a vacuum; it exists inside an economic environment, and that environment influences how much attention, scrutiny, and maintenance the software ultimately receives.

Can someone audit my work sir?

One misconception that became apparent while preparing the talk is the belief that open-source software somehow audits itself. We frequently hear that "the code is public, so thousands of people can inspect it." While technically true, I think that statement is incomplete. Open source means that anyone can review the code. It does not mean that anyone actually will. Reading thousands of lines of unfamiliar source code requires expertise, time, and motivation.

There you have it, it's

talking about our community and sponsors

Most people don't spend weeks auditing a project simply because they appreciate transparency. They do it because there's an incentive. Perhaps they're building a competing product. Perhaps they're conducting academic research. Perhaps they're performing a professional security audit. Or perhaps they're simply curious enough to dive into the internals. Whatever the reason, the point remains the same: open source creates the possibility of review, but incentives determine whether that possibility becomes reality.

This perspective led me to think about one of the most discussed aspects of the Coldcard story: the licensing changes. I'm deliberately avoiding the debate over whether moving away from GPL was right or wrong. That question is less interesting to me than another one. What incentives changed after that decision? Restricting commercial reuse doesn't automatically make software less secure, nor does it magically introduce vulnerabilities. But it undeniably changes the economic landscape surrounding the project.

First, we made a little intro by

If fewer companies benefit from studying the code, fewer companies may decide to dedicate engineering resources to understanding every implementation detail. If fewer developers can build commercial products on top of that work, the motivation to perform deep reviews may also change. To be absolutely clear, I'm not claiming that licensing changes caused the Coldcard vulnerability. I don't believe the available evidence supports such a conclusion. What I am suggesting is much more modest: incentives changed, and in Bitcoin, incentives are rarely an irrelevant variable.

The community's reaction was equally fascinating. As expected, the conversation quickly split into opposing camps. Some concluded that the incident proved self-custody had failed. Others argued that no serious Bitcoiner should ever have trusted a hardware wallet's random number generator and that everyone should instead generate entropy manually using dice or other independent methods. I don't think either position captures the real lesson.

The first confuses a failure in one implementation with a failure of Bitcoin itself. The second risks transforming an advanced security practice into the minimum acceptable standard for every user. Security is rarely that binary. The real challenge isn't deciding who deserves blame. The real challenge is building tools that are secure enough for ordinary users while still allowing advanced users to adopt stronger threat models whenever their circumstances require them.

Preparing this presentation also made me rethink one of Bitcoin's most famous principles: Don't Trust. Verify. It's a phrase that has inspired countless people, myself included. But perhaps we sometimes interpret it too literally. Bitcoin doesn't eliminate trust. It redistributes it. We still trust compilers, hardware manufacturers, cryptographic libraries, silicon vendors, and countless other components that make modern computing possible. The objective isn't to eliminate trust completely—that would be impossible. The objective is to minimize unnecessary trust and make independent verification feasible whenever practical. Yet there's an important distinction that I think we sometimes overlook: something being verifiable is not the same thing as someone actually verifying it.

After my presentation, several colleagues gave a practical demonstration on generating entropy with dice. I thought it was excellent. More people should understand how entropy works and why it matters. But I walked away thinking less about the technical demonstration and more about the broader lesson. Human systems behave remarkably like economic systems.

Roll the dices and make your entropy sir

People respond to incentives. Developers do. Auditors do. Companies do. Entire communities do. Perhaps the most important question raised by the Coldcard incident isn't who introduced the bug or who failed to detect it. Perhaps the more uncomfortable question is whether we've built communities where verification remains continuously incentivized, or communities where everyone quietly assumes someone else has already done the hard work.

That question extends far beyond Coldcard. It applies to open-source software. It applies to governance. It applies to every collaborative project that depends on voluntary review and shared responsibility. And it certainly applies to Bitcoin. Long after the technical details of this vulnerability fade from memory, I suspect this will be the question that stays with me:

Quis verificat ipsos verificatores?

Who verifies the verifiers?

Published first at https://stacker.news/items/1541415