Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure

[Jan Čapek via bitcoin-dev]

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 + Luke Dashjr via bitcoin-dev
 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:
> 
> 
> https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9TV9LRqvStak/edit?usp=sharing
> 
> Again:
> 
> * 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).
> 
> * The specification should be complete, including updates for GBT and
> the Stratum mining protocol. These are included in the current draft.
> 
> 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.
> 
> Luke
> 
> 
> On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote:
> > Hi,
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > Refs:
> > 
> > [1] https://arxiv.org/pdf/1604.00575.pdf
> > [2]
> > https://halongmining.com/blog/2018/03/07/dragonmint-btc-miner-uses-version->
> > 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
> > 
> > 
> >   BIP: ?
> >   Title: Reserved nversion bits in blockheader
> >   Author: BtcDrak 
> >   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
> > 
> > 
> > ==Abstract==
> > 
> > This BIP reserves 16 bits of the block header 

Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure

[Luke Dashjr via bitcoin-dev]

On Wednesday 07 March 2018 3:43:49 PM Jan Čapek 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 since 
2014.

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

> 
> 
> On Wed, 7 Mar 2018 14:43:11 + Luke Dashjr via bitcoin-dev
> 
>  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:
> > https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9T
> > V9LRqvStak/edit?usp=sharing
> > 
> > Again:
> > 
> > * 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).
> > 
> > * The specification should be complete, including updates for GBT and
> > the Stratum mining protocol. These are included in the current draft.
> > 
> > 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.
> > 
> > Luke
> > 
> > On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote:
> > > Hi,
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > Refs:
> > > 
> > > [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]