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 938511B85 for ; Wed, 30 Sep 2015 17:58:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD21A128 for ; Wed, 30 Sep 2015 17:58:46 +0000 (UTC) Received: by wicge5 with SMTP id ge5so208413276wic.0 for ; Wed, 30 Sep 2015 10:58:45 -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=pgaT7ZqW5QPCzF2n/a5KAYf1kfpkLiqB594/VSCFHlc=; b=mnTRYEJi6zI8q+ABdmbyj8UCvCYYgXAh0iVAivrJQFYBBaKYq7mw8O00ksZ5LJJLl5 pty5YAEipuWrBMjIQV8rzBUnPfunp1F8jfo0nes5heEc2OQsXkASaXbkJWutKv4IS7sd OtdlTq4ALfDDSOHVJy5sH56KKkSMIxgr9MFe3LOVvc03Raf+L2mhpplVT0Q6z0YaoXhT zwoRs/5ORb3qi4cUcSMZOYHGdfk5/p0gAlDgfhqvhxxMFgxBVAalIm6koW8CoxTW4exi FuMGBw93v+RNHbB9SrdfKmG403sIvMuJ13EGh9a3YlMN85Tmr4b5zrgvfKlLL8j3Nu/p Ro7g== X-Gm-Message-State: ALoCoQnBkVdwWGy+Hmy5ndQhdW3pQktPgL6oC6Lw8phJNjUP17qX2hJwFqzYY7VGqgT6vHWqbJk/ MIME-Version: 1.0 X-Received: by 10.180.8.106 with SMTP id q10mr5927581wia.92.1443635925573; Wed, 30 Sep 2015 10:58:45 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Wed, 30 Sep 2015 10:58:45 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Wed, 30 Sep 2015 19:58:45 +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 17:58:47 -0000 On Wed, Sep 30, 2015 at 7:11 PM, Mike Hearn via bitcoin-dev wrote: > Several people have asked several times now: given the very real and widely > acknowledged downsides that come with a soft fork, what is the specific > benefit to end users of doing them? As previously explained, the biggest advantage of softforks is that assuming the hasrate majority upgrades, network convergence is guaranteed. I don't know of anyone else (apart from you) that believes that the advantages of softforks are generally worse than those of hardforks. I'm attempting to clarify everything related to consensus rule changes in BIP99. > Until that question is answered to my satisfaction I continue to object to > this BIP on the grounds that the deployment creates financial risk > unnecessarily. To repeat: CLTV does not have consensus at the moment. But your argument is flawed because it assumes softforks are more risky than hardforks. You've been explained why this is not the case, so unless you can explain what's more important for a consensus system than network convergence I think we can still consider this consensus rule change uncontroversial, just like BIP66 was (even if you were also unable to understand the advantages of softforks back then, just like you are unable to understand them now, as you just proved in your answer to my explanation). Using BIP99's terminology, this is an "uncontroversial softfork" and it's therefore the safest option for consensus rule changes deployment. I should definitely improve my explanation on why uncontroversial softforks are preferrable to uncontroversial hardforks in most cases (and maybe try to come up with an example in which a hardfork is preferable). I should also explain the disadvantages of uncontroversial softforks that you have pointed out several times. So I will mention you in BIP99's PR once I update it with a new section that talks about the trade offs of uncontroversial softforks vs uncontroversial hardforks. In the meantime I believe that we can safely move forwards with BIP65 (again, just like we did with BIP66 ) and I also believe that you, as an expert in Bitcoin, will eventually be able to understand the advantages of uncontroversial softforks. With all due respect, I don't think we need to wait for you to understand the advantages of softforks to move forward with BIP65, just like we didn't need to wait for every developer and user to understand BIP66 to deploy it. You don't have specific complaints against the new script operator, and you don't have an uncontroversial hardfork alternative design (or implementation). This is a feature that enables new contracts that are important to Bitcoin. Please don't try to block it just to make a point about what "uncontroversial" means.