Delegated Proof of Stake (DPOS) White Paper

[MolonLabe]

You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.

Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.

How does a node which just connected 10 minutes ago know which of the two realities is 'alternate'?

If you go all the way back to the genesis block and have 10% in the genesis block balance...  you will never be able to produce a chain more than 1/10 the length of the public chain.  It just is not possible. 

Remember: a block is not produced every 30 seconds unless all delegates are on line.  If a delegate is not on line to produce a block in that timeslot the time slot is skipped and that chain is forever one block shorter than it could have been. 

Only at first. Eventually I am producing a block every 30 seconds with all the delegates I control. In my alternate reality I am, temporarily, only broadcasting the transactions which allow my delegates to take over. Don't the transactions elect delegates? And everyone is fired after one round for failing to produce a block, anyway.

This would result in a permanently shorter blockchain, though, by (I assume 100 dels and I control 4) 96. However, could I not continue to build this chain, waiting for a cumulative total of 97 blocks to be missed (for one reason or another)? My chain could include the exact same transactions, such that when I substitute it for the existing chain people don't notice (except the delegates, who are are fired immediately). Even if this takes months, it would be worth doing. Eventually 97 blocks will be missed somewhere. Then I will have the longest chain?

Let me also ask this: What if I'm 8th and 9th in line, person 7 submits their block, but I lie and claim that person 7 didn't submit a block. I sign block 8 on top of block 6, then I sign block 9 on top of block 8. What does person 10 decide to do? My chain is now longer. Does person 10 fire person 7? For your sake I hope not, but I don't see how person 10 intends to proceed. What if I also control person 11 (but no others, only those 3)? The reverse of this attack is to selfish-mine two blocks in a row, or ddos a delegate to stop him from learning of a block in time. Surely one of these two attacks must hurt, if the other does not.

[bytemaster]

2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.

This is not possible, someone with a minority of shares cannot elect 100 delegates.  All shares are voting for someone at some time.  You can change your vote, but not create new votes.   End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.

I don't have a minority, I have all the votes, don't I?

You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.

Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.

If you go all the way back to the genesis block and have 10% in the genesis block balance...  you will never be able to produce a chain more than 1/10 the length of the public chain.  It just is not possible. 

Remember: a block is not produced every 30 seconds unless all delegates are on line.  If a delegate is not on line to produce a block in that timeslot the time slot is skipped and that chain is forever one block shorter than it could have been. 

 

[JoeyD]

2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.

This is not possible, someone with a minority of shares cannot elect 100 delegates.  All shares are voting for someone at some time.  You can change your vote, but not create new votes.   End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.

I don't have a minority, I have all the votes, don't I?

You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.

Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.

[MolonLabe]

2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.

This is not possible, someone with a minority of shares cannot elect 100 delegates.  All shares are voting for someone at some time.  You can change your vote, but not create new votes.   End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.

I don't have a minority, I have all the votes, don't I?

[bytemaster]

2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.

This is not possible, someone with a minority of shares cannot elect 100 delegates.  All shares are voting for someone at some time.  You can change your vote, but not create new votes.   End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.

[MolonLabe]

Let me try again. Same basic idea.

