Change to one vote per account

Dear Lisk community,

the roadmap phase "Delegated Proof of Stake" suggests several improvements of the delegated proof of stake system used in Lisk. With this email, I would like to start the discussion regarding one of the objectives of this phase, namely "Change voting system". The voting system has been extensively discussed in the community in the past (see https://github.com/LiskHQ/lisk/issues/353). Here at Lightcurve we had a close look at all these different ideas and we are now eager to gather your feedback regarding our LIP "Change to one vote per account" on this mailing list. You can find a short summary of the LIP below and the full proposal in the attachment.

Abstract
This LIP proposes a change of the voting system for the election of delegates in Lisk. We suggest to only allow one vote per account with a vote weight given by the balance of that account. The goal is to increase the decentralization of the network by disincentivizing coalitions between active delegates and creating a healthy competition for active delegate slots. Moreover, the proposed voting system is very simple and encourages a high participation of stakeholders.

lip-change_to_one_vote_per_account.md (26.4 KB)

1 Like

In my opinion the only purpose (or at least the most important one) of the voting system is to guarantee a secure and an efficient network/blockchain. If the voting system can not guarantee the security and efficiency of the blockchain, it is not suitable for Lisk, no matter if it has all desired properties listed in the proposed LIP.

I will explain in the following why in my opinion the "one vote per account" system will lead to an inefficient and maybe even an insecure blockchain/network and why it is therefore not suitable for Lisk. This is not because of technical aspects, but because of economical and game-theory aspects.

TLDR: The "one vote per account" system will lead to 101 delegates not caring about the integrity, efficiency and security of the network because they will have not enough financial incentive to do so. They will use the cheapest possible nodes, they won't update their nodes in a timely manner when critical security fixes should be applied, they won't care about missed blocks, they won't use their time to promote and support Lisk in any way and they will be bribeable for very low cost.

Let me explain why:
The following will happen in the long run: Well, I think it could happen pretty quickly, because the voters and delegates already know the drill from other DPOS systems like ARK, Oxy, etc...
But let's assume we play the game from the beginning, in little steps:

1. delegates will offer very little rewards, let's say 0-5%.
2. people will vote for those who offer 5%, and 101 delegates offering 5% will be forging.
3. clever standby delegate on rank 102 will offer 10% to give voters more incentive to vote him instead of one of the top 101, to join the forging position.
4. voters will vote for the 10%-delegate on rank 102 (because they will get more rewards by doing this), who will finally replace the 5%-delegate on rank 101.
5. delegates on rank 102 - 150 will offer the same, 10%, maybe also delegates on rank 1 - 101 will increase their rewards.
6. this will lead to a situation where all forging delegates on rank 1 - 101 will offer 10%, until rank 102 begins to offer 20% and step 4 - 6 will repeat with 20%.
7. This cycle will continue with increasing sharing rewards.
...
Delegates will continue to share more and more, until everybody shares around 95-99%. Actually, an equilibrium will happen, at the point when delegates share so much, that their income (maybe 1-5%) barely covers their costs. To reduce their costs, they will use the cheapest possible $3/month VPS nodes, they will spend as little time as possible for Lisk, and they won't care about their nodes, because they earn almost nothing anyways, it doesn't matter for them if they miss blocks or if they become unvoted. If people think this is no problem because they can unvote those sloppy delegates and simply vote for better delegates, they are wrong. There won't be better delegates, because every delegate will HAVE TO give 95-99%+ rewards to have a chance to join 101 and for an income of like $100 per month, there won't be many offering a good delegate job.

The end result will be, that those 101 forging delegates have extremely little financial incentive to run their nodes in a secure and reliable manner. They won't care about the network or the ecosystem. Even worse, they could earn more by accepting bribe money. The LIP explains the situation about bribing, it is not too easy to bribe 51 delegates to do real harm to the network. But still, it would be very cheap for a competitor blockchain to bribe a fair amount of delegates (which don't even have to be coordinated) to disturb the Lisk blockchain severely.

For voters those 95% sharing rewards might sound like heaven. BUT: the high LSK rewards will be worth nothing when the blockchain is insecure, is inefficient, is not upgraded in a timely manner when crucial security fixes should be applied, because this will lead to falling LSK prices on the market. You could even lose your LSK if the blockchain is not secured properly by financially incentivised, serious delegates.

Another reason why I don't like the "one vote per account" system is that I want to vote for multiple delegates, because there are many great people in our community! I can't and don't want to reduce my vote to only one single delegate. I know at least 50 delegates who definitely would earn my vote. I would definitely prefer a system where I can vote multiple people and everyone gets (account balance)/(# of votes) voting weight from me. Of course I could split into 30 accounts, but it's too much of a hurdle to do that and it would need quite some LSK for paying the fees.

Because in my opinion the "one vote account" would lead to an inefficient, abandoned and insecure blockchain I refuse this proposal severely.

4 Likes

Hi cc001,

I very much enjoyed reading your explanation of what “one vote per account” will lead to. I’m not strongly convinced it will happen, but I’m interested in understanding the scenario better. One thing I miss mentioned there explicitly is why the scenario you describe applies to the proposed “one vote per account” and not to the current “101 votes per account”. I can think of some reasons, but I’m no expert in economics or game theory, so I would like to read your explanation.

Can you please elaborate on that for me and others that might wonder about the same question?

Thank you,

Vít

···

On Tue, Feb 5, 2019 at 10:40 PM cc001 cc001.bct@gmail.com wrote:

In my opinion the only purpose (or at least the most important one) of

the voting system is to guarantee a secure and an efficient

network/blockchain. If the voting system can not guarantee the security

and efficiency of the blockchain, it is not suitable for Lisk, no matter

if it has all desired properties listed in the proposed LIP.

I will explain in the following why in my opinion the "one vote per

account" system will lead to an inefficient and maybe even an insecure

blockchain/network and why it is therefore not suitable for Lisk. This

is not because of technical aspects, but because of economical and

game-theory aspects.

TLDR: The “one vote per account” system will lead to 101 delegates not

caring about the integrity, efficiency and security of the network

because they will have not enough financial incentive to do so. They

will use the cheapest possible nodes, they won’t update their nodes in a

timely manner when critical security fixes should be applied, they won’t

care about missed blocks, they won’t use their time to promote and

support Lisk in any way and they will be bribeable for very low cost.

Let me explain why:

The following will happen in the long run: Well, I think it could happen

pretty quickly, because the voters and delegates already know the drill

from other DPOS systems like ARK, Oxy, etc…

But let’s assume we play the game from the beginning, in little steps:

  1. delegates will offer very little rewards, let’s say 0-5%.

  2. people will vote for those who offer 5%, and 101 delegates offering

5% will be forging.

  1. clever standby delegate on rank 102 will offer 10% to give voters

more incentive to vote him instead of one of the top 101, to join the

forging position.

  1. voters will vote for the 10%-delegate on rank 102 (because they will

get more rewards by doing this), who will finally replace the

5%-delegate on rank 101.

  1. delegates on rank 102 - 150 will offer the same, 10%, maybe also

delegates on rank 1 - 101 will increase their rewards.

  1. this will lead to a situation where all forging delegates on rank 1 -

101 will offer 10%, until rank 102 begins to offer 20% and step 4 - 6

will repeat with 20%.

  1. This cycle will continue with increasing sharing rewards.

Delegates will continue to share more and more, until everybody shares

around 95-99%. Actually, an equilibrium will happen, at the point when

delegates share so much, that their income (maybe 1-5%) barely covers

their costs. To reduce their costs, they will use the cheapest possible

$3/month VPS nodes, they will spend as little time as possible for Lisk,

and they won’t care about their nodes, because they earn almost nothing

anyways, it doesn’t matter for them if they miss blocks or if they

become unvoted. If people think this is no problem because they can

unvote those sloppy delegates and simply vote for better delegates, they

are wrong. There won’t be better delegates, because every delegate will

HAVE TO give 95-99%+ rewards to have a chance to join 101 and for an

income of like $100 per month, there won’t be many offering a good

delegate job.

The end result will be, that those 101 forging delegates have extremely

little financial incentive to run their nodes in a secure and reliable

manner. They won’t care about the network or the ecosystem. Even worse,

they could earn more by accepting bribe money. The LIP explains the

situation about bribing, it is not too easy to bribe 51 delegates to do

real harm to the network. But still, it would be very cheap for a

competitor blockchain to bribe a fair amount of delegates (which don’t

even have to be coordinated) to disturb the Lisk blockchain severely.

For voters those 95% sharing rewards might sound like heaven. BUT: the

high LSK rewards will be worth nothing when the blockchain is insecure,

is inefficient, is not upgraded in a timely manner when crucial security

fixes should be applied, because this will lead to falling LSK prices on

the market. You could even lose your LSK if the blockchain is not

secured properly by financially incentivised, serious delegates.

Another reason why I don’t like the “one vote per account” system is

that I want to vote for multiple delegates, because there are many great

people in our community! I can’t and don’t want to reduce my vote to

only one single delegate. I know at least 50 delegates who definitely

would earn my vote. I would definitely prefer a system where I can vote

