Topic: How is achieved consensus on code change? (Read 1974 times)

You didn't tell us a definitive "why", Peter. Let me see if I can guess "A democratic Bitcoin, for all!"

Take your democratic business somewhere else, you know there is more than enough opposition (i.e. support for Core) to relegate your Bitcoin fork to an altcoin, and yet you refuse to launch you coin honestly, and instead insist on disrupting this ecosystem.

Fuck off. You're not welcome.

Bitcoin Unlimited (BU) operates according to its Articles of Federation.  With respect to your question, the GitHub repository is controlled by the BU President (who is presently Andrew Clifford [solex]):

"Cryptocurrency" is the concept behind Bitcoin. And you said:


Didn't take much explanation, seeing as all I had to do was quote you verbatim.


So you literally said exactly that. You can not-appreciate the fact if you like.

And so it turns out that your assertions had little merit anyway. Bit of a backtrack, eh, after you claimed achow101 was being too vague? It seems you know less than he did, and yet you were pretty arrogant and dismissive.

Until he demonstrated that you were the one with vague and outdated information, all of a sudden you were polite, and expecting him to help you with your ignorance?

Your subtly false presentation of reality is a threat to the stability of Bitcoin, your position is always "if Bitcoin can't take my misanthropy, then it deserves to die"


Bitcoin can survive your negative, destructive behaviour, and you're incredibly arrogant to believe that it can't.

Your nonsense is getting boring. I won't be responding to you any more in this thread.

I'm very surprised to hear this.  I really thought that Satoshi was alone in final say on the code while he was around, and that Gavin took over that roll until he left.  I'm not saying you're wrong, just that this doesn't line up with what I remembered.  I suppose I may have been misunderstanding this all along.  I'll have to see if I can find any confirmation of this.


I may spend some time to do this. I was hoping to save some time with reliable information from someone that knew for certain, but I'm capable of checking on it myself.  I'd prefer not to be accidentally spreading false information.

This is simply untrue. I know for a fact that during Gavin's maaintainership Dooglus had commit access for a time. Furthermore, I am pretty sure that Sirius also had commit access while Satoshi was around.


The people I listed are definitively known to have commit access (except Sirius). They were just the ones that I could name off of the top of my head. You can also just look at the git repository and see who has made a merge commit. That will give you a list of everyone who has had commit access.

I can give it a more definitive list once I get back to my computer as I am currently on mobile.

I don't know how you can expect him to know.


Tell us when and why the Unlimited repo commit keys were distributed? You can't, so don't behave as if you are somehow entitled to an answer to your question that is (intentionally) impossible to answer. Pure trolling, because you have no reasonable arguments

Originally Satoshi Nakamoto was the only one with merge access.  When he left, he gave that access to Gavin Andresen.  Gavin maintained sole merge access until he left when he gave that access to Wladimir.  That was the last I heard.  I'm not doubting that Wladimir gave that access to additional individuals, I'm just curious to know when, why, and to whom.  It seems like important information to know if we're going to put our faith in a codebase.


I'm looking for actual knowledge, not guesses based on what you thought you might have heard at sometime in the past from some unknown source.

Wladimir, Pieter Wuille, Marco Falke, Jonas Schnelli all have commit access. The may be more. I'm fairly certain they all got their merge access before Wladimir was maintainer.

By whom?  The code doesn't magically merge itself. Which individuals are responsible for the merging?


By whom?  The last I heard (which admittedly was quite a while ago), Wladimir was the only one with merge access.  Who else has merge access and when did Wladimir give it to them?


Certainly, however, those with merge access have the final say.  They can merge something without approval, and while the other developers might scream and shout about it and demand that no users install it, the code will still be in that version of Core.  They can refuse to merge something that has approval, and while the other developers might scream and shout about it and demand that it be merged, the code still won't be in that version of Core.

Please explain how abandoning bitcoin as a failed experiment would result in "writing off all other possible cryptocurrencies"?  I never said any such thing, and don't appreciate you implying that I did.

Did Wladimir give additional people merge access?  That's great news.  I hadn't heard about it.  When did that happen, and who else has that access?


While you've made it pretty clear that you've been on a propaganda crusade for a while, I have no interest in "bashing core".  Greg Maxwell and I have had discussions in the past and we agree on many things.  There is room for discussion and exchange of ideas without needing to "bash" a group or individual.  Choosing to run XT, Classic, Unlimited, or any other implementation is not an attack on you, the Core developers, or anyone else.  There is nothing magical or divine about being a Core developer.


I never said they were failing.  I implied that right now the majority of hashpower is choosing to run Core compatible code, and that it wasn't clear how badly Core would need to fail before miners would choose to abandon it for some other implementation.

