diff options
| author | Andy Chase <theandychase@gmail.com> | 2016-01-18 20:23:31 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-01-19 04:23:52 +0000 |
| commit | cfc6daacbd162d034acdfe5a5ea8559a83ce7f6a (patch) | |
| tree | af95dfdea8c53050aee8e302eead7c7e3fc3146c | |
| parent | b7de3d5a8de9a36de93ee9da43f998f3c6e56b03 (diff) | |
| download | pi-bitcoindev-cfc6daacbd162d034acdfe5a5ea8559a83ce7f6a.tar.gz pi-bitcoindev-cfc6daacbd162d034acdfe5a5ea8559a83ce7f6a.zip | |
Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
| -rw-r--r-- | fd/0636cd747d0c65ce2e48bd971f646efe20fa74 | 431 |
1 files changed, 431 insertions, 0 deletions
diff --git a/fd/0636cd747d0c65ce2e48bd971f646efe20fa74 b/fd/0636cd747d0c65ce2e48bd971f646efe20fa74 new file mode 100644 index 000000000..4cbc8358b --- /dev/null +++ b/fd/0636cd747d0c65ce2e48bd971f646efe20fa74 @@ -0,0 +1,431 @@ +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 4CFA7A71 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 19 Jan 2016 04:23:52 +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 1C42713C + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 19 Jan 2016 04:23:51 +0000 (UTC) +Received: by mail-ig0-f171.google.com with SMTP id z14so69114761igp.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 18 Jan 2016 20:23:51 -0800 (PST) +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:cc:content-type; + bh=xXRK10Lby7KlOr/8xfv+/N2O13F7RpgGlOSFK1qof8Q=; + b=lGE27Nv/Yw64mKB2OZFH4iK7dvV2tsSFXOUe8EMTLRLWTOYXFhTX/exwY1SDqixgZA + FicCQ3pePaRHk+ne/mvDiiwGFptoSNzofugA7iC7JEkpan/zcjojYE97fKTLsGL70wu+ + x3JOPlsPFkF/b1Uicovt3AMZkm+pbv2zm4Wnf70o6VxjPqw//ZuUpb8es6JeQj97xjcP + eU4EwsjI/z/LoCXycApy6r9UyEeqTrV7FjjHMwUWo8TU8kSZigImvfzGtmu7SAKogoPj + ixMDvev4N1t5DP6Io9q+doyA5OxHGMTMsk67Lu5XQTf6DyJ6mm11+LGMIEBqkYlriT25 + G5sQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:sender:in-reply-to:references:from + :date:message-id:subject:to:cc:content-type; + bh=xXRK10Lby7KlOr/8xfv+/N2O13F7RpgGlOSFK1qof8Q=; + b=FVHMybndlBDY/NroaTJJyeDEExON8dJOepqPMdqBQsKwirKwY9VNfJkg0Ib3hr0qn6 + k2izzKBzVyBROgXB8tBHwqdox+e9Rk1+JhOR1Ig3HWmX1NrT/bY8J6OTZ4f/vHOkD1KV + 97UOTuf5XEFF6es1CLhQmBYaf8BcrU9g0OEHQM+Gruf+WaoyYHnArq9j1rOHvmOBWMkU + YUyLjno2OjMma3rO+FKpXiZf0uO6wst6d3uUfCL27OWm4+vkKy79OusPz7F2sWEtoCcK + UfHy/IKFEWp04qmTe6clF/J+vxswhr1K/qkEAFOhKgzgvW0PG0gHGf61H3Itn9CWuMT2 + 7IsQ== +X-Gm-Message-State: AG10YOQ/3ckFNxnmza+34XBHxUMsmXq2POQrB4X/bwAqQN6fkNhgbBsNU/BuIurBoPpHiHLvs4tbs4o3qLQlPQ== +X-Received: by 10.50.41.68 with SMTP id d4mr14539264igl.31.1453177430515; Mon, + 18 Jan 2016 20:23:50 -0800 (PST) +MIME-Version: 1.0 +Sender: asperous2@gmail.com +Received: by 10.50.122.103 with HTTP; Mon, 18 Jan 2016 20:23:31 -0800 (PST) +In-Reply-To: <201601190212.30685.luke@dashjr.org> +References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com> + <201509042145.34410.luke@dashjr.org> + <CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com> + <201601190212.30685.luke@dashjr.org> +From: Andy Chase <theandychase@gmail.com> +Date: Mon, 18 Jan 2016 20:23:31 -0800 +X-Google-Sender-Auth: L5jsDGG-qUNEXe2egyjhj7c1ahY +Message-ID: <CAAxp-m_AFAB7BgHpXvorMeUovxK+TmUD9j7Hwv9bVBXysYfmnw@mail.gmail.com> +To: Luke Dashjr <luke@dashjr.org> +Content-Type: multipart/alternative; boundary=089e011768e78aa7fe0529a83caf +X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, + HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_SBL autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Tue, 19 Jan 2016 15:37:01 +0000 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, gmaxwell@gmail.com +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: Tue, 19 Jan 2016 04:23:52 -0000 + +--089e011768e78aa7fe0529a83caf +Content-Type: text/plain; charset=UTF-8 + +Thanks for your comments Luke. + +> Are you saying your proposal is intentionally not intended to reflect the +reality? + +That's right. I want to be able to include more voices and be able to get a +clearer idea of acceptance then the process currently has available. + +This process should work alongside the current one; not replace it. + +> conditions under which a proposal is *known to be* accepted by the +community + +*known to be* Is what I'm working towards; yes; but I think we need +additional tools/processes to determine that then what we currently have +available. + +> As mentioned, IMO a committee shouldn't be indicating acceptance, as much +as +it should be *determining* acceptance. + +The committee determine acceptance when taking their opinions in aggregate. +The source of their indication might be similar to what we currently have +(esp for Core Devs, etc.) + +> That sounds very time consuming + +Ok + +> And what happens if these committees don't represent the community? + +The committee structures are fluid-- that is users are able to re-organize +at any time. + +> What about when only part of the community - let's say 10% - decides to +adopt a BIP that doesn't require consensus + +This might happen, but is not a flaw in my process. My process makes it +clear they are going against the acceptance of the rest of the community. I +don't intend to "force" anyone to implement or use an accepted BIP. If that +is desired that's outside the scope of this BIP. + +> But the Bitcoin user base is completely unknown, and tracking software +user base is a privacy violation. + +I made a suggestion for this here: +https://gist.github.com/andychase/dddb83c294295879308b + +If there are other ways for honest but anonymous voting mechanisms (that +aren't proof-of-stake since that's proof-of-most-money) I'd be all ears. + +> Bitcoin economic activity is also unknown +> This needs a proper specification. How do miners express their positions? + +I agree these are flaws in the proposal. I'm not sure that one way of +indicating should be considered valid forever, but may have to change over +time. + +> Chosen how, and by whom? + +I think the process could be used to determine this. + +> but I don't think we can just let the author set any conditions they like +either + +I'm not sure what you mean here but would love more information. + +On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr <luke@dashjr.org> wrote: + +> On Saturday, September 05, 2015 9:19:51 PM Andy Chase wrote: +> > Okay for sure yeah writing another proposal that reflects the current +> state +> > of affairs as people see it might provide some interesting perspective on +> > this proposal. I would welcome that. +> +> Are you saying your proposal is intentionally not intended to reflect the +> reality? I wasn't talking about a "current state of affairs" for BIPs as +> much +> as that that the acceptance of BIPs is *defined by* the state of affairs. +> +> Overall, I think something *similar to* this proposal is a good idea, but I +> disagree with how this proposal currently approaches the problem. Instead, +> what I would recommend is a specification based on BIP 123 that specifies +> the +> conditions under which a proposal is *known to be* accepted by the +> community +> (ie, discerning, not deciding), and establishes a way for a committee to +> review the BIP and *determine* if these conditions have been met. This +> would +> avoid a "disconnect" between the "official status" and reality, making the +> BIP +> process more useful to everyone. +> +> Reviewing your current proposal: +> +> > * It sets up '''committees''' for reviewing comments and indicating +> > acceptance under precise conditions. +> +> As mentioned, IMO a committee shouldn't be indicating acceptance, as much +> as +> it should be *determining* acceptance. +> +> > ** Committees are authorized groups that represent client authors, +> miners, +> > merchants, and users (each as a segment). Each one must represent at +> least +> > 1% stake in the Bitcoin ecosystem. +> +> 1% seems like an awful lot to dedicate to BIP status changes. +> +> > A committee system is used to organize the essential concerns of each +> > segment of the Bitcoin ecosystem. Although each segment may have many +> > different viewpoints on each BIP, in order to seek a decisive yes/no on a +> > BIP, a representational authoritative structure is sought. This structure +> > should be fluid, allowing people to move away from committees that do not +> > reflect their views and should be re-validated on each BIP evaluation. +> +> That sounds very time consuming. And what happens if these committees don't +> represent the community? What about when only part of the community - let's +> say 10% - decides to adopt a BIP that doesn't require consensus? Logically +> that BIP should still proceed... +> +> > ** Proof of claim and minimum 1% stake via: +> > *** Software: proof of ownership and user base (Min 1% of Bitcoin +> userbase) +> +> But the Bitcoin user base is completely unknown, and tracking software user +> base is a privacy violation. +> +> > ** Merchant: proof of economic activity (Min 1% of Bitcoin economic +> > activity) +> +> Bitcoin economic activity is also unknown, and it seems likely that +> merchants +> consider their own activity confidential. +> +> > Mining: proof of work (Min 1% of Hashpower) +> +> This needs a proper specification. How do miners express their positions? +> +> > A BIP Process Manager should be chosen who is in charge of: +> +> Chosen how, and by whom? +> +> > == Conditions for activation == +> > +> > In order for this process BIP to become active, it must succeed by its +> own +> > rules. At least a 4% sample of the Bitcoin community must be represented, +> > with at least one committee in each segment included. Once at least one +> > committee has submitted a declaration, a request for comments will be +> called +> > and the process should be completed from there. +> +> Until this BIP is active, its rules do not apply, so this would be a form +> of +> circular reasoning. I like the idea of putting conditions for activation in +> the BIP text, but I don't think we can just let the author set any +> conditions +> they like either... +> +> Luke +> + +--089e011768e78aa7fe0529a83caf +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Thanks for your comments Luke.</div><div><br></div>&g= +t; Are you saying your proposal is intentionally not intended to reflect th= +e<div>reality?</div><div><br></div><div>That's right. I want to be able= + to include more voices and be able to get a clearer idea of acceptance the= +n the process currently has available.</div><div><br></div><div>This proces= +s should work alongside the current one; not replace it.</div><div><br></di= +v><div>>=C2=A0conditions under which a proposal is *known to be* accepte= +d by the community</div><div><br></div><div>*known to be* Is what I'm w= +orking towards; yes; but I think we need additional tools/processes to dete= +rmine that then what we currently have available.</div><div><br></div><div>= +>=C2=A0<span style=3D"font-size:12.8px">As mentioned, IMO a committee sh= +ouldn't be indicating acceptance, as much as</span></div><span style=3D= +"font-size:12.8px">it should be *determining* acceptance.</span><div><span = +style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1= +2.8px">The=C2=A0committee=C2=A0determine acceptance when taking their opini= +ons in aggregate. The source of their=C2=A0indication might be=C2=A0similar= +=C2=A0to what we currently have (esp for Core Devs, etc.)</span></div><div>= +<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-= +size:12.8px">>=C2=A0That sounds very time consuming</span></div><div><sp= +an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz= +e:12.8px">Ok</span></div><div><span style=3D"font-size:12.8px"><br></span><= +/div><div><span style=3D"font-size:12.8px">>=C2=A0And what happens if th= +ese committees don't=C2=A0</span><span style=3D"font-size:12.8px">repre= +sent the community?</span></div><div><span style=3D"font-size:12.8px"><br><= +/span></div><div><span style=3D"font-size:12.8px">The committee structures = +are fluid-- that is users are able to re-organize at any time.</span></div>= +<div><br></div><div><span style=3D"font-size:12.8px">>=C2=A0What about w= +hen only part of the community - let's=C2=A0</span><span style=3D"font-= +size:12.8px">say 10% - decides to adopt a BIP that doesn't require cons= +ensus</span></div><div><span style=3D"font-size:12.8px"><br></span></div><d= +iv><span style=3D"font-size:12.8px">This might happen, but is not a flaw in= + my process. My process makes it clear they are going against the acceptanc= +e of the rest of the community. I don't intend to "force" any= +one to implement or use an accepted BIP. If that is desired that's outs= +ide the scope of this BIP.</span></div><div><span style=3D"font-size:12.8px= +"><br></span></div><div><span style=3D"font-size:12.8px">>=C2=A0But the = +Bitcoin user base is completely unknown, and tracking software user=C2=A0</= +span><span style=3D"font-size:12.8px">base is a privacy violation.</span></= +div><div><span style=3D"font-size:12.8px"><br></span></div><div><span style= +=3D"font-size:12.8px">I made a suggestion for this here:=C2=A0<a href=3D"ht= +tps://gist.github.com/andychase/dddb83c294295879308b">https://gist.github.c= +om/andychase/dddb83c294295879308b</a></span></div><div><span style=3D"font-= +size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">If ther= +e are other ways for honest but=C2=A0anonymous=C2=A0voting mechanisms (that= + aren't proof-of-stake since=C2=A0that's proof-of-most-money) I'= +;d be all ears.</span></div><div><br></div><div><span style=3D"font-size:12= +.8px">> Bitcoin economic activity is also unknown</span><br></div><div><= +span style=3D"font-size:12.8px">>=C2=A0</span><span style=3D"font-size:1= +2.8px">This needs a proper specification. How do miners express their posit= +ions?</span></div><div><span style=3D"font-size:12.8px"><br></span></div><d= +iv><span style=3D"font-size:12.8px">I agree these are flaws in the proposal= +. I'm not sure that one way of indicating should be considered valid fo= +rever, but may have to change over time.</span></div><div><span style=3D"fo= +nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">>= +=C2=A0</span><span style=3D"font-size:12.8px">Chosen how, and by whom?</spa= +n><br></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp= +an style=3D"font-size:12.8px">I think the process could be used to determin= +e this.</span></div><div><br></div><div><span style=3D"font-size:12.8px">&g= +t;=C2=A0but I don't think we can just let the author set any conditions= + t</span><span style=3D"font-size:12.8px">hey like either</span></div><div>= +<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-= +size:12.8px">I'm not sure what you mean here but would love more inform= +ation.</span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail= +_quote">On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr <span dir=3D"ltr"><= +<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>>= +;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = +.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, September 05= +, 2015 9:19:51 PM Andy Chase wrote:<br> +> Okay for sure yeah writing another proposal that reflects the current = +state<br> +> of affairs as people see it might provide some interesting perspective= + on<br> +> this proposal. I would welcome that.<br> +<br> +Are you saying your proposal is intentionally not intended to reflect the<b= +r> +reality? I wasn't talking about a "current state of affairs" = +for BIPs as much<br> +as that that the acceptance of BIPs is *defined by* the state of affairs.<b= +r> +<br> +Overall, I think something *similar to* this proposal is a good idea, but I= +<br> +disagree with how this proposal currently approaches the problem. Instead,<= +br> +what I would recommend is a specification based on BIP 123 that specifies t= +he<br> +conditions under which a proposal is *known to be* accepted by the communit= +y<br> +(ie, discerning, not deciding), and establishes a way for a committee to<br= +> +review the BIP and *determine* if these conditions have been met. This woul= +d<br> +avoid a "disconnect" between the "official status" and = +reality, making the BIP<br> +process more useful to everyone.<br> +<br> +Reviewing your current proposal:<br> +<br> +> * It sets up '''committees''' for reviewing co= +mments and indicating<br> +> acceptance under precise conditions.<br> +<br> +As mentioned, IMO a committee shouldn't be indicating acceptance, as mu= +ch as<br> +it should be *determining* acceptance.<br> +<br> +> ** Committees are authorized groups that represent client authors, min= +ers,<br> +> merchants, and users (each as a segment). Each one must represent at l= +east<br> +> 1% stake in the Bitcoin ecosystem.<br> +<br> +1% seems like an awful lot to dedicate to BIP status changes.<br> +<br> +> A committee system is used to organize the essential concerns of each<= +br> +> segment of the Bitcoin ecosystem. Although each segment may have many<= +br> +> different viewpoints on each BIP, in order to seek a decisive yes/no o= +n a<br> +> BIP, a representational authoritative structure is sought. This struct= +ure<br> +> should be fluid, allowing people to move away from committees that do = +not<br> +> reflect their views and should be re-validated on each BIP evaluation.= +<br> +<br> +That sounds very time consuming. And what happens if these committees don&#= +39;t<br> +represent the community? What about when only part of the community - let&#= +39;s<br> +say 10% - decides to adopt a BIP that doesn't require consensus? Logica= +lly<br> +that BIP should still proceed...<br> +<br> +> ** Proof of claim and minimum 1% stake via:<br> +> *** Software: proof of ownership and user base (Min 1% of Bitcoin user= +base)<br> +<br> +But the Bitcoin user base is completely unknown, and tracking software user= +<br> +base is a privacy violation.<br> +<br> +> ** Merchant: proof of economic activity (Min 1% of Bitcoin economic<br= +> +> activity)<br> +<br> +Bitcoin economic activity is also unknown, and it seems likely that merchan= +ts<br> +consider their own activity confidential.<br> +<br> +> Mining: proof of work (Min 1% of Hashpower)<br> +<br> +This needs a proper specification. How do miners express their positions?<b= +r> +<br> +> A BIP Process Manager should be chosen who is in charge of:<br> +<br> +Chosen how, and by whom?<br> +<br> +> =3D=3D Conditions for activation =3D=3D<br> +><br> +> In order for this process BIP to become active, it must succeed by its= + own<br> +> rules. At least a 4% sample of the Bitcoin community must be represent= +ed,<br> +> with at least one committee in each segment included. Once at least on= +e<br> +> committee has submitted a declaration, a request for comments will be = +called<br> +> and the process should be completed from there.<br> +<br> +Until this BIP is active, its rules do not apply, so this would be a form o= +f<br> +circular reasoning. I like the idea of putting conditions for activation in= +<br> +the BIP text, but I don't think we can just let the author set any cond= +itions<br> +they like either...<br> +<span class=3D"HOEnZb"><font color=3D"#888888"><br> +Luke<br> +</font></span></blockquote></div><br></div> + +--089e011768e78aa7fe0529a83caf-- + |