Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)

[luke-jr]

The datacarriersize policy option is meant to limit the size of extra data allowed in transactions for relaying and mining. Since the end of 2022, however, attackers have found a way to bypass this limit by obfuscating their spam inside OP_FALSE OP_IF patterns instead of using the standardized OP_RETURN. This remains under active exploitation to a degree very harmful to Bitcoin even today.

A straightforward way to address this is to simply fix the bug (#28408), but that was (inappropriately) closed due to social attacks.

This remains an active issue that needs to be addressed.

Other solutions have been proposed, including:

• Rejecting transactions entirely if they attempt to bypass the datacarriersize limit (so-called "Ordisrespector")
• Extending the existing policy script size limits to Tapscript. Currently, this varies for pre-segwit (1650) and segwit v0 transactions (3600), but could be unified and applied equally to all scripts. (This is included in Knots v25.1 currently)
• Identifying extra data yet removing the witness discount rather than filtering it out entirely. It's not clear this would be effective alone, but is supported by Knots v25.1.
• Adding a second datacarriersize with a broader scope like in datacarriersize: Match more datacarrying #28408 (suggested by glozow).
• Moving back to a whitelist-based transaction policy, where only known/standardized scripts are accepted.
• A softfork making data storage impractical. This would likely be very "painful" to implement, review, and even adopt (it would require upgrades from all wallets). It would also be a slow process and entail risks without significant economic support upfront.

I have written code for the first 3, which I am happy to PR if there's interest. Perhaps others can suggest and/or implement other solutions.

[glozow]

The datacarriersize policy option is meant to limit the size of extra data allowed in transactions for relaying and mining.

History of this config option suggests datacarriersize is meant to limit the size of data in OP_RETURN outputs, so this statement is untrue.

• comments on Add an option to allow users to disable relaying/mining data carrier transactions #3715:
  • comment asked about including the usage of bare CHECKSIG and CHECKMULTISIG, arguing it should be in scope for that PR
  • comment asked whether "Data carrrier TX means in that context, that this are TXes, which contain data unrelated to the Bitcoin system...?"
  • comment said "data carrier tx means a tx with an op_return output"
  • comment suggested people talking about bare multisig should go to Option to consider bare multisig scripts in TX outputs non-standard #3939, indicating it was out of scope
• Enable customising node policy for datacarrier data size with a -datacarriersize option #5077 adding -datacarriersize used MAX_OP_RETURN_RELAY as the default. That is still the case today.
• 0.10.0, in which -datacarrier and -datacarriersize were first introduced, explicitly defined the term "data carrier" as pertaining to OP_RETURN transactions in the release notes :

    -datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions if this is 1.
    -datacarriersize=n : Maximum size, in bytes, we consider acceptable for "data carrier" outputs.

• PR Comments: More comments on functions/globals in standard.h. #11058 added the doc "A data carrying output is an unspendable output containing data. The script type is designated as TX_NULL_DATA."

The docs from #11058 have not changed except for moving files:

bitcoin/src/kernel/mempool_options.h

Lines 46 to 53 in cb6d619

	/**
	* A data carrying output is an unspendable output containing data. The script
	* type is designated as TxoutType::NULL_DATA.
	*
	* Maximum size of TxoutType::NULL_DATA scripts that this node considers standard.
	* If nullopt, any size is nonstandard.
	*/
	std::optional<unsigned> max_datacarrier_bytes{DEFAULT_ACCEPT_DATACARRIER ? std::optional{MAX_OP_RETURN_RELAY} : std::nullopt};

Instead of retroactively deciding that -datacarriersize applies to more than just OP_RETURNs, why not propose a new config option?

[luke-jr]

History of this config option suggests datacarriersize is meant to limit the size of data in OP_RETURN outputs, so this statement is untrue.

It's meant to limit extra data in transactions. OP_RETURN was supposed to be the only tolerated way to do that. datacarriersize has no possible use if it's trivial to bypass. The "Ordisrespector" approach would take us back to that prior status quo.

why not propose a new config option?

It would be confusingly redundant. But if that is Concept ACK'd, I would be happy to do it. (Added to list of solutions in OP for now)

[dergoegge]

It's meant to limit extra data in transactions. OP_RETURN was supposed to be the only tolerated way to do that.

Can you add any references for this? because the GitHub and git history very clearly contradicts your statements (#29187 (comment)).

[luke-jr]

No, it doesn't contradict it. That overview conveniently leaves out the context of OP_RETURN being the only way tolerated, and the datacarriersize limit makes no sense the way you want to spin it.

[wizkid057]

• Identifying extra data yet removing the witness discount rather than filtering it out entirely. It's not clear this would be effective alone, but is supported by Knots v25.1.
• Adding a second datacarriersize with a broader scope like in datacarriersize: Match more datacarrying #28408 (suggested by glozow).

TL;DR - My suggestion is to implement the bug fix as above with a combination of these two bullet points. ^

It seems like an acceptable compromise solution would be the combination of these two, provided that the default for the new second otherdatacarriersize option (or whatever it ends up being called) is the same as the existing one for OP_RETURN (80 bytes of arbitrary data), and there is an option to disable the equalization of the fees, if desired (as there is in Knots).

This fully addresses the only somewhat valid objection I saw to the original (now closed) PR, in my opinion, which was that there was no mechanism for users to run nodes which use the current policy if they so desired without code changes. While I'm personally at a loss to why anyone would want to run a node that permits active exploitation of an obvious bug, I'm all for giving people choices. Adding the options above resolves that objection entirely, as anyone with that mindset can simply set them to whatever they want.

This effectively adds OP_IF/OP_FALSE as a new "tolerated" method of data carrying, with a limit on data carrying equal to that of the existing tolerated method of OP_RETURN. But keep in mind that the OP_FALSE/OP_IF exploit method of data carrying is arguably worse for the network than OP_RETURN, though, since these types of store-data-in-the-witness transactions require two transactions, and they tend to just leave a dust output in the UTXO set forever once the data is "revealed". The above would disincentivize that harm sufficiently, since equalizing the fee-per-byte with OP_RETURN should effectively drive data carrying back to OP_RETURN (never enters the UTXO set) from a cost basis. This is because the two-transaction method of performing the OP_IF/OP_FALSE exploit would end up being more costly overall than one transaction to an OP_RETURN.

Further, any implementation of these new flags should be 100% unambiguous in documentation and comments such that they apply to all known data carrying methods besides OP_RETURN, and thus avoiding the potential situation where folks in the future can attempt to ignore an active exploit by simply changing the documentation.

Finally, let's be clear that this is a valid issue, that the use of OP_FALSE/OP_IF for storing arbitrary data IS in fact an exploit, one that is being actively harmful, and fixing (or even slowing down, in the case of the suggested implementation above) that exploitation is in the best interest of the network as a whole. There is no script that actually validates anything that can make use of such a mechanism. It explicitly and provably does NOT use the arbitrary data for any validation whatsoever. Any such method of storing data is clearly not an intended use case for the Bitcoin network any more than someone storing arbitrary data in other types of outputs (like P2PKH, multisig, etc) is an intended and valid use case, as this is harmful to the network. The latter was effectively discouraged by tolerating a small amount of arbitrary data with OP_RETURN, which is at least not as harmful to the network. While the existence of OP_RETURN doesn't prevent anyone from using more harmful methods, it does make them prohibitively more expensive to do so and seems to have all but eliminated that practice.

The OP_FALSE/OP_IF exploit gets around the clear intentions of allowing OP_RETURN by both avoiding the data size limit, AND getting a huge discount on fee per byte for that data compared to regular transactions. A clear bug to be addressed. If, for example, people figured out a way to exploit OP_RETURN to get around the 80 byte relay limit when it was implemented, I'm certain there would have been a quick fix for that. Also, if you have people constantly dumping garbage in your driveway that you have to clean up any time you want to move your car, and you decide to put in a security system to prevent that as best possible (maybe by making your neighbor's yard more attractive to the dumpers)... making the argument that the ones doing the dumping are now somehow the victims because they can no longer take advantage of you is just not valid. The same goes for people actively exploiting a clear bug in Bitcoin. What happens with people actively exploiting it as a result of a fix that levels the playing field is not of consequence to users of Bitcoin. Heck, this proposal doesn't even prevent the practice, just puts it on par with other data carrying. In my opinion, the exploit should be closed completely, but the two bullet points above are an excellent compromise.

Let's get this fix done, and let's not let perfect be the enemy of good.

[1440000bytes]

Since CVE ID is used to validate this as a vulnerability, I wanted to share that cve.org has added "disputed" tag for CVE-2023-50428. This tag is used when there are differences of opinion about whether its a vulnerability based on the CVE program's definition.

A note has also been added to CVE by MITRE on 4 Jan 2024:

NOTE: although this is a vulnerability from the perspective of the Bitcoin Knots project, some others consider it "not a bug."

https://nvd.nist.gov/vuln/detail/CVE-2023-50428#VulnChangeHistorySection

[wizkid057]

Since CVE ID is used to validate this as a vulnerability

It's not, really. In fact, I didn't even mention "CVE" once in my detailed comment above.

This is clearly a bug, clearly a vulnerability in the software, clearly unintended behavior, and clearly being actively exploited in the wild. That more than qualifies this particular issue as a valid CVE, but absolutely no one credible is doing the reverse of using the CVE ID's existence to "validate this as a vulnerability." It's an unambiguous vulnerability regardless of if it has a CVE number assigned to it.

I wanted to share that cve.org has added "disputed" tag for CVE-2023-50428

The people actively exploiting a bug, or otherwise supporting the exploit of a bug, now also abusing the mechanisms related to CVE reporting... is frankly unsurprising, and really doesn't qualify as something to be used as a "gotcha" here. In fact, I think it gives the need to patch the exploit even more weight, given how desperate the active exploiters are being in attempts to prevent this bug from being patched.

The ability to inject arbitrary data into any system in a way that isn't explicitly documented as permitted for an expected purpose of the system is always a vulnerability and always something that should be addressed. This is cybersecurity 101 stuff, and isn't even remotely specific to Bitcoin. The data proceeding OP_FALSE/OP_IF is clearly and provably arbitrary and not in any way required nor intended for Bitcoin to function as designed.

Storing virtually limitless amounts of arbitrary data (effectively up to the max block size) in the Bitcoin public ledger (and thus forcing everyone running a full node to not only download and deal with this data, but requiring it to be stored for all eternity in one form or another) by using a clearly unintended exploit that gets around not only previously imposed limitations on tolerated arbitrary data size, but also gets a discount for doing so vs standard transactions? That's got to be probably the most obvious exploit on the Bitcoin network since the infinite money exploit. Fixing it shouldn't even be remotely controversial.

If someone can show me code, code comments, documentation, community discussion about the pros/cons of such a mechanism, and confirmation of "rough consensus" on this, from before this exploit was developed and abused, that clearly defines this specific OP_FALSE/OP_IF method of storing arbitrary data in the Bitcoin blockchain as a well defined intended behavior that was agreed upon to be permitted by the community and nodes, then, I'd likely have to concede that this is not a vulnerability that needs fixing since it would then be clearly defined and intended behavior. In the absence of that (which is the reality of the situation, because none of the above exists), this is unintended behavior, and a clear vulnerability that needs addressing.

In fact, this is orders of magnitude worse than similar vulnerabilities in other systems that are clearly and unambiguously defined as a vulnerability and bug to be fixed. The only reason this one is being disputed in any way, in my opinion, is because there's a massive conflict of interest and major financial incentive to the exploiters to retain their ability to abuse the Bitcoin network. So the full resources of those groups are being utilized to sow discord on what should be a cut and dry vulnerability patch. Sadly, that's a very noisy minority in this case.

"Bitcoin is a decentralized digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: transaction management and money issuance are carried out collectively by the network." By finally addressing this issue (or heck, even acknowledging that it is and issue), the developers would be upholding the primary purpose of the network, being a digital currency, thereby maintaining user trust in its reliability, long term viability, and overall security. Fortunately some developers are capable of seeing through the noise here, and hopefully other developers will regain their collective sanity and cut through the noise as well to properly address this bug. It's been quite the spectacle, and admittedly very disheartening, watching so many developers on this project whom I've held in pretty high regard over the years be so clearly and blatantly deceived and swayed by the obvious noise from attackers on this particular issue. That's been very sad to see.

[totient]

It's meant to limit extra data in transactions. OP_RETURN was supposed to be the only tolerated way to do that.

Can you add any references for this? because the GitHub and git history very clearly contradicts your statements (#29187 (comment)).

"There was [sic] been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database." (https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.0.md#op_return-and-data-in-the-block-chain)

If datacarriersize was meant to apply only to arbitrary data in op_return and not to all data, why wasn't it called op_returncarriersize?

Its quite clear that op_return was meant to deprecate all other arbitrary data injection schemes, and it was then limited to 40 (later 80) bytes. The release notes history never show an intention to change the client to accommodate large amounts of arbitrary data either in relay policy or permanent storage in blockchain data.

This debate actually goes back quite a bit further, at least to v0.3. This size of op_return data was supposed to be limited to sha256 output (32 bytes), plus a few bytes for an identifier tag. This design choice was in compliance of Satoshi's suggestion "I also support a third transaction type for timestamp hash sized arbitrary data." (https://bitcointalk.org/index.php?topic=2162.msg28549#msg28549), At the time Satoshi wrote the above post signaling his support for 32 bytes of arbitrary data, Satoshi and Gavin (maybe others too) had agreed to implement a script whitelisting policy, which was an intentional effort to stop people from finding clever uses of script to create transactions which didn't relate to the monetary purpose of the client software.

The PR 28408 Review note posted by @glozow starts recording history from 0.10. I'm not sure why the incredibly relevant context about Bitcoin's design principles from 0.9 (and earlier) is being ignored.

[mzumsande]

A softfork making data storage impractical. [...] It would also be a slow process

It's going to be a slow process either way:

Even if Bitcoin Core changed its default policy, the effect on propagation would be negligible for a long time.
The p2p network is densely connected, with reachable nodes having 8 tx-relaying outbound peers and typically many more tx-relaying inbounds. Some network simulations I did in the context of full-RBF a few years ago indicated that already a minority of 10% of nodes supporting a feature (that is non-standard for the rest) is sufficient for propagation with a >95% probability (assuming both sender and miner run well-connected reachable nodes).

Since the txns in question are standard for almost all nodes today and the network tends to upgrade to newer versions slowly (https://bitnodes.io/dashboard/1y/#user-agents), it would take several years to get anywhere near that 10% threshold if upgrades would just happen naturally. After that, preferential peering would be a simple and effective countermeasure - there wouldn't even be a real need for out-of-band delivery.
In general, I think that using policy to prevent transactions from propagating when there is an active minority that wants them propagated is just not going to work in practice.

Adding an option that's not enabled by default would be purely symbolic for the purpose of transaction relay. However, it could still make sense to have it because if miners want to run that and earn less fees, a config option would make that easy for them and they wouldn't have to resort to alternative clients.

[saltduck]

Can we just remove the discount of the segwit data? It is fair for both generic users and the attackers.在 2024年1月11日，07:11，Martin Zumsande ***@***.***> 写道： A softfork making data storage impractical. [...] It would also be a slow process It's going to be a slow process either way: Even if Bitcoin Core changed its default policy, the effect on propagation would be negligible for a long time. The p2p network is densely connected, with reachable nodes having 8 tx-relaying outbound peers and typically many more tx-relaying inbounds. Some network simulations I did in the context of full-RBF a few years ago indicated that already a minority of 10% of nodes supporting a feature (that is non-standard for the rest) is sufficient for propagation with a >95% probability (assuming both sender and miner run well-connected reachable nodes). Since the txns in question are standard for almost all nodes today and the network tends to upgrade to newer versions slowly (https://bitnodes.io/dashboard/1y/#user-agents), it would take several years to get anywhere near that 10% threshold if upgrades would just happen naturally. After that, preferential peering would be a simple and effective countermeasure - there wouldn't even be a real need for out-of-band delivery. In general, I think that using policy to prevent transactions from propagating when there is an active minority that wants them propagated is just not going to work in practice. Adding an option that's not enabled by default would be purely symbolic for the purpose of transaction relay. However, it could still make sense to have it because if miners want to run that and earn less fees, a config option would make that easy for them and they wouldn't have to resort to alternative clients. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nsvrn]

I strongly think that the datacarriersize should be updated to what it truly supposed to do in the first place(not what it's documentation was changed to after ord spam started). This is like saying that every option that exists now literally doesn't apply to future additions in the functionality.
And people who say it's a cat and mouse game, isn't every attack mitigation in network security like that?
May be you want to admit that there isn't a good solution you've found but even then what makes you oppose the accuracy of what already exists as options.
It will never add up for me that the dev community here is basically saying that ord injection is neither a bug nor "data".

[tromp]

No matter what new restrictions are imposed, it's safe to assume that the economic reality of people wanting to inscribe data on the blockchain will persist and use whatever means is available and cheapest. There will always be means available such as spreading the data over multiple outputs or multiple txs, encoding the data as arbitrary taproot scripts, or encoding the data as fake public keys or key hashes. Some of these encodings will be detectable while others will not.
Raising the cost of inscriptions will reduce the amount of it, but it's not clear by how much. Doubling the cost could reduce it by half or reduce it by only by 10%. I don't know of any studies of the price sensitivity of inscribers. There is likely some degree of irrationality there.
It would be nice to see, for any proposed measure, what alternative encoding scheme(s) the inscribers can be expected to migrate to, on a cost minimization basis, and what implications that will have on things like full node resource usage, and whether we would be happy with that.

[GregTonoski]

what alternative encoding scheme(s) the inscribers can be expected to migrate to, on a cost minimization basis, and what implications that will have on things like full node resource usage, and whether we would be happy with that.

If it had been about cost minimisation only then they would have spammed testnets (for virtually free) instead of the Mainchain.

[tromp]

If it had been about cost minimisation then they would have spammed testnets

Their perceived value is of inscriptions on the bitcoin main chain of course. Not on a testnet, not on an altcoin chain, and not of an inscribed link to some other hosting site. They want their data to still be downloadable a century from now, guaranteed. Any cost minimization is conditional on that.