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

0 Members and 1 Guest are viewing this topic.

Offline theoretical


Suppose there are two possible policies (P or Q) that the network could follow at the choice of the delegates.

Suppose 40% of the network will vote for delegates who support policy P but never those who support policy Q, while 60% of network will vote for delegates who support policy Q but never policy P.

I think bytemaster's goal in proposing this change is to incentivize delegates to move from policy P to policy Q in this situation.  With the intent of creating consensus -- reaching equilibrium when all delegates support Q.  [1]

I thought at first that this would happen -- delegates would always be incentivized to move from P to Q in order to raise their max payout.  Because moving from P to Q would always increase your approval rating from 40% to 60%, regardless of how many delegates currently support P or Q.

But I thought a little more and realized this is not actually the case.  While the GUI tells the user they can vote for any number of candidates, in actuality each BTSX can only vote for up to some maximum number of delegates K (to keep bytes per transaction reasonable).  The Q supporters have 0.6 * M * K total votes, while the P supporters have 0.4 * M * K total votes, where M is the total number of BTSX in circulation.  If there are N_P delegates who support P, and N_Q delegates who support Q, the average number of votes per delegate for each faction would be:

    A_P = 0.4 * M * K / N_P
    A_Q = 0.6 * M * K / N_Q

At equilibrium we must have A_P = A_Q (otherwise delegates would switch to the other faction to increase their payout):

    0.4 / N_P = 0.6 / N_Q

Which simplifies to:

    0.4 / 0.6 = N_P / N_Q

In other words, the equilibrium actually occurs when the factional proportions of the delegates reflects the factional proportions of the population.  I think this will happen as long as the number of approvals is limited by K, which in turn is a fundamental consequence of limited bytes per transaction and large pool of delegates, which cannot be overcome without increasing bytes per transaction (increasing bandwidth and storage requirements for everyone) or decreasing the number of live delegates from 100 to K (greatly increasing centralization).

One solution to the conundrum might be to allow transactions that ignore the limit K and vote for up to a full slate of 101 delegates (or 151 if we increase the delegate count), but requiring such transactions to pay R times the normal fee, where R is equal to the size of the transaction divided by the size of a normal transaction.  Thus, K becomes a "soft limit" where exceeding K merely leads to an increase in fees, whereas AFAIK currently K is a "hard limit" (transactions which attempt to vote for more than K delegates are simply rejected).

[1] Under the simplifying assumption that delegates always set their payout to 100%, are thus actually paid proportional to their approval rating, and only care about their payout rate.  I.e. this model doesn't consider delegates who set lower payouts to gain approval, or delegates who believe in a minority opinion for ideological reasons and are willing to accept a lower payout as the price of keeping their principles (although both of those are quite plausible real behavior of real delegates; indeed, enabling the first option is the reason why the client allows delegates to set their pay rate!)
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Hi can anyone explain what a Delegate is and how they work? I've been looking for an explanation and I can't find anything!

Thanks!
                    = ^  ^ =
                     ~ '   ' ~
                          ^

Simplest terms... a delegate is a miner elected by the coin holder to produce blocks.  There are only 101 of them.

Only 101 of them are active at any point of time but many more are waiting ready to start the "hard" work .... Just vote them in  ;)


Offline tajnost

  • Newbie
  • *
  • Posts: 7
    • View Profile
i can has delegate vote?
wallet_approve_delegate tajnost
 8)

Offline Fox

I think there needs to be a weighting to high reliability. Because 95% reliability is terrible, but the payout isn't much different from having 99.99% reliability (only a 5% difference), so the incentive isn't there to get high reliability. On the other hand, if you make 95% or below = 10%, and 96% = +20%, 97% = +40%, 98% = +60%, 99%=+80%, 99.9% = +100%, this should put the incentive in the right place.

Discussion earlier in this thread include expanding the delegate slate and payout beyond the current 101, perhaps to 150.  Standby delegates #102+ may not have a valid non-zero reliability rate, which may impact payout calculations offered above. 

