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
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0394540A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Apr 2017 11:48:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
[209.85.213.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 487B7F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Apr 2017 11:48:29 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id s68so97376757vke.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Apr 2017 04:48:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=d1uhrxukvfSHCcu2ctedsZkGSNKe8Y8IhmxkzU16l+w=;
b=dUD8mPQpmhiUS4hZcFavwkFyiaK4AxyANcoXRQa3uN9cWaVN/0WR5l+PA/1j+IidZq
gSS8KpMW/o1cdBDG8Y5hdHlwRJ0pIungrYu84BoOxEms1RE6vyMqe+2cpXVRBi2ar6uW
eJ7gc3vkVIQt2Wrwh36e1HFi/n37jHC9GpTNNQJ/QpZDyIaXs0mIFhkMT0YHroUGJson
qQ1nq0bewKQib3ZdGnjyTjwmSiOQgoP+aqGNGZOoYpZR65uV2JT7LTVLf5MWqVZklCIg
lcccacSvFxnh6FdR8uiqyPd5txFYtm+E+Gvqp3XFCEdl6atvYW3C//8TwUgttnkOr4lM
zuEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=d1uhrxukvfSHCcu2ctedsZkGSNKe8Y8IhmxkzU16l+w=;
b=MncBSxAaUgUaVBDRy/0Bat/XHrAsE0sXrkRpjRdS8PkoOSPRK+mAO56etQZGovzVdJ
y45xcY6wxk6htxVSoY1exsCdqBUBced1sFhb6Z1IMGEo0V8L1UK2gkd2W+/0V45dJ3BX
MPvnzk+++fqf7Pl7G8G0d+TyB/Mnc3tJ2b0195A7CNDXcMf/4x6W3fhkJ5WEX02bb++x
7Dopcrv9yU5LZM1SPh6IEkJyjAgDrNJ3Idlg/3CdJ4ziJ632Gd38lCYfuhwXQ1Y75N0i
BAJEHOZ/XDTw17NEv/h26T20dbrlkDXt2iqqZkLp+kCQW37QcCrEWZJhqgd6l+JgC0g1
tzwA==
X-Gm-Message-State: AFeK/H29GpHe/iyBdgZEVIMbIli+LPK0eLQAZE/GSyI+IP2pzpwgJM3z+AVwWLtNg+d2ltlcfPxZebUpNE36Jg==
X-Received: by 10.31.110.138 with SMTP id j132mr18094903vkc.103.1491738508360;
Sun, 09 Apr 2017 04:48:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.151.136 with HTTP; Sun, 9 Apr 2017 04:48:27 -0700 (PDT)
Received: by 10.31.151.136 with HTTP; Sun, 9 Apr 2017 04:48:27 -0700 (PDT)
In-Reply-To: <CAJR7vkqnRNLv6xpg04Uh2ybu5DQnBSqc5rdBBJ77Dy=EsEAK2Q@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
<CAJR7vkoq8Y_-fbdxN=--gF5wrGByr5oODc4FkTaCEvDSuP0whQ@mail.gmail.com>
<CABm2gDo+XreV1va2rrHrBCf9x-pcGWqjaQcn7ptRJ4jRE=N79g@mail.gmail.com>
<CABm2gDoEBzoyjVVhxJXgzW6dBF=+hN-oo+jP1AWYznaGKA4HKA@mail.gmail.com>
<CAJR7vkqnRNLv6xpg04Uh2ybu5DQnBSqc5rdBBJ77Dy=EsEAK2Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sun, 9 Apr 2017 13:48:27 +0200
Message-ID: <CABm2gDpaPeYXnPq0k6QMdz4t3PYXaSTqay2PJz-7gVcD3ixiRw@mail.gmail.com>
To: Jimmy Song <jaejoon@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c14a23ae392d4054cba6f21
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no 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] A Small Modification to Segwit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sun, 09 Apr 2017 11:48:30 -0000
--94eb2c14a23ae392d4054cba6f21
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Why won't the attacker use asicboost too? (Please don't say because of
patents)
On 9 Apr 2017 12:26 am, "Jimmy Song" <jaejoon@gmail.com> wrote:
> Jorge,
>
> Suppose someone figures out an ASIC optimization that's completely
> unrelated that gives X% speed boost over your non-ASICBoosted
> implementation. If you ban ASICBoost, someone with this optimization can
> get 51% of the network by adding N machines with their new optimization. =
If
> you allow ASICBoost and assuming this gets a 20% speed boost over
> non-ASICBoosted hardware, someone with this optimization would need 1.2N
> machines to get 51%. The network in that sense is 20% stronger against th=
is
> attack in terms of cost.
>
> Jimmy
>
> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>
>> To be more specific, why "being higher will secure the Bitcoin network
>> better against newer optimizations"?
>> Or, to be more clear, let's forget about future "optimizations", let's
>> just think of an attacker. Does asicboost being used by all miners
>> make the system more secure against an attacker? No, for the attacker
>> can use asicboost too.
>> What about the case when not all the miners are using asicboost? Then
>> the attacker can actually get an advantage by suing asicboost.
>>
>> Sometimes people compare asicboost with the use of asics in general as
>> both providing more security for the network and users. But I don't
>> think this is accurate. The existence of sha256d asics makes an attack
>> with general purpose computing hardware (or even more specialized
>> architectures like gpgpu) much more expensive and unlikely. As an
>> alternative the attacker can spend additional resources investing in
>> asics himself (again, making many attacks more expensive and
>> unlikely).
>>
>> But as far as I know, asicboost can be implemented with software
>> running on general purpose hardware that integrates with regular
>> sha256d asics. There is probably an advantage on having the asicboost
>> implementation "in the same box" as the sha256d, yet again the
>> attacker can invest in hardware with the competitive advantage from
>> having asicboost more intergrated with the sha256d asics too.
>>
>> To reiterate, whether all miners use asicboost or only a subset of
>> them, I remain unconvinced that provides any additional security to
>> the network (to be more precise whether that makes "tx history harder
>> to rewrite"), even if it results on the hashrate charts looking "more
>> secure".
>>
>>
>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>> >
>> >
>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > Praxeology Guy,
>> >
>> >> Why would the actual end users of Bitcoin (the long term and short te=
rm
>> >> owners of bitcoins) who run fully verifying nodes want to change
>> Bitcoin
>> >> policy in order to make their money more vulnerable to 51% attack?
>> >
>> >
>> > Certainly, if only one company made use of the extra nonce space, they
>> would
>> > have an advantage. But think of it this way, if some newer ASIC
>> optimization
>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>> with
>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>> secure
>> > the Bitcoin network better against newer optimizations.
>> >
>> >
>> > Why?
>>
>
>
--94eb2c14a23ae392d4054cba6f21
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Why won't the attacker use asicboost too? (Please don=
't say because of patents)</div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On 9 Apr 2017 12:26 am, "Jimmy Song" <<a hr=
ef=3D"mailto:jaejoon@gmail.com">jaejoon@gmail.com</a>> wrote:<br type=3D=
"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Jorge,<div><b=
r></div><div>Suppose someone figures out an ASIC optimization that's co=
mpletely unrelated that gives X% speed boost over your non-ASICBoosted impl=
ementation. If you ban ASICBoost, someone with this optimization can get 51=
% of the network by adding N machines with their new optimization. If you a=
llow ASICBoost and assuming this gets a 20% speed boost over non-ASICBooste=
d hardware, someone with this optimization would need 1.2N machines to get =
51%. The network in that sense is 20% stronger against this attack in terms=
of cost.</div><div><br></div><div>Jimmy</div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Sat, Apr 8, 2017 at 12:22 PM, Jorge T=
im=C3=B3n <span dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" target=
=3D"_blank">jtimon@jtimon.cc</a>></span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">To be more specific, why "being higher will secure the Bitco=
in network<br>
better against newer optimizations"?<br>
Or, to be more clear, let's forget about future "optimizations&quo=
t;, let's<br>
just think of an attacker. Does asicboost being used by all miners<br>
make the system more secure against an attacker? No, for the attacker<br>
can use asicboost too.<br>
What about the case when not all the miners are using asicboost? Then<br>
the attacker can actually get an advantage by suing asicboost.<br>
<br>
Sometimes people compare asicboost with the use of asics in general as<br>
both providing more security for the network and users. But I don't<br>
think this is accurate. The existence of sha256d asics makes an attack<br>
with general purpose computing hardware (or even more specialized<br>
architectures like gpgpu) much more expensive and unlikely. As an<br>
alternative the attacker can spend additional resources investing in<br>
asics himself (again, making many attacks more expensive and<br>
unlikely).<br>
<br>
But as far as I know, asicboost can be implemented with software<br>
running on general purpose hardware that integrates with regular<br>
sha256d asics. There is probably an advantage on having the asicboost<br>
implementation "in the same box" as the sha256d, yet again the<br=
>
attacker can invest in hardware with the competitive advantage from<br>
having asicboost more intergrated with the sha256d asics too.<br>
<br>
To reiterate, whether all miners use asicboost or only a subset of<br>
them, I remain unconvinced that provides any additional security to<br>
the network (to be more precise whether that makes "tx history harder<=
br>
to rewrite"), even if it results on the hashrate charts looking "=
more<br>
secure".<br>
<div class=3D"m_-6497736858983536379HOEnZb"><div class=3D"m_-64977368589835=
36379h5"><br>
<br>
On Sat, Apr 8, 2017 at 6:27 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> w=
rote:<br>
><br>
><br>
> On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br>
><br>
> Praxeology Guy,<br>
><br>
>> Why would the actual end users of Bitcoin (the long term and short=
term<br>
>> owners of bitcoins) who run fully verifying nodes want to change B=
itcoin<br>
>> policy in order to make their money more vulnerable to 51% attack?=
<br>
><br>
><br>
> Certainly, if only one company made use of the extra nonce space, they=
would<br>
> have an advantage. But think of it this way, if some newer ASIC optimi=
zation<br>
> comes up, would you rather have a non-ASICBoosted hash rate to defend =
with<br>
> or an ASICBoosted hash rate? Certainly, the latter, being higher will =
secure<br>
> the Bitcoin network better against newer optimizations.<br>
><br>
><br>
> Why?<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>
--94eb2c14a23ae392d4054cba6f21--
|
