> Bitcoin Core has spent more than a century of CPU time fuzzing individual functions and critical components (though oss-fuzz, Fuzzor, bitcoinfuzz and individual contributors), and decades of CPU time simulating small networks of full nodes under test (Antithesis, Fuzzamoto). I can’t establish causality from this alone, but my strong suspicion is that the sustained testing effort is an important reason these projects have become so robust.

Reproducible builds give you a source code -> binary mapping. Without this, any open source project needs to pick a single “trusted” person to produce binaries; where no one else can even double check that person compiled the source code they claimed to have compiled (given no reproducibility). So even if you don’t trust the contents of a binary, reproducible builds still solve the problem of a project deciding which binary to make available to end users, given its source code.

The Bitcoin Core development process and distribution model actually makes it somewhat harder to fix security issues, compared to other serious software distributors. Take Google Chrome as an example. The CVE fixing happy path is to develop and review a fix in private, push that fix to a private repository, and then push auto-updates to any affected users (running any currently supported release). At some point in the future, you can disclose the bug, once your (built in, on by default) telemetry tells you a significant portion, if not all, of your users have upgraded. Bitcoin Core development happens in public. While a small(er) group of developers can receive a report of a security issue, and create a patch in private; at some point, long before any end user could be running a fixed binary, this patch must become public, as part of a Pull Request, opened on github.com/bitcoin/bitcoin/. At that point, it can be seen and reviewed by any person (attacker, regular contributor, or otherwise). This means CVEs must be fixed carefully, you can't open a Pull Request titled "p2p: fix message parsing bug that causes node to crash" with a patch and functional test attached, demonstrating how to exploit the issue; otherwise someone might decide to take down the network that afternoon, for fun. Instead, CVE fixes are generally hidden as parts of other fixes, or refactors, however that is also non-trivial to do. While a small group of developers might be aware of the (hidden) fix, it's possible for any other contributor, or random internet person looking at GitHub, to do code review, and point out when a patch might not only be doing what it claims to be doing; undermining your ability to fix covertly. It's obviously possible to tell more (regular) contributors about a fix; depending on the severity, that comes with more tradeoffs. The fact that CVE fixes may be hidden in refactors, or other innocuous looking changes, is also why it can be harder to backport (i.e take a fix applied to master, and apply it to the 30.x branch) these fixes to already released versions of Core. Release branches only get bug-fixes; someone will ask questions if you open a Pull Request to backport a 15 commit refactor (no-op), to an old stable branch. The difficulty to backport is exacerbated by the fact that backports are already an obvious place for an attacker to look for covert, or exploitable bug fixes. Depending on the severity, it's quite possible that a (very) bad bug, might get fixed in master, released as part of a new major version (i.e v30.0), but not backported to other stable branches, if it's deemed too risky to try and publicly apply those changes to release branches, without making it obvious that a CVE is being patched, and risking it's exploitation, while a significant portion of the network is still vulnerable. Note that at any point, between when the patch is merged to master, and the next major release happens (1.5-5 months), any person may publicly point out that your patch was actually doing multiple things, and undermine your covert fix. They may also reverse engineer the patch, to the point where they can exploit the issue, and do so. All of this work must happen in public, because Bitcoin Cores distribution process, uses reproducible builds. This makes it impossible to ship private code changes in binaries (i.e uploading binaries that contain code that hasn't been made public), because any person can take the publicly available source code, and transform it into the same binaries that are available to download from bitcoincore.org. If at any point, the public source code does not match what is being distributed, alarm bells will ring. The are multiple (non-contributors) that are consistently performing the steps to check that the release source code, exactly matches the release binaries. Bitcoin Core does not ship software with auto-update functionality, and it never will. This means we cannot "push" updates to anybody. Any user of the software, opts-in to updates, at whenever they consider it convenient. Bitcoin Core does not have any form of telemetry, and it never will. Our usage insights come from the public bitcoin network (i.e the user-agent strings of nodes), and are a rough gauge of which versions of the software are most used. There are many trade-offs involved here, fixing security vulnerabilities in Bitcoin Core, is non-trivial, and unlike the happy-path of most other software distrobutors. However it's important that we continue to distribute software in this way.

The @obscuravpn signup flow, is how paying on the internet should work (by default): Identifier -> Options -> Lightning Invoice -> Product