Author Topic: Proposal: Max Delegate Pay = Approval Rate  (Read 11935 times)

0 Members and 1 Guest are viewing this topic.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
i would like to have some payment for the following 102-202 delegates on the list. In a time of an DDoS attack or something with this magnitute. What about to pay some of the fees to this "standby" delegates? In the long run we need something like this to replace a delegate fast. what do you think?

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
I do not think it's a good way to drive shareholers to vote by just giving Delegates incentives to push it because it's low efficient. If we want people to vote, it's better to give them incentives directly instead of let Delegates to do it. So I believe we should do this with hard-coded:

1. For every new wallet, people must vote all their shares in like one week(set proper blocks number), if you do not vote, after that(one week), you will lose 5% of the shares in this wallet. We could call this as "iniital vote".

2. After the initial vote or penalty complete, you need to update you vote quaterly(I think yearly is too long), or you will lose 5% shares in this wallet every time.


EDIT for voting incentive: after further discussion with others, I realized that give penalty to these inactive acounts is not a good idea since it's too unfriendly and it may bother users all the time even we think voting is an important duty for everyone. Actually, like Gulu mentioned below, I start to believe financial penalty/award is not a correct way for voting incentive. I suggest we do like this:

Make a status remark for every account to show if it has voted or not, when is its last time to update its votes, and maybe the persentage of voted shares in this account. Make this information listed beside every acount name shows in everyone's wallet clearly and publicly. This may be just a small incentive, but it could be helpful, it's not unfriendly, it's easy to implement. By just doing this, we could not increase the voting rate to like 60% or more, but high voting rate like 60%+ should not be really necessary to the system at all.

EDIT END.



For encourage the Delegates to compete each other and try to clime up on the Delegates list, I think current mechanism already works in an  effective way. To make it even better, we could make the delegates maxiam pay rate limitation linked to their position in the list directly. Like set the maxiam pay rate limitation of No.1 Delegate as 100%, No. 2 as 99.5%, and reduce it by 0.5% of each postion down. For the Delegates in backup list, we could make it w/ discount fixed payrate, like set No.102 delegets to have 49.5%*10%=4.95% fixed payrate every round, and so there will be 99 paid backups in the row(from 4.95% to 0.05%), and these money could be covered by which we reduced from top 101 pay rate. 

As for penalty for bad performance, I think the most important thing is have some automatic machanism to stop the bad performance immediately and make the Delegates have fianance loss meanwhile. For example, if one delegates missed x(may set it lower than 5) blocks continously, stop its right of block production immediately, make all the votes on it invalid until those votes get updated by shareholders. We could also set a maximum cumulative block miss for each Delegate and implement similar penalty. And meanwhile, we could set the cumulative record clear(to 0) like every month or quaterly. We could define more rules w/ similar or different penalty(from stop block production right by 24 hours to ban the delegate forever). The key is too have automatic way to stop the bad performance and/or attack immediately instead of waiting for shareholders to vote them out, which will not happen in minutes or hours for sure. And of couse, the behaviors restriced by these automatic mechanism should be simple/clear enough as "bad performance" or "attack" and get the community in agreement before it implemented into system.

In my view, the proposals above are more effective/simple, so want to share with you for discussion. Thanks.

 +5%

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
their pay should go up the more votes they get. 

 +5% +5% +5%


and I want to propose something CRAZY but maybe genius....

... you end up with a popularity contest but the problem is the most popular person or people might not be anything more than cult of personality. ...is popularity the only thing that matters for a delegate? ...

I agree with this.  I have seen delegate with 91% reliability with more approval than most others with better reliability and blocks produced.  Is the job to reliably produce blocks or to be a politician who is popular but doesn't do their job?  Or maybe that is the question.  What is the job?  Based on all the discussion, time and energy spent on this, you would think the whole point of BitShares is to run and vote for delegates and the other "functionality" is an aside.

so we could add reliability to the equation, something like :

