CVE-2023-50428General(bitcoin / bitcoin_core)

There are two specific vulnerabilities in Bitcoin Core that could have been fixed and avoided any talk of a fork. These are: CVE-2023-50428: Bypass of datacarriersize limit using OP_FALSE OP_IF CVE-2024-34149: Policy script size limits not enforced for Tapscript CVE stands for Common Vulnerability and Exposure, which provides a database of security vulnerabilities. The issues allowing spam to propagate freely on Bitcoin were acknowledged as vulnerabilities and made it into the CVE database. From a cybersecurity perspective, fixing vulnerabilities is a no brainer, even if the effect of the fix isn't perfect. Basic code changes would have at least made it so that the latest versions of Core and onward would not have that specific bug. The issues were fixed in Knots 25.1. Varying rationale has been given for not implementing the proposed fixes, but to me, all that has happened is that two bugs weren't fixed. I don't care that spammers would have an alternate method of getting their transactions relayed. The official policy of the reference implementation would be that relaying those transactions is non-standard. Policy defaults matter. Standards matter. Friction matters. This whole problem could have been solved ages ago by Core practicing basic vulnerability management.

9/ PR #28408 closes. 11 Concept NACKs vs 9 Concept ACKs. The loophole remains open. Jan 5, 2024: Luke opens Issue #29187 and formally designates the bypass as a security vulnerability: CVE-2023-50428. "Active exploitation... very harmful to Bitcoin even today."

TLDR version: A very disturbed person exploited Taproot vulnerability early in 2023. A patch for CVE-2023-50428 has been proposed in September 2023 and rejected/closed by Core in JAN 2024, as not a bug, but a feature. Core has been aggressively accommodating "other use cases for Bitcoin" since then, despite the outrage of their users, node operators, which decided to no longer put up with Core lies&gaslighting and proposed BIP 110.

Can you imagine how much easier it would be for IBD, and just running a node in general, if CVE-2023-50428 was just taken care of when @LukeDashjr brought it up? It just blows my mind how much damage Core has done.

Not dramatic enough after all that ↓ - Core to this day refuses to patch the inscriptions bugs CVE-2023-50428 and CVE-2024-34149. - Core rejected proposed patch, PR #28408, in JAN 2024 - Adding an insult to an injury, Core merged PR #32406, despite 75% NACK votes. They even locked Github, to prevent more NACK and ninja opened it to allow ACK votes. BIP110 is a proper response to all that. Again, plebs are not dramatic enough, after more than 2 years of gaslighting and hand waving.

@lukedewolf @hodlonaut The main two are: CVE-2023-50428: Bypass of datacarriersize limit using OP_FALSE OP_IF CVE-2024-34149: Policy script size limits not enforced for Tapscript Either one of these being fixed would have made Inscriptions non-viable.

Nobody’s angry about a 12% discount. The lie: “it’s only a 12% discount.” The truth: Taproot shipped without extending the datacarrier filters to cover Tapscript, which created the OP_FALSE OP_IF exploit that bypasses size limits entirely. That’s CVE-2023-50428. And you know it, Stephan.

@giacomozucco @CaminaDrummer4 @dathon_ohm @FiscalDominanc @privacymatter21 @BitcoinBombadil @BTCtoOblivion Giacomo, why did Core decided to ignore the "unforseen consequences" and never patch the CVE-2023-50428 ?

@murchandamus You mean like how we’re routing around you in order to fix CVE-2023-50428? Yeh man, I’d say everyone understands.

@BTCBreadMan You can’t be serious. “Valid transactions paying fees can break the system” is a design problem? Great. CVE-2023-50428 is the design problem. BIP-110 is the fix. You just made our argument for us.

CVE-2023-50428 I think it should be addressed, however where it gets complex is how it would potentially be “fixed.” Even the “fix” Luke made was in policy, which as you know can be bypassed, so it is not an effective fix. There are only two ways you can fix this, either you have a policy which all miners follow, or in you set a limit as a consensus rule. If you think from the perspective of Core devs, obviously they are not going to push for a consensus change to address a nuisance, and they believe policy should be dictated by the network (as evident in most of their comms). Changing consensus rules is a no-no, even for the most annoying Core dev that you dislike. So the topic is quite complex and what you or I hold as opinions, is not really relevant.

Good article. My take on the hard fork is this: after failing to properly fix CVE-2023-50428 (the vulnerability that allowed bypassing data size limits), Core developers put Bitcoin on a path toward Ethereumization. That is not Bitcoin. BIP-110 simply returns Bitcoin to its original monetary path—that is Bitcoin. Intrinsic properties matter far more for the definition of Bitcoin than extrinsic properties like financial/computational backing.

@calibrated_lies @BTCtoOblivion @ProductionReady @Excellion @jimmysong @parkeralewis @jratcliff If the real goal is to damage Bitcoin; This could be a way to not fix the real issues: CVE-2023-50428 and CVE-2024-34149 In other words, to increase the noise to make the real signal to go away.

@grok @StackingSaunter @eric_b_hodln @stephanlivera @grok , was CVE-2023-50428 resolved in any other Bitcoin node implementations?

@Excellion @asanoha_gold I’m glad you think CVE-2023-50428 should be addressed, so I assume you still think that changing the documentation was not the correct move? Also, your comment here leaves the whole thing between a rock and a hard place saying it can’t be fixed in policy or consensus

21/ Celah/loophole tetap terbuka lebar. 5 Januari 2024: Luke membuka Open Issue #29187 dan secara formal menetapkan bypass Peter tersebut sebagai sebuah security vulnerability: CVE-2023-50428.

The Bitcoin Core v30 wallet migration bug (Jan 2026, in 30.0 & 30.1) can delete all files in a wallet directory under rare conditions with legacy unnamed wallet.dat files (esp. with pruning). Not CVE-2023-50428. Binaries pulled; fixed in upcoming 30.2. Avoid migrations until then. CVE-2023-50428 is a 2023 datacarrier size limit bypass via OP_FALSE OP_IF (inscriptions spam); disputed/not fixed in Core, fixed in Knots. 2013 was a chain fork (not inflation) from v0.8 block incompatibility; resolved in hours via miner downgrade. (Inflation bugs: 2010 value overflow; potential 2018 in 0.15-0.16.2.) Core code hasn't been flawless over ~17 years—bugs happened, but were addressed without long-term harm.

@jaysmontoya @Ducatstable @grok, can you tell us about the recent Bitcoin Core v30 issue that deletes legacy wallets (CVE-2023-50428), its status as fixed, and the 2013 inflation bug causing a chain split? What do you think of the claim that Bitcoin Core devs have shipped flawless code for 17 years?

FrickFracck, thing were fine until 2023 when ordinals happened. - Core to this day refuses to patch the inscriptions bugs CVE-2023-50428 and CVE-2024-34149. - Adding an insult to an injury, Core merged PR #32406, despite 75% NACK votes. They even locked Github, to prevent more NACK and ninja opened it to allow ACK votes. BIP110 is a proper response to all that.

Leurico, that's an utter BS. It's been going on since 2023. Core continuously refuse to do anything about inscriptions bugs listed as CVE-2023-50428 and CVE-2024-34149. Core, with straight face, closed Luke's proposal to fix the exploits, PR #28408, in JAN 2024. Plebs waiting only added an insult to an injury, when Core merged PR #32406, default policy change and activated in Core v30 in OCT 2025.