TL;DR
Bitcoin CVE-2023-50428 was filed by Luke Dashjr on 2023-12-09 against Bitcoin Core through version 26.0. The NVD entry, scored 5.3 MEDIUM and marked Disputed, says the -datacarriersize policy limit can be bypassed by wrapping data inside an OP_FALSE OP_IF envelope in Taproot script-path witness. Bitcoin Core called this a policy question not a consensus break and never shipped a fix. Bitcoin Core 30.0 released 2025-10-10 raised the default -datacarriersize limit from 83 bytes to 100,000 bytes via PR #32359, a 1,200x increase and the opposite of what the CVE asked for. Bitcoin Knots patched the filter in 25.1.knots20231115 and grew from about 69 nodes in January 2024 to roughly 4,240 of 23,842 reachable nodes by September 2025. Funds were never at risk. Consensus was never broken. The episode shows what Bitcoin governance looks like when a reference-client decision and an alternative-client filter coexist on the same network.
The CVE Luke Dashjr Filed Against Bitcoin Core
I work in the crypto self-custody space and I have watched the inscriptions debate split rooms full of Bitcoin developers since early 2023. Luke Dashjr filed CVE-2023-50428 on 2023-12-09 against Bitcoin Core through version 26.0. The argument was simple. Inscriptions embed arbitrary payload in transaction witness data using a script pattern the existing -datacarriersize policy filter ignores. As Knots maintainer, Dashjr called that a vulnerability. The Core maintainers called it a policy choice.
The NVD record carries CVSS v3.1 base score 5.3 MEDIUM with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. That vector matters. Confidentiality impact is None. Integrity impact is None. Only Availability shows Low impact. No funds at risk. No keys at risk. No invalid blocks. Only node relay capacity.
The NVD status line reads Disputed. Bitcoin Core maintainers reviewed the filter patch on bitcoin/bitcoin issue #29187 and declined to merge. Bitcoin Knots shipped its own filter in version 25.1.knots20231115 the same month.
What the Mechanism Actually Does
Bitcoin transactions can carry small amounts of arbitrary data. The classical path is OP_RETURN. The -datacarriersize node policy capped OP_RETURN payloads at 83 bytes by default (80 payload bytes plus 3 opcode overhead bytes). That cap was always a policy filter, not a consensus rule.
The CVE describes a different path. Inside a Taproot script-path spend, the witness can contain arbitrary script. An inscription wraps its payload in an OP_FALSE OP_IF <data chunks> OP_ENDIF envelope. The OP_FALSE guarantees the conditional branch never executes, so the data is treated as inert pushdata instead of runnable code. The -datacarriersize filter never looked at this path. Arbitrary payload size passed through.
This is a policy bypass, not a consensus break. Every inscription transaction is a valid Bitcoin transaction under consensus rules. Miners include them. Full nodes accept them. The only thing they bypass is a relay-time filter, and only on nodes that bothered to enforce it.
Why Bitcoin Core Called It Policy Not Consensus
The Core position rested on two technical observations and one governance observation.
The technical observations were straightforward. The cited transactions are consensus-valid. Node operators can configure their own relay policies today. Forcing the reference client to block valid transactions globally would be a much heavier intervention than the inscriptions themselves.
The governance observation was harder. Bitcoin Core has no mandate to win social fights. It ships the reference implementation. Operators who disagree can run alternative clients without splitting consensus. Bitcoin Knots existed precisely so that operators who saw inscription relay as harmful had an opt-in path.
Casey Rodarmor launched Ordinals on Bitcoin mainnet on 2023-01-21. Inscription #0 was created on 2022-12-14. By the time the CVE was filed in December 2023 the technique had been in active mainnet use for almost a year. The cat was already out of the bag.
Two Clients Diverged
Bitcoin Core declined the filter patch. Inscription transactions remained relay-eligible under default Core policy.
Bitcoin Knots 25.1.knots20231115 shipped the filter. The Knots inspector reads the witness for an OP_FALSE OP_IF envelope and drops the transaction at relay if the payload exceeds the configured cap.
Both clients enforce the same consensus rules. Both validate the same blocks. They differ in which transactions they relay before mining.
Knots adoption was a barometer of how much of the network agreed with the filter position. Reachable Knots nodes grew from roughly 69 in January 2024 to about 4,240 of 23,842 reachable nodes by early September 2025, around 17.78 percent of the listening network. That spike came alongside the v30.0 policy fight, not the original CVE filing.
Two Years Later Bitcoin Core Raised the Limit 1200x
Bitcoin Core 30.0 shipped on 2025-10-10. One line of release-note policy reframed the entire episode.
PR #32359 by Peter Todd raised the default -datacarriersize from 83 bytes to 100,000 bytes. That is a 1,200x increase. The same PR also lifted the cap on the number of OP_RETURN outputs per transaction. Operators who wanted the old behavior could still pass -datacarriersize=83 on startup.
The framing matters. Two years after a CVE asked Core to tighten the OP_RETURN filter, Core released a version that effectively retired it. The PR-thread reasoning was that enforcement had become unwinnable in practice. Inscriptions had already routed around the limit through witness envelopes. The OP_RETURN cap was punishing the one path that was explicitly designed for small amounts of arbitrary metadata while leaving the unintended path wide open. Maintainers framed the change as symmetry, not surrender.
Read it as you like. The empirical outcome is that the policy filter the CVE asked Core to extend is now configured by default to ignore more than a hundred kilobytes per transaction.
Bitcoin Knots continued shipping its own stricter filter in parallel. The v30.0 release is what drove the September 2025 Knots adoption surge.
What This Episode Shows About Bitcoin Governance
Bitcoin has no CEO. No board. No way to force a security patch on a reference implementation. For a deeper look at how the protocol works see Technical Deep Dive.
What CVE-2023-50428 actually tested was whether the social process around Bitcoin Core could be pressured by a filed CVE. The answer was no. The CVE became a public record. The patch did not become a default. Two years of debate later, Core moved in the opposite direction.
That outcome is the system working as designed, not as broken. A developer who disagreed shipped a different client. Operators who agreed with him ran that client. The reference implementation set defaults that matched the actual on-chain reality. The network kept producing blocks throughout. No funds were at risk. No consensus was broken.
If you came to this CVE looking for a security incident, there is no incident to clean up. If you came looking for a governance milestone, this is what one looks like in Bitcoin. A filed disagreement, two clients, a network that does not require unanimous agreement to keep running, and a default that eventually catches up to reality.
For wallet hygiene that holds regardless of relay policy fights, see the Bitcoin self-custody guide and the BIP-39 brute-force guide. For the inscriptions side of the story see Bitcoin Ordinals Explained.
Further reading:
- CVE-2023-50428 NVD Detail
- CVE-2023-50428 cve.org Record
- bitcoin/bitcoin Issue #29187
- Bitcoin Core 30.0 Release Notes
- release-notes-30.0.md on GitHub
- PR #32359 Remove arbitrary limits on OP_RETURN datacarrier outputs
- Ordinals Protocol Docs
New to Bitcoin? Start with Chapter 1. It takes eight minutes.
Want the full picture? Read all 19 chapters free or order the physical book.
