I think it is a good thing that we are paying attention to bitcoin development funding and how decisions are made within whatever organizational structures exist around bitcoin development. And in that sense, I appreciate Hodlonaut's work.

However, I wish the issue wasn't filters and op-returns and datacarriersize. Because I think Hodlonaut is wrong about some of the actual facts of the situation and now people are all yammering away on it like they know what's up when he got them started with bad info.

A central point in Hodlonaut's article is the claim that datacarrier and later datacarriersize were originally intended to apply to all transactions with data:

This has become a bit of a rallying cry for those who support RDTS:

source

source

I am not a dev and was not involved in bitcoin in 2014 (when Bitcoin 0.9 introduced relaying this usage of OP_RETURN) nor even when Bitcoin 0.10 was released (introducing the datacarrier option to relay/mine OP_RETURN transactions along with datacarriersize) and I generally misunderstand things, but I would like to point out that there were, indeed, other ways of storing data in transactions.

Here is one example:

https://mempool.space/tx/b844b81ecabc10822fbcc4644a40b586406501c8cbbd34c61ca584597580d4f5?showDetails=true

This transaction is from before even Bitcoin 0.9 was released, so presumably whatever the original scope of datacarriersize was, it was aware that transactions could do this.

The transaction is a Counterparty transaction that uses legacy multisigs to embed data in a bitcoin block. The data is in little blobs in fake keys for the multisig.

In case you are wondering, this wasn't exactly a weird secret thing that only happened once. Here is a CoinDesk article that describes some of the debate around data embedding and specifically talks about Counterparty using multisigs to store data:

And here is a Counterparty forum post from August of 2014 discussing how they used multisigs to embed data:

And here is a January 2014 BitcoinTalk post (also before Bitcoin 0.9) about embedding data in multisigs

So, if users understood the introduction of datacarriersize to "limit the data carried in any relayed transaction" -- as Hodlonaut claims -- such users would have expected it to apply to data embedded in multisigs like this.

It did not apply to such embedded data.

Hodlonaut wrote this whole very long article the argument of which kind of hinges on Core developers redefining the scope of a relay option:

But, as far as I can tell, this is a case of people not understanding each other. Given that there were other ways of embedding data in transactions, I don't see how the original scope of an option that only worked on one of several possible ways to embed data should have been expected by users to apply to all possible ways to embed data. (I murdered that sentence, and I'm sorry, but I'm also tired).

I don't care about Counterparty, nor do I care about inscriptions or storing data in bitcoin transactions. But I do believe it's pointless to try to stop it, and that it is pretty obvious that datacarriersize was not some magic setting in your node that made it so you wouldn't relay transactions that contained icky "non-monetary data." I wish people would stop making shit up.

The article is long and Hodlonaut makes a lot of interesting observations about the dynamics of how Bitcoin Core development occurs. Hopefully Bitcoiners continue to have the attitude that if some one or some group refuses to let you into their thing, you can build your own.