multiple people and everyone gets (account balance)/(# of votes) voting

weight from me. Of course I could split into 30 accounts, but it’s too

much of a hurdle to do that and it would need quite some LSK for paying

the fees.

Because in my opinion the “one vote account” would lead to an

inefficient, abandoned and insecure blockchain I refuse this proposal

severely.

LIPS mailing list

LIPS@lists.lisk.io

http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io

1 Like

Hi cc001,

thank you very much for your input.

Before addressing your concerns, let me emphasize that the whole LIP process is designed to make the whole evolution of Lisk transparent and include the expertise and knowledge of the community. So it would be great to have several sound, well-reasoned proposals for a new voting system in order to carefully weigh the arguments and choose the best solution (maybe combining different proposals).

Regarding your reasoning below:

  1. I agree that if people ONLY vote based on maximal gain (shared rewards), then the delegates with the highest percentage of shared rewards will get into the top 101 slots. However, if people also value other factors (expertise in running a node, community involvement,...), then these factors matter and a person with a good community involvement, for instance, has a realistic chance of becoming a delegate (after convincing account holders with a balance of around 500,000 LSK, see LIP for details). Currently, this is not really possible. Overall, it will probably be a mix of both (people voting selfish and people considering involvement/other factors) and the community will determine in which direction the system moves.

  2. The LIP already discusses the security implications of the proposed change of the voting system in detail and makes it clear that only a large number of malicious delegates would pose a serious threat. Furthermore, we have several other proposals on the roadmap that will substantially increase the security guarantees:

  • The objective ‘Improve blocks verification’ proposes to add Byzantine fault tolerance to the protocol. This means that the protocol will tolerate malicious/Byzantine delegate up to a certain threshold.
  • The objective ‘Punish protocol violations by delegates’ will add a mechanism to the protocol that punishes a delegate if it can be proven on the blockchain undoubtfully that the delegate acted maliciously. We haven’t finalized the research and specifications, but think of a 10,000 LSK security deposit (value is to be decided) that a delegate loses if they do something malicious.
  1. I also don't clearly see that sharing a high percentage of rewards is a problem. Most delegates have and most likely will have a considerable amount of Lisk (it could be discussed if this should be enforced by the protocol). Take for example a delegate that shares 100 % of the rewards (extreme case, likely it will be less), but also owns 50,000 LSK (and votes for themself). According to the estimates in the LIP, votes by additional 450,000 LSK would be approximately sufficient to secure an active delegate slot. In this case, 10 % of the rewards go to the delegate (10 % of the vote weight is from the delegate itself), 90 % to all other votes. Everybody would be interested to keep productivity high as otherwise they lose money. Moreover, delegates can be voted out of the 101 much easier if the productivity is low (much less people have to change their votes).

I am happy to discuss more!
Cheers,
Jan

Hello,

Delegate hirish here. I would like jump in with my considerations about this proposal.

First of all we need to set the goals Lisk wants to reach. I assume the goals are:
- Get rid of groups
- Increase competition between delegates
- Still maintain secure the network
- Makes community happy with rewards (?)

I'm currently a forging delegate. I'm a developer investing his time on Lisk. I'm an entrepreneur who has an idea to be implemented on Lisk (www.sapiensproject.io). The majority of community members could read my words as biased, but I will try to analyze this proposal from all point of views: delegates, developers and promoters, community members interested in shares. This because I was and I am all of them.

Before starting to analyze the future scenario, I would like to spend some words about greediness and high incentives. In simple words, greediness and high incentives is what is making bitcoin, and the crypto-world in general, secure. I understand it is very unpopular, but that's how it works. High rewards push people to do great things.

As a delegate point of view, we already know what will happen thanks to other DPOS projects that have already implemented this solution. It will end up with delegates with an average share percentage of 90+%. This means very low incentives. Low financial incentives means also low carefulness to the secure aspect of the network. It's a natural reaction of human kind.

As a developer and promoter, since there are low incentives, there will be also low level of participation in the project. I honestly think I would never have coded all the Ledger Integration and all the other project I did with low incentives. And the reasons is simple: I can make more money by doing something else (see? greediness push people to do *also* great things!). The same conclusion could be made for a promoter point of view. We had tons of Lisk Meetups around the world. I believe this will disappear. Projects like Lisk Utrecht Center and Elite Center would not have been possible without a proper amount of funds.

As a community member interested in shares, this proposal seems like heaven. But I'm not sure they're going to get more shares. Since you have only 1 vote, the 90% share acts like an upper-bound-hard-cap on how much you can get from vote sharing. Currently you get in average 25% from *every* delegate. It is also true that with "1 vote per account" you will share the vote with a lot less people. But I'm not sure this will be enough to get more. Automatic Bot that does switch of votes in favor of low-ranked high-shares delegates will popup making delegate ranks very unstable. This will create network instabilities if delegates are not ready. I'm quite sure (but it needs more calculations) that voters will get less rewards in average compared to the current solution if they do not act on weekly basis on their vote.

I will try to summarize pros and cons of this solution.

PROS
- New delegates will join the game
- Large groups will lose power, but probably won't disappear
- More competition for active delegate slots, but (CONS) based mostly on share percentage and not on great contributions.

CONS
- Voters will get less rewards if they do no switch vote on regular basis
- It could cause network instabilities
- Low incentives to keep secure the network
- Low incentives to contribute to Lisk
- It is not a definitive solution
- Projects like sidechains and Lisk centers and meetups won’t be funded anymore since financial incentives are low.
- Low financial incentives it means also becoming less attractive to developers.

Conclusion
In my honest opinion as an investor in this project, this solution cannot be interpreted as a definitive one because it simply shift the current problems to some different (and more delicate/critical) ones and doesn’t fit all the goals behind this change.

I would like to see Lisk as a vanguard in the DPOS field by finding a proper and original solution, and not a “temporary patch” that solve some problems, but creates new and more monsters.
And these monsters are already out there.

Best,

hirish

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

···

Il mercoledì 6 febbraio 2019 14:45, Jan Hackfeld <jan.hackfeld@lightcurve.io> ha scritto:

Hi cc001,

thank you very much for your input.

Before addressing your concerns, let me emphasize that the whole LIP
process is designed to make the whole evolution of Lisk transparent and
include the expertise and knowledge of the community. So it would be
great to have several sound, well-reasoned proposals for a new voting
system in order to carefully weigh the arguments and choose the best
solution (maybe combining different proposals).

Regarding your reasoning below:

1. I agree that if people ONLY vote based on maximal gain (shared
    rewards), then the delegates with the highest percentage of shared
    rewards will get into the top 101 slots. However, if people also value
    other factors (expertise in running a node, community involvement,...),
    then these factors matter and a person with a good community
    involvement, for instance, has a realistic chance of becoming a delegate
    (after convincing account holders with a balance of around 500,000 LSK,
    see LIP for details). Currently, this is not really possible. Overall,
    it will probably be a mix of both (people voting selfish and people
    considering involvement/other factors) and the community will determine
    in which direction the system moves.

2. The LIP already discusses the security implications of the proposed
    change of the voting system in detail and makes it clear that only a
    large number of malicious delegates would pose a serious threat.
    Furthermore, we have several other proposals on the roadmap that will
    substantially increase the security guarantees:

- The objective 'Improve blocks verification' proposes to add Byzantine
    fault tolerance to the protocol. This means that the protocol will
    tolerate malicious/Byzantine delegate up to a certain threshold.

- The objective 'Punish protocol violations by delegates' will add a
    mechanism to the protocol that punishes a delegate if it can be proven
    on the blockchain undoubtfully that the delegate acted maliciously. We
    haven't finalized the research and specifications, but think of a 10,000
    LSK security deposit (value is to be decided) that a delegate loses if
    they do something malicious.

3. I also don't clearly see that sharing a high percentage of rewards is
    a problem. Most delegates have and most likely will have a considerable
    amount of Lisk (it could be discussed if this should be enforced by the
    protocol). Take for example a delegate that shares 100 of the rewards &nbsp;&nbsp;&nbsp;&nbsp;\(extreme case, likely it will be less\), but also owns 50,000 LSK \(and &nbsp;&nbsp;&nbsp;&nbsp;votes for themself\)\. According to the estimates in the LIP, votes by &nbsp;&nbsp;&nbsp;&nbsp;additional 450,000 LSK would be approximately sufficient to secure an &nbsp;&nbsp;&nbsp;&nbsp;active delegate slot\. In this case, 10 of the rewards go to the
    delegate (10 of the vote weight is from the delegate itself\), 90 to
    all other votes. Everybody would be interested to keep productivity high
    as otherwise they lose money. Moreover, delegates can be voted out of
    the 101 much easier if the productivity is low (much less people have to
    change their votes).

    I am happy to discuss more!
    Cheers,
    Jan

    On 2/6/19 1:02 PM, Vit Stanislav wrote:

> Hi cc001,
> I very much enjoyed reading your explanation of what "one vote per
> account" will lead to. I'm not strongly convinced it will happen, but
> I'm interested in understanding the scenario better. One thing I miss
> mentioned there explicitly is why the scenario you describe applies to
> the proposed "one vote per account" and not to the current "101 votes
> per account". I can think of some reasons, but I'm no expert in
> economics or game theory, so I would like to read your explanation.
> Can you please elaborate on that for me and others that might wonder
> about the same question?
> Thank you,
> Vít
> On Tue, Feb 5, 2019 at 10:40 PM cc001 <cc001.bct@gmail.com > > mailto:cc001.bct@gmail.com> wrote:
>
> In my opinion the only purpose (or at least the most important one) of
> the voting system is to guarantee a secure and an efficient
> network/blockchain. If the voting system can not guarantee the security
> and efficiency of the blockchain, it is not suitable for Lisk, no
> matter
> if it has all desired properties listed in the proposed LIP.
>
> I will explain in the following why in my opinion the "one vote per
> account" system will lead to an inefficient and maybe even an insecure
> blockchain/network and why it is therefore not suitable for Lisk. This
> is not because of technical aspects, but because of economical and
> game-theory aspects.
>
> TLDR: The "one vote per account" system will lead to 101 delegates not
> caring about the integrity, efficiency and security of the network
> because they will have not enough financial incentive to do so. They
> will use the cheapest possible nodes, they won't update their nodes
> in a
> timely manner when critical security fixes should be applied, they
> won't
> care about missed blocks, they won't use their time to promote and
> support Lisk in any way and they will be bribeable for very low cost.
>
> Let me explain why:
> The following will happen in the long run: Well, I think it could
> happen
> pretty quickly, because the voters and delegates already know the drill
> from other DPOS systems like ARK, Oxy, etc...
> But let's assume we play the game from the beginning, in little steps:
>
> 1. delegates will offer very little rewards, let's say 0-5%.
> 2. people will vote for those who offer 5%, and 101 delegates offering
> 5% will be forging.
> 3. clever standby delegate on rank 102 will offer 10% to give voters
> more incentive to vote him instead of one of the top 101, to join the
> forging position.
> 4. voters will vote for the 10%-delegate on rank 102 (because they will
> get more rewards by doing this), who will finally replace the
> 5%-delegate on rank 101.
> 5. delegates on rank 102 - 150 will offer the same, 10%, maybe also
> delegates on rank 1 - 101 will increase their rewards.
> 6. this will lead to a situation where all forging delegates on rank
> 1 -
> 101 will offer 10%, until rank 102 begins to offer 20% and step 4 - 6
> will repeat with 20%.
> 7. This cycle will continue with increasing sharing rewards.
> ...
> ...
> Delegates will continue to share more and more, until everybody shares
> around 95-99%. Actually, an equilibrium will happen, at the point when
> delegates share so much, that their income (maybe 1-5%) barely covers
> their costs. To reduce their costs, they will use the cheapest possible
> $3/month VPS nodes, they will spend as little time as possible for
> Lisk,
> and they won't care about their nodes, because they earn almost nothing
> anyways, it doesn't matter for them if they miss blocks or if they
> become unvoted. If people think this is no problem because they can
> unvote those sloppy delegates and simply vote for better delegates,
> they
> are wrong. There won't be better delegates, because every delegate will
> HAVE TO give 95-99%+ rewards to have a chance to join 101 and for an
> income of like $100 per month, there won't be many offering a good
> delegate job.
>
> The end result will be, that those 101 forging delegates have extremely
> little financial incentive to run their nodes in a secure and reliable
> manner. They won't care about the network or the ecosystem. Even worse,
> they could earn more by accepting bribe money. The LIP explains the
> situation about bribing, it is not too easy to bribe 51 delegates to do
> real harm to the network. But still, it would be very cheap for a
> competitor blockchain to bribe a fair amount of delegates (which don't
> even have to be coordinated) to disturb the Lisk blockchain severely.
>
> For voters those 95% sharing rewards might sound like heaven. BUT: the
> high LSK rewards will be worth nothing when the blockchain is insecure,
> is inefficient, is not upgraded in a timely manner when crucial
> security
> fixes should be applied, because this will lead to falling LSK
> prices on
> the market. You could even lose your LSK if the blockchain is not
> secured properly by financially incentivised, serious delegates.
>
> Another reason why I don't like the "one vote per account" system is
> that I want to vote for multiple delegates, because there are many
> great
> people in our community! I can't and don't want to reduce my vote to
> only one single delegate. I know at least 50 delegates who definitely
> would earn my vote. I would definitely prefer a system where I can vote
> multiple people and everyone gets (account balance)/(# of votes) voting
> weight from me. Of course I could split into 30 accounts, but it's too
> much of a hurdle to do that and it would need quite some LSK for paying
> the fees.
>
> Because in my opinion the "one vote account" would lead to an
> inefficient, abandoned and insecure blockchain I refuse this proposal
> severely.
>
>
> --
> LIPS mailing list
> LIPS@lists.lisk.io <mailto:LIPS@lists.lisk.io>
> http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io
>

--

Jan Hackfeld
Cryptographer, Lightcurve

---------------------------------------

LIPS mailing list
LIPS@lists.lisk.io
http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io

1 Like

Dear all,

@hirish: Also thanks for your input here. I tried to address your points below.

Cheers,
Jan

Hello,

Delegate hirish here. I would like jump in with my considerations about this proposal.

First of all we need to set the goals Lisk wants to reach. I assume the goals are:
- Get rid of groups
- Increase competition between delegates
- Still maintain secure the network
- Makes community happy with rewards (?)

I'm currently a forging delegate. I'm a developer investing his time on Lisk. I'm an entrepreneur who has an idea to be implemented on Lisk (www.sapiensproject.io). The majority of community members could read my words as biased, but I will try to analyze this proposal from all point of views: delegates, developers and promoters, community members interested in shares. This because I was and I am all of them.

Before starting to analyze the future scenario, I would like to spend some words about greediness and high incentives. In simple words, greediness and high incentives is what is making bitcoin, and the crypto-world in general, secure. I understand it is very unpopular, but that's how it works. High rewards push people to do great things.

I agree with your general statement. We need to set incentives in our system so that they are crypto-economically sound and participants/delegates have incentives to be honest (because of voting / slashing / ...)

As a delegate point of view, we already know what will happen thanks to other DPOS projects that have already implemented this solution. It will end up with delegates with an average share percentage of 90+%. This means very low incentives. Low financial incentives means also low carefulness to the secure aspect of the network. It's a natural reaction of human kind.

I would give the same reasoning as in my reply to Anthony regarding his point *4. Increased likelihood of delegates being bribed*

As a developer and promoter, since there are low incentives, there will be also low level of participation in the project. I honestly think I would never have coded all the Ledger Integration and all the other project I did with low incentives. And the reasons is simple: I can make more money by doing something else (see? greediness push people to do *also* great things!). The same conclusion could be made for a promoter point of view. We had tons of Lisk Meetups around the world. I believe this will disappear. Projects like Lisk Utrecht Center and Elite Center would not have been possible without a proper amount of funds.

We really appreciate your work Hirish and what you do really deserves support, in my opinion, independently of the fact whether you are a delegate or not. See also point *2. Much less Lisk to give away to deserving causes (Community donations, Lisk Centers, Meetups, Projects, etc.)* from my reply to Anthony.

As a community member interested in shares, this proposal seems like heaven. But I'm not sure they're going to get more shares. Since you have only 1 vote, the 90% share acts like an upper-bound-hard-cap on how much you can get from vote sharing. Currently you get in average 25% from *every* delegate. It is also true that with "1 vote per account" you will share the vote with a lot less people. But I'm not sure this will be enough to get more.

I believe that this is not true. In the current voting system you of course can receive rewards from 101 active delegate, but you also have to share it with much more people (most people vote for 101 active delegates). So if delegates share 25 % in the current and also 25 % in the proposed voting system, people roughly would get the same amount of payouts (the total block rewards received by delegates are just the same, so 25 % of that is just the same).

I will try to summarize pros and cons of this solution.

PROS
- New delegates will join the game
- Large groups will lose power, but probably won't disappear
- More competition for active delegate slots, but (CONS) based mostly on share percentage and not on great contributions.

CONS
- Voters will get less rewards if they do no switch vote on regular basis

Not true, if payouts remain at the current level or are higher.

- It could cause network instabilities

See *4. Increased likelihood of delegates being bribed* in last reply.

- Low incentives to keep secure the network

See *4. Increased likelihood of delegates being bribed* in last reply.

- Low incentives to contribute to Lisk

See *2. Much less Lisk to give away to deserving causes* in last reply.

- It is not a definitive solution

I would love to see more well-reasoned proposals.

- Projects like sidechains and Lisk centers and meetups won’t be funded anymore since financial incentives are low.

See *2. Much less Lisk to give away to deserving causes* in last reply.

- Low financial incentives it means also becoming less attractive to developers.

I agree that delegates make less money if the tendency in the proposed voting system is that more rewards are shared. But I don't understand why the platform should be less attractive to developers (those which are not delegates).

Here Santerr, let me add some comments from myself.

The problems that I see are primarily the inefficiency of the current system as well as the centralization of votes. Of course, you can argue with this because it is subjective but looking at the mood of the community, many people have the same opinion.

The main problem that we all see is the huge impact of the cartel on delegates who are in 101. There is no way to get to 101 without the support of the cartel. The community does not decide, the cartels decide. I know that I can vote for everyone, but let’s not fool ourselves, we see what is happening now. Voices change for each call of the cartel. I believe that 1 vote on the account will not solve this problem and in addition will result in the collapse of many initiatives for the development of the ecosystem. The current proposal is explicit treatment of symptoms and not the actual source of the disease. This will bring new and new problems. It does not make sense.

What I suggest:

The creation of a DAO where the power will indeed pass into the hands of the community and the problem of the cartel will be solved once and for all, despite the fact that they will be able to exist all the time. This is important because I do not like restrictions, I would like everyone to be able to act as they want and have no artificial restrictions.

We create a Community DAO fund which is fed by 10-20% delegate awards. The changes are saved in the protocol and pass automatically. I accept that we are introducing the changes proposed by HQ with 1 voice to the account. Which will probably result in a 90% reward distribution. Many people say that this is a problem. I will try to prove that it can be a benefit for the whole community. Let me answer the requests of the hirish delegate, I will be able to explain this vividly on the example:

Hirish - " As a developer and promoter, since there are low incentives, there will be also low level of participation in the project. I honestly think I would never have coded all the Ledger Integration and all the other project I did with low incentives. And the reasons is simple: I can make more money by doing something else (see? greediness push people to do also great things!). The same conclusion could be made for a promoter point of view. We had tons of Lisk Meetups around the world. I believe this will disappear. Projects like Lisk Utrecht Center and Elite Center would not have been possible without a proper amount of funds."

Santerr - Not true. Only the influence on these activities by the delegates will change. Delegates will still be able to do great things, all they have to do is come up with a DAO idea and the community will decide if it makes sense. If so, you will receive the funds that you think are needed for this project. The only thing that will change is that empty promises will have to turn into deeds. Hirish, you’re one of the few delegates who does something. Praise you for it, but even if you share 90% you will have DAO funds to implement your ideas. At the start your confidence coefficient grows because the community sees you are not passive.

Hirish - As a community member interested in shares, this proposal seems like heaven. But I’m not sure they’re going to get more shares. Since you have only 1 vote, the 90% share acts like an upper-bound-hard-cap on how much you can get from vote sharing. Currently you get in average 25% from every delegate. It is also true that with “1 vote per account” you will share the vote with a lot less people. But I’m not sure this will be enough to get more. Automatic Bot that does switch of votes in favor of low-ranked high-shares delegates will popup making delegate ranks very unstable. This will create network instabilities if delegates are not ready. I’m quite sure (but it needs more calculations) that voters will get less rewards in average compared to the current solution if they do not act on weekly basis on their vote.

Santerr - I think that the difference in remuneration for voters will not change fundamentally, but it is not important. Manipulation in the votes will be hard to beware of open voting. The next stage of HQ should be the pursuit of anonymous votes. Today we know that it requires huge amounts of work. In my proposal, it will not have too much impact if at all.

Your pros and cons Hirish

PROS

- New delegates will join the game - exactly. Enormous opportunities will be given to delegates who now have nothing, even though they proved their usefulness for the ecosystem. Examples: Liskpoland and proline. It is enough that they apply to DAO and, taking into account the reputation they have, they can count on co-financing of their projects from the fund.

  • Large groups will lose power, but probably won’t disappear - groups are not a problem how their functioning is a problem. My suggestion solves it, groups can exist, but they will not have the power to control the community like puppets.

  • More competition for active delegate slots, but (CONS) based mostly on share percentage and not on great contributions.

CONS

  • Voters will get less rewards if they do no switch vote on regular basis - requires more research. I believe that the rewards will not change too much.

  • It could cause network instabilities - This will not happen. Being a good delegate and keeping your node in good condition will increase the trust of the community, which results in the delegate being able to count on financing their projects at DAO. In addition, we introduce an additional% rewards for good nodes in a specific time unit. For example, a delegate’s prize increases by several percent every 3-6-12 months if its node functions without any problem. After a year, he can earn 10% more. Additional rewards are paid from DAO. I think that this is good and will motivate you to do a good job.

  • Low incentives to keep secure the network - You do not want to do nothing. You are rewarded for running the node and this is your job. Nobody blames you. There will be others who will do more and the number of projects I believe will be greater than today on the side of the delegates. I remind you - Hirish - you are one of the few who can see that he is doing something.

  • Low incentives to contribute to Lisk - ** I do not think that the rewards will be low. It all depends on the price of lisk. In the future even 100lsk can be worth a lot. Of course, he realizes that a large part of the delegates may give up because nobody can come to terms with a reduced level of living, currently the fox is a real gold coin. But this is not a problem, others will be better. And those who leave will confirm that the real motivation was greed and not the development of the ecosystem.

  • It is not a definitive solution

  • Projects like sidechains and Lisk centers and meetups won’t be funded anymore since financial incentives are low. - on the contrary, I believe that the chances of such initiatives will be even greater.

  • Low financial incentives it means also becoming less attractive to developers. - for which developers? I understand that it’s about delegates because they are paid. Let’s ask how much @prolina earned because probably no one doubts his contribution to the ecosystem. Thanks to my suggestions, in the end, such developers will be able to bloom in a lisk.

I will also paste a few of my entries that I have made available to the lisk.chat so that they do not get lost and also present several scenarios of how this proposal works.

"arguments that if profits from forging will be lower then delegates will not develop the ecosystem is wrong. It does not really matter, because they do not do it because they want to develop the ecosystem. Proof of gratitude, do you know? The same is true when we are standing at the crossroads of the road and the boy approaches our car and immediately cleans windows (sometimes even when we do not want it) What happens later? He comes to us and wants money. We give them because it is stupid to give nothing because he did some work for us. Delegates also have the same function, some (Some delegates, because there is a large group that does nothing), it is simply stupid to take money and not do anything totally.

In addition, I am almost convinced (it’s just guesses) because we do not have any reports. That money can be burned and all management is not economically optimal.

In addition, today the delegates form the lisk center, but they may close it in 5 months as well and no one should blame it. I remind the delegates they do it willingly that today they show good-naturedness does not mean that they will do it later.

The solution is simple: DAO, where the community decides who will receive subsidies, where to open a new center, etc.

"

cc001 - I disagree. Would you as delegate give up your day job and work fulltime for lisk, and donate to others, if you get only a halve-day-salary per month?? Honestly, I don’t think so.

Santerr - "but in my proposal, the delegate does not have to do anything but maintain the forging. DAO takes over the role of the delegate in terms of ecosystem development. This, in my opinion, is much more optimal and we will be able to do a lot more things.

and so most delegates do nothing but forging. Praise to those who have acted so far for the development of the ecosystem but we are reaching the point where we can relieve delegates from this hard work.

to encourage delegates to good forging and keeping nodes at a high level. I would introduce in the protocol the growth of spoil in a specific timeframe by a certain percentage (numbers to be determined). Additional proceeds would be covered by DAO. In case the delegate makes 90% available, even a few% would be a significant increase in earnings.

You have to calculate it more or does it make sense, but I think it would be a good incentive.

For example, by maintaining a reliable node for a year you get an additional 10% from DAO. If your node is not working properly for some time, you are lowering the level."

“In such a case, a situation may arise that the delegate declares in DAO his proposal to create a project which we put to vote and decide whether to trust this delegate and provide him with funds for implementation or not. If we decide to help the delegate, we REQUIRE from him the implementation of what he has decided. Now we have nothing, we are moving on empty words and promises that do nothing to the ecosystem.”

"First of all, everything is clear and clear, because one of the problems is also that the delegates take a lot, but they do nothing. DAO solves this. Like the problem of sharing 90% of profits.

Being a delegate will also be a more elite place for people who really care about development. For (for example) 10% profit from noda (numbers to attention) can still be high earnings. In addition, the delegate can continuously develop their projects by submitting applications at DAO. A delegate who will have more confidence will earn even more.

Ask yourself if delegates who want 90% of profits, or they will not do anything, want ecosystems well or not, maybe something else?

If the delegate tells me that he will not be motivated to act for the community, because he will not earn enough. I answer him: Hey, okay, no problem. This money does not disappear all the time, they are waiting for you, all you have to do is present us your project and convince us that it is worth investing in it and you will receive the money for implementation. You can be anonymous, we do not want to know who you are, all we need is results and implementation.

I do not think the delegates have a better verifier. :wink:

it also does not close the existence of cartels. But only if the cartels work for the development of the ecosystem because only then will they receive additional funds."

Unchecked money is spent carelessly and inefficiently, no one doubts that delegates primarily care about their own but not the development of the ecosystem, so we can assume that part of the money is simply blown. Of course, I do not have a grudge and I do not want to look into anyone’s wallet - it only shows the inefficiency of this system. The DAO Fund solves this problem and takes away the power of the cartels. It causes that power really gets into the hands of the community and that it decides about further development. A greater number of programmers have the opportunity to develop their projects. I am curious what HQ thinks and think about the community because it seems quite a good and not too difficult solution in the implementation.

Ciao

Glory of Minions

···

Sent with ProtonMail Secure Email.

Dear Lisk community,

I tried to summarize the main discussion points and concerns raised so far and addressed them below.

Cheers,
Jan

1) Claim: A new voting system is likely to imply higher reward sharing.

The general consensus is that one vote per account would lead to a stronger competition for the delegate slots and as a large fraction of votes would be based on the percentage of shared rewards, delegates sharing larger fractions of rewards would get elected (cc001 elaborates on this in more detail). One may also ask the question why a delegate promising higher rewards does not get elected now (Vít posed this question). In my opinion, the main reason is that the voting pools have by far the largest influence on the decision of who becomes delegates (as also said by Santerr).

In my opinion, a system of one vote per account reflects the interest of account holders (e.g. maximum personal gain or supporting active community members) much better. For instance, a person with strong expertise and good community involvement has a realistic chance of becoming delegate (after convincing account holders with a balance of around 500,000 LSK, see LIP for details), whereas it currently is almost impossible to become an active delegate without the support by a voting pool. Overall, delegates will probably be elected because of a mix of several factors (people voting selfish and people considering involvement/reliability/other factors) and the community will determine in which direction the system moves.

2) Claim: If delegates receive a smaller percentage of the rewards, they are likely to have lower up time, run nodes on cheaper machines and perform updates less timely.

In my opinion, it is important not to exaggerate the issue of missed block slots. For instance, assume that 5 % of the block slots would be missed. This simply means that the Lisk blockchain is able to process 5 % less transactions and the respective delegates miss out on the block rewards (less inflation). This is not a security problem. Note that LIP 002 proposes to change to a byte based block size and Lisk would be able to process around 120 transactions per block. Moreover, 5 % less transaction capacity would mean higher transaction fees if blocks are full as the demand is the same, but the overall supply of block space is reduced by 5 %.

Moreover, if we believe that low productivity poses a problem and forfeit block rewards do not give a strong enough incentive, then additional slashing conditions could be put in place. For instance, delegates could lose the value of the block reward (or even 5 times the block reward) every time they miss a block.

Less timely updates, e.g. during a hard fork, would also lead to a number of missed block slots of the respective delegates. So basically the same argument as above applies. If it is an update due to a security fix, then this topic is discussed below dealing with the impact on security.

Running Lisk Core on a cheaper nodes should not be a problem if the delegate manages to forge reliably. Otherwise, the line of reasoning regarding the productivity applies.

3) Claim: If delegates receive a smaller percentage of the rewards, they are more likely to be bribed. Thus, the proposed voting will have a negative impact on the security of the network.

In my opinion, the security of a delegated proof-of-stake blockchain cannot exclusively rely on block rewards (otherwise, we would say, for instance, if delegates get 5,000 Euros/month the network is secure, but if they only get 500 Euros/month the network is insecure). That is why we propose to introduce Byzantine fault tolerance (roadmap objective “Improve blocks verification“) and additional deposits/slashing (roadmap objective “Punish protocol violations by delegates”) to the protocol. We have not finalized the proposal draft, but we would probably require a security deposit by delegates. For instance, if we have a security deposit of 20,000 LSK for every delegate and up to 33 delegates can be malicious due to Byzantine fault tolerance, then more than 680,000 LSK of deposits (i.e., deposits by at least 34 delegates) would be slashed if two contradicting blocks would be finalized. This is a much stronger security guarantee than relying on future block rewards (note that you can do a 51 % attack on basically all proof-of-work cryptocurrencies with this amount of money https://www.crypto51.app/ and the attack on Ethereum Classic showed that this is a real danger).

4) Claim: The proposal poses a security problem as a malicious entity with 1/101 fraction of the Lisk stake can permanently remain delegate and disrupt the system.

This issue is already discussed in detail in the section “Impact on Security” in the LIP. Basically, the only malicious attack one single delegate can do is to not forge (see also discussion of productivity above). Further note that in a separate LIP we will propose a banning/punishment of delegates that are offline for an extended period of time (see section “Dependence on Delegate Productivity” in the LIP draft). Thus if a delegate loses their private key, for instance, they would eventually be banned/punished and cannot indefinitely harm the Lisk network.

5) Claim: Delegates will contribute a lot less to the community (via Meetups, Lisk Centers, community donations).

Many delegates definitely do awesome additional work, which is appreciated by the community, but many also simply take the money. In my opinion, the community efforts (Lisk Center, meetups, donations) are not a result of the current voting system, but rather because there are idealistic people involved in Lisk. There are also other people who make a lot of community contributions (more than many active delegates) and are trying to become active delegates, but fail as they are not supported by the pools. I would personally be happy to see another democratic, transparent and fair way to support community initiatives (Santerr proposed the creation of a DAO).

6) Claim: There will still be voting pools.

There is of course no guarantee that in the proposed system of one vote per account there will be no voting pools. One of our main reasons for proposing one vote per account is to have a voting system that does not give incentives to pools (there can be other social factors to form a pool, but these are incentives outside the voting system). For instance, one account holder cannot be forced to vote for all members of a pool as only one vote is possible. Two or more delegates also cannot strengthen their position by voting for each other, which is happening now. Of course the current pools have a considerable amount of stake and could still secure several delegate slots, but far less than they currently have (As explained in the LIP, x % of stake are sufficient to secure x delegate slots). In this regard, the current delegate pools are as powerful as any other group/individual with a significant amount of stake.

7) Claim: With one vote per account only whales become delegates.

According to the estimates in the LIP approximately 500,000 LSK are sufficient to secure one delegate slot. So a whale with this amount of LSK can become delegate or any group of people that together has this amount of LSK. If only whales would become delegates and no group of account holders with smaller balances can join to put one delegate in place, then this would mean that 99 % of the voting tokens are owned by 101 whales.

