BIP113 breaks mining protocol #8024

Currently all mining knows that there is a 7200s limit on using roll-n-time This refers to moving the ntime forward when mining, to generate more unique work.

Of course this isn't an issue within master cgminer, since it limits ntime rolling to quite a small value, however there is no currently implemented command in the stratum protocol to specify limits on roll-n-time, since it has always been a constant 7200 seconds. Miners also are currently not required to know the current time for all pooled mining, including p2pool, since there is currently nothing in the mining protocol that would affecte a miner with the incorrect current time.

There is also no information provided in the getblocktemplate command specifying what the 'current' limit is. This would of course be MANDATORY at the least, to implement a break in protocol - that requires all miners to create and implement a new protocol defining ntime roll limits different to the current value.

I am of course referring to, at the least, more than 90% of all bitcoin mining.

https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

This BIP incorrectly seems to think that mining uses ntime to gather more fees. It doesn't. That may be a side effect in the future due to changes in the bitcoin protocol that don't take mining into consideration, but is NOT AT ALL the reason why ntime is currently adjusted. Mining uses ntime to generate more work due to the limitation inflicted upon mining of the nonce only being 32 bits.

This is a complete deal breaker for implementation of anything else that includes this BIP since any mining pool may lose blocks to miners that can generate large ntime values, and there is no way for a pool to currently verify the ntime rolling limit of all miners, or to specify a limit, that miners will guarantee to adhere to, based on the new random value that is dependent upon previous random block times.

The nTime of the current block is not relevant in BIP113. Only the median of the timestamps of the past 11 blocks.

Yes the median defines a limit on the current ntime ... Different to what it currently is.

The nTime of a new block is restricted to be:

• larger than the median nTime of the past 11 blocks
• less than 7200 seconds after the current time (network-corrected clock time, not block time).

None of this changes in BIP113.

Ah OK, thus I have indeed misunderstood the incorrect commentary written in the BIP113 about the use of ntime and am indeed wrong if it doesn't actually affect the 7200s limit. Thanks for clearing that up.