path: root/28/cdbfbdaf498c49507136f4c9546ec0e8073674

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 6355B1062
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Sep 2015 23:50:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com
	[209.85.213.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DD03AA8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Sep 2015 23:50:52 +0000 (UTC)
Received: by igcrk20 with SMTP id rk20so65314143igc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Sep 2015 16:50:52 -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=tIYWFpSoeJ5L+3er16DC8g6qjKtrj/DWzs/6GDLWSlY=;
	b=0yEWPK1Yqf5vMuR35/tYcdu8cqbGpq43YYJt9kEfwCdDdrEPn8Wvkp+nuElVD5ufgv
	43KfvMadFI9zsSTEyfT94PE2tN0ozI8fIVKhvd2khRLPvq1YkfHF5wx+jtNB3Y2ufRgr
	FyFNdc7UXDbZWMwogFeox2Rmkh5eqj3zn9/nd3GiXB89DqEVRZfMhNlpMBW8Bhblsng9
	31OPdPZN4UpchP99WaCi+MkF+gpyMCGoqcokMG9IdjxVCZZJLBtDMY+A6A7XkfEy46i0
	7U4Qbf2RnvxVhAOFrYN8FiAPCxZjUJ8rs2RKS7GcLdYxOCHwTVp7L/BU4myqwLdw4wNm
	A74A==
X-Received: by 10.50.61.172 with SMTP id q12mr7528939igr.43.1442101852297;
	Sat, 12 Sep 2015 16:50:52 -0700 (PDT)
MIME-Version: 1.0
Sender: asperous2@gmail.com
Received: by 10.50.3.33 with HTTP; Sat, 12 Sep 2015 16:50:32 -0700 (PDT)
In-Reply-To: <CAAxp-m9Umz4kQQL64UCYGY8Z1PSeM0jpMCa-R064OCMqNJ1nKA@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>
	<CAAxp-m9Umz4kQQL64UCYGY8Z1PSeM0jpMCa-R064OCMqNJ1nKA@mail.gmail.com>
From: Andy Chase <theandychase@gmail.com>
Date: Sat, 12 Sep 2015 16:50:32 -0700
X-Google-Sender-Auth: QIyqjEFwNsh5EtHYl6osCYaTFFU
Message-ID: <CAAxp-m-dMP4ri1zeoguYiSdHa87Q9yOdLOsN1SJutys4s_X=3g@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,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: Sat, 12 Sep 2015 23:50:54 -0000

Wanted to throw up here some feedback I got off-list. Source:
http://bitco.in/forum/threads/bitcoinxt-dispute-resolution-etc.36/#post-602

=3D=3D=3D=3D [1] =3D=3D=3D=3D

> Interesting.
>
> I like your idea that people can form representational groups which then =
collectively votes ("committees"). Basically an individual can delegate his=
 vote to one, but take it away at any time. This allows one person to do th=
e detail work on behalf of others.
>
> I think that your 2 week then 2 week process is too constrained. I would =
propose that the groups have 2 weeks to respond, then an indetermine time o=
ccurs where the BIP author can work to resolve the open questions by corres=
ponding directly with the groups. Then 2 week final arguments and voting.
>
> I think a clear definition of what "accepted" means would be important. I=
 think that "accepted" should mean that the master github branch, and relev=
ant project releases should incorporate the BIP as soon as reasonably possi=
ble after a branch is created that passes security and code competence chec=
ks. In other words, the "YES" votes may have to implement the BIP or pay to=
 have it implemented.
>
> I think that you need to clearly define how the different groups prove th=
eir stake, and perhaps specify maximum ratios. That is, you can't have 100 =
committees with 99 merchant processors and 1 miner.

=3D=3D=3D=3D [2] =3D=3D=3D=3D

Timeline
--------

that's an important point. I've gotten that echoed from a few people
now. I was thinking that a re-submit could be called if more time is
needed but I think your method of allowing the author to have control
over the pace makes a lot of sense.

What does accepted mean? "Accepted" is the hardest thing to grasp in
this paper. There's just no way to force client authors, users, and
miners, to integrate and use a change, even if one is accepted by my
process. I.e. I'm trying to define what "accepted" even means, but
maybe I should use different words that don't have baggage. Like my
process could indicate "community greenlight" and client authors who
refuse to follow "community greenlight" can do so, but they are going
against the wishes of the community and that becomes obvious. Other
client others (like btcd) might follow the greenlight recommendation
instead and users are free to switch to that. Then there could also be
"community redlight", and "no decision reached" in which there was
conflicting views.

If I go this route, I could use the word "accepted" to mean something
like "appears in the longest fork", or "is in use by multiple clients,
merchants, & users" (for things like urls that aren't
blockchain-related).

How to prove stake?
--------------------

"How groups prove their stake" is the hard question that has to be
addressed in this proposal or any. I've pushed forward several
recommendations but there's no perfect solution that everyone will
accept. For users, in the comments I suggested a "community sample"
method that requires that only a random few people in a group to give
up their privacy.

Ratios
------


The "accepted" or "greenlit" standard in my proposal is defined as:
least 70% of the represented percentage stake in 3 out of the 4
Bitcoin segments. It's true that it seems weird to have 1 group in a
segment by itself (seems like too much power), you have to recall that
committees can consist of several groups that have agreed to act
together. If the 1 miner group had conflicts they'd separate to make
public both their views.

I'm interested in if you think that definition should be changed or if
you are worried about those risks.

=3D=3D=3D=3D [3] =3D=3D=3D=3D

> What does accepted mean?
> ------------------------
>
> I like your "community greenlight" idea to cover how BIPs apply to the la=
rger community of wallet providers. However, I also think that there should=
 be stronger language applied to the Bitcoin Core or Bitcoin XT (if a XIP i=
s submitted). That language should make it absolutely clear that committers=
 can't revert or refuse to commit a change that implements the "greenlighte=
d" BIP just because they don't agree with it.
>
> How to prove stake?
> -------------------
>
> I think we need to nail this down (even if imperfectly) to make this BIP =
real. Personally, I think that there should be at least one way to anonymou=
sly vote (say by owning coins). But I don't feel that there's any need to p=
reserve anonymity for the other stakeholders. In fact, for some groups I th=
ink it would be bad to allow anonymous voters. If you own a bunch of coins,=
 or prove massive mining capacity, there can be no doubt that you are incen=
tivized to vote for what is best for bitcoin. But some vocal forum writer, =
speaker or professor might not care about Bitcoin's ultimate success, or be=
 a paid shill or sockpuppet. But requiring identity at least these people a=
re putting a little bit of their personal reputation behind their comments.=
 Of course, companies already disclose their identities so no problem there=
.
>
> But how do we choose which indirect stakeholders (companies, etc) get a v=
ote? All I can think is that coin owners vote that this company is in fact =
important... this would be a once every 5 years or something vote not somet=
hing you can give or take away every time a BIP is proposed.
>
> Ratios
> ------
>
> Somehow I missed that in your doc. Your proposal seems ok, although it ma=
y be hard to get consensus at those levels. And honestly I think that miner=
s have too much power already -- I think that Bitcoin should be optimizing =
itself for users not for infrastructure. At the same time, I hope that mine=
rs realize that their business model requires consumer users (vs corporate =
users like bank 2 bank) so will probably vote what they believe is best for=
 consumers..

On Wed, Sep 9, 2015 at 6:21 PM, Andy Chase <theandychase@gmail.com> wrote:
> 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 BI=
P-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 f=
or determining BIP acceptance.
>
> * but the proposal is "complete" when the proposer is happy with the fina=
l 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.
>>