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:
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:
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.
The discussion over definitions can be easily solved if parties are willing. The discussion over solutions is much harder to resolve as there are simply two mutually exclusive ideas about it and it hasn't sounded like anyone is willing to compromise. I therefore think that solving the definition discussion isn't going to reconcile anything.
The polarization is real. The causes, even including some of the nastier accusations, are probably real too. But the intent each side ascribes to the other is all that is being talked about, and those are missing nuance.
Thus, it's been an echo chamber of shit slinging for years now, and it's probably best ignored.
It seems that this would imply that we should have two separate chains. I'm not sure that such a thing would be a bad outcome, but I am also naive here. Probably there are lots of reasons Bitcoiners have already long-debated why two separate chains = one winner, one loser.
I go through phases where I ignore it and phases where I am caught up in it. When I am caught up in it, I tell myself that perhaps the conversation will be more tenable if there are more voices who aren't willing to shoot for insult and accusation (maybe just not as willing).
https://twiiit.com/LukeDashjr/status/2066654398453792882
That’s a sex thing
Has @Scoresby even read the article? Its main theme is different.
Anyway, @Scoresby can ask the author about the meaning of the datacarrier parameter if it's not clear from the tweet.
This is the bit I keep coming back to.
In a normal infrastructure or business-critical project, you would bring engineering, operations, product, risk, commercial users and decision-makers into one room to separate facts from preferences.
We all know Bitcoin has no CEO or central product owner, and that is part of the point.
But has that cross-camp conversation actually happened?
Maybe I have missed it, but all I seem to see are meeting notes, podcasts, posts and threads from one camp talking to its own side, while the other camp does the same.
What I would like to see is a factual, civil discussion with people from different perspectives in the same room, ideally with a neutral moderator.
Not “Core good” or “Core bad”.
More: what is the actual problem, what are the trade-offs, who is affected, what evidence supports each side, and what would change anyone’s mind?
Did I miss the memo? Are these conversations already being had outside of this site and Bitcoin Twitter?