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"><<a href=3D"m= ailto:morcos@gmail.com" target=3D"_blank">morcos@gmail.com</a>></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'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't anyone'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'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.</div></div></blockquote><div><br></div><div>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."</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'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 "clear super-majority of the people and businesses who are u= sing Bitcoin the most," 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'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."</div></div><br clear=3D"all"><div><br></div>= -- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div> </div></div> --001a11347da6bde4a00518cee74e--