summaryrefslogtreecommitdiff
path: root/a1/1a64faa57f6eb3b331f3dcc5e0efec0b3ad285
blob: 71f670da8adf998b3cfb991740511bb6b42099a5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A3E817F0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Sep 2015 06:17:26 +0000 (UTC)
Received: by pacfv12 with SMTP id fv12so201068083pac.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CA+w+GKS74iF2FNuHtds=3R9++sx9ZP-0tcq_j5XqZw9-6uHkVQ@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<CALqxMTFEme9gYHTAVVLtFc4JCK4hoBLXEhMCRdEXK9cWso_pUA@mail.gmail.com>
	<CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
	<4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
	<CA+w+GKSm2Np92+NA77nNMB5LqSyO0=W8dziiMtGO=Jf+7KidHQ@mail.gmail.com>
	<C0E61EA6-76BE-45E0-8983-A3BC26CC64CF@gmail.com>
	<CA+w+GKS74iF2FNuHtds=3R9++sx9ZP-0tcq_j5XqZw9-6uHkVQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----Z1COHDYPKYY1YB42SVUSHWK76BQ7YW"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Mon, 28 Sep 2015 23:17:33 -0700
To: Mike Hearn <hearn@vinumeris.com>
Message-ID: <EE96B281-464B-4B17-BAF6-25F3E30AB238@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>Mike,<br>
<br>
Insults were not really my intention. Let&#39;s set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks.<br>
<br>
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.<br>
<br>
- Eric<br><br><div class="gmail_quote">On September 28, 2015 5:54:33 AM PDT, Mike Hearn &lt;hearn@vinumeris.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>we have NO hard fork mechanism in place that isn&#39;t highly prone to systemic consensus failure.<br /></div></blockquote><div><br /></div><div>Just use an opcode that isn&#39;t currently defined. Done. What about that mechanism is prone to failure?</div><div> </div><div>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 &quot;inherently insecure&quot; seems needlessly trollish - I certainly would disagree, but it&#39;s a different debate.</div></div></div></div>
</blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------Z1COHDYPKYY1YB42SVUSHWK76BQ7YW--