Published on: 2013-05-09T15:43:31+00:00
In an email conversation between Mike Hearn and Jeff Garzik, the issue of signed timestamps is discussed. Hearn raises the question of whether the 2038 issue applies to signed timestamps in Bitcoin blocks. Garzik responds by stating that they treat the field as unsigned, so it is not a major concern.The discussion then moves to Pieter Wuille's proposal for a well-defined 64-bit timestamp for each block, with only the lowest 32 bits included in the header. Wuille suggests that the full 64-bit timestamp can be derived deterministically by adding the lowest 32-bit value that does not violate certain rules. This proposal is not backward-incompatible and ensures that there is never a gap of more than 136 years between two blocks.Another email exchange between Peter Todd and someone else focuses on interpreting timestamps on blockchain blocks for timestamping purposes. Todd suggests changing the meaning of the header timestamp to be relative time passed since the last block. The conversation also mentions the possibility of using a random beacon for secure timestamping and the idea of having a flag day where blocks after a certain height are considered to have a different epoch.The accuracy of block timestamps in Bitcoin is discussed, with nodes accepting blocks within a certain time range. It is noted that miners have an incentive to set the timestamp accurately to avoid driving up the difficulty. Two types of timestamps are mentioned: proofs that data existed before a time and proofs that data existed after. A solution is proposed to update the block header time calculation during a flag day when blocks after a certain height are considered to have a different epoch.A conversation between Pieter Wuille and Jeff Garzik debates the relevance of the year 2038 in relation to Bitcoin's block header format. Wuille believes it is unlikely that they would break the block header format and invalidate mining hardware. He suggests that even 16 bits of precision in the block header timestamp could suffice under certain conditions. The discussion ends with a link to download a free book on graph databases and an invitation to join the Bitcoin-development mailing list.Jeff Garzik and John Dillon discuss the possibility of Satoshi Nakamoto intentionally designing the Bitcoin protocol to require a hard fork in 2038. Garzik dismisses this idea, stating that it is too far in the future to be relevant. He also argues against expanding the precision beyond 32 bits in the timestamp field. Pieter adds that assuming the "full" 64-bit time is the smallest one that makes sense given its lower 32 bits would work fine.In an email exchange, John Dillon speculates about Satoshi Nakamoto setting up the Bitcoin network to require a hard fork in the future. Jeff Garzik responds by saying that 2038 is too far off to be relevant and explains that a hard fork may be necessary to break the 1MB limit. Garzik's email signature indicates that he was working for exMULTI, Inc. at the time.Peter Todd speculates about whether Satoshi Nakamoto deliberately used 32-bit timestamps in Bitcoin's code. Todd suggests that a hard fork could be an opportunity to change the timestamps. The email is signed using GnuPG v1.4.11 with a SHA256 hash.The reason behind having both 32-bit and 64-bit timestamp fields in Bitcoin is discussed in an email thread. It is explained that changing the fields would require all Bitcoin users to update their software simultaneously, which is a "hard-fork" change. It is suggested that fixing the timestamps can be left until a hard fork is needed for other reasons.The question of why there are both 32-bit and 64-bit timestamp fields in the Bitcoin protocol specification is raised in an email from Addy Yeow. Jeff Garzik cryptically replies, "Hysterical raisins," which is a play on words of "historical reasons." The use of smaller timestamp fields may save space in the data structure for efficiency. However, without more information, the exact reason is unclear.In a post to a mailing list, Addy asks why there are both 32-bit and 64-bit timestamp fields instead of making all of them 64-bit in the Bitcoin protocol specification. The specific reason behind this choice is not clear, but it is suggested that using smaller timestamp fields may save space in the data structure for efficiency purposes. Further clarification is needed to fully understand the reasoning behind this design decision.
Updated on: 2023-08-01T04:51:11.460775+00:00