Timewarp fix grace period

[Antoine Poinsot]

Dear miners,

I am seeking feedback from mining pool and ASIC engineers on the value of the grace period for the timewarp vulnerability fix included in the Consensus Cleanup proposal. The fix involves tying the timestamp of the first block in a difficulty period to the timestamp of the last block in the previous period. Specifically, it would render invalid a block which:

• is the first in a difficulty period;
• has a timestamp lower than the previous block's minus a grace period.

The grace period was introduced due to the presence of deployed mining hardware which rolls nTime forward by up to 600 seconds. Absent a grace period a miner finding the previous block could set its timestamp as far in the future as possible, possibly leading the next miner (if using nTime-rolling) to produce an invalid block. See discussion in the original Consensus Cleanup BIP. It's been six years since this was proposed, therefore i would like to confirm this value is still safe to use nowadays.

Is there equipment in use today which rolls nTime past 600 seconds? Or rolls nTime more than once per second? Did you have any issue upgrading to testnet4 (which contains this fix)? Does anyone otherwise have substantial evidence the grace period needs to be increased? I would like to strike a good balance between not weakening the vulnerability fix more than necessary and minimizing the risk to miners of seeing their block rejected.

Antoine Poinsot

[Sjors Provoost]

Something else I’m worried about is that some open source pool software [0,1] ignores the 'curtime' and 'mintime' fields provided by 'getblocktemplate'. They instead take time from their clock.

These two instances in open source software have been fixed, but we don't know if this type of bug is common in closed source software.

It's important to check that your pool software does not ignore these values. This also applies to mainnet today, but it's less likely to lead to problems than after the timewarp fix.

An easy way to find out if your pool software has this issue, is to mine on testnet4 and try to find the first block of a retarget period.

Due to some people who are taking maximum advantage of the rule that testnet difficulty drops to 1 after 20 minutes, the timestamps on testnet4 are almost always two hours in the future. As a result, when then first block of a retarget period uses clock time, it will violate the timewarp rule and be rejected. If it uses the 'curtime' field provided by `getblocktemplate` instead, the timestamp will be adjusted to account for this  and the block will be fine.

Unfortunately, if your software relies on 'mintime' instead, Bitcoin Core itself has a bug which gives the wrong 'mintime' (only affects testnet4). So in order to perform the above test it's best to run this patch: https://github.com/bitcoin/bitcoin/pull/31600 (or the master branch after its merged).

- Sjors

[0] https://github.com/stratum-mining/stratum/pull/1325 ('min_ntime' refers to 'curtime')

[1] https://github.com/benjamin-wilson/public-pool/commit/4282233d2f11ceecbd0d142e8292ccc9c37ea999 (uses 'mintime' )

--
You received this message because you are subscribed to the Google Groups "Bitcoin Mining Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinminingd...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoinminingdev/IvTrnJ2B95ZIVCFYjIgjFWiGu3SFsVRdrX1XrTm8kkl6-8Dfvo_Ay4qRO4dhnZVRRAiVC_Co3_Ink_D4-dKUZNlNLjgwBHpfLN9G_wp9m5s%3D%40protonmail.com.