# culubas - Timejacking and Bitcoin (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/19640502) **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[culubas]] **Full Title**:: Timejacking and Bitcoin **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [culubas.blogspot.com](http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html) **Host**:: [[culubas.blogspot.com]] **Highlighted**:: [[2022-10-12]] **Created**:: [[2022-10-12]] ## Highlights - By announcing inaccurate timestamps when connecting to a node, an attacker can alter a node's network time counter and deceive it into accepting an alternate block chain. This could significantly increase the chances of a successful double-spend, drain a node's computational resources, or simply slow down the transaction confirmation rate. ^396323145 ### Timestamp Hacking - Each node internally maintains a counter that represents the network time. This is based on the median time of a node's peers which is sent in the version message when peers connect. The network time counter reverts to the system time however if the median time differs by more than 70 minutes from the system time. ^396323147 - An advanced attack would involve speeding up the clocks of a majority of the network's mining resources while slowing down the target's clock. Since the time value can be skewed by at most 70 minutes, the difference between the nodes would be 140 minutes. ^396323148 ### Creating a "Poison Pill" Block - The network time is used to validate new blocks. As a precaution, nodes reject any block timestamp that is greater than 2 hours from the current network time. Block timestamps that are earlier than the median time of the past 11 blocks are also rejected. ^396323150 - The attacker would then create a new block with a timestamp set 190 minutes ahead of the real time. ... The target node would reject this new block (because the timestamp is 260 minutes past its own slowed-down network time) and continue using the previous chain. However the miners would accept the block (because it's no more than 120 minutes past their own sped-up network time). ^396401923 ### Double-Spending - The target wouldn't receive legitimate transaction confirmations during the attack window. This would be a period of time during which an attacker could feed confirmations to the target without honest nodes intervening. ^396323154 ### Solutions - Use the node's system time instead of the network time to determine the upper limit of block timestamps and when creating blocks. ^396323156 - Tighten the acceptable time ranges. The node's network time could be restricted to a value within 30 minutes. ^396323157 - Use only trusted peers. Requiring secure nodes to use only trusted peers could make those nodes less secure since a small number of trusted peers may be subverted. ^396323158 - Use the median block chain time exclusively when validating blocks. This would ensure no timestamp splits are possible and would be a complete solution. This is already done on the timestamp's lower bound and could be applied similarly to the upper bound. ^396323159