8) Suggestion by cc001: People want to vote for more than one delegate, so alternatively the vote weight of an account could be (account balance)/(# of votes).

As observed by cc001, changing to one vote per account is equivalent to changing the vote weight to (account balance)/(# of votes). For instance, if an account holder owns 900 LSK and casts three votes, then each vote would have weight 300 LSK if the vote weight is given by (account balance)/(# of votes). In the proposed system of one vote per account, the account holder could split the 900 LSK into 3 accounts with 300 LSK each and cast a different vote with each of the accounts. This would then have the same effect. The disadvantage is that this creates the additional inconvenience to manage multiple accounts and users have to pay additional fees for splitting the account and casting multiple votes. The benefit of one vote per account, in my opinion, is that the voting system is simpler. Furthermore, it adds an additional barrier against formation of pools as multiple accounts need to be managed to vote for all members of a pool. It would be great to also have the suggestion by cc001 drafted as a separate LIP.

Dear community,

@Santerr: Thanks for your input regarding the voting system.

I try to capture the points you raised also in the summary of the discussion so far, in particular, in point 5).

I like your idea of a DAO and would personally be happy to see a LIP in this direction that suggests a democratic and fair way to support community initiatives.

Cheers,
Jan

As Dutch Pool we support a change in the Lisk voting system, but we don’t think one vote per account would be the best solution.

###One vote per account

Like cc001 suggested, people want to vote for more than one delegate. In the case of only one vote per account, most people would probably not go through the hassle to create and manage multiple accounts. We also think that the way to go is when vote weight equals (account balance)/(# of votes).

Jan said: “Furthermore, it adds an additional barrier against formation of pools as multiple accounts need to be managed to vote for all members of a pool.” We don’t think this would be the case. For every pool there will be an independent delegate that is equally attractive to vote for. (Also with our proposal below, there will be even more pools to vote for.)

###Possibility to forge for delegates outside the top 101

Besides making the vote weight equal (account balance)/(# of votes), we also think delegates from position 102-201 should have the possibility to forge, while keeping the number of active delegates each round the same (101). Every delegate should have a probability to forge based on their vote weight. This makes sure that new delegates also have a chance to forge, while giving delegates with the highest vote weight more blocks to forge.

This also creates another effect. Normally when a delegate shares a certain percentages of his forging rewards with his voters, the rewards for those voters would drastically decrease when the vote weight increases. When a delegate has a probability to forge based on their vote weight, they will get a higher probability when the vote weight increases and thus forge more blocks. This would of course stop when the probability of a delegate to forge gets to 100% (forging every round).

###Productivity

We have read that there will be a separate proposal for the productivity/missed blocks punishments, but we think (account balance)/(# of votes)*productivity should be the vote weight.

###Conclusion

What we proposed in this reaction is actually a combination of what Rise and Adamant are doing at the moment (or Rise on sidechains). Rise consensus: https://medium.com/rise-vision/rise-v1-3-x-consensus-change-quick-overview-2431cc3b0dcc. Adamant fair delegate system: https://medium.com/adamant-im/fair-delegate-system-in-dpos-568e5c3c86c8

···

Op do 14 feb. 2019 om 11:29 schreef Jan Hackfeld jan.hackfeld@lightcurve.io:

Dear Lisk community,

I tried to summarize the main discussion points and concerns raised so

far and addressed them below.

Cheers,

Jan

  1. Claim: A new voting system is likely to imply higher reward sharing.

The general consensus is that one vote per account would lead to a

stronger competition for the delegate slots and as a large fraction of

votes would be based on the percentage of shared rewards, delegates

sharing larger fractions of rewards would get elected (cc001 elaborates

on this in more detail). One may also ask the question why a delegate

promising higher rewards does not get elected now (Vít posed this

question). In my opinion, the main reason is that the voting pools have

by far the largest influence on the decision of who becomes delegates

(as also said by Santerr).

In my opinion, a system of one vote per account reflects the interest of

account holders (e.g. maximum personal gain or supporting active

community members) much better. For instance, a person with strong

expertise and good community involvement has a realistic chance of

becoming delegate (after convincing account holders with a balance of

around 500,000 LSK, see LIP for details), whereas it currently is almost

impossible to become an active delegate without the support by a voting

pool. Overall, delegates will probably be elected because of a mix of

several factors (people voting selfish and people considering

involvement/reliability/other factors) and the community will determine

in which direction the system moves.

  1. Claim: If delegates receive a smaller percentage of the rewards, they

are likely to have lower up time, run nodes on cheaper machines and

perform updates less timely.

In my opinion, it is important not to exaggerate the issue of missed

block slots. For instance, assume that 5 % of the block slots would be

missed. This simply means that the Lisk blockchain is able to process 5%

less transactions and the respective delegates miss out on the block

rewards (less inflation). This is not a security problem. Note that LIP

002 proposes to change to a byte based block size and Lisk would be able

to process around 120 transactions per block. Moreover, 5 % less

transaction capacity would mean higher transaction fees if blocks are

full as the demand is the same, but the overall supply of block space is

reduced by 5 %.

Moreover, if we believe that low productivity poses a problem and

forfeit block rewards do not give a strong enough incentive, then

additional slashing conditions could be put in place. For instance,

delegates could lose the value of the block reward (or even 5 times the

block reward) every time they miss a block.

Less timely updates, e.g. during a hard fork, would also lead to a

number of missed block slots of the respective delegates. So basically

the same argument as above applies. If it is an update due to a security

fix, then this topic is discussed below dealing with the impact on security.

Running Lisk Core on a cheaper nodes should not be a problem if the

delegate manages to forge reliably. Otherwise, the line of reasoning

regarding the productivity applies.

  1. Claim: If delegates receive a smaller percentage of the rewards, they

are more likely to be bribed. Thus, the proposed voting will have a

negative impact on the security of the network.

In my opinion, the security of a delegated proof-of-stake blockchain

cannot exclusively rely on block rewards (otherwise, we would say, for

instance, if delegates get 5,000 Euros/month the network is secure, but

if they only get 500 Euros/month the network is insecure). That is why

we propose to introduce Byzantine fault tolerance (roadmap objective

“Improve blocks verification“) and additional deposits/slashing (roadmap

objective “Punish protocol violations by delegates”) to the protocol. We

have not finalized the proposal draft, but we would probably require a

security deposit by delegates. For instance, if we have a security

deposit of 20,000 LSK for every delegate and up to 33 delegates can be

malicious due to Byzantine fault tolerance, then more than 680,000 LSK

of deposits (i.e., deposits by at least 34 delegates) would be slashed

if two contradicting blocks would be finalized. This is a much stronger

security guarantee than relying on future block rewards (note that you

can do a 51 % attack on basically all proof-of-work cryptocurrencies

with this amount of money https://www.crypto51.app/ and the attack on

Ethereum Classic showed that this is a real danger).

  1. Claim: The proposal poses a security problem as a malicious entity

with 1/101 fraction of the Lisk stake can permanently remain delegate

and disrupt the system.

This issue is already discussed in detail in the section “Impact on

Security” in the LIP. Basically, the only malicious attack one single

delegate can do is to not forge (see also discussion of productivity

above). Further note that in a separate LIP we will propose a

banning/punishment of delegates that are offline for an extended period

of time (see section “Dependence on Delegate Productivity” in the LIP

draft). Thus if a delegate loses their private key, for instance, they

would eventually be banned/punished and cannot indefinitely harm the

Lisk network.

  1. Claim: Delegates will contribute a lot less to the community (via

Meetups, Lisk Centers, community donations).

Many delegates definitely do awesome additional work, which is

appreciated by the community, but many also simply take the money. In my

opinion, the community efforts (Lisk Center, meetups, donations) are not

a result of the current voting system, but rather because there are

idealistic people involved in Lisk. There are also other people who make

a lot of community contributions (more than many active delegates) and

are trying to become active delegates, but fail as they are not

supported by the pools. I would personally be happy to see another

democratic, transparent and fair way to support community initiatives

(Santerr proposed the creation of a DAO).

  1. Claim: There will still be voting pools.

There is of course no guarantee that in the proposed system of one vote

per account there will be no voting pools. One of our main reasons for

proposing one vote per account is to have a voting system that does not

give incentives to pools (there can be other social factors to form a

pool, but these are incentives outside the voting system). For instance,

one account holder cannot be forced to vote for all members of a pool as

only one vote is possible. Two or more delegates also cannot strengthen

their position by voting for each other, which is happening now. Of

course the current pools have a considerable amount of stake and could

still secure several delegate slots, but far less than they currently

have (As explained in the LIP, x % of stake are sufficient to secure x

delegate slots). In this regard, the current delegate pools are as

powerful as any other group/individual with a significant amount of stake.

  1. Claim: With one vote per account only whales become delegates.

According to the estimates in the LIP approximately 500,000 LSK are

sufficient to secure one delegate slot. So a whale with this amount of

LSK can become delegate or any group of people that together has this

amount of LSK. If only whales would become delegates and no group of

account holders with smaller balances can join to put one delegate in

place, then this would mean that 99 % of the voting tokens are owned by

101 whales.

  1. Suggestion by cc001: People want to vote for more than one delegate,

so alternatively the vote weight of an account could be (account

balance)/(# of votes).

As observed by cc001, changing to one vote per account is equivalent to

changing the vote weight to (account balance)/(# of votes). For

instance, if an account holder owns 900 LSK and casts three votes, then

each vote would have weight 300 LSK if the vote weight is given by

(account balance)/(# of votes). In the proposed system of one vote per

account, the account holder could split the 900 LSK into 3 accounts with

300 LSK each and cast a different vote with each of the accounts. This

would then have the same effect. The disadvantage is that this creates

the additional inconvenience to manage multiple accounts and users have

to pay additional fees for splitting the account and casting multiple

votes. The benefit of one vote per account, in my opinion, is that the

voting system is simpler. Furthermore, it adds an additional barrier

against formation of pools as multiple accounts need to be managed to

vote for all members of a pool. It would be great to also have the

suggestion by cc001 drafted as a separate LIP.

LIPS mailing list

LIPS@lists.lisk.io

http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io

Hey Jan

Thanks for your extensive summary.

I think I have to repeat my main concern(s) again though, I'm not sure if you really understood what I tried to say. I do this because I think it is very important for the future of Lisk and I think it is very dangerous if you really go with this 1-vote, because of two reasons:
1. See my concerns below, I think it could harm Lisk tremendously and it can't be undone. I'll also answer on your claims below.
2. Most of the community are against this proposal, and a lot of different suggestions how to improve it has been posted. I think it does not look good if you push something through against the majority, especially because Lisk always mentions how important the community and their opinion on something is for them.

My main concern is the following: It seems you completely underestimate the amount of people voting only to receive the highest possible reward. I'd say only 5% of all votes are based on idealism and voting for good delegates, not related to received rewards. Probably 95% of the votes are ONLY based on the received rewards. This has huge implications if you introduce the 1-vote-per-account change. It's nothing technical but based on human nature, economy and game theory.
If almost no people vote based on idealism but only on rewards, the final top 101 will only contain unknown delegates sharing 95% or more. And here comes my main concern you seem to neglect: There will be only very few people willing to do complimentary work to support Lisk and the community. Yes there might be a few. But also those who do it now and are not forging yet, do it either because they hope to become forging sometime (I hope they will!) or because they get some donations from forging delegates. (or both). But this will change when it becomes obvious that there won't be any rewards because forging delegates won't donate anymore and become a forging delegate will only be possible if you are willing to share more than 95%. No matter how much good work you do for Lisk.
Basically, ALL community work around Lisk will stop. This is exactly the opposite of the idea behind DPOS do let people become forging who deserves it because they do great work for Lisk.

See my detailed answers to your claims below:

1) Claim: A new voting system is likely to imply higher reward sharing.

The general consensus is that one vote per account would lead to a stronger competition for the delegate slots and as a large fraction of votes would be based on the percentage of shared rewards, delegates sharing larger fractions of rewards would get elected (cc001 elaborates on this in more detail). One may also ask the question why a delegate promising higher rewards does not get elected now (Vít posed this question). In my opinion, the main reason is that the voting pools have by far the largest influence on the decision of who becomes delegates (as also said by Santerr).

No. The main reason is that there is a huge cliff on 101. Everybody who votes a delegate outside of 101 doesn't get any reward until this delegate becomes forging. Because of that big cliff, it takes very long time until a new delegate becomes forging (if ever), and only if all others vote him too (and are willing to pay for that with their missing rewards until he can enter 101) he has a chance to enter. Basically, everybody thinks that the others should vote him first, and when he is very close to 101 I will vote him too, to not miss too much of my rewards. And the result is that nobody votes him. It's not because of the voting pools. If there were no voting pools, all individual delegates would also share a percentage and voters would also vote the top 101, because this will bring them the maximum rewards. It would be the exact same situation, nobody will change their vote because they don't want to miss their rewards. This point has nothing to do with pools/groups.

In my opinion, a system of one vote per account reflects the interest of account holders (e.g. maximum personal gain or supporting active community members) much better. For instance, a person with strong expertise and good community involvement has a realistic chance of becoming delegate (after convincing account holders with a balance of around 500,000 LSK, see LIP for details), whereas it currently is almost impossible to become an active delegate without the support by a voting pool. Overall, delegates will probably be elected because of a mix of several factors (people voting selfish and people considering involvement/reliability/other factors) and the community will determine in which direction the system moves.

The exact opposite is the case. Now, people can vote idealistically AND economically by voting 90 top 101 delegates to get rewards, and 11 great standby delegates. This means, they get 90% of the possible rewards, and sacrifice 10% of their possible income to vote idealistically for good non-forging-delegates. With your change, that's not possible anymore. You will be able only to vote idealistically OR economically, not both. Already now, most of the people vote only economically, even if it would be pretty cheap to add some idealistic votes. I'm very sure that almost nobody will sacrifice 100% of their income to vote ideologically, especially not the big accounts!

2) Claim: If delegates receive a smaller percentage of the rewards, they are likely to have lower up time, run nodes on cheaper machines and perform updates less timely.

In my opinion, it is important not to exaggerate the issue of missed block slots. For instance, assume that 5 of the block slots would be missed\. This simply means that the Lisk blockchain is able to process 5 less transactions and the respective delegates miss out on the block rewards (less inflation). This is not a security problem. Note that LIP 002 proposes to change to a byte based block size and Lisk would be able to process around 120 transactions per block. Moreover, 5 less transaction capacity would mean higher transaction fees if blocks are full as the demand is the same, but the overall supply of block space is reduced by 5 .

Moreover, if we believe that low productivity poses a problem and forfeit block rewards do not give a strong enough incentive, then additional slashing conditions could be put in place. For instance, delegates could lose the value of the block reward (or even 5 times the block reward) every time they miss a block.

Less timely updates, e.g. during a hard fork, would also lead to a number of missed block slots of the respective delegates. So basically the same argument as above applies. If it is an update due to a security fix, then this topic is discussed below dealing with the impact on security.

Running Lisk Core on a cheaper nodes should not be a problem if the delegate manages to forge reliably. Otherwise, the line of reasoning regarding the productivity applies.

You miss the point completely here. The problem with the small percentage of rewards is not missing blocks. The problem is that delegates won't care about their nodes and Lisk, because they earn so little with it. And it will not only take 24h until 50% of all nodes upgraded after a secure security issue like it happened lately, but it will take probably weeks or even longer. And they will not do any work for Lisk like developing Hardware wallet support, setting up Lisk Centers, etc...

3) Claim: If delegates receive a smaller percentage of the rewards, they are more likely to be bribed. Thus, the proposed voting will have a negative impact on the security of the network.

In my opinion, the security of a delegated proof-of-stake blockchain cannot exclusively rely on block rewards (otherwise, we would say, for instance, if delegates get 5,000 Euros/month the network is secure, but if they only get 500 Euros/month the network is insecure). That is why we propose to introduce Byzantine fault tolerance (roadmap objective “Improve blocks verification“) and additional deposits/slashing (roadmap objective “Punish protocol violations by delegates”) to the protocol. We have not finalized the proposal draft, but we would probably require a security deposit by delegates. For instance, if we have a security deposit of 20,000 LSK for every delegate and up to 33 delegates can be malicious due to Byzantine fault tolerance, then more than 680,000 LSK of deposits (i.e., deposits by at least 34 delegates) would be slashed if two contradicting blocks would be finalized. This is a much stronger security guarantee than relying on future block rewards (note that you can do a 51 % attack on basically all proof-of-work cryptocurrencies with this amount of money https://www.crypto51.app/ and the attack on Ethereum Classic showed that this is a real danger).

I support a security deposit. But nobody will do a 25k USD security deposit if they know they can only earn $100 per month!! That's like having ONLY RISK and almost no reward...

About the bribing. It would be very cheap for a competitive blockchain project to bribe some delegates, to disturb the chain. I agree, it might not be such a big security issue, because it is not easy to bribe and coordinate 51 delegates. But they could pay like 30 delegates to deliberately miss blocks or double forge. It doesn't look very good if the chain misses 30% of all blocks, has forks all the time, Exchanges can't accept deposits and withdraws because of that, and so on... It would be very easy and very cheap to harm the public image of Lisk by doing this.

4) Claim: The proposal poses a security problem as a malicious entity with 1/101 fraction of the Lisk stake can permanently remain delegate and disrupt the system.

This issue is already discussed in detail in the section “Impact on Security” in the LIP. Basically, the only malicious attack one single delegate can do is to not forge (see also discussion of productivity above). Further note that in a separate LIP we will propose a banning/punishment of delegates that are offline for an extended period of time (see section “Dependence on Delegate Productivity” in the LIP draft). Thus if a delegate loses their private key, for instance, they would eventually be banned/punished and cannot indefinitely harm the Lisk network.

I don't see a problem here, even with 1-vote-per account.

5) Claim: Delegates will contribute a lot less to the community (via Meetups, Lisk Centers, community donations).

Many delegates definitely do awesome additional work, which is appreciated by the community, but many also simply take the money. In my opinion, the community efforts (Lisk Center, meetups, donations) are not a result of the current voting system, but rather because there are idealistic people involved in Lisk. There are also other people who make a lot of community contributions (more than many active delegates) and are trying to become active delegates, but fail as they are not supported by the pools. I would personally be happy to see another democratic, transparent and fair way to support community initiatives (Santerr proposed the creation of a DAO).

The community efforts definitely happen mostly because of the rewards. Either directly to the delegates or via donations from forging delegates to the community members. I know quite a few delegates who quit their regular job, working full time for Lisk now. This is only possible because of the rewards. When those rewards fail (because 95%+ is given away), all those activities will stop because people will go back to their regular jobs. Yes there are a few idealistic people, they are great, but they are only a few, and even they do a lot of it because they hope to become delegate sometimes. And those people got a lot of financial support from forging delegates and pools via donations.

6) Claim: There will still be voting pools.

There is of course no guarantee that in the proposed system of one vote per account there will be no voting pools. One of our main reasons for proposing one vote per account is to have a voting system that does not give incentives to pools (there can be other social factors to form a pool, but these are incentives outside the voting system). For instance, one account holder cannot be forced to vote for all members of a pool as only one vote is possible. Two or more delegates also cannot strengthen their position by voting for each other, which is happening now. Of course the current pools have a considerable amount of stake and could still secure several delegate slots, but far less than they currently have (As explained in the LIP, x % of stake are sufficient to secure x delegate slots). In this regard, the current delegate pools are as powerful as any other group/individual with a significant amount of stake.

There will always be voting pools, as long as voting is not anonymous. You can't prevent it. You have to set the right incentives to diminish the negative impact of them, which you fail with the 1-vote-per-account proposal.

7) Claim: With one vote per account only whales become delegates.

According to the estimates in the LIP approximately 500,000 LSK are sufficient to secure one delegate slot. So a whale with this amount of LSK can become delegate or any group of people that together has this amount of LSK. If only whales would become delegates and no group of account holders with smaller balances can join to put one delegate in place, then this would mean that 99 % of the voting tokens are owned by 101 whales.

Not only whales. But quite a few. But the bigger problem will be sockpuppet accounts. I fear there will be at least 90 unknown sockpuppet delegates, sharing 95-99%, and nobody has ever seen them in the chat.

8) Suggestion by cc001: People want to vote for more than one delegate, so alternatively the vote weight of an account could be (account balance)/(# of votes).

As observed by cc001, changing to one vote per account is equivalent to changing the vote weight to (account balance)/(# of votes). For instance, if an account holder owns 900 LSK and casts three votes, then each vote would have weight 300 LSK if the vote weight is given by (account balance)/(# of votes). In the proposed system of one vote per account, the account holder could split the 900 LSK into 3 accounts with 300 LSK each and cast a different vote with each of the accounts. This would then have the same effect. The disadvantage is that this creates the additional inconvenience to manage multiple accounts and users have to pay additional fees for splitting the account and casting multiple votes. The benefit of one vote per account, in my opinion, is that the voting system is simpler. Furthermore, it adds an additional barrier against formation of pools as multiple accounts need to be managed to vote for all members of a pool. It would be great to also have the suggestion by cc001 drafted as a separate LIP.

I'm not talking about 3 accounts. I'm talking about 30-50 people I want to vote for. Nobody will do this work and accepts the costs to manage 50 different accounts. This will result in the situation where people would like to vote for much more people than they can, which is not desirable.

I'm not sure if it's really so much simpler to tell people that they only have one vote instead of 101 votes or 131 votes. If I have to elect my government, they tell me I have to vote for 5 people, or 10 people, or 1 people. No issue at all.

I repeat my main points: It's not about missing blocks or technical security. The problem will be that all community activity and voluntary work for Lisk will stop, because the low rewards are not worth any additional work anymore. Delegates won't care about Lisk anymore, they just take the $100 per month. And if they lose that, it's not so bad, it's only $100. The quality of the delegates will become very low. They will miss blocks more often, they will not upgrade in a timely manner, they will not install security fixes. They could even try to hurt the blockchain because they get bribed to do so, which could hurt the public image of Lisk tremendously. And once you have those army of 95%+-sharing-socks in the top 101, you won't be able go back again.

I hope you listen to the community and don't implement this 1-vote-per-account proposal, it will hurt Lisk tremendously.

···

On 14.02.19 11:29, Jan Hackfeld wrote:

Hi Vít

The problem why nobody votes rank 102 and higher right now is because of two reasons:
* Because people only have 101 votes to vote 101 delegates, they get the maximum reward if they vote the top 101. If they want to vote for rank 102 and higher, it would cost them the rewards of the vote they would have to remove from top 101.
* Because of the high cliff at rank 101, it takes very long time until a new delegate could enter rank 101. This means, people would lose money for a long time if they would vote for rank 102 or higher.

I made a proposal here how we could change that. In my opinion this would be MUCH better than the 1-vote proposal: We should increase to 131 possible votes, this would remove the 101 cliff (or at least lower it significantly) and would make it much easier for new delegates to enter:

https://lists.lisk.io/pipermail/lips_lists.lisk.io/2019-February/000039.html

cc001

···

On 06.02.19 13:02, Vit Stanislav wrote:

Hi cc001,
I very much enjoyed reading your explanation of what "one vote per account" will lead to. I'm not strongly convinced it will happen, but I'm interested in understanding the scenario better. One thing I miss mentioned there explicitly is why the scenario you describe applies to the proposed "one vote per account" and not to the current "101 votes per account". I can think of some reasons, but I'm no expert in economics or game theory, so I would like to read your explanation.

Can you please elaborate on that for me and others that might wonder about the same question?

Thank you,
Vít

On Tue, Feb 5, 2019 at 10:40 PM cc001 <cc001.bct@gmail.com > <mailto:cc001.bct@gmail.com>> wrote:

    In my opinion the only purpose (or at least the most important
    one) of
    the voting system is to guarantee a secure and an efficient
    network/blockchain. If the voting system can not guarantee the
    security
    and efficiency of the blockchain, it is not suitable for Lisk, no
    matter
    if it has all desired properties listed in the proposed LIP.

    I will explain in the following why in my opinion the "one vote per
    account" system will lead to an inefficient and maybe even an
    insecure
    blockchain/network and why it is therefore not suitable for Lisk.
    This
    is not because of technical aspects, but because of economical and
    game-theory aspects.

    TLDR: The "one vote per account" system will lead to 101 delegates
    not
    caring about the integrity, efficiency and security of the network
    because they will have not enough financial incentive to do so. They
    will use the cheapest possible nodes, they won't update their
    nodes in a
    timely manner when critical security fixes should be applied, they
    won't
    care about missed blocks, they won't use their time to promote and
    support Lisk in any way and they will be bribeable for very low cost.

    Let me explain why:
    The following will happen in the long run: Well, I think it could
    happen
    pretty quickly, because the voters and delegates already know the
    drill
    from other DPOS systems like ARK, Oxy, etc...
    But let's assume we play the game from the beginning, in little steps:

    1. delegates will offer very little rewards, let's say 0-5%.
    2. people will vote for those who offer 5%, and 101 delegates
    offering
    5% will be forging.
    3. clever standby delegate on rank 102 will offer 10% to give voters
    more incentive to vote him instead of one of the top 101, to join the
    forging position.
    4. voters will vote for the 10%-delegate on rank 102 (because they
    will
    get more rewards by doing this), who will finally replace the
    5%-delegate on rank 101.
    5. delegates on rank 102 - 150 will offer the same, 10%, maybe also
    delegates on rank 1 - 101 will increase their rewards.
    6. this will lead to a situation where all forging delegates on
    rank 1 -
    101 will offer 10%, until rank 102 begins to offer 20% and step 4 - 6
    will repeat with 20%.
    7. This cycle will continue with increasing sharing rewards.
    ...
    Delegates will continue to share more and more, until everybody
    shares
    around 95-99%. Actually, an equilibrium will happen, at the point
    when
    delegates share so much, that their income (maybe 1-5%) barely covers
    their costs. To reduce their costs, they will use the cheapest
    possible
    $3/month VPS nodes, they will spend as little time as possible for
    Lisk,
    and they won't care about their nodes, because they earn almost
    nothing
    anyways, it doesn't matter for them if they miss blocks or if they
    become unvoted. If people think this is no problem because they can
    unvote those sloppy delegates and simply vote for better
    delegates, they
    are wrong. There won't be better delegates, because every delegate
    will
    HAVE TO give 95-99%+ rewards to have a chance to join 101 and for an
    income of like $100 per month, there won't be many offering a good
    delegate job.

    The end result will be, that those 101 forging delegates have
    extremely
    little financial incentive to run their nodes in a secure and
    reliable
    manner. They won't care about the network or the ecosystem. Even
    worse,
    they could earn more by accepting bribe money. The LIP explains the
    situation about bribing, it is not too easy to bribe 51 delegates
    to do
    real harm to the network. But still, it would be very cheap for a
    competitor blockchain to bribe a fair amount of delegates (which
    don't
    even have to be coordinated) to disturb the Lisk blockchain severely.

    For voters those 95% sharing rewards might sound like heaven. BUT:
    the
    high LSK rewards will be worth nothing when the blockchain is
    insecure,
    is inefficient, is not upgraded in a timely manner when crucial
    security
    fixes should be applied, because this will lead to falling LSK
    prices on
    the market. You could even lose your LSK if the blockchain is not
    secured properly by financially incentivised, serious delegates.

    Another reason why I don't like the "one vote per account" system is
    that I want to vote for multiple delegates, because there are many
    great
    people in our community! I can't and don't want to reduce my vote to
    only one single delegate. I know at least 50 delegates who definitely
    would earn my vote. I would definitely prefer a system where I can
    vote
    multiple people and everyone gets (account balance)/(# of votes)
    voting
    weight from me. Of course I could split into 30 accounts, but it's
    too
    much of a hurdle to do that and it would need quite some LSK for
    paying
    the fees.

    Because in my opinion the "one vote account" would lead to an
    inefficient, abandoned and insecure blockchain I refuse this proposal
    severely.

    -- LIPS mailing list
    LIPS@lists.lisk.io <mailto:LIPS@lists.lisk.io>
    http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io

Dear Dutch Pool,

thank you for sharing you ideas on the mailing list.

Your suggestion is actually addressing both of our roadmap objectives, "Change voting system" and "Incentivise standby delegates", which we decided to treat in separate LIPs. To give more delegates the possibility of forging is also what we a exploring and Iker is currently working on. Maybe, you could also split your proposal into two parts so we can have separate discussions on the 2 aspects of DPoS:

1) How many votes can an account cast and what is the weight of every vote?
You propose balance/#votes

2) Considering all votes, which delegates are eligible for forging blocks and what is the probability of delegates forging blocks?

You propose: Top 201 delegates, forging proportional to delegate weight.

Regarding the productivity, I wonder how you define it. If you define it only for blocks in the last month (#forged blocks/# block slots), then it could open the possibility of long range attacks (or history attack): In an alternative chain that is completely valid, all delegates are banned because they don't forge for a month and delegate with very small weight get into place. Nodes joining the network and synchronizing from genesis could believe this is the correct chain.

Cheers,
Jan

Dear cc001,

thanks for your input. I try to address it below and will discuss your alternative proposal in another email.

Cheers,
Jan

Hey Jan

Thanks for your extensive summary.

I think I have to repeat my main concern(s) again though, I'm not sure if you really understood what I tried to say. I do this because I think it is very important for the future of Lisk and I think it is very dangerous if you really go with this 1-vote, because of two reasons:
1. See my concerns below, I think it could harm Lisk tremendously and it can't be undone. I'll also answer on your claims below.
2. Most of the community are against this proposal, and a lot of different suggestions how to improve it has been posted. I think it does not look good if you push something through against the majority, especially because Lisk always mentions how important the community and their opinion on something is for them.

Please understand that the purpose of the mailing list is for reasoning and scientific discussion. The science team does not make the decision, which LIP gets implemented. For the new voting system it would be great to see multiple alternative LIPs be draftend and a PR be opened on GitHub (https://github.com/LiskHQ/lips).

Please also refer to our blog for an explanation of the LIP process:

Note that there also has been a lot of unhappiness expressed from the community regarding the current voting system and therefore it is one roadmap objective to improve it.

My main concern is the following: It seems you completely underestimate the amount of people voting only to receive the highest possible reward. I'd say only 5% of all votes are based on idealism and voting for good delegates, not related to received rewards. Probably 95% of the votes are ONLY based on the received rewards. This has huge implications if you introduce the 1-vote-per-account change. It's nothing technical but based on human nature, economy and game theory.
If almost no people vote based on idealism but only on rewards, the final top 101 will only contain unknown delegates sharing 95% or more. And here comes my main concern you seem to neglect: There will be only very few people willing to do complimentary work to support Lisk and the community. Yes there might be a few. But also those who do it now and are not forging yet, do it either because they hope to become forging sometime (I hope they will!) or because they get some donations from forging delegates. (or both). But this will change when it becomes obvious that there won't be any rewards because forging delegates won't donate anymore and become a forging delegate will only be possible if you are willing to share more than 95%. No matter how much good work you do for Lisk.
Basically, ALL community work around Lisk will stop. This is exactly the opposite of the idea behind DPOS do let people become forging who deserves it because they do great work for Lisk.

I agree that probably higher percentage of rewards are shared (see summary point 1) and I don't see a problem with that (see summary point 2). In terms of community involvement, I believe an alternative system that supports this (not rewards for delegates, see summary 5) is needed as the voting system does not really incentivise it and it is only due to the idealism of a part of the current delegates (many are also not active).

I think in a fair voting system delegates are representing the interests of the voters. If you say that 95 % of the votes are only interested in rewards, then the effect of any voting system that allows for a fair competition is that delegates with the highest percentage of rewards will be active.

See my detailed answers to your claims below:

1) Claim: A new voting system is likely to imply higher reward sharing.

The general consensus is that one vote per account would lead to a stronger competition for the delegate slots and as a large fraction of votes would be based on the percentage of shared rewards, delegates sharing larger fractions of rewards would get elected (cc001 elaborates on this in more detail). One may also ask the question why a delegate promising higher rewards does not get elected now (Vít posed this question). In my opinion, the main reason is that the voting pools have by far the largest influence on the decision of who becomes delegates (as also said by Santerr).

No. The main reason is that there is a huge cliff on 101. Everybody who votes a delegate outside of 101 doesn't get any reward until this delegate becomes forging. Because of that big cliff, it takes very long time until a new delegate becomes forging (if ever), and only if all others vote him too (and are willing to pay for that with their missing rewards until he can enter 101) he has a chance to enter. Basically, everybody thinks that the others should vote him first, and when he is very close to 101 I will vote him too, to not miss too much of my rewards. And the result is that nobody votes him. It's not because of the voting pools. If there were no voting pools, all individual delegates would also share a percentage and voters would also vote the top 101, because this will bring them the maximum rewards. It would be the exact same situation, nobody will change their vote because they don't want to miss their rewards. This point has nothing to do with pools/groups.

In my opinion, a system of one vote per account reflects the interest of account holders (e.g. maximum personal gain or supporting active community members) much better. For instance, a person with strong expertise and good community involvement has a realistic chance of becoming delegate (after convincing account holders with a balance of around 500,000 LSK, see LIP for details), whereas it currently is almost impossible to become an active delegate without the support by a voting pool. Overall, delegates will probably be elected because of a mix of several factors (people voting selfish and people considering involvement/reliability/other factors) and the community will determine in which direction the system moves.

The exact opposite is the case. Now, people can vote idealistically AND economically by voting 90 top 101 delegates to get rewards, and 11 great standby delegates. This means, they get 90% of the possible rewards, and sacrifice 10% of their possible income to vote idealistically for good non-forging-delegates. With your change, that's not possible anymore. You will be able only to vote idealistically OR economically, not both. Already now, most of the people vote only economically, even if it would be pretty cheap to add some idealistic votes. I'm very sure that almost nobody will sacrifice 100% of their income to vote ideologically, especially not the big accounts!

2) Claim: If delegates receive a smaller percentage of the rewards, they are likely to have lower up time, run nodes on cheaper machines and perform updates less timely.

In my opinion, it is important not to exaggerate the issue of missed block slots. For instance, assume that 5 % of the block slots would be missed. This simply means that the Lisk blockchain is able to process 5 % less transactions and the respective delegates miss out on the block rewards (less inflation). This is not a security problem. Note that LIP 002 proposes to change to a byte based block size and Lisk would be able to process around 120 transactions per block. Moreover, 5 % less transaction capacity would mean higher transaction fees if blocks are full as the demand is the same, but the overall supply of block space is reduced by 5 %.

Moreover, if we believe that low productivity poses a problem and forfeit block rewards do not give a strong enough incentive, then additional slashing conditions could be put in place. For instance, delegates could lose the value of the block reward (or even 5 times the block reward) every time they miss a block.

Less timely updates, e.g. during a hard fork, would also lead to a number of missed block slots of the respective delegates. So basically the same argument as above applies. If it is an update due to a security fix, then this topic is discussed below dealing with the impact on security.

Running Lisk Core on a cheaper nodes should not be a problem if the delegate manages to forge reliably. Otherwise, the line of reasoning regarding the productivity applies.

You miss the point completely here. The problem with the small percentage of rewards is not missing blocks. The problem is that delegates won't care about their nodes and Lisk, because they earn so little with it. And it will not only take 24h until 50% of all nodes upgraded after a secure security issue like it happened lately, but it will take probably weeks or even longer. And they will not do any work for Lisk like developing Hardware wallet support, setting up Lisk Centers, etc...

3) Claim: If delegates receive a smaller percentage of the rewards, they are more likely to be bribed. Thus, the proposed voting will have a negative impact on the security of the network.

