Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the correct timestamp being used? #147

Open
zawy12 opened this issue Dec 1, 2024 · 0 comments
Open

Is the correct timestamp being used? #147

zawy12 opened this issue Dec 1, 2024 · 0 comments

Comments

@zawy12
Copy link

zawy12 commented Dec 1, 2024

Please make sure all code and contracts that depend on timestamps use the highest timestamp out of the set of the current block and the past 11 blocks, or the highest timestamp seen. The MTP and the current timestamp are not secure timestamps because they don't have decentralized PoW support. Below explains why. Any objection should indicate which numbered statement is wrong.

In short, at Bitcoin's core is a timestamp server, motivating miners to push time forward to keep difficulty as low as possible. Users limit forward time by rejecting chains that push too far. MTP in BTC can be kept back without increasing difficulty, breaking the incentive mechanism as it applies to MTP.

  1. A majority of miner hashrate can publicly hold back the MTP (median of past 11 timestamps) to an arbitrarily-long amount of time without harming any part of bitcoin or violating any rule.
  2. It may be profitable for them to do so as a result of external dependencies on the the MTP. For example, Opentimestamps aggregates a lot of timestamps which may control a lot of value that may be exploitable by, or of interest to, miners, but the fee paid to miners to have an honest MTP is small in comparison.
  3. This may not affect the value of bitcoin on exchanges which makes it much more likely to occur than other 51% attacks.
  4. As a result of 2 and 3, an accurate MTP doesn't have support from the PoW who's security model is based exclusively on the long-term profit of the majority hashrate.**
  5. Being able to hold the MTP back in time without PoW support removes the purpose of having a timestamp, so it should not be used as a timestamp.
  6. Therefore no code, entity, or contract anywhere that assumes the MTP has PoW support should use the MTP as a timestamp.
  7. Neither should the timestamp of a particular block be used as a timestamp because it can be held back as far as the MTP.
  8. The timestamp that has PoW and decentralization support, is the highest timestamp out of the set of the current timestamp and the past 11 timestamps.
  9. It will be at most 2 hours in the future which is compatible with timestamping whereas a timestamp in the past isn't.

Also note that miners could make the MTP and therefore individual timestamps jump months ahead in a single block if they've held the MTP back that long. That is, a differences in two MTP's is also not valid.

The cause of the problem is that bitcoin and most other coins aren't following one of the most basic requirements of all consensus mechanisms: monotonic timestamps on every valid consensus-supporting message (each block). The highest timestamp seen would have better PoW support if the DAA changed every block which would make it costly for the miners to delay timestamps during the 2 week adjustment period.

** Bitcoin security isn't based on >51% hashrate refusing to collude for short term profit. It's based on >51% "colluding" to not attack because it would hurt their long-term profits. Bitcoin is secure even if there is only 1 miner, as long as he's spread out so that there's not a single legal point of attack. If >51% finds it profitable over the long-term to take some action such as exploiting Opentimestamps, they will take it. It doesn't matter if they are many miners spread over many jurisdictions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant