From 54c16443109c72f8b2fc9a8be0e8f85d88da512a Mon Sep 17 00:00:00 2001 From: Fabian Schuh Date: Tue, 30 Jan 2018 09:15:22 +0100 Subject: [PATCH] New BSIP 29 --- README.md | 1 + bsip-0025.md | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++ bsip-0029.md | 97 ++++++++++++++++++++++++++++ 3 files changed, 273 insertions(+) create mode 100644 bsip-0025.md create mode 100644 bsip-0029.md diff --git a/README.md b/README.md index 5b9c17c..91f3ea0 100644 --- a/README.md +++ b/README.md @@ -36,3 +36,4 @@ Number | Title | [26](bsip-0026.md) | Refund Order Creation Fee in Originally Paid Asset on Cancel | Abit More | Protocol | Accepted [27](bsip-0027.md) | Asset Issuer Reclaim Fee Pool Funds | Abit More | Protocol | Accepted [28](bsip-0028.md) | Worker Proposal Improvements | Bill Butler | Protocol | Draft +[28](bsip-0029.md) | Asset issue change to require owner authority | Fabian Schuh | Protocol | Draft diff --git a/bsip-0025.md b/bsip-0025.md new file mode 100644 index 0000000..89ad639 --- /dev/null +++ b/bsip-0025.md @@ -0,0 +1,175 @@ + BSIP: 00025 + Title: Transaction Flat-Rates with Weighted Rate-Limitation + Authors: Fabian Schuh + Status: Draft + Type: Protocol + Created: 2017-10-16 + Worker: T.B.D. + +# Abstract + +Blockchain technology currently depends upon transaction fees to prevent +spam. These fees suffer all of the known problems with +micro-transactions and prevent blockchains from being used for low-value +transactions, massive trading and high-rate market making. Truly +decentralized applications must offer users the *appearance* of free +transactions if they wish to compete with their centralized +alternatives. + +This document proposes a protocol upgrade to BitShares to introduce +rate-limitations for *fee-free* transactions. Since the BitShares +blockchain is entitled to be a profitable decentralized autonomous +company (DAC), making use of *fee-free* transactions comes at a +*monthly* fixed cost as well as the option to lock shares away in a +vesting balance in order to increase the standard rate at which users +may interact with the blockchain. + +# Motivation + +Blockchains are decentralized networks where all transactions are +broadcast to all peers. Every so often a block is produced that includes +some or all of the pending transactions. All blockchains must find a +solution to prevent malicious users from consuming all of the available +network capacity with worthless transactions. These worthless +transactions can prevent other valuable transactions from being +processed and ultimately destroy the network. + +The solution adopted by most blockchains thus far is to charge a minimum +transaction fee. A fee worth just a few cents is enough to make +attacking the network expensive and unprofitable. While this approach +solves the spam problem, it introduces new problems. + +Market making as well as micro-transactions are a highly competitive +market. Being *decentralized* and *trust-less* alone, does not make the +BitShares blockchain a good competitor when compared to centralized +services. + +Despite blockchain transactions being cheaper *technically*, the fee +that is attached to each and every transaction on BitShares results in +some crucial businesses to be unviable, such as **market making** at +scale, where dozens of orders are created (and canceled) continuously, +in order to provide liquidity to the markets. + +# Rational + +In this proposal, we extend the BitShares fee model to allow +transactions made by accounts to go through without paying a fee. We +require accounts to be lifetime members to harness a **transaction +flat-rate** with certain limits that can be raised by additionally +providing BTS (units of the core asset) in a vesting balance that is +locked away for a certain amount of time, only do be made liquid in +weekly chunks over the whole period. + +## Full Reserve vs Fractional Reserve + +Let's view a blockchain like an Internet Service Provider (ISP) co-op +which owns all of the cables in the town and can process a maximum +amount of data transmission on those cables at any time. This is called +*the capacity* of the transmission lines. People living in the town can +buy shares in the ISP and obtain the right to utilize a portion of the +available capacity. + +The ISP has two choices and can either run a **full reserve** or +**fractional reserve** system. + +* Under a full reserve system each user is only allowed a fraction of + the capacity proportional to her shares. Because not everyone uses + the Internet at the same time, the town's network would be significantly + underutilized. +* Under a fractional reserve system the individual users could utilize + more date rate than they are entitled to at any given point in time so + long as not everyone uses the Internet at the same time. + +The problem with operating a fractional reserve is that congestion +occurs anytime too many people wish to use the network at the same time. +The ISP needs a way to prioritize transmissions during congested +periods. In the most extreme case, a fully congested network must revert +to a full reserve system. + +The challenge is setting the proper fractional reserve ratio or +implement a **dynamic fractional reserve ratio**. Under this model the +blockchain will +automatically adjust the reserve ratio for the network during times of +congestion. The blockchain will set a target utilization that leaves +enough headroom for short term surges in demand. Any time the surges +are sustained the blockchain reduces the maximum rate-per-share. +When a surge is over and there is surplus capacity the blockchain can +slowly increase the rate-per-share. + +If the time window for this control cycle is stretched too far then the +reserve ratio will not adjust fast enough to respond to short-term +surges, if the window is too short then clustering usage will have too +big of an impact on normal users. + +In our estimate it should be sufficient to measure the average weekly +transaction rate usage of users. This parameter will be changeable by +the BitShares committee. The advantage with this approach is, that the +BitShares committee can define whether they prefer a dynamic fractional +reserve, where occasional uses may transact more often within a very +short period of time, or a simple and static method, where professional +users get an easy picture of how many transactions they may produce in a +certain amount of time. + +## Flat-Rate Model + +In recent years, ISP providers have seen a shift in their own economics +leaving the *pay-per-use* (e.g. per minute) service domain where users +paid for a duration they occupied a land-line to go for a +*pay-per-serice* flat-rate model where users paid a fixed fee to enable +a specific service to be used for free within certain conditions (e.g. +data volume). With the improvements in communications technology, land +lines got replaced by fiber which can carry significantly more load. +Thus the flat-rate model makes sense from business perspective. + +The same holds true for blockchain technologies. The Graphene framework +is capable of incomparable transaction loads and thus, the individual +transaction may not be tagged with a fee for the profit alone, but +merely to prevent spam. A full reserve system gives value to a +transaction processing capabilities of the blockchain which everyone can +own a share of to prevent spam. + +## Flat-Rate with Weighted Rate-Limitation + +That said, we here propose a combination of the flat-rate model with a +stake-weighted limitation of transaction rates. + +* **Flat-Rate**: A new feature is added to the blockchain that enables + the flat-rate model with a basic transaction rate that can be defined + by the BitShares committee (e.g. 10 transactions per day). This + operation costs a fee and lasts for a committee-parameterized amount + of time (e.g. 30 days). These rates are the same for every single user + that has bought the flat-rate subscription. + +* **Stake-Weighting**: Since some users may need more than the basic + amount of transactions per day, power users can increase the + implicitly assumed weight of 1x to a higher value by providing BTS + core tokens in a vesting balance locks them away for as long as the + subscription lasts. + +This ultimately gives the option to + +* pay a fee for every transaction (current system) +* pay for a flat-rate to transaction for fee within certain conditions +* powerup your account with core tokens to increase fee transaction + rate + +# Specifications + +* Do not refund order creation fee! +* Replace Annual Fee operation? + +# Discussion + +Todo + +# Summary for Shareholders + +Todo + +# Copyright + +This document is placed in the public domain. + +# See Also + +1. [Steem Whitepaper](https://steem.io/SteemWhitePaper.pdf) diff --git a/bsip-0029.md b/bsip-0029.md new file mode 100644 index 0000000..8e76517 --- /dev/null +++ b/bsip-0029.md @@ -0,0 +1,97 @@ + BSIP: 0029 + Title: Asset issue change to require owner authority + Authors: Fabian Schuh + Status: Draft + Type: Protocol + Created: 2018-01-28 + Discussion: https://github.com/bitshares/bitshares-core/issues/199 + Worker: + +# Abstract + +With the current design, the issuer of an asset can be changed with the +*active authority* alone. However, this authority is also required for +issuing new units of an asset/token. If this process wants to be +automated, an active key needs to be stored on an internet-connected +device. If compromised, an attacker can easily move the asset under his +control with no way to back. + +This proposal comes with two changes to the protocol: + +1. The current behavior of changing an assets' parameters will no longer + allow to change the issuer. +2. A new operation is introduced that allows to change the issuer of an + asset but requires the owner authority of the issuer to sign that + transaction. + +# Motivation + +Improve asset security. + +# Rational + +Assets should not be at risk while automating issuing of new units. + +# Specifications + +## Current Design and Implementation + +Currently, any asset can be updated with `asset_update_operation`. This +operation contains an optional `new_issuer` that changes the issuer of +the asset. + +## Proposed Changes + +# `asset_update_operation` + +The existing `asset_update_operation` will be modified in such that it +no longer allows the user of `new_issuer` after a hard fork. + +# `asset_update_issuer_operation` + +A new operation is added with the following construction + +``` + + struct asset_update_issuer_operation : public base_operation + { + struct fee_parameters_type {uint64_t fee = 20 * GRAPHENE_BLOCKCHAIN_PRECISION; }; + + asset fee; + account_id_type issuer; + asset_id_type asset_to_update; + account_id_type new_issuer; + extensions_type extensions; + + account_id_type fee_payer()const { return issuer; } + void validate()const; + + void get_required_owner_authorities( flat_set& a )const + { a.insert( issuer ); } + + void get_required_active_authorities( flat_set& a )const + { } + + }; +``` + +This new operation merely allows to change the issuer of an asset and +requires the owner authority (of the issuer account) to sign the +transaction. + +# Summary for Shareholders + +We here propose the addition of a new operation that improves security +of assets with respect to updating the issuer. This closes a long +existing problem that makes running automated issuing of units a +security issue since an attacker that obtains the keys can obtain full +control of an asset indefinitely. This proposal changes this behavior +and requires the owner to sign such change of issuer. + +# Copyright + +This document is placed in the public domain. + +# Sponsoring + +This worker proposal is proudly presented and sponsored by [Blockchain Projects BV](http://blockchainprojectsbv.com).