Open letter to core devs (reflections/questions from the op_return saga and proposal to establish a well-organized channel/link between devs and users)

Philosophy
1

The aim of this post is to address non-technical aspects which are perhaps not receiving the attention they deserve, as well as to provide a single post where core devs can express coherently their stance on some key questions that a relevant section of users would appreciate to have answers to. There seems to be a large disconnect and lack of productive communication between devs and users which is hurting everybody, and this post attempts to establish a clear and respectful dialogue between the 2 parties. The current state of dialogue in the bitcoin community is “not at its peak”, I think we can all agree that we need to do something to re-establish productive dialogue.

The following are a series of reflections, questions and concerns on which we can hopefully all work together on:

Today, after 4 months from @pandacute post which tried to raise concerns that have not been considered valid at the time of his post (https://delvingbitcoin.org/t/behind-the-op-return-drama/1650=), we can indeed claim that some trust between core devs and users has been broken. This is shown by the fact that today 24% of the nodes run Knots (from less than 1% 4 months ago). 24% is the percentage of people who disagree so much with how the change was handled that they switched implementation, I believe we should also consider all the other percentage of users that disagree and will show this by not upgrading to core v.30

I would like to point out that some ppl switched not because they disagree on he technical arguments regarding opening up op_return (this is wrongly consider the only motivation), but rather because of some behaviours that some core devs displayed, namely:

  1. Perceived attempt to force changes on nodes (taking away node configurability)

  2. Dismissal of criticisms from non-technical users (insistence from core devs to consider only technical aspects and not incorporate in the discussion also other aspects, by default if you are not a technical person your opinion on this matter is not considered). This hugely curtails dialogue and make users’ opinions feel rejected/not-considered (the surest way to push someone away), as well as setting the frame for an incorrect dialogue (as long as humans are involved the discussion must be enlarged to human factors, and I’m not talking about feelings, I’m talking about preferences/ values/perceived control).

  3. Public engagement with users is not seen as important, statements like “if you don’t like what core is doing with the code just don’t run it” do not communicate a willingness to have an open stance for dialogue, listening to criticisms, and mutual confrontation

  4. Especially in the last few weeks some core devs have recurred to call to authority to defend their stance, “trust us because we have history of being trustworthy, I would not advise to run the btc implementation run by the person who has not a trustworthy history”. This is perceived as in total opposition to the bitcoin ethos of don’t trust verify and more importantly not to trust authority for the sake of authority

These above are the main factors that have pushed people away from core, and I would like to invite core devs to at least reflect a little bit if any of this might be true and might have played a role in all this situation. Also, could core devs organize together to provide a response to the following questions below? I emphasize “organize together”, a point better elaborated in point “c” below:

a) In light of the developments of the last few months, do core devs still believe that is was the correct decision to take away node configurability in future implementations? Here the question is not technical but rather philosophical, namely: do you believe it is correct to enforce a configuration option that many demanded to keep, even if it is the right technical choice? You can be 100% correct about the change, and a 100% wrong in the manner of implementing it. It would be nice to know if core still believes this was the correct approach (because if they do, then we have to assume that this modus operandi will be used again in the future).

b) In light of the developments of the last few months, do core devs still believe that it was the correct decision to limit the conversation only to technical aspects and not incorporate also other aspects?

c) Do core devs have a plan or are already organizing themselves to establish a clearer and more organized public engagement? In the situation like the one at hand it seems impossible for users to receive an opinion which represents the majority of core devs. Let me explain better: if some core devs say something, and someone then reference what those individuals said as an expression of core stance, core devs reply is “that is just their personal opinion, they don’t speak for the whole core dev team”. Ok, but if this is the case, then how are users to know what is the coherent/majority stance of the core team? In the 2 video link at the bottom of this post, ppl assume that the core devs attending and speaking are expressing the majority of core team stance, it only makes sense. And if they do not, then this highlight a lack of clear organization for core team to express its dominant viewpoint. A “spoke-person” or a forum that aims to channel and present the majority stance of the core team seems to be necessary, otherwise effective and productive communication between core devs and users is impossible. Many core devs rightly complained they wasted hours addressing users concerns on different forums, platforms, posts. This is a result of not having a single organized point where devs and users can effectively carry out an organized dialogue. I keep saying “organized” because a) the conversations today are scattered all over the place and this results in massive waste of time for everybody, b) there is no single voice/channel that expresses core dominant viewpoint, if every core dev has to constantly explain his viewpoint to all different users then we get the confusion and inefficiency we just had

d) Do core devs have a problem with some of their members being involved in conflict of interest activities and are planning to perhaps organize themselves in a different manner? (i.e. Loop and Citrea). I remember various core devs saying that we should not value the PR based on who submitted it, but only on its technical content. That is true, as long as the person who submits the PR is not involved in a conflict of interest. Believing that conflict of interest cannot be taken into account when evaluating a PR is a position that has no place in the real world. From the external, core devs having conflict of interest reflects very poorly on the team as a whole and raises legit suspicions/questions in people. We always complain about conflict of interest issue in our fiat system, why are we allowing the same issue in our btc system?

e) This is not a direct attack, please don’t take it as such, but this is simply a question that must be asked for clarifications. Why are some core devs talking directly and in private setting with businesses like Citrea? (I’m referencing to the last link below). I was not under the impressions that core devs could speak directly and in private setting with on-chain businesses, is this a common practice? Because I’m sure you can understand how this is also a kind of action that raises legit concerns among users

I hope you can see from my post that this is an attempt to provide core devs with an avenue to address some fundamental questions that so far had no answers. If I am allowed to say so, core devs seems to be very willing to engage in technical discussions, but not equally willing to engage in non-tech discussions, and this lack of engagement is what is likely driving the gap between core and plebs further apart.

Reference list for the statements and comments expressed in this post:

https://youtu.be/gbQvU-woY14

https://youtu.be/x-eUUC8Idaw

https://fountain.fm/episode/gniC6BIENiKYYitsSNXX

https://primal.net/e/nevent1qqsr5c87fcc7gawcv4hp9vjx3e6p8wten9v2z0y0qj3nc9nad04x2zqljl0ah

2

Not a Core developer, but FWIW; the fundamental reason for some recent changes like OP_RETURN, full-RBF and minrelaytxfee is that a limitation that does not stop people from doing what it is intended to limit, and that encourages them to instead do it in a way that is actively worse or degrades the network, is a bad limitation.

Keeping the OP_RETURN limit does not prevent people from storing data on the blockchain, since they were already doing so via ordinals etc. For smallish amounts of data, letting people store it in an OP_RETURN instead of abusing witness data is beneficial to both the sender and the network since it does not require an additional chained transaction to “reveal” this data. And there is simply no good reason to increase the datacarriersize to a higher but still arbitrary value, instead of just having it limited by the max transaction size.

Furthermore, node mempool policy that does not match miner mempool policy create a mismatch between the node mempools and the blocks that are being mined, which breaks compact blocks and makes block propagation (very) significantly slower. Nodes enforcing the RBF flag do not prevent miners from running full-RBF. Nodes enforcing a minrelaytxfee of 1 sat/vB do not prevent miners from accepting transactions paying less. And nodes enforcing a lower OP_RETURN datacarriersize do not prevent miners from mining blocks with larger limits. Most miners were doing at least one if not all of those things.

In general, for open source projects, organizing communication from a loose connection of volunteer developers tends to be difficult, and whatever communication there is tends to get lost in the noise. But if you are sufficiently interested in the technical aspects of Bitcoin, there are many mailing lists and other forums you can subscribe to that would have thoroughly informed you of the rationales for these changes, not to mention the Github itself. The devs have better things to do than sit on Reddit and X all day long and argue with people who are already convinced they are right and who won’t listen to reason.

And to address one of your claims;

this is shown by the fact that today 24% of the nodes run Knots (from less than 1% 4 months ago).

According to BitNodes, of the ~7100 nodes with “Knots” in the subver, ~6100 are on tor. Seeing as you can make an unlimited number of onion addresses and map them to a single node, most of these are likely fake.

There seem to be about 800 Knots nodes on IPv4, of a total of 6658, and it’s hard to say how many of these were previously running Core and how many were deployed as new nodes to make the number larger. But seeing as about half of the Knots nodes are running a version that was released only 11 days ago, my money are on a good number of these being run by one or a mere handful of individuals.