From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5acp-00007V-Rz for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 14:17:03 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.171 as permitted sender) client-ip=209.85.212.171; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f171.google.com; Received: from mail-wi0-f171.google.com ([209.85.212.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5ack-0000bC-0e for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 14:17:03 +0000 Received: by wiwd19 with SMTP id d19so24474781wiw.0 for ; Thu, 18 Jun 2015 07:16:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.205.168 with SMTP id lh8mr27423187wic.95.1434637012054; Thu, 18 Jun 2015 07:16:52 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 07:16:51 -0700 (PDT) In-Reply-To: <20150618140544.GA7674@amethyst.visucore.com> References: <55828737.6000007@riseup.net> <20150618111407.GA6690@amethyst.visucore.com> <20150618140544.GA7674@amethyst.visucore.com> Date: Thu, 18 Jun 2015 16:16:51 +0200 X-Google-Sender-Auth: NE9uCowMU7u61i79-JIYxvb5yk4 Message-ID: From: Mike Hearn To: "Wladimir J. van der Laan" Content-Type: multipart/alternative; boundary=001a11c38ace7c3ca10518cb75e5 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z5ack-0000bC-0e Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 14:17:03 -0000 --001a11c38ace7c3ca10518cb75e5 Content-Type: text/plain; charset=UTF-8 > > 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? --001a11c38ace7c3ca10518cb75e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 fr= ee 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 co= de, and BIP 1 is=C2=A0at least clear about that. Otherwise it can tu= rn out during implementation that something was different to what was antic= ipated. 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 a= s writing a BIP is meant to save the potential author time

and

BIP authors= are responsible for collecting community feedback on a BIP before submitti= ng it for review

OK. Gavin has been vetti= ng the idea publicly and collecting community feedback. Note that the entir= e Bitcoin community is not on this list, so he published a series of blog p= osts to get wider feedback, and then was criticised for not doing it all he= re instead.

But anyway - so far, so good.=C2=A0 The procedure is being followed.<= /div>

What h= appens 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 comp= lete description of the proposed enhancement. The enhancement must represen= t a net improvement. The proposed implementation, if applicable, must be so= lid and must not complicate the protocol unduly.
=C2=A0
=C2=A0Once a BIP has been accepted, the reference imple= mentation must be completed.=C2=A0
<= br>
This is where the problem starts.
=
The BIP process you refer to does n= ot state how acceptance will happen. It merely sets out a few minimum r= equirements like making some sort of sense, having code. It's also full= of extremely vague descriptions like "must represent a net improvemen= t". Improvement according to who? That's left unexplained.

And then it s= ays what happens once a BIP is accepted.
The middle bit is missing. When there is= disagreement over a consensus BIP, how are decisions made?


--001a11c38ace7c3ca10518cb75e5--