In my opinion, the security of a delegated proof-of-stake blockchain cannot exclusively rely on block rewards (otherwise, we would say, for instance, if delegates get 5,000 Euros/month the network is secure, but if they only get 500 Euros/month the network is insecure). That is why we propose to introduce Byzantine fault tolerance (roadmap objective “Improve blocks verification“) and additional deposits/slashing (roadmap objective “Punish protocol violations by delegates”) to the protocol. We have not finalized the proposal draft, but we would probably require a security deposit by delegates. For instance, if we have a security deposit of 20,000 LSK for every delegate and up to 33 delegates can be malicious due to Byzantine fault tolerance, then more than 680,000 LSK of deposits (i.e., deposits by at least 34 delegates) would be slashed if two contradicting blocks would be finalized. This is a much stronger security guarantee than relying on future block rewards (note that you can do a 51 % attack on basically all proof-of-work cryptocurrencies with this amount of money https://www.crypto51.app/ and the attack on Ethereum Classic showed that this is a real danger).

I support a security deposit. But nobody will do a 25k USD security deposit if they know they can only earn $100 per month!! That's like having ONLY RISK and almost no reward...

If nobody want to do it, then this just means that delegates will actually share less rewards. Demand and supply determine a fair price.

About the bribing. It would be very cheap for a competitive blockchain project to bribe some delegates, to disturb the chain. I agree, it might not be such a big security issue, because it is not easy to bribe and coordinate 51 delegates. But they could pay like 30 delegates to deliberately miss blocks or double forge. It doesn't look very good if the chain misses 30% of all blocks, has forks all the time, Exchanges can't accept deposits and withdraws because of that, and so on... It would be very easy and very cheap to harm the public image of Lisk by doing this.

Delegates can still be downvoted. To permanently sustain 30 delegates you would need around 30 % of the voting Lisk tokens. Moreover, all delegates double forging would loose their deposit and would be permanently banned if the punishment mechanism is in place.

“I agree that if people ONLY vote based on maximal gain (shared
rewards), then the delegates with the highest percentage of shared
rewards will get into the top 101 slots. However, if people also value
other factors (expertise in running a node, community involvement,…),
then these factors matter and a person with a good community
involvement, for instance, has a realistic chance of becoming a delegate”

If this were true, then the current system would work just fine. Unfortunately a large majority of voters are always going to vote for maximum profit. This proposal does not really change that.

"I also don’t clearly see that sharing a high percentage of rewards is

a problem"

This is actually a significant problem for several reasons (in no particular order):

**1. Less motivation and resources for delegates to maintain near perfect up time. **

2. Much less Lisk to give away to deserving causes (Community donations, Lisk Centers, Meetups, Projects, etc.)

3. Reduced price of Lisk - Voters are more likely to dump than delegates

4. Increased likelihood of delegates being bribed

5. Less incentive to actually become a delegate in the first place, which actually leads to less competition

I agree that we need to make changes to our consensus algorithm, for several reasons. However, IMO, implementing a 1 vote per account solution will actually do more harm than good. We should be looking at solutions that give an incentive for voters to vote for highly productive delegates, rather than their sharing percentage. We should not be settling on a questionable band aid to the problem.

*“We are always willing to find solutions, not compromises” - Max Kordek *

···

On Wed, Feb 6, 2019 at 12:00 PM lips-request@lists.lisk.io wrote:

Send LIPS mailing list submissions to

    lips@lists.lisk.io

To subscribe or unsubscribe via the World Wide Web, visit

    [http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io](http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io)

or, via email, send a message with subject or body ‘help’ to

    lips-request@lists.lisk.io

You can reach the person managing the list at

    lips-owner@lists.lisk.io

When replying, please edit your Subject line so it is more specific

than “Re: Contents of LIPS digest…”

Today’s Topics:

  1. Re: Change to one vote per account (Jan Hackfeld)

Message: 1

Date: Wed, 6 Feb 2019 14:45:40 +0100

From: Jan Hackfeld jan.hackfeld@lightcurve.io

To: lips@lists.lisk.io

Subject: Re: [LIPS] Change to one vote per account

Message-ID: 992126ef-1cca-165d-c455-6ccc25e57660@lightcurve.io

Content-Type: text/plain; charset=utf-8; format=flowed

Hi cc001,

thank you very much for your input.

Before addressing your concerns, let me emphasize that the whole LIP

process is designed to make the whole evolution of Lisk transparent and

include the expertise and knowledge of the community. So it would be

great to have several sound, well-reasoned proposals for a new voting

system in order to carefully weigh the arguments and choose the best

solution (maybe combining different proposals).

Regarding your reasoning below:

  1. I agree that if people ONLY vote based on maximal gain (shared

rewards), then the delegates with the highest percentage of shared

rewards will get into the top 101 slots. However, if people also value

other factors (expertise in running a node, community involvement,…),

then these factors matter and a person with a good community

involvement, for instance, has a realistic chance of becoming a delegate

(after convincing account holders with a balance of around 500,000 LSK,

see LIP for details). Currently, this is not really possible. Overall,

it will probably be a mix of both (people voting selfish and people

considering involvement/other factors) and the community will determine

in which direction the system moves.

  1. The LIP already discusses the security implications of the proposed

change of the voting system in detail and makes it clear that only a

large number of malicious delegates would pose a serious threat.

Furthermore, we have several other proposals on the roadmap that will

substantially increase the security guarantees:

  • The objective ‘Improve blocks verification’ proposes to add Byzantine

fault tolerance to the protocol. This means that the protocol will

tolerate malicious/Byzantine delegate up to a certain threshold.

  • The objective ‘Punish protocol violations by delegates’ will add a

mechanism to the protocol that punishes a delegate if it can be proven

on the blockchain undoubtfully that the delegate acted maliciously. We

haven’t finalized the research and specifications, but think of a 10,000

LSK security deposit (value is to be decided) that a delegate loses if

they do something malicious.

  1. I also don’t clearly see that sharing a high percentage of rewards is

a problem. Most delegates have and most likely will have a considerable

amount of Lisk (it could be discussed if this should be enforced by the

protocol). Take for example a delegate that shares 100 % of the rewards

(extreme case, likely it will be less), but also owns 50,000 LSK (and

votes for themself). According to the estimates in the LIP, votes by

additional 450,000 LSK would be approximately sufficient to secure an

active delegate slot. In this case, 10 % of the rewards go to the

delegate (10 of the vote weight is from the delegate itself), 90 to

all other votes. Everybody would be interested to keep productivity high

as otherwise they lose money. Moreover, delegates can be voted out of

the 101 much easier if the productivity is low (much less people have to

change their votes).

I am happy to discuss more!

Cheers,

Jan

On 2/6/19 1:02 PM, Vit Stanislav wrote:

Hi cc001,

I very much enjoyed reading your explanation of what "one vote per

account" will lead to. I’m not strongly convinced it will happen, but

I’m interested in understanding the scenario better. One thing I miss

mentioned there explicitly is why the scenario you describe applies to

the proposed “one vote per account”? and not to the current "101 votes

per account". I can think of some reasons, but I’m no expert in

economics or game theory, so I would like to read your?explanation.

Can you please elaborate on that for me and others that might wonder

about the same question?

Thank you,

V?t

On Tue, Feb 5, 2019 at 10:40 PM cc001 <cc001.bct@gmail.com > > > mailto:cc001.bct@gmail.com> wrote:

In my opinion the only purpose (or at least the most important one) of
the voting system is to guarantee a secure and an efficient
network/blockchain. If the voting system can not guarantee the security
and efficiency of the blockchain, it is not suitable for Lisk, no
matter
if it has all desired properties listed in the proposed LIP.
I will explain in the following why in my opinion the "one vote per
account" system will lead to an inefficient and maybe even an insecure
blockchain/network and why it is therefore not suitable for Lisk. This
is not because of technical aspects, but because of economical and
game-theory aspects.
TLDR: The "one vote per account" system will lead to 101 delegates not
caring about the integrity, efficiency and security of the network
because they will have not enough financial incentive to do so. They
will use the cheapest possible nodes, they won't update their nodes
in a
timely manner when critical security fixes should be applied, they
won't
care about missed blocks, they won't use their time to promote and
support Lisk in any way and they will be bribeable for very low cost.
Let me explain why:
The following will happen in the long run: Well, I think it could
happen
pretty quickly, because the voters and delegates already know the drill
from other DPOS systems like ARK, Oxy, etc...
But let's assume we play the game from the beginning, in little steps:
1. delegates will offer very little rewards, let's say 0-5%.
2. people will vote for those who offer 5%, and 101 delegates offering
5% will be forging.
3. clever standby delegate on rank 102 will offer 10% to give voters
more incentive to vote him instead of one of the top 101, to join the
forging position.
4. voters will vote for the 10%-delegate on rank 102 (because they will
get more rewards by doing this), who will finally replace the
5%-delegate on rank 101.
5. delegates on rank 102 - 150 will offer the same, 10%, maybe also
delegates on rank 1 - 101 will increase their rewards.
6. this will lead to a situation where all forging delegates on rank
1 -
101 will offer 10%, until rank 102 begins to offer 20% and step 4 - 6
will repeat with 20%.
7. This cycle will continue with increasing sharing rewards.
...
...
Delegates will continue to share more and more, until everybody shares
around 95-99%. Actually, an equilibrium will happen, at the point when
delegates share so much, that their income (maybe 1-5%) barely covers
their costs. To reduce their costs, they will use the cheapest possible
$3/month VPS nodes, they will spend as little time as possible for
Lisk,
and they won't care about their nodes, because they earn almost nothing
anyways, it doesn't matter for them if they miss blocks or if they
become unvoted. If people think this is no problem because they can
unvote those sloppy delegates and simply vote for better delegates,
they
are wrong. There won't be better delegates, because every delegate will
HAVE TO give 95-99%+ rewards to have a chance to join 101 and for an
income of like $100 per month, there won't be many offering a good
delegate job.
The end result will be, that those 101 forging delegates have extremely
little financial incentive to run their nodes in a secure and reliable
manner. They won't care about the network or the ecosystem. Even worse,
they could earn more by accepting bribe money. The LIP explains the
situation about bribing, it is not too easy to bribe 51 delegates to do
real harm to the network. But still, it would be very cheap for a
competitor blockchain to bribe a fair amount of delegates (which don't
even have to be coordinated) to disturb the Lisk blockchain severely.
For voters those 95% sharing rewards might sound like heaven. BUT: the
high LSK rewards will be worth nothing when the blockchain is insecure,
is inefficient, is not upgraded in a timely manner when crucial
security
fixes should be applied, because this will lead to falling LSK
prices on
the market. You could even lose your LSK if the blockchain is not
secured properly by financially incentivised, serious delegates.
Another reason why I don't like the "one vote per account" system is
that I want to vote for multiple delegates, because there are many
great
people in our community! I can't and don't want to reduce my vote to
only one single delegate. I know at least 50 delegates who definitely
would earn my vote. I would definitely prefer a system where I can vote
multiple people and everyone gets (account balance)/(# of votes) voting
weight from me. Of course I could split into 30 accounts, but it's too
much of a hurdle to do that and it would need quite some LSK for paying
the fees.
Because in my opinion the "one vote account" would lead to an
inefficient, abandoned and insecure blockchain I refuse this proposal
severely.
--
LIPS mailing list
LIPS@lists.lisk.io <mailto:LIPS@lists.lisk.io>
[http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io](http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io)

Jan Hackfeld

Cryptographer, Lightcurve


Subject: Digest Footer

LIPS mailing list

LIPS@lists.lisk.io

http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io


End of LIPS Digest, Vol 4, Issue 4


Dear all,

@Anthony: Thanks for your input here!

In my opinion, there are a lot of aspects mixed together with regards to the voting system

1) What is most decentralized, simple, transparent, democratic way so select the delegates?
=> This point should be the main objective of the voting system

2) What is the best way to ensure high productivity?
=> If missing the block reward is not a sufficiently high punishment, we could debate adding extra measures, e.g. delegates additionally lose some of their balance when missing their slot.