1] You owned a large number of coins at some time in address A, and have 2 or 3 delegates in a row, but have since sold the coins.
2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
4] Reconstruct most of the rest of the transaction history, optionally including "sending the large number of coins from step 1 where they really went in real life". You control 100% of the delegates, and can see the real chain, so this is trivial. Rebuild reality up to the present day.
5] Repeat 2-4 1000 times with different delegate public keys, so all 1000 fake + 1 real chains look almost the same, but have different delegate groups.
6] Release the 1000 chains and wait for one of them to stick, using a Sybil attack (new nodes don't know which chain is real). You have now made yourself 100% of the delegates and can double spend as you wish.

[bytemaster]

The attack only works if you buy 51% of the delegates because regardless of how much computational power you have you can only produce one block per delegate per round (a round is where every delegate produces a block).   

No, I am saying you have a few delegates in a row, and attack within a single round.

Lastly, once you did reveal your secret chain (or if it were accidentally discovered) evidence that you signed two blocks with the same timestamp will get you fired from both chains.

I know.

Conclusion: this attack is just the 51% attack carried out with leverage.   However, it has one other problem.  The main chain ignores all forks older than a certain date provided you have the majority of delegates producing blocks on your fork.   The secret chain wouldn't be accepted even if it were 'longer'. 

The whitepaper says:
2.4 Resolving Chain Forks
Like proof of work and other proof of stake systems, the best block chain is the longest valid chain.

But, how does the the software know which chain is valid? If two blocks are signed, the delegate is fired, but which block succeeds? I assume the NEXT delegate (which I also control) will decide, that is how I double spend.

A round is all delegates producing one block (approximately).   A transaction isn't confirmed until 51% of the delegates have produced a block after it.

If you have N delegates in a row then you can produce N blocks (or not)... the delegate at N+1 (GOOD_GUY) will build off of the longest chain he has seen, which if you kept your attack chain secret would be a block HEAD-N.   If you made it public he would build off of your blocks.   

Now you release your secret chain and invalidate GOOD_GUYs block because the network would switch over to your chain. 

So to attack the network requires not broadcasting your secret chain and having a large number of sequential delegates in a row.   Fortunately, the potential for this attack to exist is calculate-able based upon the data received by each client.   If I have missed the last N blocks, then I must wait until I have received 2N valid blocks after the gap. 

At 99 delegates and 30 second block interval you will have complete confirmation in 25 minutes.  If no delegates have missed a block then it will be impossible for someone to produce a longer chain and you have complete confirmation in 30 seconds.

[liondani]

Would it be a good idea to "fire" every X time the last y (even number) delegates (with the lowest votes)  from the 99 first delegates even if they have a good reputation so the other delegates on the list (after the 99 first) have the chance to proof they can make also a very good job and collect more votes after they proove it.The same time everybody on the  list compete each other to give the best results (having excellent equipmment etc.) so they try to be as higher on the list as possible ... Could it be the case that the first 1-2 years nobody get fired because they are all "trustfull" (until they proove the opposite) and when we really need new "realy" trustfull delegates we don't find them anymore because they don't are anymore on the waiting list? Maybe my suggestion is worthless because I don't understand the concept verry well... at least I am trying to help 

This is an interesting concept.  Effectively all you are doing is increasing the number of delegates and forcing the lower delegates to 'take turns'.

What if the number of the effective delegates is a % of something that has to do with the "chain growth"/market cap/average number of transactions per day for the last x months ? I mean in the begining the 99 delegates will be more than enough.But after 3 years if we make the hypothesis that the marketcap for DPOS-PTS2 is in the 5 top places I would personally be not comfortable with 99 delegates... When I think 99 delegates take the fees for million's of transactions it seems centralized in my mind... to many power/"money" to a few delegates...So it would be reasonable the odd number of delegates to change proportional to maybe "average transactions" (per day) or "average fee value" etc. combined with my first proposal to give the change to more delegates to participate...

[MolonLabe]

The attack only works if you buy 51% of the delegates because regardless of how much computational power you have you can only produce one block per delegate per round (a round is where every delegate produces a block).   

No, I am saying you have a few delegates in a row, and attack within a single round.

Lastly, once you did reveal your secret chain (or if it were accidentally discovered) evidence that you signed two blocks with the same timestamp will get you fired from both chains.

I know.

Conclusion: this attack is just the 51% attack carried out with leverage.   However, it has one other problem.  The main chain ignores all forks older than a certain date provided you have the majority of delegates producing blocks on your fork.   The secret chain wouldn't be accepted even if it were 'longer'. 

The whitepaper says:
2.4 Resolving Chain Forks
Like proof of work and other proof of stake systems, the best block chain is the longest valid chain.

But, how does the the software know which chain is valid? If two blocks are signed, the delegate is fired, but which block succeeds? I assume the NEXT delegate (which I also control) will decide, that is how I double spend.

[bytemaster]

I also changed the implementation to only re-rank the delegates once per round where a around is N blocks where N == the number of active delegates.

[bytemaster]

Wouldn't it make sense to lower the number of delegates at the beginning when there are probably just a few candidates that are known and can be trusted. When the thing gets as bigger and more people know about it we will have more trustworthy people with real world identities...

Any opinion on this bm?

A delegate does not equal an individual (networks are ignorant of the the concept of individuals).   So it is entirely possible to have 1000 delegates controlled by 7 trusted individuals.   The key is to set the threshold for allowing someone to become a delegate and to moderate this with confirmation time.    Anyone who is unable to secure 1% or so of the support of the shareholders is likely not a good candidate.   However, requiring 5% may be too much. 

Reducing the number of delegates helps to increase the pay-per-delegate which increases the competition to be delegates and thus the quality of service.  There is probably a balance between too many and too few.

[Amazon]

Wouldn't it make sense to lower the number of delegates at the beginning when there are probably just a few candidates that are known and can be trusted. When the thing gets as bigger and more people know about it we will have more trustworthy people with real world identities...

Any opinion on this bm?

I think we should set the rules fixed and hard coded from the beginning

[santaclause102]

Wouldn't it make sense to lower the number of delegates at the beginning when there are probably just a few candidates that are known and can be trusted. When the thing gets as bigger and more people know about it we will have more trustworthy people with real world identities...

Any opinion on this bm?

[bytemaster]

I'm confused about something.

Here's what I'm imagining:

Phase 1: Establish Large Stake
a] Borrow 1 million USD
b] Purchase 1 million USD's worth of BTS (or 4% of the total or whatever).
c] Send these transactions to yourself a few times, using these votes to appoint different versions of yourself as a few delegates in a row. Play by the rules for now, including saving up as much coin age as possible.
d] Sell BTS for ~1 million, right as your delegates are in a row (you may have some profit or loss here).
e] Repay your loan.

