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
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	boundary="Sig_/cnXmGn.oI5iqL.vztaVri8b";
	protocol="application/pgp-signature"
Subject: Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in
 blockheader - stratum mining.configure
Precedence: list

--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--