Pages:
Author

Topic: A Stake-Based Double-Voting Consensus Protocol (Read 745 times)

member
Activity: 199
Merit: 15
Reorganized the sentences and paragraphs of the English version trying to make them express more accuratly.
Think it should be reposted.
member
Activity: 199
Merit: 15
What about the cumulative stake rule, how does that combine?
That rule should still work if there are no suspicious chains. With a very small probabitlity, the bootsraping notes will be attacked and become the victim of a fake fork, unless they concern about fork announcements or something like that.

I'm trying to minimize the major defects of PoS including the harm of NaS, theoritically or pratically.
As I've said before:
Quote
The main purpose of the study is to make PoS protocol more suitable for the use of cryptocurrency and become the mainstream protocol in the future.
PoS consensus mechanism is the closest protocol to replace the classic proof of work which is, seems to me, dying.  I'll be sad if there is no protocol strong enough to do that.
full member
Activity: 351
Merit: 134
The bootstraping nodes have to:
Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.

And what is the chain selection rule for non-bootstrapping nodes? Same? Different?
Different. With finalization, without the check above.

What about the cumulative stake rule, how does that combine?
member
Activity: 199
Merit: 15
The bootstraping nodes have to:
Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.

And what is the chain selection rule for non-bootstrapping nodes? Same? Different?
Different. With finalization, without the check above.
full member
Activity: 351
Merit: 134
The bootstraping nodes have to:
Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.

And what is the chain selection rule for non-bootstrapping nodes? Same? Different?
member
Activity: 199
Merit: 15
Let me sum up the content we discussed:
The attacker has to:
1. Find a time point where a certain proportion (e.g. 20%) stakes and miners suddenly silent at the same time for a long period or brib enough users to do so.
2. Collect as many accounts as possible of the miners (in this case >80%) that were active at the time point above.
3. Collect enough accounts with more stakes than the average total online stakes (in this case >80%).
or
Collect accounts owning more than a certain proportion (e.g. 95%) stakes at a time point and 95% active miners' accounts at the same time point.
Then he could launch a successful bootstrap poisoning attack. I must say both of them are remarkable achievements.

The bootstraping nodes have to:
Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.

As discribed above,  a successful bootstrap poisoning attack shouldn't be very frequent, or to say unusual.
Bootstraping nodes don't need to do anything bizarre or too complex. All of those anayasis are objective but if they want to do it carfully they should pay some attention to the subjective information. This degree of subjectiveness should be acceptable for any practical objective systems. After all, even bitcoin has "subjective" fork announcements.
member
Activity: 199
Merit: 15
It cannot work. Whatever rule you come up with related to inactive stake, you can easily replicate either through bribing, or just might happen by accident.

In addition, the attackers could easily be miners as well.

You cannot cobble together a chain selection rule + some other bizarre ad-hoc rule for detecting history attacks; they have to be one and the same rule, otherwise this will just be to easy to exploit due to complexity.
Remember that between two chains, the suspecious part only appears at the forked place where we need to focus on. That means you have to limit the history point to the part where the main chain fluctuates. You can't control the history point so easily, can you?

Quote
In addition, the attackers could easily be miners as well.
Being a miner is not enough. He has to buy as many active miners' accounts as possible. The purpose of mentioning the miners was to explain that there should not be too many quiet periods because the voting cycle of miniers is about an hour.  (In case you didn't read through the paper, the voting cycle of the stakeholders is about 100 hours, so that the meaning of "active" in our system is an actual cyclically-publishing activity, which is different than the common sense of the meaning of "active" .)

And the miners are a group of people who are continuously benifiting from the system, not like the long since cashing out stakeholders. They should not be so easy to buy over.
full member
Activity: 351
Merit: 134
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.
How does that work? Bribling?

Yes.

Quote
How long does the quiet periods usually last? If I find out that the chain I accepted have some proportion of stakes suddenly disapear for two days, I'll check it again. Late, but still objective.

More importantly, in PoAS, miners are working fulltime with accumulated stakes. If you don't want the real miners suddenly stop working , which is too obvious, you have to buy the accounts of those working miners. I can't figure out how to purchase that yet.

It cannot work. Whatever rule you come up with related to inactive stake, you can easily replicate either through bribing, or just might happen by accident.

In addition, the attackers could easily be miners as well.

You cannot cobble together a chain selection rule + some other bizarre ad-hoc rule for detecting history attacks; they have to be one and the same rule, otherwise this will just be to easy to exploit due to complexity.
member
Activity: 199
Merit: 15
Yes, but it doesn't work. That could easily happen on the canon chain during quiet periods.
How long does the quiet periods usually last? If I find out that the chain I accepted have some proportion of stakes suddenly disapear for two days, I'll check it again. Late, but still objective.

More importantly, in PoAS, miners are working fulltime with accumulated stakes. If you don't want the real miners suddenly stop working , which is too obvious, you have to buy the accounts of those working miners. I can't figure out how to purchase that yet.
member
Activity: 199
Merit: 15
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.
How does that work? Bribling?
full member
Activity: 351
Merit: 134
"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.
member
Activity: 199
Merit: 15
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?
full member
Activity: 351
Merit: 134
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.
member
Activity: 199
Merit: 15
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.
member
Activity: 199
Merit: 15
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?
full member
Activity: 351
Merit: 134
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.
member
Activity: 199
Merit: 15
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.
full member
Activity: 351
Merit: 134
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.
member
Activity: 199
Merit: 15
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.
Quote
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.
full member
Activity: 351
Merit: 134
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.

Quote
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.
Pages:
Jump to: