Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upCoordinator-instantiated milestone partitioning attack #177
Comments
Come-from-Beyond
closed this
Jun 21, 2017
This comment has been minimized.
This comment has been minimized.
mariodian
commented
Oct 25, 2017
|
Why was this closed immediately instead of being addressed? |
This comment has been minimized.
This comment has been minimized.
TbLtzk
commented
Oct 25, 2017
|
At least a rational for refuting the suggestion would be interesting |
This comment has been minimized.
This comment has been minimized.
scipsycho
commented
Feb 9, 2018
|
yeah, it at least should have been given an explanation. |
This comment has been minimized.
This comment has been minimized.
tactical-drone
commented
Feb 9, 2018
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ercw commentedJun 21, 2017
•
edited
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.