Author Topic: BSIP Proposal #5 to address voter apathy for witnesses  (Read 5386 times)

0 Members and 1 Guest are viewing this topic.

Offline moinyoin


Offline R

  • Hero Member
  • *****
  • Posts: 1004
    • View Profile
*BUMP*

I have begun refining the contents of BSIP-0005 since it hasn't been updated and discussion has stagnated; I will post a link to a draft BSIP here and on Steemit when it's ready.

EDIT:

I have elaborated upon bytemaster's BSIP:
https://steemit.com/bitshares/@cm-steem/bsip-0022-draft-introducing-expiring-votes-for-witnesses-committie-members-and-proxies-within-the-bitshares-network-an
https://github.com/grctest/bsips/blob/master/bsip-0022.md
« Last Edit: July 06, 2017, 09:42:29 pm by Customminer »

Offline R

  • Hero Member
  • *****
  • Posts: 1004
    • View Profile
*BUMP*

I think this BSIP is needed more now than ever before, we've barely got competition against the currently elected witnesses & the 'campaigning' for these positions is almost non-existent. We're seeing witnesses in power who have zero price feeds and several who are entirely anonymous. I think that having to refresh your votes once every 6 months would be healthy for Bitshares. The solution to voter apathy isn't to ignore the problem and rely on proxies, but rather to encourage participation in the voting mechanism.
« Last Edit: May 07, 2017, 01:49:00 pm by Customminer »

Offline roadscape

Quote
1) The issues (voter apathy, lack of fresh witnesses, stability, incumbent witness accountability)
2) Considerations (reputation, technical abilities, ecosystem knowledge, conflicts of interest)
3) Candidate process (mentoring / training, accomplishments, voting campaigns, motivation)
4) Policies (metrics for monitoring witness performance, decentralization,
   anonymity, feeds, communications, grounds for termination, process for
   termination, minimum vote threshold, minimum technical standards)
5) Standards and best practices (some of these overlap with items above)
Very good start!
It is unfortunate that we still don't see dposhub which could have helped here
immensely. Maybe @roadscape could add a witness specific discussion feature and
show some metrics for each witness.

These are great ideas.. IMO BSIP-5 is unnecessary.. it's the proxies' job to keep witnesses, committee members, & workers accountable. But we should help proxies by showing more data so they can make educated votes. And a public set of guidelines would allow us to set expectations for performance. I'd be happy to add any such features to the block explorer.
http://cryptofresh.com  |  witness: roadscape

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I understood your BSIP OP, and was aware of it being open to all for contributions. I would like to see the guidelines tightened up so what appears in github is more coherent and cohesive. By the time an idea has matured well enough to conform to the guidelines only the finer parts of the proposal should need refinement, and if the process is similar to others I've worked on the final stage discussion tends to be about getting the language right so as to unambiguously convey the what why and how aspects of the BSIP.
+5%

Quote
Have you given any more thought to the minimum requirements a BSIP must contain?
Some.. yes. I think BSIPs should have a TL;DR; non-technical paragraph for shareholders (besides the discussion). Could we call it "Summary for Shareholders"?

I would love to see more detailed specs on witness performance in the wallet.  A pop-up reminder on the importance of voting for those that have not voted yet would also be a good idea.
Definitely. Not necessarily needs to be an invasive popup, but maybe just a "warning" in the status bar as we had it in bts1 already. BitShares just lacks the development resources to tackle all those nasty little feature requests :( Hope this changes significantly next year

Quote
I don't think I would support anything else to incentiveize voting at this point.  I think our current level of voting stake is pretty good compared to bts1.  And in bts1 most stake at the exchanges was voting too.
Agreed. I also don't like BSIP5. But shareholders should be given a way to read into it and have their own opinion on it.

About 1:
At first I did not really like bsip#5's idea of expiring votes, but now I think
we probably should focus on the potential issues that the current system could
create and have a way to handle cases of lost keys and/or apathetic votes
hanging around.

Bsip#5's purpose is not to create instability or drastical and istantanueous
changes in voting, it is just a countermeasure that would "kick in" ONLY if
needed.

If the current voting system and its partecipants prove to be succesfull enough
to guarantee a well working environment, bsip#5 would never really kick in!  If
proxies and not-proxying shareholders continue to remain actives, you could
easily forget about bsip#5 at all! It will be there to check the "health" of the
system, but doing nothing.
I see it the same. We are still in the bootstrapping stage. But neglecting the
fact that a 15% stake holder could redefine all witnesses and committee members
is a serious concern (though I don't think a single individual has that much
stake - but a group of them could)

Quote
Bsip#5 would kick in ONLY when an "issue" arises... only to improve the security
and the health of the system in that situation.  We should take "votes hanging
around" and "cases of lost keys" (think about a big proxy have such a problem)
seriously. And we should have a system that prevents those events to harm the
system itself.
Lost keys are not an issue since they can't be used for a 51% attack. It however
results in a perceived low participation and thus people may think bitshares can
be attacked with less stake.

Quote
I don't think the real question about bsip#5 is "yes or no?", but probably it
should be "how?" How such a system should works?
Bsip5 is ONE proposal that could tackle the issue. We could also improve on it
and construct a completely separate bsip with another approach.

Quote
To me, it should NOT be something that could make drastical and istantanueous
changes, instead it probably should kick in only after "x" amount of
inactivity-time and then acts in a very slow way over a long enought period of
time.
Agreed. Bytemaster elaborated an idea that is much better IMHO: He would like to
have a window-based smoothened voting such that an instant change in votes can
be seen on the blockchain but only gradually takes affect. This makes
"taking-over" the network more difficult because people can sell their stake
before an attack can be performed. However, it also slows down the reaction
times on misbehaving witnesses or committee members. It also leaves the question
of how long should that window be? 1 week, 2 weeks? 6 months? It will also not
identify slow attacks that gradually replace witnesses (not sure if that could
be used for a successful attack though)

Quote
IF properly configured, Bsip#5 would NOT cause active/voted witnesses to be
fired, neither inactive/non-high-voted witnesses to step-in in place of the
active ones.  It only would make votes more reliable and truthful.
Not sure. For me it only shows that the support for the active votes is *STILL*
there (refreshed periodically)

Quote
About 4:
I would really like to have more metrics for monitoring witness performance, but
I also think it is pretty hard to find good an reliable metrics to evaluate
witnesses work, above all in this early stage.  For example, the only metric
available now is "missed blocks", and I think that as right now it is not a good
metric to evaluate witnesses, not at all!
I agree with this!
Another metric would be how frequently they publish a price feed. The latter is
something I consider worth firing a witness for.

Quote
Lots of witnesses have lots of more missed blocks than me, still I do NOT think
they are less reliable or "worthy" than me.  They probably were just more
unlucky, and had to manage more unexpected crashes, freezes, forks and so on due
to bugs in the node and NOT due to their "lack of skills" or something that
should make them to be fired anyway.
Reminds me of my times as witness in bts1. I TOTALLY agree with you assessment
:)

Quote
About parts of 2) and 3):
I think that have good, worthy, and reliable "ready-to-be-active witnesses" is
as much important as have good witnesses.

One simple and probably reliable way to achieve that, is to "push" want-to-be
witnesses to run a witness_node in the Demo/Dev chain.  (Maybe also by
remunerate them just that little enough to be able to run a low end vps to
sustain the demo/dev chain power required)

Only after they prove to be capable and reliable in running as witness in de
Demo chain, they should be taken into account by shareholders to be voted in the
Main chain.
That is something every shareholder could decide individually. For now, most
active witnesses have also been active in BTS1 so I assume they know already how
that business works.

Thanks for your input @Bhuz

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
These are very complex subjects that probably were never fully thought through seriously enough

About 1:
At first I did not really like bsip#5's idea of expiring votes, but now I think we probably should focus on the potential issues that the current system could create and have a way to handle cases of lost keys and/or apathetic votes hanging around.

