So I was writing a comment on Peter Todd's Luke is wrong: datacarriersize was about OP_Return, since Bitcoin Core v0.10.0 but it grew so much in scope that I thought it warranted its own post.
The central claims in Todd's post are:
- that datacarrier and datacarriersize were always meant to apply just to OP_RETURN outputs
- that the Core dev team was always fine with arbitrary data onchain and never made any effort to stop it
Both claims are sustained by citing from Bitcoin Core's v0.10.0 release notes. However, there's a lot more relevant sources that Mr Todd didn't think relevant to bring up, so it falls on me to do it on his behalf.
Applicability of datacarrier/datacarriersize
The most glaring omission in his post is that LukeDashjr was the original author of -datacarrier and -datacarriersize, which were indeed released with Bitcoin Core v0.10.0.
So not only is Todd claiming that Luke is wrong about the options he introduced himself, he also chose to share the release notes written by someone else (likely Wladimir van der Laan) instead of the actual descriptions of these options written by Luke, because they tell an entirely different story:

These descriptions remained unchanged until the summer 2023, when Core started moving towards legitimizing inscriptions explicitly. Marco Falke rewrote the description of datacarriersize to reduce it's scope to apply only to transaction outputs (inscriptions are done in transaction inputs). Bitcoin Core v26.0 released on December 2023 was the first release with the redefined datacarriersize.

Around the same time Luke submitted his own PR expanding the scope of his original option to include the inscription data envelope, unaware of the redefinition, and was ultimately shot down on the grounds of the definition of datacarriersize (without acknowledging that it had just been rewritten, nor Luke noticing it. That was noticed later).
Early Core dev's view on arbitrary data
The claim that Bitcoin devs have always been fine with unlimited arbitrary data and never made any effort to stifle it also crumble upon further inspection.
The release notes of v0.9.0 (when transactions with op_return was started to be relayed by default) are very unambiguous in this regard:

Another interesting source is the PR itself that made OP_RETURNs standard (and originally hardcoded to a maximum length of 80 bytes before Luke introduced datacarriersize a year later).
In it you can see that most devs, including Gregory Maxwell, talk very cautiously about opening up that data vector, while Todd is almost alone pushing for wider limits.


As a final comment, 10 years later Mr Todd was engaging regularly with the ordinal wallet repository around the time that ordinals launched. In here for instance, he can be seen arguing against adding an option to the wallet to store the arbitrary data on BitTorrent instead of Bitcoin transactions "because this data is worthless and it could be lost, so it has to go onchain".
Full timeline of events
- 04 Jun 2013 -> standard OP_RETURN PR created - https://github.com/bitcoin/bitcoin/pull/2738
- 24 Sep 2013 -> standard OP_RETURN gmax comment on arbitrary data - https://github.com/bitcoin/bitcoin/pull/2738#issuecomment-25017368
- 22 Oct 2013 -> standard OP_RETURN PR merged
- 21 Feb 2014 -> datacarrier PR created - https://github.com/bitcoin/bitcoin/pull/3715
- 18 Mar 2014 -> v0.9.0 released - https://web.archive.org/web/20140323172837/https://bitcoin.org/bin/0.9.0/
- 26 Jun 2014 -> datacarrier PR merged
- 11 Oct 2014 -> datacarriersize PR created - https://github.com/bitcoin/bitcoin/pull/5077
- 31 Oct 2014 -> datacarriersize PR merged
- 16 Feb 2015 -> v0.10.0 released - https://web.archive.org/web/20150318102801/https://bitcoin.org/bin/0.10.0/
- 06 Jun 2023 -> "clarify datacarriersize" PR created https://github.com/bitcoin/bitcoin/pull/27832
- 03 Aug 2023 -> "clarify datacarriersize" PR merged, released in Core v26
- 05 Sep 2023 -> "match more datacarrying" PR created - https://github.com/bitcoin/bitcoin/pull/28408
- 05 Jan 2024 -> "match more datacarrying" PR rejected
💥🔫