mimblewimble / grin

Minimal implementation of the Mimblewimble protocol.
https://grin.mw/
Apache License 2.0
5.04k stars 990 forks source link

Identify and ban total proof of work cheats #1139

Open ignopeverell opened 6 years ago

ignopeverell commented 6 years ago

During header sync, we trust the total difficulty given by peers during the handshake to select who to get headers from. This is easy to lie about. We need to identify when a node fails to send us headers to match that total difficulty and ban them.

ignopeverell commented 6 years ago

Thinking some more about this and validating my current understanding by going through the code, we're a lot less vulnerable than I thought to a "fake difficulty" attack. The reasons are quite simple:

  1. A fake high difficulty will set the node back in sync mode. But this doesn't operate regular gossip operations, we would still process blocks on the currently best valid chain.
  2. Only the sync_head get directly impacted by a sync reset. As long as the total proof of work on the sync_head is less than what's the on the header_head, there is no impact on the more authoritative chain records: header_head and body_head.

With that in mind, the following would happen if a fake high difficulty peer showed up:

  1. Nodes would reset their sync_head and be ready to follow new block headers being sent to them.
  2. Nodes would send locator requests. Note that this is rather cheap as they're now cached.
  3. From there 2 possibilities:
    • We start receiving some headers and add them to the sync_head. This is a fairly cheap operation, especially given that those headers still have to have a valid PoW against current difficulty.
    • Denial of service angle: the fake peer doesn't send us anything. This could happen after the previous point occurred as well. This would cause the node to repeat 2 every 10 seconds until the fake peer either disappears to actually provides a most worked chain.

It seems the first thing that'll happen overall is that all peers connected to the cheating peer will start polling it, with little effort from honest peers and that's about it. Note that the each locator request isn't very large.

The main impact here is that this could prevent honest peers from triggering what could be a real sync because of the masking of the cheating peer. But then the faking would have to be going on for a while with unclear benefits. It may still be worth detecting very long non-resolving header syncs and banning the peer that initiated it.

sesam commented 5 years ago

Maybe @garyyu @antiochp already have covered this recently? What is still to be done for this issue to be closeable?

antiochp commented 5 years ago

@garyyu Please correct me if I'm wrong but my understanding of the impact here is -

1) new nodes try and sync against the "fraud peer" and fail to sync successfully against any alternative honest peers (we sync headers from the "most work" peer). 2) all mining nodes stop broadcasting new blocks due to a mistaken belief that they are out of sync and their new block is "stale"

(1) is bad because new nodes do not sync successfully (2) is potentially catastrophic network wide

garyyu commented 5 years ago

@antiochp The two impacts above listed are correct. And all nodes will show head syncing x%... on TUI.