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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
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 50F3E163D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 15:38:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5040C23F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 15:38:29 +0000 (UTC)
Received: by igcrk20 with SMTP id rk20so56074126igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 08:38:28 -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=rVmIklXnJ8AAucjE2rob47mB+gGGqNjATwcz6ve8m3c=;
b=rHXd+IYmPafcWo2aUUIJBRQXxmLLvbi2F5o6Mxkr7O09M/nBywO2UpCVVeHDJm6BA2
wVyO0zHO3rlapQeq8hatf5ji0ipN7d2sx8tTEsLpxZx0tCk9YS6t+zP6oq5U+o47aqdH
j8IaEgavBjjnpb/LyGV/80SyvzRm30NC3K8E0=
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=rVmIklXnJ8AAucjE2rob47mB+gGGqNjATwcz6ve8m3c=;
b=GXqeSeuu1uC8duDyMYZzhoMWgjlFBSbBkb0cfyVflQWDWUnhgO7/RP4lbSgqz+mV6q
5SlqcMyIpWDGnMqV0NtiWbI+XG6SI3P08hDsM2uN0JyG369+sW3bq+9Z1i8D7/sQd4lZ
3+JOaqNlSSDvnkuZogDaVt6aqFaKniWc9DVWCEYhNN35IO50GVmO1hQyUFx2iQVE3GU8
I2S/YamJByOMYFHUoNp7dpyYtJPCRstvXa111ecMIC943gfHroHik3/m87+FOJV0pDe3
ZSlQ203t8sddL6ooGcK+xfy8wyOCgCXkTaBcJK9gFirjmA1WBtm0ZMOKBTk6BxdwsRZB
INsw==
X-Gm-Message-State: ALoCoQmSm3/WgwpgLtgeFUauVftQL1Ie9/osqhNG93+ryQuxSqnAnuHqG12Ay9vYec1VF7uylXb4
MIME-Version: 1.0
X-Received: by 10.50.30.130 with SMTP id s2mr12793544igh.69.1443454708615;
Mon, 28 Sep 2015 08:38:28 -0700 (PDT)
Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 08:38:28 -0700 (PDT)
In-Reply-To: <20150928150543.GB28939@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>
<CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
<20150928150543.GB28939@savin.petertodd.org>
Date: Mon, 28 Sep 2015 17:38:28 +0200
Message-ID: <CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bdc0d9c286e0e0520d07d48
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 15:38:30 -0000
--047d7bdc0d9c286e0e0520d07d48
Content-Type: text/plain; charset=UTF-8
>
> Can you explain exactly how you think wallets will "know" how to ignore
> the invalid chain?
>
I'm confused - I already said this. For a fork to work, hard or soft, there
must be support from a majority of the hash power.
Therefore, the usual SPV technique of following the highest work chain
results in ignoring the minority chain produced by the hard fork.
BIP 101 is SPV friendly because the wallets would simply follow the 75%
chain and never even be aware anything has changed. It's backwards
compatible with them in this respect: they already know how to ignore the
no-bigger-blocks fork that'd be created if some miners didn't upgrade
during the grace period.
My point about IsStandard is that miners can and do bypass it, without
expecting that to carry financial consequences or lower the security of
other users. By making it so a block which includes non-standard
transactions can end up being seen as invalid, you are increasing the risk
of accidents that carry financial consequences.
That's incorrect: Miners bypassing IsStandard() risk creating invalid
> blocks in the event of a soft-fork. Equally, we design soft-forks to
> take advantage of this.
>
Gah. You repeated what I just said. Yes, I know miners face that risk, my
point is that they do NOT face such a risk when there's no soft fork in
action and have historically NOT faced that risk at all, hence the
widespread practice of bypassing or modifying this function.
All this approach does is make changing IsStandard() the same as changing
AcceptBlock(), except without the advantage of telling anyone about it.
> > 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?
>
> We seem to be in strong disagreement about which option has "clear,
> explicit downsides"
Obviously. So please enlighten me.
How do ordinary Bitcoin users benefit from this rollout strategy? Put
simply, what is the point of this whole complex soft fork endeavour?
--047d7bdc0d9c286e0e0520d07d48
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">Can you explain exactly how you think wallets wi=
ll "know" how to ignore<br>
the invalid chain?<br></blockquote><div><br></div><div>I'm confused - I=
already said this. For a fork to work, hard or soft, there must be support=
from a majority of the hash power.</div><div><br></div><div>Therefore, the=
usual SPV technique of following the highest work chain results in ignorin=
g the minority chain produced by the hard fork.</div><div><br></div><div>BI=
P 101 is SPV friendly because the wallets would simply follow the 75% chain=
and never even be aware anything has changed. It's backwards compatibl=
e with them in this respect: they already know how to ignore the no-bigger-=
blocks fork that'd be created if some miners didn't upgrade during =
the grace period.</div><div>=C2=A0</div><div>My point about IsStandard is t=
hat miners can and do bypass it, without expecting that to carry financial =
consequences or lower the security of other users. By making it so a block =
which includes non-standard transactions can end up being seen as invalid, =
you are increasing the risk of accidents that carry financial consequences.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's incorrect: M=
iners bypassing IsStandard() risk creating invalid<br>
blocks in the event of a soft-fork. Equally, we design soft-forks to<br>
take advantage of this.<br></blockquote><div><br></div><div>Gah. You repeat=
ed what I just said. Yes, I know miners face that risk, my point is that th=
ey do NOT face such a risk when there's no soft fork in action and have=
historically NOT faced that risk at all, hence the widespread practice of =
bypassing or modifying this function.</div><div><br></div><div>All this app=
roach does is make changing IsStandard() the same as changing AcceptBlock()=
, except without the advantage of telling anyone about it.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">> So I'll repe=
at the question that I posed before - given that there are<br>
> clear, explicit downsides, what is the purpose of doing things this wa=
y?<br>
> Where is the gain for ordinary Bitcoin users?<br>
<br>
</span>We seem to be in strong disagreement about which option has "cl=
ear,<br>
explicit downsides"</blockquote><div><br></div><div>Obviously. So plea=
se enlighten me.</div><div><br></div><div>How do ordinary Bitcoin users ben=
efit from this rollout strategy? Put simply, what is the point of this whol=
e complex soft fork endeavour?=C2=A0</div></div></div></div>
--047d7bdc0d9c286e0e0520d07d48--
|
