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 <bitcoin-list@bluematt.me>) id 1Z5fQI-0005if-Kb
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 19:24:26 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 192.241.179.72 as permitted sender)
	client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
	helo=mail.bluematt.me; 
Received: from mail.bluematt.me ([192.241.179.72])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Z5fQH-0007pf-ES
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Jun 2015 19:24:26 +0000
Received: from [IPv6:2607:fb90:406:1c88:517:fde8:e69b:258b]
	(mde0536d0.tmodns.net [208.54.5.222])
	by mail.bluematt.me (Postfix) with ESMTPSA id 282AC5563F;
	Thu, 18 Jun 2015 19:24:18 +0000 (UTC)
User-Agent: K-9 Mail for Android
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>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
From: Matt Corallo <bitcoin-list@bluematt.me>
Date: Thu, 18 Jun 2015 12:24:14 -0700
To: Gavin Andresen <gavinandresen@gmail.com>,Alex Morcos <morcos@gmail.com>
Message-ID: <9BD8D5D8-3A4B-4361-BF4C-25E1019CA428@bluematt.me>
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.8 (-)
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 SPF_PASS               SPF: sender matches SPF record
	-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1Z5fQH-0007pf-ES
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.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 19:24:26 -0000

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

Ive been trying to stay out of these increasingly useless shit-throwing c=
ontests, but I wanted to take objection to this... I highly, highly doubt=
 any seriously technical person is making any kind of decision on block s=
ize issues based on their own personal network. If you're assuming this i=
s a serious motivating factor for anyone, then I'm not sure you've even b=
een reading your email or listening to the conversations you've had with =
people over the last year or more.

On June 18, 2015 11:23:33 AM PDT, 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:=20
>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."