From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Timewarp fix, Mining software and Clocks
Date: Sun, 25 Aug 2024 07:36:42 -0700 (PDT) [thread overview]
Message-ID: <e045e415-9f0b-4f90-9c65-3aeeecca785bn@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3882 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 4264 bytes --]
reply other threads:[~2024-08-25 14:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e045e415-9f0b-4f90-9c65-3aeeecca785bn@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox