diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2015-09-29 01:17:15 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-28 23:17:18 +0000 |
| commit | 928de468ae460495cb5242b67cc2b918354451ba (patch) | |
| tree | 8f45a96108c12ed33db1ddf6db938b6f7222e1ac | |
| parent | 08de28a3675b306f08a24a8eecbe77ef2f6b9322 (diff) | |
| download | pi-bitcoindev-928de468ae460495cb5242b67cc2b918354451ba.tar.gz pi-bitcoindev-928de468ae460495cb5242b67cc2b918354451ba.zip | |
Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
| -rw-r--r-- | af/db27b1385f4ece09ef9fe8eafc2a5db4b90e5e | 143 |
1 files changed, 143 insertions, 0 deletions
diff --git a/af/db27b1385f4ece09ef9fe8eafc2a5db4b90e5e b/af/db27b1385f4ece09ef9fe8eafc2a5db4b90e5e new file mode 100644 index 000000000..27ed87464 --- /dev/null +++ b/af/db27b1385f4ece09ef9fe8eafc2a5db4b90e5e @@ -0,0 +1,143 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id B2EB91C7C + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 28 Sep 2015 23:17:18 +0000 (UTC) +Received: by wiclk2 with SMTP id lk2so122386725wic.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CA+w+GKRcUYsKzG8n5ut-ObD1MM9bs0OD-jdHe1+cLkcO6B7wKg@mail.gmail.com> +References: <20150927185031.GA20599@savin.petertodd.org> + <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com> + <20150928132127.GA4829@savin.petertodd.org> + <CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com> + <20150928142953.GC21815@savin.petertodd.org> + <CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com> + <20150928144318.GA28939@savin.petertodd.org> + <CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com> + <20150928150543.GB28939@savin.petertodd.org> + <CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com> + <8461c6195ca65ce7355f693fa24bb177@xbt.hk> + <CA+w+GKRcUYsKzG8n5ut-ObD1MM9bs0OD-jdHe1+cLkcO6B7wKg@mail.gmail.com> +Date: Tue, 29 Sep 2015 01:17:15 +0200 +Message-ID: <CABm2gDrcrtZLQE8Q9ZuxsWEfD_mFhdBz36x3RCPrQtbBi1455A@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +To: Mike Hearn <hearn@vinumeris.com> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <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: 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 + +<p dir=3D"ltr"><br> +On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo= +undation.org</a>> wrote:<br> +>> 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.<br> +><br> +><br> +> 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.<br> +><br> + <br> +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.<br> +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. <br> +In those cases I prefer a hardfork, but this is not one of those cases.</p> +<p dir=3D"ltr">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).</p> + +--f46d043c7ff2f3f3840520d6e536-- + |