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
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
|
Return-Path: <jan.capek@braiins.cz>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 77B671080
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Mar 2018 15:43:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com
[209.85.128.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69D795FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Mar 2018 15:43:56 +0000 (UTC)
Received: by mail-wr0-f194.google.com with SMTP id p104so2615430wrc.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 07 Mar 2018 07:43:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=braiins-cz.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:organization:mime-version;
bh=FMjcZVwZuXMQc/tKga+a2kg9jDzumOUXn6XDHDDLeOw=;
b=qsCiFVbOBz56PAVPQJLak3q3osZH7eBMHp+OxnrNbQr1mrELtSphVZ/PivHXMjwCOr
lws5hXkaX9G4bv8QjQ3R9GMMsjk3JfUw9iZCM6u7t+WmzYJnPDWo2z6kk1vtqWQNWz/e
FfOHlvRzHCclWc2Bwy2pP3Ay/an+JZEYyY/h7fTTVipYfRMY+fOEWjALeUpOLw3fWdhQ
H54FG6P9HSAbwYMi5DjFDZv2utA9/8OeSAUqgODTh64y4j8DuhHo1U18YWyoDINgKqpJ
tayBrCCKifrGXU1epu0L5y7OCtH7BeMAMdNO7vTK2JDCUJEwbUv6gT1FO9qNSGLsf3vC
1Swg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:organization:mime-version;
bh=FMjcZVwZuXMQc/tKga+a2kg9jDzumOUXn6XDHDDLeOw=;
b=grW3iKl5dZjsy3npImO199rA5+4Dv59BgJNFQN40cijYCHEADwgQoX9uxDaQYMRcva
QYvuJb194PY/yC2sJMBgltAmf+2PyGUMF4N60ubi0DaUvz6u2z3rlyStMyFlN/Z+pDqW
BINWrvv824FnYu4/BfozynaLvMcXa6Q2PbkMrGV6+KT8qQhtPsIBVgo6y3oKZGuXYluq
ezGAeDOhCvCRlnIDKJMpXh40rJYml1AI5rP8+nqQQ5o/2TatXgUbzdEN781Ju8fbGWPO
CGN2XBLjzNUGMqYY5j7VbiIRP9Vjk0Jap+GUGCTinJ911RCTYUXW/e/AIb4I9r3yQrb3
T1CQ==
X-Gm-Message-State: APf1xPAn+ppQMdsNIcAG1xnqli5KlPeUddRHRAsG9YzY4D8aPABsfWdn
bwdJaRAJOx51UCh6HeH9Kg/p/7VY
X-Google-Smtp-Source: AG47ELtAGO1T6o1lCexXnsxtZw6MCxPkUolOv6gW2r1gYdcvcVfOzOsGQslbfbLvdByk/IHnQLmPOA==
X-Received: by 10.223.175.44 with SMTP id z41mr18541288wrc.129.1520437434415;
Wed, 07 Mar 2018 07:43:54 -0800 (PST)
Received: from glum ([88.208.115.67]) by smtp.gmail.com with ESMTPSA id
r1sm13223726wmg.22.2018.03.07.07.43.53
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 07 Mar 2018 07:43:54 -0800 (PST)
Date: Wed, 7 Mar 2018 16:43:49 +0100
From: Jan =?UTF-8?B?xIxhcGVr?= <jan.capek@braiins.cz>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20180307164349.1cfa51b3@glum>
In-Reply-To: <201803071443.13417.luke@dashjr.org>
References: <CADJgMzv85-So7F1+nyDP_xA2GH5erodA21PM-uAJw8P6_ix6hA@mail.gmail.com>
<201803071443.13417.luke@dashjr.org>
Organization: braiins
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
boundary="Sig_/cnXmGn.oI5iqL.vztaVri8b";
protocol="application/pgp-signature"
X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE, URIBL_DBL_SPAM,
URIBL_RHS_DOB autolearn=no version=3.3.1
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 08 Mar 2018 14:53:06 +0000
Subject: Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in
blockheader - stratum mining.configure
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: Wed, 07 Mar 2018 15:43:57 -0000
--Sig_/cnXmGn.oI5iqL.vztaVri8b
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Hello,
Our reasoning for coming up with a new method for miner configuration
was stated here: https://github.com/slushpool/stratumprotocol/issues/1
It is primarily the determinism of expecting the response. That is
the reason why we chose a new method mining.configure instead of an
existing mining.capabilities that was not being very well documented or
used.
On Wed, 7 Mar 2018 14:43:11 +0000 Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Why are you posting this obsolete draft? You've already received
> review in private, and been given useful suggestions. There's even a
> shared Google Doc with the current draft:
>=20
> https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9T=
V9LRqvStak/edit?usp=3Dsharing
>=20
> Again:
>=20
> * This is no different from what Timo and Sergio proposed years ago,
> and as such should be based on their work instead of outright
> not-invented-here respecification. The current draft integrates their
> work while not trying to steal credit for it (they are included as
> primary authors).
>=20
> * The specification should be complete, including updates for GBT and
> the Stratum mining protocol. These are included in the current draft.
>=20
> Additionally, it is not appropriate to begin using a draft BIP on
> mainnet before any discussion or consensus has been reached. Doing so
> seems quite malicious, in fact. I hope DragonMint miners can still
> operate using the *current* Bitcoin protocol.
>=20
> Luke
>=20
>=20
> On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote:
> > Hi,
> >=20
> > The following proposal reduces the number of version-bits that can
> > be used for parallel soft-fork signalling, reserving 16 bits for
> > non-specific use. This would reduce the number of parallel
> > soft-fork activations using versionbits to from 29 to 13 and
> > prevent node software from emitting false warnings about unknown
> > signalling bits under the versionbits signalling system (BIP8/9). I
> > chose the upper bits of the nVersion, because looking at the
> > versionbits implementation in the most widely deployed node
> > software, it is easier to implement than say annexing the lower 2
> > bytes of the field.
> >=20
> > The scope of the BIP is deliberately limited to reserving bits for
> > general use without specifying specific uses for each bit, although
> > there have previously been various discussions of some use-cases of
> > nVersion bits including version-rolling AsicBoost[1], and nonce
> > rolling to reduce CPU load on mining controllers because
> > ntime-rolling can only be done for short periods otherwise it could
> > have negative side effects distorting time. However, specific use
> > cases are not important for this BIP.
> >=20
> > I am reviving discussion on this topic now, specifically, because
> > the new DragonMint miner uses version-rolling AsicBoost on
> > mainnet[2]. It is important to bring up so node software can adapt
> > the versionbits warning system to prevent false positives. This BIP
> > has the added advantage that when a new use for bits is found,
> > mining manufacturers can play in the designated area without
> > causing disruption or inconvenience (as unfortuntely, the use of
> > version-rolling will cause until BIP8/9 warning systems are
> > adapted). I appologise for the inconvenience in advance, but this
> > is the unfortunate result of restraints while negotiating to get
> > the patent opened[3] and licensed defensively[4] in the first place.
> >=20
> > I believe there was a similar proposal[5] made some years ago,
> > before the advent of BIP9. This proposal differs in that it's
> > primary purpose is to remove bits from the versionbits soft-fork
> > activation system and earmark 16 bits for general use without
> > allocating fixed uses for each bit. The BIP cites a couple of
> > usecases for good measure, but they are just informational
> > examples, not part of a specification laid down. For this reason,
> > there no is mention of the version-rolling Stratum extension[6]
> > specifics within the BIP text other than a reference to the
> > specification itself.
> >=20
> > Refs:
> >=20
> > [1] https://arxiv.org/pdf/1604.00575.pdf
> > [2]
> > https://halongmining.com/blog/2018/03/07/dragonmint-btc-miner-uses-vers=
ion->
> > rolling-asicboost/ [3]
> > https://www.asicboost.com/single-post/2018/03/01/opening-asicboost-for-=
defe
> > nsive-use/ [4] https://blockchaindpl.org/ [5]
> > https://github.com/BlockheaderNonce2/bitcoin/wiki [6]
> > http://stratumprotocol.org/stratum-extensions
> >=20
> > <pre>
> > BIP: ?
> > Title: Reserved nversion bits in blockheader
> > Author: BtcDrak <btcdrak@gmail.com>
> > Comments-Summary: No comments yet.
> > Comments-URI:
> > https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft
> > Type: Informational
> > Created: 2018-03-01
> > License: BSD-3-Clause
> > CC0-1.0
> > </pre>
> >=20
> > =3D=3DAbstract=3D=3D
> >=20
> > This BIP reserves 16 bits of the block header nVersion field for
> > general purpose use and removes their meaning for the purpose of
> > version bits soft-fork signalling.
> >=20
> > =3D=3DMotivation=3D=3D
> >=20
> > There are a variety of things that miners may desire to use some of
> > the nVersion field bits for. However, due to their use to coordinate
> > miner activated soft-forks, full node software will generate false
> > warnings about unknown soft forks if those bits are used for non
> > soft fork signalling purposes. By reserving bits from the nVersion
> > field for general use, node software can be updated to ignore those
> > bits and therefore will not emit false warnings. Reserving 16 bits
> > for general use leaves enough for 13 parallel soft-forks using
> > version bits.
> >=20
> > =3D=3DExample Uses=3D=3D
> >=20
> > The following are example cases that would benefit from using some
> > of the bits from the nVersion field. This list is not exhaustive.
> >=20
> > Bitcoin mining hardware currently can exhaust the 32 bit nonce field
> > in less than 200ms requiring the controller to distribute new jobs
> > very frequently to each mining chip consuming a lot of bandwidth and
> > CPU time. This can be greatly reduced by rolling more bits. Rolling
> > too many bits from nTime is not ideal because it may distort the
> > timestamps over a longer period.
> >=20
> > Version-rolling AsicBoost requires two bits from the nVersion field
> > to calculate 4-way collisions. Any two bits can be used and mining
> > equipment can negotiate which bits are to be used with mining pools
> > via the Stratum "version-rolling" extension.
> >=20
> > =3D=3DSpecification=3D=3D
> >=20
> > Sixteen bits from the block header nVersion field, starting from 13
> > and ending at 28 inclusive (0x1fffe000), are reserved for general
> > use and removed from BIP8 and BIP9 specifications. A mask of
> > 0xe0001fff should be applied to nVersion bits so bits 13-28
> > inclusive will be ignored for soft-fork signalling and unknown
> > soft-fork warnings.
> >=20
> > This specification does not reserve specific bits for specific
> > purposes.
> >=20
> > =3D=3DBackwards Compatibility=3D=3D
> >=20
> > This proposal is backwards compatible, and does not require a soft
> > fork to implement.
> >=20
> > =3D=3DReferences=3D=3D
> >=20
> > [[bip-0008.mediawiki|BIP8]]
> > [[bip-0009.mediawiki|BIP9]]
> > [https://arxiv.org/pdf/1604.00575.pdf AsicBoost white paper]
> > [https://github.com/BlockheaderNonce2/bitcoin/wiki nNonce2 proposal]
> > [http://stratumprotocol.org/ Stratum protocol extension for
> > version-rolling]
> >=20
> > =3D=3DCopyright=3D=3D
> >=20
> > This document is dual licensed as BSD 3-clause, and Creative Commons
> > CC0 1.0 Universal. =20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=20
CEO Braiins Systems | Slushpool.com
tel: +420 604 566 382
email: jan.capek@braiins.cz
http://braiins.cz
http://slushpool.com
--Sig_/cnXmGn.oI5iqL.vztaVri8b
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJaoAi1AAoJEHsopSWtdWV87TcP/A7OJ3IBa/pYwunzacKMyy7C
YltyNZ3+Z//mjPjAybxLvpMqbtLZRdH43T1FLPoskTrykuXtKF7oTF5xxwvD1N9j
a7FUlRhUSNN1f/rv7cChnHpNKhNmRQPzajjKNeOiSVHHNgwo16wiYzUmqi84B+Yr
MnLFwve3jMjgeUwoslaN7DPrkTXuVr0DEp+HIG/519hkyCQuANJ/2ksivInnH+pr
q4psVMvaOyNm801lb7QoPGX3k9BLqjIQ4XLxR0p4tG2qyGYlLmaUsHtGTVBXZkT3
t9N7uMEIpQw7TkJ8ZUsfuX68fV9HXOZ8eTQZHLQ+RbkieNESy/AUAYNw6YV304py
5rRYIiKf0TXHi5JuukWg1U51QJzpF/z+7HBZdls/4ICRgEqI3aIpNalcNXF9jszf
ipRXdKZMXfeCUZaCMYICHOiyz0dF0JvPzp3LluNOV1XelLRo9mkC3VYGh3hKRmOe
o1pMGRWKeNIjTVbyxO3GJ5mbe5kplLnsp1F7bRCrqIdM5Ewcue+uUthFaruM/eM3
n+3sR50cJwdKTMXjk89fcCDA7oSQhVmq1D1s3dAhWPZHl1zjJP+gkuBb82Jm4KSJ
S/Slp3MucC4wdQtBe73yloUY03AOdBsxK2GK/1ss8QubI0B4MyGM4tDgc/LGpzdH
9FDNpNqc2w2lrVLaeASm
=RB5D
-----END PGP SIGNATURE-----
--Sig_/cnXmGn.oI5iqL.vztaVri8b--
|