Merge pull request #29 from BTS-CM/master

New BSIPs 23 & 24
2017-09-01 10:41:51 +02:00 · 2017-09-01 10:41:51 +02:00 · 5a6e0c9f0c
commit 5a6e0c9f0c
parent 13881e0aa8 67281019af
7 changed files with 733 additions and 4 deletions
--- a/BSIP-0023.md
+++ 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
--- a/BSIP-0024.md
+++ 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
--- a/README.md
+++ b/README.md
@ -34,3 +34,5 @@ Number             | Title                                                    |
 [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
 [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
--- 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
--- 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
--- 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
--- 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 <Telegram: @cmmob>
+    Authors: [Customminer](https://steemit.com/@cm-steem/)
    Authors of relevant BSIP-0005: Daniel Larmier <Dan@cryptonomex.com>
                              Fabian Schuh <Fabian@BitShares.eu>
    Status: Draft