BitShares 2.0, Graphene & Cryptonomex

After much discussion with those in the BitShares community over the licensing terms of Graphene and BitShares 2.0, Cryptonomex has decided to take the following actions:

• All code as of June 1, 2015 will be released under the CC0 1.0 Universal license (https://creativecommons.org/publicdomain/zero/1.0/legalcode)
• All future work performed by Cryptonomex will be a derivative owned by Cryptonomex, Inc and will be licensed for use with BitShares under the BSD 3 clause license (http://opensource.org/licenses/BSD-3-Clause) where BitShares shall refer to a single logical blockchain regardless of how many side-chains it may add in the future.    Rights to use the work for any other blockchain are reserved to Cryptonomex, Inc.
• All future additions to BitShares will be licensed by their respective authors according to the terms laid out in their individual worker proposals.

Cryptonomex will continue to propose upgrades to BitShares to be funded with stakeholder approval. In all such proposals Cryptonomex will retain the copyright on the work and license it for use with the BitShares blockchain under the BSD license.  All other uses for such future work will be reserved to Cryptonomex.

Cryptonomex has not accepted any funding from the Angel Shares donations made to Invictus.

Cryptonomex is committed to the long-term success of BitShares and will depend upon the BitShares community as much as the BitShares community depends upon us.   

Transfer fees will be $0.20 (my proposal)  but that doesn't mean ALL fees for ALL operations are the same.

Market Orders can charge just $0.01 to place and then charge $0.20 when they get matched and be free to cancel. 

Account registration (for cheap names) can be just $0.01.   

I just wanted to throw that out there because many people seem to think there is only one "Transaction Fee", when in reality these are the fees that can be configured now:

      uint32_t key_create_fee; ///< the cost to register a public key with the blockchain
      uint32_t account_create_fee; ///< the cost to register the cheapest non-free account
      uint32_t account_len8_fee;
      uint32_t account_len7_fee;
      uint32_t account_len6_fee;
      uint32_t account_len5_fee;
      uint32_t account_len4_fee;
      uint32_t account_len3_fee;
      uint32_t account_len2_fee;
      uint32_t account_premium_fee;  ///< accounts with premium names; i.e. @ref is_cheap_name returns false
      uint32_t account_whitelist_fee; ///< the fee to whitelist an account
      uint32_t delegate_create_fee; ///< fixed fee for registering as a delegate; used to discourage frivioulous delegates
      uint32_t witness_withdraw_pay_fee; ///< fee for withdrawing witness pay
      uint32_t transfer_fee; ///< fee for transferring some asset
      uint32_t limit_order_fee; ///< fee for placing a limit order in the markets
      uint32_t short_order_fee; ///< fee for placing a short order in the markets
      uint32_t publish_feed_fee; ///< fee for publishing a price feed
      uint32_t asset_create_fee; ///< the cost to register the cheapest asset
      uint32_t asset_update_fee; ///< the cost to modify a registered asset
      uint32_t asset_issue_fee; ///< the cost to modify a registered asset
      uint32_t asset_fund_fee_pool_fee; ///< the cost to add funds to an asset's fee pool
      uint32_t asset_settle_fee; ///< the cost to trigger a forced settlement of a market-issued asset
      uint32_t market_fee; ///< a percentage charged on market orders
      uint32_t transaction_fee; ///< a base price for every transaction
      uint32_t data_fee; ///< a price per 1024 bytes of user data
      uint32_t signature_fee; ///< a surcharge on transactions with more than 2 signatures.
      uint32_t global_parameters_update_fee; ///< the cost to update the global parameters
      uint32_t membership_annual_fee; ///< the annual cost of a membership subscription
      uint32_t membership_lifetime_fee; ///< the cost to upgrade to a lifetime member
      uint32_t withdraw_permission_update_fee; ///< the cost to create/update a withdraw permission
      uint32_t create_bond_offer_fee;
      uint32_t cancel_bond_offer_fee;
      uint32_t accept_bond_offer_fee;
      uint32_t claim_bond_collateral_fee;
      uint32_t file_storage_fee_per_day; ///< the cost of leasing a file with 2^16 bytes for 1 day
      uint32_t vesting_balance_create_fee;
      uint32_t vesting_balance_withdraw_fee;
      uint32_t global_settle_fee;
      uint32_t worker_create_fee; ///< the cost to create a new worker
      uint32_t worker_delete_fee; ///< the cost to delete a worker


Under BitShares 2.0 the "reserve fund" is just another way of looking at "burned funds".    The maximum spending rate has not changed.   Therefore the "available supply" is technically unchanged.   Except perhaps we could claim 3.7 Billion shares and pump coin market cap

Assuming no workers are hired and witnesses are paid $100 per month and there are 101 witnesses then the network is "burning" shares assuming we can sign up 101 life time members per month (3 per day). 

So under the new model revenue and growth should both be dramatically increased.   

Anyone that participated in the original referral program and converted at least 1 user to create an account prior to June 8th will get a free lifetime membership when we do the upgrade.

Since we are claiming BitShares can scale to 100,000 transactions per second I thought it would be fair to weigh in on what the Bitcoin core devs plan for scaling:

https://lightning.network/

I watched the video presentation of the slides and found the entire thing fascinating.  Here are my takeaways:

1. It functions a lot like a "collateralized" ripple network.  To make a payment you must find a route between the sender and receiver.
2. It requires "interactivity" and active participation of all links in the route, including the receiver.
3. It would reintroduce privacy to the blockchain.
3. While the simple example of  A->B->C->D appears to be simple enough where "B" and "C" are well known hubs.  If you replace A and D with 1000A's and 1000D's then the combinatoric complexity of the "un-broadcast transaction" between B and C can get rather large, especially when you consider all of the possible intermediate states.  B and C would probably end up setting up many parallel payment channels to prevent any one channel from becoming too complex. 
4. Even on the "lightning network" the time it would take to negotiate all of the handshakes and routing would be a second or more assuming nodes were distributed around the world. 

Their definition of scalability is:   7 billion people making 2 transactions per day each.   162,000 transactions per second.  50 Mbyte/sec "best case"

BitShares can handle that on a single computer at 20 Mbyte/sec which is well within reach of many data centers.  Internet2 can handle 12 Gigabyte per second bandwidth.

So here is my overall conclusion:

1) The Lightning Network would make an excellent currency if the complexity can be properly managed because it would be both fast and private.
2) To send a payment to an "offline" receiver would require hitting the blockchain. 
3) It will not work for markets on a blockchain
4) it would be "buggy" because long chains can have many failure points that end up "locking up funds" for longer than intended and would require some kind of reputation system due to the cost of opening a channel with a bad node. 
5) Economics of scale would drive most transactions through a small set of hubs because they can offer lower fees and have high reliability (no hangs waiting for a timeout).  These nodes would end up being like a 101 delegates and require much more than 50Mbyte/sec due to all of the handshaking required. 
6) While the number of transactions that end up hitting the blockchain will be fewer, the size of the transactions hitting the blockchain will be much larger.

At the end of the day, the Lightning Network will end up just as centralized as any other network due to pure economics. 

Conclusion:  a complex solution compared to BitShares approach that ultimately results in similar centralization and fees and is only fit for transfers.

No USD deposit fees for the next 2 months.

https://www.ccedk.com/bitusd-usd

Just curious why they are getting such a huge bump.