Phase 2: Build Fake Chains
a] Enter a VM/Supercomputing environment where you can easily do many calculations per second.
b] Take the current blockchain from point (1.d), where you have a few delegates in a row.
c] Using the existing 'real' transaction history, build several thousand parallel chains, one with the 1d sale transaction (which is broadcast), but all others without (which are private).
d] When the last delegate-controlled-by-you is up, proceed to Phase 3.

Phase 3: Profit
a] Broadcast the fake chains, and have your last delegate sign them all quickly (you won't even have to validate, as you know your own chains inside the VM). The thousand attack-chains are now the longest, but none include the 1c sale transaction. Have your delegate refuse to sign the 'real' chain (although you can claim he just 'did not get to it' in time with so many other chains to sign).
b] The next delegate will pick the longest chain (the attack chain) and sign it.
c] One or all of your delegates will be fired (or, possibly, the average user will never notice that anything happened, and none will be fired).
d] In a few blocks, double-spend-sell BTS in step 1d for 1 million.
e] Free million!


What are the problems with this?

Step 1:  buy a large amount of BTS with borrowed money
Step 2:  appoint yourself to be a delegate
Step 3:  once delegate, build a large number of fake chains in secret...
Step 4:  sell a large amount of BTS
Step 5:  reveal your fake chain.

The attack only works if you buy 51% of the delegates because regardless of how much computational power you have you can only produce one block per delegate per round (a round is where every delegate produces a block).   The time stamps on the blocks are deterministic and always incrementing by the block interval.   The result is that your secret chain would only be able to produce 4% of the blocks that the public chain was producing and thus would be much shorter.  You wouldn't even be able to vote other delegates out or do anything in secret that would allow you to produce blocks faster.   

The only way for your secret chain to get longer is to produce blocks with timestamps in the future, but those blocks would be rejected by all peers. 

Lastly, once you did reveal your secret chain (or if it were accidentally discovered) evidence that you signed two blocks with the same timestamp will get you fired from both chains.

Conclusion: this attack is just the 51% attack carried out with leverage.   However, it has one other problem.  The main chain ignores all forks older than a certain date provided you have the majority of delegates producing blocks on your fork.   The secret chain wouldn't be accepted even if it were 'longer'. 

[bytemaster]

Would it be a good idea to "fire" every X time the last y (even number) delegates (with the lowest votes)  from the 99 first delegates even if they have a good reputation so the other delegates on the list (after the 99 first) have the chance to proof they can make also a very good job and collect more votes after they proove it.The same time everybody on the  list compete each other to give the best results (having excellent equipmment etc.) so they try to be as higher on the list as possible ... Could it be the case that the first 1-2 years nobody get fired because they are all "trustfull" (until they proove the opposite) and when we really need new "realy" trustfull delegates we don't find them anymore because they don't are anymore on the waiting list? Maybe my suggestion is worthless because I don't understand the concept verry well... at least I am trying to help 

This is an interesting concept.  Effectively all you are doing is increasing the number of delegates and forcing the lower delegates to 'take turns'.