You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Difficulty algorithm could use the MTP of the 1st and last blocks in its averaging window instead of the timestamps.
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.
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.
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:
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
The text was updated successfully, but these errors were encountered: