Add Max Reorganization Depth #295
Conversation
blondfrogs
changed the title
blondfrogs
force-pushed
the
max_reorg
branch
from
7b4e625 to
1030a39
Compare
There was a problem hiding this comment.
Looks good for just depth reorg. Because connecting to one or two rogue nodes first can cause a split if the rogue nodes are able to send 55 blocks before additional connections, let's add these two conditions before rejecting surprise re-org:
- Our node is caught up to the best blockchain.
- Our node is well-connected to the network, and has been well-connected for a while.
https://gist.github.com/gavinandresen/630d4a6c24ac6144482a
Goal: Prevent surprise selfish mining re-org (Scenario C and Scenario D)
|
Updated required checks for max reorg |
src/validation.cpp
Outdated
| //If this is a reorg, check that it is not too deep | ||
| int nMaxReorgDepth = gArgs.GetArg("-maxreorg", Params().MaxReorganizationDepth()); | ||
| bool fGreaterThanMaxReorg = chainActive.Height() - nHeight >= nMaxReorgDepth; | ||
| if (fGreaterThanMaxReorg && g_connman && g_connman->GetNodeCount(CConnman::CONNECTIONS_ALL) > 3 && !IsInitialBlockDownload()) |
blondfrogs
force-pushed
the
max_reorg
branch
from
5156685 to
68ea455
Compare
blondfrogs
changed the title
|
There's an issue with this that I'd like to bring up: any time a client coming online syincing to the network connects to a pool (honest or malicious) mining on a chain > 55 blocks, that client will never be able to connect to the rest of the network, even if they connect to other nodes and get the other part of the chain later on. The scenario could be a lot worse if two exchanges are on separate forks that they both consider valid because there's no way to tell which fork users are on and deposits and withdrawals will be lost. I don't think it's a viable solution to consider which chain the client saw first as a consensus rule determining block validity because different clients can see different chains first. In classic PoW, these chain splits can be resolved by measuring cumulative proof-of-work, but in this case there would be a irreconcilable fork. |
This allows clients to run the wallet and not allow reorganizations that are 55 or more blocks. This can be changed on client start by passing in the flag
maxreorg=<n>This should help stop potential chain attacks by malicious users as well as allow exchanges to augment the required amount of confirmations required.