Quote from: w00t on February 01, 2017, 02:52:34 PM

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.

Quote from: w00t on February 01, 2017, 02:52:34 PM

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.

Quote from: DannyHamilton on February 01, 2017, 03:22:51 PM

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.

Quote from: DannyHamilton on February 01, 2017, 03:22:51 PM

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.