Bsip#5's purpose is not to create instability or drastical and istantanueous changes in voting, it is just a countermeasure that would "kick in" ONLY if needed.

If the current voting system and its partecipants prove to be succesfull enough to guarantee a well working environment, bsip#5 would never really kick in!
If proxies and not-proxying shareholders continue to remain actives, you could easily forget about bsip#5 at all! It will be there to check the "health" of the system, but doing nothing.

Bsip#5 would kick in ONLY when an "issue" arises... only to improve the security and the health of the system in that situation.
We should take "votes hanging around" and "cases of lost keys" (think about a big proxy have such a problem) seriously. And we should have a system that prevents those events to harm the system itself.

I don't think the real question about bsip#5 is "yes or no?", but probably it should be "how?"
How such a system should works?

To me, it should NOT be something that could make drastical and istantanueous changes, instead it probably should kick in only after "x" amount of inactivity-time and then acts in a very slow way over a long enought period of time.

IF properly configured, Bsip#5 would NOT cause active/voted witnesses to be fired, neither inactive/non-high-voted witnesses to step-in in place of the active ones.
It only would make votes more reliable and truthful.


About 4:
I would really like to have more metrics for monitoring witness performance, but I also think it is pretty hard to find good an reliable metrics to evaluate witnesses work, above all in this early stage.
For example, the only metric available now is "missed blocks", and I think that as right now it is not a good metric to evaluate witnesses, not at all!

Lots of witnesses have lots of more missed blocks than me, still I do NOT think they are less reliable or "worthy" than me.
They probably were just more unlucky, and had to manage more unexpected crashes, freezes, forks and so on due to bugs in the node and NOT due to their "lack of skills" or something that should make them to be fired anyway.

In a system that relies on current missed blocks for the future evaluation (if we can not erase the current missed blocks count), could be even more harmful:
The current witnesses that participated to the testnet, that bootstrapped the system, that managed a way less reliable witness_node, that spent lot of times in reporting strange behaviours, crashes, freezes etc, the ones that really helped the system to improve and achieve a better and more reliable status...In such a system All these pleople/witnesses would also be the ones with probably (on average) higher missed blocks and so the one that would be more unfairly penalized by that metrics.

All this just to say that we should be very carefull on deciding what is a fair and good metric to really evaluate witnesses work and their "worthiness", ABOVE ALL in an early stage as the present one.


About parts of 2) and 3):
I think that have good, worthy, and reliable "ready-to-be-active witnesses" is as much important as have good witnesses.

One simple and probably reliable way to achieve that, is to "push" want-to-be witnesses to run a witness_node in the Demo/Dev chain.
(Maybe also by remunerate them just that little enough to be able to run a low end vps to sustain the demo/dev chain power required)

Only after they prove to be capable and reliable in running as witness in de Demo chain, they should be taken into account by shareholders to be voted in the Main chain.

« Last Edit: December 24, 2015, 02:15:46 pm by Bhuz »

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
I would love to see more detailed specs on witness performance in the wallet.  A pop-up reminder on the importance of voting for those that have not voted yet would also be a good idea.

I don't think I would support anything else to incentiveize voting at this point.  I think our current level of voting stake is pretty good compared to bts1.  And in bts1 most stake at the exchanges was voting too.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Thom

It took me a couple of hours to for the posts on github and in this thread. They were TL;DR, but you managed to digest them and offer detailed comments here. You are one productive machine xeroc!

I understood your BSIP OP, and was aware of it being open to all for contributions. I would like to see the guidelines tightened up so what appears in github is more coherent and cohesive. By the time an idea has matured well enough to conform to the guidelines only the finer parts of the proposal should need refinement, and if the process is similar to others I've worked on the final stage discussion tends to be about getting the language right so as to unambiguously convey the what why and how aspects of the BSIP.

Have you given any more thought to the minimum requirements a BSIP must contain?
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Hi Thom,

