Open LeeSmet opened 5 years ago
@LeeSmet a problem in the consensus or just in the implementation of the blockcreator?
The specific problem being refered to:
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).
Should it be possible to create multiple blocks on the same exact timestamp?