Why allow blocks in the past?

[Nite69]

What is the reasoning behind this? Why allow blocks whose timestamps are behind head block? I see no good reason for that. I see only risks it brings (as history has pointed out).

Another question; would it be safe (ie. does it open any vulnerabilities) to prevent that, or allow to skip only 1 timestamp backwards?

[gmaxwell]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

[matt4054]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

Thanks for the answer.

More broadly regarding the issue of selfish mining, are the core devs thinking about fixing it somehow in the future with something like enforcing timestamps with some tolerance and rejecting blocks that have been withheld, or any other means?

[btcash]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

Why allow blocks from the future?

[jl2012]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

Why allow blocks from the future?

Because bitcoin is decentralized, so one can't really determine what is past, present, and future

[Peter Todd]

More broadly regarding the issue of selfish mining, are the core devs thinking about fixing it somehow in the future with something like enforcing timestamps with some tolerance and rejecting blocks that have been withheld, or any other means?

Selfish mining is probably not possible to fix in an environment where there are large pools - there isn't even an incentive to broadcast your blocks to more than ~30% of the hashing power if your goal is to get more blocks and/or transactions than your competition. (I spoke to one of the authors of the selfish mining paper about exactly this at the financial crypto conference FWIW)

However, selfish mining isn't a viable strategy if you only have a very small amount of the hashing power, and similarly with a very small amount of hashing power you're incentive is to broadcast your blocks widely. Fixing the problem properly will probably be related to encouraging, or forcing, mining decentralization in general.

[Nite69]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

Why allow blocks from the future?

Because bitcoin is decentralized, so one can't really determine what is past, present, and future

In the block's reference view, we can. It is in the past, if it's timestamp is earlier than the latest block.

Also bitocin has network centralized time which is every connected node's average time. However, this is not 100%, it can can vary.

But since the last block is acepted, every miner can safely assume it's timestamp can be used as next block's timestamp. There should really be no reason to generate a block which has earlier timestamp. Not even if we assume it would be possible to generate endless amount of block during a second.

AFAIK current imlementation uses node's time to stamp the blocks, as long as it fullsills the rule of last blocks 11 median (I guess it has allways followed). So there practically is at least one block which timestamp is earlier than prev block, but it is only seconds behind.

But does anyone remember the discussion what has certainly been done when this 11-block-median is decided?

[Nite69]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

You mean this scenario:

1) someone starts mining with timestamps as far in the future as possible, ie near the 2 hour limit.
2) since network time can vary from node to node, some nodes does not yet accept it and so cannot yet start mining on it, they keep mining at the prev block, until the time passes.

This increases the risk of forking unintentionally. Ie, if the nodes which does not accept the future block finds another block while the mean miner (or those who accepted the first block) finds a second block on the limit.

Even in that scenario, it is just annoying; One of the forks will eventually be the main chain. And I would say the miner mining at the time llimit will lose in the long run.
However, would it be prevented by allowing 1 block in the past?

[Nite69]

Is this vulnerability real:

https://bitcointalk.org/index.php?topic=504103.msg5691810#msg5691810

[BitOnyx]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

Why allow blocks from the future?

Because bitcoin is decentralized, so one can't really determine what is past, present, and future

ok, you lost me there xD

[itod]

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

Why allow blocks from the future?

Because bitcoin is decentralized, so one can't really determine what is past, present, and future

In the block's reference view, we can. It is in the past, if it's timestamp is earlier than the latest block.

This is not necessarily true. If the latest block is referenced sometime in the future, your timestamp can be earlier than the latest block and still be in the future, not in the past. So the jl2012's statement stands.

[Cryddit]

Is this vulnerability real:

https://bitcointalk.org/index.php?topic=504103.msg5691810#msg5691810

It is not real for Bitcoin.  It is real (or about to be if they go ahead with their ill-advised hardfork) for AUR however. 

Bitcoin, like AUR, allows timestamps before the previous block (down to the median of the last 11 blocks)  but because it adjusts difficulty once every 2016 blocks, you cannot use that feature to jump back over more than one difficulty adjustment. 

AUR has a maximum 20% upward/downward difficulty adjustment using KGW starting after a scheduled hardfork any day now, and adjusts EVERY BLOCK.  So the attacker can mine 5 blocks with timestamps reaching as far into the future as necessary to get the 20% easier adjustment each, then mine a block with a timestamp as far back in time from there as he can get, making up all or most of the time increment his prior five blocks have added but incurring the 20% difficulty penalty only once.  It doesn't take a genius to see that if you adjust difficulty downward five times and up once by the same amount, you get a ridiculously low difficulty fast.

BTCX has warned them about this vulnerability and warned them that he will exploit it immediately if they do this hardfork.  And let's face it, he makes deadly serious warnings, not idle threats.  He keeps alt developers honest, at least in terms of calling them out on easy exploits.  You cannot look at the things he's already done to other alts and exchanges that made stupid security blunders, and believe that he will not carry through with the exploit he's already warned them about.  But they appear to be going ahead with the hardfork anyway. 

So grab some popcorn and pull up a seat. 

[Nite69]

Is this vulnerability real:

https://bitcointalk.org/index.php?topic=504103.msg5691810#msg5691810

It is not real for Bitcoin.  It is real (or about to be if they go ahead with their ill-advised hardfork) for AUR however. 

Bitcoin, like AUR, allows timestamps before the previous block (down to the median of the last 11 blocks)  but because it adjusts difficulty once every 2016 blocks, you cannot use that feature to jump back over more than one difficulty adjustment. 

AUR has a maximum 20% upward/downward difficulty adjustment using KGW starting after a scheduled hardfork any day now, and adjusts EVERY BLOCK.  So the attacker can mine 5 blocks with timestamps reaching as far into the future as necessary to get the 20% easier adjustment each, then mine a block with a timestamp as far back in time from there as he can get, making up all or most of the time increment his prior five blocks have added but incurring the 20% difficulty penalty only once.  It doesn't take a genius to see that if you adjust difficulty downward five times and up once by the same amount, you get a ridiculously low difficulty fast.

BTCX has warned them about this vulnerability and warned them that he will exploit it immediately if they do this hardfork.  And let's face it, he makes deadly serious warnings, not idle threats.  He keeps alt developers honest, at least in terms of calling them out on easy exploits.  You cannot look at the things he's already done to other alts and exchanges that made stupid security blunders, and believe that he will not carry through with the exploit he's already warned them about.  But they appear to be going ahead with the hardfork anyway. 

So grab some popcorn and pull up a seat. 

Well, I'm quite sure something is going to be done.

But the main question is that the easiest fix would be preventing blocks in the past. However, everyone seems to be afraid of touching that 'median 11 block rule', most likely because no one really understand why it is there. So all are afraid of that by changing it, they might open some unknown vulnerability. I fully understand that reasoning, but is this a real fear? I don't see any vulnerability it would open and have not heard of any. Of course, that does not prove there are no vulnerabilities, something unknonw can allways pop up.

But it would help pondering, if the original reason for that rule was known. So WHY allow median 11 block time warp? I see it only as a risk, not preventing any fraud.

[jl2012]

Is this vulnerability real:

https://bitcointalk.org/index.php?topic=504103.msg5691810#msg5691810

It is not real for Bitcoin.  It is real (or about to be if they go ahead with their ill-advised hardfork) for AUR however. 

Bitcoin, like AUR, allows timestamps before the previous block (down to the median of the last 11 blocks)  but because it adjusts difficulty once every 2016 blocks, you cannot use that feature to jump back over more than one difficulty adjustment. 

AUR has a maximum 20% upward/downward difficulty adjustment using KGW starting after a scheduled hardfork any day now, and adjusts EVERY BLOCK.  So the attacker can mine 5 blocks with timestamps reaching as far into the future as necessary to get the 20% easier adjustment each, then mine a block with a timestamp as far back in time from there as he can get, making up all or most of the time increment his prior five blocks have added but incurring the 20% difficulty penalty only once.  It doesn't take a genius to see that if you adjust difficulty downward five times and up once by the same amount, you get a ridiculously low difficulty fast.

