path: root/93/8b4ec8cf3a40f3fbbb73f7d1784becdac6b98d

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <morcos@gmail.com>) id 1Z5enW-0004Fl-NX
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 18:44:22 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.48 as permitted sender)
	client-ip=74.125.82.48; envelope-from=morcos@gmail.com;
	helo=mail-wg0-f48.google.com; 
Received: from mail-wg0-f48.google.com ([74.125.82.48])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z5enV-0001JJ-99
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 18:44:22 +0000
Received: by wgbhy7 with SMTP id hy7so71181081wgb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 18 Jun 2015 11:44:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.123.4 with SMTP id lw4mr17720291wjb.94.1434653055162;
	Thu, 18 Jun 2015 11:44:15 -0700 (PDT)
Received: by 10.180.168.34 with HTTP; Thu, 18 Jun 2015 11:44:14 -0700 (PDT)
In-Reply-To: <CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@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>
	<CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com>
Date: Thu, 18 Jun 2015 14:44:14 -0400
Message-ID: <CAPWm=eVuCJVcw4ZU6x9SxASVLm4cE8_pRLNAZBzak8TqO43HWQ@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e01227ee0ba9e800518cf31f4
X-Spam-Score: -0.6 (/)
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
	(morcos[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
X-Headers-End: 1Z5enV-0001JJ-99
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:44:22 -0000

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

Not that I know how to do this, but would you be willing to attempt some
other method of measuring just how much of a "super-majority" we have
before deploying code?  Maybe that information would be helpful for
everyone.  Obviously such a poll couldn't be perfect, but maybe better than
the information we have now.

A) I don't believe we should consider changing the 1 MB limit now
B) I conceptually believe in increasing block size, but would like to
follow a more conservative process and wait to see if a stronger technical
consensus on a plan to do so can develop.
C) I'd like to go along with Gavin and Mike's 8MB proposal (maybe we wait
til this is fully specified, but again not deployed)

Perhaps there can even be 4 polls:
Miners can vote in coinbases
Known corporate entities can announce their vote
Does the Bitcoin Foundation infrastructure still exist to represent some
authenticated (I think) set of individuals
A reddit poll

I don't even know if I think this is a good idea, but just trying to find a
way to move forward where more of us are on the same page.






On Thu, Jun 18, 2015 at 2:23 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> 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
>

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

<div dir=3D"ltr">Not that I know how to do this, but would you be willing t=
o attempt some other method of measuring just how much of a &quot;super-maj=
ority&quot; we have before deploying code?=C2=A0 Maybe that information wou=
ld be helpful for everyone.=C2=A0 Obviously such a poll couldn&#39;t be per=
fect, but maybe better than the information we have now.<div><br></div><div=
>A) I don&#39;t believe we should consider changing the 1 MB limit now</div=
><div>B) I conceptually believe in increasing block size, but would like to=
 follow a more conservative process and wait to see if a stronger technical=
 consensus on a plan to do so can develop.</div><div>C) I&#39;d like to go =
along with Gavin and Mike&#39;s 8MB proposal (maybe we wait til this is ful=
ly specified, but again not deployed)</div><div><br></div><div>Perhaps ther=
e can even be 4 polls:</div><div>Miners can vote in coinbases</div><div>Kno=
wn corporate entities can announce their vote</div><div>Does the Bitcoin Fo=
undation infrastructure still exist to represent some authenticated (I thin=
k) set of individuals</div><div>A reddit poll</div><div><br></div><div>I do=
n&#39;t even know if I think this is a good idea, but just trying to find a=
 way to move forward where more of us are on the same page.</div><div><br><=
/div><div><br></div><div><br></div><div><br></div><div><br></div></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jun 18, 2015 =
at 2:23 PM, Gavin Andresen <span dir=3D"ltr">&lt;<a href=3D"mailto:gavinand=
resen@gmail.com" target=3D"_blank">gavinandresen@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"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jun 18, 2015 a=
t 1:42 PM, Alex Morcos <span dir=3D"ltr">&lt;<a href=3D"mailto:morcos@gmail=
.com" target=3D"_blank">morcos@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;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 Bitcoin Core that don&#3=
9;t change consensus: =C2=A0Wladimir is the decider but he works under a pr=
ocess that is well understood by developers on the project in which he take=
s under reasonable consideration other technical opinions and prefers to ha=
ve clear agreement among them.</div></div></blockquote><div><br></div></spa=
n><div>Yes.</div><span class=3D""><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 hav=
e said, this isn&#39;t anyone&#39;s decision for anyone else.</div></div></=
blockquote><div><br></div></span><div>Yes.</div><span class=3D""><div>=C2=
=A0</div><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"><div>It&#39;s up t=
o each individual user as to what 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 to decide for themselves?=C2=A0 I believe th=
at 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 individua=
l person decides for themselves.=C2=A0 I believe that this is what gives Bi=
tcoin, or really any money, its value and what makes it work, that we all a=
gree on exactly what it is.=C2=A0 So I believe that it is misleading and ba=
d for Bitcoin to tell users and business that you can just choose without c=
oncern 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 an=
y codebase you want) until you believe that pretty much everyone has consen=
ted 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 sys=
tems believe that when the users of the system have this principle in mind,=
 it&#39;s what will make the system work best.</div></div></blockquote><div=
><br></div></span><div>I don&#39;t think I agree with &quot;pretty much eve=
rybody&quot;, because status-quo bias is a very powerful thing. Any change =
that disrupts the way they&#39;ve been doing things will generate significa=
nt 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 wor=
king 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 worried they, personally, won&#39;t be ab=
le 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 fu=
ll node AND stream Game of Thrones), on their old raspberry pi machines.</d=
iv><div><br></div><div>The criteria for me is &quot;clear super-majority of=
 the people and businesses who are using Bitcoin the most,&quot; and I thin=
k that criteria is met.</div><span class=3D""><div><br></div><div>=C2=A0</d=
iv><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>3) Code changes to =
Core that do change consensus: I think that Wladimir, all the other committ=
ers besides Gavin, and almost all of the other developers on Core would def=
er to #2 above and wait for its outcome to be clear before considering such=
 a code change.<br></div></div></blockquote><div><br></div></span><div>Yes,=
 that&#39;s the way it has mostly been working. But even before stepping do=
wn as Lead I was starting to wonder if there are ANY successful open source=
 projects that didn&#39;t have either a Benevolent Dictator or some clear v=
oting process to resolve disputes that cannot be settled with &quot;rough c=
onsensus.&quot;</div></div><span class=3D"HOEnZb"><font color=3D"#888888"><=
br clear=3D"all"><div><br></div>-- <br><div>--<br>Gavin Andresen<br></div>
</font></span></div></div>
</blockquote></div><br></div>

--089e01227ee0ba9e800518cf31f4--