BitShares Forum
Main => Stakeholder Proposals => Topic started by: toast on December 06, 2014, 07:51:56 pm
-
I deleted the keys for delegate.adam before there was a "revoke" feature. It is a symptom of bad voter turnout that an old inactive delegate is in the top 101...
-
I deleted the keys for delegate.adam before there was a "revoke" feature. It is a symptom of bad voter turnout that an old inactive delegate is in the top 101...
I'd more likely say it's a symptom of a badly designed delegate approval system that allows an inactive delegate to be elected at all.
Why don't we automatically blacklist a delegate if either
a) their reliability falls too low
b) they miss too many consecutive blocks
-
I deleted the keys for delegate.adam before there was a "revoke" feature. It is a symptom of bad voter turnout that an old inactive delegate is in the top 101...
I'd more likely say it's a symptom of a badly designed delegate approval system that allows an inactive delegate to be elected at all.
Why don't we automatically blacklist a delegate if either
a) their reliability falls too low
b) they miss too many consecutive blocks
b) case should blacklist for certain periods of time. I still think a delegate "vacation" feature is needed where delegate withdraws for certain period of time from block signing.
-
Need almost like a punchcard telling people hey i'm still here... a ping feature somehow... so that if keys are lost or person goes away that the system automatically chooses someone else.. those that are interested in evolving bitshares will be available to pucnh in or pong back to tell the system yes Im good to go.
-
I deleted the keys for delegate.adam before there was a "revoke" feature. It is a symptom of bad voter turnout that an old inactive delegate is in the top 101...
I'd more likely say it's a symptom of a badly designed delegate approval system that allows an inactive delegate to be elected at all.
Why don't we automatically blacklist a delegate if either
a) their reliability falls too low
b) they miss too many consecutive blocks
b) case should blacklist for certain periods of time. I still think a delegate "vacation" feature is needed where delegate withdraws for certain period of time from block signing.
Yes, that would be good. Maybe blacklisted until the delegate pays a reactivation fee.
Sent from my SCH-S720C using Tapatalk 2
-
That is funny and a little sad.
Just to outline the history of how this happened as observed by an outsider simply exploring the blockchain...
The last block that delegate produced is on Oct 23, 2014. And yet the delegate has only missed a total of 5 days worth of blocks he was responsible for.
Looking at the voting history (http://www.bitsharesblocks.com/delegates/delegate?name=delegate.adam), most of the stake voting for that delegate was removed within the day after it produced its last block (likely stake controlled by bytemaster), which makes sense. I assume that took the delegate out of the top 101, which is why the missing blocks are not too large. Over the course of the next month, more stake stopped voting for the delegate as is naturally expected, but even at its lowest point it maintained at least 50 million BTS voting for it.
Then on November 25, 2014 (Block 1097773 (http://www.bitsharesblocks.com/blocks/block?id=1097773)) someone with 38 million BTS voted for the delegate for some reason. Why? Then over the course of the next week or two, a small amount of additional stake started voting for it (likely because they didn't know it was inactive and because it had recently gotten closer to the top 101 and therefore visible to less attentive voters who simply go down the delegate list giving thumbs up), until eventually, just today, someone with nearly 12 million BTS voted for the delegate (Block 1194382 (http://www.bitsharesblocks.com/blocks/block?id=1194382)) causing it to squeak into the 101th delegate spot.
So, although the 50 million BTS that never took away their vote from an inactive delegate partly explain why this inactive delegate is at rank 101 right now, it also wouldn't have been possible if new votes (just over the last two weeks) weren't cast in favor of the inactive delegate. Of course it was not made clear to people that this delegate is now inactive and they shouldn't vote for it, which was why that revoke feature is useful.
The real test of the voters now is how long it will take for people to take their votes away from the delegate when they realize it is not producing blocks (it will in particular be interesting to measure the response time of large stakeholders such as those two stakeholders, the 38 million BTS one and the 12 million BTS one, that voted for the delegate in the past two weeks). I kind of wish you didn't bring up this issue on the forum toast, because it would have been nice to see how many days passed before people noticed without having a prominent community member bring it to their attention. Then again it is only in the BTS delegates sub-forum, so it may still take an embarrassingly long time before the issue is corrected.
-
yee this is not a good test case... the guy has a cult like following, even though he has not said a constructive thing since May. So I expect them to vote for him for a year or so, even if he is not producing blocks.
-
That is funny and a little sad.
Just to outline the history of how this happened as observed by an outsider simply exploring the blockchain...
The last block that delegate produced is on Oct 23, 2014. And yet the delegate has only missed a total of 5 days worth of blocks he was responsible for.
Looking at the voting history (http://www.bitsharesblocks.com/delegates/delegate?name=delegate.adam), most of the stake voting for that delegate was removed within the day after it produced its last block (likely stake controlled by bytemaster), which makes sense. I assume that took the delegate out of the top 101, which is why the missing blocks are not too large. Over the course of the next month, more stake stopped voting for the delegate as is naturally expected, but even at its lowest point it maintained at least 50 million BTS voting for it.
Then on November 25, 2014 (Block 1097773 (http://www.bitsharesblocks.com/blocks/block?id=1097773)) someone with 38 million BTS voted for the delegate for some reason. Why? Then over the course of the next week or two more people started voting for it (likely because they didn't know it was inactive and because it had recently gotten closer to the top 101 and therefore visible to less attentive voters who simply go down the delegate list giving thumbs up), until eventually it got enough votes just today (in Block 1194382 (http://www.bitsharesblocks.com/blocks/block?id=1194382), someone with nearly 12 million BTS voted for the delegate) to recently squeak into the 101th delegate spot.
So, although the 50 million BTS that never took away their vote from an inactive delegate partly explain why this inactive delegate is at rank 101 right now, it also wouldn't have been possible if new voters (just over the last two weeks) didn't create new votes in favor of the inactive delegate. Of course it was not made clear to people that this delegate is now inactive and they shouldn't vote for it, which was why that revoke feature is useful.
The real test of the voters now is how long it will take for people to take their votes away from the delegate when they realize it is not producing blocks. I kind of wish you didn't bring up this issue on the forum toast, because it would have been nice to see how many days before people noticed without having a prominent community bring it to their attention. Then again it is only in the BTS delegates sub-forum, so it may still take an embarrassingly long time before the issue is correct.
I think this is likely to be normal. Most people will wait for some attentive bird dog to blow the whistle. Then they will watch people they respect discuss it before deciding if and how to change their vote. I'm not sure this is too much of a problem, Sounds like a system working exactly the way it is supposed to: the bigger the problem the bigger the uproar and the more people wake up to fix it. :)
-
yee this is not a good test case... the guy has a cult like following, even though he has not said a constructive thing since May. So I expect them to vote for him for a year or so, even if he is not producing blocks.
This is another thing I worry about. How many people go down the delegate list and vote for someone because they have a familiar name? But there isn't necessarily any connection between the BTS account name and the real-life identity. Are we expecting the people who voted to have done their due diligence to see is delegate.adam actually does represent Adam B Levine? If so, wouldn't they have realized that the delegate is inactive and not voted for them?
This is another way where the convenience of TITAN names can lead to unintended bad consequences (the other was mistyping the name because they thought it is easy enough to recall from memory so they didn't need to copy and paste it, and then fat fingering the name and losing their money, e.g. bter vs btercom).
-
delegate.adam was voted on purpose, because someone didn't like the previous 101st delegate bts.coin, so he voted for adam to push bts.coin out of 101.
Now we just need to vote for some other active delegate, for example delo.cass. Then this issue will be resolved.
-
delegate.adam was voted on purpose, because someone didn't like the previous 101st delegate bts.coin, so he voted for adam to push bts.coin out of 101.
Now we just need to vote for some other active delegate, for example delo.cass. Then this issue will be resolved.
This is interesting! The solution *should* be for everyone to run multiple delegates by default on each node so that people can vote in "fillers". "Backbone" delegates should look into this.
-
delegate.adam was voted on purpose, because someone didn't like the previous 101st delegate bts.coin, so he voted for adam to push bts.coin out of 101.
Now we just need to vote for some other active delegate, for example delo.cass. Then this issue will be resolved.
I agree. We still have several init delegated on the 101 list and also have active delegates without being voted enough.
-
delegate.adam was voted on purpose, because someone didn't like the previous 101st delegate bts.coin, so he voted for adam to push bts.coin out of 101.
Now we just need to vote for some other active delegate, for example delo.cass. Then this issue will be resolved.
This is interesting! The solution *should* be for everyone to run multiple delegates by default on each node so that people can vote in "fillers". "Backbone" delegates should look into this.
While I think this would be helpful, I also think we should try to test out more new delegates. This would get us closer to a more robust solution then having multiple delegates on one node.
-
delegate.adam was voted on purpose, because someone didn't like the previous 101st delegate bts.coin, so he voted for adam to push bts.coin out of 101.
Now we just need to vote for some other active delegate, for example delo.cass. Then this issue will be resolved.
That guy is also voting for delegate2.svk31 which is inactive as well but currently in 111th place, would be great if he would vote for dev.bitsharesblocks instead.