path: root/51/633f68cab75df13546a4c3f3e3adaacfb5c8d5

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 <kanzure@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
References: <55828737.6000007@riseup.net>
	<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
Date: Thu, 18 Jun 2015 09:33:24 -0500
Message-ID: <CABaSBaxN+tUV0zoPLoJJ-ooBVsT1cg9U+9ge4Xw78d+3Be6LJA@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
To: Mike Hearn <mike@plan99.net>, Bryan Bishop <kanzure@gmail.com>
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 <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 14:33:38 -0000

--001a11c36780ae89550518cbb053
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn <mike@plan99.net> 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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jun 18, 2015 at 5:00 AM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr">Dude, calm down.</div></blockquote>=
<div><br></div><div>Well hold on, his concerns are real and he seems perfec=
tly calm to me and others apparently.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
"><div dir=3D"ltr">and Gavin already said long ago he wouldn&#39;t just com=
mit something, even though he has the ability to do so.<div></div></div></b=
lockquote></div><br>Nobody is worried about Gavin or anyone else making com=
mits to git repositories. You&#39;ll notice that this wasn&#39;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&#39;s repositories.=
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex"><span style=3D"font-size:12.8000001907349px">So why did I say i=
t? Because it&#39;s consistent with what I&#39;ve always said:</span><br></=
blockquote><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
(That&#39;s not a good reason.)</div><div class=3D"gmail_extra"><br></div><=
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"><span style=3D"font-size:12.8000001907349px">you cannot run=
 a codebase like Wikipedia</span><br></blockquote><div class=3D"gmail_extra=
"><br></div>Wikipedia is a top-down centralized authority-based hierarchy. =
That&#39;s pretty close to what you&#39;re proposing. That&#39;s what every=
one else is disagreeing with. You seem to have switched your position mid-f=
light...?</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><span style=3D"font-size:12.8000001907349px">This is n=
ot a radical position. That&#39;s how nearly all coding projects work. I ha=
ve been involved with open source for 15 years and the &#39;single maintain=
er who makes decisions&#39; model is normal, even if in some large codebase=
s =C2=A0subsystems have delegated submaintainers.</span></blockquote><div><=
br></div><div>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&#39;s how open-source works. However, it&#39;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.</div><div><br></div><div>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.</div><div><br></div><div>Anything other th=
an this is somewhat radical, and I am confused as to why others have been t=
alking about &quot;developer consensus&quot;. 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&#39;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><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><span style=3D"font-size:12.8000001907349px">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.=
</span><br></blockquote><div><br></div><div>Well, if you&#39;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.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><span style=3D"font-size:=
12.8000001907349px">Gavin and I say - there is a process, and that process =
is a hard fork of the block chain.</span></blockquote><div><br></div><div>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?</div><div><br></div><div class=3D"gmail_signature">- B=
ryan<br><a href=3D"http://heybryan.org/" target=3D"_blank">http://heybryan.=
org/</a><br>1 512 203 0507</div>
</div></div>

--001a11c36780ae89550518cbb053--