path: root/dc/7e2011cd6a16f7490c3ec4bb6b86cbc4293feb

Return-Path: <bryan@blockcypher.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E7CD671E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 18:45:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com
	[209.85.214.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 096641AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 18:45:01 +0000 (UTC)
Received: by obre1 with SMTP id e1so140036866obr.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 11:45:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=6H663wGPSWOQosT0UKp+rt7JAhc3wWEAf1htziy3QHs=;
	b=Ma2oVp6TWNR5H8mfUanvetoiYSmi3ogn34xYbNL/MxcvqubL5rwAvxDv1S9hxxXHXP
	h2NTop+Qb4L0guprJ4ygfw9nktn+Qdue0MTByn+0B/wSrkIx6s2QX5xuVzLMNm66jBtB
	AinlA+WERlTChHooAUSV/ngm2r3GZ0v4adHVVrxgN7YXkfhMF4ISJeXzIS+mCMc8bFQ2
	RwIW7cQpC+pb3Pv/zM36KLr1srlXOwkcK5FCamttdFYjInPqyA4t8oEnDXTBGe/eHv55
	eboLhpyyzjjc1mZAE2RIl7CO1RRQMho4f9QyLQDk+vfPOslMMqggLwilk2fwqP7Jvkmu
	9bgA==
X-Gm-Message-State: ALoCoQnSV7etwQNydOj0zUUCqa7CMQmzRGYJmZYo9PEi6FDe7rScr4e3tNJJRmbUGScTy3qouwfI
MIME-Version: 1.0
X-Received: by 10.202.95.138 with SMTP id t132mr3899300oib.55.1437590701461;
	Wed, 22 Jul 2015 11:45:01 -0700 (PDT)
Received: by 10.182.206.16 with HTTP; Wed, 22 Jul 2015 11:45:01 -0700 (PDT)
In-Reply-To: <55AFD390.9060306@bitcoins.info>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<55AFD390.9060306@bitcoins.info>
Date: Wed, 22 Jul 2015 11:45:01 -0700
Message-ID: <CANeMN=-K0vR=ZQCoc03cWOrR3NHR37+Ejw0n-xyT3_OjBFHk6Q@mail.gmail.com>
From: Bryan Cheng <bryan@blockcypher.com>
To: pieter.wuille@gmail.com
Content-Type: multipart/alternative; boundary=001a113cd41a17fabd051b7b2b3b
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 18:45:03 -0000

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

Pieter, I agree with the overall gist of your statement (that Bitcoin is a
consensus-driven protocol that's incompatible with certain forms of central
governance) but I respectfully disagree with some of the conclusions you're
drawing.

> Consensus changes should be done using consensus, _and the default in
case of controversy is no change_.

(emphasis mine)

I think that there's a disconnect between the idea that Bitcoin Core making
a consensus-driven change in turn means that the network is being forced
down a certain path. This takes away a great deal of the individual agency
that makes Bitcoin what it is today. Upgrading to a version of Bitcoin Core
that is incompatible with your ideals is in no way a forced choice, as you
have stated in your email; forks, alternative clients, or staying on an
older version are all valid choices. If the majority of the network chooses
not to endorse a specific change, then the majority of the network will
continue to operate just fine without it, and properly structured consensus
rules will pull the minority along as well. (For example, re: block sizes,
if the majority of hashing power remains on a version or fork that does not
mine >1MB blocks, a chain of <1MB blocks will continue to be the longest,
and up to date clients will still respect that. That is consensus at work,
pure and simple.)

Obviously Core is in a unique position as a reference client and ignoring
that would be irresponsible. If broad consensus among the developers cannot
be reached, then Core should not make a given change. However, freezing
Core's ability to make changes in light of _any_ controversy is allowing a
few voices to dictate direction and is counter to any kind of
consensus-driven decision making.

Placing Core and its developers on some sort of pedestal where we believe
that they dictate policy and therefore shouldn't be allowed to take any
risks will create the very situation that you're advocating against- that a
small group of developers have control over Bitcoin's policies. Instead, we
should strive to treat Core as _just another Bitcoin Client_, we should
educate users to make informed choices about the version of software they
are running and the choices implicit in that, and we should allow consensus
at the protocol level to make the decisions on the overall direction of the
network.

> My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later

I will keep this brief because this is straying off topic of the idea of
this thread- but I don't believe that increasing Bitcoin's capacity as a
network is inherently incompatible with the development of a fee market,
and considering a fee market to be formed of only a single set of variables
(transaction rate versus block size) is not sound economic analysis.

On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> default in case of controversy is no change.
>>
>
> I think the result of this would probably be that no controversial changes
> ever get implemented via this process so others will hard fork the code and
> eventually make this process irrelevant.  Since you need close to 100%
> agreement the irrelevance would have to come as a step function which will
> manifest itself in a rather disruptive manner.
>
> The question is really is this hark-forking disruption worse than coming
> up with some kind of process to handle controversial changes.
>
> Russ
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Pieter, I agree with the overall gist of your statement (t=
hat Bitcoin is a consensus-driven protocol that&#39;s incompatible with cer=
tain forms of central governance) but I respectfully disagree with some of =
the conclusions you&#39;re drawing.<div><br></div><div>&gt;=C2=A0<span styl=
e=3D"font-size:12.8px">Consensus changes should be done using consensus, _a=
nd the default in case of controversy is no change_.=C2=A0</span></div><div=
><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font=
-size:12.8px">(emphasis mine)</span></div><div><br></div><div>I think that =
there&#39;s a disconnect between the idea that Bitcoin Core making a consen=
sus-driven change in turn means that the network is being forced down a cer=
tain path. This takes away a great deal of the individual agency that makes=
 Bitcoin what it is today. Upgrading to a version of Bitcoin Core that is i=
ncompatible with your ideals is in no way a forced choice, as you have stat=
ed in your email; forks, alternative clients, or staying on an older versio=
n are all valid choices. If the majority of the network chooses not to endo=
rse a specific change, then the majority of the network will continue to op=
erate just fine without it, and properly structured consensus rules will pu=
ll the minority along as well. (For example, re: block sizes, if the majori=
ty of hashing power remains on a version or fork that does not mine &gt;1MB=
 blocks, a chain of &lt;1MB blocks will continue to be the longest, and up =
to date clients will still respect that. That is consensus at work, pure an=
d simple.)=C2=A0<br></div><div><br></div><div>Obviously Core is in a unique=
 position as a reference client and ignoring that would be irresponsible. I=
f broad consensus among the developers cannot be reached, then Core should =
not make a given change. However, freezing Core&#39;s ability to make chang=
es in light of _any_ controversy is allowing a few voices to dictate direct=
ion and is counter to any kind of consensus-driven decision making.</div><d=
iv><br></div><div>Placing Core and its developers on some sort of pedestal =
where we believe that they dictate policy and therefore shouldn&#39;t be al=
lowed to take any risks will create the very situation that you&#39;re advo=
cating against- that a small group of developers have control over Bitcoin&=
#39;s policies. Instead, we should strive to treat Core as _just another Bi=
tcoin Client_, we should educate users to make informed choices about the v=
ersion of software they are running and the choices implicit in that, and w=
e should allow consensus at the protocol level to make the decisions on the=
 overall direction of the network.</div><div><br></div><div>&gt;=C2=A0<span=
 style=3D"font-size:12.8px">My personal opinion is that we - as a community=
 - should indeed let a fee market develop, and rather sooner than later</sp=
an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span =
style=3D"font-size:12.8px">I will keep this brief because this is straying =
off topic of the idea of this thread- but I don&#39;t believe that increasi=
ng Bitcoin&#39;s capacity as a network is inherently incompatible with the =
development of a fee market, and considering a fee market to be formed of o=
nly a single set of variables (transaction rate versus block size) is not s=
ound economic analysis.</span></div></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin vi=
a bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
default in case of controversy is no change.<br>
</blockquote>
<br></span>
I think the result of this would probably be that no controversial changes =
ever get implemented via this process so others will hard fork the code and=
 eventually make this process irrelevant.=C2=A0 Since you need close to 100=
% agreement the irrelevance would have to come as a step function which wil=
l manifest itself in a rather disruptive manner.<br>
<br>
The question is really is this hark-forking disruption worse than coming up=
 with some kind of process to handle controversial changes.<br>
<br>
Russ<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--001a113cd41a17fabd051b7b2b3b--