On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn <mike@plan99.net> wrote:

OK, let's agree to unpack the two things.

The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of "core developers" and if so, who are these people? Is it "whoever reverts the change last"? Could I write down in a document a precise description of how decisions are made? No, and that's been a fairly frustrating problem for a long time.

But let's leave it to one side for a moment.

Let's focus on the other issue: what happens if the Bitcoin Core decision making process goes wrong?

Why do you keep talking about Bitcoin Core maintainers? The means for doing a hard fork is convincing the network to run modified code, whether that is a new version of Bitcoin Core or a fork of it, or something else entirely.

If I see consensus about a proposed network change, I will be in favor of implementing it in Bitcoin Core. But we're not at that point. There is no network change proposed with consensus. There is not even a patch to be discussed. There are working proposals, and people are talking about them. This is good.

I think maintainers of particular software should not be, and are not those who decide the network's rules. People running the code are. Of course maintainers have a large influence, but so do other people - like you.

> This was a reference to a post by Gregory on Reddit where he said if Gavin were to do a pull request for the block size change and then merge it, he would revert it. And I fully believe he would do so!

I believe so too, and I would do the same. Because I believe implementing a consensus rule change without having very good expectations that the network will adopt it, is reckless from the point of view of maintainers, for all reasons I have mentioned before.

Pieter