From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A61E610D9 for ; 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 ; Sat, 6 Feb 2016 17:34:03 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id s2so59908982oie.2 for ; 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: From: Bryan Bishop To: Bitcoin Dev , Bryan Bishop 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen=C2=A0wrote:=
Responding to "28 days is not lo= ng enough" :

Gavin,
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.

= Benefits of segregated witness

Ecosystem buy-in and support for = segregated witness continues to grow:


A plan for Bitcoin Core capacity = increases was put forward and can be found here:

With respect, the question should no= t 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 agr= ee to upgrade to these new incompatible rules".

If Bitcoin users don'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.

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'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.

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" 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.

Regarding your request for definitions about soft-hard for= ks and generalized soft-forks, you can find some definitions over here: