BSIP-0022 Draft - "Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network" (An elaboration/extension of Dan's BSIP-0005); Input would be massively appreciated!

in #bitshares7 years ago (edited)

BTS

Hey,

This is the fourth BSIP I've created recently, this BSIP is an elaboration/extension of @dan's BSIP-0005 and proposes the introduction of expiring votes for Witnesses, Committie members & Proxies within the Bitshares network.

This BSIP is a draft and open to community input on the entire contents of the BSIP.

I would massively appreciate any input, including concerns/criticisms.

Long live Bitshares! :D

Best regards,
@cm-steem


BSIP: 0022
Title: Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network
Authors: Customminer <Telegram: @cmmob>
Authors of relevant BSIP-0005: Daniel Larmier <Dan@cryptonomex.com>
                          Fabian Schuh <Fabian@BitShares.eu>
Status: Draft
Type: Protocol
Created: 2017-07-06
Primary discussions: <https://github.com/cryptonomex/graphene/issues/265>
                     <https://bitsharestalk.org/index.php/topic,18109.0.html>
                     <https://github.com/bitshares/bitshares-core/issues/73>
Similar discussions: <https://github.com/steemit/steem/issues/953>
Worker: TBD

Abstract

This BSIP proposes to introduce an expiration on votes cast within the Bitshares network so as to encourage an active voting population and campaigning by those who desire being voted into power.

Motivation

Currently within Bitshares DPOS system, an user's votes for committee/witness/proxy representatives are permanent unless changed by the voter at a later date.

Rationale

  • Permenant votes introduce the danger of enabling an oligarchy within the Bitshares network, we should be encouraging a more democratic network.
  • Campaigning efforts since the upgrade from BTSX (0.9x) to BTS 2.0 have drastically stagnated.
    • There were plans for a 'DPOSHub' to stimulate campaigning efforts, this has yet to materialize.
    • Elected witnesses rarely make an active effort to attend BeyondBitcoin hangouts nor hold their own scheduled hangouts, they are largely a silent group of individuals.
    • The 'Stakeholder proposal' subforum on Bitsharestalk is not as active as it should be; many elected witnesses haven't provided a discussion URL and many such threads on bitsharestalk haven't received a new post/update in months/years.
    • The list of active witnesses/committee members rarely changes.
  • There's a grim reality that humans (our primary userbase for now) eventually die, potentially with insufficient procedures in place for their relatives to recover their cryptoassets. Dead users cannot be convinced to change their cast votes, thus their votes are permanent regardless of their chosen representatives future activity/behaviour.
  • Non-expiring votes places new applicants at a disadvantage as they need to compete with the long established large vote weights that the currently active witnesses/committee users have.
  • To evict malicious users from their positions of power, concerned users have to engage in a smear campaign across multiple Bitshares communication portals.
    • Having to engage in this type of activity can be a negative experience for all users involved & could potentially damage the reputation of the campaigners (and the network if things get messy).
    • New users may be put off by such neccessary negative campaigning.
    • Inactive users who have voted for the malicious user may never take notice of such a campaign or may be apathetic to voting, negating the effectiveness of such a smear campaign (thus the malicious entity potentially remains in power).
  • Regarding consensus on this topic, the past BSIP-0005 by Dan Larimer & Fabian Schuh was not well received and was previously defferred due to a lack of sufficient detail in the BSIP.

Specifications

Committee controlled variables

  • Rate of vote weight decay.
    • Once the vote has aged past the 'max vote age' what length of time should pass before the vote is worth 0 BTS?
  • Max vote age (before votes begin to decay).
    • Separate age variables for: Comittee, Witness & Proxy votes (proxies should potentially age at a slower rate than comittee/witness, as these users have opted to delegate their voting power to an active user).
  • Accounts blacklisted from voting (exchanges/services/scam accounts).

Decay function

To keep things simple, we should start with a linear decay function. If this proves too aggressive/passive, the rate of decay could be modified or the formula could be changed at a later date to potentially be exponential.

Example linear vote weight decay function: (note: pseudocode!)

//Assuming this function only triggers once the vote has passed the set 'max vote age' set by the committee, hence we don't check for the vote tx not having aged past the 'max_days_decay' in this example.

let max_days_decay = 30; //Set by committee
let start_decay_date = vote_date()
let days_since_decay_began = todays_date() - ()

if (days_since_decay_began > max_days_decay) {
    decaying_vote_weight = 0; //Or nullify the vote
} else {
    decaying_vote_weight = original_vote_weight - ((original_vote_weight/max_days_decay)*days_since_decay_began)
}

Discussion

Should the committee have the power to blacklist users from voting?

Whilst exchanges/services voting with user funds (without permission) is bad, such functionality opens the doors for normal users to be included in the blacklist. One would hope that the network would vote such a committee out, but what's to stop the committee then blacklisting users that don't vote for them (or who vote for competitor committee users) so as to maintain power indefinetley? Currently highly unlikely, but still theoretically plausible.

Voter Apathy

  • An arguement that is repeatedly raised is that voters are apathetic towards voting within the Bitshares network, and that they may not repeatedley vote which could lead to a reduced cost to attack the network (by voting in malicious users).
  • Whilst the potential consequences of catastrophic voter apathy is a legitimate concern, I believe that by promoting a healthier democratic process we can offset the risk that voter apathy poses. We aught to be promoting the regular campaigning for these positions of power so as to encourage healthy competition which leads to innovation. Sitting back and not addressing/improving the voter apathy issue isn't a solution nor a reason to block the implementation of this proposal (IMO).
  • Counter arguments to voter apathy concerns:
    • Nobody should hold permanent votes placed by now dead users.
    • Likewise, you shouldn't permanently receive votes from users who have lost their keys.
    • Non-voters are not included in the democratic process for government elections & past votes in previous government elections do not carry over to new government elections to avoid parties remaining permenantly in power.
    • A gradual vote weight decay rather than an immediate removal would slow the loss of vote weight, providing a window of partial vote weight application for the witness/committee/proxy to utilise whilst they campaign for users to vote for them to stay in power. Likewise, the slow rate of vote weight reduction will reduce the odds of a low vote weight attack (malicious users voting malicious users into power).
  • Countering voter apathy
    • Make use of the BSIPs 19 and 20 (profit-sharing/dividends against MPA & UIA respectively) to only include users who have participated in the voting mechanism when distributing dividends to BTS holders (not applicable to MPA holders) or UIA holders (at the discretion of the UIA issuer performing the dividend payment).
    • Fund the development of 'DPOSHub' style websites to improve the ease of witness/committee campaigning (encouraging competition/innovation) as well as discovery (enabling users to find new users they believe worthy of power within the BTS network).

Concerns of a lack of central communications channel

  • Some users have voiced concerns that because there isn't one mutually utilized central communications channel within the Bitshares community, we shouldn't implement vote weight decay.
  • I can sympathise with this concern, our community is distributed around the world & some countries block communication channels that others have access to (Russia rumoured to potentially block Telegram, China's "great firewall", venezuela blocking whatsapp, etc), likewise there are several language barriers between sub-communities.
  • To account for this concern, we should not implement this change without sufficient discussion nor consensus & transcript translation (and distribution of such information) for our users worldwide.
  • If we were to fund the development of 'DPOSHub' style multi-lingual websites, this could help offset this concern as such as website should be politically neutral.

Out of scope

  • Worker proposal votes - they are generally fixed in length thus the vote weight expiry doesn't/shouldn't need to apply, unless the worker proposal vote length is less than the 'max vote age' variable set by the committee (which wouldn't make sense).

Large proxy voting power concerns

There have been concerns raised that by decaying the vote weight that has been delegated to proxies too quickly we may cause large swift changes to active witnesses/committees/worker-proposals.

To counter these concerns, we have accounted for:

  • A linear decay function, so as to not immediately remove vote weight delegated to proxies (preventing the swift change concern); This could be over the course of months or even years.
  • A proposed separate max_vote_age for proxies than witnesses/committee, as the user opted to delegate their voting power to their trusted active proxy. This value would be at the discretion of the committee, who answer to the voting userbase (including the proxies).

Other?

Please do raise your concerns, propose improvements and engage in the BSIP creation process, your opinion matters!

Summary for Shareholders

  • If this BSIP was implemented, voting would be a more frequently required activity as your previously placed votes will slowly expire after the max vote age is passed. If you fail to repeat your previous vote after the expiration period then you may find that the witnesses/committie members that you support could lose power. This in itself could have repercussions on shareholders if users with different policical alignments are voted into power.
  • Malicous users will be voted out of power more easily without requiring negative smear campaigning within Bitshares community portals, maintaining a postive image to the public.
  • Witness/Committie/Proxy campaigning will increase, potentially impoving community engagement to the benefit of the network.
  • No worker proposal has been created/proposed yet. Further discussion is required prior to considering such action.
  • If BSIPs 19 and 20 are implemented in the future, voting will potentially have an impact on your eligibility for receiving dividends (not set in stone, just an idea to incentivize voting participation).

Copyright

This document is placed in the public domain, 100% open source & should be considered MIT licensed.

See Also

Sort:  

As a voter, what is important to me is validating my identity, not necessarily all 20 votes I've placed in the past for various Witnesses, Committee Members, and Workers. As I read BSIP22, I was under the impressions that I'd have to re-vote for my specific proxies, or witnesses, etc, but this is a lot to ask of any user. I've casually mentioned this in the telegram channel, but I think adopting a voter registration system would be easier to implement and easier to execute.

Under this plan, my existing votes would remain in effect as long as I renewed my voters registration. This would serve the purpose of removing votes for accounts where the owner has died or lost their keys and no longer is able to cast a vote.

The implementation I'd envision wouldn't required a very advanced implementation. Each user account would need something like:

(user variable) voter_registration_expires: <datetime>
(global variable) voter_registration_graceperiod: <days>

As long as today < voter_registration_expires, the user's votes would remain in effect.

The global graceperiod value could be used to ensure that the registration could be renewed without a lapse. So, if your registration expires on 1/1/2018, you would be able to renew your registration anytime after 11/1/2017.

This would be a very simple implementation on the UI as well. The user could be presented with a badge and a single button that asks the user to renew their registration. Clicking the button renews it and all votes remain as cast.

The disadvantage to this approach is that doesn't require the user to re-consider their votes, they just click a button and all votes are renewed until the next cycle. While it's certainly easier from the perspective of user-experience it doesn't promote thoughtful engagement.

Consider that in Western democratic elections your pre-existing votes don't stand from election to election. As an individual you have to explicitly recast your ballot. This forces you to at least consider the other options available to you and if your last choice really remains appropriate going forward.

In the end, what needs to be achieved is the relinquishing of the stranglehold that a few select early adopters have on the evolution of the Bitshares system and while voter decay doesn't guarantee this, it does provide the two fold benefits of filtering inactive stake and forcing those remaining active users who delegate or vote with their stake, to take into consideration what they are voting for or whom they are delegating to.

I'm surprised such a mechanism hasn't been in place earlier. In the corporate world the vote is only valid till the next general meeting.

I agree that the bitshares witnesses and committee members are becoming fairly stagnant, and entrenched. This would be good for the network and encourage more competition for witnesses positions. Full Support. What do you think would be an ideal initial parameter for the time until decay begins? Would it be on the order of 6 months or 12 months? Also, I think this change should come with a large reduction in the fee cost of casting votes, to encourage more users to regularly update their votes.

The fees for account update aren't actually that bad though, currently less than half a cent (USD). This once or twice a year is insignificant.

Regarding the max_vote_age, 6 or 12 months sound good. It'd ultimately be up to a combination of the Bitshares network/community & for the committee to enable.

Thanks for hard work @cm-steem. I strongly support this BSIP but I guess that this would require a hard fork so we need to think it through so that there are as few hard forks as possible.

  1. I agree that we should start with linear decay function. I'm not sure about initial length of the interval. What would happen when this feature goes live? Would all votes start decaying at the same time? In this case I would go for 1 or 2 years. Or would it use the history of voting? In that case couple of months could be enough.
  2. I would omit blacklisting in the first version (or at minimum not use it) - it is a very dangerous feature.
  3. I would include worker proposals - some of them are really long (e.g. refund400k until 31 Dec 2035), alternatively we could limit the length of worker proposals to e.g.one or two years but that would be part of another BSIP
  4. I wouldn't enforce voting to be a requirement for BSIP 19 and 20, people will game the system which might be very dangerous in the end.
  5. I still don't understand when my vote would be "refreshed", i.e. would againd gain maximum strength. Let's say that I'm voting for 5 committee members and I add vote for 6th member. 5 votes will have limited strength and one new vote will be at full strength or all 6 votes would be at full strenght?
Loading...

Hey CM - when do you sleep?

I'm really impressed with the quality of your writing. Thank you for posting this. I'm reading it and trying to continue learning about Bitshares.

Heh, I don't get enough sleep for sure!

Thanks for the kind words, give me a shout if you have any questions about Bitshares :)

I appreciate this effort. I haven't seen any point in voting in the bitshares network since I have no idea what each witness stand for.

I have lately looked at the ark and lisk networks where the delegates really put effort into their campaign. They even pay to stay in power. Or the users organize their own node.

I believe some competitiveness among the witnesses both reenvigorates and rejuvenates.

I appreciate this effort. I haven't seen any point in voting in the bitshares network since I have no idea what each witness stand for.

Some do post monthly updates, attend events, create witness tools and participate in the community, but a few of the witnesses I have no idea what they stand for nor what benefits they bring over others.

I believe some competitiveness among the witnesses both reenvigorates and rejuvenates.

I agree, a lack of competition encourages stagnation.

Big thanks for @cm-steem this is good post, i don't know about witness before coz i'm a new here

This comment has received a 0.15 % upvote from @booster thanks to: @hamzaoui.

Any effort that is advantageous for the development of the platform and strenghten its competivness should be taken. Similar to evolution: only survival by constant and fast developmen/adaption.

Thank You for posting this so folks can see the workings of the group and potential moves made for the community as a whole...Resteemit!

Thanks for the update. Its quite amazing how you work hard and update us with this info, thanks

Thanks, wasn't much work just formulating my own view on how we could approach this topic.

Weloome and I appreciate your contributions here