Delegated Proof of Stake (DPOS) White Paper

[bytemaster]

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

This is already how it is, you can split your stake however you like.

There is a qualitative difference between:

1 BTS supports delegate 1
1 BTS supports delegate 2
1 BTS supports delegate 3
1 BTS supports delegate 4
1 BTS supports delegate 5

compared to:
5 BTS supports delegates 1,2,3,4 & 5

I hope you can see the difference here.

It is MUCH easier under the current system for a person with a big stake to vote themselves to be a delegate without appealing for broad community support.
Under my proposal it is possible for a delegate to show that over 50% of stake supports their position as delegate.  Under current proposal this is not possible.
Current proposal appears to me to make buying votes possible.  My proposal I don't believe it is possible.
Downvoting under the current system requires people to remove their support for their desired delegates in order to downvote.  Your client seems like it has to do some complicated analysis to constantly monitor which of your liked delegates need support and which don't.  Why not just allow people to state who they want as their delegates and express that will all their stake?

A key part of our design was to make voting for delegates a low-overhead as possible.  Your proposal would require every transaction to update N delegates where N is unbounded. 

In reality there is no difference between 1 BTS supports 1-5 and 5 BTS supports 1,2,3,4 & 5 because all you did was perform a constant multiplier on the vote.

[Agent86]

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

This is already how it is, you can split your stake however you like.

There is a qualitative difference between:

1 BTS supports delegate 1
1 BTS supports delegate 2
1 BTS supports delegate 3
1 BTS supports delegate 4
1 BTS supports delegate 5

compared to:
5 BTS supports delegates 1,2,3,4 & 5

I hope you can see the difference here.

It is MUCH easier under the current system for a person with a big stake to vote themselves to be a delegate without appealing for broad community support.
Under my proposal it is possible for a delegate to show that over 50% of stake supports their position as delegate.  Under current proposal this is not possible.
Current proposal appears to me to make buying votes possible.  My proposal I don't believe it is possible.
Downvoting under the current system requires people to remove their support for their desired delegates in order to downvote.  Your client seems like it has to do some complicated analysis to constantly monitor which of your liked delegates need support and which don't.  Why not just allow people to state who they want as their delegates and express that will all their stake?

[Agent86]

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

 

but with well studied restrictions like...
a)vote for X delegates max.
b)my first voted delegate takes Y points, the second Y-1 points .... etc...
c)make your suggestions...

I think there is diminishing returns in making things more complicated.
You can think of it as a Yes/No question:  Do you want this person to be a delegate?  Do you trust this person as a delegate?
The answer to this question is likely "yes" for more than one delegate.

If you especially like and want to support a particular community member you can choose to support them to have more than one delegate but you would never want one person to control all of them.

[toast]

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

This is already how it is, you can split your stake however you like.

[liondani]

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

 

but with well studied restrictions like...
a)vote for X delegates max.
b)my first voted delegate takes Y points, the second Y-1 points .... etc...
c)make your suggestions...

[Agent86]

I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…

keep them delegates of yours below 50%, never post before logging off from the main account…

Ok, I guess you're saying I'm a sockpuppet?  Sorry I missed it; not the case.

[tonyk]

You sound like the most self-doubtful person I have ever met (other than myself).
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…

I guess I'm trying to talk more broadly about what method of electing delegates will be most fair, hardest to game etc.  It seems like there may be a lot of people that want to be delegates especially if they are well compensated.

As you may have already noticed, I am one of the most stupid people on this forum… but I do not think that there are more than 25-30 people (you must know the exact number anyway) ready and willing to run BTS TX delegate nodes.
If BTS X is success the number will be much bigger and ever improving… no matter the formula though you will be able to run as many of those delegates as you choose. You will have the necessary trades to keep your delegates in the top 100 just because the market will need a magic hand to keep parity for months and months… So as I said – do not get too greedy, keep them delegates of yours below 50%, never post before logging off from the main account… and on aside note that I already gave you - sell BTC at $680 if/whenever the market touches that price.
TK

[Agent86]

You sound like the most self-doubtful person I have ever met (other than myself).
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…

I guess I'm trying to talk more broadly about what method of electing delegates will be most fair, hardest to game etc.  It seems like there may be a lot of people that want to be delegates especially if they are well compensated.

[tonyk]

I feel like the current delegate voting system could use "refinement".

The purpose of voting is to try to accurately reflect the views of the stakeholders.  I don't think this is sufficiently accomplished in the current proposal.

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

In the current system, in order to "downvote" someone who does something like excludes transactions, you unfortunately must withdraw your support for someone you want to support in order to cast your downvote.  It's also a strange balancing act where the vote you would like to cast is dependent on the votes cast by others.  If a candidate has all the votes they need, you need to go find another candidate to vote for.  If a candidate is going to be downvoted out of being a delegate by others, there's no need for you to use your stake to downvote.

I propose you just vote for any delegate you support.  Delegates are selected on how broad their appeal is to stakeholders.  There could be a minimum of 97 delegates but an uncapped maximum where everyone who has over 50% community support is automatically a delegate.  This seems fair to me.  It would be great if all our delegates had over 50% community support backing them (also gets rid of "magic" number of delegates).

If a delegate messes up it's no problem to withdraw your support for that delegate without affecting your support of others.

Delegates could also see if they have lots of community support or if they are "on thin ice".  If a delegate had a ton of community support e.g. 95%, It might be rational for them to decide to run an additional delegate and they could have 2 delegates.  I might be happy to vote for a trusted core developer to run multiple delegates, say 5 delegates, but at some point I'm not willing to vote for their 6th delegate because I think that is starting to get greedy.  So people with lots of community support can gauge that support and potentially run more delegates than someone with less community support.

You sound like the most self-doubtful person I have ever met (other than myself).
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…

[Agent86]

I feel like the current delegate voting system could use "refinement".

The purpose of voting is to try to accurately reflect the views of the stakeholders.  I don't think this is sufficiently accomplished in the current proposal.

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

In the current system, in order to "downvote" someone who does something like excludes transactions, you unfortunately must withdraw your support for someone you want to support in order to cast your downvote.  It's also a strange balancing act where the vote you would like to cast is dependent on the votes cast by others.  If a candidate has all the votes they need, you need to go find another candidate to vote for.  If a candidate is going to be downvoted out of being a delegate by others, there's no need for you to use your stake to downvote.

I propose you just vote for any delegate you support.  Delegates are selected on how broad their appeal is to stakeholders.  There could be a minimum of 97 delegates but an uncapped maximum where everyone who has over 50% community support is automatically a delegate.  This seems fair to me.  It would be great if all our delegates had over 50% community support backing them (also gets rid of "magic" number of delegates).

If a delegate messes up it's no problem to withdraw your support for that delegate without affecting your support of others.

Delegates could also see if they have lots of community support or if they are "on thin ice".  If a delegate had a ton of community support e.g. 95%, It might be rational for them to decide to run an additional delegate and they could have 2 delegates.  I might be happy to vote for a trusted core developer to run multiple delegates, say 5 delegates, but at some point I'm not willing to vote for their 6th delegate because I think that is starting to get greedy.  So people with lots of community support can gauge that support and potentially run more delegates than someone with less community support.

[HackFisher]

I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot,  English is not my native language , I hope I can been understood.
1.   The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2.   Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot.  We also can set the confirm time of this block is longer than others, maybe need  all delegates honored.
3.   Each block after this snapshot include the status if honor this snapshot.
4.   Each translation include the status if honor this snapshot
5.   if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot.  The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot ,  if  select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6.    If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant,   if N equal  100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume  +  volume of 34 days translation. It doesn’t increase as time passing  .

Solid idea.  The challenge is in defining what to include in the state and how to download it.   With DPOS we have some options not available to other systems, but it is still challenging.

to download the chain , for a new node ,first get the current block No. Nc,  ,  then download the block from Nc-(Nc Mod N) , and check the comfirm status of this snapshot that every was included in blocks  , if this snapshot is comfirmed by N blocks , the client don`t need to download the blocks before this snapshot ,otherwise, downland the prevoius N blocks .

I'm thinking that is quite similar to checkpoint, only the difference is that this checkpoint is checked by delegates (Aka, representing the shareholders)?

[BTSdac]

I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot,  English is not my native language , I hope I can been understood.
1.   The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2.   Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot.  We also can set the confirm time of this block is longer than others, maybe need  all delegates honored.
3.   Each block after this snapshot include the status if honor this snapshot.
4.   Each translation include the status if honor this snapshot
5.   if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot.  The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot ,  if  select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6.    If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant,   if N equal  100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume  +  volume of 34 days translation. It doesn’t increase as time passing  .

Solid idea.  The challenge is in defining what to include in the state and how to download it.   With DPOS we have some options not available to other systems, but it is still challenging.

to download the chain , for a new node ,first get the current block No. Nc,  ,  then download the block from Nc-(Nc Mod N) , and check the comfirm status of this snapshot that every was included in blocks  , if this snapshot is comfirmed by N blocks , the client don`t need to download the blocks before this snapshot ,otherwise, downland the prevoius N blocks .

[liondani]

6.    If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant,   if N equal  100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume  +  volume of 34 days translation. It doesn’t increase as time passing  .

 

[bytemaster]

I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot,  English is not my native language , I hope I can been understood.
1.   The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2.   Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot.  We also can set the confirm time of this block is longer than others, maybe need  all delegates honored.
3.   Each block after this snapshot include the status if honor this snapshot.
4.   Each translation include the status if honor this snapshot
5.   if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot.  The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot ,  if  select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6.    If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant,   if N equal  100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume  +  volume of 34 days translation. It doesn’t increase as time passing  .

Solid idea.  The challenge is in defining what to include in the state and how to download it.   With DPOS we have some options not available to other systems, but it is still challenging.

[BTSdac]

I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot,  English is not my native language , I hope I can been understood.
1.   The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2.   Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot.  We also can set the confirm time of this block is longer than others, maybe need  all delegates honored.
3.   Each block after this snapshot include the status if honor this snapshot.
4.   Each translation include the status if honor this snapshot
5.   if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot.  The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot ,  if  select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6.    If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant,   if N equal  100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume  +  volume of 34 days translation. It doesn’t increase as time passing  .