If you're presented with two identical looking epocs, with the same blocks and different epoc signatories with equal stake, how do you pick between them?
If two competing forks (with epochs) have absolutely equal stake (even to the billionth fraction) at the first separating block, that may result in forking the chain itself. I can't think of a solution for such a situation other than forking the chain. So why wouldn't the history attacker just do exactly that, present you with an identical looking fork with a different epoc? Surely you have to pick the higher stake epoc, which has to be greater than 50%, not 99%? |
|
|
|
Hello Paul, Also note that a single honest stakeholder (hodler  ) holding a relatively small stake (~.1%) will make such a history attack impossible. I'm not totally sure I follow how that is possible. Lets discuss this before I get into any of your other questions This is in context of long timespan History attack where an attacker acquires private keys of accounts that no longer have stake. The owners of those keys may not have much incentive to keep them private since they themselves have nothing to lose. Therefore, an attacker can acquire them relatively inexpensively. In most stake based systems, these keys must form a majority stake at some point in time. Since creating blocks for PoS doesn't require large computation, the attacker can create a large number of blocks in his favor very quickly and overtake the "real" chain. Note that this scenario depends upon how frequently the stakes are changing in the network (churn rate). For a typical network, change of 100% network stake from one group of parties to another group is likely to take over several months if not years. Proof-of-Approval incorporates several features that make the attacker's task difficult. 1. The chain length is counted as the number of slots spanned, not the number of blocks in it. A "real" chain is a lot more likely to have missing blocks than the attack chain. With this rule, the real chain is not penalized. 2. Epoch approvals incentivize even the smallest stakeholder (say a single coin) to participate in epoch approval. Although no claims can be made for the participation rate of epochs, it is highly likely that over a period of month or so, almost all stakeholder would have approved at least one epoch. Over a period of several months or years, it would be even larger. 3. For fork selection with epochs, stakes of all signatories (block creator, block approver, epoch approver, stake transferer) are considered. This is likely to be very close to 100% over a period of months or years. 4. If a 100% churn did occur in the period, all original stakeholders have become signatories for the real chain (100% stake!). An attack chain can only win by exceeding signatory stake in the "real" chain. If an honest "hodler" is holding .1% stake, it isn't possible for the attacker to acquire the private keys representing the needed stake. Regards, Shunsai If you're presented with two identical looking epocs, with the same blocks and different epoc signatories with equal stake, how do you pick between them? What you're claiming is that you have a 99% attack proof protocol, because, objectively there is no difference between a history attack and an attack happening 'now'. |
|
|
|
Also note that a single honest stakeholder (hodler ) holding a relatively small stake (~.1%) will make such a history attack impossible. Hi Shunsai, I'm not totally sure I follow how that is possible. Lets discuss this before I get into any of your other questions Cheers, Paul. |
|
|
|
The ultimate goal, though, is to have the entire stake in the system sign every block, isn't it? I know that would be totally unfeasible because of the size of the data, but this is the security model you're aiming to approximate?
Absolutely! In addition to the size of data, nodes on slow/intermittent connections may not be able to send their approvals for each block. In that case, I think you have succeeding in increasing the difficulty/cost of the recent history attack using old private keys, because as you say, the attacker now needs a super majority of old stake in order to pull off the attack. But, I think its important to note that the attack *is* still possible because old private keys have little to no value. The vulnerability in your design will be the approximation of the ideal all-stake-signs-all-blocks idea. So, as I think you've noticed, ordering by stake in the head block isn't ideal. I expect there to also be boundary issues around the edges of the epocs. I'd like to suggest a simplifying change to your consensus design: * Ditch the epocs * Ditch the approvals * Retain the block reward * Keep all candidate blocks submitted in the chain (perhaps add a minimum stake threshold) * Incentive uncle references (like the PoW etherum chain) * Recursively sort by the cumulative stake This is largely similar to the way ETH currently works, and would negate the need for epocs because you now have active history for all branches, so inserting into past history would have a similar cost to the idealised version above. Cheers, Paul. |
|
|
|
Hello Paul, "Proof of approval is an approximation of a PoS chain in which every block is signed by all the stake in the system"?
How about this? Proof-of-Approval is a stake based protocol where every block is signed by the stake majority and every epoch is signed by almost the entire stake in the system. Regards, Shunsai The ultimate goal, though, is to have the entire stake in the system sign every block, isn't it? I know that would be totally unfeasible because of the size of the data, but this is the security model you're aiming to approximate? |
|
|
|
|
Hi Shunsai,
Thanks for the clarification.
So I can better understand the way this works, am I right to make the following simplifying statement:
"Proof of approval is an approximation of a PoS chain in which every block is signed by all the stake in the system"?
Cheers, Paul.
|
|
|
|
Hello Abdulkhaliq123, In that case, why approve blocks at all? There are two different problems that need solvin Approving blocks provides another very desirable property - finality. In fact, the transactions are stable once a single block has been deposited on it. Regards, Shunsai I think Abdulkhaliq123 was talking about from an incentive PoV - why be a block approver when you can get the same reward for doing nothing, essentially? If you reward each upoc approver the same amount as each block approver, then no one will approve blocks. On the other hand, if you divide the epoc reward between all nodes, then the amount of the reward will be zero because you can just sybil attack it. |
|
|
|
|
Hi Shunsai,
I'd like some clarification on the epoc rewards; every node on the network will receive an award for approving an epoc and said award is the same as the block approval reward?
In that case, why approve blocks at all? In addition, wouldn't this cause the currency to inflate out of control as everyone on the network receives the same award?
edit: also, wouldn't evidence of the epoc rewards result in a massive amount of data (needing to be stored), since every node on the network will participate?
Cheers, Paul
|
|
|
|
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. 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'. |
|
|
|
...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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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://bitcointalk.org/index.php?topic=1382241.msg14058047#msg14058047 |
|
|
|
I hope this could explaine: 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. |
|
|
|
|
Every time you consider increased centralisation for whatever reason, you must ask yourself this question: why am I not simply using VISA?
|
|
|
|
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. |
|
|
|
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. 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? |
|
|
|
I stopped reading the paper at this point. I'm afraid this paper reads like a blog post from someone who just read about cryptocurrencies for the first time.
I don't quite catch the point of you but if there were any misunderstandings caused by the grammar and syntax, I'm very sorry about that becsuse I'm not a native English speaker. If you have any point of view that is against mine, would you please tell me in a direct way because I don't want to miss the main idea again. Thanks. 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.... At best this will leave you with the security model of PoS. At worst you will have all kinds of sybil attack problems related to the nuances of your implementation. |
|
|
|
“Proof of Stake” (PoS) protocol is the most successful one of them because it doesn’t
need any external resources and consumes low energy I stopped reading the paper at this point. I'm afraid this paper reads like a blog post from someone who just read about cryptocurrencies for the first time. |
|
|
|
Hello Aliashraf,
I believe I have a good solution to this History attack (aka Costless Simulation attack) issue. While most PoS systems are relying on the so called "Weak Subjectivity" solution, this solution is purely objective. I am writing it up now and will post it here soon for everyone's review. I can't overstate the value of the feedback provided in this forum. Thanks everyone!
Regards,
Shunsai
I believe this to be impossible, so I await your update with the utmost enthusiasm! |
|
|
|
|
Show Posts
