[LIPS] Change to one vote per account

Vit Stanislav vit at lightcurve.io
Wed Feb 6 07:02:11 EST 2019


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


More information about the LIPS mailing list