How is an agreement on a BIP on GitHub reached?

[BlackJacky]

Hi,

I would like to know who is deciding if an BIP on GitHub is implemented in the Bitcoin core? Who is deciding it? I always here "the community is" but who is the community...the miners?

Thanks for an answer

[TierNolan]

The process for a BIP is basically

- discuss the feasibility of the BIP on the mailing list

- receive a BIP number
-- this is supposed to happen unless the BIP is clearly a bad idea
-- a request for draft reference code might be made at this point

- create the code that implements the BIP on the reference client

- code is discussed

- Core developers decide if they will include the code

- new version of the software is released with the updated code

- when 95% of miners (by hash) accept the updated code, the change is locked in
-- This works as a rolling vote (950 of the last 1000 blocks are mined by miners with updated code)

[BlackJacky]

Thanks!

I would see a major key moment:

The "Core developers decide if they will include the code". What if the community would like to have the update but the core developers are not implementing it?

[TierNolan]

The "Core developers decide if they will include the code". What if the community would like to have the update but the core developers are not implementing it?

The person proposing the BIP could go directly to the miners with his version of the code.  If he can convince 95% of them to use his code, then that counts as the BIP being accepted.

That is not likely to work though.  The latest BIP was released at the end of January and it still hasn't hit 95% support.  It is at around 70% at the moment, though it is rising slowly.

Even with core developer support, it is taking a while for miners to use the updated software.  Some "random" person is not likely to be able to convince them.  Using non-standard software could cause them to end up on a bad fork.

There is some disagreement about increasing the block size between the core developers.  That is a hard fork though.  In theory, that means 100% (including non-miners).  In practice, 100% isn't really required, but it risks splitting the coin in two, so it should be high 90's probably.

[altcoinex]

Also See https://en.bitcoin.it/wiki/BIP_0001
Most notably the section titled 'BIP Work Flow' for a detailed explanation.

[btchris]

TierNolan isn't wrong, but his answers are limited to BIPs which cause hard forks (on everyone's mind these days w.r.t. the blocksize limit...).

BIPs which don't cause hard soft forks do not need 95% miner support. BIPs don't need to be suggestions for Bitcoin Core or even the Bitcoin network. They can be purely informational in nature, e.g. BIP-32.

(Just some additional perspective....)

[TierNolan]

BIPs which don't cause hard forks do not need 95% miner support.

That's true, though I think you mean soft forks.

Information -> no agreement threshold required
Soft fork -> 95% of miners
Hard fork -> large support from everyone

Miners can't force through a hard fork.  That requires everyone to update their software.

[fbueller]

Not all BIPS require any action in bitcoin core. It's the reference implementation, but BIPS are improvements that serve the entire ecosystem. Eg, some are specific ways to derive a HD wallet, but bitcoin core doesn't make use of HD wallet code in there.

[btchris]

BIPs which don't cause hard forks do not need 95% miner support.

That's true, though I think you mean soft forks.

Oops, silly mistake on my part, thanks....

[doug_armory]

Miners can't force through a hard fork.  That requires everyone to update their software.

I was under the impression that, moving forward, the process would be at least somewhat like the soft fork process. Sure, miners can't jam it through, but there has to be some sort of orderly rollout. If BC Core rolled in support for >1MB blocks and such blocks started appeared overnight, the results would be...ugly, to say the least. Part of the problem is that there's no way to upgrade everybody, unlike the early days, when there were very few users and (IIRC) Satoshi induced some hard forks due to catastrophic bugs. The current soft fork standard seems fine to me since it's impossible to get all users on board; alerts can go out on the network, and somebody will always refuse to upgrade for any number of reasons.

Of course, I could be wrong about all this. Also, as you pointed out, any BIP that doesn't require a fork can be implemented at any time. For example, BIP 32 is pretty widespread now, and that one didn't require a fork.

[TierNolan]

I was under the impression that, moving forward, the process would be at least somewhat like the soft fork process.

There is no real safe way of doing it.

Sure, miners can't jam it through, but there has to be some sort of orderly rollout. If BC Core rolled in support for >1MB blocks and such blocks started appeared overnight, the results would be...ugly, to say the least.

With a hard fork, getting consensus first is important.

The problem is how to handle it if complete consensus isn't achievable.  The 95% rule with soft forks recognises that getting everyone to agree is to high a standard, but it still requires near total agreement. 

It is pretty clear that complete consensus isn't required, even for hard forks.  If 95% of miners and 95% of merchants updated, then everyone else would have to update too.

Part of the problem is that there's no way to upgrade everybody, unlike the early days, when there were very few users and (IIRC) Satoshi induced some hard forks due to catastrophic bugs. The current soft fork standard seems fine to me since it's impossible to get all users on board; alerts can go out on the network, and somebody will always refuse to upgrade for any number of reasons.

Of course, I could be wrong about all this. Also, as you pointed out, any BIP that doesn't require a fork can be implemented at any time. For example, BIP 32 is pretty widespread now, and that one didn't require a fork.

I think giving notice is the best bet.  If 95% of the miners say that "starting with block 400,000 we will be using larger blocks", then that gives notice to everyone else to update.

Satoshi could have made the 1MB "anti-DOS" rule expire and I don't think anyone would have objected.

The suggestion on the mailing list is to look at the client names in the version message.  If most nodes end up using the large-block version of the client, then that shows that there is wide support for larger blocks.  It wouldn't be an automatic thing, but a way to show that there is consensus for larger blocks.

The large block debate could set the rules for how to handle hard forks that don't have complete agreement.