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

Coordinator-instantiated milestone partitioning attack #177

Closed
ercw opened this Issue Jun 21, 2017 · 4 comments

Comments

Projects
None yet
6 participants
@ercw
Copy link

ercw commented Jun 21, 2017

Issue:
Since IOTA is currently specially vulnerable to 51% attacks, a rogue Coordinator could present two separate milestones using identical index numbers to the network and sustain a partitioning attack long enough to successfully double-spend on the network.

Theory:
IOTA is currently only protected against reorg-attacks by virtue of the Coordinator. In the case that the attack is launched using a compromised Coordinator private key (or if the IOTA Foundation is simply malicious), then there is no such protection. The Coordinator would issue two different milestone transactions with the same index numbers which would split the network into two parts. The Coordinator would then keep incrementing the two milestones separately. Simultaneously, to ensure that no subtangle overtakes the other and to prevent the network from converging, the Coordinator would abuse the fact that IOTA currently has very low hashpower and ensure that both subtangles are sustained by producing PoW (by spamming transactions) on whichever subtangle that needs it long enough for a double-spend to confirm on economically important nodes.

Suggested fix:
A kill-switch mechanism could be implemented in clients in order to halt the network in the case of a milestone partitioning attack. If two milestone transactions with the same index numbers but different hashes are detected in the validateMilestone-function a node could cease all operations and start spamming the network indefinitely with a new type of transaction alerting other nodes of the attack, presenting the proof of the two milestones with same index but different hashes. Nodes that see this special transaction could enter the same behavior. This should make attempts at milestone partitioning attacks less feasible for the Coordinator.

@mariodian

This comment has been minimized.

Copy link

mariodian commented Oct 25, 2017

Why was this closed immediately instead of being addressed?

@TbLtzk

This comment has been minimized.

Copy link

TbLtzk commented Oct 25, 2017

At least a rational for refuting the suggestion would be interesting

@scipsycho

This comment has been minimized.

Copy link

scipsycho commented Feb 9, 2018

yeah, it at least should have been given an explanation.

@tactical-drone

This comment has been minimized.

Copy link

tactical-drone commented Feb 9, 2018

In the case that the attack is launched using a compromised Coordinator private key

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
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.