agorise
/
bsips
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Clean commit 

BSIP 19 updated.
BSIPs 20, 21 & 22 initial commit.
oxarbitrage-patch-1
grcgrc 2017-07-24 01:41:06 +01:00
parent a9f7976b19
commit 6c647d394a
5 changed files with 474 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
README.md
View File

@ -30,4 +30,7 @@ Number | Title |
[16](bsip-0016.md) | Optimization to Force Settlement Parameters of BitCNY | Jerry Liu | Protocol | Installed
[17](bsip-0017.md) | Revive BitAsset after Global Settlement | Peter Conrad | Protocol | Draft
[18](bsip-0018.md) | Revive BitAsset through buying Settlement Pool | Fabian Schuh | Protocol | Draft
[19](bsip-0019.md) | Introducing profit sharing/dividends to Bitshares | Customminer | Protocol | Draft
[19](bsip-0019.md) | Introducing profit sharing/dividends to Bitshares (MPA only) | Customminer | Protocol | Draft
[20](bsip-0020.md) | Introducing profit sharing/dividends to Bitshares (UIA only) | Customminer | Protocol | Draft
[21](bsip-0021.md) | Introducing the 'Coin-Age' statistic to Bitshares assets | Customminer | Protocol | Draft
[22](bsip-0022.md) | Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network | Customminer | Protocol | Draft

114
bsip-0019.md
View File

@ -1,81 +1,129 @@
BSIP: #019
Title: Introducing profit sharing/dividends to Bitshares
Title: Introducing profit-sharing/dividends to Bitshares (MPA only)
Authors: Customminer
Status: Draft
Type: Protocol
Created: 2017-06-18
Primary Discussion: https://bitsharestalk.org/index.php/topic,23981.0.html, https://bitsharestalk.org/index.php/topic,23981.msg304489.html#msg304489
Primary Discussion: https://bitsharestalk.org/index.php/topic,23981.0.html
Similar Discussions: https://bitsharestalk.org/index.php/topic,23706.0.html , https://bitsharestalk.org/index.php/topic,21476.msg279498.html#msg279498 , https://bitsharestalk.org/index.php/topic,23707.0.html
Replaces: N/A
Superseded-By: N/A
Worker: None yet - propose bounty?
Worker: No worker proposal yet - propose bounty?
---
# Abstract
The introduction of 'profit sharing / dividends' for [BTS|MPA|UIA] on the Bitshares DEX, either via redistribution of fees [BTS|MPA|UIA] or issuance (sharedrop) of additional tokens (UIA only) against asset holders (not simply collateral).
The introduction of 'profit sharing / dividends' for [BTS|MPA] on the Bitshares DEX via the redistribution of fees.
---
# Motivation
One of the major selling points of BTSX back in 2014 was the 5% (really variable x%) on 'anything' marketing. I'm not proposing
One of the major selling points of BTSX (for myself) back in 2014 was the 5% (really variable x%) on 'anything' marketing.
The idea that anyone could securely hold MPAs long term in their wallet and receive better 'interest' rates than that FIAT banks were offering was (and remains) a powerful message that had me (and a lot of other users) sold on Bitshares.
The idea that anyone could securely hold MPAs long term in their wallet and receive better 'interest' rates than that FIAT banks were offering was (and remains) a powerful message which had myself (and a lot of other users) sold on Bitshares.
During the migration from BTSX (BTS 0.9x) to BTS 2.0 we removed 'socialized yield' due to '[yield harvesting](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)', however I believe that its removal without an established replacement income stream for asset holders was a mistake (one that we can ammend).
During the migration from BTSX (BTS 0.9x) to BTS 2.0 we removed 'socialized yield' due to '[yield harvesting](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)'. I believe that its removal without an established replacement income stream for asset holders was a mistake (one that we can amend).
The motivation of UIA dividends through sharedropping (additionally issued tokens) is to replicate the distribution mechanism of POS cryptocurrencies, plausibly enabling pos cryptos to migrate entirely to the BTS DEX.
The last monthly gathered fee estimate was approximately 1 million BTS per month which is approximately $330,000 (not an insignificant sum), of which 80% was distributed to the referral system (20% goes to the reserve pool).
The Bitshares DEX [recently turned a profit](https://steemit.com/bitshares/@steempower/bitshares-state-of-the-network-13th-june-2017)!
We can reallocate fee redistribution without increasing fees by reducing referral fee allocation.
Peerplays has [already implemented profit sharing in graphene](https://github.com/BunkerChainLabsInc/peerplays-profitshare).
---
# Rational
* The potential for earning more interest on smartcoins than centralized banks offer for FIAT deposits (with near zero risk) could drive many new users to pick the BTS DEX over centralized banks for storing their savings.
* An increased demand for smartcoins leads to an increased supply and thus a reduction in the quantity of liquid BTS (since 200-300% BTS are locked up as collateral for each smartcoin).
* Providing dividend functionality to UIA issuers introduces potential for new UIA to be created with this functionality in mind.
* The potential for profiting more by holding your assets on the BTS DEX than within a traditional FIAT bank (without taking on risk) could drive many new users to pick the BTS DEX over centralized banks for storing their savings in the future.
* An increased demand for MPA leads to an increased MPA supply and thus a reduction in the quantity of liquid BTS (since 200-300% BTS are locked up as collateral for each MPA token).
* An increase in MPA supply potentially encourages greater MPA liquidity on the BTS DEX.
* Other cryptocurrency platforms offer profit-sharing/dividends, such as [Peerplays](https://github.com/BunkerChainLabsInc/peerplays-profitshare)/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash.
* New types of UIA could be made possible, driving fees to the reserve pool when registered.
* By incentivizing Bitshares users to hold their BTS on the DEX instead of on centralized exchanges we minimize the risk of said centralized exchanges having a massive voting weight with which they could disrupt BTS operations by voting maliciously.
* We can reallocate fee redistribution without increasing fees by reducing referral fee allocation.
---
# Specifications
## Creation of fee redistribution variables for committee/asset-issuer to set
## Implementation of Peerplays profit sharing mechanism
The Peerplays developement team developed [profit-sharing code for the Graphene toolkit](https://github.com/BunkerChainLabsInc/peerplays-profitshare) approximately one year ago, they have repeatedley given permission for the BTS DEX to utilise their developed profit-sharing code ([case 1](https://bitsharestalk.org/index.php/topic,23981.75.html), [case 2](https://steemit.com/bitshares/@cm-steem/bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares#@peerplays/re-cm-steem-bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares-20170620t032010758z)). A large portion of the work required for this BSIP may already be complete.
The consensus regarding fee redistribution was that the values should be decided by the committee (or the asset issuer for UIA).
## Fee redistribution variables
The fee redistribution values should be discussed thoroughly and either decided by the committee (smartcoins) or the MPA issuer (non-smartcoin assets such as Algorithm based Assets).
Committee fee redistribution values required: reserve-pool, referral, bitAsset holders, BTS holders, LTM members, Non-LTM members.
### Potential fee redistribution variables:
## Implementation of peerplays profit sharing mechanism
* #### Higher level fee redistribution groups
* Reserve pool : %
* [Referral system](http://docs.bitshares.eu//bitshares/user/referral-program.html) : %
* bitAsset (MPA) holders : %
* BTS holders : %
The user 'Bunkerchain labs' posted "[Implement our profit sharing code thanks to Peerplays development](https://bitsharestalk.org/index.php/topic,23981.75.html)", a large portion of the work for this BSIP may be complete.
* #### Account types
* [LTM members](http://docs.bitshares.eu//bitshares/user/account-memberships.html#lifetime-members) : %
* Non-LTM members : %
* #### Dividend settings
* Dividend schedule (sharedrop timeframe) : Days/Blocks
* Max Coin-Age : Days/Blocks
* Bonus rate for age past max coin-age : %
* MPA dividends permissions : Enable/Disable
* MPA dividend prioritization : Equal split between all MPA (subsidizing less active MPA), or proportional to [trading volume|MPA supply].
## Basis for distribution within sharedrop timeframe
* Dividends is paid on a scheduled basis as opposed to on user demand
* Dividends are paid based on MPA asset holdings
* 'Coin-age' of asset holdings
* Split of network fees between MPA tokens, either on an equal split or proportional basis.
## Whitelist/Blacklist options
* Configured by the Committee or the MPA issuer.
* An optional whitelist could provide increased control over who is eligible to earn dividends on their MPA holdings.
* An optional blacklist could prevent exchanges/services from earning dividends/interest on MPA (incentivizing holding MPA on the BTS DEX over centralized exchanges).
---
# Discussion
## Is BSIP19 vulnerable to 'yield-harvesting'?
A quote from the '[Socialized yield is broken](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)' blog post:
> "Under BitShares the BitAsset holders receive a yield simply by holding BitUSD. This yield was between 1% and 5% APR on average. Unfortunately, yield harvesting can happen at any time by someone shorting to themselves to gain a very low risk return and undermining goal of encouraging people to buy and hold BitUSD. The yield was funded from transaction fees and by interest paid by shorts."
The concept of "Collateralized Bonds" has yet to materialize within Bitshares 2.0, so in effect we cut asset holders out of fee redistribution (by removing 'socialized yield') without providing a replacement source of income for holding assets on the Bitshares DEX.
* Rather than paying profit to shorters on demand, this BSIP proposes scheduled dividends against BitAsset (MPA) holders via the redistribution of network fees.
* If we simply took a snapshot of user asset holdings at the immediate time of dividend issuance then users could create the asset immediately prior to the scheduled dividend after which they could settle the token back to BTS. To prevent this behaviour, we need to take the age of asset holdings into account.
* Thus BSIP19 is not vulnerable to the 'yield-harvesting' issue that was prevalent within 'Socialized Yield'.
The vast majority of the gathered fees were from non-trading transactions (registering assets, accounts, etc).
## Collateralized Bonds
The concept of "[Collateralized Bonds](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)" has yet to materialize within Bitshares 2.0, so in effect we cut asset holders out of fee redistribution (by removing 'socialized yield') without providing a replacement source of income for holding assets on the Bitshares DEX.
## Further research
* Should exchanges be exempt from receiving dividends? (Beneficial to decentralization, detrimental because selecting individuals to exclude from profit-sharing could be a slippery slope)
* Should LTM users receive a separate bonus dividend?
* Should this BSIP be split in two? One for focusing on MPA's, the other on UIAs?
* Can we pay out dividends in MPA, or will we have to distribute BTS?
* Who can perform this work?
## Additional topics for discussion
* Should exchanges be exempt from receiving dividends?
* Should LTM users receive a separate bonus dividend? Specifically, BTS dividends for holding BTS
* Can we pay out dividends in MPA, or will we have to distribute BTS?
* Is there a better idea than 'coin-age' for fair dividend distribution?
* What's a fair max coin-age? The sharedrop timeframe?
* Should coin-age greater than the sharedrop timeframe receive a bonus modifier?
* Who can perform this work?
* How much should a worker proposal charge for this task?
---
# Summary for Shareholders
* No worker proposal has been created yet, input from coders regarding the cost is neccessary.
* Provide redistributable fee variables for the committe to set.
* This BSIP does not propose values for these fees, this is up to the discretion of the network & committee.
* The fees distributed towards the referral system will be reduced to make room for profit-sharing.
* No worker proposal has been created yet, input from coders regarding the cost is necessary.
* This BSIP does not propose values for these fees, this is up to the discretion of the network & committee.
* The fees distributed towards the referral system will be reduced to make room for profit-sharing.
---
# Copyright
Potentially peerplays for their [profit-sharing functionality]([Peerplays](https://github.com/BunkerChainLabsInc/peerplays-profitshare)) - MIT?
Peerplays created the [profit-sharing functionality](https://github.com/BunkerChainLabsInc/peerplays-profitshare) w/ MIT license:
* > "[The code was created by Bunkerchain Labs Inc. and licensed MIT. So long as MIT parameters are met it can be used in Bitshares.](https://steemit.com/bitshares/@cm-steem/bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares#@peerplays/re-cm-steem-bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares-20170620t032010758z)" - Peerplays (Steemit)
* > "[Implement our profit sharing code thanks to Peerplays development](https://bitsharestalk.org/index.php/topic,23981.75.html)" - BunkerChainLabs (Bitsharestalk)
# See Also
N/A
* [BSIP-19 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-019-updated-draft-introducing-profit-sharing-dividends-to-bitshares-mpa-only)

146
bsip-0020.md Normal file
View File

@ -0,0 +1,146 @@
BSIP: #020
Title: Introducing profit-sharing/dividends to Bitshares (UIA only)
Authors: Customminer
Status: Draft
Type: Protocol
Created: 2017-06-26
Primary Discussion: https://bitsharestalk.org/index.php/topic,23981.0.html
Similar Discussions: N/A
Replaces: N/A
Superseded-By: N/A
Worker: No worker proposal yet - propose bounty?
---
# Abstract
The introduction of 'profit sharing / dividends' for User Issed Assets (UIA) on the Bitshares DEX
---
# Motivation
* One of the major selling/marketing points of BTSX (for myself) back in 2014 was the 5% (really variable 'x' %) on 'anything' marketing. The idea that anyone could securely hold assets long term within their Bitshares wallet and potentially receive better 'interest' rates than that which FIAT banks were offering was (and remains) a powerful message. Whilst this previously applied solely to market pegged assets (MPA - bitUSD, bitCNY, bitEUR, etc), I believe that the same concepts could be extended to UIA.
* Increasing the profitability of the BTS DEX.
* Encouraging users to hold assets on the BTS DEX over centralized exchanges.
---
# Rational
* New UIAs may be created on the BTS DEX to take advantage of this functionality, driving additional fees to the reserve pool upon registration of said assets.
* Improving the ease of performing sharedrops of UIA against BTS/MPA/UIA asset holders will likely increase the frequency of sharedrops being performed on the BTS DEX.
* UIA sharedrops should be considered an incentive for users to hold their assets on the BTS DEX instead of on centralized exchanges, helping prevent exchanges from having a massive BTS vote weight.
* Alternative cryptocurrencies could plausibly migrate their token distribution onto the BTS DEX to avoid maintaining their own proof-of-stake (POS) blockchain as a form of disaster recovery whilst maintaining the ability to provide interest equivelant to their prior POS blockchain.
* Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as [Peerplays](https://github.com/BunkerChainLabsInc/peerplays-profitshare)/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash.
* Most (if not all) Bitcoin forks (1000's of them) have '[sendmany](https://chainquery.com/bitcoin-api/sendmany)' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within the BTS DEX (unless I'm mistaken?).
---
# Specifications
## Implementation of peerplays profit sharing mechanism for UIA
* The Peerplays developement team developed [profit-sharing code for the Graphene toolkit](https://github.com/BunkerChainLabsInc/peerplays-profitshare) approximately one year ago, they have repeatedley given permission for the BTS DEX to utilise their developed profit-sharing code ([case 1](https://bitsharestalk.org/index.php/topic,23981.75.html), [case 2](https://steemit.com/bitshares/@cm-steem/bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares#@peerplays/re-cm-steem-bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares-20170620t032010758z)). A large portion of the work required for this BSIP may already be complete.
## UIA Profit-Sharing/Dividend distribution methods
* Profit-Sharing/Dividends via market fee redistribution (only if the UIA has implemented its own market fees).
* Sharedropping additionally issued UIA tokens against UIA holders (self/other UIA).
* Initial sharedrop distribution of new UIA against holders of any asset on the BTS DEX (sharedrop UIA-A against BTS/UIA-B/MPA holders).
## Whitelist/Blacklist options
* An optional whitelist (configurable by the UIA Issuer) could provide increased control over who is eligible to earn dividends on their UIA holdings.
* An optional blacklist (configurable by the UIA issuer) could prevent exchanges/services from earning dividends/interest on UIA (incentivizing holding UIA on the BTS DEX over centralized exchanges).
## Minimum UIA holdings for dividend eligibility
* Users with very small UIA holdings may be eligible for dividends less than the UIA is configured for (less than the max decimal places), providing the UIA issuer the ability to set the minimum quantity of UIA to be eligible to earn dividends could counteract such an issue.
* Increasing the minimum UIA holdings for dividend eligibility could decrease the network fees required to perform the distribution (less recipients, less fees).
## UIA issuer set interest rates & target assets
* Enable the UIA issuer to select one (or many) assets on the BTS DEX which would be eligible to receive a sharedrop allocation.
* UIA issuer set % for each selected asset.
* Enforce minimum interest rates to prevent creating dust (tiny transactions) or the allocation of dividends less than the UIA's max decimal places.
* Enforce maximum interest rates to prevent attempting to issue more tokens than the max coinsupply.
## Minimum UIA coin-age for dividend eligibility
* To prevent users from only holding UIA during the dividend/sharedrop (buying shortly beforehand and selling immediately afterwards), we aught to provide the UIA issuer the ability to take the 'coin-age' of UIA holdings into account.
* Providing the UIA issuer the ability to set a custom coin-age requirement for sharedrop allocation could provide incentives to hold assets on the BTS DEX long term.
---
# Discussion
## How is this different from BSIP-0019?
* BSIP-0019 proposes the implementation of 'profit sharing / dividends' for MPAs, where as this BSIP references User Issued Assets (UIA).
* BSIP-0019 redistributes network fees (% taken from referral system), where as this BSIP proposes profit-sharing via the redistribution of market fees and/or the sharedropping of additionally issued UIA.
* BSIP-0019 requires the comittee to configure profit-sharing for MPA, where as this BSIP requires the UIA issuer to configure the profit-sharing settings for said UIA.
## BSIP-020's resistance to 'yield-harvesting'
A quote from the '[Socialized yield is broken](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)' blog post:
> "Under BitShares the BitAsset holders receive a yield simply by holding BitUSD. This yield was between 1% and 5% APR on average. Unfortunately, yield harvesting can happen at any time by someone shorting to themselves to gain a very low risk return and undermining goal of encouraging people to buy and hold BitUSD. The yield was funded from transaction fees and by interest paid by shorts."
* Rather than paying profit to shorters on demand, this BSIP proposes scheduled dividends against asset holders on the BTS DEX. Thus BSIP-020 shouldn't be vulnerable to the 'yield-harvesting' issue that was prevalent within 'Socialized Yield' unless the UIA is configured improperly by the UIA issuer.
## Potentially inappropriate for [Exchange Backed Assets](http://docs.bitshares.eu/bitshares/user/eba.html) (EBA)
* Tokens such as OPEN.GRC which are UIA representative of real backed Gridcoins held by Openledger would not be eligible for dividends due to the fact that these tokens are backed by real cryptocurrency and do not operate a fractional reserve.
* If the EBA provider was to purchase additional backing cryptocurrency to then distribute legitimately onto users then this would be possible, this is however highly unlikely to occur.
## BTS DEX sharedrop spam?
* A potential negative impact that BSIP-020 could have upon the BTS DEX is that there may be a large influx of users sharedropping worthless/troll tokens onto asset holders.
* To deter this behaviour, the sharedropping of UIA-A (your example UIA) against UIA-B (my example UIA) should have a larger network fee than issuing a sharedrop of UIA-A against UIA-A holders. Likewise, sharedropping an UIA against MPA holders should
## Maximum coinsupply/inflation abuse
* If an user creates an initial coin supply of 99999999999 (current max) then attempts to issue additional tokens through newly introduced functionality, we'll need to reinforce the maximum coin supply.
* If an user creates an UIA with a coin supply less than max but with an interest rate which would attempt to drive the coin supply greater than the maximum possibly supply we'll need to reinforce the maximum coin supply.
* Increasing the maximum coin supply limit wouldn't solve the above problems.
## Max decimal places
* If an user holds a tiny amount of an UIA and the inflation rate is very low, then the user may be eligible for a payment lower than the max decimal places (ie 4 decimal places & 0.00001 UIA token payment). We should reinforce these maximum decimal places during dividend issuance, potentially enforcing minimum UIA holdings and minimum interest rates.
## Incentivizing market making
* We could potentially sharedrop UIA against market makers based on network statistics such as filled orders (participants & amount) or MPA collateral/debt positions.
* Incentivizing market makers wouldn't be vulnerable to the 'yield-harvesting' that plagued 'socialized-yield', rather we may see users fake volume on illiquid trading pairs in an attempt to inflate their sharedrop allocation. To avoid this, UIA issuers performing such a market-maker sharedrop should target trading pairs with high liquidity (ultimately up to their discretion).
## Automation once configured?
If an UIA is configured to inflate and distribute said newly issued tokens against holders of asset 'x' on the BTS DEX, then the UIA owner was set to either null or the committee then this would increase decentralization of said token in a manner similar to POS cryptocurrency issuance (no centralized issuer). This would potentially run into issues regarding network spam and max coinsupply/inflation abuse so perhaps it'd be worth keeping manual..
## Further research
* Who can perform this work?
* 3rd party scripts for determining sharedrop allocation modifiers?
---
# Summary for Shareholders
* No worker proposal has been created yet, input from coders regarding the cost is neccessary.
* No proposed change to current network fees.
* UIA changes are in scope of this BSIP, not MPA.
---
# Copyright
Peerplays created the [profit-sharing functionality](https://github.com/BunkerChainLabsInc/peerplays-profitshare) w/ MIT license:
* > "[The code was created by Bunkerchain Labs Inc. and licensed MIT. So long as MIT parameters are met it can be used in Bitshares.](https://steemit.com/bitshares/@cm-steem/bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares#@peerplays/re-cm-steem-bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares-20170620t032010758z)" - Peerplays (Steemit)
* > "[Implement our profit sharing code thanks to Peerplays development](https://bitsharestalk.org/index.php/topic,23981.75.html)" - BunkerChainLabs (Bitsharestalk)
---
# See Also
N/A

114
bsip-0021.md Normal file
View File

@ -0,0 +1,114 @@
BSIP: #021
Title: Introducing the 'Coin-Age' statistic to Bitshares assets
Authors: Customminer
Status: Draft
Type: Protocol
Created: 2017-07-03
Primary Discussion: https://steemit.com/bitshares/@cm-steem/bsip-020-draft-introducing-profit-sharing-dividends-to-bitshares-uia-only-input-would-be-massively-appreciated
Similar Discussions: N/A
Replaces: N/A
Superseded-By:
Worker: N/A
# Abstract
Introducing the ability to query the 'Coin-Age' of assets held by individuals upon the BTS DEX.
# Motivation
* There exists no directly queryable 'coin-age' statistic within the Bitshares network.
* Currently, the closest we can get to querying an account's accumulated asset coin-age within the client is query an account's transaction history then calculate the coin-age with an external script.
* There aren't currently any open-source scripts for calculating user asset coin-age.
# Rational
* BSIPs 19 and 20 (Introducing profit-sharing/dividends for MPA(19)/UIA(20)) both reference a non-existent 'coin-age' statistic.
* Proposed for proportionally distributing profit/dividends based on the length of time an asset has been held in the user's balance within the dividend time period, preventing abuse of the scheduled dividend.
* We have experienced market fluctuations/instability caused by publicly scheduled snapshots (users buy immediately before, snapshot, sell immediately afterwards); discouraging similar practices through the inclusion of 'coin-age' in the dividend mechanism could help neutralise this issue.
* Regarding consensus, there hasn't been sufficient discussion for users to voice disagreement against coin-age proposals.
* A legit concern is that if there are a significant quantity of asset holders & transactions to process, that evaluating accumulated_coin_age for all users could be computationally expensive.
* A concern regarding coin-age that this BSIP accounts for is if coins are held longer than the user specified time_period, that the coins start representing more than one of themselves (1 being worth 2 if held 2 times longer than the user input time period).
# Specifications
* For each chunk of a specific asset transfered to an user in the past, enable the easy querying/calculation of each user's accumulated 'coin-age' statistic.
* Possible route:
* 1. Retrieve list of accounts holding chosen asset
* 2. Given this list, query the account's current asset holdings (for chosen asset), returning the list of transactions that make up holdings.
* 3. Evaluate coin-age from list of tx for each eligible asset holder.
* Draft coin-age calculation: (very much so example pseudocode, not production code!)
```
let reference_asset = USD; //User input variable
let time_period = 30 days; //User input variable
let accumulated_coin_age = 0;
let reference_time = current_time; //User input variable
if (whitelisted_accounts) {
let eligible_asset_holders = whitelisted_accounts //whitelist input by user
} else if (blacklisted_accounts) {
let eligible_asset_holders = asset_holder_list - blacklisted_account_list //blacklist input by user
} else {
let eligible_asset_holders = asset_holder_list //include all asset holders.
}
for each asset_holder in eligible_asset_holders {
for each tx in asset_holdings {
let tx_balance = current_tx_balance //Get the quantity of coins present in this transaction
let time_diff = current_date - tx_inbound_date //Get the age of the transaction
if (time_diff > time_period) {
accumulated_coin_age += tx_balance //Prevent coins being worth more if held longer than time_period. Increase time_period to provide this functionality.
} else {
accumulated_coin_age += ((time_diff/time_period)*tx_balance)
}
}
//Store current asset_holder & accumulated_coin_age in [hashmap|storage] for later referencing
}
```
* Coin-Age based individual-user dividend calculation:
```
if (whitelisted_accounts) {
let total_eligible_token_supply = assets_held_by_whitelisted_accounts
} else if (blacklisted_accounts) {
let total_eligible_token_supply = total_supply - assets_held_by_blacklisted_accounts
} else {
let total_eligible_token_supply = total_supply
}
let total_distributable_tokens = 1000 OPEN.GRC; //quantity & token type set by user
for each asset_holder in coin_age_hashmap {
dividend_allocation = (accumulated_coin_age/total_eligible_token_supply)*total_distributable_tokens
}
```
# Discussion
## How does coin-age prevent abuse of BSIPs 19 & 20?
* If we were to perform a scheduled dividend based on a static snapshot of immediate account holdings, users could purchase the asset immediately prior to the scheduled dividend, receive the dividend then sell immediately afterwards, potentially causing market instability/fluctuations around the scheduled dividend.
* We have experienced this form of market instability in the past for protoshares (around past sharedrops) and for BTS (for peerplays).
(buy immediately beforehand, sell immediately afterwards, causing market instability around the scheduled dividend).
## Potential alternatives to 'coin-age' for preventing abuse of a dividend system
* Random snapshot date within sharedrop time period (similar to peerplay's secret snapshot date within possible snapshot range).
* Downsides: Assets held outwith the moment of snapshot within the snapshot time period are not eligible for receiving dividends.
* Increasing market fees on the days surrounding the scheduled sharedrop? If an UIA has an additionally enabled fee market, a premium fee could be enabled potentially encouraging users to buy the assets earlier in the month & providing longer term asset holders additional profit? Would ony be possible for UIA, not MPA.
* Disabling of market trading in the days surrounding the dividend payment? This would be incresibly heavy handed & potentially scare asset holders, especially if the asset price fluctuaed on external exchanges.
* Entirely disregard any concerns of dividend system abuse? Openledger currently performs regular sharedrops onto Obits holders without taking coin-age into account!
# Summary for Shareholders
* No impact on shareholders, this would simply enable an additional queryable statistic within the Bitshares network for additional functionality proposed in BSIPs 19 and 20 to take advantage of.
* No worker proposal nor bounty proposed yet, simply brainstorming documentation within the community!
* Will be discussed/mentioned in a future BeyondBitcoin hangout.
# Copyright
N/A - Consider this BSIP entirely open-source/MIT-licensed, I am not the originator of the concept of 'coin-age' (several proof-of-stake cryptocurrencies make use of coin-age for finding stakable coins).
# See Also
* [List account balances - Graphene documentation](http://docs.bitshares.org/api/database.html#id8)
* [BSIP 21 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-0021-draft-introducing-the-coin-age-statistic-to-bitshares-assets-input-would-be-massively-appreciated)

129
bsip-0022.md Normal file
View File

@ -0,0 +1,129 @@
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)