BTCX has warned them about this vulnerability and warned them that he will exploit it immediately if they do this hardfork.  And let's face it, he makes deadly serious warnings, not idle threats.  He keeps alt developers honest, at least in terms of calling them out on easy exploits.  You cannot look at the things he's already done to other alts and exchanges that made stupid security blunders, and believe that he will not carry through with the exploit he's already warned them about.  But they appear to be going ahead with the hardfork anyway. 

So grab some popcorn and pull up a seat. 

Well, I'm quite sure something is going to be done.

But the main question is that the easiest fix would be preventing blocks in the past. However, everyone seems to be afraid of touching that 'median 11 block rule', most likely because no one really understand why it is there. So all are afraid of that by changing it, they might open some unknown vulnerability. I fully understand that reasoning, but is this a real fear? I don't see any vulnerability it would open and have not heard of any. Of course, that does not prove there are no vulnerabilities, something unknonw can allways pop up.

But it would help pondering, if the original reason for that rule was known. So WHY allow median 11 block time warp? I see it only as a risk, not preventing any fraud.

I think people have answered your question in different ways but you seem couldn't get it. Let me try to explain in a moral, non-technical standpoint.

Why allow blocks whose timestamps are behind head block?

If the timestamp of the head block is 1 hour beyond the ACTUAL time, why must I, as a honest miner, be forced to tell lie by generating a new block with timestamp 1 second after the head block?

The lesson is: due to the decentralized nature of the network, the timestamp is never intended to be a PRECISE timing source. It could be off by at most 2 hours. It is good enough for a long time span but never rely on it for short term timing. Even we don't allow "blocks in the past", it won't change this fact.

[gmaxwell]

So WHY allow median 11 block time warp? I see it only as a risk, not preventing any fraud.

It was explained to you that it prevents shenanigans where the time is pushed against the rail and a trouble making minority makes the network unreliable. This is doubly true when you start to consider nlocktime.  Perhaps you don't care— people often don't care when it comes to other people's security— but at the same time it doesn't actually buy you anything either: If you want a monotonized timestamp just filter the existing one with max(current,last_filtered_value).

[Cryddit]

The 11 block median rule is there so that one miner future-stamping his block, or even two or three in a row, can't force everybody to fake the timestamps on following blocks too.  

Dishonest miners would like to advance the time in the blockchain timestamps as far as they can while mining few blocks; that keeps the difficulty down.  If honest miners were not allowed to undo the damage, we would have wildly inaccurate timestamps (it would probably be 2016 already in the blockchain) and artificially low difficulty.  

[Nite69]

So WHY allow median 11 block time warp? I see it only as a risk, not preventing any fraud.

It was explained to you that it prevents shenanigans where the time is pushed against the rail and a trouble making minority makes the network unreliable. This is doubly true when you start to consider nlocktime.  Perhaps you don't care— people often don't care when it comes to other people's security— but at the same time it doesn't actually buy you anything either: If you want a monotonized timestamp just filter the existing one with max(current,last_filtered_value).

Well, I do care, but I just don't buy that explanation. AFAIK, the biggest damage an evil miner could do by pushing the time limit is slightly increased amount of orphans. And half of those orphans would be his own. It would depend on that if his clock is ahead or behind average network time. Most damage with smallest lost would be keeping his clock at average, where he would get half of the 'extra' orphans created because of pushing the time limit. Going forward would increase the orphans, but he would get them by himself. Going backward would decrease the amount of 'extra' orphans.

There would be no damage to transactions and miners loses would be neglible (only that evil miner would lose noticeable amounts). I do not consider a damage that time would not stay in realtime, it is not doing it anyway.

Even this damage would be practically nothing, if we would allow timestamp to jump over one block back in time.

If you do

Code:

grep "Added time data" debug.log

You'll find out that most of the nodes are within 10 seconds of yours. And almost all are inside minute. The increase in orphans would not be much.

If nlocktime is to be worried, it should be fixed by decreasing that 2 hour limit. (However, that would make timejacking easier, so network time variance should be limited as well, but that's another story)