From mboxrd@z Thu Jan 1 00:00:00 1970 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 1Z5ass-0008RZ-2V for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 14:33:38 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.179 as permitted sender) client-ip=209.85.217.179; envelope-from=kanzure@gmail.com; helo=mail-lb0-f179.google.com; Received: from mail-lb0-f179.google.com ([209.85.217.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5asl-00077b-Hy for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 14:33:38 +0000 Received: by lbbti3 with SMTP id ti3so53600858lbb.1 for ; Thu, 18 Jun 2015 07:33:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.42.230 with SMTP id r6mr13010112lal.30.1434638005207; Thu, 18 Jun 2015 07:33:25 -0700 (PDT) Received: by 10.152.18.168 with HTTP; Thu, 18 Jun 2015 07:33:24 -0700 (PDT) In-Reply-To: References: <55828737.6000007@riseup.net> Date: Thu, 18 Jun 2015 09:33:24 -0500 Message-ID: From: Bryan Bishop To: Mike Hearn , Bryan Bishop Content-Type: multipart/alternative; boundary=001a11c36780ae89550518cbb053 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 (kanzure[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: 1Z5asl-00077b-Hy 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 14:33:38 -0000 --001a11c36780ae89550518cbb053 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn wrote: > Dude, calm down. > Well hold on, his concerns are real and he seems perfectly calm to me and others apparently. > and Gavin already said long ago he wouldn't just commit something, even > though he has the ability to do so. > Nobody is worried about Gavin or anyone else making commits to git repositories. You'll notice that this wasn't even mentioned in the original email you were replying to. Instead, the email was talking about commit access, which is a property of GitHub's repositories. So why did I say it? Because it's consistent with what I've always said: > (That's not a good reason.) you cannot run a codebase like Wikipedia > Wikipedia is a top-down centralized authority-based hierarchy. That's pretty close to what you're proposing. That's what everyone else is disagreeing with. You seem to have switched your position mid-flight...? This is not a radical position. That's how nearly all coding projects work. > I have been involved with open source for 15 years and the 'single > maintainer who makes decisions' model is normal, even if in some large > codebases subsystems have delegated submaintainers. There are a number of reasons why that perspective is broken; throughout our conversations others have repeatedly reminded you (such as in -wizards) that forking an open-source repository is not at all like a hard-fork of the blockchain. Anyone can be glorious leader of any repository they want, that's how open-source works. However, it's critical that bitcoin users are never convinced to trust BDFLs or anything else that can be compromised. Should all bitcoin users suddenly start using software with BDFLs, even multiple implementations with separate BDFLs, then those users can be trivially compromised through their trust in those individuals and projects. The alternative is that every developer and every user is personally responsible for self-validation of the rules, checking for correctness and validity. Happy coincidence that this seems to match the strategy of operating the bitcoin network itself, which is to run a node that sees everything and validates all the transactions. Anyone is able to find an error in logic or flaw in the system rules, and they should make it known as widely as possible so that others may evaluate the evidence and consider which solutions preserve the important properties of the system. This is not a matter of majorities or minorities; these arguments should be true for anyone independent of who or what they are, or what level of unpopularity they may have. Anything other than this is somewhat radical, and I am confused as to why others have been talking about "developer consensus". I suspect that the reason why they have been saying developer consensus is because they are talking about the Bitcoin Core project on GitHub at the moment. But the topic switched to contentious hard-forks already, which is not a topic of repositories but a topic of the blockchain and network; and in the context of contentious hard-forks it is clear why everyone individually must evaluate the rules and decide whether they the software is correct, or whether changes can trivially cause catastrophic broken hard-forks. These lines of reasoning should be true for everyone, and not merely true for one person but not another. Users, companies and developers must be aware of this, even though it's different from their usual expectations of how systems operate and are maintained. And it is important to be careful to not misconstrue this to others because it is entirely possible to unintentionally convince others that traditional and centralized models are safely applicable here. I realise some people think this anti-process leads to better decision > making. I disagree. It leads to no decision making, which is not the same > thing at all. > Well, if you're talking about the recent disputes regarding a certain patch to hard-fork the blockchain, a decision to not include such a patch seems like the very definition of a decision. Gavin and I say - there is a process, and that process is a hard fork of > the block chain. I doubt that other bitcoin software maintainers would agree with that sort of toxic reasoning; contentious hard-forks are basically a weapon of war that you can use against any other collaborator on any bitcoin project. Why would anyone want to collaborate on such a hostile project? How would they even trust each other? - Bryan http://heybryan.org/ 1 512 203 0507 --001a11c36780ae89550518cbb053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 18, 2015 at 5:00 AM, Mike Hearn <mike@plan99.net> wrot= e:
Dude, calm down.
=

Well hold on, his concerns are real and he seems perfec= tly calm to me and others apparently.
=C2=A0
and Gavin already said long ago he wouldn't just com= mit something, even though he has the ability to do so.

Nobody is worried about Gavin or anyone else making com= mits to git repositories. You'll notice that this wasn't even menti= oned in the original email you were replying to. Instead, the email was tal= king about commit access, which is a property of GitHub's repositories.=

So why did I say i= t? Because it's consistent with what I've always said:

= (That's not a good reason.)

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">you cannot run= a codebase like Wikipedia

Wikipedia is a top-down centralized authority-based hierarchy. = That's pretty close to what you're proposing. That's what every= one else is disagreeing with. You seem to have switched your position mid-f= light...?

This is n= ot a radical position. That's how nearly all coding projects work. I ha= ve been involved with open source for 15 years and the 'single maintain= er who makes decisions' model is normal, even if in some large codebase= s =C2=A0subsystems have delegated submaintainers.
<= br>
There are a number of reasons why that perspective is broken;= throughout our conversations others have repeatedly reminded you (such as = in -wizards) that forking an open-source repository is not at all like a ha= rd-fork of the blockchain. Anyone can be glorious leader of any repository = they want, that's how open-source works. However, it's critical tha= t bitcoin users are never convinced to trust BDFLs or anything else that ca= n be compromised. Should all bitcoin users suddenly start using software wi= th BDFLs, even multiple implementations with separate BDFLs, then those use= rs can be trivially compromised through their trust in those individuals an= d projects.

The alternative is that every develope= r and every user is personally responsible for self-validation of the rules= , checking for correctness and validity. Happy coincidence that this seems = to match the strategy of operating the bitcoin network itself, which is to = run a node that sees everything and validates all the transactions. Anyone = is able to find an error in logic or flaw in the system rules, and they sho= uld make it known as widely as possible so that others may evaluate the evi= dence and consider which solutions preserve the important properties of the= system. This is not a matter of majorities or minorities; these arguments = should be true for anyone independent of who or what they are, or what leve= l of unpopularity they may have.

Anything other th= an this is somewhat radical, and I am confused as to why others have been t= alking about "developer consensus". I suspect that the reason why= they have been saying developer consensus is because they are talking abou= t the Bitcoin Core project on GitHub at the moment. But the topic switched = to contentious hard-forks already, which is not a topic of repositories but= a topic of the blockchain and network; and in the context of contentious h= ard-forks it is clear why everyone individually must evaluate the rules and= decide whether they the software is correct, or whether changes can trivia= lly cause catastrophic broken hard-forks. These lines of reasoning should b= e true for everyone, and not merely true for one person but not another. Us= ers, companies and developers must be aware of this, even though it's d= ifferent from their usual expectations of how systems operate and are maint= ained. And it is important to be careful to not misconstrue this to others = because it is entirely possible to unintentionally convince others that tra= ditional and centralized models are safely applicable here.

<= /div>
I realis= e some people think this anti-process leads to better decision making. I di= sagree. It leads to no decision making, which is not the same thing at all.=

Well, if you're talking abo= ut the recent disputes regarding a certain patch to hard-fork the blockchai= n, a decision to not include such a patch seems like the very definition of= a decision.

Gavin and I say - there is a process, and that process = is a hard fork of the block chain.

I= doubt that other bitcoin software maintainers would agree with that sort o= f toxic reasoning; contentious hard-forks are basically a weapon of war tha= t you can use against any other collaborator on any bitcoin project. Why wo= uld anyone want to collaborate on such a hostile project? How would they ev= en trust each other?

- B= ryan
http://heybryan.= org/
1 512 203 0507
--001a11c36780ae89550518cbb053--