path: root/11/2933a04ff63c0e9eb4cd34930ba30a11ecf605

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 4C975F00
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 Sep 2015 04:41:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
	[209.85.213.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4085510C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 Sep 2015 04:41:16 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so4475270igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 03 Sep 2015 21:41:15 -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=zRy/zy4aeiPn6z+24VTMv5XQhFGomBHjjEtFCV6g4uo=;
	b=MI0VLl2aZiKaNrK8VLrEJI0QHTGR/i/cH9JQvziX3Ryep1cyjSurMZ8SN2enH4/dWZ
	zljxXsKzPNNZYB1drmwzXhBaAQ/7mo2+Rl8LFKzU5WwDA3gS/hnhpgv7KBGmdC3JBKfV
	ixFyWRP5NPmj8iZrGWeECsadFsgJKR8LavvQys4SPCCYoKUaOuwgiWTjjqGfIu3ywJtL
	RMyFk9YG5GAq8C3Lzx1QpNgTr/WO2zS6C6Pkc2w19kVCbsT0RcoxlL8+2X8A8syK0/T0
	dv+SRQjnjhNCS6OL2SzovNmgsPTQQXM9TtwjXypz4IrhP7FIHS4vLB1nkv0pHIh5MdvQ
	V1bQ==
X-Received: by 10.50.119.105 with SMTP id kt9mr2960628igb.97.1441341675678;
	Thu, 03 Sep 2015 21:41:15 -0700 (PDT)
MIME-Version: 1.0
Sender: asperous2@gmail.com
Received: by 10.50.3.33 with HTTP; Thu, 3 Sep 2015 21:40:56 -0700 (PDT)
In-Reply-To: <CABaSBaw7hM2qmuR6Z6USy5=V9NGeCPKmHHuVOH=vexDk7kY8OA@mail.gmail.com>
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
	<CABaSBaw7hM2qmuR6Z6USy5=V9NGeCPKmHHuVOH=vexDk7kY8OA@mail.gmail.com>
From: Andy Chase <theandychase@gmail.com>
Date: Thu, 3 Sep 2015 21:40:56 -0700
X-Google-Sender-Auth: 69cZHxSlAyalSJsP_NUh5KKrlZU
Message-ID: <CAAxp-m_vo5vJEemR_hRX3hNcUPveA6EHn-ZFMJo8ke59E6BrKw@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0111c26a94354e051ee482fa
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 04:41:17 -0000

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

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
>

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

<div dir=3D"ltr">As posted:<div><div><br></div><div>**Enforcement/Organizat=
ion** I agree with your comments. I don&#39;t believe in setting up an orga=
nization to manage this process (would be too much power and not really nee=
ded because the internet is pretty good at information sharing). Therefore,=
 I designed it around the assumption that participation is voluntary. This =
means that it&#39;s hard to enforce rules like forcing groups to see the ot=
her side. Groupthink/Echo chambers is real and is bad but it&#39;s hard to =
change human nature.</div><div><br></div><div>In regards to enforcement, I =
believe that the best approach would be to motivate committees to produce t=
he best opinion they can (and also proof of stake, another weak point in th=
is proposal), as the better they can do this the more likely the community =
will accept their opinion as valid and important.</div><div><br></div><div>=
Indeed, I believe that without an organization managing the process, it&#39=
;s up to each individual reader of each BIP/Opinions set to make the decisi=
on on whether or not there is clear and true community acceptance.</div></d=
iv><div><br></div><div>----</div><div><br></div><div><div>**Committee versu=
s another approach**</div><div><br></div><div>Pros of using Committees:</di=
v><div><br></div><div>* Committees are used today in many fields with a ran=
ge of success. Lots of previous work to work off of here, history is establ=
ished.</div><div>* Many segments already have committee-like structures (Me=
rchants produce shared signed documents, miners often represent themselves,=
 User groups have representatives like voting on subreddit moderators, Core=
 Devs have Core Devs)</div><div>* Committees can filter a range of opinions=
 down to a yes/no</div><div>* Committees have real people that can be talke=
d to, contacted, etc.</div><div>* Much easier to proof stake in a range (Pe=
ople generally accept the Bitcoin Core has 70-90% of the market share) vs s=
omeone trying to proof they make up (.000001% of the Bitcoin user-base)</di=
v><div>* Committees have some stability, encourages experience and expertis=
e (Committee members can be knowledgeable in their area and adequately unde=
rstand BIPs)</div><div><br></div><div>Cons:</div><div><br></div><div>* Fear=
 of committees working in the dark, censoring opinions (i.e. &quot;Dark smo=
key room of fat cats&quot;) (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)</div><=
div>* More centralized, centralization of power (generally bad) (Possible s=
olution: encourage smaller committees)</div><div>* Centralization pressure =
(groups may seek to consolidate to gain power) (Possible solution: Segmenta=
tion)</div><div>* Encourages groupthink, political maneuvers, turns good pe=
ople into politicians, mud-tossing</div><div><br></div><div>**Another possi=
ble approach: micro votes**</div><div><br></div><div>Pros:</div><div><br></=
div><div>* Each user can represent themselves, no censorship</div><div>* Pe=
ople feel more involved and empowered</div><div><br></div><div>Cons:</div><=
div><br></div><div>* How to prove and prevent manipulation?</div><div>* Onl=
y motivated people will contribute. Motivated people may be motivated for b=
ad reasons.</div></div><div><br></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <span dir=
=3D"ltr">&lt;<a href=3D"mailto:kanzure@gmail.com" target=3D"_blank">kanzure=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On=
 Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; I wrote the BIP mostly to stir the pot on ideas of governance<br>
<br>
</span>Some quick comments:<br>
<br>
I have some objects that I am not ready to put into words, but I do<br>
think there are easily some major objections to committee design. If I<br>
vanish and never respond with my objections, perhaps there&#39;s an IETF<br=
>
RFC about this already....<br>
<br>
Something that may mitigate my possible objections would be some<br>
mandatory requirement about ecosystem echo-chambers making many<br>
attempts and efforts at steelman representations of alternative<br>
viewpoints. Understanding objections at a fundamental level, enough to<br>
make strong steelman statements, is very important to ensure that the<br>
competing opinions are not censored from consideration. Pathological<br>
integration and internalization of these steelman arguments can be<br>
very useful, even if the process looks unusual.<br>
<br>
Your process does not have to replace any particular BIP process<br>
as-is, but rather could be an alternative that proceeds on its own<br>
perhaps indefinitely without replacement. I don&#39;t think too many BIP<br=
>
processes are necessarily incompatible except by namespace collision.<br>
<br>
<a href=3D"https://gist.github.com/andychase/dddb83c294295879308b#gistcomme=
nt-1566432" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/an=
dychase/dddb83c294295879308b#gistcomment-1566432</a><br>
<br>
- Bryan<br>
<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:=
//heybryan.org/</a><br>
1 512 203 0507<br>
</blockquote></div><br></div></div>

--089e0111c26a94354e051ee482fa--