path: root/ae/2164109a782e3784d45f2bc525160faff2fa08

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 CB82211F3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 Sep 2015 20:13:39 +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 45A8F11C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 Sep 2015 20:13:38 +0000 (UTC)
Received: by igbni9 with SMTP id ni9so22066942igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 04 Sep 2015 13:13:37 -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;
	bh=tQhVn4b5LvcPKj90Fn4VJzggsRWUSdFftv84V4MbiGA=;
	b=MKSGT5A0KNYEe5HT/eLUbjZOMHGKbSfSmPiHKV/yunAbnDSKG7S/qMOzbLF2oXmw9x
	LYP+mz/t9fpO7L38GwgnMTyPTK3uiqgwwW/hmw4+OWdU6NrOiXWAX2QzIOifnXoaV1QQ
	YKjh3MHwDnQRZg/66xTMlqCmt8eskWVaVPYFpYHhwO+eaDAj4G4lsnv3ZTDQk+StUXWv
	LdJxmZ39GF2Ekc+DXa74bY5OvDGIYFkhbYmR6TgYY65+nsa47SLD8JDeOgvqlSGq3smV
	DGcYkbD+1BtbVHxHjBl2O9WqmJ4AYm/ylBW5qrdWu4QhgR8qm1KZLSm2OSRbYhXwxsFV
	bWWQ==
X-Received: by 10.50.36.106 with SMTP id p10mr10692880igj.31.1441397617728;
	Fri, 04 Sep 2015 13:13:37 -0700 (PDT)
MIME-Version: 1.0
Sender: asperous2@gmail.com
Received: by 10.50.3.33 with HTTP; Fri, 4 Sep 2015 13:13:18 -0700 (PDT)
In-Reply-To: <CADJgMzvanj41Dfa4kQsq5SVvt-Zeee2SOfD3Uws-FpBQsyZsqg@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>
From: Andy Chase <theandychase@gmail.com>
Date: Fri, 4 Sep 2015 13:13:18 -0700
X-Google-Sender-Auth: ssKHE4HzcWzFUDtf_oNtSbhiAlQ
Message-ID: <CAAxp-m_EmMbVBqQK9ijoe+n0dAs726TaBX5m1Wgzsv-m1KHdfQ@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0115ebd0fc247a051ef188be
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,
	HTML_MESSAGE,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: Fri, 04 Sep 2015 20:13:39 -0000

--089e0115ebd0fc247a051ef188be
Content-Type: text/plain; charset=UTF-8

Thanks for your thoughts.

My proposal isn't perfect for sure. There's likely much better ways to do
it. But to be clear what I'm trying to solve is basically this:

Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
users? Let's set up a system where everyone has a say and clear acceptance
can be reached.

---

My motivation for writing this proposal is stated right at the start:
> "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."

BIPs are considered "accepted" right now based on an undefined system,
quite honestly. Btc Drak: What's the system for accepting a BIP? Words like
"consensus" come up but they aren't defined. My goal is to define a system
that makes finding "consensus" (I like the word "acceptance" better) in a
clear and fair way.

I.e. what's broken?

* Being sure that a proposal is widely accepted or rejected
* Preventing deadlock (i.e. one person's weak objections preventing
acceptance)
* Receiving feedback from important segments like user groups,
merchants/exchanges, etc. in a systematic and clear way instead of going
and forth or having "oracles" on technical advisory boards.

> Yes the process is loose, but is it broken?

Yes/No. Work gets done with the current process. Work can get done with
this process. The goal is for this process is to be safer/clearer/better
defined way.

> There have been a flood of
> BIPs added recently with zero bureaucracy or friction.

As we move forward, we want to balance the powers in such a way that we may
want to pause a bit before we accept each proposal. 2 weeks for comments +
2 weeks for opinions will slow things down, but it shouldn't stall
meaningful work. I used 4 weeks for the process with the understanding that
most proposals are clear and easily acceptable. Controversial proposals
will likely need more time and thus will likely have be submitted at least
twice to discover a clear response.

"Accepting" a BIP means just that: It's accepted. What's acceptance mean?
This proposal provides an answer.

Client implementations, users, miners, and merchants can feel safe
implementing and using a feature that has clear acceptance. This process
isn't meant to force anything on client implementors, users, miners, or
merchants.

On Fri, Sep 4, 2015 at 12:20 PM, Btc Drak <btcdrak@gmail.com> wrote:

