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 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/e045e415-9f0b-4f90-9c65-3aeeecca785bn%40googlegroups.com.