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
|
Return-Path: <jaejoon@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A180727
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 14:35:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E21C186
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 14:35:32 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id w64so10487136wma.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 08 Apr 2017 07:35:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=FENJcUIycttol+kxsDGswT8t1OKyHW0OSQ5/ovWv8/Y=;
b=m8X71JhSiNsqqnDXZP6QtZdyodID2pSxGqHhBCVYeuwwqt1HwfnsaeyoQbNljcxE9I
6wbg8NjlMDZEF/slxo527Bx5IbAJZI64OmbPGDv5eI8X1QWak/CmUXm5wqDOtHhQT9q6
LD1gb+xYmwWT5ytxiUUYn8HcAResP3Wi52xJSMhKElF6Rb9oCO6sfGf4LgU3q8GEMbf0
Ai7Gngh+PoS5G7Xzy+ptkrzqlp7XY1j495J9un5pqrh1wUJabMTVPG49e0vQLD9T9iPB
hYSZJFK+ACbWACynzOZz3yGah0wBeSv4ppkLELuOhtxWuvqXjoG8slo2R2eqvTp28n7A
kV7Q==
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=FENJcUIycttol+kxsDGswT8t1OKyHW0OSQ5/ovWv8/Y=;
b=UdBTANMSr2GNs2gw+soJJGnsGX7OEzJp0r9e4ZzqaxCxAVUBy946VPKv8kSEglh6PN
DVuULcaq2PwYUfIL6ONAdLlydOtQjim5GV1oWk0AgBE0mBoy8D6hlT01B4vJdgOQPOtI
uz3fZu301trR4mfkZVxoUuP4DPWs842WVhM8Xz0cvXFheaoLaNcV4BkBl0QXek9U358J
mn0PcnXPIIKm+dNEXKkYrAV2YdBWWsdXYEUEqXprB+i/mJA/y8nlVKlRCquiyB8xmm7T
tRkjfa78zYiLuYzWZl3FVA/rYNFqkPlz5xbYKVaKUD0CWj/N1RC1UURZRR8BY6MSjxOu
zxuw==
X-Gm-Message-State: AN3rC/6wsfNsem63LZPee0QXD3csKwiiNdtmCw11OFECqpKfEY38MrzAm7MkfDbPmTal7+X67CjBM3OFVPZSsQ==
X-Received: by 10.28.60.6 with SMTP id j6mr3352966wma.19.1491662131304; Sat,
08 Apr 2017 07:35:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.169.246 with HTTP; Sat, 8 Apr 2017 07:35:30 -0700 (PDT)
In-Reply-To: <CACDYSUROutAMV7C8pUXz0PMvH5awkw-XUtce7BxTtZMD_yUm5A@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
<CAJR7vkoq8Y_-fbdxN=--gF5wrGByr5oODc4FkTaCEvDSuP0whQ@mail.gmail.com>
<CACDYSUROutAMV7C8pUXz0PMvH5awkw-XUtce7BxTtZMD_yUm5A@mail.gmail.com>
From: Jimmy Song <jaejoon@gmail.com>
Date: Sat, 8 Apr 2017 09:35:30 -0500
Message-ID: <CAJR7vkrn-oFium3wFgcOdqNPuYq+rW2DqyOnkDaCTHabO0y3Xg@mail.gmail.com>
To: Pavel Moravec <pavel.moravec@braiins.cz>
Content-Type: multipart/alternative; boundary=001a1148e60a7622b0054ca8a77f
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 08 Apr 2017 14:38:55 +0000
Cc: Bitcoin Protocol Discussion <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: Sat, 08 Apr 2017 14:35:33 -0000
--001a1148e60a7622b0054ca8a77f
Content-Type: text/plain; charset=UTF-8
Pavel,
Until all miners update (firmware or hardware), the change encourages
> large difference in mining efficiency. And IMO it gives another
> advantage to large mining operations in general.
>
Certainly, there would have to be changes for stratum, pool software, etc.
But the monetary incentives align to all the changes needed.
Remember, overt ASICBoost can get something like a 12.5% efficiency boost
from toggling a single bit in the version (equivalent to 2 colliding work
items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4%
from 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf).
In lieu of an explicit allowance of overt ASICBoost, the monetary
incentives lead to odd BIP9 signaling, especially if 4 or more proposals
signal at once. There really isn't a practical way to block overt ASICBoost
without forcing the version bits to be some value.
In other words, the question isn't about allowing/disallowing ASICBoost at
this point. The question is whether we want ASICBoost open or hidden.
> You make a strong assumption that the new optimization is not
> compatible with overt ASICBoost. If it is compatible, ASICBoost
> doesn't help you with "defending against" the new optimization at all.
> And it can be the case that the new optimization is based on ASICBoost
> so you can make the situation "worse" by allowing it.
>
This would only be the case if overt ASICBoost were not possible at all. It
is currently possible to use overt ASICBoost, so optimizations based on
overt ASICBoost would also be possible unless something were done to
actively block it.
> Certainly, if only one company made use of the extra nonce space, they
> would have an advantage.
>
> Can you explain why the reality should be significantly different? In
> sufficiently near future.
Market incentives, I would imagine. How quickly that would be is not
something I'm qualified to answer.
> We don't have to deal with any such theoretical situation now. You
> proposal goes in opposite direction, by adding support for patented
> algorithm. I don't know myself what the possible legal implications
> are (maybe only for a subset of miners) so I consider it as an
> unnecessary risk. At least before some conclusive legal analysis says
> differently.
>
I'm not adding support as much as explicitly allowing what's implicitly
allowed. Whatever risks you imagine for this proposal exist on the network
currently, with unmodified BIP-141 and with modified BIP-141. The
difference in adding the modification is that overt ASICBoost is explicitly
allowed in the modified BIP-141 as to not hide it.
Jimmy
--001a1148e60a7622b0054ca8a77f
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"><div=
>Pavel,</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
Until all miners update (firmware or hardware), the change encourages<br>
large difference in mining efficiency. And IMO it gives another<br>
advantage to large mining operations in general.<span class=3D"gmail-"><br>=
</span></blockquote><div><br></div><div>Certainly, there would have to be c=
hanges for stratum, pool software, etc. But the monetary incentives align t=
o all the changes needed.=C2=A0</div><div><br></div><div>Remember, overt AS=
ICBoost can get something like a 12.5% efficiency boost from toggling a sin=
gle bit in the version (equivalent to 2 colliding work items), 18.5% from 2=
bits (equivalent to 4 colliding work items), 23.4% from 4 bits (see <a hre=
f=3D"https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf">https://arxiv.=
org/ftp/arxiv/papers/1604/1604.00575.pdf</a>). In lieu of an explicit allow=
ance of overt ASICBoost, the monetary incentives lead to odd BIP9 signaling=
, especially if 4 or more proposals signal at once. There really isn't =
a practical way to block overt ASICBoost without forcing the version bits t=
o be some value.</div><div><br></div><div>In other words, the question isn&=
#39;t about allowing/disallowing ASICBoost at this point. The question is w=
hether we want ASICBoost open or hidden.</div><div>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex">You make a strong assumption that=
the new optimization is not<br>
compatible with overt ASICBoost. If it is compatible, ASICBoost<br>
doesn't help you with "defending against" the new optimizatio=
n at all.<br>
And it can be the case that the new optimization is based on ASICBoost<br>
so you can make the situation "worse" by allowing it.<br></blockq=
uote><div><br></div><div>This would only be the case if overt ASICBoost wer=
e not possible at all. It is currently possible to use overt ASICBoost, so =
optimizations based on overt ASICBoost would also be possible unless someth=
ing were done to actively block it.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><span class=3D"gmail-">
> Certainly, if only one company made use of the extra nonce space, they=
would have an advantage.<br>
<br>
</span>Can you explain why the reality should be significantly different? I=
n<br>
sufficiently near future.</blockquote><div><br></div><div>Market incentives=
, I would imagine. How quickly that would be is not something I'm quali=
fied to answer.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">We don't have to deal with any such theoretical situat=
ion now. You<br>
proposal goes in opposite direction, by adding support for patented<br>
algorithm. I don't know myself what the possible legal implications<br>
are (maybe only for a subset of miners) so I consider it as an<br>
unnecessary risk. At least before some conclusive legal analysis says<br>
differently.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">I'm not adding =
support as much as explicitly allowing what's implicitly allowed. Whate=
ver risks you imagine for this proposal exist on the network currently, wit=
h unmodified BIP-141 and with modified BIP-141. The difference in adding th=
e modification is that overt ASICBoost is explicitly allowed in the modifie=
d BIP-141 as to not hide it.</div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">Jimmy</div></div>
--001a1148e60a7622b0054ca8a77f--
|
