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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
Return-Path: <digitsu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D6FD567
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Oct 2015 07:02:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com
[209.85.220.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A3F1E87
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Oct 2015 07:02:52 +0000 (UTC)
Received: by qkas79 with SMTP id s79so55188736qka.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Oct 2015 00:02:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=date:mime-version:message-id:in-reply-to:references:from:to:cc
:subject:content-type;
bh=5UBrHW7mFLyANAVD3ApxhOA5Gm29cdQoiVkJt/Cwsx8=;
b=Q8pUsDXHTRX/wIxlM3X6b+tMbj2Ez4ZBvtJNyFqymL25mAHSzzeB8AhSOCj+XoEyg5
MSsMHEOcCPRp74paYLKhEFZH/misSfOBkbbdYKXrAuO0v98x/Wu1H136kE7kZj3dBuQC
M0zBNgP85Esmd1y84K11pz7sxCx6T1V1i0FjaS9iz5zkGaehctJnsv7DqM0FdataNJQr
MMJPe4THDRECpdTUOxsaNqkaBaL9ddh8CzGVEu+fKtkPLAZta6EKpuqIxw5GHEQ7Lz4o
jnC/sdvt2lNIVRo/6mqGYSewZ8ERDbuuCuFq9glFTI7bV6p4Nz28vY3cJmcYJcrIlVtv
YFng==
X-Received: by 10.55.16.71 with SMTP id a68mr30320810qkh.95.1444633371905;
Mon, 12 Oct 2015 00:02:51 -0700 (PDT)
Received: from hedwig-18.prd.orcali.com
(ec2-54-85-253-144.compute-1.amazonaws.com. [54.85.253.144])
by smtp.gmail.com with ESMTPSA id s87sm5395218qkl.5.2015.10.12.00.02.50
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 12 Oct 2015 00:02:51 -0700 (PDT)
Date: Mon, 12 Oct 2015 00:02:51 -0700 (PDT)
X-Google-Original-Date: Mon, 12 Oct 2015 07:02:50 GMT
MIME-Version: 1.0
X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/)
Message-Id: <1444633370859.8a298e9c@Nodemailer>
In-Reply-To: <20151007150014.GA21849@navy>
References: <20151007150014.GA21849@navy>
X-Orchestra-Oid: 4696BF88-304D-4BD6-9E6C-CABB1ABD1301
X-Orchestra-Sig: 4a272ada9788058c6f59ddb3b9f0bec23c7a550d
X-Orchestra-Thrid: TD56C876D-E76D-40BE-ACDA-81C322724964_1514188637025508290
X-Orchestra-Thrid-Sig: 220f0a8934cbc01363a0589b0c2f86c063b6bea8
X-Orchestra-Account: 83cdfba2f0b5e03358d5f5ca4b9224792eb26aca
From: digitsu@gmail.com
To: "Anthony Towns" <aj@erisian.com.au>
Content-Type: multipart/alternative;
boundary="----Nodemailer-0.5.0-?=_1-1444633371062"
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: 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, 12 Oct 2015 07:02:54 -0000
------Nodemailer-0.5.0-?=_1-1444633371062
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thanks for that great breakdown Anthony. I think it helps a lot of us get a=
better handle on the matter without getting too technical.=C2=A0
A couple of questions on some of the points you made I'd like to put out =
there:
First I think your unsaid assumption about the fragility of a soft fork =
showing incorrect confirmations is dependent on the percentage of hash =
power that didn't upgrade. =C2=A0If using your same numbers this was only =
5% of the hash power, the attack is effectively not effective (u less the =
attacker knew an exact merchant that was unfortunately on the minority of =
the network.=C2=A0
-- snip --
=C2=A0- non-upgraded bitcoin nodes: total breakage. there will be a push
=C2=A0 =C2=A0alert telling you to upgrade. anyone who doesn't will think =
they're
=C2=A0 =C2=A0tracking =22bitcoin=22 but will actually be tracking a new =
=22bitcoin-old=22
=C2=A0 =C2=A0altcoin. most non-upgraded miners will presumably realise =
they're
=C2=A0 =C2=A0wasting hashpower and stop doing this pretty quick; and =
remaining
=C2=A0 =C2=A0miners will only create blocks very slowly due to sudden =
reduced
=C2=A0 =C2=A0hashpower, without possibility of difficulty adjustment.=
=C2=A0
----
Is this true=3F I thought that un-upgraded nodes would just dump the new =
blocks from the upgraded miner majority as invalid. This how would they =
even know (besides the PSA) that they were on the wrong side=3F=C2=A0
----snip---
users who
=C2=A0 =C2=A0don't uprade will try to do transactions, but won't see them =
confirm
=C2=A0 =C2=A0for hours or days due to lack of hashpower.
----
But only for txns for users who are using the new OP code right=3F Regular =
transactions will get relayed by both upgraded and in-upgraded nodes and =
miners alike.=C2=A0
=E2=80=94
Regards,
------Nodemailer-0.5.0-?=_1-1444633371062
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22 =
=22http://www.w3.org/TR/REC-html40/loose.dtd=22>
<html><body><div id=3D=22mbx-wrapper=22>
<div id=3D=22mbx-content=22 class=3D=22content=22 onfocus=3D=22didBecomeFir=
stResponder()=22 contenteditable=3D=22true=22 onblur=3D=22didBlur()=22>Than=
ks for that great breakdown Anthony. I think it helps a lot of us get a =
better handle on the matter without getting too technical.=
<div><br></div>
<div>A couple of questions on some of the points you made I'd like to put =
out there:</div>
<div><br></div>
<div>First I think your unsaid assumption about the fragility of a soft =
fork showing incorrect confirmations is dependent on the percentage of hash=
power that didn't upgrade. If using your same numbers this was only =
5% of the hash power, the attack is effectively not effective (u less the =
attacker knew an exact merchant that was unfortunately on the minority of =
the network. </div>
<div><br></div>
<div>-- snip --</div>
<div>
<div> - non-upgraded bitcoin nodes: total breakage. there will be a =
push</div>
<div> alert telling you to upgrade. anyone who doesn't will =
think they're</div>
<div> tracking =22bitcoin=22 but will actually be tracking a =
new =22bitcoin-old=22</div>
<div> altcoin. most non-upgraded miners will presumably realise=
they're</div>
<div> wasting hashpower and stop doing this pretty quick; and =
remaining</div>
<div> miners will only create blocks very slowly due to sudden =
reduced</div>
<div> hashpower, without possibility of difficulty adjustment.=
</div>
<div>----</div>
<div><br></div>
<div>Is this true=3F I thought that un-upgraded nodes would just dump the =
new blocks from the upgraded miner majority as invalid. This how would they=
even know (besides the PSA) that they were on the wrong =
side=3F </div>
<div><br></div>
<div>----snip---</div>
<div>users who</div>
<div> don't uprade will try to do transactions, but won't see =
them confirm</div>
<div> for hours or days due to lack of hashpower.</div>
</div>
<div><br></div>
<div>----</div>
<div><br></div>
<div>But only for txns for users who are using the new OP code right=3F =
Regular transactions will get relayed by both upgraded and in-upgraded =
nodes and miners alike. </div>
<div><br></div>
</div>
<div id=3D=22mbx-old-email=22 contenteditable=3D=22true=22><div =
class=3D=22mailbox=5Fsignature=22 style=3D=22display: block;=22>
<br>—
Regards,</div></div>
</div></body></html>
------Nodemailer-0.5.0-?=_1-1444633371062--
|
