pull down to refresh

The case for privatizing Bitcoin Core

@kanzure, who is a BIP editor and maintains the Bitcoin Developer Mailing List, recently started a discussion on the mailing list with the subject "The case for privatizing Bitcoin Core."
There is a recurring pattern of non-contributors (sometimes even non-developers) intruding into an online forum intended mainly for people collaborating on Bitcoin Core to work together on whatever they are working on.
His suggestion was to move collaboration to a private, membership-based collaboration space, while still keeping the code open. You can read his post if you are interested in the details of his proposal.
Kanzure noted that any group of people is free to work on Bitcoin Core in whatever way they like and
An alternative to what I am proposing is already happening: development inside closed offices (Chaincode, Brink, Localhost, etc), which is less accessible and less open than a invite-only developer collab site. And also less "open development" than the current Bitcoin Core GitHub project. So a failure to sort out these issues with Bitcoin Core collaboration can and has already produced solutions that are functionally less inclusive than an online member-only source forge.
I'll note that most of the responses to kanzure did not agree with his approach, and this proposal is not likely to happen.1
When I first saw the word "privatizing" I thought, "Wow, that's gonna piss some people off." But I spent a little time thinking about why I felt this, and it got me to something I hadn't fully appreciated about open source.

Open source != freedom of speech

Not being terribly familiar with open source standards, it is easy to let open source blur in my mind with freedom of speech. This is possibly made worse by the use of the free as in speech, not as in beer line when explaining what people mean when they say "free, open source software." But my realization was that open source isn't a promise of rights.
If a person creates a piece of software and makes it open source, this gives absolutely zero rights to anyone else. No one has a right to participate in the project or contribute to it or expect anyone who works on it to do anything in particular.
What it means is that people have choices.
This is also how Bitcoin works. Nobody can force you to run code you don't like and you can't force anyone else to run code they don't like.
Similarly, with development, you can't force anyone to show you what they are working on, nor can you force them to listen to your thoughts on the matter.
There are 10,000 nuances of open source, and I don't pretend to know much at all about any of them, but from this ignorant perspective in which I stand, open source Bitcoin development means
  1. Anyone may see the code
  2. Anyone may change the code
  3. Anyone may run different software if they don't like what a particular implementation is doing
And that's about it.

Everything good always comes back to timshel

I'm a great Steinbeck fan. East of Eden is worth reading with some regularity (as is Tortilla Flat). There is this moment in East of Eden:
After two years we felt that we could approach your sixteen verses of the fourth chapter of Genesis. My old gentlemen felt that these words were very important too—‘Thou shalt’ and ‘Do thou.’ And this was the gold from our mining: ‘Thou mayest.’ ‘Thou mayest rule over sin.’ The old gentlemen smiled and nodded and felt the years were well spent. It brought them out of their Chinese shells too, and right now they are studying Greek.
The gold he's talking about here is that by some magical twist we humans seem2 to have a choice in what we do in this world. Lots of human history is caught up with different people's endeavors at restricting these choices (or navigating them while we try to coordinate), but the experience of being human is that others cannot directly3 control you.
In the same way, open source is timshel: thou mayest look at the code. What you do after that (participate on the terms of whoever maintains the project or fork it and make your own thing) is up to you.

I exerted manful force in only including that tiny little segment from above. But then I remembered footnotes: Here's the much lengthier passage:
Lee laughed. “I guess it’s funny,” he said. “I know I wouldn’t dare tell it to many people. Can you imagine four old gentlemen, the youngest is over ninety now, taking on the study of Hebrew? They engaged a learned rabbi. They took to the study as though they were children. Exercise books, grammar, vocabulary, simple sentences. You should see Hebrew written in Chinese ink with a brush! The right to left didn’t bother them as much as it would you, since we write up to down. Oh, they were perfectionists! They went to the root of the matter.”
“And you?” said Samuel.
“I went along with them, marveling at the beauty of their proud clean brains. I began to love my race, and for the first time I wanted to be Chinese. Every two weeks I went to a meeting with them, and in my room here I covered pages with writing. I bought every known Hebrew dictionary. But the old gentlemen were always ahead of me. It wasn’t long before they were ahead of our rabbi; he brought a colleague in. Mr. Hamilton, you should have sat through some of those nights of argument and discussion. The questions, the inspection, oh, the lovely thinking—the beautiful thinking.
“After two years we felt that we could approach your sixteen verses of the fourth chapter of Genesis. My old gentlemen felt that these words were very important too—‘Thou shalt’ and ‘Do thou.’ And this was the gold from our mining: ‘Thou mayest.’ ‘Thou mayest rule over sin.’ The old gentlemen smiled and nodded and felt the years were well spent. It brought them out of their Chinese shells too, and right now they are studying Greek.”
Samuel said, “It’s a fantastic story. And I’ve tried to follow and maybe I’ve missed somewhere. Why is this word so important?”
Lee’s hand shook as he filled the delicate cups. He drank his down in one gulp. “Don’t you see?” he cried. “The American Standard translation orders men to triumph over sin, and you can call sin ignorance. The King James translation makes a promise in ‘Thou shalt,’ meaning that men will surely triumph over sin. But the Hebrew word, the word timshel—‘Thou mayest’— that gives a choice. It might be the most important word in the world. That says the way is open. That throws it right back on a man. For if ‘Thou mayest’—it is also true that ‘Thou mayest not.’ Don’t you see?”
“Yes, I see. I do see. But you do not believe this is divine law. Why do you feel its importance?”
“Ah!” said Lee. “I’ve wanted to tell you this for a long time. I even anticipated your questions and I am well prepared. Any writing which has influenced the thinking and the lives of innumerable people is important. Now, there are many millions in their sects and churches who feel the order, ‘Do thou,’ and throw their weight into obedience. And there are millions more who feel predestination in ‘Thou shalt.’ Nothing they may do can interfere with what will be. But ‘Thou mayest’! Why, that makes a man great, that gives him stature with the gods, for in his weakness and his filth and his murder of his brother he has still the great choice. He can choose his course and fight it through and win.” Lee’s voice was a chant of triumph.

Footnotes

  1. In particular, @TheCharlatan's response was particularly thoughtful, so I'm including a large portion of it here: "The question around how to handle data embedding and meta protocols through policy has been a major discussion point on the repository for more than a decade. Even with a clear majority of regular contributors agreeing, a decision on the topic was always going to arouse major controversy. The perceived brigading did not impede the project from making progress on the issue. It led to a rare moment of alignment in the form of a common statement, brought more eyes to reviewing the pull requests, and finally led to a resolution of the question. The discussion was also focused on the two pull requests, and did not impede progress on the 300+ others. Contrary to public perception, I also think moderation of the pull requests in question was ok. I especially like that it was kept open by the moderators for people to comment on, since people are clearly still confused on what the change actually does. More importantly it also shows that our organization is still the same scrappy, loose collective of individuals with individual approaches and opinions capable of tolerating dissent. If I were to choose a client to run my money on, these are all soft qualities I'd look out for."
  2. If you don't think humans have any choice, perhaps you should eschew open source software.
  3. Yes, there's violence and manipulation, but I'm still clinging to the idea that I control how I react to them.
270 sats \ 10 replies \ @optimism 10h
Also read Michael Folkson's reply:
The recent statement by Core stating what its current contributors prioritize when designing transaction relay policy [3] and the communication around the recent transaction relay policy pull request (#32404) merge decision [4] I thought was excellent. However to take that precedent on Core transaction relay policy (a signed statement by a set of Core contributors and signposting around the merge decision) and assume it can be applied to a consensus rule change (CTV and CSFS or whatever the current set of opcodes is currently in vogue) requesting Core contributors prioritize review within 6 months is short sighted to put it mildly. Core can make unilateral decisions on transaction policy because consensus compatible forks can have different transaction policy without splitting the chain or the network. It can't make unilateral decisions on a consensus rule change. If there is significant disagreement on a consensus rule change an attempted consensus rule change can split the network and create two currencies.
Hence if Core wants to make merge decisions on transaction relay policy pull requests based on its recent statement I think that is fine. If it wants to hide comments on such a pull request that don't accept that statement I think that is fine. But if it wants to create a set of contributors who think they can effectively decide on consensus rule changes without the input of the broader community that is clearly not fine.
Here's where I'm at:
If you want to retain any reasonable expectation of consensus protocol stability, then having the staging/integration repo is a good worth preserving, no matter the cost. Having the discussions, no matter how hard or abusive, is a necessary part of the process.
If however you don't care what kind of softforks go on the p2p network and you don't care what utterly insane activation parameters (like developer-said-so flag-day activation) people will code into their BIP8/9 deployments, and are willing to actively support and sustain that kind of chaos, then by all means, remove the integration repo.
But realize, that genie will not voluntarily return to the bottle. Once this is done, there is no return to softfork orchestration, and the divides will ultimately widen.
reply
If you want to retain any reasonable expectation of consensus protocol stability
Do you think having a single dominant implementation is the main reason there haven't been more forks (soft or hard) of Bitcoin?
In a way, it's surprising that there hasn't been a somewhat popular spin off of Bitcoin in such a long while. I wonder how much of protocol stability is simply burn-out from the ICO era and altcoins in general. Or perhaps it is Bitcoin success? Any fork is going to be immediately compared to BTC and if it doesn't quickly garner massive adoption, it's a failure.
I suppose these are slightly different questions that what you pose. A fork claiming to continue BTC is not the same as a fork claiming to be something else.
reply
132 sats \ 8 replies \ @optimism 10h
Do you think having a single dominant implementation is the main reason there haven't been more forks (soft or hard) of Bitcoin?
I think that having a reference implementation for the consensus protocol is super important, and for the p2p protocol in lieu of formal spec too.
For the peripheral functionality, from mempool policy (knots) to block template logic (custom pool nodes) to how all this is stored on disk (libbitcoin) it is good to have a reference client, to show other devs how it's done, but since these things aren't touching consensus, it's not something that should be literally copied. Every implementation has leeway in this.
It being the reference client doesn't have to mean it is the dominant implementation in the wild, but it is, so because of this, my answer to your question would be yes, it prevents forks and creates stability.
However, if a majority of maintainers of alternative implementations of the peripheral functions would simply agree that bitcoin/bitcoin is the absolute truth (= reference client) in case of a consensus bug in another implementation, then it doesn't have to be the dominant implementation in the wild. I think the absolute truth part is the case nowadays, iirc Niklas Goegge has done important work on this for both btcd and libbitcoin, and the solution has always been that Bitcoin Core, even when behavior is a bug, is the truth.
What I think we're seeing now is that the peripheral functionality and specifically the choices made by the maintainers of the staging tree are becoming a barrier to the - imho - essential function it serves for graceful integration of consensus (and baseline p2p) functionality. I don't agree that it should be like that, but all sides in this chose escalation. And now we see an even worse, and more escalating, proposal.

I cannot comment on spin-offs, that's just nonsense anyway.
reply
Bitcoin Core, even when behavior is a bug, is the truth.
isn't this the interesting weirdness about Bitcoin? I have a feeling many things touch consensus in unexpected ways. somewhat like removing the checkpoints from Core actually could trigger a fork (it's just really unlikely).
our current situation is that the reference implementation for consensus is still kinda wrapped up with relay policy and the wallet. while i realize work is being done to separate the two, I don't agree with the match Core bug-for-bug approach.
Do I go so far as to say the chain is the reference implementation? Maybe. If you can start with the beginning and sync to the most recent tip, seems like what happens next is up for grabs a little bit. Negotiating consensus in one repo does not seem objectively better than negotiating it in the next block.
Anyway, consensus is such a tricky little bitch.
reply
I don't agree with the match Core bug-for-bug approach.
Okay, then hardfork galore is okay and all the energy spent on pow for inferior chaintips is okay? Sounds like a great way for centralized mining to become the standard. With soft forks at least hashpower doesn't get lost.
Do I go so far as to say the chain is the reference implementation?
Hey bro, nice that you accept bitcoin. Before i transfer some sats over LN, Which blockhash are you on? Ugh.
reply
hardfork galore
...is a claim and I'm curious what evidence you have to support it? There was the btcd issue, but I'm not aware of too many other instanceswhere alt implementations have led to forks.
Running past versions of Bitcoin Core is similar to running an alt implementation (certainly there have been new versions of core that introduced potentially forking changes). Why haven't we seen more forks from miners running old versions of Core?
Good observation that making your code open source doesn't actually confer rights upon anyone. You actually are simply exercising your rights to release your code for free - no one forced you to do that and no one was entitled to anything!
That's a good answer to why FOSS isn't communist, which some people argued in my other thread #1015405
Lastly, I wouldn't agree with turning all communications in Core private. However, if they were to implement pay-to-post, that seems like a good solution to fighting spam.
reply
Pay to post is great, but I doubt it would have changed the volume of posting around the op-return debate. Spam is one thing, but what I think kanzure is getting at is separating the workspace from the public forum for discussing the project.
reply
512 sats \ 0 replies \ @jakoyoh629 6h
When's the IPO?
Nice read, thanks!
reply
102 sats \ 2 replies \ @supratic 7h
I thought was already privatized... not officially, obviously. I wonder how long it will take for bitcoin core devs to step away and join forces with other implementations? or even build new ones?
Ah yet forgot, they are all well paid to stay where they are, under NDAs and other contracts (all KYC obviously) who knows for how long.
reply
63 sats \ 1 reply \ @Scoresby OP 7h
It is in the sense that the maintainers control the repo. Kanzure, I believe, was using the term in the sense of limiting who would be able to view discussion on prs and issues. Currently, anyone can view all of this.
reply
219 sats \ 0 replies \ @supratic 7h
Currently, anyone can view all of this.
yes, and that's how it should be. the only publicly unseen things are the voice conversations happening in the bg. I'm optimists, things will change really soon. This monopoly has been going on for too long.
reply
1333 sats \ 0 replies \ @0xbitcoiner 11h
There are 10,000 nuances of open source, and I don't pretend to know much at all about any of them, but from this ignorant perspective in which I stand, open source Bitcoin development means
One person's ignorance can be a goldmine of knowledge for others. Solid post!
reply
wonderful read. thanks @Scoresby.
reply
102 sats \ 0 replies \ @ivermectin 9h
What if the discussions are still visible, but limit what could participate. I don’t think it’s a good idea, but it is one step softer approach.
reply
0 sats \ 0 replies \ @k00b 6h
I miss Lee.
reply