Max Delegate Pay = (Approval Rate * reliability) / 100

reliability = reliability for the last x blocks (because "current" reliability should be more importand than total...)


Offline GaltReport

... you end up with a popularity contest but the problem is the most popular person or people might not be anything more than cult of personality. ...is popularity the only thing that matters for a delegate? ...

I agree with this.  I have seen delegate with 91% reliability with more approval than most others with better reliability and blocks produced.  Is the job to reliably produce blocks or to be a politician who is popular ?  Or maybe that is the question.  What is the job?  Based on all the discussion, time and energy spent on this, you would think the whole point of BitShares is to run and vote for delegates and the other "functionality" is an aside.

I would think that from a user standpoint, all this delegate and voting stuff is all back-office maintenance.  There should be some default vote for recommended slate of delegates or deault proxy for voting.  For example, I don't have the time or desire to participate in my homeowner's association much so I sign a proxy so that the current president can vote for me.


« Last Edit: August 17, 2014, 12:46:53 pm by GaltReport »

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
how to encourage user to vote up to 101 delegates. how about use this way ,translation fee is changed depend on how many delegates user vote
for example , resume max translation fee can increase 50% if  the user don`t vote any delegate.
Tx fee=0.15-(101-VN)*0.5/101, VN : how many delegates user vote
I don`t konw it will increse how much CPU load while checking if a translation is valid.
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
I like delegates taking ownership for the network, giving them an economic incentive to improve participation by everyone.

I still think the game-theory behind delegates strategy is kind of backwards with weird incentives (e.g., delegates have the incentive to actively damage the network in the case of a price shock; delegates are "forced" to keep pay rates well above market value). This proposal has good intentions, but layered on top of the other backwards incentives might lead to a big problem:

If I'm running a node and I choose a 20% payrate to be my subsistence rate with 100% uptime. My vote total drops from 100% to 95%, and I have no ability to raise my rate, I now have the incentive to turn off my node. You then have to wait for enough people to vote you out, which may not happen quickly - and there is now a dead delegate for an indefinite amount of time.

I generally believe the market should sort it out:
1) delegates should be allowed to set the pay rates to whatever they want (I understand the argument against, perhaps you can allow for a publicized lag time between when it is announced and set. Give users the choice whether or not they want to vote for someone that chooses to run a dynamic operation where payrate tracks bitUSD, for example).
2) If users do not want a delegate in, they should be able to down-vote a delegate.


EDIT: For this plan to work, delegates also have to have the ability to raise their pay rate.

Actually I wouldn't have it multiply like that.   If you have a pay rate at 20% and an approval of 100% your effective pay rate will be 20%.   If you have a pay rate of 20% and approval of 21% you still get 20%.   If you have pay rate of 20% and approval of 15% then your pay rate is only 15%.

Effectively low-approval delegates cannot demand 100% pay rate.   But high approval delegates can get their pay rate.

I thought of this and I think we must keep it simple, fair and it should motivate us more for a better place on the delegate list.
So it would be best in my mind to implement your proposal ( Max Delegate Pay = Approval Rate ) but cancel the payrate option for all delegates because it is not needed anymore because of the  effective pay rate. So if for example the effective pay rate due to Approval rate is 15% then pay them 15% and burn the 85%, it' simple like that....  It would not be fair for one delegate to be on the first places and get paid for example 10% instead of 80% because he made a wrong/bad decision (considering the present NEW terms and conditions) in the past...
And it don't gives enough motives to low pay rate delegates to want to go up the list... I am a good example with a payrate of 5% :P... Why should I get concerned to go up the list if I am on spot 40 if I can not win more? I don't say they don't exist motivation at all, I say the motivation would be much greater knowing I get paid better if I perform better...


PS and with the system how it is right now some of the first delegates on the list would make only greater efforts if they loose many spots. With your proposal even the second delegate would try to get on spot 1  ;) (of course only if pay rate is canceled or they have from the beginning 100% payrate)
Not to mention that delegates that feels comfortable on their spots have only motives to get new delegates active and not improove current delegates spot places...
« Last Edit: August 17, 2014, 12:28:32 pm by liondani »

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
Based on this I'd like to propose the following delegate payment method:
1. 10% of all taxes go into a cover fund. This amount should be vote-changeable by delegates (perhaps with some bounds).
2. 2% reduction for each missed block in the last 1000 (up to max 50%).
3. 1% reduction for each missed block (by previous delegate in round) (up to max 25%).
4. Delegate pay ratio is calculated now.
Sounds reasonable .. but why is 3)? Whats the reason I get 1% off because the delegate one block earlier missed his block? Or am I reading it wrong?

After some thinking I believe penalties for 2 and 3 should be equal. Its just communication between 2 parties. Difficult to tell who is to blame.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
@yidaidaxia you cannot enforce #1 at the protocol without a global weekly inactivity fee...

Sent from my SCH-I535 using Tapatalk

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline gulu

  • Full Member
  • ***
  • Posts: 121
    • View Profile
And I oppose against slated voting. Too centralized. Likely do more damage than good. But multi-voting is good.
BTC: 1FRsgcQELHKFY2VMFosBnyBaNxZgS4wj7x
PTS: Pf9yDYUknXShepu6YjwSEpMvm1ewNQLNgE
BTSX: gulu

Offline gulu

  • Full Member
  • ***
  • Posts: 121
    • View Profile
Delegates should be focused on getting the vote out, their pay should go up the more votes they get. 

Theory:  people not approving of a delegate shouldn't be expected to pay for that delegate so pay should be proportional.

This would significantly increase incentive for delegates to get people involved....
This is just the nature of democracy. I don't recall any voting rate of US president higher than 50% in the recent decades. In BTSX's case, many shares are simply in cold storage. It is rather inconvenient for them to vote.
BTC: 1FRsgcQELHKFY2VMFosBnyBaNxZgS4wj7x
PTS: Pf9yDYUknXShepu6YjwSEpMvm1ewNQLNgE
BTSX: gulu

Offline yidaidaxia

  • Full Member
  • ***
  • Posts: 179
    • View Profile
I do not think it's a good way to drive shareholers to vote by just giving Delegates incentives to push it because it's low efficient. If we want people to vote, it's better to give them incentives directly instead of let Delegates to do it. So I believe we should do this with hard-coded:

1. For every new wallet, people must vote all their shares in like one week(set proper blocks number), if you do not vote, after that(one week), you will lose 5% of the shares in this wallet. We could call this as "iniital vote".

2. After the initial vote or penalty complete, you need to update you vote quaterly(I think yearly is too long), or you will lose 5% shares in this wallet every time.


EDIT for voting incentive: after further discussion with others, I realized that give penalty to these inactive acounts is not a good idea since it's too unfriendly and it may bother users all the time even we think voting is an important duty for everyone. Actually, like Gulu mentioned below, I start to believe financial penalty/award is not a correct way for voting incentive. I suggest we do like this:

Make a status remark for every account to show if it has voted or not, when is its last time to update its votes, and maybe the persentage of voted shares in this account. Make this information listed beside every acount name shows in everyone's wallet clearly and publicly. This may be just a small incentive, but it could be helpful, it's not unfriendly, it's easy to implement. By just doing this, we could not increase the voting rate to like 60% or more, but high voting rate like 60%+ should not be really necessary to the system at all.

EDIT END.



For encouraging the Delegates to compete each other and try to clime up on the Delegates list, I think current mechanism already works in an  effective way. To make it even better, we could make the delegates maxiam pay rate limitation linked to their position in the list directly. Like set the maxiam pay rate limitation of No.1 Delegate as 100%, No. 2 as 99.5%, and reduce it by 0.5% of each postion down. For the Delegates in backup list, we could make it w/ discount fixed payrate, like set No.102 delegets to have 49.5%*10%=4.95% fixed payrate every round, and so there will be 99 paid backups in the row(from 4.95% to 0.05%), and these money could be covered by which we reduced from top 101 pay rate. 