What happens is some developers create the changes and submit a pull request. The code is then reviewed, and if enough regular contributors agree that the changes should be merged, then they will be merged. In order for that to happen though, a couple of things generally have to happen. First, as a general rule of thumb, if a consensus change does not have an associated BIP which thoroughly explains the details on a technical level that someone else can implement it, then the change is rejected. Secondly, it must be implemented as a fork with deployment parameters. This means that when the software is released, the changes are not active. Miners will signal acceptance and enforcement of the change (usually through block version numbers) and once the signalling has passed a certain threshold, the software will automatically switch to the new rules.

If signalling for the fork remains below the threshold, then it will not activate. After some point, there is an expiration. Once the expiration passes, the fork can be considered dead and removed from the code. In this case, it means that everyone has agreed that the consensus change is not necessary.

There is no BIP requiring that forks require signalling, and there is no actual vote (signalling is not a vote). However, since the very first official soft fork (Satoshi did stuff back in the day that could have caused a fork but did not because the community was still small) was BIP 34. Ever since, all forks (consensus changes) have required deployment. The current deployment system is BIP 9 VersionBits.

If there is a flaw, then the release can be retracted and miners advised to not signal for it. The fixes can be made and a new version released. However, these are generally unlikely given that most majorly accepted consensus changes are tested and reviewed for months before being accepted. They are tested on the Bitcoin testnet to ensure that there will be no problems once deployed onto the mainnet.

Not necessarily. Wladimir is not the only person with commit access. There are a lot of areas of the code for which he does not have expertise in, and he relies on other contributors to evaluate the code and recommend it for merging. There have been several Pull Requests merged where Wladimir had no comment and merged after several ACKs, and others where he had no comment and the change was merged by someone else. I'm pretty sure that he has also NACK'ed things that still got merged.

He's not the only person who is NACK'ing those proposals. Almost everybody that is part of the Bitcoin organization on Github (not all are committers) have been rejecting those proposals.

You're writing off all other possible cryptocurrencies except for Bitcoin? Interesting.

While preferred, it is not necessary to get a significant number of nodes to accept the changed blocks.  Once the forking change activates (which triggers based on hashpower and not on node counts) the new larger blocks will be created an broadcast.  The blockchain will fork, and users will get to choose (by choosing which version of the software they run) which fork they want to be on.

Lots of users on the old version and few users on the new just means that lots of users will be on a less secure, but more desired blockchain, and a few users will be on a much more secure, but much less desired, blockchain.

There would be a bit of chaos as the exchange rates adapted to the levels of security and demand.  Eventually, miners that spent a large amount of money mining on a low demand blockchain would find that they weren't profitable.  They'd start losing money and would either need to shut down their operation or switch to the blockchain that had higher demand (and therefore higher exchange rate).  Meanwhile, users that chose to use the less secure blockchain could discover their chain being subject to hashpower attacks such that transactions they thought confirmed suddenly become unconfirmed and disappear.  Loss of time, money, and other resources will drive them to the more secure network.  Eventually either the miners and users will settle on a single version or the whole concept of bitcoin will be abandoned as a failed experiment.

No it isn't, you're deliberately misconstruing the real situation. A blocksize increase has already been committed to the codebase, and it's not just Wladimir who has commit access.

So, Wladimir isn't preventing blocksize increases, and does not hold the sole veto, as you present it. Your presentation is inaccurate propaganda to bash Core.



Explain to us about the way(s) in which Core is failing.

+ Enough nodes accepting the changed blocks

While there is discussion, collaboration, and review, in the end Wladimir J. van der Laan has the final say about Bitcoin Core.  If he decides that code isn't going to be part of Core, then it isn't part of Core.  If he decides that code is part of Core, then it is part of Core.

That code is then published as a version available for anybody that wants to download and run it.  If people don't like changes that are in the new version, then can refuse to download and run it.  They can also choose to switch to some other Bitcoin implementation (such as Bitcoin Classic, Bitcoin XT, Bitcoin Unlimited, etc).  Since forking change typically require some significant amount of hashpower to get behind it before it activates, it is possible for enough miners to refuse to run a particular version. In that case, the forking change never activates.

So, to get an increase in block size in Core, you need:

• A developer to code the change
• Enough support from the developer community to convince Wladimir J. van der Laan to include it in a version
• Enough miners to run that version

If you are missing any of those 3 things, then you can't get the block size increase in Core.  At the moment, this is stalled at the convincing Wladimir J. van der Laan step.  It isn't clear how many miners would adopt the version if Wladimir J. van der Laan approved it.


To get an increase in some other implementation, you need:

• A developer to code the change
• Enough miners to run that implementation

If you are missing either of those 2 things, then you can't get the block size increase in other implementations. At the moment, this is stalled at getting enough miners to run the implementation. It's not clear how badly Core would need to fail before miners will abandon the Core code for some other implementation.