Recently there there were reorg attacks on different networks. And MWC can experience the same problem. We have plan how to restore the network after the large reorg attack, but we better to think how to update the node to handle the series of attacks.
We can introduce the checkpoints, or we can add some ‘penalty’ to do reorgs. The checkpoints can be local, so the nodes will maintain the local copy of ‘must have’ blocks. Or the checkpoints can be global, so any server or other blockchain like BTC or ETH can be used to store them.
Also we can introduce some penalty to the deepness and quality of reorgs. For example the deeper the reorg and less transactions it has, more additional difficulty it must have.
The problem with any non global checkpoints is the network splitting. It is possible to split the network with crafted attack. And the split will be sustainable, so it can be fixed manually by cleaning the node data and do resync.
With global checkpoints the problem is centralization or another point of attack. For example if BTC selected to store the checkpoint, attacker can now publish some checkpoint that he benefit the most. So the problem will not be solved as well. I think such global point of attack will make network weaker.
As we can see, non of solutions are perfect. In this case it make sense to select good enough with smallest complexity. And it is a local checkpoints. Also local checkpoints are not required the hardfork (other alternatives does required). We can think about that as automatic change in the mwc-node config (currently we can do the same by updating configs with some scripts and restart ting the mwc-node every minute)
Because the network can be splitted, we want to:
- minimize the chance of the split.
- the splitted nodes should be able to recover eventually in most cases.
- the checkpoints should limit the maximum reorg to some well defined depth.
Here is the proposal:
- We are assuming that the ‘natural’ reorg depth can’t be deeper then 10 blocks.
- Every node will maintain 2 checkpoint:
- P1 = Max Height - 10
- P2 = Max Height - 20
- Checkpoint P2 never can be changed. So the maximum reorg can be 20.
- Checkpoint P1 can be changed if another branch difficulty is 2x larger that the current branch. We can say another branch should be 10 blocks higher if branch stuck. But is there is a mining on both branches, that rule will not be applicable and network likely split.
Here is an example of what will happens during different attack scenarios (in all scenarios it doesn’t matter how attacker release blocks, all branch or one by one just building the parallel branch).
In this example we have a blockchain of height 100. Normally syncing takes some time. That is why some nodes will have hight 100, some 99. So we will have the heights for both types of nodes:
tip: 100 tip: 99
P1: 90 P1:89
P2: 80 P2:79
Here are good cases:
If reorg at block 79 or deeper - we are good. The whole attacker branch will be rejected.
If reorg at heights 91-99 - we are good as well. The attacker branch will be accepted. The deepness is small, so it is ok.
If reorg at the range 81-89 - The attacker branch in order to be accepted need to have height 40 or more. It is good scenario because the reorg deepness will be below 20 and attacker need hashpower 2x more then a network.
Here are bad cases:
- Reorg happens at height 90 and new branch height is 10. In this case half of the nodes will follow the reorg. But half of the nodes are not because of checkpoint P1 they will expect height 20 or more.
If mining pools will keep staying on the right branch, then after another 10 blocks, the whole network will switch back and split will be fixed.
But if some of the mining pools will not switch and they will have 1/2 or more of the mining power, then in 10 blocks they will create a splitted network. That split will need to be fixed manually (the node data need to be deleted and resync need to be done).
- The worse issue will happens if reorg happens at height 79 and the new branch will be 30 blocks hight. Because of the some nodes will reject the branch. But half of the nodes will accept it because P1 will be satisfied and P2 is still 1 block lower. The result will be splitted and network can be fixed only manually.
Another alternative - the checkpoints can have time, so in case of P1 collision, that include the miners that mine on both branches, permanent ‘split’ can be avoided and network eventually will stabilize. But that will introduce opportunity of stealth large reorg. Attacker just need to do that differently by simulating this scenario. It is not acceptable because that main purpose of the checkpoints is prevent such deep attacks.
Positive outcome of checkpoints: Checkpoint in this proposal guarantee that reorgs can’t be higher then 20. In worst case scenario the network will be splitted and fixed later. That will allow to reduce the number of confirmations that are required for the swaps and exchanges.