Coldcard漏洞揭示开源与源码可用差异及比特币软件激励

Bitcoin Magazine

Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives

Closed versus Open Source code has divided the Bitcoin and broader crypto industry for well over a decade. Bitcoin advocates have long argued that the financial infrastructure of the world should be built in public. Transparency and auditability, they say, are non-negotiable when real money is at stake. Yet the app and legacy layers of finance often disagree.

Yet the recent Coldcard hack, a popular self-custody hardware wallet where users lost over $100 million worth of bitcoin (more than 1,500 BTC), cast doubt over what “Open Source” actually means. It revealed that perhaps most people, even many hardcore bitcoiners, are poorly educated on the Open Source software development philosophy and when it fails.

The Principles and Terminology

The language around Open Source can be complicated. Free and Open Source Software (FOSS) and Free/Libre and Open Source Software (FLOSS) refer to software that meets formal definitions of user freedom.

The Free Software Foundation (FSF) defines free software through four essential freedoms:

• Freedom 0: The freedom to run the program as you wish, for any purpose.
• Freedom 1: The freedom to study how the program works, and change it so it does your computing as you wish (access to the source code is a precondition for this).
• Freedom 2: The freedom to redistribute copies so you can help others.
• Freedom 3: The freedom to distribute copies of your modified versions to others (access to the source code is a precondition for this).

The FSF emphasizes that “free” refers to liberty, not price, in a common quote heard from FOSS advocates: “‘free’ as in ‘free speech,’ not as in ‘free beer.’”

The Open Source Initiative’s Open Source Definition adds ten practical criteria. These include free redistribution without royalties, availability of source code in the preferred form for modification, the right to create and distribute derived works, and no discrimination against persons, groups, or fields of endeavor — including commercial use. A license must meet all ten criteria to qualify as Open Source under the OSI standard.

“Source available” or “source viewable” is different. Code may be publicly readable while the license restricts the right to sell it. Coldcard’s firmware, for example, is released under MIT terms plus the Commons Clause. The Clause specifically removes the right to “Sell” the software — defined as providing it to third parties for a fee or other consideration in a product or service whose value derives entirely or substantially from the software itself. In other words, Coldcard’s firmware could not be used commercially.

The Commons Clause’s own FAQ states the difference explicitly: “Is this ‘Open Source’? No.” It notes that applying the clause means the software meets many elements of the Open Source Definition but not all of them, and therefore should not be called Open Source.

These distinctions matter. Publishing source code creates the possibility of inspection. Granting the full set of rights defined by the Free Software Definition or the Open Source Definition is what makes software FOSS or FLOSS. But having the badge of approval, being able to wave a FOSS or FLOSS flag, is not the point. Commercial liberty in FOSS unlocks third-party incentives to test and review code that might otherwise not be there, critics argue.

The four freedoms form the philosophical core of Open Source. In practice they rest on an economic assumption: that enough motivated people will actually examine the code. When that assumption fails, the system produces a classic tragedy of the commons, a situation where a shared resource is overused or neglected because individual users act in their own short-term self-interest rather than in the long-term interest of the group.

Each person has an incentive to take more (or contribute less) than is sustainable, and the resource degrades as a result. This happens when there is misalignment between the short-term self-interest of the individual and the long-term interest of the group. Sometimes alignment exists; sometimes it does not.

One Bitcoin developer put the problem bluntly: “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.”

As a result, Open Source does not create safety by itself. It creates the possibility of verification. Whether that verification occurs depends on incentives, skill, and attention. Historical FOSS is believed to harden over time as vulnerabilities are discovered, disclosed and patched, creating solid foundations others build on top of. The Linux kernel is a great example of such hardened FOSS; it powers the vast majority of the world’s servers, cloud infrastructure, Android devices, and embedded systems, making it one of the most widely deployed pieces of software in history.

Open Source as Demonstrated by Bitcoin Core

Bitcoin Core, the reference implementation of Bitcoin, is another prescient large-scale example of pure open-source functioning in the wild. The software, which runs behind most Bitcoin-related infrastructure, is released under the MIT license. Its development process is broadly public by design.

Anyone can open a pull request. Code review is the primary filter and the recommended entry point for new contributors. Reviewers use a formal vocabulary—Concept ACK (acknowledgment and agreement with the goal), Approach ACK (agreement with the goal and method), ACK with a specific commit hash (tested and approved for merge), or NACK (disagreement, which should be accompanied by technical reasoning).

Maintainers weigh consensus among contributors and the technical merits of a change before merging. Consensus-critical changes face a still higher bar and usually require a Bitcoin Improvement Proposal and extensive multi-year discussions on the bitcoin-dev mailing list and IRC.

There is no privileged caste of “Bitcoin Core developers.” Trust is earned through demonstrated competence over time. Maintainers exist for practical reasons—auditing and merging code, managing releases, and basic moderation—but the work produced is pure open-source code that anyone can inspect, build, fork, or run. Developers who get code ‘commits’ merged into Bitcoin Core are broadly called Bitcoin Core Contributors.

Calle, a long-time open-source Bitcoin developer, summarized the reality recently: “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 work comes largely through nonprofit and grant structures such as Brink, OpenSats, Spiral, and others rather than a traditional company product roadmap. Technical discussion and debate take place 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 carry comment histories stretching back a decade. The result is a development culture optimized for correctness and auditability rather than speed or commercial feature velocity.

The Economics of Open Source

Most users of open-source or source-available software never read the code themselves. They rely on the assumption that others are examining it. In the Coldcard case, a critical entropy flaw remained in publicly available firmware for roughly five years before it was exploited and thus discovered.