Delegated Proof of Stake (DPOS) White Paper

[sudo]

When designing a DPOS you have to assume that at some point the delegates may decide to act together and coordinate in their own interest and misrepresent information. Are there mechanisms in place to prevent that from happening?

Sent from my iPhone using Tapatalk

Assuming 51% of the delegates decide to collude they could block transactions just like a 51% in bitcoin.   However, they could not sign alternative blocks without getting fired.   If the average shareholder elects people that will collude to harm the network then the network will end up getting hard-forked and continue with new delegates... not pleasant but not the end of the world and certainly much better than Bitcoin mining pools colluding.   

If less than 51% are colluding they will get fired for signing false blocks and would certainly get caught.   

Light weight clients could query multiple delegates which are unlikely to collude to defraud them... this is a similar principle to Ripple.   

As the delegates have a stake in the network, an income stream, and their ability to retain control after attempting to harm the network is near 0 I don't see this as a legitimate threat.

Once  delegates do evil,is there  any other punishment  besides fire? Such as destroy certain amount bts of these bad delegates?

[bitmeat]

The cost of doing a digital signature is practically free. There is no way this will need a top notch computer. That's the whole point - delegates put money upfront to reserve their spot, sort of like a license to print money haha but there are checks and balances that if they do something nefarious they would lose the license and the money they put up.


Sent from my iPhone using Tapatalk

[cob]

Perhaps their income stream could be locked for a certain length of time sufficient enough to encourage good behavior. Like what they get paid is actually payable within the next year in chunks. Just a thought.

Cool idea. As long as it's not too long. Since there might be ups and downs in the market. Also might be costly to run a top notch Delegate computer and bills might need to be paid. Nothing insane like ASICs of course.
I'm guessing the payment would be withheld just long enough to make sure no collusion happened.

[bitmeat]

Perhaps their income stream could be locked for a certain length of time sufficient enough to encourage good behavior. Like what they get paid is actually payable within the next year in chunks. Just a thought.


Sent from my iPhone using Tapatalk

[bytemaster]

When designing a DPOS you have to assume that at some point the delegates may decide to act together and coordinate in their own interest and misrepresent information. Are there mechanisms in place to prevent that from happening?

Sent from my iPhone using Tapatalk

Assuming 51% of the delegates decide to collude they could block transactions just like a 51% in bitcoin.   However, they could not sign alternative blocks without getting fired.   If the average shareholder elects people that will collude to harm the network then the network will end up getting hard-forked and continue with new delegates... not pleasant but not the end of the world and certainly much better than Bitcoin mining pools colluding.   

If less than 51% are colluding they will get fired for signing false blocks and would certainly get caught.   

Light weight clients could query multiple delegates which are unlikely to collude to defraud them... this is a similar principle to Ripple.   

As the delegates have a stake in the network, an income stream, and their ability to retain control after attempting to harm the network is near 0 I don't see this as a legitimate threat.

[bytemaster]

Not sure there is a much better one, but making number of delegates odd, seems like an ad-hoc bandaid solution to a fundamental problem.


Sent from my iPhone using Tapatalk

Being odd only handles a single, rare, corner case and is not a key feature or bandaid.   It would probably work just fine being even.  We only recognized this corner case after much thought about the edge conditions of our algorithm.

[bitmeat]

When designing a DPOS you have to assume that at some point the delegates may decide to act together and coordinate in their own interest and misrepresent information. Are there mechanisms in place to prevent that from happening?


Sent from my iPhone using Tapatalk

[bitmeat]

Not sure there is a much better one, but making number of delegates odd, seems like an ad-hoc bandaid solution to a fundamental problem.


Sent from my iPhone using Tapatalk

[tonyk]

Quite possibly I am missing significant piece of the puzzle here but:
Do shareholders broadcast their vote through delegates only? (I was under the impression that it is done through any active/online wallet/node, no matter if they are delegates or not?)
If my understanding is correct, the # of initial delegates *working* on any of the now competing forks, will be a factor, but not the deciding factor which fork survives. (In that regards you can choose # of delegates not divisible by 2,3 and 5, just for a good measure). Far more important will be fast, organize action of significant part of the shareholders – in that regard single-minded 25% shareholder (group of shareholders), will be the likely winners even if they chose to support the fork with let say 1/3 of the initial delegates

[bytemaster]

'This means that the fork is ultimately resolved by how the shareholders are divided by the network split rather than just how the delegates are divided.'

How are the shareholders divided?
 Are they (the shareholders) actually divided?  or only their vote/s is divided.

Their ability to change their vote is divided by their ability to broadcast to the network.

[tonyk]

'This means that the fork is ultimately resolved by how the shareholders are divided by the network split rather than just how the delegates are divided.'

How are the shareholders divided?
 Are they (the shareholders) actually divided?  or only their vote/s is divided.

[bytemaster]

Recent update... the number of delegates must be a ODD number to prevent the potential of a chain split of equal length.     We had discussed making the number of delegates PRIME, but this seems to be an unnecessary considering a it does not prevent a 3-way split from potentially forming two equal length chains. 

At every time interval (30 sec) exactly one block can be produced (or not produced).   If the network splits this means that two chains with opposite holes will be produced until the missing delegates are fired.   Assuming both sides of the fork replace their delegates at an equal rate then the chain that started out with the most delegates will always have the most blocks and thus be the best.   

If you get a chain fork that lasts for a prolonged period of time then which ever chain is most effective at keeping delegates online will ultimately win.   To be effective at this will require that the delegates that were disconnected be replaced rapidly; however, to replace them requires shareholders to switch votes or to vote against them.   This means that the fork is ultimately resolved by how the shareholders are divided by the network split rather than just how the delegates are divided.   

What will likely happen in the event of such a split is that all shareholders will become aware of the split immediately and also know which side of the split they are on.  Many delegates can immediately detect that they are on a minority fork and could choose to let the minority fork die by voluntarily not producing blocks for it.   Only in the event of hostile delegates would the minority delegates & shareholders attempt to 'make a run for it'... 

Conclusion: having an ODD number of delegates makes it easy to identify a minority fork and the shareholders and delegates will act accordingly. 

There is one last 'far-out-there' attack where the network is divided into 3 or more pieces less than 50%... in this case the delegates would have to stay online producing blocks until they could confirm that their 3rd is the largest 3rd.  If they are in the smallest 3rd then they should stop producing blocks to let that third die.

These corner cases are all ultimately resolved by the longest-chain standard and it is inconceivable to think that a consensus would not force once fork or another to win out.

[CLains]

Instead of plotting a reply just videocall AnonyMint one evening and press record - he seems lonely.

[werneo]

Bitcoin "has not solved the Byzantine Generals Problem... it just defined a rule set for consensus  that allows anyone with money to control the network and once controlled there are no alternatives."

BING, BADDA BOOM!

https://bitcointalk.org/index.php?topic=558316.msg6577007#msg6577007  *edited with correct link.

[bytemaster]

Very interesting thread over there....