Timewarp fix, Mining software and Clocks

Timewarp fix, Mining software and Clocks
From: Antoine Riard @ 2024-08-25 14:36 UTC ( / )
  To: Bitcoin Development Mailing List




Hi list,

About fixing the timewarp attack, I think one aspect wasn't mentioned in 
Pointsot's post
about consensus cleanup from few months ago is potentially the necessity to 
have an upgrade of pool softwares. New consensus rule is the following "The 
nTime field of each block whose height, mod 2016, is 0 must be greater than 
or equal to the nTime field of the immediately prior block minus 600".

As it's noted in the cleanup bip, if the last block of the period timestamp 
is in the
future, non upgraded miners mining the first block of the period could see 
it orphaned
if the nTime field isn't adjusted accordingly. While this could arise 
spontaneously from
unreliable local clocks, a malicious miner could deliberately exploit this 
new behavior by
offsetting last block nTime field to one hour in the future (consensus rule 
reminder: no
block more than 2 hours in the future), then next honest non-upgraded miner 
could naively mine the first block of the next period which would be deemed 
invalid by new consensus rules. Malicious miner, aware of the nTime 
offsetting, gets an advantage to mine the first block of this period, which 
would be accepted by all remaining network full-nodes. Assuming all network 
wall clocks are well in sync, there is little risk for a malicious miner to 
engage in such last block period nTime offsetting (scenario re-tested here 
[0]).

New bitcoin core getblocktemplate code on testnet4 is adjusting the nTime 
field for
each first period block compared to the last block nTime field minus 600s. 
However,
this upgrade behavior is far from being ported in any other block template 
providers
(e.g getblocktemplate other implementations, stratum v2) in the mining 
ecosystem and
I don't know if it should be further documented or implemented (e.g 
addendum to bip23 ?). E.g Stratum V2's `SubmitSolution` has rules on the 
header_timestamp validity, and as far as I can tell they appear to be 
compatible with the new timewarp fix rule [1]. Though it sounds each block 
template software should be checked on its own here. With the same upgrade 
occasion, it could be recommended that miners wall clock are synced with 
NTP stratum 0 or stratum 1 devices, which would minimize attack surface 
from timejacking issues already existent  due to the 2 hours rule [2].

All that said, I think there are few minor downsides of instituting a new 
Time inter-dependency between subsequent blocks. One is for mining 
softwares you would have to ensure strict ordering of the template nTime 
field for those 2 boundaries blocks in face of reorg or concurrent template 
works on. A second one is a miner can move the MTP value as updated by the 
next block, said block that miner might not mine itself, and as such the 
consensus validity of time-based time-locked transactions.

Personally, I don't think those downsides raise a bottleneck to further 
inquiry on this
cleaning up of the difficulty adjustement algorithm. Yet I think it would 
be interesting
to ask if there are other consensus and mining software dependencies or 
wall clocks hardening that we should consider in the context of a timewarp 
fix.

Cheers,
Antoine (the other one)
ots hash: 612acbb8167f1a3e278524ce22846b35e466d4b9c51321e7b661d15973a13b3b

[0] https://github.com/ariard/bitcoin/tree/play-with-timewarp-fix-2
[1] 
https://github.com/stratum-mining/sv2-spec/blob/main/07-Template-Distribution-Protocol.md
[2] https://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html

--