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 E9EE81AED for ; Mon, 28 Sep 2015 12:26:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A1FA11D for ; Mon, 28 Sep 2015 12:26:18 +0000 (UTC) Received: by igxx6 with SMTP id x6so48489402igx.1 for ; Mon, 28 Sep 2015 05:26:18 -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=7ChXvpHVyiIJkZzeJhRTNCJYNxVJmuezVcrXb8mBc00=; b=LHIq1U4YAwY3ORlnociUZNqqjJGYO+EvJyCEuD9HItjW+2ecpKuTQb9sO9RPj8PFhG 16owEFMHhb2rRXfc3hBABf66ipaX2mTA4nqjwR/7LtD43AoDUWWgsGekm11dVZMLfhIy t2zZl8Eo9IEqpIGJbqoeoJBcLPBOwyIBEgCYw= 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=7ChXvpHVyiIJkZzeJhRTNCJYNxVJmuezVcrXb8mBc00=; b=U/V+YLfFNpBW+dGfKe53ioDCKXRc0wYjyCmCiZmjwfyGDOmLbNyxxqHWyAUiBACMvR vY/JG1r+BhCGCRtUCXdIIf1meoiIyJd+IvEXUwaN7+s5sZG/9MC7ZfcxFbFvgKMxesVd IlVeqep7N0h0Y0vrXpfBdsSbOHG4UhWVFJsWuMThyOjgI/uZeTHmSzCIdlDrW8kQcSm6 2KHNWn4pbk0kQzDBj8dR7xkan3LX+NdNeON37iu5TMuY9nE1hTnWjjKQKYVFgi2ifMrs p4Q9PlYxWKcoUXYyHtmG0UaYedmB3L2pmM5Boc7fss+VTzWVlTsT+4fvlO/inHN4+hRq gAMA== X-Gm-Message-State: ALoCoQlCWwJSJUtMmVs9/IWZoxvI58sVO5ahirerp8/MsAUfABrQ4VLJBdCv89+tbobZ2d5CIxxj MIME-Version: 1.0 X-Received: by 10.50.30.130 with SMTP id s2mr11595645igh.69.1443443177942; Mon, 28 Sep 2015 05:26:17 -0700 (PDT) Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 05:26:17 -0700 (PDT) In-Reply-To: <4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com> References: <20150927185031.GA20599@savin.petertodd.org> <4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com> Date: Mon, 28 Sep 2015 14:26:17 +0200 Message-ID: From: Mike Hearn To: Eric Lombrozo Content-Type: multipart/alternative; boundary=047d7bdc0d9ce040170520cdcd00 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: Mike Hearn via 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, 28 Sep 2015 12:26:19 -0000 --047d7bdc0d9ce040170520cdcd00 Content-Type: text/plain; charset=UTF-8 > > Go ahead and object to soft forks...but at least try not to make arguments > based on changing the definitions of terms we all generally agree upon. > I don't intend to do that, and I don't think I am - I know what the difference between a soft and hard fork is and am not trying to confuse or blur the two. To reiterate: this current BIP implements a soft fork. I am not debating that. I am saying it should use a hard fork instead. This will ensure no repeat of the P2SH case where invalid blocks were being found for weeks (or was it months?) after the new rules kicked in, thus exposing SPV wallets and old nodes to unnecessary risk for no benefit. Additionally, I am making it clear that there's no consensus for rolling out the new opcode in this way. As you say, the mechanism has issues. If you read the comments when I wrote my article, you can see that others share the same concerns: https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn --047d7bdc0d9ce040170520cdcd00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Go ahead and object to soft forks...but at least try not = to make arguments based on changing the definitions of terms we all general= ly agree upon.

I don't intend to = do that, and I don't think I am - I know what the difference between a = soft and hard fork is and am not trying to confuse or blur the two.

To reiterate: this current BIP implements a soft fork. I = am not debating that. I am saying it should use a hard fork instead. This w= ill ensure no repeat of the P2SH case where invalid blocks were being found= for weeks (or was it months?) after the new rules kicked in, thus exposing= SPV wallets and old nodes to unnecessary risk for no benefit.
Additionally, I am making it clear that there's no consens= us for rolling out the new opcode in this way. As you say, the mechanism ha= s issues. If you read the comments when I wrote my article, you can see tha= t others share the same concerns:



--047d7bdc0d9ce040170520cdcd00--