3) What is the best way to encourage community engangement?
=> In my personal opinion this is best solved via on-chain governance and having something like a community fund. Think for something like 0.5 LSK per block go to a community fund which can finance initiatives as Lisk Centers, Sidechain projects, meetups,...

4) How to we ensure that the network is secure and delegates cannot be bribed?
=> Possible solutions for this are adding depots for delegates and slashing conditions, adding Byzantine fault tolerance,...

I now want to address some of the points Anthony raised:

> *If this were true, then the current system would work just fine.
> Unfortunately a large majority of voters are always going to vote for
> maximum profit. This proposal does not really change that.*

I don't claim that peoples behavior will change and I agree that probably a large proportion would vote based on profit. This is the same now. My point was rather that in the system of 1 vote per account, a vote can make a difference much easier (I only need to convince people with a balance of 500,000 LSK that I do great stuff and its worth to vote for me). Currently, a vote makes much less of a difference as I need to convince account holders with a balance of around 29,000,000 LSK, which is basically impossible. So people currently don't see that their vote matters as it does not change anything.

*1. Less motivation and resources for delegates to maintain near perfect up time. *

I am happy to discuss measures to ensure a perfect up time. I don't think this is ensured by the current voting system. If one of the voting pools now would be fine with a delegate that has only 60 % productivity, it would likely remain in the top 101 ranks as voter would still vote for all members in the pool to receive rewards. So maybe it is the social pressure of the pool, but not the voting system that ensures productivity.

