Quote from: monsterer2 on January 28, 2019, 02:37:45 PM

Cumulative stake weighting for branch selection is a good idea, but only when you cannot move a critical amount of stake around on a block by block basis, otherwise history attacks are still possible. This means you need a limit on the amount of stake you can move over a certain number of blocks*.

For the historical attacks that construct new branches, we provide two layers of protection.

One is the save point. Save point is a finalized block which will limit the history attacks to its escendants. It means that the attacker must collect enough stakes after the last save point which may be less than an hour earlier. That seems much harder.

The other one is the branch priority decision strategy:The branches with higher online stakes will definitely be heavier. Therefore, unless the historical stakes that an attacker possesses exceed all the online stakes of the current main branch, it will not succeed. For example: the total stakes are made up of three equal part A，B and C. If you collect the private keys of part A and B at a history point, that's 2/3 of the total and you plan to build a new fork from the history point and replace the original one. But the owner of stake A and B must have moved their stakes to other accounts, like A', B', before they give the old private keys to you. So the original branch will have the active stakes of A'+B'+C and your branch will have the stakes of A+B. Your branch will never heavier than the original one under my strategy. Besides, your account A and B will become invalid when a new save point is established.

Quote

The 'network dispersity' thing is just nonsense, though.

Not if most of the users don't break the rule and choose to paticipate in , which probably will happen because the cost of breaking it (like renting alot of VPSs over the plannet) is higher than the benifits (mining reward which is not so big, or double spending which is nearly impossible).