path: root/e5/b4528e7bca89205c194ee13b2915b2806bf2cf

Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F0B2EF46
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Mar 2018 15:48:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 164515FF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Mar 2018 15:48:18 +0000 (UTC)
Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265::71])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 65C8738A0C5C;
	Wed,  7 Mar 2018 15:48:02 +0000 (UTC)
X-Hashcash: 1:25:180307:jan.capek@braiins.cz::WxPmlI2=pTV33/LG:asV=m
X-Hashcash: 1:25:180307:bitcoin-dev@lists.linuxfoundation.org::fSRxEdCVfh7DYcss:8s7s
From: Luke Dashjr <luke@dashjr.org>
To: Jan =?utf-8?q?=C4=8Capek?= <jan.capek@braiins.cz>
Date: Wed, 7 Mar 2018 15:48:00 +0000
User-Agent: KMail/1.13.7 (Linux/4.15.1-gentoo; KDE/4.14.37; x86_64; ; )
References: <CADJgMzv85-So7F1+nyDP_xA2GH5erodA21PM-uAJw8P6_ix6hA@mail.gmail.com>
	<201803071443.13417.luke@dashjr.org> <20180307164349.1cfa51b3@glum>
In-Reply-To: <20180307164349.1cfa51b3@glum>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201803071548.01405.luke@dashjr.org>
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD, URIBL_DBL_SPAM,
	URIBL_RHS_DOB 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@lists.linuxfoundation.org
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:48:20 -0000

On Wednesday 07 March 2018 3:43:49 PM Jan =C4=8Capek wrote:
> Our reasoning for coming up with a new method for miner configuration
> was stated here: https://github.com/slushpool/stratumprotocol/issues/1

This reasoning is not sound.

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

It was as well documented as the original stratum protocol, and in use sinc=
e=20
2014.

While the response type is admittedly undefined, simply defining that would=
=20
have been a better solution than to reinvent it incompatibly for no reason.=
=20
(Although version rolling does not actually require a response at all.)

>=20
>=20
> On Wed, 7 Mar 2018 14:43:11 +0000 Luke Dashjr via bitcoin-dev
>=20
> <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
> >=20
> > shared Google Doc with the current draft:
> >     https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg=
9T
> >     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
> > 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-ve=
rs
> > > ion-> rolling-asicboost/ [3]
> > > https://www.asicboost.com/single-post/2018/03/01/opening-asicboost-fo=
r-> > > defe nsive-use/ [4] https://blockchaindpl.org/ [5]
> > > https://github.com/BlockheaderNonce2/bitcoin/wiki [6]
> > > http://stratumprotocol.org/stratum-extensions
> > >=20
> > > <pre>
> > >=20
> > >   BIP: ?
> > >   Title: Reserved nversion bits in blockheader
> > >   Author: BtcDrak <btcdrak@gmail.com>
> > >   Comments-Summary: No comments yet.
> > >=20
> > >   Comments-URI:
> > > https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft
> > >=20
> > >   Type: Informational
> > >   Created: 2018-03-01
> > >   License: BSD-3-Clause
> > >  =20
> > >            CC0-1.0
> > >=20
> > > </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