[LIPS] LIPS Digest, Vol 4, Issue 4

Anthony Morinello morinelloa at gmail.com
Wed Feb 6 13:50:28 EST 2019


"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 at lists.lisk.io> wrote:

> Send LIPS mailing list submissions to
>         lips at lists.lisk.io
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io
> or, via email, send a message with subject or body 'help' to
>         lips-request at lists.lisk.io
>
> You can reach the person managing the list at
>         lips-owner at 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 at lightcurve.io>
> To: lips at lists.lisk.io
> Subject: Re: [LIPS] Change to one vote per account
> Message-ID: <992126ef-1cca-165d-c455-6ccc25e57660 at 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.
>
> 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
> (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 at gmail.com
> > <mailto: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 <mailto:LIPS at lists.lisk.io>
> >     http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io
> >
> >
>
> --
> Jan Hackfeld
> Cryptographer, Lightcurve
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> LIPS mailing list
> LIPS at lists.lisk.io
> http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io
>
>
> ------------------------------
>
> End of LIPS Digest, Vol 4, Issue 4
> **********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lisk.io/pipermail/lips_lists.lisk.io/attachments/20190206/98541754/attachment-0001.html>


More information about the LIPS mailing list