Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure
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 nVersion field for > > general purpose use and removes their mean
Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure
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] https://blockchaindpl.org/ [5] > > > http