As for penalty for bad performance, I think the most important thing is have some automatic machanism to stop the bad performance immediately and make the Delegates have fianance loss meanwhile. For example, if one delegates missed x(may set it lower than 5) blocks continously, stop its right of block production immediately, make all the votes on it invalid until those votes get updated by shareholders. We could also set a maximum cumulative block miss for each Delegate and implement similar penalty. And meanwhile, we could set the cumulative record clear(to 0) like every month or quaterly. We could define more rules w/ similar or different penalty(from stop block production right by 24 hours to ban the delegate forever). The key is too have automatic way to stop the bad performance and/or attack immediately instead of waiting for shareholders to vote them out, which will not happen in minutes or hours for sure. And of couse, the behaviors restriced by these automatic mechanism should be simple/clear enough as "bad performance" or "attack" and get the community in agreement before it implemented into system.

In my view, the proposals above are more effective/simple, so want to share with you for discussion. Thanks.
« Last Edit: August 17, 2014, 01:20:56 pm by yidaidaxia »
PTS: PmUT7H6e7Hvp9WtKtxphK8AMeRndnow2S8   /   BTC: 1KsJzs8zYppVHBp7CbyvQAYrEAWXEcNvmp   /   BTSX: yidaidaxia (暂用)
新浪微博: yidaidaxia_郝晓曦 QQ:36191175试手补天

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
3 is because a delegate could decide to ignore previous delegate's block even if he received that block on time.
If it is intentional - the penalty should be even more severe (but none can prove it).
If it is technical issue with delegate's connection - he will suffer (at least 1%).
If it is technical issue with the previous delegate - the penalty will be spread randomly to everyone until this is fixed.
explains it ... +5%

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
3 is because a delegate could decide to ignore previous delegate's block even if he received that block on time.
If it is intentional - the penalty should be even more severe (but none can prove it).
If it is technical issue with delegate's connection - he will suffer (at least 1%).
If it is technical issue with the previous delegate - the penalty will be spread randomly to everyone until this is fixed.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Based on this I'd like to propose the following delegate payment method:
1. 10% of all taxes go into a cover fund. This amount should be vote-changeable by delegates (perhaps with some bounds).
2. 2% reduction for each missed block in the last 1000 (up to max 50%).
3. 1% reduction for each missed block (by previous delegate in round) (up to max 25%).
4. Delegate pay ratio is calculated now.
Sounds reasonable .. but why is 3)? Whats the reason I get 1% off because the delegate one block earlier missed his block? Or am I reading it wrong?

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
I propose we make an equation like

                      Max Pay Rate= Approval Rate*2*Stability

   The principle behind this is that if one delegate gets over 50% of approval, he deserves everything, as in real company. Of course, Max Pay Rate can not exceed 100%.

However, I am against the idea that all standby delegates get pay also, because some big shareholders would vote for his own 101 delegates but doesn't contribute to network security.  Then DPOS is no different to POS. Probably only the top 50 standby delegates deserve pay, 50 backups are enough.

Big plus for adding stability to the equation. Unstable delegates should be paid less.
I would also suggest half the penalty for the delegate just after the one that missed block.
Also I'm against pay based on vote %. Each delegate in top 101 does the same job (hopefully). Doesn't matter if it is most approved or not.
I also support adding part of the taxes into cover fund.

Based on this I'd like to propose the following delegate payment method:
1. 10% of all taxes go into a cover fund. This amount should be vote-changeable by delegates (perhaps with some bounds).
2. 2% reduction for each missed block in the last 1000 (up to max 50%).
3. 1% reduction for each missed block (by previous delegate in round) (up to max 25%).
4. Delegate pay ratio is calculated now.

Any feedback welcome.