A Security Disclosure Lands: How to Tell Severity From Noise

“Bitcoin vulnerability” is a phrase that spans four very different situations. Sorting out which one is in front of you resolves most of the panic.

Four layers, four blast radii

A consensus flaw — something allowing invalid blocks to be accepted or the supply schedule to be violated — is the only genuinely systemic case, and is extremely rare. An implementation bug affects users running a particular client version; the protocol is fine and the fix is an upgrade. A wallet vulnerability affects users of that wallet, often requiring specific conditions. A service breach is a company being compromised, which says nothing about Bitcoin at all.

What responsible disclosure looks like

Serious findings are usually reported privately, patched, deployed, and only then described publicly — often with details withheld until adoption is widespread. A public announcement with dramatic framing and no patch available is a weaker signal than a quiet advisory accompanied by a released fix.

Questions that separate the cases

Which software and which versions? Is a patch available and deployed? What conditions must hold for exploitation — physical access, a malicious counterparty, a specific transaction type? Has anyone lost funds, or is it theoretical? And critically: does this affect coins held in self-custody with an updated client, or only a particular service?

The recurring answer

Most “Bitcoin hacked” headlines describe a company being compromised. That is a real event with real losses for real people, and it is worth reporting — but it is a custody and corporate-security story, not a protocol one. Conflating them makes readers less able to assess risk, not more.