agorise
/
bsips
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

New BSIP 29

bsip53
Fabian Schuh 2018-01-30 09:15:22 +01:00
parent 30477cb3ff
commit 54c1644310
3 changed files with 273 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
README.md
View File

@ -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

175
bsip-0025.md Normal file
View File

@ -0,0 +1,175 @@
BSIP: 00025
Title: Transaction Flat-Rates with Weighted Rate-Limitation
Authors: Fabian Schuh <Fabian.Schuh@blockchainprojectsbv.com>
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)

97
bsip-0029.md Normal file
View File

@ -0,0 +1,97 @@
BSIP: 0029
Title: Asset issue change to require owner authority
Authors: Fabian Schuh <Fabian.Schuh@blockchainprojectsbv.com>
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<account_id_type>& a )const
{ a.insert( issuer ); }
void get_required_active_authorities( flat_set<account_id_type>& 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).