A Stake-Based Double-Voting Consensus Protocol

[yj1190590]

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?

[yj1190590]

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.

[monsterer2]

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.

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.

[yj1190590]

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?

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.

[yj1190590]

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.

[monsterer2]

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?

[yj1190590]

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.

[monsterer2]

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?

[yj1190590]

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:

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.

[yj1190590]

Reorganized the sentences and paragraphs of the English version trying to make them express more accuratly.
Think it should be reposted.