Current approval rates for delegate #102 drop rapidly from ~6% to ~0.6% for delegate 150.  Interestingly, the sum of approval rate for this lot is ~101% or on average a 1% subsidy per active delegate to support the standby delegates.

I feel expanding the payout delegate pool beyond 101 has merit, as having a node up to date and ready to produce blocks for the network provides value if called upon. 

Witness: fox

Offline bytemaster

Hi can anyone explain what a Delegate is and how they work? I've been looking for an explanation and I can't find anything!

Thanks!
                    = ^  ^ =
                     ~ '   ' ~
                          ^

Simplest terms... a delegate is a miner elected by the coin holder to produce blocks.  There are only 101 of them.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline dankeykang

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
    • Marie's Meows
Hi can anyone explain what a Delegate is and how they work? I've been looking for an explanation and I can't find anything!

Thanks!
                    = ^  ^ =
                     ~ '   ' ~
                          ^
Bitshares X account:  mwpeace

Please checkout my cat shelter, http://mariesmeows.wix.com/alliancerescues

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
I think there needs to be a weighting to high reliability. Because 95% reliability is terrible, but the payout isn't much different from having 99.99% reliability (only a 5% difference), so the incentive isn't there to get high reliability. On the other hand, if you make 95% or below = 10%, and 96% = +20%, 97% = +40%, 98% = +60%, 99%=+80%, 99.9% = +100%, this should put the incentive in the right place.

I like the idea, but I still strongly believe that market should decide what delegate's pay rates should be - not arbitrary weighted scores.

For example, the market wouldn't necessarily punish a charity (or developer) delegate with 95% reliability while the market would punish a for-profit delegate with 95% reliability in a given week. In order for such a market to work, you need to allow delegate pay rate to rise and fall with market forces. Fee adjustment alone won't help since that is more of a global fix. You want the ability for individual delegates to to react to direct market forces, which would mean allowing delegates to adjust pay rates.
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline kokojie

  • Sr. Member
  • ****
  • Posts: 286
    • View Profile
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...)

I think there needs to be a weighting to high reliability. Because 95% reliability is terrible, but the payout isn't much different from having 99.99% reliability (only a 5% difference), so the incentive isn't there to get high reliability. On the other hand, if you make 95% or below = 10%, and 96% = +20%, 97% = +40%, 98% = +60%, 99%=+80%, 99.9% = +100%, this should put the incentive in the right place.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
I wonder if another KPI can be included. :
1 Calculate what percentage of transactions in blocks produced by the delegates are known in advance.
2 Check how many known transactions willing to pay fee higher than min transaction fee in blocks produced by delegates are known in advance.
3 Any other transactions that should be included in the block but aren't.

For this to work a layer of control over delegates might be required. For example the following:

"Performance Control Nodes" - They act as normal nodes connected to seed nodes and/or closest delegates. They gather transactions and evaluate delegate's produced blocks in the above mentioned manner (1,2,3).

Is it possible to link several independent such nodes to each delegate and force the delegate to exchange all the information with these nodes. For example:
A delegate receives a signed transaction but before he is able to include it to a block he should transmit it to all "Performance Control Nodes".
In that case a best practice for a delegate might be to make sure that most of "Performance Control Nodes" connected to the delegate have received the transaction(s) being included into a block before producing it.

I was just curious if some delegate control mechanism is possible and if this idea makes sense.

PS: after posting I glanced over the topic... This is way off topic. Sorry for that.

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags
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....

if it's possible to  Automatical  evaluate  delegate   by KPI?
Considering factors such as "delay","missinig block percent", "online time " ,"pay rate" ,"Approval Rate "at the same time
but with “weight percent” voted by btser?

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
I think the lotto reward can be using at  BTS-vote too,
give some reward to the one who vote for the winner
let it be beneficial to vote for the right one.

Offline yidaidaxia

  • Full Member
  • ***
  • Posts: 179
    • View Profile
