0 Members and 1 Guest are viewing this topic.
Quote from: dankeykang on August 20, 2014, 06:39:27 pmHi 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.
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! = ^ ^ = ~ ' ' ~ ^
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.
Quote from: GaltReport on August 17, 2014, 12:27:39 pmQuote from: luckybit on August 16, 2014, 01:27:11 pmQuote from: liondani on August 16, 2014, 12:29:33 pmQuote from: bytemaster on August 16, 2014, 06:15:46 amtheir pay should go up the more votes they get. 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) / 100reliability = reliability for the last x blocks (because "current" reliability should be more importand than total...)
Quote from: luckybit on August 16, 2014, 01:27:11 pmQuote from: liondani on August 16, 2014, 12:29:33 pmQuote from: bytemaster on August 16, 2014, 06:15:46 amtheir pay should go up the more votes they get. 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.
Quote from: liondani on August 16, 2014, 12:29:33 pmQuote from: bytemaster on August 16, 2014, 06:15:46 amtheir pay should go up the more votes they get. 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.
Quote from: bytemaster on August 16, 2014, 06:15:46 amtheir pay should go up the more votes they get. 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? ...
their pay should go up the more votes they get.
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....
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 addressthen 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.
Quote from: alt on August 17, 2014, 11:55:20 pmI 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 addressthen 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!
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.
Quote from: liondani on August 16, 2014, 12:29:33 pmQuote from: bytemaster on August 16, 2014, 06:15:46 am... 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.
Quote from: bytemaster on August 16, 2014, 06:15:46 am... 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? ...
Quote from: maqifrnswa on August 16, 2014, 01:55:03 pmI 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 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.
Quote from: emski on August 16, 2014, 08:33:43 pmBased 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?
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.
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.
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.
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?
Quote from: bytemaster on August 16, 2014, 02:09:13 pmQuote from: maqifrnswa on August 16, 2014, 01:55:03 pmI 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 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.
Quote from: fuznuts on August 16, 2014, 02:21:45 pmThere 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.
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?
Quote from: bytemaster on August 16, 2014, 02:09:13 pmActually 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 shocksI also would like to see some way to allow delegates to get paid tracking another bit asset via dynamic payrates.
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.
Quote from: liondani on August 16, 2014, 12:29:33 pmQuote from: bytemaster on August 16, 2014, 06:15:46 amtheir pay should go up the more votes they get. 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.
Quote from: bytemaster on August 16, 2014, 06:15:46 amtheir pay should go up the more votes they get. 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 ...
Quote from: puppies on August 16, 2014, 07:27:41 amAt 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!
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.
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).