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 ) 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: References: <55828737.6000007@riseup.net> <20150618111407.GA6690@amethyst.visucore.com> <0ede5c200ce70e4d92541dd91749b4ea@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Matt Corallo Date: Thu, 18 Jun 2015 12:24:14 -0700 To: Gavin Andresen ,Alex Morcos 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos 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."