A Stake-Based Double-Voting Consensus Protocol

[yj1190590]

This problem was discussed in section 6(2).

You briefly mention the problem and that 'countermeasures' might need to be deployed, but the key issue is not addressed.

If the key issue you mentioned means the "VPS" problem, maybe you have missed the main idea of the paper or maybe I missguided you by my previous posts, I am sorry for that. Although I have a preference for it because it's objective and seems "elegant" to me, "Network Dispersity" is just one of the abilities to "accumulate stakes". If it fails, the security and fairness will not be affected because:
1.

If countermeasures are not taken, and in the end, if the miners want to win more votes, they will need to arrange more super gatherer nodes globally

And the competition of accumulate stakes is still fair and objective.
Even if the accumulating process is subjective, you could consider it as a sort of "public" DPoS protocol in this respect.
2.

most of the stakes are owned by the richest users who will tend to accumulate their stakes by themselves and work alone.

It means that the chains will remain strong whether the "network dispersity" works or not, and the motivation of breaking the rules of network dispersity is low because of the negative ROIs.

[1714961006]

1714961006

[monsterer2]

If the key issue you mentioned means the "VPS" problem, maybe you have missed the main idea of the paper or maybe I missguided you by my previous posts, I am sorry for that. Although I have a preference for it because it's objective and seems "elegant" to me, "Network Dispersity" is just one of the abilities to "accumulate stakes". If it fails, the security and fairness will not be affected because:
1.

If countermeasures are not taken, and in the end, if the miners want to win more votes, they will need to arrange more super gatherer nodes globally

And the competition of accumulate stakes is still fair and objective.
Even if the accumulating process is subjective, you could consider it as a sort of "public" DPoS protocol in this respect.
2.

most of the stakes are owned by the richest users who will tend to accumulate their stakes by themselves and work alone.

It means that the chains will remain strong whether the "network dispersity" works or not, and the motivation of breaking the rules of network dispersity is low because of the negative ROIs.

Please enlighten me, what is the main idea of the paper, because as far as I can tell, the main idea is stake weighting with "Network Dispersity" added on top, which has horrible sybil attack problems?

[yj1190590]

Please enlighten me, what is the main idea of the paper, because as far as I can tell, the main idea is stake weighting with "Network Dispersity" added on top, which has horrible sybil attack problems?

Stake weighting, not with network dispersity but with accumulated stakes. Sybil attacks are also not so easy and not even valuable for attackers to apply, and it is no big deal if it really happens.
Please at least read the answer I just replied, I don't want to explain the same stuff repeatedly.
The main idea of the paper was introduced here https://bitcointalk.org/index.php?topic=5094909.msg49129375#msg49129375.

First of all, thank you for your concern. But you don't have to be offensive because I am not your enemy but a guy who wants to share something and discuss them with someone interested. Maybe I have offended you with some unappropriate words that I didn't noticed, I appologize for that.  Anyway, all questions are welcome.

[monsterer2]

Stake weighting, not with network dispersity but with accumulated stakes. Sybil attacks are also not so easy and not even valuable for attackers to apply, and it is no big deal if it really happens.
Please at least read the answer I just replied, I don't want to explain the same stuff repeatedly.
The main idea of the paper was introduced here https://bitcointalk.org/index.php?topic=5094909.msg49129375#msg49129375.

First of all, thank you for your concern. But you don't have to be offensive because I am not your enemy but a guy who wants to share something and discuss them with someone interested. Maybe I have offended you with some unappropriate words that I didn't noticed, I appologize for that.  Anyway, all questions are welcome.

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*.

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


*) See our discussion with @shunsaitakahashi on PoA - https://bitcointalk.org/index.php?topic=3913439.0

[yj1190590]

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.

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).

[yj1190590]

*) See our discussion with @shunsaitakahashi on PoA - https://bitcointalk.org/index.php?topic=3913439.0

Yes I have read that before, and the paper, which is nice.
And the original post about the "history attack" of yours, good thinking, by the way.

[monsterer2]

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.

But what if that is easy?

What if I own old (now empty) private keys containing more stake than the current online stake in the main branch and that is within your re-org limit? Surely I can just construct a new branch from there which will become selected as the best branch?

If the amount of current online stake dwindles due to a network outage, or other force majeure, this doesn't seem to far fetched.

[yj1190590]

But what if that is easy?

What if I own old (now empty) private keys containing more stake than the current online stake in the main branch and that is within your re-org limit? Surely I can just construct a new branch from there which will become selected as the best branch?

If the amount of current online stake dwindles due to a network outage, or other force majeure, this doesn't seem to far fetched.

Under the circumstance you described, the history attack could succeed. But if you can't control the time of your attack, what's the point of the attack?
Besides, if there is a chain with the ability of finalization, I will not confirm my transactions untill the final state is established when I am going to make an important deal.

[monsterer2]

Under the circumstance you described, the history attack could be succeed. But if you can't control the time of your attack, what's the point of the attack?
Besides, if there is a chain with the ability of finalization, I will not confirm my transactions untill the final state is established when I am going to make an important deal.

Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.

[yj1190590]

Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.

Bootsrap attack may be a common problem of all chains with finalization. Let's talk about the difficulty and the impact of launching a successful history bootsrap-poinsoning attack in our system.

First, you have to find a history point where there are enough empty accounts that had more stakes than the average total online stakes after that history point. Apparently the longer history the point is ,the more available accounts you can get. But the longer history you look back, the less impact the event of force majeure will have, which limits the history length of that point.

Second, whatever an attack aims for, the cost will not allow you to afford so many stakes.
As the example I gave, the users who sold their empty accounts to the attacker are actually risking their assets (if the attacker succeeds ,their current assets A' and B' will become useless.) for a short-term profit which is the cost of the attack. And that risk cost should not be low enough for one to bear.  At least he can't attack constantly, that makes the influence  of the bootstrap poisoning attack limited (maybe a fork with a few victims, which won't last long).

[monsterer2]

Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.

Bootsrap attack may be a common problem of all chains with finalization. Let's talk about the difficulty and the impact of launching a successful history bootsrap-poinsoning attack in our system.

First, you have to find a history point where there are enough empty accounts that had more stakes than the average total online stakes after that history point.

That isn't true for bootstrap poisoning - as far as any bootstrapping node knows, there is no history available *after* their currently syncing block. A bootstrapping node will accept any valid data as canon, whereas an online node would be able to discard old forks because it has a memory of the real chain.

Moreover, I would say bootstrap poisoning is a problem for all coins which have the NaS problem. 'Finalization' is not a well defined term.

As the example I gave, the users who sold their empty accounts to the attacker are actually risking their assets (if the attacker succeeds ,their current assets A' and B' will become useless.) for a short-term profit which is the cost of the attack. And that risk cost should not be low enough for one to bear.  At least he can't attack constantly, that makes the influence  of the bootstrap poisoning attack limited (maybe a fork with a few victims, which won't last long).

The users who sold their now empty private keys to the attacker risk nothing. They have long since profited by cashing out.

[yj1190590]

That isn't true for bootstrap poisoning - as far as any bootstrapping node knows, there is no history available *after* their currently syncing block. A bootstrapping node will accept any valid data as canon, whereas an online node would be able to discard old forks because it has a memory of the real chain.

Moreover, I would say bootstrap poisoning is a problem for all coins which have the NaS problem. 'Finalization' is not a well defined term.

The difference between an online node and bootstraping node only exists in finalized systems. Otherwise both types of nodes will compare all existing branches obtaining same results. That's why I said the  bootstrap poisoning attack is caused by finalizatin and the history attacks are caused by NaS.

The users who sold their now empty private keys to the attacker risk nothing. They have long since profited by cashing out.

True, I was wrong about that. But there exist many objective methods that can tell the differences between the original chain and the fake one. Such as "the active account with 20% stakes never active anymore since..." or something like that. The new notes should analysis the packages they received, which is troublesome but not too hard.  Even if you manage to fetch the total accounts with 100% stakes and fake a perfect chain, which shouldn't usually happen, there still exist some subjective methods that can distinguish them. I think the influence of a successful bootsrap-poinsoning attack is acceptable.

[monsterer2]

True, I was wrong about that. But there exist many objective methods that can tell the differences between the original chain and the fake one. Such as "the inactive account with 20% stakes never active anymore since..." or something like that.

I don't think so. 'Active since' doesn't make sense because when the attacker buys the private keys, he forks from the point where they were active and produces a fake chain with this now active stake participating. The only thing preventing this attack from succeeding is online nodes being relied upon to keep their existing fork and reject the attackers fork. But this is subjective, not objective.

[yj1190590]

I don't think so. 'Active since' doesn't make sense because when the attacker buys the private keys, he forks from the point where they were active and produces a fake chain with this now active stake participating.

I mean the 20% active accounts he didn't buy. He can't fake them as active.

[monsterer2]

I mean the 20% active accounts he didn't buy. He can't fake them as active.

You can't build a selection rule based on inactive stake. The canon chain may have a whole load of inactive stake during genuine quiet periods, you don't want to select against it during these times, because that's another attack angle.

[yj1190590]

You can't build a selection rule based on inactive stake. The canon chain may have a whole load of inactive stake during genuine quiet periods, you don't want to select against it during these times, because that's another attack angle.

20% active stakes suddenly become quiet at the same time and never active again, that's unusual. Why can't it trigger any alert when we are analysising?

[yj1190590]

You can't build a selection rule based on inactive stake. The canon chain may have a whole load of inactive stake during genuine quiet periods, you don't want to select against it during these times, because that's another attack angle.

20% active stakes suddenly become quiet at the same time and never active again, that's unusual. Why can't it trigger any alert when we are analysising?

That was an example, what I want to say is : you can't easily fake a perfect chain that can't be recognized when we compare it with the real one.

[monsterer2]

That was an example, what I want to say is : you can't easily fake a perfect chain that can't be recognized when we compare it with the real one.

I'm saying the opposite - you can easily fake a chain by doing this. Give me one objective way of distinguishing between a history attacked chain and the real one.

[yj1190590]

That was an example, what I want to say is : you can't easily fake a perfect chain that can't be recognized when we compare it with the real one.

I'm saying the opposite - you can easily fake a chain by doing this. Give me one objective way of distinguishing between a history attacked chain and the real one.

"A certain proportion of active stakes suddenly become never active for a certain period of time." as I said. Isn't that objective?

[monsterer2]

"A certain proportion of active stakes suddenly become never active for a certain period of time." as I said. Isn't that objective?

Yes, but it doesn't work. That could easily happen on the canon chain during quiet periods. Or, your attacker can pay large portions of previously active stake to go quiet, then wait some amount of time and launch his attack when he knows your selection rule will favour his fork.