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
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.
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.
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.
This may not affect the value of bitcoin on exchanges which makes it much more likely to occur than other 51% attacks.
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.**
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.
Therefore no code, entity, or contract anywhere that assumes the MTP has PoW support should use the MTP as a timestamp.
Neither should the timestamp of a particular block be used as a timestamp because it can be held back as far as the MTP.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: