Lisk-sdk: Solutions to improve Lisk DPoS

[karek314]

I think current Lisk DPoS is way to centralised and vulnerable to many attacks. One person with big wallet can possibly up vote all his 101 delegates to top 101 forging with current implementation. There is also risk that delegates will stop forging and network will stuck so new ones will be impossible to pick, it seems it was problem in Crypti. When price is falling incentive to run node is getting smaller and smaller.

Possible solutions:

• Making Lisk DPoS more decentralised by lifting up forging delegates up to 202 (to avoid issues with accounts which did make 101 votes already, it will also require halving reward) and keep possible votes to make at 101, so each account will be possible to chose only 50% delegates, this way single person with big wallet won't be able to take over network. This will actually reduce vulnerability to this type fo attack and make network more decentralised, this will also prevent/reduce buddy-2-buddy / vote-4-vote scheme which discourage new people to become part of Lisk ecosystem.

• Implement mechanism which will pick closest standby delegate as forging one when any of Top forging ones failed X times to create block, along with function which will check if previous delegate recovered itself so forging power will be granted back. More or less, should be discussed.

Even after implementing those ideas, there still will be few things to improve, but this will be big step forward. Will post few more possible improvements in upcoming time.

[mrv777]

One if the reasons 101 is currently used I believe is because of the 10 second blocks. Speed is important as forging nodes need to try and keep consensus. If you double forging delegates, you double the nodes that need to stay in sync. While this is all possible, I believe more optimizations to the code may be necessary before something like that can happen.
Disclaimer: This is just my understanding of it all :)

[karek314]

Of course round will be longer or/and reward halved, there are few possible solutions.

[densmirnov]

Why raising the number of forging delegated, when you can simply limit the number of possible votes to, lets say, 50? It's not the complete solution, but it will work better against 101 attack.

[karek314]

Because many accounts did make more than 50 votes already, i think it will be quite hard to make everyone to remove votes, other-way it requires more messy hard-fork.

[karek314]

There are other possible approaches to improve DPOS

• Split votepower among votes made, this has been already proposed by @4miners as far i know

• Another idea is to not only extend number of top delegates, but increase competition between top delegates by making block rewards higher for those with higher position and smaller for those with lower rank, this can possibly significantly increase competition in top delegates and create some more space for top delegates. Some people can even enjoy being active delegate with 0.1 LSK block reward with lower rank, this is at least something what can make development around Lisk ecosystem more active. As soon dapps sdk will be ready, then small reward delegates may fuel small dapps creation while bigger projects can get more revenue for development etc.
  Increasing number of delegates, in addition with less revenue per block has some drawbacks, although nothing what can't be solved. like more stable core client with built-it failover on different servers and setting different forging delegate if top one failed X times and more.

[simonmorgenthaler]

it would be very interesting to see how dpos works if the votes are anonymous, meaning you only see the total approval rate on a delegate, but you don't see who or how many voted for it.

[mrv777]

A few other ideas:

1. Voting weight of an account = The square root the balance of the account
   _--This should help balance large accounts vs small accounts. However, I know big accounts can split their funds, but I'm not sure to what extent they would._
2. Voting weight of an account = Balance - (Balance * (#delegates they voted for*.005))
   _--I think this is better than just (balance/#votes), but still promotes being more selective with votes. (ex. An account votes for 100 delegates, those delegates only receive 50% of their weight, but if they vote for just 1 delegate, that delegate gets 99.5% of their weight)_
3. Voting weight of an account = Balance, until 50 votes then lose 1% of weight for every additional vote. (ex. an account that votes 101 delegates will only vote at 49% balance to those delegates)
   _--While I think its too difficult to set a lower voting limit on accounts at this point (ex. each account only gets 51 votes), this can achieve a similar result in rewarding more selective voting choices and make it more difficult for one big account to get all 101 spots._
4. Delegate weight = 0.8(votes) + 0.2(votes*productivity in last 30 days).
   _--If 30 day productivity > 0 and 30 day missed blocks > 10. This would reward well run delegate nodes (Should add a double forging penalty too, ha)_

I would personally be interested in seeing the results with 2, 4 and maybe 1 were all used.

Disclaimer: I'm not saying we should use all of these ideas. They are just my random 4am thoughts, where I didn't double check any of the math and being such, please point out any flaws.

[2mdoty]

from karek314 - "Split votepower among votes made, this has been already proposed by @4miners as far i know"

This is what I have proposed since when I first saw the current Lisk voting system in Crypti 2 years ago. We are currently implementing this in Ark, ark.io . We are keeping the ability for delegates to see who voted for them to encourage profit sharing with voters in the form of direct payments, equity shares in funded projects run by delegates, and non-profit community service type projects.

[Isabello]

Lisk DPOS - The current implementation and its problems

The current incarnation of Lisk continues on the tradition of Delegated Proof Of Stake. In the implementation we have inherited all of the problems and issues with the protocol that were present in Crypti and by extension, BitShares. While these problems are not terribly pressing, we should look to address them.

Current State:

In the existing implementation, every wallet address is given 101 votes to assign as they choose. These votes carry a set amount of weight based on the total amount of LSK found in that wallet. There for every user is actually granted (Stake * 101) in power to influence the network. Each account can only vote for another account once, this means is only allowed to apply its full stake to another account once.

Extending the concept of 101 votes, we have 101 delegates. These delegates are tasked with securing the network by signing transactions into blocks and broadcasting those blocks onto the network, pushing the blockchain forward and sealing data into its immutable structure.

In this current state we are subject to some faults. Here is a list:

1. One individual with a high amount of stake can overtake all others on their own. Currently, a user only requires 19.44% of all available lisk in order to secure all 101 delegate slots.
2. A group of individuals can effectively reproduce this attack by securing most or all positions within the 101 delegates. Once they have achieved control of the network, nothing stops them from implementing a forked copy of the software on all nodes/delegates involved. This essentially provides them unfettered access to do as they please, accept or reject transactions they choose and more.
3. With a majority stake in delegates, control is basically guarenteed. These users will continue to get richer and richer, creating a higher and higher barrier to entry for anyone looking to join the elite ranks of the 101.

These issues are present in most implementations of DPOS, but they are more pronounced in Lisk where all of the available Lisk was purchased during the ICO and only recently has more Lisk been added to the system in the form of forging rewards. These rewards carry the problem mentioned above.

Future State:

In order to resolve the deficiencies mentioned in the previous section, we must address some of the core assumptions. These core changes are listed below:

1. To address the 101 vote and stake attack, we must change the amount of votes every account is allowed. The most desirable number ends up being 33 votes per account. This is the most amount of votes that can be included in a single transaction. Now in order for an evil agent to overtake the entire network they will require 60%+ of all LSK to secure every available delegate position. Mathematically, this looks like (STAKE * 33) for the amount of power a single stake can apply.

2. Further limits should be placed on the value of a stake. The recommendation is to reduce the total amount of weight a stake carrys when spread across more individuals. Therefor, we should change from (Stake * 33), to ((Stake * 33) / VOTES). This further increases the required amount of funds to attack and control all 101 positions.

Additional Improvements to the Algorithm

Fostering external interest is also on the agenda. Currently, if you aren't in the 101, you probably won't be, unless you cut a deal with groups like GDT or other large holders. In an effort to reduce the amount of control large groups like this have, we must look at other options for incentivizing standby delegates.

One initiative is to move to a two tiered system. A hybrid of DPOS and ALGORAND by Silvio Micali. In ALGORAND, blocks are generated by a Round Leader and subsequently validated by a pool of signers. In Lisk, we already have a Round Leader for every block in the form of delegates. To extend the concepts of ALGORAND for our purposes, we will look to include Standby delegates as the block validators. A subset of standby delegates will be selected after every block is forged to participate as block validators. This second layer of consensus will work to ensure that the blocks coming from delegates are not only secure, but valid.

A reward to standby delegates who participate as block signers will be given. The current proposal is that they will receive part of the blocks fees, and part of the forged lisk from that block. Validators signatures will be weighted based on the STAKE voting for them, so that standby delegates who are closer to the 101 will be chosen more often. This prevents an attack from an EVIL user who could generate hundreds of accounts to gain an advantage over others. While this will still be possible, its effects are greatly diminished by the voting and stake application changes mentioned in the previous section.

Other important (Potential) changes.

Within the current system we are faced with an ever present issue with voting. Users vote once and thats the end of their engagement. Theres never a reason to change or remove a vote. Theres no incentive to do so.

Therefor, we look to implement a system of VOTING DECAY. This decay system will diminish the stake value of a vote until a new transaction is put onto the chain reapplying the vote(s). To extend this concept, we will look to limit the "Terms" a delegate can serve. The basic idea behind this is so that new delegates can enter into the 101 more frequently. Delegates who have been removed from the 101 by having votes decay will enter into a COOLDOWN phase where they cannot be voted back into the 101 for a set time period. They will be able to serve as a block validater during this time period, though.

Following up on the concept of voter decay, we need to reward people for voting more than once. To this end, we look to provide all voters of a block signer/validator a small slice of the block rewards generated by those delegates. While this value may not be huge, it should be enough that people will want to vote for users.

Closing Sentiments.

DPOS has some fundamental issues, and we aim to address them by adapting some concepts from ALGORAND and using our existing infrastructure in conjunction with those changes. Expanding on those changes we aim to create more engagement and increase the fluidity of the overall system, allowing more individuals to participate within the confines of the 101 system. I believe these changes will be very important to allow Lisk the room it requires to grow and evolve.

[mrv777]

First thoughts for me is a combination, but prioritized by complexity:
Now
VOTING STAKE = Balance-(Balance * (#delegates they voted for*.005))
I prefer a linear decrease over STAKE/VOTES as it decreases stake too fast and by too much in my opinion.

In between unless it's very easy to do
33 Vote max if change to voting stake wasn't enough of a change as these two do somewhat similar functions (encouraging accounts to be more picky with their votes and prevent a large bag holder from buying all 101 spots) (If this is added with the linear decrease, I would increase the reduction per vote mentioned above by about 3x to keep it similar)

Future after new SDK is working
Voting Decay and ALGORAND. These are very interesting ideas.
ALGORAND sounds like it would be complex to add, but if it adds to the security of the system it may be good to have.

[Phoenix1969]

What about complete randomization of forging delegates? (ducks under desk)

and progressive timeout bans for missing blocks or similar...

[dakk]

@Phoenix1969 if you randomize the forging delegates without considering votes, one person can create more delegates account to increase his probability to forge more blocks in a round

[simonmorgenthaler]

Reducing the possible votes to 33 is in general the same as dividing the Voting stake through 3 (because you can split your account into 3 accounts, and vote with every account 33 different delegates, which result in the same 100 votes, but with a third of the weight).

I agree with mrv that dividing the STAKE/VOTES is too harsh and leads to the situation where delegates only vote for themselves. I prefer a more sophisticated formula like the one mrv suggested, or the square root of the amount or something like that.

I like the idea of the VOTING DECAY

An I think also the idea of automatically remove a delegate from the active group if he doesn't forge for a specific amount of time might be a good addition.

Will follow up with other thoughts :)

[2mdoty]

Think this all sounds way too complicated and will lead to unintended consequences. It is much simpler to just divide an account's voting weight by the number of delegates voted for and apportion it equally among the votes. We are also looking at adding chainable proxy voting for Ark to enable Liquid Democracy applications, so an account can assign another account to vote for it, which in turn, can assign its cumulative voting weight from the proxies to yet another account.

The use of standby delegates as automatic backups to replace non-functioning delegates is a very useful improvement since there is currently no way to replace an non-functioning delegate which still has sufficient vote to remain in the top 101.

There may be some merit to lowering the maximum number of votes and applying some sort of algorithm to adjust voting weights based on number of votes cast, but between the Ark system of simply dividing the vote and the current Lisk system, we'll have real data from the two extremes to define a range of expected behavior.

[2mdoty]

Also keep in mind, that it is a challenge already to encourage people to vote, so any additional complexity added to voting will reduce participation even further.

[mrv777]

I like the idea of proxy voting. Have that tx be just 0.1LSK too. That way people that are too lazy or don't have time to keep up with votes can just give some else they trust permission to vote with their weight.
Can also expire, like NXT's balance leasing maybe

[2mdoty]

Ranked voting, where the order of the votes applies a multiplier, so if 10 are voted for, 1st choice multiplies stake by 10, second by 9, and so on down to 1X for 10th choice.

[stenea]

I would rather have lisk team focusing on sidechain SDK instead of finding workarounds on current DPOS consensus mechanism. @karek314 one person taking over all the 101 delegates would kill lisk, it makes no economic sense to try to do such a "power-play" because nobody would trust lisk anymore. People invested(and still are) time or money in lisk for being the first blockchain sidechain framework developed in JS, not for improving DPOS. I would like to have lisk remembered as the first blockchain framework that allowed sidechain not as the blockchain that reinvented DPOS. That's not lisk mission. And having lisk team even thinking about this, while there are a lot of other important things to be done, I think it's just affecting lisk and not in the way we all want.

[Doweig]

My 2 cents on few things:

To address the 101 vote and stake attack, we must change the amount of votes every account is allowed. The most desirable number ends up being 33 votes per account. This is the most amount of votes that can be included in a single transaction. Now in order for an evil agent to overtake the entire network they will require 60%+ of all LSK to secure every available delegate position. Mathematically, this looks like (STAKE * 33) for the amount of power a single stake can apply.

I strongly agree with this one. I really believe that the Number of votes per account should be LESS than the number of forging delegates.

One individual with a high amount of stake can overtake all others on their own. Currently, a user only requires 19.44% of all available lisk in order to secure all 101 delegate slots.

This is also true on any PoW blockchain, if you spend enough $$$ you can take over the network. But in reality, no one will spend millions of $ to double spend a few LISK and get his millions in holding collapse. However PoW is largely seen as the most secure consensus algorithm.

Therefor, we look to implement a system of VOTING DECAY. This decay system will diminish the stake value of a vote until a new transaction is put onto the chain reapplying the vote(s). To extend this concept, we will look to limit the "Terms" a delegate can serve. The basic idea behind this is so that new delegates can enter into the 101 more frequently. Delegates who have been removed from the 101 by having votes decay will enter into a COOLDOWN phase where they cannot be voted back into the 101 for a set time period. They will be able to serve as a block validater during this time period, though.

It would be very hard for a voter to keep track of all 101 votes and refresh/change them when needed. Most people even do very little due diligence before voting at the moment. I think the effect will be to just lower the approval % needed to get into the 101 because people just forget to revote. Therefore making the network easier to attack

One initiative is to move to a two tiered system. A hybrid of DPOS and ALGORAND by Silvio Micali. In ALGORAND, blocks are generated by a Round Leader and subsequently validated by a pool of signers. In Lisk, we already have a Round Leader for every block in the form of delegates. To extend the concepts of ALGORAND for our purposes, we will look to include Standby delegates as the block validators. A subset of standby delegates will be selected after every block is forged to participate as block validators. This second layer of consensus will work to ensure that the blocks coming from delegates are not only secure, but valid.

An easier and just as effective way to make regular holders to get a share of the newly created tokens would be to have more pools forging. On the security aspect, if we judge the 101 forging layer to not be secure enough, the problem should be addressed on that layer, not adding an extra layer of validation. Like for example having a block to be signed by multiple delegates before being considered valid (a la STEEM)

Further reading on DPoS concerns and possible improvements:
https://github.com/cosmos/cosmos/issues/43

My own proposal on Number of Votes per Account (Draft):
https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-2.md
https://github.com/ArkEcosystem/AIPs/issues/1

[mrv777]

@Doweig Good input, thank you

My thoughts on the vote weight splitting:
You don't really need this and to limit # of votes. People will most likely severely limit their votes with the halving. Most likely I think it will result in this out come:
Regular Holders - most likely just placing 1 or 2 votes and most likely with pools. A few unselfish holders may vote outside pools and themselves, but with halving it could have little effect depending on how many votes they make
Greedy Whales - most likely place <10 votes spread across pools and themselves
Unselfish Whales & Core team - Only groups I could see placing more than just a handful of votes and voting for delegates other than just themselves and pools.

Overall, I think applying any penalty to voting weight will limit the number of votes an account will want to make so may have little additional effect when combining the two.

I think halving is too aggressive though and will result in the 101 being mostly a combination of pools & greedy whales, if Unselfish Whales & Core team can't even it out (which in the long run they won't be able to maintain since they will most likely not be forging). I would prefer more of a linear decrease in voting weight (0.25-0.9% decrease of account balance with each vote).

[karmacoma]

I would rather have lisk team focusing on sidechain SDK instead of finding workarounds on current DPOS consensus mechanism.

The blockchain application platform is getting absolute focus. Structured brainstorming sessions are being conducted everyday, and great progress is being made here towards SDK implementation.

Despite what some might think or say, we are very glad to see open and frank discussion on how we can possibly make the current DPoS implementation fairer. The set of proposals brought forward by @Isabello was as a result of a brainstorming session we held, and is by no means the authoritative solution.

[mrv777]

Thought of another idea, but this one may be unnecessary and just add too much complexity. Wanted to write it down though, just to note:

What if with each vote, you had to assign a percentage of your balance to go with it. In increments of 1% and they combined for no more than 100%:
Example: I place 3 votes.
Vote A I want to get 50% of my weight
Vote B gets 20%
Vote C gets 15%

And I'm left with 15% of my weight to vote with if I want or I don't have to. Trying to place Vote D for 16% would result in an error.

[stenea]

@karmacoma I get it. And I know you are brainstorming about sidechain SDK. It's just that it seems too early to think about this while there are still so many things to do. I would prefer having you focusing and talking 100% about sidechain SDK instead of improving DPOS.And that's available for us too. Maybe we can help you on SDK instead of brain-squashing on how to change the current DPOS.

[corsaro1]

Most part of the listed proposal are excellent and it will be great to see them applicated. Anyway I think dpos can be perfected as soon as we'll have a working Lisks's App SDK to create sidechains and dapps.

[Isabello]

The SDK and DPOS can be thought about at the same time. We have the resources to do both.

[Odsejen]

There are great ideas to improve the current system, but i remember one of the last milestones was "mainnet stabilization" (just saying). A new forging model may be necessary and for security reasons the ALGORAND approach looks like the most interesting and sounds like necessary on the long run.

A reward to standby delegates who participate as block signers will be given. The current proposal is that they will receive part of the blocks fees, and part of the forged lisk from that block. Validators signatures will be weighted based on the STAKE voting for them, so that standby delegates who are closer to the 101 will be chosen more often. This prevents an attack from an EVIL user who could generate hundreds of accounts to gain an advantage over others. While this will still be possible, its effects are greatly diminished by the voting and stake application changes mentioned in the previous section. <<

It can be combined with whatever, a.e "voting decay", "more/less delegate spots", "more voting activity ->(leads) to a higher probability to get a validator spot" .. seems endless.
My favorite is increasing the spots to 200 & halving the rewards with a forging reward ranking (the higher the more) and some additional changes to voting power or votes per se, but for now i would stay with a running system and further improve & adapt the core, sidechain integration and sdk, with this in sight also new possibilities for governance models and therefore DPoS systems can occur which could give even more and wider prospects (a.e. a flexible core in which forging-parameters can be elected in a given frame, the integration of sidechains etc.) . I think the majority is now more likely interested and focused on stability, value(preservation), usability and especially use-cases.
And what about a second Testnet in which we're just trying discussed changes to dpos, think could be a good idea.

Views are different but in my opinion we have currently a very nice group of different persons, GDT or NON-GDT, as there is a big difference, whose a lot of them followed Lisk since start and a lot new great delegates, i think the big majority here are interested to make Lisk a fresh, nice experience & investment. Exactly these group of all our current delegates cooperating with the LiskTeam and each other, are i.m.o able to prevent many many sorts of attacks and will hopefully find a good consensus about this topic.

just my 2 Lisk.

[mrv777]

Also, vote limiting can be added with my linear decrease of voting weight. Currently, if you decreased voting weight by 1% after the first vote, vote 101 would remove all your weight. Example:
1 vote = that delegate gets 100% your weight
2 votes = both delegates get 99% your weight
100 votes = each delegate gets 1% of your weight
101 votes = each delegate gets 0% of your weight

if you increased the decrease to 2%, no one can really vote for more than 50 delegates as it would set your voting weight to 0 for all voted delegates

I still prefer something in the 0.5-1% range though

(Just writing down ideas again :) )

[corsaro1]

I think it could be fine too choosing at each forging round the 101 forging delegates, among the first 150-200 delegates, with an higher probability to be choosen based on:

• more closer to 1st rank
• less missed blocks

So doing even delegates outside the first 101 position could be randomly called to forge a block, making the community more participant in the process of forging. At same time, even if a delegate is in the first 101 slots, and he has too much missed blocks, he could not be included in all rounds, due to the fact the algoritm could prefer on some rounds at its place a delegate in rank > 101 with better performance.

The result would be a less rigid border between standby and active forgers.

Just my 2 cent

[wariner84]

@corsaro interesting ...+1

[mrv777]

I have another idea that may not be too difficult to implement that would help the system. What about an expiration on a voting transaction? Maybe 1, 2, or 3 months?

[Isabello]

weve discussed vote weight decreasing over time require reapplication but
technologically it introduces some unneccessary complexity

On Wed, May 3, 2017 at 2:01 PM, mrv777 [e-mail] wrote:

I have another idea that may not be too difficult to implement that would
help the system. What about an expiration on a voting transaction? Maybe 1,
2, or 3 months?

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/LiskHQ/lisk/issues/353#issuecomment-298891248, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APzFsEJN0mkfIaFDv95XPjDw01n7j1r2ks5r2Gx9gaJpZM4LKAVd
.

[mrv777]

I'm not just talking about decreasing or decaying though, but actually expiring the vote.
If a vote is X days old, it's no longer valid

[Isabello]

And how do we handle this during synchronization? It needs to be X blocks old, not time.

The problem with expiring the vote is it creates alot of uncertainty, those transactions still exist but we ignore them after a certain round? It touches memory tables more than I am comfortable since those transactions are valid until the end of time. So we create a hard fork situation where new transactions can expire? If we implement this today, right now, most votes would expire immediately, yes? This is not the way.

[Isabello]

Additionally, if votes expired, someone would just create a script that automatically removes and revotes delegates just before the time is up. It does not solve the problem.

[mrv777]

Sorry, I meant X blocks.

It should take the same effect as if they did a remove vote tx. It's just done automatically instead of by the user.
Yes, someone could create a script. However, it should fight against people that just leave since they would need to still have that script running somewhere and the version they are running would still need to work.

Again, just an idea.

[Isabello]

Its an idea weve discussed a few times here internally but the end result is that its just not feasible. The user has made a decision on their vote and we should not mess with that. Their vote is immutable and should remain until they withdraw it.

[simonmorgenthaler]

On the other side, for example the president needs to be reelected every four years. In other words, the vote expires after 4 years and needs a reapplication then. I think it wouldn't be a problem for the users if it is very clear from the beginning that a vote is valid until withdrawal but at max for X blocks. I think it indeed could make the 101 list more vivid.

[Isabello]

Nobody agreed to these terms when they first voted. This is what makes such a change a hardfork.

[karek314]

Expiring votes is just not convenient at all for end user. Not even considering other aspects.
Firstly there should be implemented as soon as possible, something more or less like limiting one account to be allowed pick 50% of current delegates forging instead 100%. There was also many other decent ideas out here in recent posts to consider, there is no single silver bullet solution so it will be nice to pick best ones and implement along with other. Generally speaking those changes should be made sooner than later, because as lisk price grows it will become harder to depose current delegates if new system will threaten their position. It will be similar story as with Bitcoin, never ending war.

Dpos seems to be quite good, but needs changes mentioned here, currently one entity can easily upvote all delegates to top101 this doesn't sounds like decentralised yet.

Apart of that, Hard fork is not scary or bad at all, sort of we already had fork in past. The hard one, specifically soft-hard-fork. When network cut off nodes below 0.5.0 (or 0.6.0 i'm not sure which version).

[hoklitrail]

I would suggest a system where delegates have to keep a fixed percentage of their forging rewards as "proof of stake" meaning they can't sell it as long as they are a delegate. If they sell, they automatically lose their position. May not be as easy to implement as it sounds. Just an idea...

On top of that they get punished if they run a node that has a lower uptime than the average across all nodes. So if the average uptime is 99.5% then you get punished for each tenth of a % that your node is below that number which will mean you drop in your ranking. So ranking is no longer based on votes as you can only be voted for to become an active delegate but your rank depends on the service you provide. The better it is, the higher you go.

If we reach a point where all the active delegates are running close to 100% uptime then that would be the best outcome we can imagine and there's no reason to kick any of them out, bar any wrong doing.
I'm not saying this is going to work. It's basically a point of discussion that may add something constructive to the debate.

Personally, I believe the end of pools is coming quickly anyway as they will lose most of their appeal the more voters we see coming on board. Their payouts will drop (and already have) significantly and it will become more attractive for people to vote for individuals again.

In the end, we have to realise that the Delegate Proof of Stake System is utterly problematic to begin with. It solves the issue of "big miners" Bitcoin is suffering from but it just shifts the problem to another area.

As long as people get paid for their votes, the system can't survive. The idea of paying somebody to vote for you is the most corrupt system imaginable. As others have pointed out, it would be illegal in any decent democracy and surely can't be a sustainable way going forward. This is the biggest grief I have with LISK right now.

I'm looking forward to a list of delegates that offer an actual service instead of just a percentage of their earnings to keep their voters happy.

[georeith]

I would suggest a system where delegates have to keep a fixed percentage of their forging rewards as "proof of stake" meaning they can't sell it as long as they are a delegate. If they sell, they automatically lose their position. May not be as easy to implement as it sounds. Just an idea...

Many delegates have promised a large chunk of their reward to voters. We don't want to disincentivise voting.

[chauey]

We need to be able to vote to ban people from being delegates who are not acting in the best interest of Lisk, like actively campaigning against Lisk and selling all their LSK? Need help to make more visible/apparent who is doing what and be able to respond more quickly and inexpensively ;)

[mrv777]

who decides who gets banned? if it's other accounts, isn't that the same as unvoting them? and what's stopping them from making another delegate?

[kctdfh]

I think it'd be beneficial to have 2 kinds of votes: vote of confidence and vote of no confidence.

If you think about it, since you can withdraw your vote from a delegate, by voting you're essentially saying "I support you until I don't". This is not how ballot democracy works because when you vote for a president, your vote is good for a full term. So to call the DPoS system 'voting' is not correct I think.

The better characterization here is a vote of support. Currently there's two positions - no vote and vote of support/confidence. But the problem (as extensively discussed) is that a small number of whales can elect their preferable delegates because of their huge vote weights. This is because the masses, with small wallets, can't in any way devalue the whales' vote. If there is a way to say "I support you until I don't", there should also be a way to say "I don't support you until I do".

If we had 3 possible positions (vote of confidence and vote of no confidence and no vote) then the masses could recognize collusion as it arises (since votes are public) and could roll back big votes. In the case of no confidence, your vote weight would SUBTRACT from the total votes of a delegate.

And technically I don't think this needs a fork because votes in the past still count the same as they did before the addition of the second vote type.

I think it's more fair this way because if whales can plan to overtake the delegate list, the smaller wallets should have the power to similarly plan and overthrow them. The higher the value of the coin, the worst our current situation will get.

[desjob]

We need to be able to vote to ban people from being delegates

How? it's decentralized. You could do it by voting, but then the vote will be worth the amount of LSK held by the vote caster, thus leading to the exact same problem.
There is by definition no censorship on who can run as delegate, and people can register as many account seeds or delegates as they want. Only factor in play is maybe the delegate registration fee, but at this level that is negligible.

[smmujahid]

If the problem of delegates control is not resolved. we would perhaps encounter more forks than BTC, thus destroying the whole system

[coolrunnings16]

I'm afraid that things are starting to blow out of proportion judging from the Lisk Reddit community. Things are getting heated between investors and delegates. Censorship in the Lisk subreddit has only fueled the anger and frustration of voters. The situation needs to addressed as soon as possible, this simply cannot continue. It's only going to tarnish and undermine the work put in by LiskHQ.
I suggest that the idea of pools should be scrapped and delegates not allowed to vote for each other. 55 members controlling the network and setting their own rules is simply not a consensual democracy. It's a completely centralized concentration of power and it's only going to worsen as project becomes more entrenched in society and LSK tokens gain value.
As an investor I urge you to address this issue as soon as the rebrand is implemented and Alpha SDK is released.

Thanks,
Michael Riordan
Ireland

[Lediedo]

@coolrunnings16 i agree!

[fastfalcon94]

I think the whole voting system needs to be reworked. Problems I see with it:

1. 1 LSK for 33 votes is stupid when there are 101 delegates. To get all the votes in you are wasting 1 LSK (Currently $10) just for 2 votes

2. Also every delegate is different. Some are single, some are groups, some require you to do extra stuff (register elsewhere, vote for all members, different LSK payout). This is beyond confusing to keep track of.

3. The threshold and current LISK fee is awful if you do not own thousands of LSK. If you own 400 LSK it would cost you $40 to vote right now. It could take months (assuming the people you voted for are even in the top 101) for you to reach a threshold where you'll get pay. Maybe 0.2 LSK from someone will come to you but you'll lose half in fees. This is the only semi-good thing about pools is that a pool of 30 people could combine your rewards and you only eat the transaction fee once.

4. Eventually it's going to create a monopoly of delegates. Say all the delegates in the top 100 pay out 80%. A new person comes along. They offer something better, 90%. People are going to be hesitant to vote for this new person because they realize the hurdle that needs to be crossed for him to make it to the top 101. They are going to stick with the 80% person as they know there vote will stay in the top 101. Eventually you are going to get 101 delegates that earn so much that no one will be able to overtake them.

How would I do it?

• Change the voting system to a membership fee instead. Make it so 2 LSK gives you 101 votes per month for a year. Eventually as price rises you can lower the membership fee. This will make it simpler and not waste 1 LSK for 2 votes.

• Get rid of the vote rolling over. Ever month you have to re-vote. This will encourage fresh blood in the delegate pools. It will also encourage community involvement.

• Make it so that if you are a delegate and send money there is a smaller fee (or no fee). This will help people will smaller LSK balances earn more and encourage monthly payouts. It also will get rid of stuck LSK if you have a 0.1 balance for a delegate that is no longer in the top 101.

Also I would make a 2nd subsection for delegate advertising. It's annoying to see the same people posts "vote for me" ads in the reddit pages and forums. Keep that clutter separate.

[karek314]

One idea came to me mind, it can be implement along with other solutions.
This system would make DPoS more competitive and cartel-proof.

I will explain this by an example, it should be pretty straightforward to implement.
Total number of delegates extended to 201, or number of delegates managed dynamically.
top 101(or any other number) - receiving constant block reward. For example 2LSK.
All other position from 102 to 201, proportionally less according to rank.
Example, delegate 133 - reward 1.1 LSK, delegate 150 - 0.8 LSK, etc. (all of course matching assumed inflation scheme)

It would make DPOS more competitive and active. Lower rank delegates in future could easily fund smaller projects, tools while full top delegates bigger ones. This can be also used with feature to punish delegates which double forge/miss blocks from forging for X blocks and replace with other chosen delegate from 102-201 or even 201-300 range (incentivising non-paid standby delegates to keep their nodes up and running), this has con, might cause some instability with block creation. Worth considering anyway.

[karek314]

Worth considering may be also introducing Lisk treasury, shall be created from some part of block rewards (by decreasing block reward, i would say 30% of current block rewards). Each user should be able to submit proposal by paying defined fee and each user should be able to vote on proposals with lowest possible fee.
Some properties of such proposal:

• Each proposal should have minimum weight to process it, related to active weight for Lisk delegates in top 101

• Deadline for evaluating result of proposal, maybe related to fee submitted

• 51% "Yes/No" votes to pass it.

• Possibility to change vote during payout for each proposal in case beneficiary is not keeping promise

• Each proposal should have textfield with description and possibly links to more details.

Such proposals can be used by non-delegate users to gather fund necessary to start projects helpful for Lisk ecosystem expansion.

It may be also reasonable to consider making this system relay only on votes casted by top delegates, making voting mandatory. (after revising entire dpos for sure)

[dhniels]

How will any changes designed to take forging rewards/power over the network be implemented without resistance, or outright denial of the network when its currently under control by basically 2 groups?

[karek314]

@dhniels Well, i'd say - it's economically wiser to stay on fork (lisk hq one, if happens) which have funds and development team behind. One example is ETH and ETC. You seems to confuse exact meaning of "groups" in Lisk. Those are collaborations of individuals as far i know there is no leader per se to force anyone to do something. I really doubt that it's possible to convince all members of one group to harm network.

It's also worth to add that current DPOS model is not doing exactly well, mostly because there is no possibility to develop blockchain applications right now, if we get tools to develop with, then system will drastically evolve to something it should have been. DPOS and voting will only work well if it's incentives are well designed, from what we have seen most people tend to vote for short term gains, most people do not realise that voting for decent delegates who work on tools is worth much more than gaining couple lisk's additionally. That's the root issue here, on the other hand if delegates start develop blockchain apps and offer tokens in their projects by exchange of support in Lisk network. People will start looking for better financial outcome, well - Lisk won't easily do another x40-x100 growth, but new tokens surely can. It will provide better financial incentive which in this case is also better outcome for entire Lisk ecosystem.

How exactly it will work out in reality, can't wait to see.

[4miners]

Also currently Lisk is not big enough for creating "Lisk Classic" to paid off, but for sure it will happen - like in every top coin (which Lisk will become soon or later). That's nothing that we should be afraid however, just enjoy free money. ;)

[TheBlaineMono]

For short term LISK HQ could think about a platform to perform, what Ascend introduced - pledging votes, without spending LSK to actual vote.
It can be done for entire list of delegates (not only one group of delegates), where we can make a visible market of delegates, and how many pledges they got from holders, public for all.

Platform could be done via LISK HQ to keep security and trust ( to avoid any accusation).

[lichuan]

I suggest Lisk consensus should use POW + LIB (last irreversible block) algorithm, the block interval can be set to 10 sec, and 10 confirms is the LIB, because the only consensus algorithm be suitable for public chain is POW.

[pcdinh]

@lichuan

because the only consensus algorithm be suitable for public chain is POW.

Proof?

[lichuan]

@pcdinh
Because in POW, the block producer is determined by hash256 computation, but the other consensus, such as DPOS, the block producer is the witness node, selected by time slot, but this depend on the global time tick, in some network edge case, DPOS will cause many fork branches, and if these branch chain can not reach 2/3 confirms, then the whole DPOS system will be halted forever.

[tomploem]

LiskHQ has dynamic transaction fees on the developers roadmap. Why don't we introduce dynamic voting fees? I am not sure if it would a hard fork but i can imagine it falls under the same undertaking as changing transaction fees.

[karek314]

If they change transaction fees generally it also affects voting fees, or should at least. Vote is just different type of transaction. 1.0.0 is also hard fork, it's not a problem whatsoever. Changing tx fees in general is also a hard fork. We had 1 or 2 already in Lisk. Hard forks are not an issue in any chain unless there is at significant support of change.

[tomploem]

Exactly, Type 0 and Type 3 transactions can be refactored at a similar time.

The idea was a dynamic voting fee with voting decay. Isabella mentioned that voting decay would not be easy to implement. Voting decay will be hard to implement but dynamic voting fee isn't.

Dynamic voting fees creates less insentive for large balances to vote while smaller balances can have a chance to vote again because of the voting fee being a percentage and not 1 LSK ( ~ 11 USD )

A factor thats need to be taking into account is that the change would only work if all votes are dismissed. The large accounts would never vote for upcoming delegates because of the dynamic fee being to much. Votes for the current forgers will never be updated.

[Jaxkr]

I don't think something as complex as voting decay is necessary.

Here's how I would implement voting:

• Make the fee astronomically small. Perhaps consider removing the fee altogether and replacing it with some PoW like Nano uses for its transactions. Users should never be punished for participating in the delegate voting process.
• Make a vote last a single calendar year. It's long enough that it's not too inconvenient, but keeps the delegate set fresh.

Additionally, having a number of votes equal to the number of delegate slots makes no sense, and has led to an incredibly steep cliff between position 101 and 102 (16.2 MILLION) while the average difference between the delegates in the top 101 is less than 500k.

The decision to have 101 delegates was made for a reason. It's an odd number , so there is no risk of a stalemate vote on a potential network fork.
So, it would make sense to give the user 50 votes. This lets them vote for a technical minority of the candidates and keeps the vote distribution less even between the top 101, which makes the forging delegate pool more dynamic.

In conclusion, I think the following would lead to a healthy Lisk DPoS ecosystem:

• Cheap / free voting.
• A lifespan for votes, preferably a year or less.
• A number of available votes per wallet that is less than the number of delegate slots.

[ghost]

My experience in leading a software development company is that you and your team are able to make a far better decision at the time you are ready to cross the bridge when you get there. The whole team will have more knowledge how things will end up working and what is possible after releasing a stable core version 2.x and the SDK. It will be pure luck if you think of a solution now that will work in 6 to 12 months.

[webmaster128]

I second everything that @Jaxkr said. Especially limiting the vote to a number less than 101 forces users to think about individual votes. Maybe the number should be as low as we want the biggest party to get. If there are only 33 votes for example, no party can ask you to vote for more than 33 delegates in order to receive reward sharing.

[5an1ty]

@webmaster128 I agree with what @Jaxkr said, I would just like to add that in case of a limited total vote size of 33. Any group could still form a group of 66 for example, they could use a website where you need to register as a voter and the website will assign you the people you need to vote for. That way they could in theory divide the votes across their 66 members pretty evenly.

Another option could be to increase the amount of votes to for example 201. That would close the cliff between the 101 forging delegates and the others causing a lot more competition. This might however cause too much jitter (delegate forging / not forging / forging ...) that it could cause stability issues for the network.

[Jaxkr]

Hi. I've expanded on my ideas a bit more and have written a proposal on changes I think would help improve the Lisk DPoS ecosystem.
It's a bit lengthy for a GitHub comment, so you can read the draft here: https://medium.com/@jacksonroberts/8896310e202c

I would appreciate your feedback.

[lichuan]

DPOS has many drawbacks, for example, if a witness node was controlled by a attacker, then the attacker can broadcast many conflicting block with the same block height, in such condition, the 101 witness network would be split to many sub-network which are not compatible with each other, at this moment,
if the confirmations of these conflicting blocks is less than 2 / 3 of total num of witness, then the whole network would be suspended. you might say that if can not reach 2 / 3, the system has a timeout mechanism, but wait, if system allow one witness produce two height within a small interval, then different witness would generate different LIB (last irreversible block).

[lichuan]

So, I recommand that lisk should use POW algorithm which is the only one suitable for public blockchain.

[lichuan]

In fact, SHA256 with large amount of memory computations can resist ASIC, because ASIC is good at SHA256 computation, but not memory access.

[webmaster128]

@lichuan please stop spamming about proof of work. Nobody here wants to waste endless amounts of energy, produce tons of carbon dioxide and burn the whole planet just to have a blockchain. This is about how to improve DPoS, not how to go back to the stone age of blockchains.

[Isabello]

Consider this consensus layer:
https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV

Quite a revolutionary approach.

2018-05-31 16:13 GMT+02:00 Simon Warta [e-mail]:

@lichuan https://github.com/lichuan please stop spamming about proof of
work. Nobody here wants to waste endless amounts of energy, produce tons of
carbon dioxide and burn the whole planet just to have a blockchain. This is
about how to improve DPoS, not how to go back to the stone age of
blockchains.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/LiskHQ/lisk/issues/353#issuecomment-393543919, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APzFsMsoZzDANAZRcry31osZbm7yXydmks5t3_qMgaJpZM4LKAVd
.

[lichuan]

@webmaster128 It's not spamming, what I want to point out is that DPOS is not safe, not safe, not safe !!!

[ducktank1990]

Votes should get chanceled after xxxxx blocks

Expected behavior
If a delegate is doing bad work or stop forging for some days he should be outvoted fast

Actual behavior
If a delegate is doing bad work or stop forging the process of unvoting took too long

Reason
There are a lot frozen accounts and the motivation of voting is not big enough
Also vote fee is to expensive atm

Solution
Votings get chanceled after xxxx blocks

Pros
steady voting per account would increase the dynamic of the system
increasing frozen voter accounts dont make the 101 dynamic more sluggish

[lichuan]

The only real safe consensus algorithm is POW, because it is measured by accumulated SHA256 power, others like DPOS or POS is not measured by accumulated stuff.

[karek314]

@lichuan POW won't work well in system which requires blocks to be made with constant block interval time. It's meant to be running applications - imagine clicking "log in" in any modern application and waiting randomly from 10 to 50 seconds.

However, POW is great system to create currency with great properties of perfect money, though we don't need another Bitcoin. Bitcoin as medium of exchange is doing quite well and it's getting better.

[lichuan]

@lichuan POW won't work well in system which requires blocks to be made with constant block interval time. It's meant to be running applications - imagine clicking "log in" in any modern application and waiting randomly from 10 to 50 seconds.

However, POW is great system to create currency with great properties of perfect money, though we don't need another Bitcoin. Bitcoin as medium of exchange is doing quite well and it's getting better.

In term of security, POW is far better than DPOS.

[ducktank1990]

Type xy Transaction: Give your Votepower to xxxxxL
Type yx Transaction: Get back your Votepower from xxxxxL

[Korben3]

Here are some more ideas, I also posted this on lisk chat.

"I would like to share a raw and wild idea I had about a small remake of the current lisk DPOS system.

The following rules might be implemented into the lisk system:

• A registered forging delegate should automatically share at least 50% of it's daily rewards divided to its voters based on the amount of lisk they own.
• Voters receive their lisk as a "type 8 transaction - Transfer lisk to voter" with a 0 lsk fee.
• Delegate may choose to increase sharing percentage by making a "type 9 transaction - Set share percentage" (50-100%).
• Each day at 24:00 is payout day and the voters and delegates receive their lisk.
• Voting fee is changed to 0.1

Example: delegate korben3 shares 50%, earns 256 lsk a day, has 2 voters both own 100 lsk. Voter 1 receives 128 lsk - (100/200)x(256x0.5) or (voter 1/total lsk of all voters)x(total lsk of delegate in 24hr x share percentage).

Reason: This makes voting more attractive, less expensive to switch delegates, pools are less attractive - you're no longer 'forced' to vote for someone in fear of not receiving max payout, voters can now earn lisk from each delegate without having to wait 423+ days for a payout, a more fair system since delegates must share at least 50%, lisk sharing with the voters is now automatically, a delegate cannot suddenly decide not to share, or share less then 50%, an under performing delegate is easier to unvote, ..

Just some brainstorming, let me know what you think "

[karek314]

A registered forging delegate should automatically share at least 50% of it's daily rewards divided to its voters based on the amount of lisk they own.

That is purely invalid and this is wrong direction at all. Sharing anything was not an intention of the system whatsoever. It is broken because network is live for more than 2 years without any product. Ideally delegate position should be ran by entities / associations of developers running delegate account and using it as funding for their own projects. What you propose is actually hardcoding negative consequence of non existent product to lisk core codebase.

I still believe system can get back on track as soon there is something to work with, then voters would get more active as well. Voters should not get any LSK as rewards, but instead getting rewards in sidechain projects token.

[Korben3]

Sharing might not be the intention of the system, but it grew organically and it can become part of the system, As long as there is a vote fee, the main incentive for owners of lisk to vote is a share of the forging reward. Why not make it a part of the system? Without sharing, you would have only a few users who care enough to vote.

[karek314]

Then conclusion is simple - voters are incredibly stupid and vote based system is invalid in first place.

Main incentive of LISK holders should be to choose delegates in wise manner, which would positively impact entire Lisk ecosystem. Voting just to receive rewards is pointless, because if ecosystem does not grow, received token share may be worthless.

However, I presume this is hard to understand for most voters, similar way the democracy does not work properly, while most people tends to vote for very short-sighted gains like:
-social care
-free benefits
-free everything
While missing that eventually they will pay for everything in taxes, if not directly then indirectly in "inflation tax". Moreover such government provided services are mostly ran very inefficiently, therefore it costs much more for much worse service.

So system must be designed wisely. I believe that If Lisk would have sidechain development feature from early days, We wouldn't have this conversation, because delegate accounts securing network could share tokens in own projects, instead of sharing Lisk token, ultimately - this is much better incentive for most voters than receiving LSK. LSK might not have such great potential for further price growth while newly created project always have, either down to nothing or "to the moon". That would also incentives deeper research of delegates/teams.

[smmujahid]

Very well put up arguments

On Wed, 3 Oct 2018 at 1:02 AM, Unhandled Exception [e-mail]
wrote:

Then conclusion is simple - voters are incredibly stupid and vote based
system is invalid in first place.

Main incentive of LISK holders should be to choose delegates in wise
manner, which would positively impact entire Lisk ecosystem. Voting just to
receive rewards is pointless, because if ecosystem does not grow, received
token share may be worthless.

However, I presume this is hard to understand for most voters, similar way
the democracy does not work properly, while most people tends to vote for
very short-sighted gains like:
-social care
-free benefits
-free everything
While missing that eventually they will pay for everything in taxes, if
not directly then indirectly in "inflation tax". Moreover such government
provided services are mostly ran very inefficiently, therefore it costs
much more for much worse service.

So system must be designed wisely. I believe that If Lisk would have
sidechain development feature from early days, We wouldn't have this
conversation, because delegate accounts securing network could share tokens
in own projects, instead of sharing Lisk token, ultimately - this is much
better incentive for most voters than receiving LSK. LSK might not have
such great potential for further price growth while newly created project
always have, either down to nothing or "to the moon". That would also
incentives deeper research of delegates/teams.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/LiskHQ/lisk/issues/353#issuecomment-426410251, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AfeMFfkAusSn2p4m7Dr9k7JiNlCfOSKaks5ug8Y-gaJpZM4LKAVd
.

[uvoz]

Just some thoughts:
Reward the delegate a 1% "mining fee" and distribute the remaing 99% among its voters. That's actually fair. On top of that, compose the delegate top 101 daily based on the quality of their service and not quantity of coins. Such approach likely makes thousands of us switching on a delegate VM on Azure or Amazon resulting in a faster, stronger and better distributed blockchain.

[reaper699]

"The Lightcurve Science team has just opened the discussion for our 11th LIP – Change to one vote per account in our DPoS.
" so the science team has been working very hard and lisk HQ has been spending alot of time and money on them only to come up with this ? very disappointing to say the least . Lets not forget who the ones are that are pushing to change the DPOS system, its the ones who are not forging, what will these "delegates" do when they are not included in the new system? push again and complain again when they are not forging ? Every person had the right to invest in lisk based on the DPOS system that was laid out to us investors in the early stage, to change this system now is to do no better than the rest of the failed DPOS coins that changed their voting process after raising funds. HQ dont forget where you got all your money from ! all your money came from most of the forging delegates who bought into your platform based on the DPOS system you designed as we all saw an opportunity for a good investment ! to change that and take that away is not very honest in terms of business. my personal opinion is that it is a terrible idea , things like ( Lisk incubators ) would not be able to happen if all delegates are sharing 90% plus! you will turn your platform into a Oxy or rise or LWF joke ! where is the incentive for the delegates to create, publish, market if they are all competing against higher sharing! this takes the value down the drain! I think the science team can at least come up with something better then supposedly spending months researching Arks platform ! its a joke
A more promising platform would be rotation of delegates that go down! ie, someone misses a block, second time they get swopped out for someone above 101 for a period of 24 hours, get cycled back and if still missing then get cycled out for another 24 hours
but to change the whole system for a select few that are not happy they do not forge is ridiculous to say the least!
I have been observing the other systems for months ! and I can tell you now that the current systems allows the entire list of delegates to work together against bad players! example: some other DPOS systems that use this 1 vote method , I wont name which one, but when a delegate is sharing 95% , his incentive to keep his node up is not very big, therefor some nodes (and this is fact) are red on mainnet for months! and there is nothing the community can do because all the votes are coming from outside and people who vote externally are not checking or caring about the health of the network at all
so If lisk wishes to "stale mate" the network by choosing this method then go ahead @Mat because the reality is that firstly nodes will get voted in because of their sharing and nothing else (greed ) then who is to say 1 person doesnt create 10 nodes and market them all individually to share 95% , of course they will get votes , then one day when they decide to not care about the nodes and they have millions voted against them, the network will be a failure of red or down nodes because it will be impossible to unvote them as they will have too many votes! at least in the current system the delegates can work together politically to help the network! take this away and you dont have DPOS , but instead you are basically writting the future of the network and then cementing the delegates in place for ever
How often do ark Delegates change ? how is 1 vote in any way contributing to "decentralization" when it puts the networks health at risk ?
is this change for the good of the network or is this just to please some delegates who never invested early enough and worked hard to become delegates . il let the community decide

[Nazgolze]

Forwarding to the lips mailing list so we have this there as well

On Wed, Feb 6, 2019 at 7:58 AM reaper699 [e-mail] wrote:

"The Lightcurve Science team has just opened the discussion for our 11th
LIP – Change to one vote per account in our DPoS.
" so the science team has been working very hard and lisk HQ has been
spending alot of time and money on them only to come up with this ? very
disappointing to say the least . Lets not forget who the ones are that are
pushing to change the DPOS system, its the ones who are not forging, what
will these "delegates" do when they are not included in the new system?
push again and complain again when they are not forging ? Every person had
the right to invest in lisk based on the DPOS system that was laid out to
us investors in the early stage, to change this system now is to do no
better than the rest of the failed DPOS coins that changed their voting
process after raising funds. HQ dont forget where you got all your money
from ! all your money came from most of the forging delegates who bought
into your platform based on the DPOS system you designed as we all saw an
opportunity for a good investment ! to change that and take that away is
not very honest in terms of business. my personal opinion is that it is a
terrible idea , things like ( Lisk incubators ) would not be able to happen
if all delegates are sharing 90% plus! you will turn your platform into a
Oxy or rise or LWF joke ! where is the incentive for the delegates to
create, publish, market if they are all competing against higher sharing!
this takes the value down the drain! I think the science team can at least
come up with something better then supposedly spending months researching
Arks platform ! its a joke
A more promising platform would be rotation of delegates that go down! ie,
someone misses a block, second time they get swopped out for someone above
101 for a period of 24 hours, get cycled back and if still missing then get
cycled out for another 24 hours
but to change the whole system for a select few that are not happy they do
not forge is ridiculous to say the least!
I have been observing the other systems for months ! and I can tell you
now that the current systems allows the entire list of delegates to work
together against bad players! example: some other DPOS systems that use
this 1 vote method , I wont name which one, but when a delegate is sharing
95% , his incentive to keep his node up is not very big, therefor some
nodes (and this is fact) are red on mainnet for months! and there is
nothing the community can do because all the votes are coming from outside
and people who vote externally are not checking or caring about the health
of the network at all
so If lisk wishes to "stale mate" the network by choosing this method then
go ahead @mat https://github.com/mat because the reality is that
firstly nodes will get voted in because of their sharing and nothing else
(greed ) then who is to say 1 person doesnt create 10 nodes and market them
all individually to share 95% , of course they will get votes , then one
day when they decide to not care about the nodes and they have millions
voted against them, the network will be a failure of red or down nodes
because it will be impossible to unvote them as they will have too many
votes! at least in the current system the delegates can work together
politically to help the network! take this away and you dont have DPOS ,
but instead you are basically writting the future of the network and then
cementing the delegates in place for ever
How often do ark Delegates change ? how is 1 vote in any way contributing
to "decentralization" when it puts the networks health at risk ?
is this change for the good of the network or is this just to please some
delegates who never invested early enough and worked hard to become
delegates . il let the community decide

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LiskHQ/lisk/issues/353#issuecomment-460920219, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB2X08tFj2dWbI2dgjzc4Od-HUouloOks5vKn0VgaJpZM4LKAVd
.

[desjob]

@reaper699 so you say it's about who invested the earliest? That list will of people will never change, so there also isn't an increased incentive to do a good job and keep their node up either. Funny that you mention greed. Delegates "create, publish and market" mostly themselves. If you look at the contributions on GitHub, most of it are tools around the delegate system itself. 99% of the people are driven by greed, both delegates and voters.
Honestly, why do you care so much who is forging? Are you really so concerned with the safety of the network? Or do you have something at stake?

[reaper699]

Of course I have something at stake, my investment! no one wants to see their investment go down the drain! and changing the consensus that way would make lisk literally worthless! all big holders will sell , people will share competitively up to 99% making incentive to keep your node uptime worth nothing.

have you even seen the other systems that are doing what is propsed ? OXY ? RISE ? ARK ? LWF ?

take a look at their positions, Lisk needs to focus on SDK and deliver their product that all!

CODERS NUMBER 1 rule, if it works, dont change it, and right now the network works! what we need is a product ! its been how many years and HQ still havent delievered even a beta working product ?

Science team been working for years only to release a statement saying Ark has a good solution ?

[errouthier]

The thing is, the current system does not work. The network may be stable and nodes may be of higher quality due to staking incentive, but the network is not secure when delegates can form groups having more than 51% control of the network. As long as the system falls victim to that, it does not work.

[reaper699]

How is forming a group to base your voting stratergy in anyway making a 51% attack, the answer is it does not ,

[desjob]

@reaper699

"and changing the consensus that way would make lisk literally worthless"

Please provide some arguments if you are going to throw big claims around. The only point I get from your story is that some other coins have changed their consensus in the past and lost value. I'm not convinced the loss of value ik their case is solely because of the change, nor does it mean that would also be guaranteed to happen with lisk.

[2mdoty]

Ark has had far more dynamic change in delegates than Lisk and Ark does not have voting cartels. Also, there is a mix of delegates offering varying amounts profit sharing, development work, code auditing, marketing outreach, and community engagement. Ark actually is functional proof which invalidates every point Reaper has made to try to justify the continued existence of the cartels with the current multiple voting system. The lack of interest in maintaining delegates in LWF has nothing to do with the profit sharing, but is due to the loss of value in the coin and abandonment of the project by its founders. Oxy discontinued DPoS and had also lost a lot of value, and hence, interest prior, though the delegates continued to maintain the network up to the switch to ERC20.

[2mdoty]

@reaper699 - "and changing the consensus that way would make lisk literally worthless"

This basically amounts to a threat against Lisk team and token holders that the Elite Cartel will dump their holdings and drive the Lisk value much lower if the voting is changed against their favor.

[hoklitrail]

Hello from Down Under. BlockcoinAU here.
I subscribed to this Github way back using an old email address so I just want make it clear who’s behind it.
I already mentioned my view in the Lisk chat but I’m posting it here with additional comments, having read previous posts by various people.

Hold your horses there, 2mdoty. :)

There are clearly a lot of fortunes at stake here and changing the voting system will affect existing pools. Understandably there is resistance from pool members and their concerns may seem to solely protect their own agenda.

However, in this case I believe there is merit to voice concern about this proposal. It goes way beyond self interest and self preservation. Reaper has a valid point regardless of whether he’s the representative of Elite or an individual. It is pointless to push for a change at all cost when the bad result of it is already visible across various other blockchain projects. That is basically as destructive to the project as big pools and vote buying are to the DPOS system.

All the potential scenarios that have already been outlined by @cc001, @5an1ty and @reaper69 did already come to fruition in other projects that tried them. It is of course just my personal view that this proposal is not worth much if the only thing HQ has so far, is to copy what others have done. Especially given that the outcome is so easily verifiable.

Claiming that this is not the case for ARK is just as short sighted as claiming that there’s no issue at all with a 51% attack on the LISK blockchain. ARK may simply not have progressed down the path enough for all these issues to become more prominent. All projects are on track to exhibit these exact symptoms and people are already creating delegates following the recipe that has been outlined by @reaper69 and @cc001.

This should not be about who came first and who has a right to be a delegate. The idea of DPOS is that a voting mechanism protects the network and that an active, caring community can vote delegates in and out based on how they perform and how much of a stake they have in the LISK ecosystem. The current system fails in that regard. It has already been shown that un-voting an unresponsive delegate is very difficult to achieve. However, the network is stable and so far we have no evidence that any of the pools are out to cause harm. Quite the opposite actually. Every time we had a major upgrade, it went smoothly and all delegates promptly responded. To suggest/debate a new voting policy that already has a clearly predictable outcome which isn't in our favour seems rather puzzling to me.

There is frustration amongst new delegates because it is impossible to enter the 101 field without the support of one of the big pools. That may well be an issue but this current proposal doesn't solve it in an improved way so it's not worth implementing because it comes with a whole lot of other/new issues/risks that we're already well aware of.

Personally I go as far as claiming that DPOS can't be fixed. It is a failed, flawed system that introduces and encourages corruption and vote buying. It works on paper but it fails in real life because people are greedy. Always have been, always will be. This goes for both sides. Delegates and voters. All these solutions have problems but some problems seem to be particularly nasty and difficult to overcome.

Maybe this is a much bigger topic and moving away from DPOS should be considered as part of a bigger longer running proposal. Even POS will do just fine when compared with DPOS. Patching a broken system is bound to introduce more risk when the actual fundamental flaws continue to exist. So far our chain has moved along quite nicely and all delegates have worked together to solve issues. The suggested proposal puts greed even higher up the chain and does nothing to make the blockchain more secure or stable for that matter.

Talking about solutions is certainly appreciated and working on an improvement rather than replacing DPOS can be helpful too but it would have to address the fundamental issues. It would be just as big a big mistake to settle for the status quo. In my view, this will take considerable time and effort far beyond a few emails and online postings.

On 7 Feb 2019, at 8:35 am, 2mdoty [e-mail] wrote:

@reaper699 https://github.com/reaper699 - "and changing the consensus that way would make lisk literally worthless"

This basically amounts to a threat against Lisk team and token holders that the Elite Cartel will dump their holdings and drive the Lisk value much lower if the voting is changed against their favor.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/LiskHQ/lisk/issues/353#issuecomment-461215640, or mute the thread https://github.com/notifications/unsubscribe-auth/AWZl9LwQUgsNc1yKMFuq0F9KZmDp4xSpks5vK1i9gaJpZM4LKAVd.

[2mdoty]

Forging rewards started on Ark just 4 months after Lisk, a relatively small difference compared to the 2+ years of operation. This is plenty of time for the different systems to demonstrate their fundamentally different results through both good and bad market conditions.

You use the term "greedy". What expected ROI do you define as "greedy", in order to give it an objective definition - .1%, 1%, 10%, 100%, 1000% or some other number? If you can provide such a definition is there consensus for it? Without an objective definition the term is meaningless in rational discussion and just becomes a tool of manipulation by appealing to emotion and casting unfounded guilt.

Also, based on current Lisk valuation of a little over $1 USD, have we seen 25 million dollars worth of development for the over $25,000,000 worth of Lisk kept by delegates?

[shuse2]

This requires Protocol changes.
Please move the discussion to https://research.lisk.io/