Pages:
Author

Topic: A Consensus Protocol Based on the Ability of Network Dispersity. (Read 292 times)

member
Activity: 199
Merit: 15
So, as an attacker creating a fork, I poison the main branch by using my stake in the main branch and in another branch thereby increasing the odds the main branch will be discarded in favour of my competing fork which contains no 'double-active' stake.
Besides that you have to have enough stake in your branch which is not active in the main branch and that is difficult to achieve.

Quote
Because the is no objective way to tell the difference between the main chain and the competing fork with historical keys - both appear to have the same amount of 'online stake'.
In my protocol the online stake can be precisely counted so that the difficulty can be adjusted by a different way from the PoW protocol. We can calculate the difficulty by using the amount of online stake and that will ensure the fake branch grows slower than the main.

In other protocols, we can build a kind of math model to restrict the blockrate into a certain range according to the current blockrate and difficulty to make sure that the higher mining power generate blocks faster than the lower.

In other words, there are objective methods to tell the difference between different mining power by refering to the current blockrates and the difficulties.
full member
Activity: 351
Merit: 134
Either you select the canon chain based on highest stake, or you don't. If your standard rule is to select based on highest stake, then your secondary rule must use some other criteria. If that is the case, then you don't have 33% attack tolerance anymore, you have a lesser tolerance which will be exploitable much more easily.
The first rule is the longest or heaviest branch; the second rule is according to the proportion of the double-active stake: the lower proportion, the higher probobility to be choose to the main branch. There could be some complex judgment basis but they basically follow those rules.

So, as an attacker creating a fork, I poison the main branch by using my stake in the main branch and in another branch thereby increasing the odds the main branch will be discarded in favour of my competing fork which contains no 'double-active' stake.

Quote
By the way , I still don't get why the fake chain can catch up with the speed of the main chain. Since the growth speed is determined by the online stake, why would a branch with partial stakes grow faster than the one with full stakes?

Because the is no objective way to tell the difference between the main chain and the competing fork with historical keys - both appear to have the same amount of 'online stake'.
member
Activity: 199
Merit: 15
Either you select the canon chain based on highest stake, or you don't. If your standard rule is to select based on highest stake, then your secondary rule must use some other criteria. If that is the case, then you don't have 33% attack tolerance anymore, you have a lesser tolerance which will be exploitable much more easily.
The first rule is the longest or heaviest branch; the second rule is according to the proportion of the double-active stake: the lower proportion, the higher probobility to be choose to the main branch. There could be some complex judgment basis but they basically follow those rules.

By the way , I still don't get why the fake chain can catch up with the speed of the main chain. Since the growth speed is determined by the online stake, why would a branch with partial stakes grow faster than the one with full stakes?
full member
Activity: 351
Merit: 134
...try to trigger your other rule to discard the canon chain as fake...
Have you thought about how? Take notice the proportion is measured by stake. So you have to fake the activities on the fake chain using the active private keys on the main chain.

Either you select the canon chain based on highest stake, or you don't. If your standard rule is to select based on highest stake, then your secondary rule must use some other criteria. If that is the case, then you don't have 33% attack tolerance anymore, you have a lesser tolerance which will be exploitable much more easily.
member
Activity: 199
Merit: 15
...try to trigger your other rule to discard the canon chain as fake...
Have you thought about how? Take notice the proportion is measured by stake. So you have to fake the activities on the fake chain using the active private keys on the main chain.

Quote
it wont, but for the sake of argument, lets assume it will
What is the other reason it wont work?

Quote
So now instead of one rule for selecting the correct fork you have two rules.
There may be more than two rules in Pos system, such as : the first N blocks are not reorganizable.
full member
Activity: 351
Merit: 134
I have thought seriously about the problem you posted and maybe I have found a way to mitigate it. It's useful to any PoS protocols.

Lets assume for a moment that this solution will work (it wont, but for the sake of argument, lets assume it will). So now instead of one rule for selecting the correct fork you have two rules. Now instead of being a majority stake holder, the attacker can just try to trigger your other rule to discard the canon chain as fake, and have your new selection rule pick his fake chain instead.
member
Activity: 199
Merit: 15
That won't help you at all. It doesn't address the problem of historical private keys. I suggest you read this post: https://bitcointalksearch.org/topic/m.14058047

I have thought seriously about the problem you posted and maybe I have found a way to mitigate it. It's useful to any PoS protocols.

First of all the reorganizition is designed to prevent forks. Under normal circumstances,  some stakeholders would be active(trading or mining) in both branches (caused by NaS too) if there appears a fork. According to the probability there will be similar stake proportion of "double-active" users between both branches.

But if the branch is a fake chain built by the attackers, they will be disproportionate —— the proportion mentioned above in the mainchain will be much less than that in the fake one, unless you have bought every account, which is impossible. Under this circumstance, the branch should never be accepted no matter how long it is. This operation is also nessesary to prevent some group of users from getting extra advantage by unfair means when forks come.

By the way, the situation you have mentioned:"any syncing node querying at random will find his fake nodes with fake history" could be resolved by controling the p2p links——
Quote
each node only needs to build connection with a certain number of nodes with the fastest response speed.

The attacker needs to try through a lot of past blocks so that the longer range he seeks, the better chance he would success. But the longer range he starts the fork, the more obvious the disproportion will be. I think that might increase the difficulty you launch an attack, after all you gain those private keys by "buying".
member
Activity: 199
Merit: 15
It's all NaS in the end. Every problem that PoS has is due to NaS.

