Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1Z5eTV-0003Gx-I0
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 18:23:41 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.54 as permitted sender)
	client-ip=209.85.215.54; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f54.google.com; 
Received: from mail-la0-f54.google.com ([209.85.215.54])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z5eTU-00065k-97
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 18:23:41 +0000
Received: by lacny3 with SMTP id ny3so59791568lac.3
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 18 Jun 2015 11:23:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.204.40 with SMTP id kv8mr13861169lac.113.1434651813862; 
	Thu, 18 Jun 2015 11:23:33 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Thu, 18 Jun 2015 11:23:33 -0700 (PDT)
In-Reply-To: <CAPWm=eX5Oc4QXkp3H5thPBPzJ-t7JGzF5pVaP+eSd0=h52ku=A@mail.gmail.com>
References: <55828737.6000007@riseup.net>
	<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
	<20150618111407.GA6690@amethyst.visucore.com>
	<CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
	<CAJHLa0OKXaUD6MnN4N6RGbNwrXx43jBm9MiELQK6BRw1OL3HNA@mail.gmail.com>
	<0ede5c200ce70e4d92541dd91749b4ea@riseup.net>
	<CAJHLa0NiDamkrbW2TMoTLqMPhzw0LBboNp1+_atBGDYMa135uw@mail.gmail.com>
	<e6da277c39b0354cdf24361e20a1fce2@riseup.net>
	<CAPWm=eX5Oc4QXkp3H5thPBPzJ-t7JGzF5pVaP+eSd0=h52ku=A@mail.gmail.com>
Date: Thu, 18 Jun 2015 14:23:33 -0400
Message-ID: <CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Alex Morcos <morcos@gmail.com>
Content-Type: multipart/alternative; boundary=001a11347da6bde4a00518cee74e
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	1.7 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5eTU-00065k-97
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Justus Ranvier <justusranvier@riseup.net>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
 to Remove Commit Access from Other Developers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 18:23:41 -0000

--001a11347da6bde4a00518cee74e
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos@gmail.com> wrote:

> Let me take a pass at explaining how I see this.
>
> 1) Code changes to Bitcoin Core that don't change consensus:  Wladimir is
> the decider but he works under a process that is well understood by
> developers on the project in which he takes under reasonable consideration
> other technical opinions and prefers to have clear agreement among them.
>

Yes.

2) Changes to the consensus rules: As others have said, this isn't anyone's
> decision for anyone else.
>

Yes.


> It's up to each individual user as to what code they run and what rules
> they enforce.  So then why is everyone so up in arms about what Mike and
> Gavin are proposing if everyone is free to decide for themselves?  I
> believe that each individual user should adhere to the principle that there
> should be no changes to the consensus rules unless there is near complete
> agreement among the entire community, users, developers, businesses miners
> etc. It is not necessary to define complete agreement exactly because every
> individual person decides for themselves.  I believe that this is what
> gives Bitcoin, or really any money, its value and what makes it work, that
> we all agree on exactly what it is.  So I believe that it is misleading and
> bad for Bitcoin to tell users and business that you can just choose without
> concern for everyone else which code you'll run and we'll see which one
> wins out.  No.  You should run the old consensus rules (on any codebase you
> want) until you believe that pretty much everyone has consented to a change
> in the rules.  It is your choice, but I think a lot of people that have
> spent time thinking about the philosophy of consensus systems believe that
> when the users of the system have this principle in mind, it's what will
> make the system work best.
>

I don't think I agree with "pretty much everybody", because status-quo bias
is a very powerful thing. Any change that disrupts the way they've been
doing things will generate significant resistance -- there will be 10 or
20% of any population that will take a position of "too busy to think about
this, everything seems to be working great, I don't like change, NO to any
change."

For example, I think some of the resistance for bigger blocks is coming
from contributors who are worried they, personally, won't be able to keep
up with a bigger blockchain. They might not be able to run full nodes from
their home network connections (or might not be able to run a full node AND
stream Game of Thrones), on their old raspberry pi machines.

The criteria for me is "clear super-majority of the people and businesses
who are using Bitcoin the most," and I think that criteria is met.



