agorise
/
bsips
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
bsips/bsip-0023.md

34 KiB
Raw Permalink Blame History 

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
    • 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 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) has been drawn to this concept already (http://fastbitcoinunited.com/ Assets: FBTC & 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" - This research paper by Joey Krug 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:

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

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.

We're interested in extracting the "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:

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:

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 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) -> BTS 2.0 (Graphene) genesis.json snippet:

This genesis file doesn't reference protoshares, rather BTS 0.9x balances. This is why users who want to redeem old PTS keys still need to import their key using the BTS 0.9x client before exporting key & importing to BTS 2.0.

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 (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 (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) perhaps due to issuance via mining, the Golos genesis data was easily found on Steemit 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:

Snapshot data inclusion in Bitshares network

The 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 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 used for snapshotting BTSX/PTS/DNS & sharedropping to BTS 2.0 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 MUSE private key import

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 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 UIA 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 services which integrate Bitshares will have access to not just the BTC UIA but to the entire BTS DEX (increased usage of MPAs).
  • Ability to trade the BTC 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, as network fees are very small!
  • Providing this option to all BTC holders will potentially recruit a significant number of users to the BTS DEX.
  • 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 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