*2. Much less Lisk to give away to deserving causes (Community donations, Lisk Centers, Meetups, Projects, etc.)*

Many delegates really do awesome additional work, which we and the community appreciate a lot. But there are also delegates who are not that active and mainly take the money. I don't see this as a result of the voting system, but rather because we have so many idealistic people involved in Lisk. I would be happy to see a community fund support these kind of initiatives.

*3. Reduced price of Lisk - Voters are more likely to dump than delegates*

I don't understand this point. The only factor that I see is that the voting system may change the rewards that delegates share and this may influence if people hold Lisk or sell Lisk.

*4. Increased likelihood of delegates being bribed*

As mentioned above, we believe that Byzantine fault tolerance, security deposits and slashing are helpful to secure the system. In particular, with the fluctuation of the Lisk price and decreasing block rewards we cannot rely on ONLY the block rewards to imply the security of the network. (Otherwise, we would have a weak security and would say if delegates get 5000 Euros/month the network is secure, but if they only get 500 Euros/month the network is insecure).

*5. Less incentive to actually become a delegate in the first place, which actually leads to less competition*

In my opinion, there is very little competition in the current system, as it is super difficult for anybody to become a delegate. Keep in mind that only people owning 500,000 LSK need to change their mind for a new delegate to get into place in the proposed system compared to 29,000,000 LSK in the current system.

Cheers,
Jan

Abstract

The proposed LIP11 will have the opposite effect of what it is intending to solve. It will likely cause a decrease in decentralization, replace coalitions with whales (or coalitions of whales), and competition will decrease as standby delegates are disenfranchised even further.

###Motivation

First, it is not believed that new coalitions can easily manifest themselves in the top ranks. They exist now, but their ability to be replicated and successfully voted in has not occurred despite attempts. One often overlooked flaw is that ICOs don’t guarantee widespread distribution. Few early market participants, and delayed releases of a functional SDK, allowed coalitions to become entrenched. These issues are not from an inherent flaw in the voting system.

Additionally, providing security of the system is arguably the most important aspect of the delegates position. It can be seen as an advantage that a potential bad actor requires much more than 1% support to gain access to a forging position.

Secondly, there is a cost of voting for a standby delegate in the form of forgone rewards. Reducing votes increases the cost of voting for standby delegates to a point where in the proposed system 1 vote will cause a 100% loss of rewards for voting for a standby delegate.

The high barrier of entry, or the “cliff” as it is known, is a a large gap of votes between the active and standby delegates that will widen with a decrease in the number of votes provided.

The third problem, of only requiring 41% of the market tokens to replace the active delegates, would be even easier with a one vote per account system. Honest players can amplify their votes by exactly 101 times against an outside, malicious, actor who only has votes due to their own holdings. Limiting a vote to a 1 - 1 ratio removes the ability to do this form of defense.

In summary, coalitions will be replaced by “Whales” or groups with large holdings who could masquerade as an individual delegates. In fact, current coalitions would probably form whales with enough pooled tokens to stay in forging positions. This would simply concentrate them, but not remove them.

As explained later on, voting for a standby delegate actually costs potential value to the voter. One vote per account will destroy most chances of a standby delegate of getting into forging position.

This LIP proposes to limit the number of votes to one vote per account. The most dangerous and alarming terminology is: …fraction of 1/101 of the total stake is guaranteed to be an active delegate (in other words, any malicious group gathering support of approximately x % of the total stake will be able to obtain x delegate slots).

In practice, the threshold to become an active delegate will be even lower for whales. Also, the claim that “some votes will also be cast for standby delegates” will be the exact opposite as we will see that standby delegates that are not voting with their own tokens will drastically lose voting % as voters are economically disincentivized to vote for non-active delegates.

Having only one vote per account will: First, change out Coalitions for Whales, and many of the current Coalitions are Whales, and so they will stay in position. Secondly, the threshold to become an active delegate is significantly lower which means that the security of the network also becomes lower. These two things are almost always connected.

Rationale

It is important to acknowledge that we agree that one perfect voting system for Delegated Proof of Stake does not exist. Nevertheless, we believe the proposed change is not an improvement and will be a form of technocratic tyranny forced upon the users of the system.

To start, a common misconception about rewards needs to be explained, as it is a primary basis for the underlying security of the entire system.

Reward Sharing; the misconception of greed and rational self interest:

