BitShares Forum
Main => General Discussion => Topic started by: coolspeed on August 03, 2014, 05:43:13 am
-
How Do Bitshares DACs Solve The "Nothing At Stake" Problem
Vitalik Buterin wrote an article, On Stake:
https://blog.ethereum.org/2014/07/05/stake/
He wrote:
However, with the naive proof of stake algorithm described above, there is one serious problem: as some Bitcoin developers describe it, “there is nothing at stake”. What that means is this: in the context of a proof-of-work blockchain, if there is an accidental fork, or a deliberate transaction reversal (“double-spend”) attempt, and there are two competing forks of the blockchain, then miners have to choose which one they contribute to.
...
The optimal strategy is to mine on any fork that you can find. Thus, in order to launch a successful attack, an attacker need only overpower all of the altruists who are willing to vote only on the correct chain.
...
However, there is a problem: what motivates signers to sign blocks on only one chain? If the arguments against pure proof of stake are correct, then most rational stake-miners would sign both chains. Hence, in hybrid PoS, if the attacker signs only his chain, and altruists only sign the legitimate chain, and everyone else signs both, then if the attacker can overpower the altruists on the stake front that means that the attacker can overtake the chain with less than a 51% attack on the mining front. If we trust that altruists as a group are more powerful in stake than any attacker, but we don’t trust that too much, then hybrid PoS seems like a reasonable hedge option; however, given the reasoning above, if we want to hybridize one might ask if hybrid PoW + TaPoS might not be the more optimal way to go. For example, one could imagine a system where transactions need to reference recent blocks, and a blockchain’s score is calculated based on proof of work and coin-days-destroyed counts.
He also pressed a very high evaluation to TaPOS, which to my understanding is somehow part of DPOS.
I think what we Bitshares community, especially Stan Larimer gave to the so called "nothing at stake" problem is what we call "Bitshares Social Consensus" -- all chains that have people's "votes" all deserve existence. Let the FREE MARKET judge which chain or which DAC should take over the most, thus the main market volume.
Any thoughts?
-
Bytemaster said several times that automatic delegate firing should occur if the are found to sign 2 different blocks.
However I dont think this is implemented... yet.
This should be sufficient provided it is difficult enough to become delegate. However some problems might arise if these who vote for the misbehaving delegate just vote-in another one.
-
How Do Bitshares DACs Solve The "Nothing At Stake" Problem
Vitalik Buterin wrote an article, On Stake:
https://blog.ethereum.org/2014/07/05/stake/
He wrote:
However, with the naive proof of stake algorithm described above, there is one serious problem: as some Bitcoin developers describe it, “there is nothing at stake”. What that means is this: in the context of a proof-of-work blockchain, if there is an accidental fork, or a deliberate transaction reversal (“double-spend”) attempt, and there are two competing forks of the blockchain, then miners have to choose which one they contribute to.
...
The optimal strategy is to mine on any fork that you can find. Thus, in order to launch a successful attack, an attacker need only overpower all of the altruists who are willing to vote only on the correct chain.
...
However, there is a problem: what motivates signers to sign blocks on only one chain? If the arguments against pure proof of stake are correct, then most rational stake-miners would sign both chains. Hence, in hybrid PoS, if the attacker signs only his chain, and altruists only sign the legitimate chain, and everyone else signs both, then if the attacker can overpower the altruists on the stake front that means that the attacker can overtake the chain with less than a 51% attack on the mining front. If we trust that altruists as a group are more powerful in stake than any attacker, but we don’t trust that too much, then hybrid PoS seems like a reasonable hedge option; however, given the reasoning above, if we want to hybridize one might ask if hybrid PoW + TaPoS might not be the more optimal way to go. For example, one could imagine a system where transactions need to reference recent blocks, and a blockchain’s score is calculated based on proof of work and coin-days-destroyed counts.
He also pressed a very high evaluation to TaPOS, which to my understanding is somehow part of DPOS.
I think what we Bitshares community, especially Stan Larimer gave to the so called "nothing at stake" problem is what we call "Bitshares Social Consensus" -- all chains that have people's "votes" all deserve existence. Let the FREE MARKET judge which chain or which DAC should take over the most, thus the main market volume.
Any thoughts?
I think we should stop calling it the "nothing at stake" problem because the phrase generates confusion. What are the factors of the problem we need to solve? List them.
Then once we agree on and understand those major issues we can find an approach to solving it if it is indeed a problem.
I gave some thought to this particular problem and the conclusion is there is a low probability of it being a successful attack vector. It's of low risk because the consequences of the attack would not be catastrophic because DPoS is set up to minimize the damage of any attack of this sort just by firing the delegates responsible.
And if it were so easy to pull off then other Proof of Stake coins with a higher market cap would face attack.
I think Bitcoin and Litecoin are centralized thus currently among of the most insecure cryptocurrencies. Proof of Work will end up being the cause of the insecurity as it promotes the centralization which ultimately will lead to attacks.
So given a choice I would say Proof of Stake is more secure than Proof of Work even if the "nothing at stake" problem is some theoretically possible attack. So far it has not been attempted or it has been attempted and proved ineffective.
If I'm wrong and someone can explain the "nothing at stake" problem in plain English then I'll give it more thought.
Bytemaster said several times that automatic delegate firing should occur if the are found to sign 2 different blocks.
However I dont think this is implemented... yet.
This should be sufficient provided it is difficult enough to become delegate. However some problems might arise if these who vote for the misbehaving delegate just vote-in another one.
Right. DPoS is self healing and somewhat collusion resistant too. Delegates can be fired and we can optimize for delegates which don't collude or attack the integrity of the network. I think DPoS offers way more flexibility than Proof of Work wit'h it's unelected government of miners. If miners desire they can gain complete and absolute control over Bitcoin and Litecoin over time and there is actual evidence of it happening right now.
If you look at Bitcoin or Litecoin neither are willing to swap out their hashing algorithms despite the fact that there are ASICs. No one gives a good reason why developers are sticking with ASICs and as a security design it really doesn't make any sense. ASICs result in extreme centralization which is very bad for security but I guess because the difficulty numbers look high it has everyone fooled into thinking it's more secure...
Difficulty is not security.
-
no nothing at stake problem because: block production is deterministic / sequential (it is not possible that two delegates find blocks before each of them saw that the other one found one).
Now one delegate could still sign two blocks. But why sould he/she do it? Own answer: To double spend a merchant after one confirmation.
Wouldnt it be possible to punish any delegate that signs two blocks even if there is a fork and that delegate has to decide randomly on one block like a miner would decide randomly? Then 2 confirmations would be enough to be safe if not two delegates collude which would require 3 confirmations to be safe and so on...
https://bitsharestalk.org/index.php?topic=4347.msg84182#msg84182
-
The Nothing At Stake problem assumes certain properties of POS based upon the Peercoin design.
It is impossible for DPOS to produce an alternative longer chain without collusion of 51% of the delegates. With 51% collusion you are back to the 51% attack that all systems are subject to.
In this case the delegates also have something at stake: their job.
So how has DPOS changed the game?
1) "Miners" are now generally public, known individuals rather than anonymous individuals.
2) Secret attacks are no longer possible
3) Alternative chains are not possible
4) In the time it takes Bitcoin to generate 1 confirmation, 60 delegates will have confirmed your transaction.
-
The 'Nothing at Stake' is indeed that people would sign two different blocks at the same time, but the true danger is that people can do this at any time.
For example:
[1] Someone was a delegate.
[2] 12 years from now when the person is no longer a delegate, they decide to attack the network.
[3] They take the current valid chain, and cut off the 12 years of blockchain-history that have passed.
[4] They then tell their computer to build a completely different blockchain-history. Without a proof of work requirement they can do this 'for nothing'
[5] Repeat [3-4] millions of times, to make many similar chains. Without a proof of work requirement they can do this 'for nothing'
[6] Sybil attack the network and try to drag people onto one of them.
PoW clients choose the chain which is longest, but PoS clients must use something else. My understanding is that Mr. L believes that long-run consensus is not a significant concern, and that wallets will be able to find the right chain by themselves without much help and without significant risk.
-
https://bitsharestalk.org/index.php?topic=5464
-
The 'Nothing at Stake' is indeed that people would sign two different blocks at the same time, but the true danger is that people can do this at any time.
For example:
[1] Someone was a delegate.
[2] 12 years from now when the person is no longer a delegate, they decide to attack the network.
[3] They take the current valid chain, and cut off the 12 years of blockchain-history that have passed.
[4] They then tell their computer to build a completely different blockchain-history. Without a proof of work requirement they can do this 'for nothing'
[5] Repeat [3-4] millions of times, to make many similar chains. Without a proof of work requirement they can do this 'for nothing'
[6] Sybil attack the network and try to drag people onto one of them.
PoW clients choose the chain which is longest, but PoS clients must use something else. My understanding is that Mr. L believes that long-run consensus is not a significant concern, and that wallets will be able to find the right chain by themselves without much help and without significant risk.
Nope, this would not work unless they controlled 100% of the stake... or enough stake to vote in a complete new slate of 101 delegates. Their chain would never be longer than the official chain because if they had only 1 delegate slot they could only produce 1% of the blocks. All clients that connected to the "attack network" would see delegate participation rate of 1% and a big red warning bar.
So the only one able to attack the network is the INIT delegates and they could only do this by preventing all transactions that vote them out. A quick sanity check would then reveal that 90% of the genesis stake was "unmoved" and thus be another RED FLAG.
Add a checkpoint at some block after the majority of init delegates have been voted out and you are even protected here.
From a risk profile perspective, you are more likely to lose your private key than be attacked in such a manner.
-
What do you mean when you say "Nope"? This is the long-range NaS as described by everyone I could find who wrote about it.
Which of the 6 steps do you disagree with?
-
What do you mean when you say "Nope"? This is the long-range NaS as described by everyone I could find who wrote about it.
Which of the 6 steps do you disagree with?
Step 4... they tell their computer to build a completely different blockchain history....
Their computer could only produce 1 block every 110 seconds and thus their chain would be 1% the length of the real history. Unless you controlled enough shares to completely change the 101 delegate slate to one you control you will never be able to create a longer chain.
-
Nope, this would not work unless they controlled 100% of the stake... or enough stake to vote in a complete new slate of 101 delegates. Their chain would never be longer than the official chain because if they had only 1 delegate slot they could only produce 1% of the blocks. All clients that connected to the "attack network" would see delegate participation rate of 1% and a big red warning bar.
So the only one able to attack the network is the INIT delegates and they could only do this by preventing all transactions that vote them out. A quick sanity check would then reveal that 90% of the genesis stake was "unmoved" and thus be another RED FLAG.
Add a checkpoint at some block after the majority of init delegates have been voted out and you are even protected here.
From a risk profile perspective, you are more likely to lose your private key than be attacked in such a manner.
Doesn't this also assume that it is unlikely that any previous delegates who have now been removed from their delegate position do not collude to attempt a double-spend attack? For example, say there were 101 non-init delegates active in early August, but they were all replaced by better delegates in late August. Someone who had synchronized with the network in early August and went offline until resynchronizing with the network in September could be vulnerable to an attack by the 101 now fired delegates colluding together, correct? The assumption here is that even though these 101 delegates now have nothing at stake since they have already been fired, they are still unlikely to all collude together to attempt a double-spend attack. I suppose, we could also have the client detect that there are two different equal length chains being offered (assuming the user's internet connection isn't completely compromised by the attacker so that they can actually get the true chain), warn the user he is under attack, and make a suggestion to pick the chain with more transaction activity since it is more likely to be the true chain.
Edit: I also realize the probability that most active delegates are replaced in a short enough time frame that the replacement happens between the time a typical user would resync is very low. I don't think it is a concern in practice. I just want to make the concern explicit to point out why we shouldn't have to really worry about it.
-
Nope, this would not work unless they controlled 100% of the stake... or enough stake to vote in a complete new slate of 101 delegates. Their chain would never be longer than the official chain because if they had only 1 delegate slot they could only produce 1% of the blocks. All clients that connected to the "attack network" would see delegate participation rate of 1% and a big red warning bar.
So the only one able to attack the network is the INIT delegates and they could only do this by preventing all transactions that vote them out. A quick sanity check would then reveal that 90% of the genesis stake was "unmoved" and thus be another RED FLAG.
Add a checkpoint at some block after the majority of init delegates have been voted out and you are even protected here.
From a risk profile perspective, you are more likely to lose your private key than be attacked in such a manner.
Doesn't this also assume that it is unlikely that any previous delegates who have now been removed from their delegate position do not collude to attempt a double-spend attack? For example, say there were 101 non-init delegates active in early August, but they were all replaced by better delegates in late August. Someone who had synchronized with the network in early August and went offline until resynchronizing with the network in September could be vulnerable to an attack by the 101 now fired delegates colluding together, correct? The assumption here is that even though these 101 delegates now have nothing at stake since they have already been fired, they are still unlikely to all collude together to attempt a double-spend attack. I suppose, we could also have the client detect that there are two different equal length chains being offered (assuming the user's internet connection isn't completely compromised by the attacker so that they can actually get the true chain), warn the user he is under attack, and make a suggestion to pick the chain with more transaction activity since it is more likely to be the true chain.
Edit: I also realize the probability that most active delegates are replaced in a short enough time frame that the replacement happens between the time a typical user would resync is very low. I don't think it is a concern in practice. I just want to make the concern explicit to point out why we shouldn't have to really worry about it.
And would those former delegates have been delegates at the same time?
-
And would those former delegates have been delegates at the same time?
Yes, they would all have to have been delegates at the same time in order to create a plausible fake blockchain history from that point forward. Which is why it is so unlikely that you can find a group of 101 delegates that satisfy that requirement and are all willing to collude.
-
And would those former delegates have been delegates at the same time?
Yes, they would all have to have been delegates at the same time in order to create a plausible fake blockchain history from that point forward. Which is why it is so unlikely that you can find a group of 101 delegates that satisfy that requirement and are all willing to collude.
Right. But not all 101, only 52...
-
Right. But not all 101, only 52...
No, you need all 101 (or something close to that), or else you will be unable to make a chain that comes to the present time without having an unusual number of missing blocks. The 51% attack is regarding the percentage of stake you need, which is much more difficult to achieve since it would be very expensive to buy up 51% of the shares in a DAC.
Edit: Actually, the system is even safer than I thought. Even if delegate participation rate is normally 90%, the missing blocks are not all by the same delegate. We can assume that delegates will randomly miss blocks. Now if someone receives a fake blockchain that reaches the present time where the delegate participation rate never dips below 95%, but after some point in time in the blockchain 5 specific delegates always miss blocks when it is their turn, then that is a huge red flag. The system can warn the user that something is suspicious about the blockchain even when 96 former delegates collude together to make a fake blockchain with an average delegate participation rate above 95%!
-
What do you mean when you say "Nope"? This is the long-range NaS as described by everyone I could find who wrote about it.
Which of the 6 steps do you disagree with?
Step 4... they tell their computer to build a completely different blockchain history....
Their computer could only produce 1 block every 110 seconds and thus their chain would be 1% the length of the real history. Unless you controlled enough shares to completely change the 101 delegate slate to one you control you will never be able to create a longer chain.
At t= -12 years, yes this may be the case. But, I assume the protocol has something in place if delegates miss blocks, and so blockchains that contain missed-blocks can continue without the protocol collapsing. As the attacker re-writes history, he will eventually manipulate 'who becomes a delegate' in his fake chains. Once he controls the delegates, he can hit 100% of the blocks for the next 12 years. Because legitimate blocks are sometimes missed accidentally, his chain might be longer after 12 years (although it would have an easily-detectible "era" of 1% delegate-participation).
And this is highly sensitive to the setup. If someone knew certain "old" private keys (key to something that held a lot of BTS funds 12 years ago, or was a delegate 12 years ago), or made certain preparation transactions, it can just get much easier. These are the long run NaS problems, and I'm not sure they can be solved by using protocol rules. PoW is more Physics than it is Computer Science or Game Theory. But perhaps attacks can be made to be prohibitively difficult.
-
How does he manipulate who becomes the delegate? He cannot forge votes
Sent from my SCH-I535 using Tapatalk
-
At t= -12 years, yes this may be the case. But, I assume the protocol has something in place if delegates miss blocks, and so blockchains that contain missed-blocks can continue without the protocol collapsing. As the attacker re-writes history, he will eventually manipulate 'who becomes a delegate' in his fake chains. Once he controls the delegates, he can hit 100% of the blocks for the next 12 years. Because legitimate blocks are sometimes missed accidentally, his chain might be longer after 12 years (although it would have an easily-detectible "era" of 1% delegate-participation).
But delegates have limited powers, so there is a limit to how much history can be re-written. They can only filter out legitimate transactions. They cannot grow a small group of delegates into 100% of delegate control, unless they already had the legitimate stake to pull it off in the first place (but that is a different attack, the so-called 51% attack that all consensus systems suffer from).
Let us instead assume that 98 former delegates, who were all delegates at the same time at t = -1 week, come together to pull off a double-spend attack on some victim. I am assuming that they do not have enough stake available at t = -1 week to vote all of their fake delegates into the 101 active delegate slots. They have to deal with only being able to sign 98% of the blocks in their fake blockchain history. Let us also assume that the victim is synchronizing the blockchain starting from the genesis block on a new computer, and that the victim's internet connection is completely controlled by the attackers. Obviously I am setting up an extreme example here. Now, if the attacker presents the fake blockchain history to the victim, will the victim's client accept it? Since at t = -1 week, 3 delegates all simultaneously started missing all of their blocks until the present (t=0), the client will find this blockchain history extremely suspicious (despite the fact that average delegate participation over this period is 97%) and will warn the user that he is likely under attack. It may be possible that those 3 delegates all suddenly disconnected from the network and even after a week the shareholders of the DAC just haven't bothered to vote them out yet, but it is incredibly unlikely that it is safer to assume the user is under attack. The user can now use out-of-band methods to figure out if he is on the correct chain or not. If it was in fact an unusual event, he can snapshot past that point to let the client continue without complaining.
So that was a pretty extreme example that would not be successful. What about an even more extreme example. What if all 101 former delegates who were all delegates at the same time at t = -1 week, now decide to collude together and do a double-spend attack since they are fired and no longer have anything at stake? In this case, if someone is synchronizing the block chain starting from a time t < -1 week and their internet access is completely compromised, they might accept the fake blockchain and thus be vulnerable to a double-spend attack. But this is an incredibly unlikely situation. You need 101 delegates who used to be active delegates at the same time to collude together to attack a potential victim, AND do a man-in-the-middle attack on the victim's internet connection, AND hope the last time the victim had synchronized with the network was before the first colluding delegate got fired.
-
What do you mean when you say "Nope"? This is the long-range NaS as described by everyone I could find who wrote about it.
Which of the 6 steps do you disagree with?
Step 4... they tell their computer to build a completely different blockchain history....
Their computer could only produce 1 block every 110 seconds and thus their chain would be 1% the length of the real history. Unless you controlled enough shares to completely change the 101 delegate slate to one you control you will never be able to create a longer chain.
At t= -12 years, yes this may be the case. But, I assume the protocol has something in place if delegates miss blocks, and so blockchains that contain missed-blocks can continue without the protocol collapsing. As the attacker re-writes history, he will eventually manipulate 'who becomes a delegate' in his fake chains. Once he controls the delegates, he can hit 100% of the blocks for the next 12 years. Because legitimate blocks are sometimes missed accidentally, his chain might be longer after 12 years (although it would have an easily-detectible "era" of 1% delegate-participation).
And this is highly sensitive to the setup. If someone knew certain "old" private keys (key to something that held a lot of BTS funds 12 years ago, or was a delegate 12 years ago), or made certain preparation transactions, it can just get much easier. These are the long run NaS problems, and I'm not sure they can be solved by using protocol rules. PoW is more Physics than it is Computer Science or Game Theory. But perhaps attacks can be made to be prohibitively difficult.
Actually the protocol does not have any way to regenerate delegates except for the 5% inactivity fee which will slowly remove votes and the corresponding balances over time. It would take a very long time and the attacker would still require a large enough stake to vote themselves in. During this long period of time there would be a lot of missed blocks.
The only time the network cannot "heal" is if the top 101 delegates are all taken out at once.
-
In long range NaS, the attacker has access to many private keys that used to own BTS (some assume 51% stake worth). With this he can control 100% of the delegates, at the cost only of recovering old private keys that are no longer in use. This may cost very little, as old private keys are not worth much to their previous owners, but the attacker can buy them (and check that he is getting what he paid for) and use them to attack the network. Over time, the number-of-old-private-keys increases drastically, as does the stake-of-old-key, the age-of-key, and the potential-attack-damage. So over 50 years or so this might be a problem.
If he cannot ever accumulate 51% worth of old-private-key, (it appears to me based on my current understanding) in dpos he can still eventually control 100% of the delegates with <51% old-stake by selectively broadcasting valid tx and controlling certain few addresses and ex-delegate accounts. For example, the normal network history might have some individuals rise from #107 and #108 up to #97 and #98, displacing my delegate at position #99. If I control the alternative chain, I can instead avoid brodcasting the tx that bumps my delegate.
-
I can see a real trouble looming for DPOS after 500 years…
or was it delegates going to Guantanamo tomorrow?
-
If he cannot ever accumulate 51% worth of old-private-key, (it appears to me based on my current understanding) in dpos he can still eventually control 100% of the delegates with <51% old-stake by selectively broadcasting valid tx and controlling certain few addresses and ex-delegate accounts. For example, the normal network history might have some individuals rise from #107 and #108 up to #97 and #98, displacing my delegate at position #99. If I control the alternative chain, I can instead avoid brodcasting the tx that bumps my delegate.
You need nearly all of the top 101 delegates under your control at the same point in time in the blockchain history in order to continue the fake history in a way that could appear plausibly legitimate to your victim's client. If you do not have nearly all of the top 101 delegates under your control at the same point in time, you cannot continue the history for long enough (without making it obviously apparent that it is an attack) to gain control of all of the top 101 delegates.
Let me explain with an example. Time t = 0 is when the DAC begins building on the genesis block. One year later, at t = 1, we have the following delegate ranking. There are 101 good delegates in the top 101 spots: good-delegate-1, good-delegate-2, ..., good-delegate-101. They each have 20% approval. The next 101 slots are filled by your evil delegates: evil-delegate-1, ..., evil-delegate-101. They each have 2% approval, all from the 2% stake you control. The next 101 slots are filled by 101 other good delegates, good-delegate-102 to good-delegate-202, each with only 1% approval. Over the course of the next year, from t = 1 to t = 2, stakeholders start moving away their votes from good-delegate-1 ... good-delegate-101 to good-delegate-102 ... good-delegate-202. This is a slow process in which one good delegate is replaced by the other good delegate one at a time. In fact, stakeholders vote according to the following peculiar pattern. They first take all of their votes away from good-delegate-k (1 <= k <= 101) and vote for the null slate, allowing one of your evil delegates to briefly get into spot 101. Then, they use that stake to vote for good-delegate-(k+101), who replaces your evil delegate on the active delegate list. At no time do you have more than one of your evil delegates as an active delegate in the true blockchain. Can you fork off of a snapshot of the blockchain between t=1 and t=2 and generate a plausible fake blockchain that gives all of your evil delegates the top 101 slots by cleverly filtering out certain transactions?
The answer is no. You may think that you can just filter out all of the transactions that change their vote from the null slate to good-delegate-(k+101), but keep the transactions that changed the vote from good-delegate-k to the null slate in the first place. If you could do this, you would end up with all of your evil delegates in the top 101 slots with 2% approval, and the rest of the good delegates at lower slots with either 1% approval or less. But you cannot do this, because you did not have nearly all of your evil delegates simultaneously in the top 101 slots at any point in time. The first time you would need to filter out one of these problematic transactions, you would be forced to filter out all of the blocks produced by good delegates after that point (otherwise the hash link would be broken). Now you might think you can just quickly fill in all of the transactions that change the vote to the null slate into one of the blocks produced by your delegate, so that you can have all of your evil delegates take over the next round. Not only would this look incredibly suspicious, but the conditions needed to pull this off are incredibly improbable. In practice, there will be many other transactions that those unvoting transactions depend on. You can't just stuff all of them into one block, you want to disperse them over multiple sequential blocks. However, since you do not control nearly all of the active delegates yet, you need to wait multiple rounds before you can fit all of those prerequisite transactions and the unvoting transactions that finally give you full control of all the delegates. But how many rounds of mostly missed blocks would that result in? It would be highly suspicious behavior that the client could warn user about. But if this is not satisfying enough, there is another measure that can be taken to be extra cautious. We can bring back TaPOS on top of DPOS. The transactions do not need to reference the previous block, they can reference a block well enough in the past that is well establish. The point is that TaPOS would make it impossible to even include those unvoting transactions in your fake blockchain.
In long range NaS, the attacker has access to many private keys that used to own BTS (some assume 51% stake worth). With this he can control 100% of the delegates, at the cost only of recovering old private keys that are no longer in use. This may cost very little, as old private keys are not worth much to their previous owners, but the attacker can buy them (and check that he is getting what he paid for) and use them to attack the network. Over time, the number-of-old-private-keys increases drastically, as does the stake-of-old-key, the age-of-key, and the potential-attack-damage. So over 50 years or so this might be a problem.
I am glad you recognize that even if an attacker was able to get other stakeholder's old private keys it would take many years to get enough (>51%) to create a plausible fake blockchain in order to attempt a double-spend attack. Another approach would be to aim for the private keys of old delegates. Either way, we can pretty much guarantee that users have updated their clients multiple times over this period. The client software needs to at least contain a hash of the genesis block so that it knows it is on the right chain. But every time there is a new version of the client, the developer can easily put in a recent checkpoint (a hash of a recent block) as a sanity check. That checkpoint immediately kills any attempt of attacking with a fake blockchain where the fork point is older than the checkpoint.
I think it's important to mention that having this checkpoint does not make things any more centralized or even require relying on the developer. A full audit of the code (including the checkpoint) is still possible since the auditors have a copy of the legitimate blockchain up to the point of the version upgrade, just like they would have a copy of the legitimate genesis block (or a means of determining whether the genesis block was legitimate) when doing a full audit of the first version of the code. And a regular user is always going to end up relying on other parties to determine if he is running the same program everyone else is running. Some trust is necessary. Bitcoin users need to trust their wallet developers, or trust the auditors who say that a particular version of the wallet software is safe to use (through a signed hash of the executable or source archive).
-
Right. But not all 101, only 52...
No, you need all 101 (or something close to that), or else you will be unable to make a chain that comes to the present time without having an unusual number of missing blocks.
makes sense
-
It is impossible for DPOS to produce an alternative longer chain without collusion of 51% of the delegates. With 51% collusion you are back to the 51% attack that all systems are subject to.
51% of individual delegates!
More individual delegates means more security! Since it will be much tougher to collude for 200 individuals instead of 30 to 100 for example...
PLEASE FIND A WAY to introduce/implement the sweat spot idea... (because to much delegates would of course hurt the network reliability for reasons already explained)
-
It is impossible for DPOS to produce an alternative longer chain without collusion of 51% of the delegates. With 51% collusion you are back to the 51% attack that all systems are subject to.
51% of individual delegates!
More individual delegates means more security! Since it will be much tougher to collude for 200 individuals instead of 30 to 100 for example...
PLEASE FIND A WAY to introduce/implement the sweat spot idea... (because to much delegates would of course hurt the network reliability for reasons already explained)
Not necessarily. It depends on the attacks. For coercion having too many individual delegates who are known would make it a lot easier to find and coerce them. If the delegates are a collective and spread out across multiple jurisdictions then it would take a globalized effort to coerce the collective of delegates. The collective if the technology allows could even share keys or use multi-sig.
Generally though you do want a lot of individual delegates involved because in other ways it does improve security. It's just a matter of what is easier to attack at the time. If for example delegates are facing political and legal attack then having the delegate be a corporation has benefits. Having it be a non-profit has benefits as well.
The idea is that the individuals should be replaceable (like batteries) but only the delegate roles are what matter to the network. The network should survive even if the individuals in those roles are corrupted, arrested, coerced, etc. The network is self healing because those delegates get fired, lessons are learned, and adaptations will take place so the same attack wont happen again.
I think the sweet spot is just the minimum amount of delegates we need to psychologically feel the network is secure. If it's not under attack it might in practice be secure with 5 delegates or less but then it's a matter of convincing a decentralization community that somehow 5 delegates can offer more security than 5 people in control of Bitcoin or Litecoin. In theory if those 5 delegates were collectives of people such as corporations then you might actually be able to do that because the ultimately security rests in the voters who can vote them out for abusing the integrity of the network.
At 101 delegates it's extremely fast. I don't see any demand for changing it to make it faster. It seems like it could scale to Visa type levels but if it required less delegates at that point in time then the shareholders could decide. It's far better than what we have with Bitcoin.
-
How about making the protocol such that a checkpoint is automatically added whenever there are 51 accumulative changes of delegates ? No centralization, and now 100% safe.
-
How about making the protocol such that a checkpoint is automatically added whenever there are 51 accumulative changes of delegates ? No centralization, and now 100% safe.
51 delegate signatures *is* a checkpoint. Adding a "checkpoint" at the protocol level would just be cosmetic, it has the same effect.
Having a process for changing the client to have client-side checkpoints is what you need to have "real" checkpoints.
-
How about making the protocol such that a checkpoint is automatically added whenever there are 51 accumulative changes of delegates ? No centralization, and now 100% safe.
51 delegate signatures *is* a checkpoint. Adding a "checkpoint" at the protocol level would just be cosmetic, it has the same effect.
Having a process for changing the client to have client-side checkpoints is what you need to have "real" checkpoints.
Right, client-side checkpoint.