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
{{ message }}
This repository has been archived by the owner on Jul 20, 2021. It is now read-only.
The consensus allows blocks to be created some time in the future, and be immediately accepted. This prevents local forking behavior in case the local time is lagging a bit behind the rest of the network nodes. At the same time, the POBS protocol evaluates blocks up to 10 seconds in the future. So if a block is found by the block creator to be valid if created at time(now + 10 secs), it will create the block now, set the block timestamp to the aforementioned timestamp (which is in the future), and submit the block to the cs. The block is accepted, and propagated. Now other block creators (or the same block creator) try to create blocks again (having added the future block, which has a timestamp higher than the block creators current timestamp). If a block is now found at time(now + 1sec), then the block is once again created and submitted (and accepted), but with a lower timestamp than the previous block.
The reason the Cs allows this to happen is due to the mediantimestampwindow variable. This variable takes the median timestamp of the last few (in tfchain 11 or so iirc) blocks, and only verifies the new bock timestamp to be higher than the median of these few blocks
We do have to make sure that 1 badly behaving blockcreator ( might be on purpose) does not limit the blockcreation chances of the rest( and as such increases his).
No description provided.
The text was updated successfully, but these errors were encountered: