From 6c647d394a6fa106e79034605c04fab17f6a5644 Mon Sep 17 00:00:00 2001 From: grcgrc Date: Mon, 24 Jul 2017 01:41:06 +0100 Subject: [PATCH 1/2] Clean commit BSIP 19 updated. BSIPs 20, 21 & 22 initial commit. --- README.md | 5 +- bsip-0019.md | 114 ++++++++++++++++++++++++++++------------ bsip-0020.md | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++ bsip-0021.md | 114 ++++++++++++++++++++++++++++++++++++++++ bsip-0022.md | 129 +++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 474 insertions(+), 34 deletions(-) create mode 100644 bsip-0020.md create mode 100644 bsip-0021.md create mode 100644 bsip-0022.md diff --git a/README.md b/README.md index 8b3bd9a..eebd4c2 100644 --- a/README.md +++ b/README.md @@ -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 \ No newline at end of file +[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 \ No newline at end of file diff --git a/bsip-0019.md b/bsip-0019.md index 5dc518a..546a18a 100644 --- a/bsip-0019.md +++ b/bsip-0019.md @@ -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 \ No newline at end of file +* [BSIP-19 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-019-updated-draft-introducing-profit-sharing-dividends-to-bitshares-mpa-only) \ No newline at end of file diff --git a/bsip-0020.md b/bsip-0020.md new file mode 100644 index 0000000..2546164 --- /dev/null +++ b/bsip-0020.md @@ -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 \ No newline at end of file diff --git a/bsip-0021.md b/bsip-0021.md new file mode 100644 index 0000000..7648e54 --- /dev/null +++ b/bsip-0021.md @@ -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) \ No newline at end of file diff --git a/bsip-0022.md b/bsip-0022.md new file mode 100644 index 0000000..29f2ab6 --- /dev/null +++ b/bsip-0022.md @@ -0,0 +1,129 @@ + BSIP: 0022 + Title: Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network + Authors: Customminer + Authors of relevant BSIP-0005: Daniel Larmier + Fabian Schuh + Status: Draft + Type: Protocol + Created: 2017-07-06 + Primary discussions: + + + Similar discussions: + 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) \ No newline at end of file From 742f1a617f22fda1aec11985628d2f8860be2a23 Mon Sep 17 00:00:00 2001 From: grcgrc Date: Thu, 31 Aug 2017 13:43:08 +0100 Subject: [PATCH 2/2] New BSIPs & Small changes to past BSIPs New: 23 & 24 Changes to old: Link to customminer's profile for contact. --- BSIP-0023.md | 658 +++++++++++++++++++++++++++++++++++++++++++++++++++ BSIP-0024.md | 69 ++++++ README.md | 4 +- bsip-0019.md | 2 +- bsip-0020.md | 2 +- bsip-0021.md | 2 +- bsip-0022.md | 2 +- 7 files changed, 734 insertions(+), 5 deletions(-) create mode 100644 BSIP-0023.md create mode 100644 BSIP-0024.md diff --git a/BSIP-0023.md b/BSIP-0023.md new file mode 100644 index 0000000..e7ef890 --- /dev/null +++ b/BSIP-0023.md @@ -0,0 +1,658 @@ + BSIP: BSIP-0023 + Title: Sharedropping an UIA against an external cryptocurrency distribution snapshot + Authors: [Customminer](https://steemit.com/@cm-steem/) + Status: Draft + Type: Protocol + Created: 2017-08-22 + Discussion: https://steemit.com/bitshares/@cm-steem/draft-bsip-0023-sharedropping-an-uia-against-an-external-cryptocurrency-distribution-snapshot , https://steemit.com/bitshares/@cm-steem/migrating-bitcoin-onto-the-bts-dex-via-uia-snapshot-sharedrop + Replaces: N/A + Superseded-By: N/A + Worker: N/A + +--- + +# Index + +* Abstract +* Motivation +* Index +* Rational +* Specifications + * Standardised snapshot process + * Summarised sidecoin snapshot steps + * Sidecoin snapshot tools + * Similar UXTO extraction tools + * LevelDB dumping tools + * Example genesis.json snippets from multiple projects + * PTS (POW) -> BTSX (BTS 0.9x) [genesis.json](https://raw.githubusercontent.com/bitshares/bitshares1-core/master/libraries/blockchain/genesis.json) + * PTS (POW) -> PTS (DPOS) [genesis.json](https://github.com/PTS-DPOS/PTS/blob/master/libraries/blockchain/genesis.json) + * BTSX ([BTS 0.9x](https://github.com/bitshares/bitshares1-core)) -> [BTS 2.0](https://github.com/bitshares/bitshares-core/) (Graphene) [genesis.json](https://github.com/bitshares/bitshares-core/blob/master/genesis.json) snippet + * Peerplays (PPY) [genesis.json](https://github.com/PBSA/peerplays/blob/master/genesis.json) (BTC donation address sharedrop onto Graphene chain) + * Decent (DCT) [genesis.json](https://github.com/DECENTfoundation/DECENT-Network/blob/master/genesis.json) (BTC donation address sharedrop onto Graphene chain) + * Golos (Steem -> Golos) + * Potential BTC_Sharedrop.JSON format + * Existing genesis documentation + * Claiming UIA token via importing external cryptocurrency private keys +* Discussion + * Need to pre-register sharedrop recipient accounts? + * Post sharedrop UIA ownership + * UIA details/settings of note + * Example snapshot targets + * Bitcoin + * Combined Top-k cryptos + * ICOs + * Non-crypto targets + * BTS Comparison to BTC forks + * Genesis.json comparisons + * Negatives of introducing this functionality + * Advantages of sharedropping an BTC [UIA](http://docs.bitshares.eu/bitshares/user/uia.html) on the BTS DEX + * Visualization of UIA sharedrop process +* Summary for Shareholders +* Copyright +* See Also + +--- + +# Abstract + +Introduce additional snapshot genesis data for the sharedropping of UIA against external cryptocurrencies (Similar to PST->BTSX & BTSX->BTS2.0 but for UIA). + +# Motivation + +It's currently not possible to claim an UIA balance by importing private key from a snapshotted external cryptocurrency. + +# Rational + +* The Bitcoin network forever fractured on 1st August 2017 when Bitcoin Cash (BCH) successfully forked away from the Bitcoin Core network. Given that all Bitcoin users were encouraged to hold their own private keys for this event, this moment in time is a perfect opportunity to sharedrop this snapshotted moment as an UIA on the BTS DEX at a later date. There may be another snapshot opportunity when the 2x part of segwit2x doesn't activate in November. +* At least one team ([Cryptonomex](https://cryptonomex.com/)) has been drawn to this concept already (http://fastbitcoinunited.com/ Assets: [FBTC](http://cryptofresh.com/a/FBTC) & [LSBTC](http://cryptofresh.com/a/LSBTC)). +* Many thousands of addresses hold less Bitcoin (core) than the required tx fee (effectively inaccessible), these funds would be made liquid if claimed as an UIA on the BTS DEX. +* If we can create complex snapshots which target multiple external cryptocurrency networks, then we could attempt to distribute an UIA to say the top 20/50/100 (etc) cryptocurrencies so as to recruit their combined userbases to the Bitshares network. +* By standardizing the process of snapshotting an external crypto and then sharedropping it as an UIA on the BTS DEX, we can provide a disaster recovery solution to external cryptocurrencies which experience catastrophic network failure. + +--- + +# Specifications + +## Standardised snapshot process + +There is currently insufficient snapshot preparation steps documented in the graphene wiki regarding how to produce a snapshot of an external blockchain for the issuance of assets (CORE|UIA) on the BTS DEX, despite this being performed during the PTS->BTSX sharedrop process (potentially internal cryptonomex documentation). + +"[Sidecoin: a snapshot mechanism for bootstrapping a blockchain](https://arxiv.org/abs/1501.01039)" - This research paper by [Joey Krug](https://www.linkedin.com/in/joeykrug) details how to produce a snapshot of the Bitcoin network then use this information as the basis for an initial token distribution. + +### Summarised sidecoin snapshot steps: + +* Download the cryptocurrency client/daemon & Fully sync the blockchain. +* Scrape BTC blockchain for uxto balances & their corresponding public keys. +* Convert public key (hash160) to the reference cryptocurrency address format, for Bitcoin it's base-56 strings. +* Summarize scraped content in a delimited text file (ie: Address hash160 Balance) +* Sort based on balance in descending order, optionally apply minimum balance filter to reduce filesize. + +These steps should apply to most bitcoin forks (many alts), in fact any large collection of public keys could work - not just cryptocurrency addresses/hash160s. + +To improve the legitimacy of the sharedrop data/files, multiple trusted parties could run the same snapshot process then compare their independently created snapshot files for verification prior to inclusion within the BTS DEX. + +#### Sidecoin snapshot tools: + +* [SideCoin's bash script for automated blockparser interaction](https://github.com/AugurProject/SideCoin/blob/master/snapshot) - Last update 3 years ago. +* [BlockParser](https://github.com/znort987/blockparser) - Last update 2 years ago, written in c++ & needs 20GB+ RAM + +These tools are designed for Bitcoin back in 2013-2015, so there may be issues running it against the latest BTC chain & it'd certainly require modification to run against alternative cryptocurrencies to bitcoin. + +#### Similar UXTO extraction tools + +* [Chainstate utxo stream](https://github.com/challengerdeep/chainstate-utxo-stream) +* [node bitcoin bootstrap](https://github.com/BooBSD/node-bitcoin-bootstrap) +* [uxto stats](https://github.com/timothyej/utxo-stats.com) - more of a visualization/counter. Could be very effective for quickly estimating the quantity of UXTO & resulting snapshot filesize. +* [Bitcoin Database Generator](https://github.com/ladimolnar/BitcoinDatabaseGenerator) - Dumps to SQL, would require further SQL -> TXT/JSON steps. +* [Bitcointalk - "Easy way" to extract the UTXO from Bitcoin Core?](https://bitcointalk.org/index.php?topic=647198.0) This thread didn't lead to opensource software, but is an interesting read for parties interested in extracting uxto data manually. + +#### LevelDB dumping tools + +Note: Dumping the chainstate leveldb database using a leveldb dumping tool will result in serialized data which will require parsing to reveal the public key, address & balance for stored UXTO. This is potentially more complex than using UXTO extraction tools, however may be more plausible for highly customized alts. + +* [level-dump](https://www.npmjs.com/package/level-dump) +* [leveldb-tools](https://github.com/tgulacsi/leveldb-tools) +* [leveldb-json](https://github.com/nisaacson/leveldb-json) +* [levelup](https://github.com/Level/levelup) + +#### We're interested in extracting the "[chainstate subdirectory](https://en.bitcoin.it/wiki/Data_directory#chainstate_subdirectory)" contents for BTC based alts + +> "[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of may 2013) for every output being spent."" + +### Example genesis.json snippets from multiple projects + +The following sections are summarized genesis.json snippets, focusing on how they allocated initial balances & vesting sharedrops (2 examples per field). + +#### PTS (POW) -> BTSX (BTS 0.9x) [genesis.json](https://raw.githubusercontent.com/bitshares/bitshares1-core/master/libraries/blockchain/genesis.json): + +Interesting to note - the vesting balance duration day cap of 730 was not reached before the sharedrop from BTS 0.9x -> BTS 2.0. I'm assuming that the vesting 'sharedrop_balances' were targetting the AGS holders, not the PTS holders (since they were in receipt of the initial_balances). + +Filesize: 22.5 MB + +``` +{ + "timestamp": "2015-03-02T19:19:07", + "initial_balances": [ + { + "raw_address": "Pivz9g8dD7QSGbTyoVwLvoXWiV4843JJBE", + "balance": 2020202020202 + }, + { + "raw_address": "PiNB2PddirZKteFBiXPQP77LMM2dUFMPSU", + "balance": 2020202020202 + } + ], + "sharedrop_balances": { + "start_time": "2014-11-06T00:00:00", + "duration_days": 730, + "vesting_balances": [ + { + "raw_address": "PsB1WyTaYEcQhZ2GryVxC8nUfM1tytjgf9", + "balance": 14436676 + }, + { + "raw_address": "Phquw2oMe9QJu3Kt2HZCX3batcQV9oFPCX", + "balance": 13514 + } + ] + } +} +``` + +#### PTS (POW) -> PTS (DPOS) [genesis.json](https://github.com/PTS-DPOS/PTS/blob/master/libraries/blockchain/genesis.json): + +Protoshares was at one point upgraded to DPOS but has recently fallen into obscurity, it had the equivelant tech of BTS 0.9x. They performed a Protoshares -> Protoshares-DPOS sharedrop. + +Protoshares performed their sharedrop using 'balances' and 'initial_vesting_balances' sections of their [genesis.json](https://github.com/PTS-DPOS/PTS/blob/master/libraries/blockchain/genesis.json) file. + +Filesize: 2.94 MB + +``` +{ +"timestamp" : "20141214T214417", +"balances": [ + [ + "3Hgj6S1kA93phoxNDsT5gEPtnc2orLqTv5", + 100000 + ], + [ + "PXvoyT5emvghiHNmrQTV3Fc9cwQX4b8uzE", + 13079 + ]], +"initial_vesting_balances": [{ + "owner": "PPYERcc1t6Vq9tG7LaU4EbPmbArAmZAs7Dr8", + "asset_symbol": "PPY", + "amount": 75000000, + "begin_timestamp": "2017-05-30T08:09:05", + "vesting_cliff_seconds": 15724800, + "vesting_duration_seconds": 15724800, + "begin_balance": 75000000 +},{ + "owner": "PPYERaNVbeWtTTuEuppoBokupFgPfxGMqwt6", + "asset_symbol": "PPY", + "amount": 475000000, + "begin_timestamp": "2017-05-30T08:09:05", + "vesting_cliff_seconds": 15724800, + "vesting_duration_seconds": 15724800, + "begin_balance": 475000000 +}] +} +``` + +#### BTSX ([BTS 0.9x](https://github.com/bitshares/bitshares1-core)) -> [BTS 2.0](https://github.com/bitshares/bitshares-core/) (Graphene) [genesis.json](https://github.com/bitshares/bitshares-core/blob/master/genesis.json) snippet: + +This genesis file doesn't reference protoshares, rather [BTS 0.9x](https://github.com/bitshares/bitshares1-core) balances. This is why users who want to redeem old PTS keys still need to import their key using the [BTS 0.9x](https://github.com/bitshares/bitshares1-core) client before exporting key & importing to [BTS 2.0](https://github.com/bitshares/bitshares-core/). + +Filesize: 35.9MB + +Note: Viewing genesis.json on Win10 w/ low RAM crashes firefox & text editors. Likewise, it's all on a single line so it's not easy for a human to read. + +``` +{ + "initial_timestamp":"2015-10-13T13:00:00" + "initial_balances":[{"amount":229174,"asset_symbol":"BTS","owner":"BTS11CMY1PYTkBGixS3gF2tEN7Qb9Thk6K1"},{"amount":706859,"asset_symbol":"BTS","owner":"BTS12LHFdUUYnm61Zi4U6Vp8iNxwBwnQ9iu"}], + "initial_vesting_balances":[{"amount":23176,"asset_symbol":"BTS","begin_balance":43550,"begin_timestamp":"2014-11-06T00:00:00","owner":"BTS11CMY1PYTkBGixS3gF2tEN7Qb9Thk6K1","vesting_duration_seconds":63072000},{"amount":71496,"asset_symbol":"BTS","begin_balance":134355,"begin_timestamp":"2014-11-06T00:00:00","owner":"BTS12LHFdUUYnm61Zi4U6Vp8iNxwBwnQ9iu","vesting_duration_seconds":63072000}] +} +``` + +#### Peerplays (PPY) [genesis.json](https://github.com/PBSA/peerplays/blob/master/genesis.json) (BTC donation address sharedrop onto Graphene chain) + +It appears that PPY performed an extensive 5% sharedrop not just to BTS holders but to several assets & even collateral targets. It should thusly be possible to create a geneis.json file which targets multiple blockchain's uxto for snapshot targetting. + +Filesize: 5.16 MB + +``` +{ + "initial_timestamp": "2017-06-06T16:00:00", + "max_core_supply": "1446051993031", + }, + "initial_bts_accounts": [{ + "name": "bts-committee-account", + "owner_authority": { + "weight_threshold": 1, + "account_auths": [], + "key_auths": [], + "address_auths": [] + }, + "active_authority": { + "weight_threshold": 150659, + "account_auths": [[ + "bts-abit", + 35513 + ],[ + "bts-bhuz", + 34400 + ] + ], + "key_auths": [], + "address_auths": [] + }, + "core_balance": 0 + },{ + "name": "bts-alexkravets", + "owner_authority": { + "weight_threshold": 1, + "account_auths": [], + "key_auths": [[ + "PPY7tkzeyUwoSCseRmUac82qNttbrtjoyQitkDqQNi94BDxrg56Es", + 1 + ] + ], + "address_auths": [] + }, + "active_authority": { + "weight_threshold": 1, + "account_auths": [], + "key_auths": [[ + "PPY7tkzeyUwoSCseRmUac82qNttbrtjoyQitkDqQNi94BDxrg56Es", + 1 + ] + ], + "address_auths": [] + }, + "core_balance": 1551 + }], + "initial_vesting_balances": [{ + "owner": "PPYERcc1t6Vq9tG7LaU4EbPmbArAmZAs7Dr8", + "asset_symbol": "PPY", + "amount": 75000000, + "begin_timestamp": "2017-05-30T08:09:05", + "vesting_cliff_seconds": 15724800, + "vesting_duration_seconds": 15724800, + "begin_balance": 75000000 + },{ + "owner": "PPYERaNVbeWtTTuEuppoBokupFgPfxGMqwt6", + "asset_symbol": "PPY", + "amount": 475000000, + "begin_timestamp": "2017-05-30T08:09:05", + "vesting_cliff_seconds": 15724800, + "vesting_duration_seconds": 15724800, + "begin_balance": 475000000 + } + ] +} +``` + +### Decent (DCT) [genesis.json](https://github.com/DECENTfoundation/DECENT-Network/blob/master/genesis.json) (BTC donation address sharedrop onto Graphene chain) + +Despite taking BTC donations, Decent did not sharedrop onto BTC addresses (in the traditional private key import sense) thus the distribution of the initial tokens is likely centralized (initial decentx balances distributing the DCT out to donators) where as BTS/PPY/PTS-DPOS performed decentralized sharedrops based on prior network uxto snapshots. + +Filesize: 13.7 KB + +``` +{ + "initial_timestamp": "2017-06-30T10:00:15", + "max_core_supply": "7319777577456900", + }, + "initial_balances": [{ + "owner": "decent1", + "asset_symbol": "DCT", + "amount": "732894133922417" + },{ + "owner": "decent2", + "asset_symbol": "DCT", + "amount": "3851075976750000" + } + ], +} +``` + +#### Golos (Steem -> Golos) + +Unable to find a genesis json file for the initial steem distribution ([despite searching github](https://github.com/steemit/steem/search?p=1&q=extension%3Ajson&type=&utf8=%E2%9C%93)) perhaps due to issuance via mining, the Golos genesis data was [easily found on Steemit](https://steemit.com/golos/@litvintech/snapshot-of-steem-blockchain-for-golos-genesis-is-done) however it isn't stored publicly on github (make a backup for future reference). + +Filesize: 10.3MB + +``` +{ + "timestamp": "2016-09-29T12:00:00", + "head_block_num": 5392323, + "head_block_id": "005247c3271c99153204077460cbd62e5750ad0f", + "chain_id": "0000000000000000000000000000000000000000000000000000000000000000", + "summary": { + "balance": "169829646.527 STEEM", + "sbd_balance": "2261611.529 SBD", + "total_vesting_shares": "453668506235.766119 VESTS", + "total_vesting_fund_steem": "162005112.002 STEEM", + "accounts_count": 8374 + }, + "accounts": [{ + "id": 10, + "name": "dantheman", + "posting_rewards": 93248715, + "curation_rewards": 399127448, + "keys": { + "owner_key": { + "weight_threshold": 1, + "account_auths": [ + + ], + "key_auths": [ + [ + "GLS7H7yZfed2GqkgdLuYy3VVrmQLV4htbiu1WGouRHsjjD4Kq1MvQ", + 1 + ] + ] + }, + "active_key": { + "weight_threshold": 1, + "account_auths": [ + + ], + "key_auths": [ + [ + "GLS7YtQZ7fwg7VE2U7wUPwdL2hWwtd3zR45XSPTk5dTirk7Mxud5z", + 1 + ] + ] + }, + "posting_key": { + "weight_threshold": 1, + "account_auths": [ + + ], + "key_auths": [ + [ + "GLS4yfYEjUoey4PLrKhnKFo1XKQZtZ77fWLnbGTr2mAUaSt2Sx9W4", + 1 + ] + ] + }, + "memo_key": "GLS5Jna5tmYoiNV7RyABdwYgRCKJGgbrt3EVB5RqzJvvx3ecG5YPp" + }, + "balances": { + "assets": [ + "20456.083 STEEM", + "152150.043 SBD", + "5455192892.482158 VESTS" + ] + }, + "json_metadata": "", + "proxy": "", + "post_count": 1016, + "recovery_account": "steem", + "reputation": "151376718499031" + }, + { + "id": 3548, + "name": "stan", + "posting_rewards": 9492362, + "curation_rewards": 20419, + "keys": { + "owner_key": { + "weight_threshold": 1, + "account_auths": [ + + ], + "key_auths": [ + [ + "GLS53xgdjGJ26QEF8qUbGsxguRBQU1UMqLKTT3LJ2ysgsLdr3zJk2", + 1 + ] + ] + }, + "active_key": { + "weight_threshold": 1, + "account_auths": [ + + ], + "key_auths": [ + [ + "GLS5SfLYuCjwi22GSB4c2kum6a2gES3HU7KYyaSBygurop8nkBYSc", + 1 + ] + ] + }, + "posting_key": { + "weight_threshold": 1, + "account_auths": [ + + ], + "key_auths": [ + [ + "GLS5ygtu1ERfX3Ba9JbuMKGgi5NxdDjHzpKdmYPk3qSAsxDaSiW63", + 1 + ] + ] + }, + "memo_key": "GLS5ygtu1ERfX3Ba9JbuMKGgi5NxdDjHzpKdmYPk3qSAsxDaSiW63" + }, + "balances": { + "assets": [ + "7.904 STEEM", + "4293.751 SBD", + "24140197.181691 VESTS" + ] + }, + "json_metadata": "", + "proxy": "", + "post_count": 948, + "recovery_account": "steem", + "reputation": "26432707129156" + }] +} +``` + +### Potential BTC_Sharedrop.JSON format + +If we need to use a json genesis format, I don't imagine that it'll be more complex than the following: + +``` +{ + "timestamp": "2017-07-01T00:00:00", + "uia_balances": [ + { + "raw_address": "BTC_Hash160_A", + "balance": Proportional_Balance_A + }, + { + "raw_address": "BTC_Hash160_B", + "balance": Proportional_Balance_B + } + ], +} +``` + +The remaining 9m BTC (which won't be distributed as block rewards since POW is non-existent), we could potentially distribute these funds proportionally to the UXTO snapshot recipients over the course of 10+ years (or however long the BTC distribution will take). + +``` +{ + "sharedrop_balances": { + "start_time": "2017-07-01T00:00:00", + "duration_days": 35600, + "vesting_balances": [ + { + "raw_address": "BTC_Hash160_A", + "balance": Proportional_Balance_A + }, + { + "raw_address": "BTC_Hash160_B", + "balance": Proportional_Balance_B + } + ] + } +} +``` + +### Existing genesis documentation: +* [Genesis Configuration](http://docs.bitshares.org/testnet/2-genesis.html) +* [Initializing blockchain](http://docs.bitshares.org/testnet/3-init-blockchain.html?highlight=genesis) +* [Example generated genesis file](https://pastebin.com/Q79S66Dh) + +## Snapshot data inclusion in Bitshares network + +The [genesis.json](https://github.com/bitshares/bitshares-core/blob/master/genesis.json) file is used in graphene to specify the initial distribution of CORE assets (BTS/PPY/PTS/DCT) within a newly initialized blockchain. Where the btc_snapshot_genesis.json (example filenaming convention) will be stored or included in the BTS network is currently unknown & requires developer input as the token being distributed is not a CORE asset (rather, an UIA) and the blockchain is well established (not initializing from zero). + +The filesize of a BTC snapshot will be huge (unless we filter sharedrop recipients by balance (either min or max)) the website [uxto-stats](https://utxo-stats.com/) shows that there are over 51.4m BTC UXTO which would be involved in the fastbitcoin snapshot; our tab delimited text file containing rows of 'address hash160 balance' (eg '365E3B5202479CF8CFEA1774D935E2D1062D6FC8 36eVJEiWAeFaJmQwcderHALfx3Z2ySHCsW 500') assuming 74 characters w/ 8bits each that's 592 bits, multiplied by 51.4m we're looking at approx 3.54 GB not including the json padding. By comparison, the BTS2.0 genesis snapshot is 1% the size of the theoretical BTC snapshot file. + +The 3.54GB BTC snapshot file will be difficult for 3rd party human verification due to its size. + +If we are required to store the 3.54 GB genesis file within transactions upon the blockchain instead of full node operators storing and hosting the file for user lookup, we wouldn't be able to store this data in a single block (far exceeding the max block size). We would need to split the genesis.json file into thousands of transactions containing a large amount of data each, the transaction fees charged to the UIA sharedrop uploader would potentially be very expensive. + +How can we include new UIA genesis data within the BTS DEX without requiring a hard fork for each subsequent UIA sharedrop? Ideally we will perform several such UIA sharedrops on the BTS DEX in the future, against different snapshot targets. + +Currently the genesis documentation covers the generation of a genesis.json template (to then customize) and the initializing of a new graphene blockchain with said genesis.json file, there isn't documentation regarding the inclusion of additional genesis data (within the genesis.json or external_genesis_btc.json files) for sharedropping non-core assets such as UIA. + +How large will these UIA genesis.json files be? The BTS [genesis.json](https://github.com/bitshares/bitshares-core/blob/master/genesis.json) used for [snapshotting BTSX/PTS/DNS & sharedropping to BTS 2.0](https://bitsharestalk.org/index.php/topic,14019.msg182308.html#msg182308) is approximately 36.7MB large, it's highly likely that a genesis_btc.json file will be hundreds/thousands of MB large. If we have complex combinations of many blockchains, this may become a burden on the network to maintain. + +## Claiming UIA token via importing external cryptocurrency private keys + +Rather than having a centralized issuance of an UIA to BTC holders (bytebal's style), it's far more desirable to simply import BTC private keys to claim owed UIA balances. + +It's currently only possible to import 'BTS 0.9x' era private keys to access sharedropped BTS (CORE Asset) tokens, we need to extend the current private key import functionality to support distribution of non-core assets & (m)any public key formats (hash160, steem active/owner keys, etc). This requires developer input and likely a hardfork to the current BTS network. + +See how we can currently import private keys in graphene to access CORE Asset balances: +[Bitshares private key import](http://docs.bitshares.org/migration/howto-importing-wallet.html) +[MUSE private key import](http://docs.bitshares.org/muse/migration/howto-importing-wallet.html) + +--- + +# Discussion + +## Need to pre-register sharedrop recipient accounts? + +Both BTSX and PTS-DPOS created sharedrops against Protoshares which is a smaller version of what would need performed against the BTC network. They both reference raw addresses without pre-registering accounts for these balances. + +Looking at the BTSX->BTS snapshot, both the initial_balances & sharedrop_balances fields reference the BTSX key not a BTS account, and searching cryptofresh for the account yields nothing. + +What would be best is if we could specify an 'uia_balance' for each address, and allow the user to import their BTC private keys into an existing Bitshares account, so we could avoid registering 52 million bitshares accounts (very expensive for the sharedropper). + +I'd greatly appreciate any developer input on this topic, some of this is pretty complex and undocumented. + +## Post sharedrop UIA ownership + +Once an UIA has been sharedropped through the inclusion of our btc_genesis.json data (either via github & witness/full-node hosted or stored within many transactions on the blockchain), what are appropriate UIA settings and who should hold authority to further change the UIA's settings? + +Ideally: UIA ownership transfered to null (destroying ownership - fully decentralized and permanent UIA settings). +Alternatively: UIA ownership committee multisig account (centralized risk however editable UIA settings). + +### UIA details/settings of note +* Description - Doesn't need to change much once set. +* "Enable market fee" -> Yes/No - Ideally we wouldn't set a market fee however then the fee pool may dry up (requiring occasional top up). + * "Market fee %" + * "Max market fee" +* "Require holders to be white-listed" -> If set & ownership set to null then only the sharedrop recipients could ever hold the asset; this would limit the market trading activity but could pose an interesting experiment. +* "Issuer may transfer asset back to himself" -> We want this to be permanently disabled for an external crypto sharedrop for maximum decentralization. +* "Issuer must approve all transfers" -> Again, permanently delete as the issuer should be out of the picture for this type of UIA. +* "Disable confidential transactions" -> Disable the ability to turn off confidential transactions, hence confidential transactions (aka stealth - still in development) will be permanently possible in the future. + +## Example snapshot targets + +Here's a few examples of sharedrop targets off the top of my head, do you have an unique idea for a sharedrop target or are you interested in any of the following? Post a reply! + +### Bitcoin + +* "Fast Bitcoin United" & "Light speed bitcoin" UIA names have been recently registered by Cryptonomex. It's likely that since FBTC has a website it's the UIA to keep an eye on. + +### Combined Top-k cryptos + +So if we can produce a snapshot for BTC, then we can produce one for every BTC fork/alt (of which there are thousands). If we can produce many individual snapshots then we could easily combine them, attempting to recruit the collective userbases from the included top-k crypto networks. + +The non-btc forks (own codebase & address/account/public-key structure) will need some snapshot process modification, but the end result should be the same. + +### ICOs + +If an ICO has an entirely public record of donators, including the addresses they donated tokens from, then we could scrape the required information (Address & balance) to produce a sharedrop against the ICO participants. + +ICO participants are incredibly diverse and are investors by nature (not miners), so they are perfect for introducing to the Bitshares DEX. + +Take the EOS ICO for example, let's scrape their public ICO records and sharedrop an UIA for them on the BTS DEX, far cheaper than the BTS DEX buying EOS to get the Bitshares name infront of the entire EOS community. + +The snapshot files produced by an ICO are likely significantly smaller than estimated 3GB+ BTC snapshot file. + +We could likewise combine multiple ICO snapshot targets in the one UIA sharedrop. + +### Non-crypto targets + +If you're able to link a scrapable public key to an account & a rank/score then you can base an UIA distribution against it, as long as the bitshares client supports importing such a public key. + +Think rewarding long established userbases on github, citizen science portals, BOINC projects, etc. + +## Entrepeneureal opportunities + +* If you create a dedicated website for your sharedropped asset, you can provide your website's visitors a referral link to multiple web wallet, potentially massively inflating your referral statistics & gaining a large percentage of fees for years to come. +* If you succeed in sharedropping an UIA & attract a significant amount of users to the BTS DEX, you are likely to do well in the Billion hero challenge if you participate. +* Once the sharedrop has been performed and UIA owernship rights have been transfered either to null or to the committee, the UIA issuer is free to buy said UIA tokens on the market (from provably legitimate sharedrop claimants). The likely initial state of the markets will be that it is traded at a very low value, as users who hold Bitcoin who personally dislike Bitshares will probably dump the coins on the market; we saw this behaviour with Bitcoin Cash where it dropped to below $200 then a week later it was worth about $1000, so it's likely going to have a volatile trading value at least at the start of its lifetime. + +## BTS Comparison to BTC forks + +| | Bitcoin Core | Segwit2x | BitcoinCash (BCH) | Bitshares UIA | +| :------------: | :------------: | :------------: | :------------: | :------------: | +| Block Size | 1mb | 2mb? | 8mb | 128KB | +| TPS* | 6-7 | 12? | 56 | 10,000+ | +| Block timing | 10m | 10m | 10m |3s | +| Avg fee | Very high | High | Low |Very Low | +| Consensus mechanism | POW | POW | POW | DPOS | +| Inbuilt DEX* | ✘ | ✘ | ✘ |✔ | +| Energy Efficient | ✘ | ✘ | ✘ | ✔ | +| Inbuilt Stealth | ✘ | ✘ | ✘ | Soon! | +| Inflationary | ✔ | ✔ | ✔ | ✘ | + +## Genesis.json comparisons + +| | Filesize | Sharedrop recipients | +|---|---|---| +| BTS0.9x | 22.5 MB | PTS/AGS holders | +| PTS-DPOS | 2.94 MB | PTS holders | +| BTS 2.0 | 35.9 MB | PTS/VOTE/DNS/(AGS?) holders | +| Peerplays | 5.16 MB | PEERPLAYS, BTS, Misc-BTS-Assets, BTS collateral holders + BTC Donators | +| Decent | 13.7 KB | Decent team | +| Fast Bitcoin United | 3.5GB ??? | BTC (1st Aug) holders | +| Golos | 10.3MB | Steem holders | + +## Negatives of introducing this functionality + +* A standardized and well documented external-crypto -> graphene snapshot/sharedrop process may see clones of BTS/STEEM/PPY (etc..) with an initial core asset distribution based on one or many external cryptocurrencies. That said, the original blockchains have funding, integrated services and are well established (A fork shouldn't be of serious concern). +* The process of handling private keys for import is risky if these keys are intercepted during the snapshot claiming process. If a malicious entity phishes the private keys imported into a malicious web wallet, then the reference blockchain funds would be at risk unless the funds had already been moved. An advantage of unspendable UXTO (balance smaller than minimum reference network fee) is that even if the keys were stolen, the original couldn't move (haha!). + +## Advantages of sharedropping an BTC [UIA](http://docs.bitshares.eu/bitshares/user/uia.html) on the BTS DEX + +* Far greater capacity, scalability and speed than the 3 forks of Bitcoin combined! (7-30 TPS vs 10k+ TPS & 10m block times vs 3 sec block times!) +* If we do not issue the tokens remaining to be mined (21m total planned) then the [BTC](https://bitcoin.org/) [UIA](http://docs.bitshares.eu/bitshares/user/uia.html) would not be inflationary in comparison to the 3 forks, better for existing holders. +* Far reduced network consensus environmental pollution/harm - DPOS vs POW. +* Running a Bitshares web wallet or light client does not require downloading the entire blockchain. +* [BTC](https://bitcoin.org/) services which integrate Bitshares will have access to not just the [BTC](https://bitcoin.org/) [UIA](http://docs.bitshares.eu/bitshares/user/uia.html) but to the entire [BTS DEX](https://bitshares.org/) (increased usage of MPAs). +* Ability to trade the [BTC](https://bitcoin.org/) token in a decentralized manner within the client against any other token with no middlemen (besides potentially gateways). +* Users with holdings in addresses smaller than the current average network transfer fee on the bitcoin network will be able to move these funds once imported on the [BTS DEX](https://bitshares.org/), as network fees are very small! +* Providing this option to all [BTC](https://bitcoin.org/) holders will potentially recruit a significant number of users to the [BTS DEX](https://bitshares.org/). +* No need for further BTC development nor network maintenance, no need to worry about centralized POW risks in the future. + +## Visualization of UIA sharedrop process + +The Bitshares starship drops out of hyperspace in planet Bitcoin's orbit, the crust is collapsing into itself as the various militarized mining corporations have bored the planet hollow to the detriment of their workers. We stretch our transporter to maximum capacity to make a backup of every Bitcoin inhabitant on our starship just as the planet is destroyed. A mirror image of the Bitcoin inhabitants will peacefully live on without their mining professions, riding the Bitshares starship off into the cosmos at light speed! + +--- + +# Summary for Shareholders + +* This will potentially require a worker proposal to cover cost of development unless cryptonomex develops & documents a solution for the network as part of their upcoming [FBTC](http://fastbitcoinunited.com/) project. +* Will require a hard fork for implementation which could potentially cause temporary network disruption. +* If genesis data requires significant storage from witnesses then this may cause the witnesses to request higher block rewards. + +# Copyright + +This document is placed in the public domain, 100% open source & should be considered MIT licensed. + +# See Also + +N/A \ No newline at end of file diff --git a/BSIP-0024.md b/BSIP-0024.md new file mode 100644 index 0000000..53a0f9a --- /dev/null +++ b/BSIP-0024.md @@ -0,0 +1,69 @@ + BSIP: BSIP-0024 + Title: Locking Bitshares away as 'Bitshares Influence' for voting privileges on the BTS DEX + Authors: [Customminer](https://steemit.com/@cm-steem/), Taconator, jcalfee. + Status: Draft + Type: Protocol + Created: 29/08/2017 + Discussion: https://github.com/bitshares/bsips/issues/28#issuecomment-324512215 https://steemit.com/bitshares/@officialfuzzy/bitshares-hangout-35-2017-08-25-opensource-agenda-whaleshare-beyondbit-payouts-powered-by-sp#@taconator/re-officialfuzzy-bitshares-hangout-35-2017-08-25-opensource-agenda-whaleshare-beyondbit-payouts-powered-by-sp-20170825t120002506z https://steemit.com/bitshares/@cm-steem/draft-bsip-0024-locking-bitshares-away-as-bitshares-influence-for-voting-privileges-on-the-bts-dex + Replaces: N/A + Superseded-By: N/A + Worker: N/A + +# Abstract + +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: (user_influence/total_influence)*total_coin_supply +* B: user_influence + +'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. + +# See Also + +N/A \ No newline at end of file diff --git a/README.md b/README.md index eebd4c2..13c9419 100644 --- a/README.md +++ b/README.md @@ -33,4 +33,6 @@ Number | Title | [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 \ No newline at end of file +[22](bsip-0022.md) | Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network | Customminer | Protocol | Draft +[23](bsip-0023.md) | Sharedropping an UIA against an external cryptocurrency distribution snapshot | Customminer | Protocol | Draft +[24](bsip-0024.md) | Locking Bitshares away as 'Bitshares Influence' for voting privileges on the BTS DEX | Customminer | Protocol | Draft \ No newline at end of file diff --git a/bsip-0019.md b/bsip-0019.md index 546a18a..91f6da9 100644 --- a/bsip-0019.md +++ b/bsip-0019.md @@ -1,7 +1,7 @@ BSIP: #019 Title: Introducing profit-sharing/dividends to Bitshares (MPA only) - Authors: Customminer + Authors: [Customminer](https://steemit.com/@cm-steem/) Status: Draft Type: Protocol Created: 2017-06-18 diff --git a/bsip-0020.md b/bsip-0020.md index 2546164..b3f3418 100644 --- a/bsip-0020.md +++ b/bsip-0020.md @@ -1,6 +1,6 @@ BSIP: #020 Title: Introducing profit-sharing/dividends to Bitshares (UIA only) - Authors: Customminer + Authors: [Customminer](https://steemit.com/@cm-steem/) Status: Draft Type: Protocol Created: 2017-06-26 diff --git a/bsip-0021.md b/bsip-0021.md index 7648e54..ee77bdf 100644 --- a/bsip-0021.md +++ b/bsip-0021.md @@ -1,6 +1,6 @@ BSIP: #021 Title: Introducing the 'Coin-Age' statistic to Bitshares assets - Authors: Customminer + Authors: [Customminer](https://steemit.com/@cm-steem/) Status: Draft Type: Protocol Created: 2017-07-03 diff --git a/bsip-0022.md b/bsip-0022.md index 29f2ab6..9cfa195 100644 --- a/bsip-0022.md +++ b/bsip-0022.md @@ -1,6 +1,6 @@ BSIP: 0022 Title: Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network - Authors: Customminer + Authors: [Customminer](https://steemit.com/@cm-steem/) Authors of relevant BSIP-0005: Daniel Larmier Fabian Schuh Status: Draft