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 6C23B1AB8 for ; Wed, 30 Sep 2015 15:55:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA826254 for ; Wed, 30 Sep 2015 15:55:53 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so68720423wic.0 for ; Wed, 30 Sep 2015 08:55:52 -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=Vft51jEEZ9T+beicKEmSODX5UVlGWvSLaQkHueRIIIU=; b=Gd2jwxNqgDbCK8t6ANlFSizjhUNINZKS19iPZE5kXjEontpeai7ez0sMwzCnZkAh0Z XdiBghtKDCuB6bLvzCrkMgbPpaPsC8OexlMt0G1JJEf3YyhZkSiZzmplsbooUNJ2DZY2 0c+leB/LNTVTlQ0owDPqJ2qG3vA63L756Odl84yTFUG8YbBnk4TPV+y2jgkTgH9NwMa0 N/EMKWPG+ufn0JqISapD/Xo8lP6D8LW4C/BuGJ3nGgV80lDZXL6/ovIOMSHwPIWs5oS0 JGCdXjGldnE/97vrxzB9rUeMYkQDxPV40Io10AQfd25v/sdFpMxzj+uJ520oiMLwcEdV oDew== X-Gm-Message-State: ALoCoQkL9ULiO7mb88hr/qlxjU3ucFHz6xfKM92zI6L5Ln4QHRXUwHMMCSDPb3VbeZkhJDhdbcod MIME-Version: 1.0 X-Received: by 10.180.8.106 with SMTP id q10mr5297659wia.92.1443628552474; Wed, 30 Sep 2015 08:55:52 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Wed, 30 Sep 2015 08:55:52 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> <20150929200302.GA5051@amethyst.visucore.com> <87wpv8ft61.fsf@rustcorp.com.au> Date: Wed, 30 Sep 2015 17:55:52 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Wed, 30 Sep 2015 15:55:54 -0000 On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn wrote: > 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? I didn't talked about how fast miners would upgrade, please read again because I believe I was extremely precise. In both cases I'm assuming there's a minority of the hasrate which doesn't upgrade. In the softfork case, the minority will always build on top of the longest chain (which is valid to them). There may be many little alternative chains that are ignored (and orphaned) by the upgraded miners, but non-upgraded miners will always build on top of the longest chain. In the hardfork case, non-upgraded miners will reject the upgraded chain because it is invalid to them, so they will build on top of the longest non-upgraded chains. Two alternative chains will continue growing forever unless the non-upgraded miners eventually upgrade. In contrast, there won't be 2 alternative chains growing forever in the softfork case even if the minority miners never upgrade. > 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? BIP99 recommends an uncontroversial softfork for this kind of case. You seem to be contradicting BIP99 in many other places. Maybe you want to complain about some of the recommendations in BIP99 (instead of everywhere else): https://github.com/bitcoin/bips/pull/181 On Wed, Sep 30, 2015 at 2:30 PM, Mike Hearn via bitcoin-dev wrote: > This will not change the fact that the rollout strategy is bad and nobody > has answered my extremely basic question: why is it being done in this way, > given the numerous downsides? You seem to be the only one who thinks that softforks have "numerous downsides" over hardforks. So everybody just basically disagrees with the assumption in your question and thus nobody can answer it.