> 3) Code changes to Core that do change consensus: I think that Wladimir,
> all the other committers besides Gavin, and almost all of the other
> developers on Core would defer to #2 above and wait for its outcome to be
> clear before considering such a code change.
>

Yes, that's the way it has mostly been working. But even before stepping
down as Lead I was starting to wonder if there are ANY successful open
source projects that didn't have either a Benevolent Dictator or some clear
voting process to resolve disputes that cannot be settled with "rough
consensus."


-- 
--
Gavin Andresen

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jun 18, 2015 at 1:42 PM, Alex Morcos <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:morcos@gmail.com" target=3D"_blank">morcos@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Let me take a pass=
 at explaining how I see this.<div><br></div><div>1) Code changes to Bitcoi=
n Core that don&#39;t change consensus: =C2=A0Wladimir is the decider but h=
e works under a process that is well understood by developers on the projec=
t in which he takes under reasonable consideration other technical opinions=
 and prefers to have clear agreement among them.</div></div></blockquote><d=
iv><br></div><div>Yes.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>2) Changes to the consensus rules: As others have said=
, this isn&#39;t anyone&#39;s decision for anyone else.</div></div></blockq=
uote><div><br></div><div>Yes.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>It&#39;s up to each individual user as to wha=
t code they run and what rules they enforce.=C2=A0 So then why is everyone =
so up in arms about what Mike and Gavin are proposing if everyone is free t=
o decide for themselves?=C2=A0 I believe that each individual user should a=
dhere to the principle that there should be no changes to the consensus rul=
es unless there is near complete agreement among the entire community, user=
s, developers, businesses miners etc. It is not necessary to define complet=
e agreement exactly because every individual person decides for themselves.=
=C2=A0 I believe that this is what gives Bitcoin, or really any money, its =
value and what makes it work, that we all agree on exactly what it is.=C2=
=A0 So I believe that it is misleading and bad for Bitcoin to tell users an=
d business that you can just choose without concern for everyone else which=
 code you&#39;ll run and we&#39;ll see which one wins out.=C2=A0 No.=C2=A0 =
You should run the old consensus rules (on any codebase you want) until you=
 believe that pretty much everyone has consented to a change in the rules.=
=C2=A0 It is your choice, but I think a lot of people that have spent time =
thinking about the philosophy of consensus systems believe that when the us=
ers of the system have this principle in mind, it&#39;s what will make the =
system work best.</div></div></blockquote><div><br></div><div>I don&#39;t t=
hink I agree with &quot;pretty much everybody&quot;, because status-quo bia=
s is a very powerful thing. Any change that disrupts the way they&#39;ve be=
en doing things will generate significant resistance -- there will be 10 or=
 20% of any population that will take a position of &quot;too busy to think=
 about this, everything seems to be working great, I don&#39;t like change,=
 NO to any change.&quot;</div><div><br></div><div>For example, I think some=
 of the resistance for bigger blocks is coming from contributors who are wo=
rried they, personally, won&#39;t be able to keep up with a bigger blockcha=
in. They might not be able to run full nodes from their home network connec=
tions (or might not be able to run a full node AND stream Game of Thrones),=
 on their old raspberry pi machines.</div><div><br></div><div>The criteria =
for me is &quot;clear super-majority of the people and businesses who are u=
sing Bitcoin the most,&quot; and I think that criteria is met.</div><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>3) Code changes to Core that do change consensus: I think that Wladimir,=
 all the other committers besides Gavin, and almost all of the other develo=
pers on Core would defer to #2 above and wait for its outcome to be clear b=
efore considering such a code change.<br></div></div></blockquote><div><br>=
</div><div>Yes, that&#39;s the way it has mostly been working. But even bef=
ore stepping down as Lead I was starting to wonder if there are ANY success=
ful open source projects that didn&#39;t have either a Benevolent Dictator =
or some clear voting process to resolve disputes that cannot be settled wit=
h &quot;rough consensus.&quot;</div></div><br clear=3D"all"><div><br></div>=
-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>

--001a11347da6bde4a00518cee74e--