Merge branch 'master' into bsip-hashed-timelock-contract

This commit is contained in:
John M. Jones 2018-10-12 06:16:39 -05:00 committed by GitHub
commit 1e02050dcd
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
7 changed files with 116 additions and 10 deletions

View file

@ -50,3 +50,4 @@ Number | Title |
[40](bsip-0040.md) | Custom active permission | Stefan Schießl | Protocol | Draft
[42](bsip-0042.md) | Adjust price feed to influence trading price of SmartCoins | Abit More | Protocol | Draft
[44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Draft
[45](bsip-0045.md) | Introduce 'allow use as bitasset backing collateral' flag/permission to assets | Customminer | Protocol | Draft

View file

@ -107,7 +107,7 @@ for each asset_holder in coin_age_hashmap {
# Copyright
N/A - Consider this BSIP entirely open-source/MIT-licensed, I am not the originator of the concept of 'coin-age' (several proof-of-stake cryptocurrencies make use of coin-age for finding stakable coins).
This document is placed in the public domain.
# See Also
* [List account balances - Graphene documentation](http://docs.bitshares.org/api/database.html#id8)

View file

@ -119,7 +119,7 @@ Please do raise your concerns, propose improvements and engage in the BSIP creat
# Copyright
This document is placed in the public domain, 100% open source & should be considered MIT licensed.
This document is placed in the public domain.
# See Also

View file

@ -651,7 +651,7 @@ The Bitshares starship drops out of hyperspace in planet Bitcoin's orbit, the cr
# Copyright
This document is placed in the public domain, 100% open source & should be considered MIT licensed.
This document is placed in the public domain.
# See Also

View file

@ -62,7 +62,7 @@ Would there even be a difference in voting behaviour betwen the two? Perhaps it
# Copyright
This document is placed in the public domain, 100% open source & should be considered MIT licensed.
This document is placed in the public domain.
# See Also

View file

@ -1,18 +1,18 @@
BSIP: 0042
Title: Adjust price feed to influence trading price of SmartCoins
Author: Abit More <https://github.com/abitmore>
Status: Draft
Status: Up for voting
Type: Protocol
Created: 2018-08-22
Discussions: https://bitsharestalk.org/index.php?topic=26948.0
https://bitsharestalk.org/index.php?topic=26315.0
Worker: TBD
Workers: 1.14.118 (pro), 1.14.119 (con)
# Abstract
We here propose to dynamically adjust price feed in order to influence trading
price of smart coins to achieve tighter peg.
This BSIP is constantly evaluated in terms of being accepted or rejected,see the last section *Constant voting evaluation* for details.
# Motivation
To get mass adoption, it's better that the SmartCoins can peg to targets more
@ -153,13 +153,33 @@ Witnesses should make their own decisions on whether to set a hard limit and
how much should it be if need to set one, generally, to reduce impacts caused
by bugs.
It will be good to apply the change to bitCNY first, which has much better liquidity
than other smartcoins. After witnesses and community learned enough in the process
it can be also applied to bitUSD.
# Discussion
[To be added]
- https://bitsharestalk.org/index.php?topic=26948.0
- https://bitsharestalk.org/index.php?topic=26315.0
- https://bitsharestalk.org/index.php?topic=26966.0
# Summary for Shareholders
[To be added]
The peg of SmartCoin to the underlying asset is crucial to create trust for SmartCoin holders, in combination with a force settlement offset that is considered fair. This BSIP seeks to adress the issue of volatility with respect to the peg by allowing the witnesses to implement (within boundaries) their own price feed strategy that is targeted to uphold the peg and provide a fair force settlement offset.
This is a crucial intrusion into the open market mechanics and is thus not a strict directive to the witnesses, furthermore this BSIP is constantly evaluated, and if it becomes rejected (see the next section), witnesses are bound to return to the former price feed mechanisms.
# Constant voting evaluation
This BSIP has a pro and a con worker and has an ever evaluated state of accepted and rejected.
- **Accepted**:
The pro worker is active in terms of receiving payout from the reserve pool AND its votes surpass the con worker.
- **Rejected**:
The pro worker is NOT active (is not receiving funds from reserve pool) OR the votes of the con worker surpass the pro worker. If the pro worker expires, this BSIP is also considered rejected.
The earliest that this worker can become active is 7th September 2018.
# Copyright

85
bsip-0045.md Normal file
View file

@ -0,0 +1,85 @@
```
BSIP: 45
Title: Introduce 'allow use as bitasset backing collateral' flag/permission to assets
Authors: @grctest
Status: Draft
Type: Protocol
Created: 07/10/2018
Discussion: https://github.com/bitshares/bsips/issues/80
Replaces: N/A
Superseded-By: N/A
Worker: N/A
```
---
# Abstract
It's currently possible to impose new asset settings through MPA encapsulation without the permission of the backing asset's 'asset owner'.
This BSIP proposes to introduce a new asset permission/flag which enables the asset owner to enable|prevent MPA encapsulation.
# Motivation
By encapsulating an asset (UIA/EBA|MPA) within a new MPA, you can impose new asset settings upon the underlying asset, to the possible detriment of the backing asset's 'asset owner'.
# Rational
By providing asset owners this functionality, we can improve asset owner confidence in the finality of their configured asset settings.
# Specifications
## Create new 'allow use as backing collateral' flag/permission
Rather than create a system of inheriting permissions from backing collateral, a new flag/permission for 'allow use as MPA backing collateral' could simply prevent MPA encapsulation entirely at the discretion of the asset owner.
Existing assets which are currently configured as an bitasset's backing collateral would require this flag to be set default enabled (allowed). This couldn't be changed unless the bitasset reconfigured to an alternative backing collateral - impossible if supply is greater than 0.
Non applicable assets (PM & twice nested MPA) would prevent the flag from being enabled.
Existing assets currently not used as backing collateral could be set to disabled by default.
# Discussion
## Consequences of MPA encapsulation
* Removal/Bypassing of market fees (if enabled)
* Re-implementation of confidential transfers (if disabled)
* Evasion of whitelist/blacklist (both user & market lists)
* Preventing the issuer from transfering the asset back to themselves (Can't transfer backing collateral back to yourself)
* Remove backing asset issuer from transfer approval provess.
## Committee configuration
Should all smartcoins be allowed as bitasset backing collateral? Given that XCD already does this with bitUSD, I think it's appropriate. That said, not all committee owned bitassets are in a stable state (bitGOLD for example is in global settlement state right now).
## Enabling the flag grants permisson for all
Currently you can perform MPA encapsulation without involving the asset owner, this could introduce conflict between the two asset owners.
If the flag is enabled, that's an indication that the asset owner accepts any bitasset use case - you wouldn't need to seek explicit permission prior to creating experimental bitassets on the BTS DEX.
If it's disabled, that's a clear indication that the asset owner doesn't want it used as backing collateral.
## How to configure assets held by null-account?
It's possible that bitassets may be owned by null-account but remain operational, configuring default disabled would burn the possibility of encapsulation - if these assets exist then if possible should be set to enabled?
## Proposed UI changes
This flag could only work as long as no MPA has already selected the asset as its backing collateral; setting this as default disabled (not allowed) for newly created assets in the asset creation form could help prevent the asset being used as backing collateral without the user's knowledge.
---
# Summary for Shareholders
* Introduces new asset owner permissions.
* Helps mitigate negative MPA encapsulation consequences, improving gateway regulatory compliance capability?
* Given enabled flags could constitute advanced permission for MPA use case, there may be UIA backed MPA created which would contribute BTS fees to the reserve pool.
# Copyright
This document is placed in the public domain.
# See Also
N/A