In this article
In 2023, Someone Filed a CVE Against Bitcoin. Bitcoin Core Chose Not to Patch It.
That sentence alone should tell you something about how Bitcoin works.
In December 2023, Luke Dashjr — the lead maintainer of Bitcoin Knots — filed <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50428" title="CVE-2023-50428 NVD Detail" rel="noopener noreferrer" target="_blank">CVE-2023-50428</a> against Bitcoin Core through version 26.0. The vulnerability described a technique that allowed large amounts of arbitrary data to be embedded in Bitcoin transactions, bypassing the datacarriersize policy limit that node operators use to filter out transaction spam.
Bitcoin Core's response? This is not a vulnerability. It's a policy question. We're not patching it.
That disagreement — and what it reveals about Bitcoin's governance — is what this post is about. Not a security alert. Not an emergency. A retrospective on one of the most revealing governance moments in Bitcoin's history.
What CVE-2023-50428 Actually Was
To understand the dispute, you need to understand how Bitcoin nodes manage data embedded in transactions.
Bitcoin has a scripting system. Most transactions use it for basic conditions: "spend these coins if you can prove you own this key." But the scripting system is flexible, and some uses — like embedding arbitrary text or image data — were never the primary intent.
To manage this, Bitcoin Core introduced the datacarriersize parameter. By default, it limits OP_RETURN data payloads to 83 bytes. The intent: allow small amounts of metadata while preventing the blockchain from being used as a general-purpose data store.
The bypass described in CVE-2023-50428 used a different scripting pattern: OP_FALSE OP_IF ... OP_ENDIF. Instead of flagging data with OP_RETURN (where the datacarriersize filter catches it), this technique wraps the data inside conditional script logic — making it look like executable code rather than a data carrier. The datacarriersize filter doesn't inspect this pattern. Arbitrarily large payloads pass through unfiltered.
This is a policy bypass, not a consensus rule violation. Transactions using this technique are fully valid Bitcoin transactions. No wallet was drained. No private keys were exposed. The network consensus rules were not broken. What was bypassed was a node-level spam filter — and even that only for operators who had configured the datacarriersize limit in the first place.
Source: <a href="https://github.com/bitcoin/bitcoin/issues/29187" title="Bitcoin Core GitHub Issue #29187" rel="noopener noreferrer" target="_blank">GitHub bitcoin/bitcoin issue #29187</a>, <a href="https://www.sentinelone.com/vulnerability-database/cve-2023-50428/" title="SentinelOne CVE-2023-50428" rel="noopener noreferrer" target="_blank">SentinelOne Vulnerability Database</a>.
Why It Mattered: The Ordinals Connection
The OP_FALSE OP_IF technique wasn't invented in 2023. It had been in active use since late 2022 — by Bitcoin Ordinals.
Ordinals inscriptions work by embedding data (images, text, JSON) inside a transaction's witness field using exactly this pattern. By the time the CVE was filed in December 2023, millions of inscriptions had already been created on-chain. BRC-20 tokens, JPEG collections, text files — all of it stored directly in Bitcoin transaction data, using the bypass described in the CVE.
This context is essential: the CVE wasn't describing a newly discovered attack vector. It was formalising a technique that had already fundamentally changed Bitcoin's on-chain activity for over a year. Filing the CVE was, in part, a political act — an attempt to have the practice officially classified as a vulnerability so that Bitcoin Core would be pressured to filter it.
That pressure did not produce the intended result.
Two Clients. Two Responses.
Bitcoin Core — the reference implementation used by the vast majority of nodes — declined to treat CVE-2023-50428 as a vulnerability requiring a patch. The core developer position: inscription transactions are consensus-valid. The OP_FALSE OP_IF pattern is legitimate script. Whether to relay or mine such transactions is a node policy choice, and that choice already exists — node operators who want to filter inscriptions can configure their own policies. Forcing a global change to block valid transactions would be a far more contentious intervention than the inscriptions themselves.
Bitcoin Knots — Luke Dashjr's fork of Bitcoin Core, version 25.1.knots20231115 — patched it. Bitcoin Knots expanded its datacarriersize filtering logic to inspect the OP_FALSE OP_IF pattern, effectively blocking inscription relay for nodes running the Knots client. For operators who consider inscription data spam, running Knots provides an opt-in filter.
Both clients run on the same Bitcoin network. Both enforce the same consensus rules. They differ at the policy layer — what transactions they choose to relay, not which blocks they accept as valid.
Sources: <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50428" title="CVE-2023-50428 NVD Detail" rel="noopener noreferrer" target="_blank">NVD CVE-2023-50428</a>, <a href="https://github.com/bitcoinknots/bitcoin/blob/aed49ce8989334c364a219a6eb016a3897d4e3d7/doc/release-notes.md" title="Bitcoin Knots v25.1 Release Notes" rel="noopener noreferrer" target="_blank">Bitcoin Knots v25.1 Release Notes</a>.
The Governance Lesson
Bitcoin has no CEO. No board. No product owner who can push a mandatory security update.
Bitcoin Core is maintained by open-source contributors. Changes require broad consensus to merge — and "consensus" here doesn't mean majority vote, it means rough agreement among a distributed set of developers, node operators, miners, and users who each have their own views on what Bitcoin should be. Controversial changes that lack that consensus simply don't ship.
This is exactly what happened with CVE-2023-50428. The CVE filing created a public record and applied reputational pressure. It didn't create an obligation. Bitcoin Core developers reviewed the arguments, concluded that the behaviour was within acceptable parameters for the reference implementation, and declined to patch.
The result was not chaos. The network continued operating. Miners who wanted to include inscription transactions included them. Node operators who wanted to filter them could run Bitcoin Knots. Both choices were valid. Neither broke the network.
This is decentralised governance in practice: not a clean, fast decision by a single authority, but a distributed negotiation that results in multiple valid configurations coexisting on the same network.
Current Status (2026): Not an Active Threat
<a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50428" title="CVE-2023-50428 NVD Detail" rel="noopener noreferrer" target="_blank">Bitcoin CVE-2023-50428</a> is not an active exploit. There is no attack surface for regular Bitcoin users. No funds have ever been at risk from this technique.
As of Bitcoin Core 27.x and 28.x, the position is unchanged: inscription transactions are processed as valid transactions by default. The OP_FALSE OP_IF pattern remains consensus-valid. Node operators choosing to run Bitcoin Knots will continue to filter inscription relay on their nodes.
The CVE remains in the NVD database — a formal record of a real technical behaviour. Whether you call that behaviour a vulnerability or a feature depends entirely on where you stand in the Ordinals debate.
For regular Bitcoin users, nothing has changed. This is an infrastructure-level decision made by node operators. Your ability to send and receive bitcoin, your wallet security, and your transaction privacy are unaffected.
What Bitcoin CVE-2023-50428 Actually Tells Us
Strip away the technical detail and the Ordinals controversy, and what remains is a clean example of how Bitcoin actually governs itself.
A developer identified behaviour they considered harmful. They used the available tools — a CVE filing, a GitHub issue, public debate — to surface it. The maintainers of the reference implementation reviewed it and made a different call. A competing client shipped a patch for operators who shared the original concern. Both sides continued operating on the same network.
No patch was forced. No consensus was broken. The network survived a genuine governance disagreement by routing around it — exactly as decentralised systems are supposed to.
Bitcoin's response to CVE-2023-50428 is not a story about a security flaw. It's a story about what happens when a system with no central authority has to answer a hard question about what it is for.
Further reading:
- <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50428" title="CVE-2023-50428 NVD Entry" rel="noopener noreferrer" target="_blank">CVE-2023-50428 — NVD Detail</a>
- <a href="https://github.com/bitcoin/bitcoin/issues/29187" title="Bitcoin Core GitHub Issue #29187" rel="noopener noreferrer" target="_blank">bitcoin/bitcoin GitHub Issue #29187</a>
- <a href="https://www.sentinelone.com/vulnerability-database/cve-2023-50428/" title="SentinelOne CVE-2023-50428" rel="noopener noreferrer" target="_blank">SentinelOne Vulnerability Database — CVE-2023-50428</a>
- <a href="https://www.wiz.io/vulnerability-database/cve/cve-2023-50428" title="Wiz CVE-2023-50428" rel="noopener noreferrer" target="_blank">Wiz Vulnerability Database — CVE-2023-50428</a>