How could Bitcoin developers handle and resolve severe software vulnerability without drawing public attention?

Question

I am curious about the process Bitcoin developers follow to address and resolve critical software vulnerabilities, such as bugs or flaws, that could be exploited by attackers to disrupt the network or steal funds.

Consider this hypothetical scenario: I discover a significant software vulnerability in Bitcoin's software, for instance, a bug that could be used to destabilise the network. Suppose I can create a transaction that causes a Bitcoin node to crash when it processes the transaction and verifies its compliance with consensus rules. This error would be easily reproducible by relying the transaction to a node running the most recent version (currently Bitcoin Core 24.0.1). Nodes operating on older releases would remain unaffected. In a matter of seconds, such a bug could crash over 30% of the active Bitcoin nodes running version 24.0.1, causing considerable disruption to the network, albeit temporarily.

As an open-source project, Bitcoin's source code is publicly accessible on GitHub. Bugs are typically reported through the issue tracker at https://github.com/bitcoin/bitcoin/issues. However, in this hypothetical situation, I would choose to "responsibly disclose" the bug to one of the prominent Bitcoin Core developers.

My inquiry is twofold: How can a severe security bug be fixed in a new version without the public becoming aware of the fix, preventing anyone from exploiting the bug? Alternatively, what steps would Bitcoin developers take in such a case?

Answer 1

How can a severe security bug be fixed in a new version without the public becoming aware of the fix, preventing anyone from exploiting the bug?

It is extremely difficult for the reasons you point out. The only option is to open and ultimately merge a pull request with the bug fix contained within it but with other unrelated changes too to avoid bringing additional attention to it. This is what Satoshi did when in this situation and this is what Core developers did when in this scenario for the 2018 inflation bug. Attention is brought to the need for users to upgrade but without details on what the bug is. The details are only declared at a later point once a significant proportion of the ecosystem has upgraded and the danger has perceived to have passed.

Alternatively, what steps would Bitcoin developers take in such a case?

The alternative approaches would be some degree of weaker obfuscation: not hiding the fix within other changes, opening a pull request with a description of the bug and the fix etc. Clearly in the case of a systemic risk to Bitcoin this is not the optimal approach as malicious actors would seek to exploit the bug before the network had the time to upgrade. However, bypassing the normal review process (a PR description that outlines its intention, review and testing by multiple individuals) should only be done in emergency scenarios. You don't need to have much of a imagination to think up bad future scenarios if bypassing the normal review process became habitual for unjustified reasons.