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 2234D1E24 for ; Wed, 30 Sep 2015 18:15:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2ABC18D for ; Wed, 30 Sep 2015 18:15:05 +0000 (UTC) Received: from mail-io0-f176.google.com ([209.85.223.176]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0MS3pM-1a68qQ2fr0-00TFKa for ; Wed, 30 Sep 2015 20:15:04 +0200 Received: by ioii196 with SMTP id i196so57513538ioi.3 for ; Wed, 30 Sep 2015 11:15:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.15.27 with SMTP id x27mr6498356ioi.51.1443636903964; Wed, 30 Sep 2015 11:15:03 -0700 (PDT) Received: by 10.50.32.164 with HTTP; Wed, 30 Sep 2015 11:15:03 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Wed, 30 Sep 2015 14:15:03 -0400 Message-ID: From: Adam Back To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:PX3SA1xlyr/HIUU64Oh6Qj1DTkgWg/zIq7Mb0qGhvk67SP7Om9U iSV3nNGyi+ZVhsoFGkF0CS9G75mNBfGkR6/ULBBglju7qH+qv58/QO06uh0KbX8MFTZTkep 6Kf24MNu/PIrlB9E6JTj7vb9W8ouxP8BQQyNx6ivMiyWWd2yKtGx0tYmSozIyfql15qUtdF GlZCH4w9yBQGlkvpY9m8Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:xiSRVqB2Q3k=:NpTkvh7STCG84PGcN6XAyN ibo+OrAcdKeb5isI5yacoB51PgbrB6UUWluU+dX7TV6xcUrCYmVZ3KK6GaFZpK9uqg9tJVWVe WND+DBWt0lGx1fGVoHmoem8WhOxsUdjgK5mNf3CA1Ci6Be9PMXw/tQPHLsgp5VcLWKHUAZkvR OPO0JQDpp4PWcL7/jCiQcVrm3OfcFP+11JTVyfsOOfI0O2RuNUGZJkUvo5C6P4HYOJUVEexhQ NmS8DfWIUCH+B0JYE9QUMUFCe4F/fhwLHHRvOkozL8VA+U/RKYmAQuux/gDU3a8saITUfZOaX gr0V0XHf7bS11+aXnNrOC39oDbQl1/1Rw6I361MU34fCEzwcehdI4bD2XINioHV46ZnuQqADA RCko4VAR9JB7JXmUUXua/FaOX86monqZBAC94k4W8JieccMwbflGdDp1bpn2XJ8rgMmXVwamZ 4Zbr/bPukoTvilaUUW8pGJrSaXeZdf3bNg5Ub2lpFEuLlhRSqPxs0viE1EkSWKGuqF0uD5jWG Dw4bkNRwGx6Pcx5INEMMm2lhHWw4l5b6HiKAW7PYolVIV4zi1mH/Pr9tzJmgnDKtQx0AdnI8M JRMXQn89sgc+jNnhcYXNCQIRVCxe8mgDTVmKWrps+XIX1L8Rguj4lkE99ej9QgTxosNV1haye p/qt4ItzI8xiAweT4Gx1NS8A0JSmxFx+kLlRZoACi6CXxQA== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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 18:15:06 -0000 On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev wrote: >> Have I missed a proposal to change BIP101 to be a real hardfork > > There's no such thing as a "real" hard fork - don't try and move the goal > posts. SPV clients do not need any changes to do the right thing with BIP > 101, they will follow the new chain automatically, so it needs no changes. BIP101 is a hybrid: in some ways it is a hard-fork and in other ways it is a soft-fork. It is a hard-fork to full-nodes, but also a soft-fork to SPV clients, as by definition the SPV miners are having changes made whether they approve or not as they are not even aware of the change. > To repeat: CLTV does not have consensus at the moment. I think people are saying CLTV is long discussed and does have consensus. > 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? > > 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. Let's not conflate CLTV with a discussion about future possible deployment methods. Forks are an interesting but different topic. Soft-forks have a lot of mileage on them at this point, hard-forks do not, and are anyway inherently higher riskier, even ignoring our lack of practical experience with planned hard-forks. With a soft-fork, while it's clear there is a temporary security model reduction for SPV nodes (and non-upgraded full nodes) in the period before they upgrade, this is preferable to the risks of a system-wide coordinated hard-fork upgrade. There is some limit if the complexity of soft-forking a feature is quite complicated (eg one could argue that with soft-fork extension-blocks vs hard-fork method of increasing block-size for example). So the balance, which I think is easily met with CLTV, is that soft-fork is simple-enough technically and the feature is entirely non-controversial and additive functionality improvement without downside or reason for dissent. To my view this is an answer to your question "what is the specific benefit to end users of doing [soft-forks]" -- it is a lower risk, and therefore faster way to deploy non-controversial (additive) changes. Given the CLTV is useful for improving lightning efficiency this is good for improving Bitcoin's scalability. Adam