The Bitcoin Blockchain is obviously known for its incorporation of computer science and cryptography. Lesser known, but just as important, was Satoshi’s execution of economics and game theory. In particular, the reward mechanism incentivized users and produced value which created a positive feedback loop successfully taking bitcoin from 0 to 1. (and now from 0 to over $3,000 USD.

Adam Smith, the Father of Modern Economics, in his book “The Wealth of Nations,” explains that “It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest.”

Altruism should not be expected of anyone. Instead, rational players are expected to act in their own self interest. Acting in one’s self interest is not greedy, it is simply rational.

In the case of DPoS, the system is created so that voters can assign vote to those who they think provides them with the most value. The form of this value can be anything: maintaining the network, providing security, issuing tokens for sidechains, creating apps, and most commonly sharing rewards.

In relation to Lisk, we should assume that rational players (during a normal time and not a time of war) will be likely to vote to maximize their value received from the system. This typically means voting for the top 101 active delegates, or as close to this number as possible.

On this assumption, by only having 101 votes and 101 forging delegates, voters are given incentive to vote for the top 101 to maximize value and most notably, voting rewards. Voting for a standby delegate literally costs them potential value so they are not given incentive to do so.

Vote sharing is simply a way for delegates to provide value to their voters, due to a lack of many methods of doing so.

The current system dynamics have evolved fairly organically for lisk. The main issue in regards to large coalitions is that they formed from Lisk’s fairly shallow ICO, cheap early price evaluation, and few market actors early in its inception.

Desired Properties

In regards to the expressed desired properties of the voting system:

  • Decentralization: The idea that delegates should be independent entities but not allowed to form a coalition is an oxymoron. They are not independent entities if they are not allowed to act independently, which includes allowing them to form coalitions. Lisk is a democracy founded on crypto-anarcho capitalism. Therefore, we may need to settle for a middle ground of independence and coalitions. The scaling trilemma comes to mind.

  • Simplicity: The best way to increase accessibility of voting is with Dynamic Fees. This will greatly encourage all users to participate in voting regardless of the size of their personal holdings. This is again, a problem that can be greatly improved without changing the voting system.

-Fairness: can be an achievable property. Simple solutions such as dynamic fees and increased vote count makes it easier for an account with small holding to participate.

Most importantly, changes to the voting system should come second to functionality, reliability, and security. The number one desired property of the voting system should be to allow for users to participate in the security of the network. Drastic changes to the voting system cause potential concerns to all of these properties.

Dependence on Stake

Stake is one of the underlying security mechanisms of the system. Similar to Satoshi’s Bitcoin incentive mechanisms, Stake ensures that bad actors are highly disincentivized due to the potential risk of losing value in their holdings and their own resources.

Additionally, tokens can’t be faked so it proves that value is pledged in the form of votes.

In general, less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

Large accounts can always obfuscate their size and so they will only vote just enough to allow their own delegate get into position and then split their vote weight to assist another account to get into position.

Dependence on Delegate Productivity

In regards to penalties related to productivity:There is no need to add complexity when the system’s voting acts as a self correcting mechanism for poor performance. In a case such as former Delegate Luukas, he stopped processing blocks and was unvoted just days later.

Additionally, this motivates malicious attacks on delegate productivity in order to have them removed automatically from the system rather then allowing rational voters to decide.

Changing the Maximum Number of Allowed Votes

Although it is not a complete solution, it is a fantastic idea to increase the number of votes, while keeping the number of forging/validating delegates at 101.

This would allow voters to signal their support for standby delegates without giving up potential value or rewards from voting for the active 101. (low cost other than the transaction fee from voting, which dynamic fees should make very affordable.)

This helps create an even landscape by reducing the cliff and encourages standby delegate participation. In other DPoS systems with lower votes, the cliff is incredibly vast.

This is a great example of a fairly simple change that has little effect on the protocol or consensus layer but vastly increases the potential positions (based on vote weight) for standby delegates. Vast changes that can create unknown effects and change the game theory and inherent dynamics of the system should be avoided and at the least highly scrutinized.

Dependence on the Number of Votes Cast

This is more of a oddity: Having a single vote will actually incentivize users to play into strange game theory to maximize their value.

Voters won’t want to vote for a delegate who have too many votes, because the % share amount will be less if the account has more vote weight to divide the shared reward between.

This will actually incentivize voting for accounts with less vote weight, instead of who is the better delegate. It’s unclear how this will play out but it’s strange nonetheless.

Vote Expiration or Vote Decay

The ability to vote almost anywhere and any time, without anyone’s permission, is one of the greatest achievements of the DPoS system. Along with other cryptographic security, such as immutability and the inability to forge votes, this system is one of the best evolutions of democracy the world has seen successfully implemented.

Also, concepts such as vote decay or election dates would remove the immutability provided by the blockchain.

As an interesting but perhaps controversial idea: It is very common for video games to completely wipe a beta server at the official launch of the game.

While it goes against the idea of immutability, a one time re-vote / election could be seen as a way to make the landscape more fair for new delegates who will never have a chance of getting votes from some of the large “lost accounts”

Ranked Voting

Score Voting

Both of these are interesting concepts; but again, the added complexity and unknown game theory make them a risk to stability and security.

Impact on Security

The greatest issue is that the security model would be greatly hurt with the proposed system.

Less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

This model replaces coalitions with whales. Even worse, potential undead whales.

If the requirement to become an active delegate is lowered to only require 560,000 LSK , then it will be easy for a whale entity to buy their way into the network.

In a more extreme case, a large account such as Oliver’s, could easily vote in six or more delegate positions for themselves. A malicious exchange could vote in many more.

Then imagine that this whale dies. Due to the majority of their vote weight coming from their own personal account, the system doesn’t have a way to easily remove them from the system.

In a more dynamic system, with many votes, you can choose to unvote this delegate and pick a replacement. More votes means a more healthy system. If three nodes are bad actors, then you have the ability to unvote all three of them, and instead vote in replacements without harming yourself very much.

With only one vote, the voter can only watch and hope that the under performing delegate is removed from the system and replaced with another.

Furthermore, voters lose all incentive to vote for standby delegates, and instead must speculate on their getting into position in the future. The cost forgone for voting for a single standby delegate means that you get nothing as an honest user.

Vote Transaction Object

Specification

New Vote Transaction

Computation of Active Delegates

Backwards Compatibility

Reference Implementation

In summary, the proposal of reducing votes to 1 will cause:

Less Freedom – Reducing the votes of users reduces civil and economic freedom. Less choices means less freedom because users are allowed less options to change the overall landscape of the ecosystem.

Standby Delegate Chances Destroyed – Voting for a standby delegate currently has a cost to the voter of potential value and rewards because they are not voting for active delegates. Less votes means that the cost of voting for a standby delegate increases. 1 vote will means that voting for a standby delegate maximizes the cost of rewards to 0.

Reduces Security – Currently, a delegate would require millions of LSK in approval whereas the proposed system only requires 560,000 LSK.While the intent is to allow easier access to honest delegates, it also makes it much easier for malicious actors to enter the system.

The main issue is not the voting system:

The current system dynamics have evolved fairly organically for Lisk. It is highly likely that the main flaws are early economics such as a shallow ICO, few early market participants, and delayed releases of a functional SDK.

It is likely that as Lisk becomes more valuable holders will dilute their positions and the tokens will become more widely distributed. Block reward reductions will also diminish the power of coalitions. Additionally. delegates will have more value to provide the system will a fully functional SDK and base transaction layer.

Instead of extreme changes that bring a lot of unknown factors and uncertainty to the system, we should seek to implement simple solutions that give users more freedom, fairness, and opportunity.

Thank you for your time, and I hope this feedback is found useful,

Written by Ultrafresh @ LiskUSA
In cooperation with Stellardynamic

Dear community

@Ultrafresh and Stellardynamic: thanks for your input.

I believe I already addressed most of your points in the discussion summary that I send this morning to the mailing list. I try to address some more specific points of you email below.

I would also be happy to see an alternative LIP by you that we could compare/discuss with the current proposal.

Cheers,
Jan

## Abstract

The proposed LIP11 will have the opposite effect of what it is intending to solve. It will likely cause a decrease in decentralization, replace coalitions with whales (or coalitions of whales), and competition will decrease as standby delegates are disenfranchised even further.

###Motivation

First, it is not believed that new coalitions can easily manifest themselves in the top ranks. They exist now, but their ability to be replicated and successfully voted in has not occurred despite attempts. One often overlooked flaw is that ICOs don’t guarantee widespread distribution. Few early market participants, and delayed releases of a functional SDK, allowed coalitions to become entrenched. These issues are not from an inherent flaw in the voting system.

See summary point 6.

Additionally, providing security of the system is arguably the most important aspect of the delegates position. It can be seen as an advantage that a potential bad actor requires much more than 1% support to gain access to a forging position.

See summary point 3.

Secondly, there is a cost of voting for a standby delegate in the form of forgone rewards. Reducing votes increases the cost of voting for standby delegates to a point where in the proposed system 1 vote will cause a 100% loss of rewards for voting for a standby delegate

Voters could still split accounts and vote for multiple delegates. If this seems too inconvenient, we could further discuss the suggestion by cc001 (see point 8 of the summary) and maybe somebody is willing to create an alternative LIP based on that suggestion.

The high barrier of entry, or the “cliff” as it is known, is a a large gap of votes between the active and standby delegates that will widen with a decrease in the number of votes provided.

The cliff will decrease dramatically as only voters in total owning around 500,000 LSK have to change their votes instead of 28 million LSK (vote weight of delegate 101 now).

The third problem, of only requiring 41% of the market tokens to replace the active delegates, would be even easier with a one vote per account system. Honest players can amplify their votes by exactly 101 times against an outside, malicious, actor who only has votes due to their own holdings. Limiting a vote to a 1 - 1 ratio removes the ability to do this form of defense.

This point is already discussed in the LIP itself and basically in both voting systems are huge amount of stake is necessary to obtain 51 delegates slots.

In summary, coalitions will be replaced by “Whales” or groups with large holdings who could masquerade as an individual delegates. In fact, current coalitions would probably form whales with enough pooled tokens to stay in forging positions. This would simply concentrate them, but not remove them.

See point 7 of the summary.

As explained later on, voting for a standby delegate actually costs potential value to the voter. One vote per account will destroy most chances of a standby delegate of getting into forging position.

This LIP proposes to limit the number of votes to one vote per account. The most dangerous and alarming terminology is: ...fraction of 1/101 of the total stakeis guaranteed to be an active delegate(in other words, any malicious groupgathering support of approximately x % of the total stake will be able to obtain x delegate slots).

In practice, the threshold to become an active delegate will be even lower for whales. Also, the claim that “some votes will also be cast for standby delegates” will be the exact opposite as we will see that standby delegates that are not voting with their own tokens will drastically lose voting % as voters are economically disincentivized to vote for non-active delegates.

Having only one vote per account will: First, change out Coalitions for Whales, and many of the current Coalitions are Whales, and so they will stay in position. Secondly, the threshold to become an active delegate is significantly lower which means that the security of the network also becomes lower. These two things are almost always connected.

## Rationale

It is important to acknowledge that we agree that one perfect voting system for Delegated Proof of Stake does not exist. Nevertheless, we believe the proposed change is not an improvement and will be a form of technocratic tyranny forced upon the users of the system.

To start, a common misconception about rewards needs to be explained, as it is a primary basis for the underlying security of the entire system.

Reward Sharing; the misconception of greed and rational self interest:

The Bitcoin Blockchain is obviously known for its incorporation of computer science and cryptography. Lesser known, but just as important, was Satoshi’s execution of economics and game theory. In particular, the reward mechanism incentivized users and produced value which created a positive feedback loop successfully taking bitcoin from 0 to 1. (and now from 0 to over $3,000 USD.

Adam Smith, the Father of Modern Economics, in his book “The Wealth of Nations,” explains that “It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest.”

Altruism should not be expected of anyone. Instead, rational players are expected to act in their own self interest. Acting in one’s self interest is not greedy, it is simply rational.

In the case of DPoS, the system is created so that voters can assign vote to those who they think provides them with the most value. The form of this value can be anything: maintaining the network, providing security, issuing tokens for sidechains, creating apps, and most commonly sharing rewards.

I agree with your reasoning here. A blockchain needs to be designed crypto-economically sound. That is why we propose several other LIPs that improve the overall system of incentives in Lisk, see summary point 3. Note that proof-of-work actually gives quite weak security guarantees for cryptocurrencies with a small market cap (see https://www.crypto51.app/ or the recent 51 % attack on Ethereum Classic)

In relation to Lisk, we should assume that rational players (during a normal time and not a time of war) will be likely to vote to maximize their value received from the system. This typically means voting for the top 101 active delegates, or as close to this number as possible.

On this assumption, by only having 101 votes and 101 forging delegates, voters are given incentive to vote for the top 101 to maximize value and most notably, voting rewards. Voting for a standby delegate literally costs them potential value so they are not given incentive to do so.

Vote sharing is simply a way for delegates to provide value to their voters, due to a lack of many methods of doing so.

The current system dynamics have evolved fairly organically for lisk. The main issue in regards to large coalitions is that they formed from Lisk’s fairly shallow ICO, cheap early price evaluation, and few market actors early in its inception.

### Desired Properties

In regards to the expressed desired properties of the voting system:

- **Decentralization**: The idea that delegates should be independent entities but not allowed to form a coalition is an oxymoron. They are not independent entities if they are not allowed to act independently, which includes allowing them to form coalitions. Lisk is a democracy founded on crypto-anarcho capitalism. Therefore, we may need to settle for a middle ground of independence and coalitions. The scaling trilemma comes to mind.

The point is that the proposed voting system does not give incentives to form pools in contrast to the current voting system. I agree that decentralization cannot be enforced, but only incentivized.

- **Simplicity**: The best way to increase accessibility of voting is with Dynamic Fees. This will greatly encourage all users to participate in voting regardless of the size of their personal holdings. This is again, a problem that can be greatly improved without changing the voting system.

I agree dynamic fees are one way to encourage voting. But the voting system should be also easy to understand for the average Joe in my opinion. I think this is both true for the current voting system as well as the proposed voting system.

-**Fairness**: can be an achievable property. Simple solutions such as dynamic fees and increased vote count makes it easier for an account with small holding to participate.

Most importantly, changes to the voting system should come second to functionality, reliability, and security. The number one desired property of the voting system should be to allow for users to participate in the security of the network. Drastic changes to the voting system cause potential concerns to all of these properties.

### Dependence on Stake

Stake is one of the underlying security mechanisms of the system. Similar to Satoshi’s Bitcoin incentive mechanisms, Stake ensures that bad actors are highly disincentivized due to the potential risk of losing value in their holdings and their own resources.

Additionally, tokens can’t be faked so it proves that value is pledged in the form of votes.

In general, less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

Large accounts can always obfuscate their size and so they will only vote just enough to allow their own delegate get into position and then split their vote weight to assist another account to get into position.

### Dependence on Delegate Productivity

In regards to penalties related to productivity:There is no need to add complexity when the system’s voting acts as a self correcting mechanism for poor performance. In a case such as former Delegate Luukas, he stopped processing blocks and was unvoted just days later.

Additionally, this motivates malicious attacks on delegate productivity in order to have them removed automatically from the system rather then allowing rational voters to decide.

### Changing the Maximum Number of Allowed Votes

Although it is not a complete solution, it is a fantastic idea to increase the number of votes, while keeping the number of forging/validating delegates at 101.

It would be great so see a LIP with concrete specifications that proposes this idea.

This would allow voters to signal their support for standby delegates without giving up potential value or rewards from voting for the active 101. (low cost other than the transaction fee from voting, which dynamic fees should make very affordable.)

This helps create an even landscape by reducing the cliff and encourages standby delegate participation. In other DPoS systems with lower votes, the cliff is incredibly vast.

This is a great example of a fairly simple change that has little effect on the protocol or consensus layer but vastly increases the potential positions (based on vote weight) for standby delegates. Vast changes that can create unknown effects and change the game theory and inherent dynamics of the system should be avoided and at the least highly scrutinized.

### Dependence on the Number of Votes Cast

This is more of a oddity: Having a single vote will actually incentivize users to play into strange game theory to maximize their value.

Voters won't want to vote for a delegate who have too many votes, because the % share amount will be less if the account has more vote weight to divide the shared reward between.

This will actually incentivize voting for accounts with less vote weight, instead of who is the better delegate. It’s unclear how this will play out but it’s strange nonetheless.

Assuming rational players that want to maximize their profits, the system will move to a Nash equilibrium where nobody benefits by changing their vote. Let us look at a simple example: Two delegates A and B
- A shares 50 % rewards
- B shares 60 % rewards
Further, assume a total of 1,100,000 LSK vote. Assume initially 550,000 LSK vote for A and 550,000 LSK for B. As you correctly observe, the voters for B receive more rewards so people voting for A would shift their votes to B. But they only do this until an equilibrium is reached where nobody benefits from changing their vote. The equilibrium is:
- 500,000 LSK vote for A
- 600,000 LSK vote for B
(B shares actually 20 % more rewards so also receives 20 % more votes in the equilibrium state).

### Vote Expiration or Vote Decay

The ability to vote almost anywhere and any time, without anyone's permission, is one of the greatest achievements of the DPoS system. Along with other cryptographic security, such as immutability and the inability to forge votes, this system is one of the best evolutions of democracy the world has seen successfully implemented.

Also, concepts such as vote decay or election dates would remove the immutability provided by the blockchain.

As an interesting but perhaps controversial idea: It is very common for video games to completely wipe a beta server at the official launch of the game.

While it goes against the idea of immutability, a one time re-vote / election could be seen as a way to make the landscape more fair for new delegates who will never have a chance of getting votes from some of the large “lost accounts”

### Ranked Voting
### Score Voting
Both of these are interesting concepts; but again, the added complexity and unknown game theory make them a risk to stability and security.

### Impact on Security

The greatest issue is that the security model would be greatly hurt with the proposed system.

Less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

This model replaces coalitions with whales. Even worse, potential undead whales.

If the requirement to become an active delegate is lowered to only require 560,000 LSK , then it will be easy for a whale entity to buy their way into the network.

In a more extreme case, a large account such as Oliver’s, could easily vote in six or more delegate positions for themselves. A malicious exchange could vote in many more.

Then imagine that this whale dies. Due to the majority of their vote weight coming from their own personal account, the system doesn’t have a way to easily remove them from the system.

In a separate proposal, we propose that such a delegate would be eventually removed, see point 4 of the summary.

We thank everyone for the discussion going on around LIP 11 and improving the DPoS system. However, we believe that these following issues have not been addressed.

By having the same number of votes as active delegates, the DPoS system creates an inherent monetary cost for voting for a standby delegate.

In the case of 1 vote, if a voting account wishes to give their full support to a standby delegate, they will lose all of their potential rewards. That is a 100% loss in vote sharing rewards for supporting a standby delegate.

We use our basic economic principles already submitted and; additionally, submit Ark as a primary example of a chain that has one vote per account. You will notice that standby delegates are almost non existent.

Having the ability to automatically eject an active delegate for being down, after a reasonable amount of time, seems like a good solution to our UndeadWhale Problem.

However, a major attack method seems to be completely missed by Lightcurve. While the idea of lowering the barrier to entry is great in theory, it fails to realize that lowering the barrier to entry allows for malicious actors to attack the system. It is very unlikely that the majority of delegates will be bought up by a single entity with the idea of severely disrupting the network.

Instead, the Parasite Attack is arguably a more dangerous attack. The Parasite delegate simply buys their positions like normal. An entity such as Oliver could easily acquire 6-7 positions themselves. An exchange could get hacked, and if the Lisk are stolen, even more positions could be acquired. However, instead of not forging, they use the forged rewards to hinder the network or siphon off the resources to develop their own competing project. No amount of slashing conditions will save you from these actors.

It is likely that many were not around during the early days of Lisk when members of Ark were performing this attack. Voters were able to eventually unvote them by voting in standby delegates. Currently, the 1 vote per account suggestion has no solution for this attack.

We believe it’s a matter of poor token distribution due to the ICO, few early market participants, and a short period of low price evaluation not giving outsiders adequate time to accumulate.

Additionally, we agree with this statement by Jan: “In my opinion, the main reason is that the voting pools have by far the largest influence on the decision of who becomes delegates.” Thus, if this opinion is so strong, then we suggest focusing on solutions that affect the problem without doing damage to the average user.

The 1 vote solution seems to completely disregard the loss of value and freedom the current voters have. Instead of changing the voting dynamics, perhaps we should look at token distribution. Although, Lisk has a fairly high deflationary rate (the next reward reduction will be 33%) we could influence the distribution of tokens even more by implementing reward sharing at the protocol level. Something like 35% to even 50% would directly affect the accumulation power of the active delegates while giving more value to the average user, instead of taking power away from the user.

Let us clearly identify the problems and fix them. If large pools are the issue, let’s do something about them without penalty to the average user.

Written by Ultrafresh @ LiskUSA
In collaboration with StellarDynamic

It’s very simple…
1 vote per account = THE LARGEST ACCOUNTS WIN, period.
This is NOT decentralization.

1 Like