Pages:
Author

Topic: A Stake-Based Double-Voting Consensus Protocol - page 2. (Read 826 times)

member
Activity: 199
Merit: 15
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).
full member
Activity: 351
Merit: 134
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.
member
Activity: 199
Merit: 15

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.
full member
Activity: 351
Merit: 134
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.
member
Activity: 199
Merit: 15
*) See our discussion with @shunsaitakahashi on PoA - https://bitcointalksearch.org/topic/proof-of-approval-version-20-3913439
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.
member
Activity: 199
Merit: 15

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).
full member
Activity: 351
Merit: 134
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://bitcointalksearch.org/topic/m.49129375.

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://bitcointalksearch.org/topic/proof-of-approval-version-20-3913439
member
Activity: 199
Merit: 15
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://bitcointalksearch.org/topic/m.49129375.

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.
full member
Activity: 351
Merit: 134
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.
Quote
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.
Quote
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?
member
Activity: 199
Merit: 15
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.
Quote
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.
Quote
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.
full member
Activity: 351
Merit: 134
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.
member
Activity: 199
Merit: 15
Anyone can provide many confirms to those signals, but he can't fake the fastest confirm to most of them, because the network latency and the physical distance between nodes.

What is the cost of a VPS? If you wanted to dominate voting by having the fastest ping times, wouldn't that be trivially achievable by renting VPSs?

good point. Renting a VPS with several IPs could be harmful.


This problem was discussed in section 6(2).
Quote

I also like to ask another question from our friend: "excluding the ping/latency property of this idea, what are differences with this proof model (PoAS) and Delegated Proof-of-Stake (DPoS) [1]?"

Under some circumstances PoAS works like DPoS. Please read the 4th section of the summary post: https://bitcointalksearch.org/topic/m.49129375
member
Activity: 199
Merit: 15
Modified for better understanding.
full member
Activity: 135
Merit: 178
..
Anyone can provide many confirms to those signals, but he can't fake the fastest confirm to most of them, because the network latency and the physical distance between nodes.

What is the cost of a VPS? If you wanted to dominate voting by having the fastest ping times, wouldn't that be trivially achievable by renting VPSs?

good point. Renting a VPS with several IPs could be harmful.

--------------

I also like to ask another question from our friend: "excluding the ping/latency property of this idea, what are differences with this proof model (PoAS) and Delegated Proof-of-Stake (DPoS) [1]?"


[1] https://blockonomi.com/delegated-proof-of-stake/
full member
Activity: 351
Merit: 134
Anyone can provide many confirms to those signals, but he can't fake the fastest confirm to most of them, because the network latency and the physical distance between nodes.

What is the cost of a VPS? If you wanted to dominate voting by having the fastest ping times, wouldn't that be trivially achievable by renting VPSs?
member
Activity: 199
Merit: 15

what about the second voting in your proposal? are they protected against sibyl attack?

The first voting is to determine the right to generate the next block.
The second voitng is to determine the main branch from different forks.

About the previous question, maybe I misunderstood you.
The "Confirms" you mentioned should not be "votes" from stakeholders. Sorry about that.
Anyone can provide many confirms to those signals, but he can't fake the fastest confirm to most of them, because the network latency and the physical distance between nodes.
full member
Activity: 135
Merit: 178
..
"Confirms" is votes from the stakeholders. He can vote for anyone he want anyway, but can not vote with the stake belonging to others.

what about the second voting in your proposal? are they protected against sibyl attack?

Quote
3. Consensus Process

We rely on two types of votes, namely the vote from stakeholders for miners and the vote from the miner node for the current main branch, to reach a consensus that will be introduced below.
member
Activity: 199
Merit: 15

thank you. however in page 8, (frauds and attacks) you write a bit about sibyl attack, but I think having several different entities in a network could make it vulnerable in front of sibyl attack. look, there is a question, how much does it may cost for a dishonest person to provide many fake CONFIRMS for himself and win the fee/reward?
"Confirms" is votes from the stakeholders. He can vote for anyone he want anyway, but can not vote with the stake belonging to others.
Quote
P.S.:

honestly, forget the patent part of your proposal.  this is better you provide your proposal with a MIT License, then people may get interested in your job. in one case, even a GPL-3 License caused failure during integration of hyperledger and ethereaum:

https://www.ethnews.com/hyperledger-fails-ethereum-integration-due-to-licensing-conflicts
Thank you for the advice! I'll consider about it.
full member
Activity: 135
Merit: 178
..
it cant be fabricated easily unless you cooperate with the signal senders.
Quote

thank you. however in page 8, (frauds and attacks) you write a bit about sibyl attack, but I think having several different entities in a network could make it vulnerable in front of sibyl attack. look, there is a question, how much does it may cost for a dishonest person to provide many fake CONFIRMS for himself and win the fee/reward?

P.S.:

honestly, forget the patent part of your proposal.  this is better you provide your proposal with a MIT License, then people may get interested in your job. in one case, even a GPL-3 License caused failure during integration of hyperledger and ethereaum:

https://www.ethnews.com/hyperledger-fails-ethereum-integration-due-to-licensing-conflicts
member
Activity: 199
Merit: 15
I afraid this parameter could fabricate easily. would you please elaborate this mechanism?
Sorry I didn't notice this question yesterday.
Network dispersity is a concept that means how much dispersed terminals in the network. Network dispersity reflects the ability to grab informations randomly appearing in the network. Like a honeycomb full of worker  bees, the more bees working out side, the better chance they grab a random flower. it cant be fabricated easily unless you cooperate with the signal senders.
Quote
while your voting model doesn't fit in opportunity cost context, your model still suffers from N@S.
I'm not saying I eliminates NAS, which is impossible . It just resolves the most serious problems caused by NaS.
Pages:
Jump to: