How is achieved consensus on code change?

[w00t]

Hi,
please pardon my ignorance as I'm not a developer but my question is fairly simple - my understanding is that there is a repository with Bitcoin core code and a lot of people has access to it (dozens). If somebody commits some change (ie. improvement or fix) who confirms that the improvement or fix is propagated to all the end users? Is it one person? Is it by consensus? Does it have to be unanimous?

I'd like to receive comment from somebody who ever did a contribution to the Bitcoin code or really knows how it works.

Thanks!

[1715264782]

1715264782

[1715264782]

1715264782

[achow101]

The github repository for Bitcoin Core is https://github.com/bitcoin/bitcoin. Even though Bitcoin Core is the current reference client, not all changes made to it affect consensus. In fact, almost none of the changes made actually affect consensus. Rather the changes to consensus are first drafted into a BIP, discussed by many developers, implemented, reviewed, tested, and then merged into the code. This process can take a very long time, and usually a lot of changes are made to the proposal.

Consensus changes can cause forks, so in order for everyone to be using the same consensus rules, fork deployment rules for each set of changes are set in place. Some things can be added without requiring everyone to upgrade. These are known as soft forks. Other things require everyone to upgrade or they will no longer be connected to the network; those are called hard forks.

Once deployment parameters are set, the code is further reviewed and then released as another version for people to install. If people want whatever changes were made, they will upgrade to the new versions. If they don't, then they don't have to. In this way, all consensus changes are decentralized. There is no one person or central authority dictating that certain changes must be accepted. The changes are simply released, and if people want to use it, they will upgrade. Otherwise, nothing happens.

[w00t]

Thanks achow101 - clearly written and understood.

As a followup to my topic here: https://bitcointalk.org/index.php?topic=1771426.0;all

Let's say that 10 developers (out of 50, 70 ?) think the block should be increased from 1 MB to 2 MB (hard fork) and the reasoning behind would be that without the change or any change the network will become clogged and less reliable (transactions not going through) - I think the amount of unconfirmed volume proves it at least to some degree.

So what happens then? This is clearly an issue that needs to be addressed somehow and somebody from the 10 developers do the change in the code from 1 MB to 2 MB, commits it and then on technical level what happens? It's going to be rejected/reversed because there was no voting among miners? If I remember correctly there was a time where block size was in free float and no limit existed - but back then I believe Satoshi himself did the change.

Since which BIP miners had to vote on any change to the code? What if there was a flaw found in the code?

[DannyHamilton]

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.

[mezzomix]

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

+ Enough nodes accepting the changed blocks

[Carlton Banks]

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.

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.

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.

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

[DannyHamilton]

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

+ Enough nodes accepting the changed blocks

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.

[Carlton Banks]

the whole concept of bitcoin will be abandoned as a failed experiment.

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

[achow101]

Thanks achow101 - clearly written and understood.

As a followup to my topic here: https://bitcointalk.org/index.php?topic=1771426.0;all

Let's say that 10 developers (out of 50, 70 ?) think the block should be increased from 1 MB to 2 MB (hard fork) and the reasoning behind would be that without the change or any change the network will become clogged and less reliable (transactions not going through) - I think the amount of unconfirmed volume proves it at least to some degree.

So what happens then? This is clearly an issue that needs to be addressed somehow and somebody from the 10 developers do the change in the code from 1 MB to 2 MB, commits it and then on technical level what happens? It's going to be rejected/reversed because there was no voting among miners? If I remember correctly there was a time where block size was in free float and no limit existed - but back then I believe Satoshi himself did the change.

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.

Since which BIP miners had to vote on any change to the code? What if there was a flaw found in the code?

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.

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.

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.

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.

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.

[DannyHamilton]

So, Wladimir isn't preventing blocksize increases, and does not hold the sole veto, as you present it.

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?

Your presentation is inaccurate propaganda to bash Core.

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.

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

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.

[DannyHamilton]

the whole concept of bitcoin will be abandoned as a failed experiment.

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

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.

[DannyHamilton]

if enough regular contributors agree that the changes should be merged, then they will be merged.

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

the change was merged by someone else.

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?

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.

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.

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.

[achow101]

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

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.

[DannyHamilton]

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

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.

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.

The may be more. I'm fairly certain

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.

[Carlton Banks]

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 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

[achow101]

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.

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.

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.

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.

[DannyHamilton]

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.

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.

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 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.

[DannyHamilton]

Pure trolling, because you have no reasonable arguments

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

[Carlton Banks]

Pure trolling, because you have no reasonable arguments

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

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.

[Carlton Banks]

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.

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.

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 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.

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?