edit: in any case, what I've posted isn't 'long' range, but instead *any* range.
I know what you mean with "NaS" but I used that word with the meaning of the "double voting problem".
If the problem mentioned at that post is still unresolved, I must say that's the problem we haven't resolved yet. But we have at least resolved the first one.
full member
Activity: 351
Merit: 134
That won't help you at all. It doesn't address the problem of historical private keys. I suggest you read this post: https://bitcointalksearch.org/topic/m.14058047
Long range attack is an other problem of PoS but we are discussing the NaS problem aren't we?
https://blog.ethereum.org/2014/05/15/long-range-attacks-the-serious-problem-with-adaptive-proof-of-work/

It's all NaS in the end. Every problem that PoS has is due to NaS.

edit: in any case, what I've posted isn't 'long' range, but instead *any* range.
member
Activity: 199
Merit: 15
That won't help you at all. It doesn't address the problem of historical private keys. I suggest you read this post: https://bitcointalksearch.org/topic/m.14058047
Long range attack is an other problem of PoS but we are discussing the NaS problem aren't we?
https://blog.ethereum.org/2014/05/15/long-range-attacks-the-serious-problem-with-adaptive-proof-of-work/
newbie
Activity: 1
Merit: 0
i

hi:
This is the research paper about the project I posted before.
Thank you for your time.
https://github.com/yj1190590/PoND/blob/master/research_paper.pdf
If there are any questions, please let me know. Thanks.

previous post:https://bitcointalksearch.org/topic/a-new-type-of-consensus-protocol-3251016
full member
Activity: 351
Merit: 134
Words like 'sealed' have little meaning in any system where block generation has zero cost.
I recommend you to read the article "Transactions as Proof-of-Stake" by Daniel Larimer whose idea was close to mine in this respect.

That won't help you at all. It doesn't address the problem of historical private keys. I suggest you read this post: https://bitcointalksearch.org/topic/m.14058047
member
Activity: 199
Merit: 15
Words like 'sealed' have little meaning in any system where block generation has zero cost.
I recommend you to read the article "Transactions as Proof-of-Stake" by Daniel Larimer whose idea was close to mine in this respect.
full member
Activity: 351
Merit: 134
I hope this could explaine:
Quote
The difference is that when the votes take effect, they are already sealed in the existing blocks. That makes the common problem of PoS such as “nothing at stake” or “stake grinding” resolved.

Words like 'sealed' have little meaning in any system where block generation has zero cost.
member
Activity: 199
Merit: 15
All stake based protocols suffer from NaS - yours included.
I hope this could explaine:
Quote
The difference is that when the votes take effect, they are already sealed in the existing blocks. That makes the common problem of PoS such as “nothing at stake” or “stake grinding” resolved.
full member
Activity: 351
Merit: 134
My point was, if you only achieve the security model of PoS with this technique, why bother at all?
We assume that you are right that it has the same security level as PoS, which actually not(you will know that if you read the section "51% attack"). At least the new model don't have the common flaws of PoS such as the wealth concentration issue or "nothing at stake" problem.

All stake based protocols suffer from NaS - yours included.
member
Activity: 199
Merit: 15
My point was, if you only achieve the security model of PoS with this technique, why bother at all?
We assume that you are right that it has the same security level as PoS, which actually not(you will know that if you read the section "51% attack"). At least the new model don't have the common flaws of PoS such as the wealth concentration issue or "nothing at stake" problem.
And provides incentives to build open development multi-chain systems which may be a progress in the field of cryptocurrency.
Quote
Provide an incentive for developers to build extend projects which ensures the sustainability and extendibility of the system.
member
Activity: 199
Merit: 15
My point was, if you only achieve the security model of PoS with this technique, why bother at all?
We assume that you are right that it has the same security level as PoS, which actually not(you will know that if you read the section "51% attack"). At least the new model don't have the common flaws of PoS such as the wealth concentration issue or "nothing at stake" problem.
full member
Activity: 351
Merit: 134
You can consider it as a kind of PoS mechanism in this respect, that's OK. But from some other respects it has many differences from PoS. About this question, you could refer to: https://github.com/yj1190590/PoND/blob/master/README_eng.md#faqs if you'd like to.

Quote
At worst you will have all kinds of sybil attack problems related to the nuances of your implementation.
Sybil attacks are not so easy just because I use the "stake" property like you said.


My point was, if you only achieve the security model of PoS with this technique, why bother at all?
member
Activity: 199
Merit: 15
You cannot objectively verify claimed network latency, so you cannot build a consensus using this concept. I think you have realised this, so you've stake weighted your consensus to compensate....
You are right, that was one reason that I use stake to measure the power of voting. But it was not a compensation because the "stake" property plays other important roles like “balance the mining power”.
you could see it here: https://github.com/yj1190590/PoND/blob/master/README_eng.md#compete-for-the-voters.
Quote
At best this will leave you with the security model of PoS.
You can consider it as a kind of PoS mechanism in this respect, that's OK. But from some other respects it has many differences from PoS. About this question, you could refer to: https://github.com/yj1190590/PoND/blob/master/README_eng.md#faqs if you'd like to.

Quote
At worst you will have all kinds of sybil attack problems related to the nuances of your implementation.
Sybil attacks are not so easy just because I use the "stake" property like you said.
Pages:
Jump to: