Delegated Proof of Stake (DPOS) White Paper

[bytemaster]

Would it make things more robust if there was a delay between the time that a delegate got the number of votes needed and the time they actually became an active delegate?  The reason I ask is we have the ability to vote against a delegate, but if whenever we try to vote against a delegate, the voters for that delegate just quickly all switch to another delegate (controlled by the same person) the people trying to vote against them might have to give up because they can't keep track of trying to switch their votes fast enough to keep that person from being a delegate?  I was also thinking if you register a delegate but fall below some minimum threshold of support for that delegate for a certain number of blocks, the delegate becomes inactive and is subject to the waiting period before it can become an active delegate after getting votes.  This way people will have a much shorter list of active delegates and delegates with at least minimum support to consider when deciding to vote for or against them and they can't be surprised by a delegate coming out of left field.

This particular attack would only matter if the attacker had 51% of the delegates.   They get in power and the only thing they can do is 'not produce a block' or 'not include a transaction' and thus I do not see what they could gain.

[toast]

Would it make things more robust if there was a delay between the time that a delegate got the number of votes needed and the time they actually became an active delegate?  The reason I ask is we have the ability to vote against a delegate, but if whenever we try to vote against a delegate, the voters for that delegate just quickly all switch to another delegate (controlled by the same person) the people trying to vote against them might have to give up because they can't keep track of trying to switch their votes fast enough to keep that person from being a delegate?  I was also thinking if you register a delegate but fall below some minimum threshold of support for that delegate for a certain number of blocks, the delegate becomes inactive and is subject to the waiting period before it can become an active delegate after getting votes.  This way people will have a much shorter list of active delegates and delegates with at least minimum support to consider when deciding to vote for or against them and they can't be surprised by a delegate coming out of left field.

Our protection against this is that the registration fee is equal to about two weeks' worth of block production, so this attack will drain their stake. Each delegate's stats are visible in the client and eventually you will have the option to let your client auto-downvote misbehaving delegates. While they attack, all they can do is exclude transactions and increase average confirmation time.

Also for down the road, I agree with others that "100 delegates" strikes people as a magic/arbitrary number and maybe we can explore what are the pros and cons of more or less delegates, What would be involved with changing it later... hard fork?  Could it be dynamic? or have shareholders also vote for the total number of delegates?

Hard fork is always possible, as is dynamic adjustment. The dynamic option is worth discussing in depth as its own topic.
Side note, our actual magic number is 97 because it is prime.

[Agent86]

Would it make things more robust if there was a delay between the time that a delegate got the number of votes needed and the time they actually became an active delegate?  The reason I ask is we have the ability to vote against a delegate, but if whenever we try to vote against a delegate, the voters for that delegate just quickly all switch to another delegate (controlled by the same person) the people trying to vote against them might have to give up because they can't keep track of trying to switch their votes fast enough to keep that person from being a delegate?  I was also thinking if you register a delegate but fall below some minimum threshold of support for that delegate for a certain number of blocks, the delegate becomes inactive and is subject to the waiting period before it can become an active delegate after getting votes.  This way people will have a much shorter list of active delegates and delegates with at least minimum support to consider when deciding to vote for or against them and they can't be surprised by a delegate coming out of left field.

I doubt early on we'll have much need to vote against delegates anyway, but this is just something that occurred to me.

Also for down the road, I agree with others that "100 delegates" strikes people as a magic/arbitrary number and maybe we can explore what are the pros and cons of more or less delegates, What would be involved with changing it later... hard fork?  Could it be dynamic? or have shareholders also vote for the total number of delegates?

[toast]

I collect old accounts totaling >50%

You are right, I assumed this wasn't possible.

Two points:
* Remember it has to be >50% stake within a particular 1 hour window. I think it'd be *more* difficult to do this than getting 50% of the current stake. "Buying all old keys with nonzero balance between 12 and 1am on DD-MM-YYYY. Don't tell any delegates or else they'll add a checkpoint!"

* Even so, this would only affect nodes that have never been online and are trying to sync for the first time, since we do not look back farther than a few rounds of full participation when considering forks.

[MolonLabe]

In that case, how does this solve the nothing-at-stake problem?

I collect old accounts totaling >50%, and build a new chain with a different vote/delegate history. I control >50% of the coins/votes at all times, and can build a chain which, at the very end, looks almost exactly like the real chain.

[toast]

Each deposit ("unspent transaction output") counts for the votes.
In every block, 100% of the stake is casting their vote, whether there is a transaction that moved it or not.

[toast]

Assume there are 1234 votes.

I control 10%, or 123 of them.

However, I also control the delegate, who can exclude transfers. So I exclude all the votes that aren't mine.

Votes cast: 123, Votes controlled by me: 123

I control 123/123 = 100% of the votes.

The remaining 1234 - 123 remain on their original vote. They don't have to make a transaction every block to keep their votes, they have to make a transaction to *move* their votes.

So you moved 123 / 1234 = 10% of the votes.

[MolonLabe]

Assume there are 1234 votes.

I control 10%, or 123 of them.

However, I also control the delegate, who can exclude transfers. So I exclude all the votes that aren't mine.

Votes cast: 123, Votes controlled by me: 123

I control 123/123 = 100% of the votes.

[toast]

In addition to owning a few accounts which were once delegates, I own an account which once held 10% of the total BTS. I can send these amounts to myself, while excluding all other transactions.

For a time, I control 100% of the votes seen by the attack-chain.

You would only adjust 10% of the vote, not 100%. The votes you don't control stay on delegates they voted for.

[MolonLabe]

In addition to owning a few accounts which were once delegates, I own an account which once held 10% of the total BTS. I can send these amounts to myself, while excluding all other transactions.

For a time, I control 100% of the votes seen by the attack-chain.

[bytemaster]

I control the secret chain, and the transactions in it.

Therefore, I control "input from the shareholders necessary to change votes away from the non-participating delegates"?

If not, how does that input come about?

After the secret chain is built, I can add in transactions from the original chain, just a little later.

You do not control the private keys of the shareholders so you cannot update their balances and thus change their votes.

Every time a user makes a transfer from User A to User B they also update what votes the shares used in the transfer are voting for.  Thus unless you can change every balance you cannot change votes.  Therefore votes for delegates are 'stuck' until a shareholder acts.

[toast]

I control the secret chain, and the transactions in it.

Therefore, I control "input from the shareholders necessary to change votes away from the non-participating delegates"?

If not, how does that input come about?

After the secret chain is built, I can add in transactions from the original chain, just a little later.

So best case you migrate the transactions that vote in the delegates in the non-secret chain and then what? You can't make that chain longer without their signature, and you can't forge stake-vote.

You can make a secret chain only if you control 51% stake at any *single* point in time (within 100 block window), including sometime in the past (you could find old keys). So wide initial distribution matters

[MolonLabe]

I control the secret chain, and the transactions in it.

Therefore, I control "input from the shareholders necessary to change votes away from the non-participating delegates"?

If not, how does that input come about?

After the secret chain is built, I can add in transactions from the original chain, just a little later.

[bytemaster]

To try again...

A new node connects and sees two chains:

Chain 1 : 100 + 99 + 98 + 100 + 100 + 97 + ... + 100 + 99 = 4589 blocks of a possible 5000
Chain 2 : 100 + 99 + 49 + 49 + 49 + 52 + 59 + 60 + 100 + 100 + 100 + ... + 100 = 4590 blocks of a possible 5000

Both follow all the rules, have snapshots, etc. Which chain does this node select as reality?

I assumed that the network still operates if 51% of the delegates are tracked down and murdered, and their computers destroyed. Perhaps that assumption was false?

The network still operates but requires input from the shareholders to elect new delegates.   So the scenario you laid out is not possible because the 'secret' chain would never have input from the shareholders necessary to change votes away from the non-participating delegates.

[MolonLabe]

To try again...

A new node connects and sees two chains:

Chain 1 : 100 + 99 + 98 + 100 + 100 + 97 + ... + 100 + 99 = 4589 blocks of a possible 5000
Chain 2 : 100 + 99 + 49 + 49 + 49 + 52 + 59 + 60 + 100 + 100 + 100 + ... + 100 = 4590 blocks of a possible 5000

Both follow all the rules, have snapshots, etc. Which chain does this node select as reality?

I assumed that the network still operates if 51% of the delegates are tracked down and murdered, and their computers destroyed. Perhaps that assumption was false?