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 325B01B1D for ; Tue, 29 Sep 2015 18:31:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CACD7110 for ; Tue, 29 Sep 2015 18:31:29 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so83737459igb.0 for ; Tue, 29 Sep 2015 11:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wXKrZ94mS+If/68o7H7NO9+U+7KU28/hnVUJvwrlluA=; b=S0wBL+sSyyq9p8AqeX4mVBwBRrLt+Ma+/ltjCy9kDauaMivrLRz/q6SK12TahSnbA7 9SFz5JXGYuPMT/ZYLYTJF0nIOd9JQAdOdb7xo4x0ivLjuJlB4taDW95gXRt+BL88kQzu /SWQOimpXEYFvFHgbFw5xXuVUInkOVIco+1ksWFVf4LzojbAcppJJD44phLFWMziWsSY ycBx3IwnNRq8Yf5pJ1fH24y7ydhPutJA9VIHZhdUq6/06rMYUS7JzXIv1VeltlS1oKzr w34nwEwcyS8gZNuuZP1R3KcSzapxeLSSMFA+gpqdbk3VL5tIp9XEuelt6bdaJ5HIDJ0T evDw== MIME-Version: 1.0 X-Received: by 10.50.23.80 with SMTP id k16mr204564igf.62.1443551489201; Tue, 29 Sep 2015 11:31:29 -0700 (PDT) Received: by 10.107.19.30 with HTTP; Tue, 29 Sep 2015 11:31:28 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Tue, 29 Sep 2015 18:31:28 +0000 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 18:31:30 -0000 On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev wrote: > There is no consensus on using a soft fork to deploy this feature. It will > result in the same problems as all the other soft forks - SPV wallets will > become less reliable during the rollout period. I am against that, as it's > entirely avoidable. > > Make it a hard fork and my objection will be dropped. I'm surprised to see this response-- BIP65 is a year old now which is plenty of time to mature and for issues to be uncovered. It (and its predecessors) have had extensive discussion-- with no controversy exposed during its entire lifetime, but in any case... I am having a little difficulty making sense of this complaint. For all any of us know miners are already enforcing the validity of CLTV, it's indistinguishable on the visible behavior. At the same time in BitcoinXT's 101 proposal the change in system rules is similarly "invisible" to existing "SPV" wallets in the same way that enforcement of CLTV is "invisible": both are no change from their perspective. Have I missed a proposal to change BIP101 to be a real hardfork (e.g. be invalid from the perspective of historical bitcoinj clients too)? ---- I'd think it to be completely reasonable to do so, even while not thinking that it would be reasonable here: Softforks and hardforks are not the same thing, not technically, and not politically. Miners can collectively, at their whim, impose any kind of soft fork they want, at any time and you won't even necessarily be able to tell... that is just how the system works. Hardforks on the other hand, can only happen with the consent of the participants-- they can directly violate system properties that the participants believe to be largely nonvolatile, and they _force__ software upgrades, so I think having a higher bar makes good sense there. The particular mechanism used in the proposal as-is has been used many times before (and has been refined over time) and we have considerable experience with it. The behavior is not, in fact, truly invisible to non-upgraded participants: it's is visible by way of the block version changing. Bitcoin Core, going back years, responds by issuing a warning-- "%s: %d of last 100 blocks above version %d\n" which then becomes "Warning: This version is obsolete; upgrade required!". Users of the software (directly or via automation) are free to decide to take whatever policy action they wish to take, delay accepting transactions, patching software, etc.. The same could be done by any client of the system if they cared to do so. I believe the versionbits mechanism will be superior, but-- among other things-- its deployment has been complicated by BitcoinXT deploying an incomplete approximation of it. Versionbits primary advantage is related to having multiple concurrent proposals in flight, which will be good to have but isn't itself a reason not to pull a proposal up ahead of versionbits.