> I'm rather perplexed about this proposal. What exactly is wrong with
> the existing BIPs process? I mean, it seems to me anyone can publish a
> BIP pretty easily in the BIPs repository. There doesnt seems to be any
> real barrier to entry whatsoever. I know there have been all manner of
> aspersions, but having just written two BIPs there was no friction at
> all.
>
> Whether the ecosystem adopts a BIP is another question of course, but
> that's out of scope of the BIPs project anyhow. Take BIP101
> controversial as it gets, but it's there. Whether Bitcoin implementers
> implement it is another kettle of fish and a matter for each project
> to decide. It's absolutely NOT the realm of the BIPs project itself.
> Bitcoin Core does not make any consensus critical changes with a BIP.
> Where one seeks to establish certain standards, say for privacy, a BIP
> would be appropriate so the ecosystem can harmonise methodology across
> the board.
>
> The status of a BIP is not really determined by anyone, it's by
> adoption - that's where consensus happens. There's a little legroom
> around this but I'm not entirely sure what you are trying to solve.
> Yes the process is loose, but is it broken? There have been a flood of
> BIPs added recently with zero bureaucracy or friction.
>
> BIP0001 is the BIP that defines the BIP process. Interestingly enough
> the only BIP that might be controversial is in fact a BIP to change
> the way BIPs are handled!
>
> So I'd really prefer to start this conversation with a breakdown of
> what you think is broken first before tackling what may or may not
> need fixing. I would be very cautious bringing "administrative"
> burdens to the process or evicting common sense from the proceedings.
> Much of the debates around consensus building seem to negate the
> importance of common sense and the simple fact that "it's obvious when
> you see it".
>
> I'm sure there can be improvements, but for me personally, I need to
> see what is broken before I can make any judgement on a potential way
> forward, and if it's not broken, we should leave it alone.
>
>
> On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > As posted:
> >
> > **Enforcement/Organization** I agree with your comments. I don't believe
> in
> > setting up an organization to manage this process (would be too much
> power
> > and not really needed because the internet is pretty good at information
> > sharing). Therefore, I designed it around the assumption that
> participation
> > is voluntary. This means that it's hard to enforce rules like forcing
> groups
> > to see the other side. Groupthink/Echo chambers is real and is bad but
> it's
> > hard to change human nature.
> >
> > In regards to enforcement, I believe that the best approach would be to
> > motivate committees to produce the best opinion they can (and also proof
> of
> > stake, another weak point in this proposal), as the better they can do
> this
> > the more likely the community will accept their opinion as valid and
> > important.
> >
> > Indeed, I believe that without an organization managing the process,
> it's up
> > to each individual reader of each BIP/Opinions set to make the decision
> on
> > whether or not there is clear and true community acceptance.
> >
> > ----
> >
> > **Committee versus another approach**
> >
> > Pros of using Committees:
> >
> > * Committees are used today in many fields with a range of success. Lots
> of
> > previous work to work off of here, history is established.
> > * Many segments already have committee-like structures (Merchants produce
> > shared signed documents, miners often represent themselves, User groups
> have
> > representatives like voting on subreddit moderators, Core Devs have Core
> > Devs)
> > * Committees can filter a range of opinions down to a yes/no
> > * Committees have real people that can be talked to, contacted, etc.
> > * Much easier to proof stake in a range (People generally accept the
> Bitcoin
> > Core has 70-90% of the market share) vs someone trying to proof they
> make up
> > (.000001% of the Bitcoin user-base)
> > * Committees have some stability, encourages experience and expertise
> > (Committee members can be knowledgeable in their area and adequately
> > understand BIPs)
> >
> > Cons:
> >
> > * Fear of committees working in the dark, censoring opinions (i.e. "Dark
> > smokey room of fat cats") (Possible solution: make committee power fluid
> > i.e. easily abandon-able: miners can change pools, users can change
> client
> > forks, change merchants, users can re-group, encourage transparency)
> > * More centralized, centralization of power (generally bad) (Possible
> > solution: encourage smaller committees)
> > * Centralization pressure (groups may seek to consolidate to gain power)
> > (Possible solution: Segmentation)
> > * Encourages groupthink, political maneuvers, turns good people into
> > politicians, mud-tossing
> >
> > **Another possible approach: micro votes**
> >
> > Pros:
> >
> > * Each user can represent themselves, no censorship
> > * People feel more involved and empowered
> >
> > Cons:
> >
> > * How to prove and prevent manipulation?
> > * Only motivated people will contribute. Motivated people may be
> motivated
> > for bad reasons.
> >
> >
> > On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure@gmail.com> wrote:
> >>
> >> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> > I wrote the BIP mostly to stir the pot on ideas of governance
> >>
> >> Some quick comments:
> >>
> >> I have some objects that I am not ready to put into words, but I do
> >> think there are easily some major objections to committee design. If I
> >> vanish and never respond with my objections, perhaps there's an IETF
> >> RFC about this already....
> >>
> >> Something that may mitigate my possible objections would be some
> >> mandatory requirement about ecosystem echo-chambers making many
> >> attempts and efforts at steelman representations of alternative
> >> viewpoints. Understanding objections at a fundamental level, enough to
> >> make strong steelman statements, is very important to ensure that the
> >> competing opinions are not censored from consideration. Pathological
> >> integration and internalization of these steelman arguments can be
> >> very useful, even if the process looks unusual.
> >>
> >> Your process does not have to replace any particular BIP process
> >> as-is, but rather could be an alternative that proceeds on its own
> >> perhaps indefinitely without replacement. I don't think too many BIP
> >> processes are necessarily incompatible except by namespace collision.
> >>
> >>
> https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
> >>
> >> - Bryan
> >> http://heybryan.org/
> >> 1 512 203 0507
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

