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 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 ; 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: References: <55828737.6000007@riseup.net> <20150618111407.GA6690@amethyst.visucore.com> <0ede5c200ce70e4d92541dd91749b4ea@riseup.net> Date: Thu, 18 Jun 2015 14:23:33 -0400 Message-ID: From: Gavin Andresen To: Alex Morcos 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 , Justus Ranvier 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 18:23:41 -0000 --001a11347da6bde4a00518cee74e Content-Type: text/plain; charset=UTF-8 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: 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
On T= hu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos@gmail.com> w= rote:
Let me take a pass= at explaining how I see this.

1) Code changes to Bitcoi= n Core that don'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.

Yes.

<= div dir=3D"ltr">
2) Changes to the consensus rules: As others have said= , this isn't anyone's decision for anyone else.

Yes.
=C2=A0
It'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'll run and we'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's what will make the = system work best.

I don't t= hink I agree with "pretty much everybody", because status-quo bia= s is a very powerful thing. Any change that disrupts the way they've be= en 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 wo= rried they, personally, won'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.

The criteria = for me is "clear super-majority of the people and businesses who are u= sing Bitcoin the most," and I think that criteria is met.
=C2=A0
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.

=
Yes, that'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't have either a Benevolent Dictator = or some clear voting process to resolve disputes that cannot be settled wit= h "rough consensus."


= --
--
Gavin Andresen
--001a11347da6bde4a00518cee74e--