path: root/48/49ec7b50ea52daf606974583cd8306a2c2bf0e

Return-Path: <kanzure@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A61E610D9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 17:34:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com
	[209.85.218.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9281015A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 17:34:03 +0000 (UTC)
Received: by mail-oi0-f49.google.com with SMTP id s2so59908982oie.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 06 Feb 2016 09:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=9ttBXeBo0HMOPdYgdDUmLLpVjhXIDtbOq+n3b6hKJDo=;
	b=LtgDx8L8FZA0oxkqHg3uL5rxJlE5d3YX9hyeiXrD8GHS5d/PajkZJhBMnWysQCFOmd
	U4r9u3cfUuAJQUW+P3jUQiQRKeRZqGo1vERYs1N64rkkrvZGrhyRKhlVV0v9DRJME1Sn
	LhhunRmNrk4H4S5Dehs220J3J7vnDhgSteBysclN3ti3NuZmypaJGhz2Ca/zkHu+AYfT
	v7rNGNv/t8jEPso5gO55Zw9GuESk+3DmVkvnUAANw0Tn9WLP6JkuxOhWKACBp1Lwa5FI
	UJgbUXT/PNSIcgkemdcVUSnjuSeQBqICQ87mwB9PdUYKLK5y1btHHuAJdbWeMRHXzVer
	g1Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=9ttBXeBo0HMOPdYgdDUmLLpVjhXIDtbOq+n3b6hKJDo=;
	b=bADM/l3FUztEJKoYE9lsAxzEMZJhAwTzSm6mE7F3NALVthMLy2BHaLjTnmhM/rJlVo
	68LTFajdHAzJcOtgazCsRMYLZRJQ/G9FGwWw2DoRr+IS1CKmy8Y48+F8zmYHPVXt1Iri
	bXHcWMp3HzHGAnx0AwsYgMCfrust7Y5k8AMkUL2Z8Xpy+p/ajPf0c4/GkflxLHckSnlK
	uoF6BvlIxfJbhF8XNHZs24nHIkvAClZuQWk9LmGGhO4JxxHogLskG+9XJ2Jxu9PkNBpH
	J+KGp/CkRVi9rs7KDEBGXiW6LToWuzYJVjuNlE9ukrORuV3IGx0Rt2kdzzmEItsjbums
	N3tQ==
X-Gm-Message-State: AG10YOQEP9mS3q8nER+Zew2EADpCgmw6SN717zRhNwD9g1SHEXeKKhYsdiCVTxVgkrgWrjVfPtvKXF3sqolk6A==
MIME-Version: 1.0
X-Received: by 10.202.3.213 with SMTP id 204mr11730963oid.48.1454780042937;
	Sat, 06 Feb 2016 09:34:02 -0800 (PST)
Received: by 10.157.17.117 with HTTP; Sat, 6 Feb 2016 09:34:02 -0800 (PST)
Date: Sat, 6 Feb 2016 11:34:02 -0600
Message-ID: <CABaSBazCt1Uqs2FJkgCXvpeLnqssz0jwrdfqT20dG+msGWRyxQ@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=001a113b97eaaf9047052b1d5f17
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
X-Mailman-Approved-At: Sat, 06 Feb 2016 17:49:03 +0000
Subject: [bitcoin-dev] Gavin: A Response to Your Forking BIP
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: Sat, 06 Feb 2016 17:34:04 -0000

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

On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen wrote:

> Responding to "28 days is not long enough" :
>

Gavin,

Thank you for the emails. Bitcoin Core has been working with the Bitcoin
ecosystem on developing and now testing a new capacity increasing feature
called segregated witness (segwit). Segregated witness is a voluntary,
mutually backwards-compatible capacity upgrade for the Bitcoin system.
Many, many hundreds of millions of dollars of Bitcoin value have flowed
through soft-forked upgrades to the Bitcoin system, representing upgrades
from across the entire ecosystem and the entire Bitcoin network, over
multiple years including BIP 12, BIP 16, BIP 17, BIP 30, BIP 34, BIP 42,
BIP 62, BIP 65, BIP 66, etc. So that=E2=80=99s the context from which I hav=
e been
approaching your hard-fork ideas for the past year.

Benefits of segregated witness
https://bitcoincore.org/en/2016/01/26/segwit-benefits/

Ecosystem buy-in and support for segregated witness continues to grow:
https://bitcoincore.org/en/segwit_adoption/

There is also a segwit testnet which everyone is encouraged to investigate
and develop against-- companies love them some testing, after all:
https://bitcoincore.org/en/2016/01/21/launch_segwit_testnet/

A plan for Bitcoin Core capacity increases was put forward and can be found
here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/01186=
5.html
https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/

With respect, the question should not be "is 28 days enough time for anyone
to roll out new binaries", it's instead a question of "how long does it
take someone to agree to upgrade to these new incompatible rules".

If Bitcoin users don't want to upgrade to incompatible rules right now, why
would they agree when 10% of the hashpower is setting some flag in a block?
Why would they change their minds at 20%? 90%? I am not saying here that
hard-forks should never be attempted, although we need as an ecosystem to
develop much more rigor and a more data-driven approach, and while that
might be hard to define exactly, as was once said by regulators, =E2=80=9CI=
 know it
when I see it=E2=80=9D. Companies in the financial sector give a year or mo=
re
before deprecating old APIs even after the new one has been up and running
concurrently and well proven, and would not shut off their old one in order
to get adoption of the new one.

Are we OK with some percent of the Bitcoin ecosystem not agreeing with the
existing rules? What would that mean? Are you willing to maintain two
separate networks, and if not, would you please document this in your BIP?
Deprecation timeline and emergency procedures?? Should we include
rationalizations for not using a new address prefix? In the event of a
partial hard-fork where two chains exist, wouldn't it make more sense to
have the new chain use a new address prefix? Using a new address prefix
could conceivably serve to minimize the impact of what almost looks like an
intentionally constructed y2k-bug type of event for the ecosystem.

I suspect that soft-fork upgrades have in the past tolerated _less_ rigor
around planning because voluntary soft-fork upgrading does not
intentionally break backwards-compatibility. Over time I expect that even
soft-fork upgrades will have much more planning, but again, it seems that
incompatible changes require much more rigor. If the sky is truly falling
according to your pronouncements, then there are millions if not billions
of dollars of value on the line which are being risked from lack of
engineering rigor without a well documented procedure, and suggesting that
we agree on that "next time" is not going to create the results that meet
your or anyone else=E2=80=99s desire. Much more, we need to signal to the b=
roader
ecosystem and world that we are serious, mature and ready for business.

Regarding your request for definitions about soft-hard forks and
generalized soft-forks, you can find some definitions over here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173=
.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012172=
.html

About hard-forks you may be interested in reading and internalizing,
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki

This was an interesting exploration of soft-forks and hard-forks:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks

On the security of soft-forks
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014=
.html

Are soft-forks misnamed?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/01126=
6.html

- Bryan
http://heybryan.org/
1 512 203 0507

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

<div dir=3D"ltr">On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen=C2=A0wrote:=
<br><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"><div dir=3D"ltr">Responding to &quot;28 days is not lo=
ng enough&quot; :</div></blockquote><div><br></div><div>Gavin,</div><div><b=
r></div><div>Thank you for the emails. Bitcoin Core has been working with t=
he Bitcoin ecosystem on developing and now testing a new capacity increasin=
g feature called segregated witness (segwit). Segregated witness is a volun=
tary, mutually backwards-compatible capacity upgrade for the Bitcoin system=
. Many, many hundreds of millions of dollars of Bitcoin value have flowed t=
hrough soft-forked upgrades to the Bitcoin system, representing upgrades fr=
om across the entire ecosystem and the entire Bitcoin network, over multipl=
e years including BIP 12, BIP 16, BIP 17, BIP 30, BIP 34, BIP 42, BIP 62, B=
IP 65, BIP 66, etc. So that=E2=80=99s the context from which I have been ap=
proaching your hard-fork ideas for the past year.</div><div><br></div><div>=
Benefits of segregated witness</div><div><a href=3D"https://bitcoincore.org=
/en/2016/01/26/segwit-benefits/">https://bitcoincore.org/en/2016/01/26/segw=
it-benefits/</a></div><div><br></div><div>Ecosystem buy-in and support for =
segregated witness continues to grow:</div><div><a href=3D"https://bitcoinc=
ore.org/en/segwit_adoption/">https://bitcoincore.org/en/segwit_adoption/</a=
></div><div><br></div><div>There is also a segwit testnet which everyone is=
 encouraged to investigate and develop against-- companies love them some t=
esting, after all:</div><div><a href=3D"https://bitcoincore.org/en/2016/01/=
21/launch_segwit_testnet/">https://bitcoincore.org/en/2016/01/21/launch_seg=
wit_testnet/</a></div><div><br></div><div>A plan for Bitcoin Core capacity =
increases was put forward and can be found here:</div><div><a href=3D"https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.htm=
l">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/01=
1865.html</a></div><div><a href=3D"https://bitcoincore.org/en/2015/12/23/ca=
pacity-increases-faq/">https://bitcoincore.org/en/2015/12/23/capacity-incre=
ases-faq/</a></div><div><br></div><div>With respect, the question should no=
t be &quot;is 28 days enough time for anyone to roll out new binaries&quot;=
, it&#39;s instead a question of &quot;how long does it take someone to agr=
ee to upgrade to these new incompatible rules&quot;.</div><div><br></div><d=
iv>If Bitcoin users don&#39;t want to upgrade to incompatible rules right n=
ow, why would they agree when 10% of the hashpower is setting some flag in =
a block? Why would they change their minds at 20%? 90%? I am not saying her=
e that hard-forks should never be attempted, although we need as an ecosyst=
em to develop much more rigor and a more data-driven approach, and while th=
at might be hard to define exactly, as was once said by regulators, =E2=80=
=9CI know it when I see it=E2=80=9D. Companies in the financial sector give=
 a year or more before deprecating old APIs even after the new one has been=
 up and running concurrently and well proven, and would not shut off their =
old one in order to get adoption of the new one.</div><div><br></div><div>A=
re we OK with some percent of the Bitcoin ecosystem not agreeing with the e=
xisting rules? What would that mean? Are you willing to maintain two separa=
te networks, and if not, would you please document this in your BIP? Deprec=
ation timeline and emergency procedures?? Should we include rationalization=
s for not using a new address prefix? In the event of a partial hard-fork w=
here two chains exist, wouldn&#39;t it make more sense to have the new chai=
n use a new address prefix? Using a new address prefix could conceivably se=
rve to minimize the impact of what almost looks like an intentionally const=
ructed y2k-bug type of event for the ecosystem.</div><div><br></div><div><d=
iv>I suspect that soft-fork upgrades have in the past tolerated _less_ rigo=
r around planning because voluntary soft-fork upgrading does not intentiona=
lly break backwards-compatibility. Over time I expect that even soft-fork u=
pgrades will have much more planning, but again, it seems that incompatible=
 changes require much more rigor. If the sky is truly falling according to =
your pronouncements, then there are millions if not billions of dollars of =
value on the line which are being risked from lack of engineering rigor wit=
hout a well documented procedure, and suggesting that we agree on that &quo=
t;next time&quot; is not going to create the results that meet your or anyo=
ne else=E2=80=99s desire. Much more, we need to signal to the broader ecosy=
stem and world that we are serious, mature and ready for business.</div><di=
v><br></div><div>Regarding your request for definitions about soft-hard for=
ks and generalized soft-forks, you can find some definitions over here:</di=
v><div><a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
15-December/012173.html">http://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2015-December/012173.html</a></div><div><a href=3D"http://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2015-December/012172.html">http://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012172.html</a></d=
iv><div><br></div><div>About hard-forks you may be interested in reading an=
d internalizing,</div><div><a href=3D"https://github.com/bitcoin/bips/blob/=
master/bip-0099.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-=
0099.mediawiki</a></div><div><br></div><div>This was an interesting explora=
tion of soft-forks and hard-forks:</div><div><a href=3D"https://petertodd.o=
rg/2016/soft-forks-are-safer-than-hard-forks">https://petertodd.org/2016/so=
ft-forks-are-safer-than-hard-forks</a></div><div><br></div><div>On the secu=
rity of soft-forks</div><div><a href=3D"http://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2015-December/012014.html">http://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2015-December/012014.html</a></div><div><br></di=
v><div>Are soft-forks misnamed?</div><div><a href=3D"http://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2015-September/011266.html">http://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2015-September/011266.html</a></di=
v></div><div><br></div><div>- Bryan<br></div><div class=3D"gmail_signature"=
><a href=3D"http://heybryan.org/" target=3D"_blank">http://heybryan.org/</a=
><br>1 512 203 0507</div>
</div>

--001a113b97eaaf9047052b1d5f17--