--089e0115ebd0fc247a051ef188be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks for your thoughts.=C2=A0</div><div><br></div><=
div><div>My proposal isn&#39;t perfect for sure. There&#39;s likely much be=
tter ways to do it. But to be clear what I&#39;m trying to solve is basical=
ly this:</div><div><br></div><div>Who makes high-level Bitcoin decisions? M=
iners, client devs, merchants, or users? Let&#39;s set up a system where ev=
eryone has a say and clear acceptance can be reached.</div></div><div><br><=
/div><div>---</div><div><br></div><div>My motivation for writing this propo=
sal is stated right at the start:<br></div><div>&gt; &quot;The current proc=
ess for accepting a BIP is not clearly defined. While BIP-0001 defines the =
process for writing and submitting a Bitcoin Improvement Proposal to the co=
mmunity it does not specify the precise method for which BIPs are considere=
d accepted or rejected.&quot;</div><div><br></div><div>BIPs are considered =
&quot;accepted&quot; right now based on an undefined system, quite honestly=
. Btc Drak: What&#39;s the system for accepting a BIP? Words like &quot;con=
sensus&quot; come up but they aren&#39;t defined. My goal is to define a sy=
stem that makes finding &quot;consensus&quot; (I like the word &quot;accept=
ance&quot; better) in a clear and fair way.</div><div><br></div><div>I.e. w=
hat&#39;s broken?</div><div><br></div><div>* Being sure that a proposal is =
widely accepted or rejected</div><div>* Preventing deadlock (i.e. one perso=
n&#39;s weak objections preventing acceptance)</div><div>* Receiving feedba=
ck from important segments like user groups, merchants/exchanges, etc. in a=
 systematic and clear way instead of going and forth or having &quot;oracle=
s&quot; on technical advisory boards.</div><div><br></div><div><span style=
=3D"font-size:12.8px">&gt; Yes the process is loose, but is it broken?</spa=
n><br></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">Yes/No. Work gets done with the current proce=
ss. Work can get done with this process. The goal is for this process is to=
 be safer/clearer/better defined way.</span></div><div><span style=3D"font-=
size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">&gt;=C2=
=A0</span><span style=3D"font-size:12.8px">There have been a flood of</span=
></div><span style=3D"font-size:12.8px">&gt; BIPs added recently with zero =
bureaucracy or friction.</span><div><span style=3D"font-size:12.8px"><br></=
span></div><div><span style=3D"font-size:12.8px">As we move forward, we wan=
t to balance the powers in such a way that we may want to pause a bit befor=
e we accept each proposal. 2 weeks for comments + 2 weeks for opinions will=
 slow things down, but it shouldn&#39;t stall meaningful work. I used 4 wee=
ks for the process with the understanding that most proposals are clear and=
 easily=C2=A0acceptable. Controversial proposals will likely need more time=
 and thus will likely have be submitted at least twice to discover a clear =
response.</span></div><div><br></div><div>&quot;Accepting&quot; a BIP means=
 just that: It&#39;s accepted. What&#39;s acceptance mean? This proposal pr=
ovides an answer.</div><div><br></div><div>Client implementations, users, m=
iners, and merchants can feel safe implementing and using a feature that ha=
s clear acceptance. This process isn&#39;t meant to force anything on clien=
t implementors, users, miners, or merchants.</div><div><div><div><br></div>=
</div></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, S=
ep 4, 2015 at 12:20 PM, Btc Drak <span dir=3D"ltr">&lt;<a href=3D"mailto:bt=
cdrak@gmail.com" target=3D"_blank">btcdrak@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">I&#39;m rather perplexed about this proposal. What exac=
tly is wrong with<br>
the existing BIPs process? I mean, it seems to me anyone can publish a<br>
BIP pretty easily in the BIPs repository. There doesnt seems to be any<br>
real barrier to entry whatsoever. I know there have been all manner of<br>
aspersions, but having just written two BIPs there was no friction at<br>
all.<br>
<br>
Whether the ecosystem adopts a BIP is another question of course, but<br>
that&#39;s out of scope of the BIPs project anyhow. Take BIP101<br>
controversial as it gets, but it&#39;s there. Whether Bitcoin implementers<=
br>
implement it is another kettle of fish and a matter for each project<br>
to decide. It&#39;s absolutely NOT the realm of the BIPs project itself.<br=
>
Bitcoin Core does not make any consensus critical changes with a BIP.<br>
Where one seeks to establish certain standards, say for privacy, a BIP<br>
would be appropriate so the ecosystem can harmonise methodology across<br>
the board.<br>
<br>
The status of a BIP is not really determined by anyone, it&#39;s by<br>
adoption - that&#39;s where consensus happens. There&#39;s a little legroom=
<br>
around this but I&#39;m not entirely sure what you are trying to solve.<br>
Yes the process is loose, but is it broken? There have been a flood of<br>
BIPs added recently with zero bureaucracy or friction.<br>
<br>
BIP0001 is the BIP that defines the BIP process. Interestingly enough<br>
the only BIP that might be controversial is in fact a BIP to change<br>
the way BIPs are handled!<br>
<br>
So I&#39;d really prefer to start this conversation with a breakdown of<br>
what you think is broken first before tackling what may or may not<br>
need fixing. I would be very cautious bringing &quot;administrative&quot;<b=
r>
burdens to the process or evicting common sense from the proceedings.<br>
Much of the debates around consensus building seem to negate the<br>
importance of common sense and the simple fact that &quot;it&#39;s obvious =
when<br>
you see it&quot;.<br>
<br>
I&#39;m sure there can be improvements, but for me personally, I need to<br=
>
see what is broken before I can make any judgement on a potential way<br>
forward, and if it&#39;s not broken, we should leave it alone.<br>
<br>
<br>
On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev<br>
<div><div>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; As posted:<br>
&gt;<br>
&gt; **Enforcement/Organization** I agree with your comments. I don&#39;t b=
elieve in<br>
&gt; setting up an organization to manage this process (would be too much p=
ower<br>
&gt; and not really needed because the internet is pretty good at informati=
on<br>
&gt; sharing). Therefore, I designed it around the assumption that particip=
ation<br>
&gt; is voluntary. This means that it&#39;s hard to enforce rules like forc=
ing groups<br>
&gt; to see the other side. Groupthink/Echo chambers is real and is bad but=
 it&#39;s<br>
&gt; hard to change human nature.<br>
&gt;<br>
&gt; In regards to enforcement, I believe that the best approach would be t=
o<br>
&gt; motivate committees to produce the best opinion they can (and also pro=
of of<br>
&gt; stake, another weak point in this proposal), as the better they can do=
 this<br>
&gt; the more likely the community will accept their opinion as valid and<b=
r>
&gt; important.<br>
&gt;<br>
&gt; Indeed, I believe that without an organization managing the process, i=
t&#39;s up<br>
&gt; to each individual reader of each BIP/Opinions set to make the decisio=
n on<br>
&gt; whether or not there is clear and true community acceptance.<br>
&gt;<br>
&gt; ----<br>
&gt;<br>
&gt; **Committee versus another approach**<br>
&gt;<br>
&gt; Pros of using Committees:<br>
&gt;<br>
&gt; * Committees are used today in many fields with a range of success. Lo=
ts of<br>
&gt; previous work to work off of here, history is established.<br>
&gt; * Many segments already have committee-like structures (Merchants prod=
uce<br>
&gt; shared signed documents, miners often represent themselves, User group=
s have<br>
&gt; representatives like voting on subreddit moderators, Core Devs have Co=
re<br>
&gt; Devs)<br>
&gt; * Committees can filter a range of opinions down to a yes/no<br>
&gt; * Committees have real people that can be talked to, contacted, etc.<b=
r>
&gt; * Much easier to proof stake in a range (People generally accept the B=
itcoin<br>
&gt; Core has 70-90% of the market share) vs someone trying to proof they m=
ake up<br>
&gt; (.000001% of the Bitcoin user-base)<br>
&gt; * Committees have some stability, encourages experience and expertise<=
br>
&gt; (Committee members can be knowledgeable in their area and adequately<b=
r>
&gt; understand BIPs)<br>
&gt;<br>
&gt; Cons:<br>
&gt;<br>
&gt; * Fear of committees working in the dark, censoring opinions (i.e. &qu=
ot;Dark<br>
&gt; smokey room of fat cats&quot;) (Possible solution: make committee powe=
r fluid<br>
&gt; i.e. easily abandon-able: miners can change pools, users can change cl=
ient<br>
&gt; forks, change merchants, users can re-group, encourage transparency)<b=
r>
&gt; * More centralized, centralization of power (generally bad) (Possible<=
br>
&gt; solution: encourage smaller committees)<br>
&gt; * Centralization pressure (groups may seek to consolidate to gain powe=
r)<br>
&gt; (Possible solution: Segmentation)<br>
&gt; * Encourages groupthink, political maneuvers, turns good people into<b=
r>
&gt; politicians, mud-tossing<br>
&gt;<br>
&gt; **Another possible approach: micro votes**<br>
&gt;<br>
&gt; Pros:<br>
&gt;<br>
&gt; * Each user can represent themselves, no censorship<br>
&gt; * People feel more involved and empowered<br>
&gt;<br>
&gt; Cons:<br>
&gt;<br>
&gt; * How to prove and prevent manipulation?<br>
&gt; * Only motivated people will contribute. Motivated people may be motiv=
ated<br>
&gt; for bad reasons.<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop &lt;<a href=3D"mailto:kan=
zure@gmail.com" target=3D"_blank">kanzure@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt; I wrote the BIP mostly to stir the pot on ideas of governance=
<br>
&gt;&gt;<br>
&gt;&gt; Some quick comments:<br>
&gt;&gt;<br>
&gt;&gt; I have some objects that I am not ready to put into words, but I d=
o<br>
&gt;&gt; think there are easily some major objections to committee design. =
If I<br>
&gt;&gt; vanish and never respond with my objections, perhaps there&#39;s a=
n IETF<br>
&gt;&gt; RFC about this already....<br>
&gt;&gt;<br>
&gt;&gt; Something that may mitigate my possible objections would be some<b=
r>
&gt;&gt; mandatory requirement about ecosystem echo-chambers making many<br=
>
&gt;&gt; attempts and efforts at steelman representations of alternative<br=
>
&gt;&gt; viewpoints. Understanding objections at a fundamental level, enoug=
h to<br>
&gt;&gt; make strong steelman statements, is very important to ensure that =
the<br>
&gt;&gt; competing opinions are not censored from consideration. Pathologic=
al<br>
&gt;&gt; integration and internalization of these steelman arguments can be=
<br>
&gt;&gt; very useful, even if the process looks unusual.<br>
&gt;&gt;<br>
&gt;&gt; Your process does not have to replace any particular BIP process<b=
r>
&gt;&gt; as-is, but rather could be an alternative that proceeds on its own=
<br>
&gt;&gt; perhaps indefinitely without replacement. I don&#39;t think too ma=
ny BIP<br>
&gt;&gt; processes are necessarily incompatible except by namespace collisi=
on.<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://gist.github.com/andychase/dddb83c294295879308b#=
gistcomment-1566432" rel=3D"noreferrer" target=3D"_blank">https://gist.gith=
ub.com/andychase/dddb83c294295879308b#gistcomment-1566432</a><br>
&gt;&gt;<br>
&gt;&gt; - Bryan<br>
&gt;&gt; <a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_bla=
nk">http://heybryan.org/</a><br>
&gt;&gt; 1 512 203 0507<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div><div><div>&gt; _______________________________________________<=
br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</div></div></blockquote></div><br></div></div>

--089e0115ebd0fc247a051ef188be--