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 85F9E1DB7 for ; Tue, 29 Sep 2015 12:07:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9B42138 for ; Tue, 29 Sep 2015 12:07:24 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so74974673igb.0 for ; Tue, 29 Sep 2015 05:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kGeyenhX23BguyxUgYiOoaajHaWAyg9HnVF0iBXpw2M=; b=XFqr5BYSzizCh8bkR6o7vjxccOTpuh3zrsRJg3xYxedw8KjsOtDBVSmr6YqAlgaJ6P W6sSr5TSW7Cj4Pv93kCwXvjX6mpCNRdB/3k0mXgqsPKKT6zFli99ZKunId8DDpIX7rvH VSCQEWceDmHPTuuV/Ui96g09ROdKjDhoX4dPI= 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=kGeyenhX23BguyxUgYiOoaajHaWAyg9HnVF0iBXpw2M=; b=BabOs4+IGd+EDcSFXf86Y+sDaE1cBANTGaUrOtNMkwHcGV9sptD7LOHe8ASABZRxVW eRMUC5fqJ5cY665rxQUleljT5I1SYxxEHh9k3uy2B1ZjS8kEM6cmBwDjOlAyBHCG7+p9 riXoa1x9oPzldKZQox7kLVrubEDXCIulKfm/60vxMimQAS1PSF6WEfc8M9GinyWQH55b QIkvrVyqqJgN5ROuTIu0cgdeNtjiGfU6sWXMXlFUkP9znzuzq0ZBzXZL3jgcjPk/ncrI y/cf32bVLh+rQ9lDynrZyP5icVy276MtmYN0FrAnVu0AN+6XfoGXr+UKVizu/BFUKSDJ soKA== X-Gm-Message-State: ALoCoQnlViGCBImgUhj9KCWYL2C2eZSCB/pxoaMVWuePFYBtLyDlCdOD+TjkIbfGWP/JWHjNaaMh MIME-Version: 1.0 X-Received: by 10.50.17.4 with SMTP id k4mr22795549igd.34.1443528444182; Tue, 29 Sep 2015 05:07:24 -0700 (PDT) Received: by 10.50.226.144 with HTTP; Tue, 29 Sep 2015 05:07:24 -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 14:07:24 +0200 Message-ID: From: Mike Hearn To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=089e011767bf23e9a90520e1a8d3 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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: Tue, 29 Sep 2015 12:07:25 -0000 --089e011767bf23e9a90520e1a8d3 Content-Type: text/plain; charset=UTF-8 Hi Jorge, Yes, there is a difference. Assuming the hashrate majority upgrades, in the > case of a softfork [snip] ...... In the case of a hardfork [snip] > Yes, I know what the difference between them is at a technical level. You didn't explain why this would make any difference to how fast miners upgrade. The amount of money they lose in both cases is identical: they are equally incentivised to upgrade with both fork types. Additionally, you say in a hard fork the other chain may "continue forever". Why do you think this is not true for miners building invalid blocks on top of the main chain? Why would that not continue forever? There just isn't any difference between the two fork types in terms of how fast miners would upgrade. Heck if anything, a hard fork should promote faster upgrades, because if a miner isn't paying attention to their debug.log they might miss the warnings. A soft fork would then look identical to a run of really bad luck, which can legitimately happen from time to time. A hard fork results in your node having a different height to everyone else, which is easily detectable by just checking a block explorer. > 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). > Isn't that circular? This thread is about deployment of CLTV, but the BIP assumes a particular mechanism, so pointing out problems with it is off topic? Why have a thread at all? --089e011767bf23e9a90520e1a8d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jorge,

Yes, there is a = difference. Assuming the hashrate majority upgrades, in the case of a softf= ork [snip] ...... In the case of a hardfork [snip]

Yes, I know what the difference between them is at a technical level. You = didn't explain why this would make any difference to how fast miners up= grade. The amount of money they lose in both cases is identical: they are e= qually incentivised to upgrade with both fork types.

Additionally, you say in a hard fork the other chain may "continue = forever". Why do you think this is not true for miners building invali= d blocks on top of the main chain? Why would that not continue forever?

There just isn't any difference between the two f= ork types in terms of how fast miners would upgrade. Heck if anything, a ha= rd fork should promote faster upgrades, because if a miner isn't paying= attention to their debug.log they might miss the warnings. A soft fork wou= ld then look identical to a run of really bad luck, which can legitimately = happen from time to time. A hard fork results in your node having a differe= nt height to everyone else, which is easily detectable by just checking a b= lock explorer.

This disc= ussion about the general desirability of softforks seems offtopic for the c= oncrete cltv deployment discussion, which assumes softforks as deployment m= echanism (just like bip66 assumed it).

Isn't that circular? This thread is about deployment= of CLTV, but the BIP assumes a particular mechanism, so pointing out probl= ems with it is off topic? Why have a thread at all?
--089e011767bf23e9a90520e1a8d3--