6c647d394a
BSIP 19 updated. BSIPs 20, 21 & 22 initial commit.
129 lines
No EOL
11 KiB
Markdown
129 lines
No EOL
11 KiB
Markdown
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](https://en.wikipedia.org/wiki/Oligarchy) within the Bitshares network, we should be encouraging a more [democratic](https://en.wikipedia.org/wiki/Democracy) network.
|
|
* Campaigning efforts since the upgrade from BTSX (0.9x) to BTS 2.0 have drastically stagnated.
|
|
* There were plans for a '[DPOSHub](https://bitshares.org/newsletter/2015/nullstreet/the_nullstreet_journal_0-5.pdf)' 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](https://cryptofresh.com/witnesses) 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.
|
|
* The informal proposal for [expiring votes within the Steem network](https://github.com/steemit/steem/issues/953) has been well received however it has not yet been implemented.
|
|
|
|
# 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
|
|
|
|
* https://bitsharestalk.org/index.php/topic,20753.0.html
|
|
* [BSIP 20 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-020-draft-introducing-profit-sharing-dividends-to-bitshares-uia-only-input-would-be-massively-appreciated)
|
|
* [BSIP 19 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-019-updated-draft-introducing-profit-sharing-dividends-to-bitshares-mpa-only)
|
|
* [BSIP 22 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-0022-draft-introducing-expiring-votes-for-witnesses-committie-members-and-proxies-within-the-bitshares-network-an) |