Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merged in efe03eb0379d87d521f6fc86cef39ec06c119f41 - added LWMA #26

Closed
wants to merge 1 commit into from
Closed

Conversation

mizuki-hikaru
Copy link

@mizuki-hikaru mizuki-hikaru commented Apr 25, 2018

Reference implementation of zawy12's LWMA difficulty algorithm merged into loki

@jagerman
Copy link
Member

There's an important update that needs to be added along with this change. Graft experienced a timestamp attack that was able to essentially freeze the ability of any pool to find a block, which then let the attacker mine away on a private chain (or even the public chain, though that tends to make the attack more obvious) without any competition from the rest of the network.

The issue is that when enough recent blocks have forged timestamps in the future, the node provides a block template with the current time, but will reject a solution to that block because the timestamp in the block is too far in the past (relative to recent chain blocks). Upon rejection, however, pools keep trying to solve the block, even though the node will never accept it.

It seems most likely, based on how this unfolded, that the attacker in graft's case stumbled on this accidentally while trying to inject forged timestamps to manipulate the difficulty, but once he figured out what he (or possibly copycats) had, multiple other attacks were orchestrated, the longest of which lasted a little over 9 hours. (None of this shows up in graft's block explorer now because the attacker was mining in private on an alt chain which, after 9 hours, he released to claim all the blocks--somewhere around 270 block rewards, or half a million GRFT).

The fix to avoid this attack is essentially to "chase" a forged timestamp: if the current time added to the block time would be rejected, forge the block's timestamp just enough to allow the block to be accepted. Most of the time this won't matter, but it's an important safety check to have in place in case those conditions do ever occur.

I wrote the patch for graft, which is currently running on most pool nodes (graft devs pushed the fix into the fix/blocktemplate-timestamp-patch branch and recommended all pools move to it), and is available here (graft-project/GraftNetwork#118), along with lots more description of the issue (and more still in the issue linked in the first post). @zawy12 has also opened a Monero issue (monero-project#3717) for it. Aside from changing a couple of macro globals, the patch should apply fairly cleanly to loki.

@zawy12
Copy link

zawy12 commented Apr 28, 2018

@jagerman Thanks for mentioning this. I'll link to this post in my "LWMA installation instructions" as an additional thing coins need to do. For other coins reading this, Loki says this change is easy and does not require a fork.

merged in 5b349daf08993c694ff9a05022dee432852832a2 - timestamps median mitigation
@KeeJef
Copy link
Collaborator

KeeJef commented Apr 28, 2018

Thanks for the heads up @jagerman we've applied that Patch to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants