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 B2EB91C7C for ; Mon, 28 Sep 2015 23:17:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D17422A for ; Mon, 28 Sep 2015 23:17:18 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so122386725wic.1 for ; Mon, 28 Sep 2015 16:17:16 -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=rbwUkG1Y/Sik3Yp3ZFvGLLBsQ7a6/8WpFsCBHd0cYNk=; b=lVaYZd7Ts+7pIkPXrMcbw3r1wyqAnuudmlpqHEEXE5/WqZt4vSOungEJaokGz4hFBW BcfFsdlsgZITN4y/M0hE5SDLnoMZse+I9t0jhBp8X1qGvMRN887wbiW3rpDVZr3FuQ3Y cvztrPso3SxB0OaHrA/vZfj0L0o9mRycokGFsh9KiQ30bTJx++ad5jm4tienBdIoE38F ywi2W4xWTjgIFqJjAJGQ8UEggl4bWU9MoaEl09jN9mnxj6q8pAlyF0pAVDD5Sm+hPu+Z Zu+ub6G1w/mjXeZOhGgdoJG3pAVWc1dAkZHRZn0kCm0Z29JrKnyg07CDrJ56IFIPnsg3 KWVw== X-Gm-Message-State: ALoCoQluMlqMbCxKY0ySRRYwXicN9a0av/Y1zdmaet3ujjtExQSwNxlC3LvmdqZk8QrwB1l/04KT MIME-Version: 1.0 X-Received: by 10.180.92.201 with SMTP id co9mr3079413wib.58.1443482236607; Mon, 28 Sep 2015 16:17:16 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Mon, 28 Sep 2015 16:17:15 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Mon, 28 Sep 2015 16:17:15 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> <20150928132127.GA4829@savin.petertodd.org> <20150928142953.GC21815@savin.petertodd.org> <20150928144318.GA28939@savin.petertodd.org> <20150928150543.GB28939@savin.petertodd.org> <8461c6195ca65ce7355f693fa24bb177@xbt.hk> Date: Tue, 29 Sep 2015 01:17:15 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mike Hearn Content-Type: multipart/alternative; boundary=f46d043c7ff2f3f3840520d6e536 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 Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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: Mon, 28 Sep 2015 23:17:18 -0000 --f46d043c7ff2f3f3840520d6e536 Content-Type: text/plain; charset=UTF-8 On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: >> In a hardfork, however, there is no mechanism to stop the old fork and we may have 2 chains co-exist for a long time. > > > There isn't any difference in how long the divergent state exists for. That depends only on how fast people upgrade, which is unaffected by the rollout strategy used. > Yes, there is a difference. Assuming the hashrate majority upgrades, in the case of a softfork non-upgraded miners will try to build on top of the longest chain (the upgraded one) but their blocks will get consistently orphaned for having a too old block version (and if they just increment the version without implementing the new restrictions, then their blocks will be orphaned when they fail to enforce the new restrictions). In the case of a hardfork, the non-upgraded miners will keep on building their own longest valid chain (the upgraded chain is not valid in their eyes), potentially forever. That's not to say softforks are always preferrable. There's cases when a feature can be implemented as a softfork or a hardfork, but the softfork solution is clearly inferior and introduces technical debt. In those cases I prefer a hardfork, but this is not one of those cases. In any case, maybe you want to provide some feedback to bip99, which is about possible consensus rule changes scenarios and a recommended deployment path for each of them (softforks and hardforks are subdivided in several types). This discussion about the general desirability of softforks seems offtopic for the concrete cltv deployment discussion, which assumes softforks as deployment mechanism (just like bip66 assumed it). --f46d043c7ff2f3f3840520d6e536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <bitcoin-dev@lists.linuxfo= undation.org> wrote:
>> In a hardfork, however, there is no mechanism to stop the old fork= and we may have 2 chains co-exist for a long time.
>
>
> There isn't any difference in how long the divergent state exists = for. That depends only on how fast people upgrade, which is unaffected by t= he rollout strategy used.
>

Yes, there is a difference. Assuming the hashrate majority upgrades, in the= case of a softfork non-upgraded miners will try to build on top of the lon= gest chain (the upgraded one) but their blocks will get consistently orphan= ed for having a too old block version (and if they just increment the versi= on without implementing the new restrictions, then their blocks will be orp= haned when they fail to enforce the new restrictions). In the case of a har= dfork, the non-upgraded miners will keep on building their own longest vali= d chain (the upgraded chain is not valid in their eyes), potentially foreve= r.
That's not to say softforks are always preferrable. There's cases w= hen a feature can be implemented as a softfork or a hardfork, but the softf= ork solution is clearly inferior and introduces technical debt.
In those cases I prefer a hardfork, but this is not one of those cases.

In any case, maybe you want to provide some feedback to bip9= 9, which is about possible consensus rule changes scenarios and a recommend= ed deployment path for each of them (softforks and hardforks are subdivided= in several types). This discussion about the general desirability of softf= orks seems offtopic for the concrete cltv deployment discussion, which assu= mes softforks as deployment mechanism (just like bip66 assumed it).

--f46d043c7ff2f3f3840520d6e536--