path: root/89/8a721f27a72ea4e724608c0c8cfe69727c8b4c

Return-Path: <asperous2@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 73068FF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Sep 2015 01:22:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com
	[209.85.213.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 77FE3E9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Sep 2015 01:22:01 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so8613410igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 Sep 2015 18:22:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:content-type:content-transfer-encoding;
	bh=LFpsk44sYZKADMri4cfUyZ+vXgCQH0qofaRfsSNMFag=;
	b=mYsPkYyPuUMSz9AiSdmJOScBmGLSzcX6e3rOoFEOJS6eT+2JI8CWb4FtEqAYuzsZNb
	NXEwi6mDE7iaPNysf/5bVG2jwAtXoTNJg7pxzxe9DUxHYofqD0f59Qd7qfREBYojZZPf
	IMr07yLWXyjqlp3cA2t7Y4YnwlEXQgBFcc5zt/FWA7uRQf2gRFszhdY/esI89FQ1VILg
	jRVqs59TcvsC+9xdzPTF0FDrVAX0ep3u5ZXDTJud4AtvTF8wjwerdHnWWNl/YduCm9bp
	E0ym/3uPdg/3L2hqZWKrfldXK3ksu8Gx7EKgeyViJaPuTL4+O4QpdFK04cidA5rCb7oD
	Dpsg==
X-Received: by 10.50.6.100 with SMTP id z4mr472705igz.97.1441848120889; Wed,
	09 Sep 2015 18:22:00 -0700 (PDT)
MIME-Version: 1.0
Sender: asperous2@gmail.com
Received: by 10.50.3.33 with HTTP; Wed, 9 Sep 2015 18:21:41 -0700 (PDT)
In-Reply-To: <CADJgMzuRy_Fbv2UaJ4EZzh8DHhYYixu=k6_Z=sKtNJ9SsLTdyQ@mail.gmail.com>
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
	<CABaSBaw7hM2qmuR6Z6USy5=V9NGeCPKmHHuVOH=vexDk7kY8OA@mail.gmail.com>
	<CAAxp-m_vo5vJEemR_hRX3hNcUPveA6EHn-ZFMJo8ke59E6BrKw@mail.gmail.com>
	<CADJgMzvanj41Dfa4kQsq5SVvt-Zeee2SOfD3Uws-FpBQsyZsqg@mail.gmail.com>
	<CAAxp-m_EmMbVBqQK9ijoe+n0dAs726TaBX5m1Wgzsv-m1KHdfQ@mail.gmail.com>
	<CADJgMzuRy_Fbv2UaJ4EZzh8DHhYYixu=k6_Z=sKtNJ9SsLTdyQ@mail.gmail.com>
From: Andy Chase <theandychase@gmail.com>
Date: Wed, 9 Sep 2015 18:21:41 -0700
X-Google-Sender-Auth: r4JI3JMscZ83xNxB5bBb-2A0mPk
Message-ID: <CAAxp-m9Umz4kQQL64UCYGY8Z1PSeM0jpMCa-R064OCMqNJ1nKA@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2015 01:22:02 -0000

Thanks for your response BTC Drak, I will attempt to summarize your
points and respond to them:

* Some BIPs are not consensus critical -- True, see my response to Luke
* BIPs do not imply usage -- This I covered in my paper.
* Acceptance can be defined by actual use -- That's one way of doing it

> Getting back to your specific proposal. It seems to focus more on
> getting BIPs accepted in the sense of published

Wildly incorrect. My BIP had nothing to do with getting published. The
first words you can read in my proposal are as follows:

> The current process for accepting a BIP is not clearly defined. While BIP=
-0001 defines the process for writing and submitting a Bitcoin Improvement =
Proposal to the community it does not specify the precise method for which =
BIPs are considered accepted or rejected. This proposal sets up a method fo=
r determining BIP acceptance.

* but the proposal is "complete" when the proposer is happy with the final =
text.

This would be a cool inclusion. That is the intent of my "Submit for
comments" process.

---

Overall your post seemed to miss the point of my proposal, but that's
likely my fault for poor wording. I'm trying to develop a process of
coming to "consensus" i.e. gathering feedback and reducing opinions
down to a yes/no should this BIP happen or should we find a better
solution.

Importantly, it's not client specific. It's just a way of saying "hey
everyone, here's a problem and solution that a lot of people agree on"
or "hey everyone, here's a problem and solution that has a few
problems with it"

It's true that even if a "BIP" is "accepted" by my proposal it still
may not actually happen (this is mentioned in my proposal), and I
believe that's healthy. We can't force a change on anyone nor should
we.

---

Since so many people are missing the actual problem I'm solving,
here's another way of wording it: A BIP is proposed and goes through
the process. A PR is submitted that matches the BIP perfectly, and is
submitted and vetted. Should wladimir merge it?

My process isn't perfect solution that would make it so we could
replace wladimir with a wladBot. But it's a tool we can use for
gathering meaningful information to help guide that decision. Waiting
on all objections to be handled works okay so far but won't work
forever.


On Mon, Sep 7, 2015 at 12:37 PM, Btc Drak <btcdrak@gmail.com> wrote:
>
> Sorry not to reply earlier. I have a rather long post. I've split it
> into two sections, one explaining the background and secondly talking
> very specifically about your proposal and possible areas to look at.
>
> I think there's a key misunderstanding about BIPs and "who decides
> what in Bitcoin". A BIP usually defines some problem and a solutions
> or helps communicate proposals to the technical community. They are
> sort of mini white papers on specific topics often with reference
> implementations attached. They may be consensus critical, or not. The
> process for getting a BIP published is fairly loose in that it really
> just requires some discussion and relevance to Bitcoin regardless of
> whether the proposal is something that would be accepted or used by
> others in the ecosystem. The BIP editor is obviously going to filter
> out obvious nonesense and that shouldn't be controversial but obvious
> when you see it.
>
> You need to separate out the idea of BIPs as is, and implementations
> of BIPs in Bitcoin software (like Bitcoin Core).
>
> Take BIP64 for example. It's a proposal that adds a service to nodes
> allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
> as a project has not implemented it but was instead implemented in XT
> and is utilised by Lighthouse. So the BIP specification is there in
> the BIPs repository. As far as the bitcoin ecosystem goes, only
> Bitcoin XT and lighthouse utilise it so far.
>
> BIP101 is another example, but one of a consensus critical proposal
> that would change the Bitcoin protocol (i.e. requires a hard fork). It
> was adopted by only the XT project and so far no other software. At
> the time of writing miners have chosen not to run implementations of
> BIP101.
>
> You can see the BIPs authoring and publishing process is a separate
> issue entirely to the implementation and acceptance by the Bitcoin
> ecosystem.
>
> For non-consensus critical proposals like BIP64, or maybe one relating
> to privacy (how to order transaction output for example), you could
> judge acceptance of the proposal by the number of software projects
> that implement the proposal, and the number of users it impacts. If a
> proposal is utilised by many projects, but not the few projects that
> have the majority of users, one could not claim wide acceptance.
>
> For consensus critical proposals like BIP66 (Strict DER encoding) this
> BIP was implemented in at least two bitcoin software implementations.
> Over 95% of miners adopted the proposal over a 4.5 month period. The
> BIP became de facto accepted, and in fact, once 95% lock-in was
> achieved, the BIP became Final by rights that the consensus rules for
> the Bitcoin network had changed.
>
> In the case of consensus critical proposals like that, you can only
> write proposals, implement it in software and hope they are adopted.
>
> Now where does the confusion arise? Well, Bitcoin Core is the de facto
> reference implementation by virtue of having the largest technical
> contributor base and the widest userbase of any Bitcoin full node
> implementation. This is where I believe, the community get stuck in
> their assumptions and is so obvious it may have been overlooked.
>
> Consensus rule changes to Bitcoin Core are always documented as BIPs
> so the exact details can be picked up by other software implementers
> (if they so desire). Take CHECKLOCKTIMEVERIFY a new widely anticipated
> opcode. The proposal implemented in Bitcoin Core and eventually
> merged. Peter also authored BIP65 (required because without it, his
> proposal could not be considered for Bitcoin Core).
>
> It is not that BIP65 was somehow "accepted", in fact, as it stands,
> BIP65 is still just a draft because while there is a BIP and a
> reference implementation in Bitcoin Core, the consensus changes to the
> Bitcoin protocol have not been proposed to the community (through a
> soft fork), and thus acceptance is still only a possibility (although
> acceptance is extremely likely because service providers are literally
> chomping at the bit waiting for deployment).
>
> Also I would like to note that it's only an internal rule of Bitcoin
> Core that consensus rule changes require a formal BIP. It is not a
> requirement laid down from the BIP gods. BIPs simply serve as a way to
> communicate ideas and proposals. The community at large will decide if
> a BIP becomes widely adopted or not. Of course, Bitcoin Core has a
> major influence on this because they have the largest user base. It is
> relevant to say the large userbase is not just a historical artefact
> by virtue of being the first Bitcoin implementation. Bitcoin Core is
> widely trusted by commercial users because of the high developer
> count, wide technical expertise and relative security given knowing
> that they will be supported with security and maintenance releases.
>
> YOUR PROPOSAL
>
> Getting back to your specific proposal. It seems to focus more on
> getting BIPs accepted in the sense of published and missed the wider
> picture. As I have detailed, getting published isnt a problem. Anyone
> can make a proposal, so long as it's not obviously off topic or
> nonsensical, there is no grounds to refuse to publish it.
>
> Any part of your proposal which seems to infer governance of Bitcoin
> is misplaced because it's not the place of BIPs. The Bitcoin Core
> project is not the BIPs project and their rules are their own. They
> are one implementation, and very influential one yes, but, not the one
> true implementation to rule them all.
>
> Where I do think the BIP-1 text falls down is with the workflow of
> ACCEPTED/REJECTED because it does not really define who is accepting
> and rejecting what and misses much of the reality of the process in
> the real world. Given the purpose of BIPs is a formal way to
> communicate technical proposals to the bitcoin community (i.e.
> implementers and protocol consumers) the work flow needs to be
> adjusted.
>
> Anyone can submit a proposal and the state of the proposal can be
> DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
> it's a work in progress, but the proposal is "complete" when the
> proposer is happy with the final text. Downstream implementers should
> not attempt to write code (in my opinion) until the proposal has been
> finalised by the authors. Only the author has the right to say when
> their proposal is finished.
>
> The states of Accepted / Rejected are easy for consensus critical
> changes, especially once versionbits softforking is enacted and
> proposals will have a timeout associated. Certainly for deployed
> proposals you could say the proposal is "active" or better still
> "pending approval". However "accepted" and "rejected" is difficult for
> say privacy standards because how can you gauge or measure it. As I
> said earlier, you might have a lot of small projects implementing some
> privacy standards, but if the major wallets dont, and thus the
> majority of users, how would you gauge it?
>
> Something is a standard only when it becomes a standard by virtue of
> having become a standard :)
>
> "Replaced" is an easy state, when another proposal supercedes and
> replaces an older one. Again the wording could be better here.
> "deprecated" would also be appropriate in some circumstances.
>
> I'm not making a concrete proposal, I'm just highlighting where BIP-1
> sort of falls apart because of an incongruence with the workflow
> states and what actually happens in real life.
>
> Local to the BIPs project, I do think the BIPs editor, and guidelines
> try to filter proposals by raising the bar: i.e. requiring proposal to
> be polished through peer review before they are formally published as
> draft BIPs. Though this process an author would a) get most of his
> details right first time, and b) have some relative confidence his/her
> idea was useful and withdraw any obvious bad proposals themselves. An
> author may still decide, despite many objections from their peers they
> want to proceed with publishing and nothing should stop them providing
> it's relevant to the Bitcoin space. Peer review pressure is likely to
> act as the best filtering mechanism in this case anyway (no-one would
> want to be seen as an ass right?). Personally speaking, I felt quite
> nervous proposing my own blocksize ideas. I sought opinions in private
> first and had it been widely decried would probably not have pursued
> it any further.
>
> So in summary, I think some aspects of BIP-1 could do with polishing
> as I have detailed, specially around the "workflow states" but not to
> introduce any committees to the process, but where possible to extract
> state from the real state of the BIP in the real world. In fact, this
> is my direct argument against any forms of committee, in that the
> state of a BIP is determined by factors outside of any particular
> individual's or groups' purview.
>