Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 461761B52 for ; Mon, 5 Oct 2015 12:10:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA1BA1AB for ; Mon, 5 Oct 2015 12:10:41 +0000 (UTC) Received: by ioiz6 with SMTP id z6so182265167ioi.2 for ; Mon, 05 Oct 2015 05:10:41 -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=/p0fnX8UBcfxGw/l0UZqa6egrAaVEdFnSluKVDl77gw=; b=VyfHFrLeXFBDpt1PG2BTk1ToYrvOb4Vf+Uk48RCYPUHnHKSQUmDkSDa8BfI8OqQzyy BudfCYq/QaN31zpvTSzz1vvSU8uPnK/oR1haaOxngrdQDrIagfMWGP+gO+3IApncH6NU NgRNMu41ZoV6DKGQOGXYw3Ii7jpq6Ikkr4Cqw= 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=/p0fnX8UBcfxGw/l0UZqa6egrAaVEdFnSluKVDl77gw=; b=YezG+FjuEx028Oq9w+j/Tqa957QgeU0t+b1ZRaW4DCySBxwGQ51rIDhJ4rjiywB1mk UQtZ/KBQVPorD1+HeAlyV241xXQQC55SJZFkWvm4Y9ViVm9veem08Z/Chh7a6P+dZpsG SudymypUKro8L+0KyeUBmpacr3Ouw6O3NdiCZr+dJq4jBevR8dCkZf3vMl1o533iSxKG X8ofakkRBmMYYKnLvgDMuMx/0KNRL2wNwbmTF/ngLf5/p7jHr7jir1YNM4A4lf6XQZ9H USdj/pQOKMFLFYDu8pPza7BpwWi2Zg0G2B3yL82bfOZxWd88yhUTMJBgtFC3D+iY6yC8 qtCQ== X-Gm-Message-State: ALoCoQncpDJmbQhaI2StKlH3msyB+5Urvbh0eEJ0cIJgaVAMQXSB95CMr5YiOIWEvVV3v/fgrKno MIME-Version: 1.0 X-Received: by 10.107.137.144 with SMTP id t16mr28689840ioi.102.1444047041138; Mon, 05 Oct 2015 05:10:41 -0700 (PDT) Received: by 10.50.123.166 with HTTP; Mon, 5 Oct 2015 05:10:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Oct 2015 14:10:40 +0200 Message-ID: From: Mike Hearn To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a113fb1e4ed2cac05215a6670 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: Mon, 05 Oct 2015 12:10:42 -0000 --001a113fb1e4ed2cac05215a6670 Content-Type: text/plain; charset=UTF-8 Hi Jorge, I'm glad we seem to be reaching agreement that hard forks aren't so bad really and can even have advantages. It seems the remaining area of disagreement is this rollout specifically. > a non-upgraded full node and an upgraded full will converge on what they > see: "the most-work valid chain" will be the same for both. > Indeed it will, but the point of fully verifying is to *not* converge with the miner majority, if something goes wrong and they aren't following the same rules as you. Defining "work" as "converge with miner majority" is fine for SPV wallets and a correct or at least reasonable definition. But not for fully verifying nodes, where non-convergence is an explicit design goal! That's the only thing that stops miners awarding themselves infinite free money! > Are you going to produce a bip65 hardfork alternative to try to convince > people of its advantages over bip65 (it is not clear to me how you include > a new script operand via hardfork)? > No, I'm focused on the block size issue right now. I don't think there's much point in improving the block chain protocol if most users are going to be unable to use it. But the modification is simple, right? You just replace this bit: CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode with this CHECKLOCKTIMEVERIFY defines a new opcode (0xc0) and that's it. The section *upgrade and testing plan* only says TBD so that part doesn't even need to change at all, as it's not written yet. --001a113fb1e4ed2cac05215a6670 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jorge,

I'm glad we seem to be reaching agr= eement that hard forks aren't so bad really and can even have advantage= s. It seems the remaining area of disagreement is this rollout specifically= .

a non-upgraded full node and an upgr= aded full will converge on what they see: "the most-work valid chain&q= uot; will be the same for both.

Indeed it will, but th= e point of fully verifying is to not=C2=A0converge with the miner ma= jority, if something goes wrong and they aren't following the same rule= s as you. Defining "work" as "converge with miner majority&q= uot; is fine for SPV wallets and a correct or at least reasonable definitio= n. But not for fully verifying nodes, where non-convergence is an explicit = design goal! That's the only thing that stops miners awarding themselve= s infinite free money!

Are you going t= o produce a bip65 hardfork alternative to try to convince people of its adv= antages over bip65 (it is not clear to me how you include a new script oper= and via hardfork)?

No, I'm focused on the block size issue right now. I= don't think there's much point in improving the block chain protoc= ol if most users are going to be unable to use it. But the modification is = simple, right? You just replace this bit:
<= br>
=C2=A0=C2=A0CHECKLOCKTIMEV= ERIFY redefines the existing NOP2 opcode

with this

=C2=A0=C2= =A0CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)

and that&#= 39;s it. The section upgrade and testing plan only says TBD so that = part doesn't even need to change at all, as it's not written yet. --001a113fb1e4ed2cac05215a6670--