I have an idea to encourage users to vote, for 101 delegate.
like LOTTO, for example, we have 101 delegate active now, they have get their votes, maybe totally 40,000,000,000 votes.
we generate a random number between 1-40,000,000,000 every 24*60*6 blocks.
we can get this lucky vote's address
then give a lucky reward  to this address, part of  the destroy fee at this day.

to increase the chance to get the reward, users need to vote more delegate, and to the right delegate.

very good idea!  but i suggest do not link the reward to the delegate , just to enlarge their possibility by voting more delegates is good enough



PTS: PmUT7H6e7Hvp9WtKtxphK8AMeRndnow2S8   /   BTC: 1KsJzs8zYppVHBp7CbyvQAYrEAWXEcNvmp   /   BTSX: yidaidaxia (暂用)
新浪微博: yidaidaxia_郝晓曦 QQ:36191175试手补天

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
I have an idea to encourage users to vote, for 101 delegate.
like LOTTO, for example, we have 101 delegate active now, they have get their votes, maybe totally 40,000,000,000 votes.
we generate a random number between 1-40,000,000,000 every 24*60*6 blocks.
we can get this lucky vote's address
then give a lucky reward  to this address, part of  the destroy fee at this day.

to increase the chance to get the reward, users need to vote more delegate, and to the right delegate.

A lottery that users are entered into by voting for delegates. I like it!  +5%
I like it too.  It would currently take about $3M of BTSX to elect 101 of your own delegates.  I would like to see the voting percentage increase for the security of the network. 

My concern with max delegate pay being based upon approval level is that I believe it will result in limited voter turnout.  If I own 1% of BTSX, and I feel that the network is already secure, why would I vote for current delegates with a payout rate above their approval rate?  It would be reducing my profits for no apparent gain. 
« Last Edit: August 18, 2014, 01:01:34 am by puppies »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Empirical1

  • Hero Member
  • *****
  • Posts: 884
    • View Profile
I have an idea to encourage users to vote, for 101 delegate.
like LOTTO, for example, we have 101 delegate active now, they have get their votes, maybe totally 40,000,000,000 votes.
we generate a random number between 1-40,000,000,000 every 24*60*6 blocks.
we can get this lucky vote's address
then give a lucky reward  to this address, part of  the destroy fee at this day.

to increase the chance to get the reward, users need to vote more delegate, and to the right delegate.

A lottery that users are entered into by voting for delegates. I like it!  +5%

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
I have an idea to encourage users to vote, for 101 delegate.
like LOTTO, for example, we have 101 delegate active now, they have get their votes, maybe totally 40,000,000,000 votes.
we generate a random number between 1-40,000,000,000 every 24*60*6 blocks.
we can get this lucky vote's address
then give a lucky reward  to this address, part of  the destroy fee at this day.

to increase the chance to get the reward, users need to vote more delegate, and to the right delegate.

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.

Offline ripplexiaoshan

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 2300
    • View Profile
  • BitShares: jademont
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.
BTS committee member:jademont

Offline fuzzy

This is getting very interesting here ..
Just my 2btsx:

I'd like to be able to run the charity delegates at 100% payrate ... (if possible) .. i am sure the reasoning behind that is obvious, isn't it?

 This is a good point.  It can eventually block out delegates who do not receive high pay, keeping them from scaling in a way that would make it nearly impossible those at the top to be taken out of their position by someone who, for instance, is trying to run delegates and not interested in putting all their funds back into building a huge delegate "firm".

It becomes too hierarchical for my tastes.  However, seeing the delegates increased from 101 to 150 seems not too bad an idea.
« Last Edit: August 16, 2014, 06:47:59 pm by fuznuts »
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
This is getting very interesting here ..
Just my 2btsx:

I'd like to be able to run the charity delegates at 100% payrate ... (if possible) .. i am sure the reasoning behind that is obvious, isn't it?

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags
if it's possible to  Automatical  evaluate  delegate   by KPI?
Considering factors such as "delay","missinig block percent", "online time " ,"pay rate" ,"Approval Rate "at the same time
but with “weight percent” voted by btser?
« Last Edit: August 16, 2014, 05:46:35 pm by sudo »

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Proposal: Max Delegate Pay = Approval Rate

