The long-standing debate surrounding closed versus open-source code has been a defining characteristic of the Bitcoin and broader cryptocurrency industry for over a decade. Proponents of Bitcoin have consistently advocated for building the world’s financial infrastructure in the open, emphasizing that transparency and auditability are paramount when significant financial assets are involved. However, the practicalities of application and legacy layers within the financial ecosystem often present a differing perspective. The recent Coldcard hack, which resulted in the loss of over $100 million worth of Bitcoin—exceeding 1,500 BTC—from users of this popular self-custody hardware wallet, has cast a harsh spotlight on the nuanced meaning of "Open Source." This incident has revealed a potential widespread misunderstanding, even among many dedicated Bitcoin enthusiasts, regarding the principles of open-source software development and the circumstances under which it can falter.
Understanding Open Source Principles and Terminology
The discourse surrounding open-source software can be intricate. Free and Open Source Software (FOSS) and its variant, Free/Libre and Open Source Software (FLOSS), denote software that adheres to specific definitions of user freedom. The Free Software Foundation (FSF) elaborates on the concept of "free software" through four essential freedoms:
- The freedom to run the program as you wish, for any purpose (freedom 0). This means users can operate the software for any objective, without restriction.
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2). This allows users to share the software freely with others.
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this, you can give the whole community a chance to benefit from your changes.
The FSF consistently clarifies that "free" in this context refers to liberty, not price, often drawing a parallel to the distinction between "free speech" and "free beer."
The Open Source Initiative (OSI) further refines this with its ten-point Open Source Definition. These criteria encompass principles such as free redistribution without royalties, the availability of source code in a modifiable form, the right to create and distribute derivative works, and the absence of discrimination against individuals, groups, or fields of endeavor, including commercial use. For software to qualify as Open Source under the OSI standard, its license must satisfy all ten criteria.
A critical distinction arises with terms like "source available" or "source viewable." In these scenarios, the source code might be publicly accessible, but the accompanying license imposes restrictions on its commercial use or redistribution. Coldcard, for instance, released its firmware under the MIT license, augmented by the Commons Clause. This clause explicitly prohibits the "Sell" of the software, defining it as providing it to third parties for a fee or other compensation within a product or service whose value is substantially derived from the software itself. Essentially, this restriction meant Coldcard’s firmware could not be commercially exploited.
The Commons Clause’s own frequently asked questions section directly addresses this: "Is this ‘Open Source’? No." It acknowledges that while such software may meet many elements of the Open Source Definition, its failure to meet all of them disqualifies it from being labeled "Open Source."
These distinctions are not merely semantic; they carry significant practical implications. The mere act of publishing source code creates the possibility of inspection. However, it is the granting of the full spectrum of rights outlined by the Free Software Definition or the Open Source Definition that truly designates software as FOSS or FLOSS. Critics argue that the true value of open source lies not just in the "badge of approval" but in the commercial liberties it unlocks, which in turn incentivize third-party engagement and review that might otherwise be absent.
The four freedoms championed by the FSF form the philosophical bedrock of open source. In practice, these freedoms rely on an economic assumption: that a sufficient number of motivated individuals will actively examine the code. When this assumption proves unfounded, the system can devolve into a "tragedy of the commons." This occurs when a shared resource is depleted or neglected because individual actors prioritize their short-term self-interest over the collective long-term good. Each participant may be incentivized to extract more value or contribute less than is sustainable, leading to the degradation of the resource. This dynamic arises from a misalignment between individual short-term gains and the group’s long-term interests.
One Bitcoin developer succinctly articulated the challenge: "Using mocks and stubs of Open Source code in tests is irresponsible and shortsighted. Open Source code is considered safe because anyone can verify it. If you aren’t willing to do the bare minimum of testing the features you actually depend on, then you are behaving like a leech." Consequently, open source does not inherently guarantee safety; it creates the potential for verification. Whether this verification materializes hinges on a confluence of incentives, expertise, and attentiveness. Historically, FOSS projects are believed to strengthen over time as vulnerabilities are identified, disclosed, and patched, forming robust foundations upon which others can build. The Linux kernel stands as a prime example of such hardened FOSS, powering a vast majority of the world’s servers, cloud infrastructure, Android devices, and embedded systems, solidifying its status as one of the most widely deployed software in history.
Bitcoin Core: A Paragon of Open Source Development
Bitcoin Core, the reference implementation of the Bitcoin protocol, serves as another compelling, large-scale demonstration of pure open-source principles in action. The software, which underpins most Bitcoin-related infrastructure, is distributed under the permissive MIT license, and its development process is intentionally designed for broad public participation.
The development workflow is structured to allow anyone to submit code changes through pull requests. Code review is the primary mechanism for vetting contributions and is the recommended entry point for new developers. Reviewers employ a formal vocabulary to express their assessment: "Concept ACK" (acknowledging and agreeing with the proposed goal), "Approach ACK" (agreeing with both the goal and the method), "ACK with a specific commit hash" (indicating tested and approved code ready for merging), or "NACK" (disagreeing, with a requirement for technical reasoning).
Maintainers then weigh the consensus among contributors against the technical merits of a proposed change before approving it for merging. Changes that are critical to consensus undergo an even more rigorous process, typically requiring a Bitcoin Improvement Proposal (BIP) and extensive multi-year discussions on the bitcoin-dev mailing list and IRC.
There is no exclusive "Bitcoin Core developer" caste; trust and authority are earned through demonstrated competence over time. Maintainers exist for practical reasons—auditing and merging code, managing releases, and moderating discussions—but the output remains pure open-source code, freely inspectable, buildable, forkable, or runnable by anyone. Developers who successfully have their code merged into Bitcoin Core are broadly referred to as Bitcoin Core Contributors.
Calle, a veteran open-source Bitcoin developer, recently commented on this transparency: "People who think that core is some sort of intransparent institution operating in the shadows are either too lazy or too dumb to go have a look for themselves. Literally everything they do is public, anyone can chime in, and the result of their work is pure Open Source code." Funding for this crucial development work primarily flows through non-profit and grant structures like Brink, OpenSats, and Spiral, rather than through traditional corporate product roadmaps. Technical discussions and debates unfold publicly on the bitcoin-dev mailing list and in the #bitcoin-core-dev IRC channel on Libera Chat, where proposals are scrutinized before and during the pull-request process. GitHub issues and pull requests often feature comment histories spanning a decade, fostering a development culture that prioritizes correctness and auditability over rapid feature deployment or commercial velocity.
The Economic Underpinnings of Open Source and the Coldcard Incident
The vast majority of users of open-source or source-available software do not personally examine the code. They operate under the assumption that others are diligently performing this review. In the case of Coldcard, a critical entropy flaw persisted in its publicly available firmware for approximately five years before it was exploited and subsequently discovered.
This vulnerability was introduced into the codebase during a significant rewrite in 2021, which also involved the removal of remaining GPL-derived code from Trezor, the pioneering hardware wallet and now the second-largest player in the self-custody market. The library at the heart of the entropy failure, which replaced trezor-crypto, is known as libngu. This library had minimal external scrutiny, boasting only seven stars and fewer than twenty forks on GitHub over its five years of use in a production environment. This starkly contrasts with the trezor-crypto library, which had 512 stars and 212 forks, or the trezor-firmware repository, which had 793 forks and 1,800 stars. The availability of source code alone did not ensure the necessary review, particularly, critics argue, because for-profit, well-funded companies were legally restricted from commercially utilizing it.
The stakes are considerably higher in the Bitcoin ecosystem than in many other software domains. A critical flaw can be directly translated into liquid funds on the open market. While the initial tranche of Coldcard funds stolen remains in a handful of addresses, and the perpetrator may eventually be apprehended, subsequent copycat attackers have demonstrated greater caution. According to Galaxy Research, some have successfully stolen and laundered even larger amounts of Bitcoin. Bitcoin’s inherent censorship resistance and immutable transaction history create a powerful incentive for attackers and a Darwinian filter: only projects that consistently attract competent review, and users and companies that implement stringent precautions, are likely to endure over the long term.
Licensing choices, according to FOSS advocates, significantly shape these incentives. Pure open-source licenses maximize the pool of potential reviewers and forks. Conversely, restricted "source available" licenses, while potentially mitigating commercial "free-riding," can also narrow the circle of individuals possessing both the legal right and the economic motivation to invest deep scrutiny. Under such restrictive licenses, the burden of code review effectively reverts to the company, placing it, in essence, closer to a closed-source model.
The Evolving Landscape: AI and Open Source
The advent of artificial intelligence is now fundamentally altering the balance between FOSS and closed-source development. Following the Coldcard incident, a volunteer initiative known as the Bitcoin Red Team—spearheaded by developers including Calle and Rob Hamilton of AnchorWatch, and supported by OpenSats—utilized advanced AI models to scan hundreds of open-source Bitcoin repositories. In a concentrated period, the team identified thousands of findings, including dozens classified as critical or high severity, across numerous projects. These discoveries were responsibly disclosed to maintainers prior to broader publication. This effort underscored the potential for systematic, AI-assisted review to uncover issues with a scale and speed previously unattainable by human teams alone.
Notably, the Red Team reported that open-weight AI models from China proved significantly more reliable in their cybersecurity analysis than closed-source American models. Even with top-tier access and cybersecurity permissions, the latter often refused to engage with the Red Team’s queries—a trend that has reportedly caused consternation among American developers.
Simultaneously, the proliferation of AI-generated code presents a new form of denial-of-service pressure on FOSS maintainers. Reviewing AI-generated output frequently demands more time than its creation. Some open-source projects outside of Bitcoin have resorted to restricting issue trackers or implementing strict anti-AI contribution policies simply to maintain operational functionality.
On the closed-source front, the traditional security advantage of "security through obscurity" is diminishing. Modern AI models possess the capability to rapidly read, de-obfuscate, probe endpoints, and reason about code. The practical distinction between open and closed source is increasingly confined to back-end code that is never exposed online. Consequently, closed-source code now relies predominantly on the quality of professional audits, the speed of patch deployment, and incentive structures that ensure competent individuals remain engaged and vigilant.
Bitcoin and the broader cryptocurrency industry are subjecting free and open-source software to unusual pressures. The confluence of substantial monetary value at risk, adversarial economic dynamics, and AI-scale analysis is compelling software models to evolve. The prospect of reverting to analog, pre-digital systems is an impractical solution for infrastructure that underpins modern society. In this increasingly sophisticated threat landscape, only projects that undergo the most rigorous auditing are likely to withstand the pressures exerted by AI-augmented hackers and the demands of a digital-first financial system.
