Security

Why Bitcoin Core Raised the Data Limit 1200x in 2025

7 min read
MH
Written by Mohamed Habbat
In this article

I work in the crypto self-custody space, and I watched the inscriptions debate split Bitcoin developers through 2023.

TL;DR

CVE-2023-50428 was published on 2023-12-09 against Bitcoin Core through version 26.0 (NVD). NIST scored it 5.3 MEDIUM. The record carries the tag disputed and says the datacarrier size limit can be bypassed by obfuscating data as code, for example with OP_FALSE OP_IF. Bitcoin Core treated this as a policy question, not a consensus break, and never merged a fix. Bitcoin Core 30.0, released on 2025-10-10, raised the default -datacarriersize from 83 bytes to 100,000 bytes through PR #32406, about 1,200 times the old limit and the opposite of the tighter filter Luke Dashjr's patch proposed. Bitcoin Knots shipped a filter in 25.1.knots20231115, three weeks before the CVE (Knots files), and on 11 October 2026 Knots ran on 4,171 of 25,374 reachable nodes (Bitnodes). Your funds were never at risk, and consensus never broke. The episode shows what Bitcoin governance looks like when the reference client and an alternative client with a stricter filter run on the same network.

The CVE Behind the Knots Filter

CVE-2023-50428 was published on 2023-12-09 and names Bitcoin Core through version 26.0 (CVE.org). The record cites a post by Luke Dashjr, who maintains Bitcoin Knots, and calls the bug a vulnerability "from the perspective of the Bitcoin Knots project". Dashjr had written on X on 2023-12-06 that "Inscriptions" were "exploiting a vulnerability in #Bitcoin Core to spam the blockchain" (post). His argument was simple. Inscriptions put arbitrary data in transaction witness data, using a script pattern the -datacarriersize policy filter does not inspect. Dashjr called that a vulnerability. The same record notes that "some others consider it 'not a bug.'"

The NVD record carries CVSS 3.1 base score 5.3 MEDIUM with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L (NVD). Read that vector closely. Confidentiality impact is None. Integrity impact is None. Only Availability shows Low. No funds and no keys are exposed, and no block becomes invalid. Node relay capacity is the entire surface.

Dashjr's patch for Bitcoin Core was PR #28408, opened on 2023-09-05. Ava Chow closed it without a merge on 2024-01-05, writing that it was "abundantly clear that this PR is controversial". Dashjr opened issue #29187 the same day to keep the question open, and that issue was closed on 2024-10-15. Bitcoin Knots had already shipped the filter in version 25.1.knots20231115, whose files are dated 2023-11-16 (Knots files).

How the Bypass Works

Bitcoin transactions can carry small amounts of arbitrary data. The standard path is an OP_RETURN output. Before version 30.0, Bitcoin Core's -datacarriersize policy capped OP_RETURN outputs at 83 bytes by default, "80 bytes of data, +1 for OP_RETURN, +2 for the pushdata opcodes" (policy.h). That cap was always a policy filter, not a consensus rule.

The CVE describes a different path. Inscription content is "stored in taproot script-path spend scripts", wrapped in an envelope of OP_FALSE OP_IF followed by data pushes and OP_ENDIF (Ordinals Handbook). The OP_FALSE means the branch never runs, so the data sits in the script as inert pushes. The handbook calls envelopes "effectively no-ops". The Bitcoin Core -datacarriersize filter never looked at this path, so data of any size passed it.

You get a policy bypass, not a consensus break. Every inscription transaction is a valid Bitcoin transaction under consensus rules. Inscription 0 sits in block 767,430 (ordinals.com), and full nodes accepted that block like any other. An inscription gets past a relay-time filter, and only on the nodes that enforce one.

Why Bitcoin Core Called It Policy Not Consensus

The Core position rested on two points, one technical and one about governance.

On the technical side, the transactions in question are consensus-valid. Operators can already set their own relay policy. Core contributors later wrote that a node should not attempt "to intervene between consenting transaction creators and miners" (Bitcoin Core).

The governance point was harder to argue. In a statement signed by 31 contributors on 2025-06-06, Bitcoin Core wrote that its contributors "are not in a position to mandate" the policies users run, and that no entity "can unilaterally push out changes to Bitcoin Core users" (Bitcoin Core). Operators who disagree can run a different client without splitting consensus. Bitcoin Knots gave operators who saw inscriptions as spam that opt-in path.

Casey Rodarmor made the first mainnet inscription on 2022-12-14 and announced on 2023-01-20 that inscriptions were ready for mainnet (How Ordinals Came to Be). By the time the CVE was published in December 2023, the technique had been in mainnet use for almost a year.

Two Clients Diverged

Bitcoin Core never merged the filter patch. Inscription transactions stayed relay-eligible under default Core policy.

Bitcoin Knots 25.1.knots20231115 shipped the filter. Its release notes say the -datacarriersize limit "has been updated to match newer style datacarrier transactions" and cite #28408 (Knots release notes). A Knots node counts the data in an OP_FALSE OP_IF envelope against the cap (Knots source) and refuses to relay a transaction that exceeds it.

Both clients enforce the same consensus rules. Both validate the same blocks. They differ on which transactions they relay before mining.

Knots adoption is the closest measure of how many node operators side with the filter. On 11 October 2026, 4,171 of the 25,374 reachable nodes in the Bitnodes snapshot, about 16 percent, reported a Knots user agent (Bitnodes). I counted the user agents in that day's snapshot myself. Nodes behind home routers that accept no inbound connections are not in that count.

22 Months Later Bitcoin Core Raised the Limit

Bitcoin Core 30.0 shipped on 2025-10-10 (Bitcoin Core). One release note reframed the whole episode.

The release notes say -datacarriersize "is increased to 100,000 by default, which effectively uncaps the limit", and that a transaction may now carry more than one OP_RETURN output (release notes). The change came from PR #32406 by Gregory Sanders, merged on 2025-06-09. 100,000 divided by 83 is about 1,200, which is where the headline number comes from. An earlier proposal from Peter Todd, PR #32359, would have removed the option altogether and was closed without a merge on 2025-05-12. Operators who want the old behaviour can still pass -datacarriersize=83, and Bitcoin Core 31.1 still accepts the option (init.cpp).

Twenty-two months after the CVE was published, Core released a version whose default removes the cap in practice. The June 2025 statement gives the reasoning: refusing to relay transactions "that miners would include in blocks anyway" pushes users to other channels, and "circumventing filters of the vast majority of the nodes is relatively easy" (Bitcoin Core). Inscriptions had already gone around the limit through witness envelopes.

The outcome is plain: the policy filter Dashjr's patch tried to extend now has a default of 100,000 bytes, which the release notes call effectively uncapped.

Bitcoin Knots kept its stricter filter. Its current release, v29.4.2.knots20260508, still has an 83-byte default and counts witness data against it (Knots source).

What This Episode Shows About Bitcoin Governance

Bitcoin has no CEO or board, and nobody can 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 tested was whether a filed CVE could pressure the social process around Bitcoin Core. It could not. The CVE became a public record. The patch never became a default. After 22 months of debate, Core moved in the opposite direction.

In my view that outcome shows the system working. A developer who disagreed shipped a different client. Operators who agreed with him ran it. The reference implementation set defaults that, in my reading, match what miners already put in blocks. The network kept producing blocks the whole time, and consensus held.

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, I think this is what one looks like in Bitcoin: a filed disagreement, two clients, a network that keeps running without unanimous agreement, and a default that eventually catches up with what happens on chain.

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:

New to Bitcoin? Start with Chapter 1.

Want the full picture? Read all 19 chapters free or order the physical book.

Frequently Asked Questions

What is CVE-2023-50428?
CVE-2023-50428 was published on 2023-12-09 and NIST scored it CVSS 3.1 base score 5.3 MEDIUM with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, an availability-only impact (NVD). The record says that in Bitcoin Core through 26.0 the datacarrier size limit can be bypassed by obfuscating data as code, for example with OP_FALSE OP_IF. The record carries the tag disputed.
Did Bitcoin Core ever patch CVE-2023-50428?
No. Bitcoin Core never merged a filter fix, and Ava Chow closed the filter pull request #28408 on 2024-01-05 as controversial. Bitcoin Core 30.0, released on 2025-10-10, went the other way: PR #32406 by Gregory Sanders raised the default -datacarriersize from 83 to 100,000 bytes and allowed more than one OP_RETURN output per transaction (release notes). An operator who wants the old limit can still set -datacarriersize=83.
Who is behind CVE-2023-50428?
The record cites a post by Luke Dashjr, the Bitcoin Knots maintainer, and calls the bug a vulnerability from the perspective of the Bitcoin Knots project (CVE.org). Dashjr posted his warning on X on 2023-12-06, three days before the record was published (post). His filter patch for Bitcoin Core was PR #28408, which was closed without a merge.
How does CVE-2023-50428 relate to Bitcoin Ordinals?
Casey Rodarmor made the first mainnet inscription on 2022-12-14 and announced on 2023-01-20 that inscriptions were ready for mainnet (How Ordinals Came to Be). Inscriptions store their content in Taproot script-path spend scripts inside an OP_FALSE OP_IF ... OP_ENDIF envelope (Ordinals Handbook). That is the pattern the CVE names.
Was anyone's bitcoin ever at risk?
No. The CVSS vector rates confidentiality and integrity impact as None and availability as Low (NVD). No keys leaked and consensus rules did not change. The bypass is a question of node relay policy, not of custody. Standard self-custody hygiene applies. See the self-custody guide and the BIP-39 brute-force guide.
Is Bitcoin Knots still filtering inscriptions?
Yes. Bitcoin Knots 25.1.knots20231115 made -datacarriersize match the newer data styles (release notes), and the current release, v29.4.2.knots20260508, still counts data in witness scripts against an 83-byte default (source). On 11 October 2026, 4,171 of 25,374 reachable nodes, about 16 percent, reported a Knots user agent (Bitnodes).

Related Articles