first of all, thanks for taking the time for reading and commenting the bsip.
As you may have guessed, it's the first attempt to get some strucutre into
different prosposals and as such all of these proposals are *drafts* only,
nothing finaly, nothing fixd, nothing decided.

In it I said that particular BSIP does not include a minimum level of content
for a BSIP, and further suggested less formal discussion should take place
elsewhere to distill the issues involved and see if a more formal BSIP to
address the perceived problem is warranted.
Sounds like a very good idea.
Bitcoin devs use a mailing list for BSIP discussion, we could alternatively use
the forum. How about a distinct subforum for BISPs discussions?
@fav: Could you do that or recommend an other subforum where we can have
discussions on existing and new bisps?

Quote
BSIP #5 attempts to address the issue of voter apathy by allowing the votes for
witnesses to expire. IMO this is not a very well thought out approach. Moreover,
if the approach is sound why not apply it to other votes, such as for committee
members? The BSIP approach could cause instability in the witness ranks, or
allow unqualified witnesses to gain the position. The role of witnesses in our
DPoS ecosystem is extremely important. Reputation is a key factor, as well as
technical abilities. However this BSIP does not address those issues. In fact,
it weakens stability and the role of witness reputation.
I fully agree with you, and tbh, I never liked the idea of bsip-5 very much. In
the end, voting apathy is reduced by having proxies.

Quote
We saw what can happen in BitShares 1 with witnesses that didn't take their role
seriously, were lax in maintenance yet had huge votes and were difficult to get
rid of, or witnesses that abandon their posts and thus reduce shareholder
accountability. It has been suggested on several occasions that we codify some
automatic performance metrics for monitoring witnesses so that if they fail to
meet certain standards they loose their position. Missing blocks is not a
sufficient disincentive IMO to keep witnesses operating properly, but it may
serve well as one of several metrics (version / info publishing, frequency of
reports or info updates, feeds, their number, accuracy and frequency just to
name a few) in an automated system of accountability / performance evaluation.
The least we could do RIGHT NOW is to have a metric derived in the wallet and
show it to the user/proxy. Either something simple like: "This witness has
missed more than 5% or his blocks" or something more sophisticated like a
green/orange/red bar indicator from a metric between 0 and 1.

Having a 'fire' feature for bad performing witnesses may open up more security
issues than it helps.

Quote
I consider this post to be a starting point for discussions about how to
strengthen the role of the witnesses, including BSIP #5. I believe we as a
community should think carefully about BSIP #5 as well as the following and
focus our discussion along these lines:
Absolutely! Actually I am in favor of rejecting bsip5 once and for all and
instead start with an informational bsip to educate shareholders and proxies.
Think of a document for best-practise and recommendations on what metrics to
consider when finding someone to vote for.

Quote
1) The issues (voter apathy, lack of fresh witnesses, stability, incumbent witness accountability)
2) Considerations (reputation, technical abilities, ecosystem knowledge, conflicts of interest)
3) Candidate process (mentoring / training, accomplishments, voting campaigns, motivation)
4) Policies (metrics for monitoring witness performance, decentralization,
   anonymity, feeds, communications, grounds for termination, process for
   termination, minimum vote threshold, minimum technical standards)
5) Standards and best practices (some of these overlap with items above)
Very good start!
It is unfortunate that we still don't see dposhub which could have helped here
immensely. Maybe @roadscape could add a witness specific discussion feature and
show some metrics for each witness.

Quote
IMO this community has been playing fast & loose regarding a very important
aspect of our DPoS ecosystem. Whenever the voter apathy topic arises it doesn't
seem to resolve much. I think we're at a place of maturity now that demands we
put more thought into this, and not just apply a patch to experiment on how it
may affect the ecosystem. I highly applaud xeroc and his efforts to establish
quality documentation and formal procedures such as BSIPs which are sorely
needed in BitShares. A more regimented, structured approach such as what jakub
and Bill Butler bring to the table will help us all to stay focused and on
point.
Have I actually told you guys that EVERYBODY could come up with a bsip? Just put
together some lines and try to follow the recommendations (for the sake of
consistency) and we can put it online!
In fact I really don't WANT to be the author of all bsips! Help is very much
appreciated!

Quote
As I said in my comments on github, my concern is not so much about resolving or
affecting voter apathy as much as it is on strengthening the witness role. I
believe we can do that more effectively through policies, procedures and
standards to improve awareness, accountability and core strengths of our
witnesses.

I hope this thread will demonstrate the strength of our witness community by the
number of witnesses that comment here. Let's see if we can get all 25 to show up
and offer their input, no matter what it is.
I'll let the witnesses I have a contact to know about this thread!

Offline Thom

I just posted an update on github (https://github.com/bitshares/bsips/#2) concerning BSIP #5.

In it I said that particular BSIP does not include a minimum level of content for a BSIP, and further suggested less formal discussion should take place elsewhere to distill the issues involved and see if a more formal BSIP to address the perceived problem is warranted.

There is much I could say here, but I will try to keep this brief. Most of my thoughts can be found in the BSIP issues on github. For some recent background see this forum poll. For older discussions about governance and voter apathy use the forum advanced search, use the keywords VOTER APATHY and change the "Search order" drop down to "Oldest topics first".

BSIP #5 attempts to address the issue of voter apathy by allowing the votes for witnesses to expire. IMO this is not a very well thought out approach. Moreover, if the approach is sound why not apply it to other votes, such as for committee members? The BSIP approach could cause instability in the witness ranks, or allow unqualified witnesses to gain the position. The role of witnesses in our DPoS ecosystem is extremely important. Reputation is a key factor, as well as technical abilities. However this BSIP does not address those issues. In fact, it weakens stability and the role of witness reputation.

We saw what can happen in BitShares 1 with witnesses that didn't take their role seriously, were lax in maintenance yet had huge votes and were difficult to get rid of, or witnesses that abandon their posts and thus reduce shareholder accountability. It has been suggested on several occasions that we codify some automatic performance metrics for monitoring witnesses so that if they fail to meet certain standards they loose their position. Missing blocks is not a sufficient disincentive IMO to keep witnesses operating properly, but it may serve well as one of several metrics (version / info publishing, frequency of reports or info updates, feeds, their number, accuracy and frequency just to name a few) in an automated system of accountability / performance evaluation.

I consider this post to be a starting point for discussions about how to strengthen the role of the witnesses, including BSIP #5. I believe we as a community should think carefully about BSIP #5 as well as the following and focus our discussion along these lines:

1) The issues (voter apathy, lack of fresh witnesses, stability, incumbent witness accountability)
2) Considerations (reputation, technical abilities, ecosystem knowledge, conflicts of interest)
3) Candidate process (mentoring / training, accomplishments, voting campaigns, motivation)
4) Policies (metrics for monitoring witness performance, decentralization, anonymity, feeds, communications, grounds for termination, process for termination, minimum vote threshold, minimum technical standards)
5) Standards and best practices (some of these overlap with items above)

IMO this community has been playing fast & loose regarding a very important aspect of our DPoS ecosystem. Whenever the voter apathy topic arises it doesn't seem to resolve much. I think we're at a place of maturity now that demands we put more thought into this, and not just apply a patch to experiment on how it may affect the ecosystem. I highly applaud xeroc and his efforts to establish quality documentation and formal procedures such as BSIPs which are sorely needed in BitShares. A more regimented, structured approach such as what jakub and Bill Butler bring to the table will help us all to stay focused and on point.

As I said in my comments on github, my concern is not so much about resolving or affecting voter apathy as much as it is on strengthening the witness role. I believe we can do that more effectively through policies, procedures and standards to improve awareness, accountability and core strengths of our witnesses.

I hope this thread will demonstrate the strength of our witness community by the number of witnesses that comment here. Let's see if we can get all 25 to show up and offer their input, no matter what it is.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html