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
122
123
124
125
126
127
128
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C9C7B17E6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 14:51:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com
[209.85.213.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5977023C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 14:51:23 +0000 (UTC)
Received: by igbni9 with SMTP id ni9so51682727igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 07:51:22 -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=wGCGP4SSFrjRAHRkl6Uhe1o34TRPIlYAbsCifnvaYaA=;
b=pihHMCgQbcsszOybd9eSxJ4WLqhyCMVyM2QG98FFsk66MmN2f24gUwAr+KPAZzCSAv
kJ0v5C6l98KuDXfUMoYs2ajBN8wxK4FQ7j7WnxopO2buNf9ZCCqHxVdepRU/8RSZsyvr
4AHlc2MvicXJJ1qzxbP0CFGWUZ5Ws/Qx2i028=
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=wGCGP4SSFrjRAHRkl6Uhe1o34TRPIlYAbsCifnvaYaA=;
b=GdwitPsfpfeC6re2WRb2bZ2XYKUCd90zziVa6O7sE2lc3HCugGMUr2p1x2mibfQ3aL
koNLlBOUTh/VNuOXRBYzJsGorLLBVeBzj1bdfRyNpkwadoElEqAIwGXy3HlnNly3js0D
StxfAloCUYLfbj9RBXPSlrrJtImiH7dVLp4be+7WGaNzf9aXLTmOiQU/G3GQdK50FVbD
vbafLqhD6VIZ/Z0RLTWwrmQuyUrrEFfo0gJIvZr1HdGrQlHXYjec8/7dxmWW6yz4ImFg
bjHpF7L9RO7B3pYU0aR4tSam8DAZBzWPcSdqRZ3eTrOkjaE2MVjaD/rDAoKk3EEQ4tsm
Blpg==
X-Gm-Message-State: ALoCoQnhtVqJo70iNyns3YAKcdXC3/L+ilRWKHyOOqHz6an2xKFQUmp0Za4kZk+g71s/FZR9vmV1
MIME-Version: 1.0
X-Received: by 10.50.66.146 with SMTP id f18mr16619492igt.83.1443451882742;
Mon, 28 Sep 2015 07:51:22 -0700 (PDT)
Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 07:51:22 -0700 (PDT)
In-Reply-To: <20150928144318.GA28939@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<20150928132127.GA4829@savin.petertodd.org>
<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
<20150928142953.GC21815@savin.petertodd.org>
<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
<20150928144318.GA28939@savin.petertodd.org>
Date: Mon, 28 Sep 2015 16:51:22 +0200
Message-ID: <CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bdc09f6b8d8bd0520cfd4d3
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 <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: Mon, 28 Sep 2015 14:51:23 -0000
--047d7bdc09f6b8d8bd0520cfd4d3
Content-Type: text/plain; charset=UTF-8
>
> Ok, so again, if that's your security criteria, what's the issue
> with soft-forks?
Please read my article as it's all explained there.
But to reiterate: the risk is that miners will build invalid blocks on top
of the best work chain, instead of an ignored lower work side chain. This
opens users to payment fraud. With a hard fork, all the blocks by miners
that aren't checking all the rules anymore get neatly collected together on
a side chain after the split, and wallets all know how to ignore that chain.
Yes, you made OP_NOPs be non-standard. So out of the box, miners won't
create invalid blocks, as long as they're running Core past that version.
But this makes the IsStandard function very much like a part of the
consensus rules, as bypassing it can result in invalid blocks being
created. Miners have always understood that they can modify this function,
or even bypass it entirely, without affecting the validity of their blocks.
And some miners do exactly that.
So I'll repeat the question that I posed before - given that there are
clear, explicit downsides, what is the purpose of doing things this way?
Where is the gain for ordinary Bitcoin users?
--047d7bdc09f6b8d8bd0520cfd4d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Ok, so again, if that's your security criter=
ia, what's the issue with=C2=A0soft-forks?</blockquote><div><br></div><=
div>Please read my article as it's all explained there.</div><div><br><=
/div><div>But to reiterate: the risk is that miners will build invalid bloc=
ks on top of the best work chain, instead of an ignored lower work side cha=
in. This opens users to payment fraud. With a hard fork, all the blocks by =
miners that aren't checking all the rules anymore get neatly collected =
together on a side chain after the split, and wallets all know how to ignor=
e that chain.</div><div><br></div><div>Yes, you made OP_NOPs be non-standar=
d. So out of the box, miners won't create invalid blocks, as long as th=
ey're running Core past that version. But this makes the IsStandard fun=
ction very much like a part of the consensus rules, as bypassing it can res=
ult in invalid blocks being created. Miners have always understood that the=
y can modify this function, or even bypass it entirely, without affecting t=
he validity of their blocks. And some miners do exactly that.</div><div><br=
></div><div>So I'll repeat the question that I posed before - given tha=
t there are clear, explicit downsides, what is the purpose of doing things =
this way? Where is the gain for ordinary Bitcoin users?</div></div></div></=
div>
--047d7bdc09f6b8d8bd0520cfd4d3--
|
