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

README.md

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

bsip-0021.md

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

bsip-0022.md

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

bsip-0023.md

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

bsip-0024.md

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

bsip-0042.md

@@ -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
+    Workers: 1.14.118 (pro), 1.14.119 (con)
-                 https://bitsharestalk.org/index.php?topic=26315.0
-    Worker: TBD
 
 # 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
 

bsip-0045.md

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