Recently, PRs going to change Bitcoin Core's default OP_RETURN policy raised quite a controversy. You may guess I am opposing this change and you are right. I have not expressed my ideas anywhere as I always wait for better arguments from advocates (of course it is also waiting for learning and convincing). Maybe it is too late, as one of the PRs have been merged, however, I want to leave something , as least for myself.
Before that, let me make some other words: seriously taking this topic requires us to give up unfounded accusations towards certain developers and opinion expressers, their relating interests and personal motivations (in fact it is necessary for every serious debate). These accusations do not mean any valid arguments, neither for advocates nor for opponents. This post is not for anyone seeking these accusations. AND I will not name anyone in this post.
There are two PRs relevant: (1) PR#32359, which remove the relay policy code enforcing OP_RETURN output size and count (within one transaction) limits, including relevant config options -datacarrier and -datacarriersize (as after remove, they have no means), we call it "the old PR"; (2) PR #32406, which remove count limit (so that several outputs can share one single size limit) and set the default size limit as 10000 bytes, while keeping above config options for next version(release), we call it "the new PR". Both of them remove the count limit and relax the size limit. Nowadays, the old PR was rejected and the new PR was merged.
So, what make this change a good one or a bad one? Before we deep in, let's make a thought experiment.
Let's assume we have a overwhelming argument in support of this change - relaxing the OP_RETURN transaction relay limitation on the network. However, we still have two ways to bring it into the real work.
(1) Start a loose movement (e.g. happening on social networks, podcasts, and blogs) to convince node operators to config their node to relax the limitation (i.e. set -datacarriersize=10000). (Please keep in mind that this option lives in Bitcoin Core for a long time.)
(2) Change Bitcoin Core's code to reset the default value of -datacarriersize as 10000 and remove the count limit, which is the current case.
You may say that the results of them are not exactly the same - the first path doesn't remove the count limit, unless we release a specific software patch for users (according to some developers' advocates to opponents, they think it is possible). But this difference doesn't matter much here, as theoretically we can push the remove into the code (without relaxing the default size limit) at first, and both of the above paths remain.
Of course, these two paths are not mutually exclusive - after we merge the new PR, we still can continue the loose movement. And none of them make the other unjustified or unseasonable. Even the argument for change policy in two paths can be the same, just happens in different space.
But they will lead to the SAME result, given that we have a overwhelming argument. That's what I want to say.
The first path is not just a practical path, but a mirror, telling us what does the second path actually means. No one will deny it - they are different, and specifically, asymmetric for different groups.
In my opinion, both advocates and opponents post many valid and invalid arguments. But this time I will fucus on important-facts-based argument from advocates, as I want friends on my part to understand more about their competitors, and these arguments have the best possibilities to be above "overwhelming arguments".
- Make local mempool as close as possible with the coming blocks helps block propagation on the network, due to compact block relay (BIP152) feature widely deployed on the network, which can reduce the advantages big miners over small miners, thus keeping mining decentralized.
- Briefly, with BIP152, when local mempool have all of the transactions in the new block, the node will be able to verify and store the new block with a small piece of data, instead of requiring the whole block from peers. It cuts bandwidth needed. So it can also enhance the security of decentralized consensus of bitcoin network.
- Make local mempool more complete also improves transaction fee estimation, which is essential for some implementations of layer 2 protocol depending on time-sensitive block confirmation.
- For example, lightning channels may rely on transactions getting confirmation on time to keep money safe at some case. But there are also implementations without/with-minimal mempool assumptions.
- Relaxing relay limitation of OP_RETURN outputs may attract explicit token/state protocols (different with implicit token protocols like RGB/Taro) to use OP_RETURN outputs - the least harmful way to on-chain confirm data - with its economics, rather than other more harmful way (which currently do not have limitations and technically not suitable to enforce limitations).
- Compare to fake outputs, which looks like normal outputs but actually is unspendable, i.e. hiding data in the public keys, OP_RETURN avoids UTXO set expansion, as you don't need to store them in the UTXO set (prunable). UTXO set expansion has long-stand negative effects on the network.
- Compare to inscriptions (put data into witness field of taproot input), OP_RETURN outputs do not discount the data's size, so it avoids block byte size expansion (given that the user fee costs remain the same). However, these two methods have different effects in the perspective of programing.
- One other side effect is also about mining decentralization - bigger RE_RETURN transactions will be seen on the public network, rather than on big miners' mempool.
It is important to note that, as you may see, these arguments rely on an expectation(assumption) about future transaction market to be sufficiently reasonable (which is able to convince us). If in the future, explicit token transactions are widely accepted and often use bigger OP_RETURN outputs, I absolutely agree with that we need relaxing. But what if it is not the case? We get just not worse than today? No. Code change is not free. (At least for this time, as we can see, it costs so much trust.)
Fine. Let's go back.
If we choose the first path, we don't need to change the code, node operators been convinced will do their part, then the network "updates/imporves". Obviously it will be slow, and laborious. However, it will be less controversial and Bitcoin Core's developers looks more neutral. It is easy to defeat opponents in philosophy - you can not determine others' node. No one need to apply a patch from unknown source or use a less secure software. No one is "forced" to choose between security with config option. Just slow, right?
How about the second path? What make the second path different with the first path is not those arguements justifing relaxing, but the context users meet these arguements. Everybody knows that Bitcoin Core is the mainstream node implementation on the network and that thers is something called "default effect" - in most cases, the default values for config options would not be changed by the users. So how can you not be more stressful/aggresive if you are an opponent? In my opinion, these two fact constitute a kind of power towards bitcoin network. When change Bitcoin Core's code, you are not just making decisions for Bitcoin Core project and part of its users, but the network in some extent. (I see some developers did not deny this.) I would say, some complex emotion (fear and disappointment) arised because of that the power is using - some developers are using this power to change the world, rather then keep distance from it. (If the process is open, the arguements are valid, what is the matter with change the world with power? Uh, a really good question, for you the reader.)
Then, as a opponent, you may have to apply a patch (in versions after next version), or use another software.
Once again, it is not a judgement towards anyone's morality or integrity. No one is obligated to choose the first path (so the second path). Developers have no obligation to develop softwares satisfing my every requirement. I am just making a guess that if the first path was choose, people will be more calmer. At least for me, it is true.
So the last part is my opinions towards recent change of Bitcoin Core's OP_RETURN policy. I break it into two parts.
First, about the arguements from advocates. They are valid by themselves, but none of them or their combination can justify deleting/abandon the config option.
In my opinion, the most valued part of bitcoin network and community is its peer discussion culture. A philosophy match this culture is believing individuals' reason and respect their self-determination as much as possible. Developers have no obligation to implement every possible config options, but it is better to keep them if they already exists (yes, moral concepts are not good ways to talk about this, but good/bad idea would not be cancelled).
A node, is at first itself, then a part of the network. It must burden the payload of engagement of consensus (propagation and validation of the blockchain) to be a node. But after that, it should be free to behave differently with others, as long as it does not attack others. We know that with many features, nodes costing minimal resources can help the whole network. But even in these cases, I would argue, their willing should also be respected. A change in usage of resources should be well documented and leave config options if possible.
If our nodes are only robots enforcing the realization of developers towards bitcoin network, the sense of running them for us will be discounted, even disappeared.
Second, about the path. I, personally, don't like the idea of using the power to change the world. To me, there are so much negative examples. Slow is fast. A short cut may involve hidden risks (after the event, we have see some).
That's all.