Luke is wrong: datacarriersize was about OP_Return, since Bitcoin Core v0.10.0 \ stacker news ~bitcoin

From the Bitcoin Core v0.10.0 release notes, February 8th 2015:

Luke Dashjr has been saying that -datacarriersize was meant to apply to all forms of arbitrary data in transactions, and that failing to do so was a bug.

Luke is wrong.

As you can see, when the -datacarrier options were added to Bitcoin Core v0.10.0, about 11 years ago, we knew it only applied to transactions containing an OP_Return output, and the size limit was about that OP_Return output. Nothing else.

Think about it: the whole point of OP_Return was to encourage people already making UTXO-using data-carrying transactions to do so in a different, less harmful way. We couldn't stop that and we knew it. There's no way we intended this to be a filter for all data.

Furthermore, in the exact same release, we also allowed arbitrary scripts to be used with P2SH:

We knew people could and would use this to put data in transactions. And we made no effort to stop that, because trying to do so is an endless cat and mouse game. Indeed, I personally created a demo program that published arbitrary text to the chain right after v0.10.0 was released:

https://github.com/petertodd/python-bitcoinlib/commit/a93de41fe6c3e4aa8dec478c464857020add275a

Finally, notice how this was years prior to Taproot. The idea that Taproot "enabled spam" is just nonsense. "Spam" has been with us since the beginning of Bitcoin.

181 sats \ 1 reply \ @Scoresby 1h

Thanks for posting this. I appreciate the clarity. I previously had not heard the argument that Taproot enabled spam in this context. I always thought people made such an argument because Taproot removed the script size limit, which meant that the ordinal people could include their ordinal data in the script.

Personally, I don't believe there is such as thing as a spam transaction that gets included in the Bitcoin blockchain.

290 sats \ 0 replies \ @petertodd OP 1h

Taproot didn't change anything meaningful from the point of view of someone who wants to publish data. The limits on P2SH are already plenty big. You just need to add more inputs if you exceed those per-txin limits, which doesn't significantly increase the cost.