{"type":"rich","version":"1.0","author_name":"npub1t9txg5aevth45pu9hcz075tj3ch25fydn8c38wew90qjjdjv3rqq3r6cf0","author_url":"https://nostr.ae/npub1t9txg5aevth45pu9hcz075tj3ch25fydn8c38wew90qjjdjv3rqq3r6cf0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-09-13\n🗒️ Summary of this message: Bitcoin's timejacking and related exploits can be fixed by overlapping block timestamps and using NTP, but new block timestamp rules are needed.\n📝 Original message:Gavin Andresen wrote:\n\u003e Background:\n\u003e\n\u003e Timejacking:\n\u003e    http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html\n\u003e\n\u003e And a recent related exploit launched against the low-difficulty\n\u003e alternative chains:\n\u003e    https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772\n\u003e\n\u003e\n\u003e Seems to me there are two fundamental problems:\n\u003e\n\u003e 1) Bitcoin should be overlapping the ranges of block timestamps that\n\u003e it uses to calculate difficulty adjustments.\n\u003e\n\u003e 2) Bitcoin's \"what time is it\" code is kind of a hack.\n\u003e\n\u003e\n\u003e Fixing (1) would mean a potential block-chain split; before\n\u003e considering doing that I'd like to consider second-best solutions.\n\u003e\n\u003e Fixing (2) is easier; incorporating a ntp library and/or simply\n\u003e removing the bitcoin mining code from the client but requiring pools\n\u003e and miners to have accurate-to-within-a-minute system clocks (or their\n\u003e blocks will be \"discouraged\") seems reasonable to me. If you want to\n\u003e produce blocks that the rest of the network will accept, run ntp on\n\u003e your system.\n\u003e\n\u003e I THINK that fixing (2) will make (1) a non-issue-- if miners can't\n\u003e mess around with block times very much then it will be very difficult\n\u003e for them to manipulate the difficulty for their benefit.\n\u003e\nThe first thing I always do when I grab the source for my colo server is \npatch util.cpp so that GetAdjustedTime() returns GetTime() with no \nadjustment.  But I'm the kind of guy that buys special GPS receivers \nbecause stratum 2 isn't low enough and occasionally checks ebay for \ncaesium fountains.\n\nNTP has been around for long enough now that there is no reason for the \nclient to screw with the clock.  If the client sees different times on \nthe network, it should issue a warning, and if it is off too far, it \nshould give an error and fail to run (and/or peers should reject it).\n\nBut that doesn't solve the whole problem, because the block timestamp \nchecking is based on the assumption that the node is looking at the \nbitcoin clock rather than the, ahem, real clock.  If we change the idea \nof network time to NTP, we will then need to write (and test!) new block \ntimestamp rules to account for the new assumptions.\n\nI'm not sure that just fixing item 2 is going to stop the attacks found \nby ArtForz, et al.  Some of the attacks Art pointed out are particularly \nbad because they change the incentive structure of the system, at least \nin the short term.  We need to flip that back around ASAP.\n\nAlso, this is going to cause problems for at least one pool operator."}