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 6A3E817F0 for ; Tue, 29 Sep 2015 06:17:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D9B051B0 for ; Tue, 29 Sep 2015 06:17:26 +0000 (UTC) Received: by pacfv12 with SMTP id fv12so201068083pac.2 for ; Mon, 28 Sep 2015 23:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=gljQU55BMwQuc09d2kakb8Q2CaBKeBwGTP+CVzagp2o=; b=R2ZNjwQSk89RZJZpWof9rP92ygMwgc6/1BkUX+1f03RL5zFp4gqcUxx0lkiSDKyx+t UvCm6qPU+7nbWrgj2VjzKZumYzmxwvpgVO838/NdF3gnJvKEur1tMz6SbXF6Rr3o89rG PKCgifi+5J/MJgFoPwacZLf3rdefiCRAIwXeZVDWEc15N5nLWb6Uq+Tt2lvpX1se4LqP qy86vYh6y90skDzKN9bxqiA8gIiF4zZBm3+ukiVb/wgMkM5uxfCX0e1Nx/uLBYF+2ave 3MnL1IVSeJ15H48Wae6bP7ge8Ee88kVMMSrMOzKbE8Dp0+LDWNW1fbv804GIe8m9MlBJ HJPQ== X-Received: by 10.68.204.37 with SMTP id kv5mr31241933pbc.64.1443507446648; Mon, 28 Sep 2015 23:17:26 -0700 (PDT) Received: from [192.168.1.100] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id i9sm23071596pbq.84.2015.09.28.23.17.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2015 23:17:26 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> <4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----Z1COHDYPKYY1YB42SVUSHWK76BQ7YW" Content-Transfer-Encoding: 8bit From: Eric Lombrozo Date: Mon, 28 Sep 2015 23:17:33 -0700 To: Mike Hearn Message-ID: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: Tue, 29 Sep 2015 06:17:27 -0000 ------Z1COHDYPKYY1YB42SVUSHWK76BQ7YW Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Mike, Insults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks. Other than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard fork make any difference to SPV clients? If, as others have suggested, all clients warn the user on unrecognized nVersion and make unknown noops nonstandard, would this satisfy your concerns? The logic seems pretty straightforward. - Eric On September 28, 2015 5:54:33 AM PDT, Mike Hearn wrote: >> >> we have NO hard fork mechanism in place that isn't highly prone to >> systemic consensus failure. >> > >Just use an opcode that isn't currently defined. Done. What about that >mechanism is prone to failure? > >Re: coma. No need for insults. Please read my article and address the >points raised there, which, by the way, do not include any mention of >SPV >wallets. Although your belief that SPV wallets are "inherently >insecure" >seems needlessly trollish - I certainly would disagree, but it's a >different debate. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------Z1COHDYPKYY1YB42SVUSHWK76BQ7YW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike,

Insults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks.

Other than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard fork make any difference to SPV clients? If, as others have suggested, all clients warn the user on unrecognized nVersion and make unknown noops nonstandard, would this satisfy your concerns? The logic seems pretty straightforward.

- Eric

On September 28, 2015 5:54:33 AM PDT, Mike Hearn <hearn@vinumeris.com> wrote:
we have NO hard fork mechanism in place that isn't highly prone to systemic consensus failure.

Just use an opcode that isn't currently defined. Done. What about that mechanism is prone to failure?
 
Re: coma. No need for insults. Please read my article and address the points raised there, which, by the way, do not include any mention of SPV wallets. Although your belief that SPV wallets are "inherently insecure" seems needlessly trollish - I certainly would disagree, but it's a different debate.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------Z1COHDYPKYY1YB42SVUSHWK76BQ7YW--