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

MTP time and timestamps aren't secure. They don't have PoW support. #996

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

MTP time and timestamps aren't secure. They don't have PoW support. #996

zawy12 opened this issue Dec 1, 2024 · 0 comments

Comments

@zawy12
Copy link

zawy12 commented Dec 1, 2024

My title sounds like an exaggeration, but I can't change it without lying.

It's an exaggeration in this sense: if timestamps are observed to monotonically increase, the MTP and the timestamps are valid and have PoW support. The degree to which they don't have PoW support is limited by how far out of sequence they get. If it's a problem, it can be seen and fix number 2 below can be used. The problem is if code, script, apps, or legal contracts depend on them as accurate. Also, a 51% attack that ignores all other blocks can do this and get around any fix. The fixes below help in the sense they can't do it while making everything else appear to be working properly, i.e. the fixes force the attack to work in private, or publicly orphan honest blocks.

At Bitcoin's core is a timestamp server, motivating miners to push time forward which makes the difficulty lower. Users limit forward time by rejecting chains that push too far. MTP in BTC can be kept back without increasing difficulty, breaking the basic incentive mechanism as it applies to MTP.

The problem exists in all coins that do not use monotonic timestamps or use an MTP as the input times for the difficulty algorithm. So it applies to almost all coins. See links below for details and proof. Ways to fix this:

  1. Difficulty algorithm could use the MTP of the 1st and last blocks in its averaging window instead of the timestamps.
  2. Wherever a PoW-supported timestamp is needed, use the highest timestamp out of the past 11 blocks and the current timestamp, or the highest timestamp seen.
  3. Ideally: Enforce monotonic timestamps which is the same as using MTP=1 instead of MTP=11. The timestamp of every block should be at least 1 second after the prior block's timestamp.

Monotonicity is a fundamental requirement for all consensus messages used in all concepts of distributed consensus as explained in Lamport's 1978 paper. If this rule is not adhered to, at least indirectly, there is always an attack. MTP was an indirect attempt at monotonicity, but it fails because it wasn't made the input to the difficulty algorithm to determine timespan. Disconnecting the difficulty algorithm from the MTP prevents the MTP from having PoW support.

This also fixes a prior issue I posted here which I think is still the older open issue.

opentimestamps/opentimestamps-client#147
https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/59

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