Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

From: Mike Hearn <[email-masked]>
Date: Thu, 18 Jun 2015 16:16:51 +0200

>
> If you think it's not clear enough, which may explain why you did not even
> attempt to follow it for your block size increase, feel free to make
> improvements.
>

As the outcome of a block size BIP would be a code change to Bitcoin Core,
I cannot make improvements, only ask for them. Which is what I'm doing.

I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany
his patch, because BIPs are best when they describe working code, and BIP 1
*is* at least clear about that. Otherwise it can turn out during
implementation that something was different to what was anticipated. I'm
sure you agree with this.

So a BIP is coming. However, BIP 1 also says this:

Vetting an idea publicly before going as far as writing a BIP is meant to
> save the potential author time

and

BIP authors are responsible for collecting community feedback on a BIP
> before submitting it for review

OK. Gavin has been vetting the idea publicly and collecting community
feedback. Note that the entire Bitcoin community is not on this list, so he
published a series of blog posts to get wider feedback, and then was
criticised for not doing it all here instead.

But anyway - so far, so good.  The procedure is being followed.

What happens once a BIP is written? The process says:

For a BIP to be accepted it must meet certain minimum criteria. It must be
> a clear and complete description of the proposed enhancement. The
> enhancement must represent a net improvement. The proposed implementation,
> if applicable, must be solid and must not complicate the protocol unduly.

>  Once a BIP has been accepted, the reference implementation must be
> completed.

This is where the problem starts.

The BIP process you refer to *does not state how acceptance will happen*.
It merely sets out a few minimum requirements like making some sort of
sense, having code. It's also full of extremely vague descriptions like
"must represent a net improvement". Improvement according to who? That's
left unexplained.

And then it says what happens once a BIP is accepted.

The middle bit is missing. When there is disagreement over a consensus BIP,
how are decisions made?