It would give a motive to concentrate the marketing efforts on one delegate account for each individual...
I mean it is much more worth to have 1 strong active delegate on top 20 rank instead of more active delegates on the last spots...

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Incentivizing delegates to pursue consensus rather than just enough support to stay in makes sense to me.  Max Delegate Pay = (Approval Rate / Highest Current Approval Rate) could provide such incentives with less startup shock.
« Last Edit: August 16, 2014, 03:27:39 pm by Troglodactyl »

Offline fuzzy

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.

another idea:
what about not to burn some BTSX but use them to pay standby delegates...(?)
for example If you have a pay rate of 80% and approval of 15% then:
1. your effective pay rate is 15%
2. 20% of BTSX get burnt (like before from total)
3.but  65% get spited proportional to their votes to all delegates included the standby...


I'll just say this and let it be where it is so people can at least know of the plans we were considering behind the scenes. 

We were thinking to build a platform where Delegates essentially pay registered DPOS users to help propagate their content.  "Action Points" could be purchased in bitUSD, bitYuan, bitRubles, bitGold/Silver...etc, as "donations to Beyond BitcoinX".  A daily purchasing cap in addition to an account total cap on "action points" would be present to keep any delegate from becoming too powerful. These work to fuel creation and sharing of content (whether educational, entertaining, pr-related...anything really). These action points can then be attached to posts that a Delegate or Sponsor Users think needs to be known by the rest of the investors and crypto community.  *I wont go into all the plans for uses of these points outside of this sphere yet* 

In the case above, using this platform, the Delegates philosophically inclined to agree to do something like what you say above would pay the community in its saved-up "action points" to propagate the content on social media.  There will be a cap to ensure users can't game the system (unless they go to the trouble of creating another account and building trust on it too).  And even links to DAC/Delegate sponsors could incentivize users to click on them by being given action points to be redeemed by a user. 

This way delegates are not forced to do any particular thing by the system.  All they have to do is get power from those who have a vested interest in the system.  We are looking for helpers in this project if anyone is interested.  There are also projects around the forums I have thought i'd like to utilize in conjunction with this (as part of the sites functionality), so I'd be interested to hear what you have to say about this within the system you are proposing if you can muster the time to explain. 

As far as the transaction fees there are potentially really cool things that can be done with that.  Interested in hearing further solutions.
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline Empirical1

  • Hero Member
  • *****
  • Posts: 884
    • View Profile
 +5% I like the idea of pay being related to approval rate.
I also like the idea of paying some standby delegates something.

I think there may be other approval requirements introduced in the case of equity release anyway, but that's something that concerned me as I'd rather equity release was only directed to the delegates that had the most approval.

Xeldal

  • Guest

I view it this way, for someone to get 100% pay they should have 100% approval.   Shareholders who don't approve of a candidate shouldn't have to pay that delegate.  By doing it this way we are really protecting shareholder property rights.  A vote is "consent to pay".   I think this really encourages delegates to move the network toward consensus and unite the shareholder opinions (increasing security) rather than divide opinions and decrease security. 

I don't think its a cut and dry property rights fix

Is that shareholder really paying the delegate?  If their not making transactions their not paying anyone.  Your vote is guaranteeing all other shareholders property to pay that delegate not just your own.

Whether or not I vote for a candidate, I will still end up paying him, based on everyone else's vote.

To me this guarantee's that no delegate will receive 100% pay.  good or bad idk.

Offline fuzzy

There are other solutions.  One of them would be to have delegates contribute to a site, or network of sites, where users are incentivized to learn about DACs, their Delegates and act in what they individually (or collectively) see as in the best interest of the ecosystem(s).

Does there come a point where putting these types of things in the code take away the ability of the users, and those trying to build a layer that enables them to collaborate and act in ways that dynamically provide solutions in times when quick adaptation becomes necessary? 

It becomes very easy sometimes for engineers to think that they can engineer a "perfect" solution.  To me, that is where enabling the users comes in.  Opinions?

I view it this way, for someone to get 100% pay they should have 100% approval.   Shareholders who don't approve of a candidate shouldn't have to pay that delegate.  By doing it this way we are really protecting shareholder property rights.  A vote is "consent to pay".   I think this really encourages delegates to move the network toward consensus and unite the shareholder opinions (increasing security) rather than divide opinions and decrease security. 

I am also thinking that for security purposes we may need to allow more than 101 votes, perhaps 150 per slate so that voting for "standby delegates" doesn't come at the expense of reducing security of active delegates.

Listening ;) 
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

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.

another idea:
what about not to burn some BTSX but use them to pay standby delegates...(?)
for example If you have a pay rate of 80% and approval of 15% then:
1. your effective pay rate is 15%
2. 20% of BTSX get burnt (like before from total)
3.and 65% (will not burnt ) get split proportional to their votes to all delegates (included the standby)...
 
« Last Edit: August 16, 2014, 02:51:22 pm by liondani »

Offline bytemaster

There are other solutions.  One of them would be to have delegates contribute to a site, or network of sites, where users are incentivized to learn about DACs, their Delegates and act in what they individually (or collectively) see as in the best interest of the ecosystem(s).

Does there come a point where putting these types of things in the code take away the ability of the users, and those trying to build a layer that enables them to collaborate and act in ways that dynamically provide solutions in times when quick adaptation becomes necessary? 

It becomes very easy sometimes for engineers to think that they can engineer a "perfect" solution.  To me, that is where enabling the users comes in.  Opinions?

I view it this way, for someone to get 100% pay they should have 100% approval.   Shareholders who don't approve of a candidate shouldn't have to pay that delegate.  By doing it this way we are really protecting shareholder property rights.  A vote is "consent to pay".   I think this really encourages delegates to move the network toward consensus and unite the shareholder opinions (increasing security) rather than divide opinions and decrease security. 

I am also thinking that for security purposes we may need to allow more than 101 votes, perhaps 150 per slate so that voting for "standby delegates" doesn't come at the expense of reducing security of active delegates. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline fuzzy

There are other solutions.  One of them would be to have delegates contribute to a site, or network of sites, where users are incentivized to learn about DACs, their Delegates and act in what they individually (or collectively) see as in the best interest of the ecosystem(s).

Does there come a point where putting these types of things in the code take away the ability of the users, and those trying to build a layer that enables them to collaborate and act in ways that dynamically provide solutions in times when quick adaptation becomes necessary? 

It becomes very easy sometimes for engineers to think that they can engineer a "perfect" solution.  To me, that is where enabling the users comes in.  Opinions?
« Last Edit: August 16, 2014, 02:23:17 pm by fuznuts »
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline bytemaster

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.
OK that's good. What happens if very few have enough votes to cover expenses? This is a problem now and possibly during price shocks

I also would like to see some way to allow delegates to get paid tracking another bit asset via dynamic payrates.

Raise fees if they cannot make enough to cover expenses.   The fees collected will go up dramatically from where they are now as trx volume and trading kicks in.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
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.
OK that's good. What happens if very few have enough votes to cover expenses? This is a problem now and possibly during price shocks

I also would like to see some way to allow delegates to get paid tracking another bit asset via dynamic payrates.
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline bytemaster

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.   
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
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.
« Last Edit: August 16, 2014, 01:59:08 pm by maqifrnswa »
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline bytemaster

I like the idea of paying the standby delegates something, a sort of "on call" pay.   If they are paid proportional to their votes then they are really campaigning for voter turn out and have incentive to grow.

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

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

why not to pay all delegates that have more than x% of votes even if they are stand by delegates proportional to their votes !!!
think about it please! So even standby delegates are motivated to go up the list that are not close to the first 101 active delegates...

PS of course the active ones should get paid better for example delegate 101 even if they are very close (about same votes) with the delegate 102 should maybe get twice the money compared with the standby delegate 102 ...

