Introduce functionality to lock Bitshares (BTS) away as 'Bitshares Influence' which will be required to vote upon Witness/Committee members and Worker-Proposals.
# Motivation
* Services and or exchanges currently have the ability to vote upon witnesses/committee members and for worker proposals, potentially to the detriment of the network and with disregard to their userbase.
* Blacklisting/Whitelisting of accounts from the voting mechanism (to prevent abusing customer's funds) is not a desirable outcome for a decentralized network & wouldn't be effective.
# Rational
* If you were required to lock away your BTS in an 'Bitshares Influence' balance which you couldn't immediately withdraw said BTS from (say withdraw over several weeks), then exchanges/services would potentially be less likely to vote with their userbase's funds as their userbase would know (publicly auditable) that they have insufficient funds to satisfy customer withdrawls (serving withdrawls with other user's deposits instead of transfering cold storage funds to hot wallets).
* Reduced liquid Bitshares on centralized exchanges.
* Valuable target for UIA sharedrop & dividend payments.
* "There is significant value to having long-term commitment because it enables communities to make long-term plans. Long term commitment of stakeholders also causes them to vote for long-term growth rather than short-term pumps." - [Steem whitepaper](https://steem.io/SteemWhitePaper.pdf#h.3si6qbxpv4do)
# Specifications
* Create new balance type 'Bitshares Influence' (Or Bitshares Power, whatever sounds best - BTSI vs BTSP).
* Modify voting system to use Bitshares Influence balance instead of Bitshares, potentially with a slow switch over period to prevent sudden change in voting outcome due to votes being reset-to-zero.
* Provide the committee the ability to modify the rate at which Influence can be converted back to Bitshares (weeks, months, etc).
* Potentially still involve Bitshares (non locked away influence) tokens in the voting mechanism, but with a reduced voting weight (say 10% for an initial guesstimate).
* Potentially allow for the use of Bitshares influence as backing collateral for MPA, so as to not deplete the MPA markets of liquidity. When they settle their debt, the BTS goes back into the influence balance whilst the profit is liquid.
# Discussion
## How should influence vote weight be distributed?
'A' would likely provide more than 1 BTS of vote weight per 1 BTSI, as not all coins would be locked away as influence.
'B' is simply your current bitshares influence, nothing else taken into account.
Would there even be a difference in voting behaviour betwen the two? Perhaps it might make the influence holders feel like their BTS are more valuable than non-influential BTS?
## Potential issues
* Exchanges/Services with large & old non-liquid cold storage accounts may be perfectly fine with locking away funds in a 'Bitshares Influence' balance, as it would potentially add further security to cold wallet funds (An attacker couldn't immediately transfer funds) & because their userbase may not be paying attention to nor regularly auditing the exchange/service's hot/cold bitshares accounts.
* If this reduces voting participation & exchanges lock away funds in this manner, then the exchange/service may end up with more voting weight than they originally did.
* A lack of liquid Bitshares could cause:
* Wild swings in centralized exchange BTS price - potentially bad for MPA reference prices, perhaps triggering global settlement events (BSIP-0018 should offset this concern).
* A lack of MPA liquidity, if users aren't using their BTS as backing collateral to short MPA into existence.
* In switch over from BTS to BTSI for voting power, if we do not snapshot past votes or slowly taper from one voting system to the other, we could encounter a period of unstable voting. If everything was reset to zero, then malicious actors could attempt to be voted into power.
# Summary for Shareholders
* Significant proposed changes to voting power - you will need to lock away funds in order to vote after the implementation of this BSIP. Unlocking funds could take weeks.
* Will require a hard fork for implementation which could potentially cause temporary network disruption.
* No worker proposal yet, requires developer input.
# Copyright
This document is placed in the public domain, 100% open source & should be considered MIT licensed.
