<story><title>Tinychain: a pocket-sized implementation of Bitcoin</title><url>https://github.com/jamesob/tinychain</url></story><parent_chain><item><author>PaulBGD_</author><text>I&amp;#x27;m working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I&amp;#x27;m not getting that also wasn&amp;#x27;t answered by the source code is how you check timestamps.&lt;p&gt;I understand the whole network time = median offset + local time thing, however I&amp;#x27;m a bit fuzzy on how you check timestamps on previous blocks when you&amp;#x27;re initially downloading the chain. How do you know that you need to check the timestamp if you can&amp;#x27;t know if you&amp;#x27;re on the latest block?</text></item></parent_chain><comment><author>Taek</author><text>You need to check two things. First you need to check that this block had a timestamp higher than the median of the past 11 blocks (it&amp;#x27;s a consensus rule). Second you need to check that the timestamp is not unacceptably far in the future. For historic blocks, it definitely won&amp;#x27;t be because the timestamp will be far in the past (as the block was created far in the past).&lt;p&gt;Latest block or not, it just needs to follow those rules. That &lt;i&gt;does&lt;/i&gt; mean it&amp;#x27;s possible for a block with an invalid timestamp to become valid after some time has passed. But if it is invalid, nobody will be mining on it, so it&amp;#x27;s unlikely to remain part of the longest chain.</text></comment>
<story><title>Tinychain: a pocket-sized implementation of Bitcoin</title><url>https://github.com/jamesob/tinychain</url></story><parent_chain><item><author>PaulBGD_</author><text>I&amp;#x27;m working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I&amp;#x27;m not getting that also wasn&amp;#x27;t answered by the source code is how you check timestamps.&lt;p&gt;I understand the whole network time = median offset + local time thing, however I&amp;#x27;m a bit fuzzy on how you check timestamps on previous blocks when you&amp;#x27;re initially downloading the chain. How do you know that you need to check the timestamp if you can&amp;#x27;t know if you&amp;#x27;re on the latest block?</text></item></parent_chain><comment><author>uobytx</author><text>Wouldn&amp;#x27;t you only need to verify proof-of-work on the largest chain? Largest meaning the highest cumulative difficulty rather than number of blocks.&lt;p&gt;If you include a timestamp in each block, just have each node simply reject times that are out of order or too far from the current time, which will prevent people from mining on an invalid chain. &amp;quot;Current time&amp;quot; meaning nothing more than a few minutes in the future of now. Yes, even when dealing with an old chain.&lt;p&gt;Here is how it works:&lt;p&gt;If an invalid or malicious person spends hashrate to mine a block with a bad date, all the nodes in the network will see it and reject the block.&lt;p&gt;Because the block is rejected, everyone else keeps attempting to mine the same block, but with the correct timestamp. The window is: greater than the last block, less than a couple minutes from now.&lt;p&gt;Because most miners are on non-malicious nodes, they eventually produce a longer chain than the chain with the bad timestamp.&lt;p&gt;Because this good chain is longer, new nodes that sync the blockchain from scratch would simply pick the longest of the available chains (which is the good one).&lt;p&gt;This could still go wrong if the attacker has a large amount of hashrate (or luck) for an extended period of time, but this gets very expensive very fast. This is why it is sometimes good to wait a few blocks before assuming consensus.</text></comment>