[LIPS] Response to Lip11 from LiskUSA

Matthew Alexander datultrafreshemail at gmail.com
Fri Feb 8 16:10:33 EST 2019

## 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.


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

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

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

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

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lisk.io/pipermail/lips_lists.lisk.io/attachments/20190208/e76759df/attachment-0001.html>

More information about the LIPS mailing list