Then 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. It doesn't seem to provide an incentive to have decentralization or to have quality delegates.

Maybe my understanding of it is incorrect but is popularity the only thing that matters for a delegate? Or are we measuring the ability of the delegate to attract followers similar to Twitter?

This has to be explained in more detail. I think it does have potential if we built Twitter like functionality into the Bitshares client so people could read blog posts or tweets from delegates and follow them but it doesn't seem to make a lot of sense right now because there is no infrastructure in place to encourage that kind of community participation.

is this not what happen right know? The more popular or richest (because of more voting power) have the most votes?

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
their pay should go up the more votes they get. 

 +5% +5% +5%


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

why not to pay all delegates that have more than x% of votes even if they are stand by delegates proportional to their votes !!!
think about it please! So even standby delegates are motivated to go up the list that are not close to the first 101 active delegates...

PS of course the active ones should get paid better for example delegate 101 even if they are very close (about same votes) with the delegate 102 should maybe get twice the money compared with the standby delegate 102 ...

Then 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. It doesn't seem to provide an incentive to have decentralization or to have quality delegates.

Maybe my understanding of it is incorrect but is popularity the only thing that matters for a delegate? Or are we measuring the ability of the delegate to attract followers similar to Twitter?

This has to be explained in more detail. I think it does have potential if we built Twitter like functionality into the Bitshares client so people could read blog posts or tweets from delegates and follow them but it doesn't seem to make a lot of sense right now because there is no infrastructure in place to encourage that kind of community participation.

« Last Edit: August 16, 2014, 01:30:20 pm by luckybit »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
At first glance I like it.  Wont this create the incentive for end users to not vote though?  Since they are reducing their dividends by increasing the approval rate of delegates.
no if the first delegate on the list get 100% pay rate and the last one 1%, so the average total pay rate for delegates  would be always 50% !!! So you vote for the best and you want to get involved to go up the list!

This isn't going to work so well. You need a minimum pay rate or there will be delegates but it could centralize. If it's based around how many people the delegate gets to vote then the delegate could just pay people in cash or in BitUSD to vote for them.

I don't see how this would work as intended.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster


At first glance I like it.  Wont this create the incentive for end users to not vote though?  Since they are reducing their dividends by increasing the approval rate of delegates.

Delegates already set a cap on their pay.


Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

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

why not to pay all delegates that have more than x% of votes even if they are stand by delegates proportional to their votes !!!
think about it please! So even standby delegates are motivated to go up the list that are not close to the first 101 active delegates...

PS of course the active ones should get paid better for example delegate 101 even if they are very close (about same votes) with the delegate 102 should maybe get twice the money compared with the standby delegate 102 ...
« Last Edit: August 16, 2014, 12:31:41 pm by liondani »

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Delegate #1 and delegate #101 would have the same responsibility for the security of the network but their incentives to stay honest would be different (given delegate # 101 doesn't see any big change to move up the list).

going from 1% to 2% is double money !!!!   Right now ok it's nothing (due to present BTSX value and transaction volume), but think what it means when the network transactions grow due to adaption and due bitASSETS transactions fees and bigger volumes in general etc.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Delegate #1 and delegate #101 would have the same responsibility for the security of the network but their incentives to stay honest would be different (given delegate # 101 doesn't see any big change to move up the list).   

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
At first glance I like it.  Wont this create the incentive for end users to not vote though?  Since they are reducing their dividends by increasing the approval rate of delegates.
no if the first delegate on the list get 100% pay rate and the last one 1%, so the average total pay rate for delegates  would be always 50% !!! So you vote for the best and you want to get involved to go up the list!

Offline cgafeng

At first glance I like it.  Wont this create the incentive for end users to not vote though?  Since they are reducing their dividends by increasing the approval rate of delegates.
good point.
BTC:1EYwcZ9cYVj6C9LMLafdcjK9wicVMDV376

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
At first glance I like it.  Wont this create the incentive for end users to not vote though?  Since they are reducing their dividends by increasing the approval rate of delegates.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

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....
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.