Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.52 as permitted sender)
	client-ip=209.85.215.52; envelope-from=pieter.wuille@gmail.com;
	helo=mail-la0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
References: <55828737.6000007@riseup.net>
	<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
	<20150618111407.GA6690@amethyst.visucore.com>
	<CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
Date: Thu, 18 Jun 2015 15:50:07 +0200
Message-ID: <CAPg+sBg4Du++h4p2jf4Trrx5OW8v13VEdmiwtWn71bynOs+UFw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c1b572d3257e0518cb15d8
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
Precedence: list

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

On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn <mike@plan99.net> wrote:

> OK, let's agree to unpack the two things.
>
> The first issue is how are decisions made in Bitcoin Core? I struggle to
> explain this to others because I don't understand it myself. Is it a vote
> of people with commit access? Is it a 100% agreement of "core developers"
> and if so, who are these people? Is it "whoever reverts the change last"?
> Could I write down in a document a precise description of how decisions are
> made? No, and that's been a fairly frustrating problem for a long time.
>
> But let's leave it to one side for a moment.
>
> Let's focus on the other issue:   what happens if the Bitcoin Core
> decision making process goes wrong?
>

Why do you keep talking about Bitcoin Core maintainers? The means for doing
a hard fork is convincing the network to run modified code, whether that is
a new version of Bitcoin Core or a fork of it, or something else entirely.

If I see consensus about a proposed network change, I will be in favor of
implementing it in Bitcoin Core. But we're not at that point. There is no
network change proposed with consensus. There is not even a patch to be
discussed. There are working proposals, and people are talking about them.
This is good.

I think maintainers of particular software should not be, and are not those
who decide the network's rules. People running the code are. Of course
maintainers have a large influence, but so do other people - like you.

> This was a reference to a post by Gregory on Reddit where he said if
Gavin were to do a pull request for the block size change and then merge
it, he would revert it. And I fully believe he would do so!

I believe so too, and I would do the same. Because I believe implementing a
consensus rule change without having very good expectations that the
network will adopt it, is reckless from the point of view of maintainers,
for all reasons I have mentioned before.

-- 
Pieter

--001a11c1b572d3257e0518cb15d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn <span dir=3D"l=
tr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.ne=
t</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>OK, let&#39;s agre=
e to unpack the two things.</div><div><br></div><div>The first issue is how=
 are decisions made in Bitcoin Core? I struggle to explain this to others b=
ecause I don&#39;t understand it myself. Is it a vote of people with commit=
 access? Is it a 100% agreement of &quot;core developers&quot; and if so, w=
ho are these people? Is it &quot;whoever reverts the change last&quot;?=C2=
=A0 Could I write down in a document a precise description of how decisions=
 are made? No, and that&#39;s been a fairly frustrating problem for a long =
time.</div><div><br></div><div>But let&#39;s leave it to one side for a mom=
ent.</div><div><br></div><div>Let&#39;s focus on the other issue: =C2=A0 wh=
at happens if the Bitcoin Core decision making process goes wrong?=C2=A0</d=
iv></div></div></div></blockquote><div><br></div><div>Why do you keep talki=
ng about Bitcoin Core maintainers? The means for doing a hard fork is convi=
ncing the network to run modified code, whether that is a new version of Bi=
tcoin Core or a fork of it, or something else entirely.<br><br></div><div>I=
f I see consensus about a proposed network change, I will be in favor of im=
plementing it in Bitcoin Core. But we&#39;re not at that point. There is no=
 network change proposed with consensus. There is not even a patch to be di=
scussed. There are working proposals, and people are talking about them. Th=
is is good.<br><br></div><div>I think maintainers of particular software sh=
ould not be, and are not those who decide the network&#39;s rules. People r=
unning the code are. Of course maintainers have a large influence, but so d=
o other people - like you.<br><br></div><div>&gt; This was a reference to a=
 post by Gregory on Reddit where he said if=20
Gavin were to do a pull request for the block size change and then merge
 it, he would revert it. And I fully believe he would do so!<br><br></div><=
div>I believe so too, and I would do the same. Because I believe implementi=
ng a consensus rule change without having very good expectations that the n=
etwork will adopt it, is reckless from the point of view of maintainers, fo=
r all reasons I have mentioned before.<br><br></div>-- <br><div>Pieter<br><=
br></div></div></div></div>

--001a11c1b572d3257e0518cb15d8--