Skip to content

"timedrift" (nMaxClockDrift) exploit to increase minting probability #82

@Thireus

Description

@Thireus

It has been suggested to change the timedrift parameter value from two hours (set by nMaxClockDrift in main.h) to one minute (http://www.peercointalk.org/index.php?topic=3931.msg37731#msg37731). This would prevent a malicious user to intentionally change his clock and mint far in the future and consequently drastically increase his chances to mint a PoS block.

A few minutes shouldn't be a big issue, it shouldn't lead to a lot of orphan PoS blocks due to desynchronized client clocks. However, I would recommend performing an appropriate study to determine which parameter's value is best. Several factors need to be taken into account such as: network speed or lags (i.e. wallet used behind a proxy), computer speed (i.e. slow Raspberry Pi), and anything else that could affect time during the minting process.

There are several studies online about time drifting distributions that would help figure out which is the optimal value to use to come up with a minimal orphan amount while preventing malicious users to increase their minting chances too much.

Some studies:
http://blog.codinghorror.com/keeping-time-on-the-pc/
http://vancouver-webpages.com/time/
http://vancouver-webpages.com/time/web.html

From what we can observe, if a web server is desynchronized by more than 20 seconds, then it is more likely that it is completely desynchronized (more than 2h, either voluntary or by mistake). If we consider computers, this study shows that this number is more likely to be around 400 seconds.

Consequently I would suggest that we adjust our timedrift parameter for a value of 360 seconds = 3 minutes. Which should cover the eventual network/computer lags. This number is not very accurate, and I believe we can perform a better analysis/study of which value we should use, but at least if a minter detects some orphan blocks he will understand by looking at his clock that this is the problem. Because a drifted clock of 3 minutes is pretty obvious to spot and correct.

Nowadays most computers are permanently synchronized with NTP servers, so it's pretty clear that two hours is way too much in any case and it's an unnecessary attack vector for whoever wants to exploit it (low impact but medium likelihood).

This issue is also discussed here: http://www.peercointalk.org/index.php?topic=2976.msg27924#msg27924

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions