A newly disclosed vulnerability in Bitcoin Core has exposed a fundamental weakness in the network’s transaction data handling, revealing that inscription creators have been quietly bypassing size limits since late 2022. Designated CVE-2023-50428 and published on December 9, 2023, the vulnerability affects Bitcoin Core through version 26.0 and Bitcoin Knots before version 25.1.knots20231115, allowing attackers to circumvent the datacarriersize policy by embedding data within OP_FALSE OP_IF opcode patterns instead of the standard OP_RETURN output.
The Exploit Mechanics
Bitcoin Core implements a datacarriersize policy that limits the amount of arbitrary data miners and relaying nodes accept in transactions. The intent is to prevent spam and keep the blockchain lean. Historically, users who wanted to embed data in transactions used OP_RETURN outputs, which are subject to an 80-byte limit. However, the creators of Ordinals inscriptions discovered that they could bypass this restriction entirely by encoding data inside witness scripts using OP_FALSE OP_IF constructions.
The technique works by placing data between opcodes that are never actually executed during script evaluation. OP_FALSE causes the subsequent IF branch to evaluate as false, meaning the data inside the IF block is skipped during execution but still stored on-chain in the witness data. Since Bitcoin nodes treat witness data differently from OP_RETURN outputs, the datacarriersize limit does not apply, effectively allowing unlimited data inscription per transaction.
This bypass has been actively exploited since late 2022, fueling the explosion of Bitcoin inscriptions and BRC-20 tokens that have consumed significant block space and driven transaction fees higher throughout 2023. With Bitcoin trading at $44,167 in early December 2023, the network was already experiencing elevated fee pressures from inscription activity.
Affected Systems
The vulnerability impacts all Bitcoin Core nodes running version 26.0 or earlier that have not applied the relevant patches. Bitcoin Knots, a derivative implementation, addressed the issue in version 25.1.knots20231115. The practical impact is not a theft of funds but rather a degradation of network performance: inscription spam bloats the blockchain, increases synchronization times for new nodes, and drives up transaction fees for all users.
Miners are indirectly affected because the increased block space consumption by inscription data means fewer financial transactions can fit in each block. This creates a tension between the revenue miners earn from inscription-related fees and the long-term health of the network’s utility as a payment system.
The Mitigation Strategy
The Bitcoin Core development community has engaged in extensive discussion about how to address CVE-2023-50428. The most straightforward fix involves extending the datacarriersize policy to cover all transaction outputs, including witness scripts that contain OP_FALSE OP_IF patterns. However, any change to Bitcoin Core’s relay policy requires broad consensus among node operators, miners, and the wider community.
Bitcoin Knots implemented a more aggressive approach, treating inscription-style data embedding as a policy violation and refusing to relay transactions that exploit the bypass. This approach has proven effective at reducing inscription spam on nodes running Bitcoin Knots but has not achieved universal adoption.
For individual users and businesses running Bitcoin nodes, upgrading to the latest patched version of Bitcoin Core is the primary mitigation. Node operators who wish to filter inscription transactions can also configure custom mempool policies that reject transactions containing oversized witness scripts.
Lessons Learned
CVE-2023-50428 illustrates a recurring theme in blockchain security: the gap between protocol specification and implementation behavior. Bitcoin’s script language is intentionally flexible, and the OP_FALSE OP_IF pattern is technically valid Bitcoin script. The vulnerability arises not from a coding error but from an assumption — that data would only be embedded via OP_RETURN — that turned out to be incorrect.
The inscription phenomenon also raises important questions about Bitcoin’s identity as a network. Is Bitcoin primarily a financial settlement system, where block space should be reserved for monetary transactions? Or is it a general-purpose data layer where anyone can store arbitrary data by paying the appropriate fees? The community remains divided on this question, and CVE-2023-50428 has become a focal point for the broader debate about Bitcoin’s purpose and governance.
User Action Required
Node operators should upgrade to Bitcoin Core v26.0 or later and review their mempool configuration settings. Users who transact in Bitcoin should be aware that inscription activity can cause sudden fee spikes and plan their transactions accordingly, using fee estimation tools and setting appropriate fee boundaries. Businesses that rely on Bitcoin for payments should consider implementing transaction batching and Lightning Network routing to reduce their exposure to on-chain fee volatility.
Disclaimer: This article is for informational purposes only and does not constitute technical or financial advice. Always verify vulnerability details through official sources and security advisories.
so Ordinals devs knew about the OP_FALSE OP_IF bypass since late 2022 and just… kept using it. cool. very cool
ordinal_skeptic they knew and didnt care because it benefited them. calling it a CVE is generous when the exploit was operating in plain sight for over a year
the 80 byte OP_RETURN limit was supposed to prevent blockchain bloat and inscriptions found a loophole that makes that entire policy meaningless. this CVE is just acknowledging reality
Burak Y. calling it a loophole is generous. it was a design choice that OP_RETURN was the only constrained output path. the protocol never intended to limit all data embedding
as a node operator this frustrates me. my disk is getting eaten by JPEG data because someone figured out how to sidestep the datacarriersize limit
node_policy_ you can already filter ordinal transactions with custom mempool policies. the issue is miners have no incentive to do that when fees are higher with inscriptions
opcode_rider exactly. miners profit from inscription fees so of course they wont filter. the incentive misalignment is the actual vulnerability here
^ run your own node policy then. you can filter ordinal transactions if you want, its your node
watching people who screamed about keeping blockchain small now defend JPEG data in witness scripts is something else