From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 25 Aug 2024 07:58:28 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1siEhI-0000i7-4W for bitcoindev@gnusha.org; Sun, 25 Aug 2024 07:58:28 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e17bb508bb9sf3091990276.2 for ; Sun, 25 Aug 2024 07:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1724597901; x=1725202701; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=CQE4NDK7XZhTp41hPyvZpGlCRZNr/sxdFSY7MRLiDNM=; b=av7C9Bluf43xOnv/I9TJJ4aQaWCkjP+9OaTE+O8uoVLTMZIf8afIvXULlgRf5J5h8Q lA/AjF5oERz+AfHawWg48PZUGBf8ctDmVbftlqB1ngDSG4D8fVFW6NryDAEWkSAwJ4Ws Qj0nRtnSH34nwWQlWOxVTpH1qHMU5rRlawfDQyIKI/bzeIfoZ3cpF6YDq1OVkd4hTAT1 Czoib3EPuGkjesDyaBE/Q7ZRZFlLG/tsxrbuvV8JT7XjAdQk+Dq1edn4BYruypyjmBn5 AVOLa8i+qzsO+GggskyvBwyrrqJGRqWpybJT49im/4zhYpMBc6esga67aEByNDtPIGl/ K03A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724597901; x=1725202701; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=CQE4NDK7XZhTp41hPyvZpGlCRZNr/sxdFSY7MRLiDNM=; b=Rh9d1HwkzxXnNgUbP9eXisM9mKKuMTbckO1fV/2neYZoqeuGRzPUx6+A1ATteiAxto 9wjrzMvCd+4MXgEb4fJ6w3JzUlNJRigX0uBHJl+23kfWtD5thMQQX1mPLf1WyRqYe6c1 +OrAYecdjSh91tuUJQ1LpQsATwbTn0S3FRvftCAvgHkdHvusQkmd2SA4or6Yqljtj939 Ine8wWHM1bjiz3Xf7jS0nNvKGFUQZgIaqQKCxQk6yiyuQOVWyWqFZ5hMf5BElhwHNciy KJ+gb1wwmII1dSJx3i8LcR0X34fgSRzT7b02223sILJtvW3uzv4EhVKlTPY2glMvLuxH kSZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724597901; x=1725202701; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=CQE4NDK7XZhTp41hPyvZpGlCRZNr/sxdFSY7MRLiDNM=; b=Zb90WwEfCzZYoVpfdB53WCct3pEkexY/8xor1D/AF3/W2sy8XM4Z0nzP3mZDLqLeQi 7JtUj9Jp1EH08uXtf1sAxZblhv4kaDO8NZum0JIAq/ntteXaDw3iaBB3sCzMBIUD6uIl 4Otu43HyiHtWfxCw+oWe7SaUOoEpsEYJ4SRKep5GHbm1A4yqJPBkh+wLhM1oIra2IhWO lKc3MxMEtbAD2IJBl7diffM4Z94u+X/SJEhorBfARW6szGUo+6CPCzWyAydRsOIHM0lN 5riikvrMP2bVwwI0Xx5+8Uoq4YQvvWvb60aThan+Qs8Hf0RmiL9PLKjXyJuEpRjJwot6 ctpw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXwDCPivg5MCAXveaBu4nEIdkKuxiHs9UnEDInoNXlLBibwFuDGK5oP+63mN5MhpWzy1lYkuHY2U+aV@gnusha.org X-Gm-Message-State: AOJu0YzLH2hjL3XesW9Rl5CNKxYtiXSsCMf3MVjD6Yq+RADoBlcqw4Op gp7w5H0ucrGG1D2BIajz4iVXnkcLKa/51HM96CyZYOT7mY4LuDTB X-Google-Smtp-Source: AGHT+IF7iQcBQ4Ys38YoXl0shf5kuUrUo45m7KUGFSp70vNBE3Eh3sFKU2jsAO5Y1O0TE163KSz29w== X-Received: by 2002:a05:6902:2845:b0:e0b:fdc2:4df2 with SMTP id 3f1490d57ef6-e17a8e429f3mr9732175276.43.1724597901192; Sun, 25 Aug 2024 07:58:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1209:b0:e16:3642:2a73 with SMTP id 3f1490d57ef6-e178bd4edf0ls2034885276.2.-pod-prod-04-us; Sun, 25 Aug 2024 07:58:19 -0700 (PDT) X-Received: by 2002:a05:690c:660b:b0:62f:f535:f41 with SMTP id 00721157ae682-6c629345863mr5747647b3.9.1724597899185; Sun, 25 Aug 2024 07:58:19 -0700 (PDT) Received: by 2002:a05:690c:2a93:b0:64a:6fb4:b878 with SMTP id 00721157ae682-6c5b829a2f9ms7b3; Sun, 25 Aug 2024 07:36:43 -0700 (PDT) X-Received: by 2002:a05:690c:288d:b0:651:6e6f:32d2 with SMTP id 00721157ae682-6c629159b96mr70593397b3.43.1724596602657; Sun, 25 Aug 2024 07:36:42 -0700 (PDT) Date: Sun, 25 Aug 2024 07:36:42 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] Timewarp fix, Mining software and Clocks MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_323898_313843232.1724596602482" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_323898_313843232.1724596602482 Content-Type: multipart/alternative; boundary="----=_Part_323899_106706459.1724596602482" ------=_Part_323899_106706459.1724596602482 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_323899_106706459.1724596602482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list,

About fixing the timewarp attack, I think one aspect wa= sn't mentioned in Pointsot's post
about consensus cleanup from few mon= ths 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 he= ight, mod 2016, is 0 must be greater than or equal to the nTime field of th= e immediately prior block minus 600".

As it's noted in the clean= up bip, if the last block of the period timestamp is in the
future, no= n upgraded miners mining the first block of the period could see it orphane= d
if the nTime field isn't adjusted accordingly. While this could aris= e 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 mor= e than 2 hours in the future), then next honest non-upgraded miner could na= ively mine the first block of the next period which would be deemed invalid= by new consensus rules. Malicious miner, aware of the nTime offsetting, ge= ts an advantage to mine the first block of this period, which would be acce= pted 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 s= uch last block period nTime offsetting (scenario re-tested here [0]).
=
New bitcoin core getblocktemplate code on testnet4 is adjusting the n= Time field for
each first period block compared to the last block nTim= e field minus 600s. However,
this upgrade behavior is far from being p= orted in any other block template providers
(e.g getblocktemplate othe= r implementations, stratum v2) in the mining ecosystem and
I don't kno= w 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 val= idity, and as far as I can tell they appear to be compatible with the new t= imewarp 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 rec= ommended that miners wall clock are synced with NTP stratum 0 or stratum 1 = devices, which would minimize attack surface from timejacking issues alread= y existent =C2=A0due to the 2 hours rule [2].

All that said, I t= hink there are few minor downsides of instituting a new Time inter-dependen= cy 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-bas= ed time-locked transactions.

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

Cheers,
Antoine (the other one)
ots hash: 612acbb8= 167f1a3e278524ce22846b35e466d4b9c51321e7b661d15973a13b3b

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

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/e045e415-9f0b-4f90-9c65-3aeeecca785bn%40googlegroups.com.=
------=_Part_323899_106706459.1724596602482-- ------=_Part_323898_313843232.1724596602482--