Adding placeholders for remaining Stealth BSIPs to README.md

BSIP44: Hashed Timelock Contract

README.md

@@ -33,15 +33,27 @@ Number             | Title                                                    |
 [23](bsip-0023.md) | Sharedropping an UIA against an external cryptocurrency distribution snapshot        | Customminer       | Protocol       | Draft
 [24](bsip-0024.md) | Locking Bitshares away as 'Bitshares Influence' for voting privileges on the BTS DEX       | Customminer       | Protocol       | Draft
 [25](bsip-0025.md) | Transaction Flat-Rates with Weighted Rate-Limitation     | Fabian Schuh | Protocol | Draft
-[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
+[26](bsip-0026.md) | Refund Order Creation Fee in Originally Paid Asset on Cancel | Abit More | Protocol | Installed
+[27](bsip-0027.md) | Asset Issuer Reclaim Fee Pool Funds                          | Abit More | Protocol | Installed
 [28](bsip-0028.md) | Worker Proposal Improvements                                 | Bill Butler | Protocol | Draft
-[29](bsip-0029.md) | Asset issue change to require owner authority                | Fabian Schuh | Protocol | Accepted
-[30](bsip-0030.md) | Always Allow Increasing Collateral Ratio If Debt Not Increased | Abit More | Protocol | Accepted
-[31](bsip-0031.md) | Update Short Position's Margin Call Price After Partially Called Or Settled | Abit More | Protocol | Accepted
-[32](bsip-0032.md) | Always Match Orders At Maker Price                                          | Abit More | Protocol | Accepted
-[33](bsip-0033.md) | Maker Orders With Better Prices Take Precedence                             | Abit More | Protocol | Accepted
-[34](bsip-0034.md) | Always Trigger Margin Call When Call Price Above Or At Price Feed           | Abit More | Protocol | Accepted
-[35](bsip-0035.md) | Mitigate Rounding Issue On Order Matching                                   | Abit More | Protocol | Accepted
-[36](bsip-0036.md) | Remove expired price feeds on maintenance interval                          | oxarbitrage | Protocol | Accepted
-[37](bsip-0037.md) | Allow new asset name to end with a number                                   | oxarbitrage | Protocol | Accepted
+[29](bsip-0029.md) | Asset issue change to require owner authority                | Fabian Schuh | Protocol | Installed
+[30](bsip-0030.md) | Always Allow Increasing Collateral Ratio If Debt Not Increased | Abit More | Protocol | Installed
+[31](bsip-0031.md) | Update Short Position's Margin Call Price After Partially Called Or Settled | Abit More | Protocol | Installed
+[32](bsip-0032.md) | Always Match Orders At Maker Price                                          | Abit More | Protocol | Installed
+[33](bsip-0033.md) | Maker Orders With Better Prices Take Precedence                             | Abit More | Protocol | Installed
+[34](bsip-0034.md) | Always Trigger Margin Call When Call Price Above Or At Price Feed           | Abit More | Protocol | Installed
+[35](bsip-0035.md) | Mitigate Rounding Issue On Order Matching                                   | Abit More | Protocol | Installed
+[36](bsip-0036.md) | Remove expired price feeds on maintenance interval                          | oxarbitrage | Protocol | Installed
+[37](bsip-0037.md) | Allow new asset name to end with a number                                   | oxarbitrage | Protocol | Installed
+[38](bsip-0038.md) | Add target collateral ratio option to short positions                       | Abit More | Protocol | Installed
+[39](bsip-0039.md) | Automatically approve proposals by the proposer                             | Fabian Schuh | Protocol | Draft
+[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
+50                 | Stealth development, Phase II                                               | Christopher Sanborn | Informational | Draft
+51                 | New operations for Confidential Asset (CA) transactions                     | Christopher Sanborn | Protocol | Draft
+52                 | Ring signatures for untraceability of Stealth transactions                  | Christopher Sanborn | Protocol | Draft
+[53](bsip-0053.md) | Blockchain scanning for inbound Stealth transactions                        | Christopher Sanborn | Protocol | Draft
+54                 | Deterministic addresses for Stealth wallets                                 | Christopher Sanborn | Informational | Draft
+55                 | Metadata hiding via Garlic Routing and other means                          | Christopher Sanborn | Informational | 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-0026.md

@@ -1,7 +1,7 @@
     BSIP: 0026
     Title: Refund Order Creation Fee in Originally Paid Asset on Cancel
     Authors: Abit More <https://github.com/abitmore>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2017-10-16
     Discussion: https://bitsharestalk.org/index.php/topic,25153.0.html

bsip-0027.md

@@ -2,7 +2,7 @@
     Title: Asset Issuer Reclaim Fee Pool Funds
     Authors: Abit More <https://github.com/abitmore>
              Fabian Schuh <Fabian@BitShares.eu>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2017-11-02
     Discussion: https://github.com/bitshares/bitshares-core/issues/188

bsip-0029.md

@@ -1,7 +1,7 @@
     BSIP: 0029
     Title: Asset issue change to require owner authority
     Authors: Fabian Schuh <Fabian.Schuh@blockchainprojectsbv.com>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-01-28
     Discussion: https://github.com/bitshares/bitshares-core/issues/199

bsip-0030.md

@@ -1,7 +1,7 @@
     BSIP: 0030
     Title: Always Allow Increasing Collateral Ratio If Debt Not Increased
     Author: Abit More <https://github.com/abitmore>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-16
     Discussion: https://github.com/bitshares/bitshares-core/issues/583,

bsip-0031.md

@@ -1,7 +1,7 @@
     BSIP: 0031
     Title: Update Short Position's Margin Call Price After Partially Called Or Settled
     Author: Abit More <https://github.com/abitmore>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-16
     Discussion: https://github.com/bitshares/bitshares-core/issues/343,

bsip-0032.md

@@ -1,7 +1,7 @@
     BSIP: 0032
     Title: Always Match Orders At Maker Price
     Author: Abit More <https://github.com/abitmore>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-16
     Discussion: https://github.com/bitshares/bitshares-core/issues/338

bsip-0033.md

@@ -1,7 +1,7 @@
     BSIP: 0033
     Title: Maker Orders With Better Prices Take Precedence
     Author: Abit More <https://github.com/abitmore>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-17
     Discussion: https://github.com/bitshares/bitshares-core/issues/625,

bsip-0034.md

@@ -1,7 +1,7 @@
     BSIP: 0034
     Title: Always Trigger Margin Call When Call Price Above Or At Price Feed
     Author: Abit More <https://github.com/abitmore>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-18
     Discussion: https://github.com/bitshares/bitshares-core/issues/606

bsip-0035.md

@@ -1,13 +1,13 @@
     BSIP: 0035
     Title: Mitigate Rounding Issue On Order Matching
     Author: Abit More <https://github.com/abitmore>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-19
     Discussion: https://github.com/bitshares/bitshares-core/issues/132,
                 https://github.com/bitshares/bitshares-core/issues/184,
                 https://github.com/bitshares/bitshares-core/issues/342
-    Replaces: -
+    Superseded-By: 0038 (partly)
     Worker: 1.14.96
 
 # Abstract
@@ -261,7 +261,8 @@ The detailed rules proposed by this BSIP with new rules highlighted:
    amount remaining), check the remaining amount, if the amount is too small
    so the order would receive nothing on next match, cancel the order.**
 
-  * When matching a limit order with a call order,
+  * When matching a limit order with a call order (**note: this rule has changed
+ in [BSIP 38](bsip-0038.md)**),
     * **if the call order is receiving the whole debt amount, which means it's
    smaller and the short position will be closed after the match, round up its
    paying amount; otherwise,** round down its paying amount.
@@ -371,12 +372,12 @@ Assuming both orders are limit orders, they'll be processed as follows:
 * If Alice's order is maker, use `$3 / 80` as match price; since Alice's order
   is smaller, round in favor of Bob's order, so Alice will get
   `round_down(50 CORE * $3 / 80 CORE) = round_down($1.6) = $1`,
-  and Bob will get `round_up($1 * 80 CORE / $3) = round_up($26.67) = $27`,
+  and Bob will get `round_up($1 * 80 CORE / $3) = round_up(26.67 CORE) = 27 CORE`,
   the effective price would be `$1 / 27 = $0.037`;
 * If Bob's order is maker, use `$19 / 500` as match price; since Alice's order
   is smaller, round in favor of Bob's order, so Alice will get
   `round_down(50 CORE * $19 / 500 CORE = round_down($1.9) = $1`,
-  and Bob will get `round_up($1 * 500 CORE / $19) = round_up($26.3) = $27`,
+  and Bob will get `round_up($1 * 500 CORE / $19) = round_up(26.3 CORE) = 27 CORE`,
   the effective price would also be `$1 / 27 = $0.037`.
 
 # Specifications

bsip-0036.md

@@ -1,7 +1,7 @@
     BSIP: 0036
     Title: Remove expired price feeds on maintenance interval
     Author: oxarbitrage <https://github.com/oxarbitrage>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-22
     Discussion: https://bitsharestalk.org/index.php?topic=25996.0

bsip-0037.md

@@ -1,7 +1,7 @@
     BSIP: 0037
     Title: Allow new asset name to end with a number
     Author: oxarbitrage <https://github.com/oxarbitrage>
-    Status: Accepted
+    Status: Installed
     Type: Protocol
     Created: 2018-02-23
     Discussion: https://bitsharestalk.org/index.php?topic=25997.0

bsip-0038.md

@@ -0,0 +1,348 @@
+    BSIP: 0038
+    Title: Add target collateral ratio option to short positions
+    Author: Abit More <https://github.com/abitmore>
+    Status: Installed
+    Type: Protocol
+    Created: 2018-03-05
+    Discussion: https://bitsharestalk.org/index.php?topic=25924.0,
+                https://github.com/bitshares/bsips/issues/51
+    Replaces: 0035 (partly)
+    Worker: 1.14.100
+
+# Abstract
+
+When a short position is margin called, some of its collateral will be sold
+and some or all of its debt will be covered accordingly.
+
+However, usually more collateral will be sold, in comparison to the minimum
+amount required to be sold to maintain the maintenance collateral ratio (MCR)
+requirement.
+
+This BSIP proposes a protocol change to let shortes (borrowers) have control
+over selling how much collateral when being margin called.
+
+This BSIP depends on [BSIP 31](bsip-0031.md).
+
+# Motivation
+
+As discussed in [this forum
+post](https://bitsharestalk.org/index.php?topic=25924.0), current process gives
+manipulators big chance to short BTS and make money and increase the risk of
+black swan, thus hurts the BTS ecosystem. Many participants in the discussion
+agree that usually it's not really required to cover all debt (thus selling more
+collateral) when being margin called.
+
+After [BSIP 31](bsip-0031.md) is
+in place, shorters will have more chance to not cover all debt on margin call,
+but it's not 100% guaranteed, and they can only accept the result passively.
+
+# Rationale
+
+Different shorters have different expectations when being margin called:
+* some want to close their short positions completely to cut losses;
+* some want to sell as little collateral as possible to keep remaining short
+  positions as large as possible;
+* some want to sell more than minimum required collateral to reduce the
+  possibility of being margin called again in the near future, but don't
+  want to close their short positions completely.
+
+With a new "target collateral ratio" option, all these expectations can be met.
+
+In sections below, both a "margin call order" and a "call order" mean a short
+position in margin call territory.
+
+## The Definition of Target Collateral Ratio
+
+For reference purpose, the collateral ratio of any given debt/short position
+describes the ratio between the available collateral (e.g. core toke BTS) to
+the debt that is owed (e.g. CNY, etc.) by the original borrower to the
+blockchain. It is defined to be a dimensionless value as
+`CR = collateral / (debt / feed_price)` where the price is measured in units of
+the debt asset / units of the collateral asset (e.g. `CNY / BTS`).
+
+"Target collateral ratio" is an optional value which can be set onto a short
+position, when the position being automatically liquidized (margin called),
+sell no more than required collateral until collateral ratio of the position
+is **higher than** this value.
+* Default value: not set, which means to sell as much collateral as possible,
+  which is same to current behavior.
+* When the value is set but below MCR, use MCR.
+* When matching a margin call order with a force settle order, ignore this
+  option.
+* When checking for black swan or globally settling, ignore this option.
+
+Why to use "higher than" but not "equal to", is due to an existing rule:
+if a short position's collateral ratio is equal to MCR, it will still be
+margin called.
+
+## The Math
+
+Let prices described below be in terms of `debt / collateral`,
+e.g. how much CNY per BTS.
+
+A margin call order can be matched with a limit order as either maker or taker,
+in any case, there would be a matching price. We can solve an equation as
+follows:
+
+```
+target_CR = new_collateral / ( new_debt / feed_price )
+          = ( collateral - max_amount_to_sell ) * feed_price
+            / ( debt - amount_to_get )
+          = ( collateral - max_amount_to_sell ) * feed_price
+            / ( debt - max_amount_to_sell * match_price )
+=>
+max_amount_to_sell = (debt * target_CR - collateral * feed_price)
+                     / (target_CR * match_price - feed_price)
+```
+
+The result is a rational number.
+
+Then, the maximum debt it wants to cover can be calculated as:
+
+```
+max_debt_to_cover = max_amount_to_sell * match_price
+```
+
+The result is a rational number as well.
+
+## Rounding on Maximums Calculation
+
+As described in [BSIP 35](bsip-0035.md), at last we need to convert the
+rational numbers to integers, so rounding is involved.
+
+### The first round
+
+When calculating maximum debt to cover, the goal is to go over the specified
+target but not go too far beyond.
+That said, if a short position got matched with a big limit order, after
+partially filled, its collateral ratio should be **just** higher than specified
+target collateral ratio.
+
+We may calculate like this: if `max_debt_to_cover` has no fractional component
+(e.g. 5.00 as opposed to 5.23), plus it by one Satoshi; otherwise, round it up.
+An effectively same approach is to round down then add one Satoshi onto the
+result:
+
+```
+max_debt_to_cover_int = round_down(max_debt_to_cover) + 1
+```
+
+With `max_debt_to_cover_int` in integer, `max_amount_to_sell_int` in integer
+can be calculated as:
+
+```
+max_amount_to_sell_int = round_up(max_debt_to_cover_int / match_price)
+```
+
+It's worth noting that we need to make sure the 2 integers always pair
+perfectly, they're either the full collateral amount and full debt
+amount, or have:
+
+```
+max_amount_to_sell_int == round_up(max_debt_to_cover_int / match_price)
+max_debt_to_cover_int  == round_down(max_amount_to_sell_int * match_price)
+```
+
+For `max_amount_to_sell_int` above, we can adjust `max_debt_to_cover_int` with:
+
+```
+max_debt_to_cover_int = round_down(max_amount_to_sell_int * match_price)
+```
+
+### Review the result
+
+Due to rounding, it's not guaranteed that selling more collateral will
+always result in higher collateral ratio on remaining call order.
+
+On one hand, it's not guaranteed that the pair of integers above will
+meet the requirements: after covered `max_debt_to_cover_int`, it's possible
+that collateral ratio of remaining order is still not higher than `MCR` or
+`target_CR`. In this case, the result is not acceptable. Generally, if we search
+upwards, we can find a new pair that meets the requirements, or hit the order's
+collateral or debt amount.
+
+On the other hand, no matter if the pair above meets the collateral ratio
+requirement, it's possible that there exists a smaller pair which meets the
+requirement. However, it's not easy to find a perfect pair. If we search
+downwards, it's not easy to decide when to stop; if we start from a smaller
+pair then search upwards, it's not easy to decide where to start.
+
+### Favor performance over accuracy
+
+Due to the difficulty mentioned above, in this BSIP we allow imperfect results,
+and don't describe or enforce how exactly to find better results.
+
+The first implementation should be made with efforts. It will become consensus
+after approved by stake holders via voting. It will then be in effect until
+changed or replaced with a new BSIP.
+
+Here are some guidelines about implementation.
+
+When searching upwards, usually the real working pair is not far away, but it's
+not guaranteed due to rounding. For better performance, it's not good to search
+by adding one Satoshi every time. Can use a divergence sequence or other
+sublinear-time algorithm, that means it's possible that some good data will be
+skipped which may result in impefect result.
+
+
+## Rounding on Order Matching, and Edge Cases
+
+Rounding rules about order matching are defined in [BSIP 35](bsip-0035.md).
+
+Generally, when two orders got matched, the order matching engine will favor
+the larger order while rounding.
+
+When a call order got matched with a limit order, if the call order has no
+`target_CR` option set but its debt is more than the limit order offered,
+or the call order has `target_CR` option set but `max_debt_to_cover_int`
+is more than the limit order offered, both means the call order is larger,
+according to the rounding rule, the call order's paid collateral will be
+rounded down, so its collateral ratio will increase after partially filled.
+
+If the call order has `target_CR` option set and is covering the whole "maximum
+debt to cover", to be fair, we should consider that part of call order to be
+smaller and favor the limit order while rounding, otherwise the limit order may
+suffer an overall loss.
+That means the call order will be partially filled and its paid
+collateral will be rounded up, in this case, if the call order's collateral
+ratio was not too low, usually, partially filling will still lead to an
+increase in collateral ratio.
+
+However, there are edge cases: if the call order's collateral ratio is already
+low, or its debt or collateral amount is tiny, rounding up paid collateral on
+partially filling will probably lead to a decrease in collateral ratio,
+in an extreme case it may even lead to a black swan event. This is against the
+intention of this BSIP. To solve this issue, if detected a decrease in
+collateral ratio when matching, we propose to ignore the `target_CR` option of
+corresponding call order, and re-evaluate the match.
+
+## The Revised Rounding Rules on Order Matching
+
+So the rule for matching a limit order with a call order will be revised as
+follows with new rules **in bold**:
+* if the call order is receiving the whole debt amount, which means it's
+smaller and the short position will be closed after the match, round up its
+paying amount;
+* **otherwise,**
+  * **if the call order has `target_collateral_ratio` set and is receiving the
+ maximum debt amount calculated with `target_collateral_ratio`, see the call
+ order as smaller, try to round up its paying amount;**
+    * **for edge cases, if the call order's collateral ratio would not increase
+   after being partially filled due to the round-up (which may even cause a
+   black swan event in an extreme scenario), see its `target_collateral_ratio`
+   as "not set" for this time, re-apply the filling rules for this match.**
+  * otherwise, the call order is larger, round down its paying amount.
+    * if the limit order would receive nothing, cancel it (it's smaller,
+   so safe to cancel);
+    * otherwise, calculate the amount that the limit order would pay as
+   `round_up(receiving_amount * match_price)`. After filled both orders,
+   if the limit order still exists, the remaining amount might be too small,
+   so cancel it.
+
+## When and How To Use the Option
+
+The `target_collateral_ratio` option can to be set, updated or cleared when
+creating or updating a short position. When doing so, other rules still apply,
+E.G. can't update a short position to have too small collateral ratio.
+
+For one account, different short positions (for different assets) can be set
+with different `target_collateral_ratio`.
+
+For one short position,
+
+* if want to close it completely to cut losses when being margin called,
+  * don't set or clear `target_collateral_ratio` option, because the option is
+   **optional** so can be unset or cleared;
+
+* if want to sell as little collateral as possible when being margin called,
+  to keep the remaining short position as large as possible,
+  * set `target_collateral_ratio` to `MCR` or less;
+
+* if want to sell more than minimum required collateral when being margin
+  called, to reduce the possibility of being margin called again in the near
+  future, but don't want to completely close the short position,
+  * set `target_collateral_ratio` to a value higher than `MCR`, E.G. `300%`.
+   The higher the value is, the more collateral will be listed for sale when
+   it's margin called.
+
+
+# Specifications
+
+## `call_order_object`
+
+The `call_order_object` stores current status of a short position.
+
+Need to add a new field into it:
+
+* `optional<uint16_t> target_collateral_ratio;`
+
+Same to other collateral ratios, the actual ratio is the value divided by
+`GRAPHENE_COLLATERAL_RATIO_DENOM` aka `1000`.
+
+Due to the `uint16_t` data type, the new field's maximum value is `65535`,
+which means `6553.5%`.
+
+## `call_order_update_operation`
+
+The `call_order_update_operation` is used to open, update and close short
+positions. It contains an `extensions` field:
+
+* `extensions_type     extensions;`
+
+Need to override data type of this field so it can include the new "target
+collateral ratio" option.
+
+## `call_order_update_evaluator`
+
+The `call_order_update_evaluator` is used to evaluate and apply the
+`call_order_udpate_operation`. Need to add logic:
+* only allow `target_collateral_ratio` to be set after the hard fork;
+* set/update/clear `target_collateral_ratio` field of `call_order_object`
+  accordingly. Specifically,
+  * set or update the field if it presents in the operation and is valid,
+  * clear the field if it doesn't present in the operation or is not valid.
+
+## `proposal_create_evaluator`
+
+The `proposal_create_evaluator` is used to evaluate and apply the
+`proposal_create_operation`, which can contain zero or more
+`call_order_udpate_operation` objects. Need to add logic:
+* only allow `target_collateral_ratio` to be set after the hard fork.
+
+## Call Order Matching and Filling
+
+After a call order get matched with a limit order and about to fill,
+* if `target_collateral_ratio` is not set, process as before;
+* if `target_collateral_ratio` is set, compare it to `MCR`, use the bigger
+  one (aka `max(target_collateral_ratio,MCR)`) to calculate maximum amount of
+  debt to cover according to the equation described above, and apply the
+  revised rounding rules, then process other logic as before.
+
+## UI/UX
+
+The new option need to be presented and can be used in UI after the hard fork.
+
+When there are call orders to be filled, if `target_collateral_ratio` option
+is set, UI need to show exact amount of collateral that another trader is able
+to buy and exact amount of debt that need to pay according to the equation
+described above. Note that this calculation will need to use the current `feed_price`.
+
+# Discussion
+
+With this BSIP, we provided a tool that can be used by shorters to keep their
+positions, however, it's not always the best strategy to keep as large position
+as possible, sometimes it's even more risky than just cutting losses.
+Nevertheless, how to use the tool, is up to the traders to decide.
+
+# Summary for Shareholders
+
+"This is how it should work."
+
+# Copyright
+
+This document is placed in the public domain.
+
+# See Also
+
+* https://bitsharestalk.org/index.php?topic=25924.0
+* https://github.com/bitshares/bsips/issues/51

bsip-0039.md

@@ -0,0 +1,71 @@
+    BSIP: 0039
+    Title: Automatically approve proposals by the proposer
+    Authors: Fabian Schuh <https://github.com/xeroc>
+             Abit More <https://github.com/abitmore>
+    Status: Draft
+    Type: Protocol
+    Created: 2018-03-20
+    Discussion: https://github.com/bitshares/bitshares-core/issues/138
+    Worker: <Id of worker proposal>
+
+# Abstract
+
+On the BitShares Blockchain, proposals allow to gather signatures for a
+multisignature-setup by means of on-chain approvals. In contrast to
+other blockchains, these proposals are actually stored on the blockchain
+and automatically executed once the required amount of approvals has
+been reached. This allows participants of a multisignature-setup to
+exchange insufficiently signed transactions easily.
+
+However, when creating a new proposal, the proposer needs to manually
+approve his operation afterwards. This is not only inconvenient, but
+also costs and additional operation and thus a fee.
+
+This BSIP recommends to have the proposer of a proposal automatically
+added as approved.
+
+# Motivation
+
+In the case of a simple 2-of-3 multisig-scheme, today's implementation
+forces us to have 3 operations stored on the blockchain: a) the proposal
+itself, and two approvals.
+
+The inconvenience and additional fee hinders adoption of this scheme and
+makes it unnecessary complicated.
+
+# Rational
+
+By proposing an action, the proposer can be considered as an agreeing
+party, otherwise the proposal wouldn't have been created in the first
+place.
+
+If the proposer is not part of the multisig-setup, having him approve
+the proposal automatically does affect the validity of the proposal
+itself.
+
+# Specifications
+
+This BSIP comes with only minimal modifications that, however, change
+the behavior of the protocol and thus need a protocol upgrade.
+
+The change is implemented in such a way that the `fee_paying_account`
+for the proposal is added to the `available_active_approvals` of the
+proposal after creation.
+
+# Discussion
+
+To be found in the forum - see link above.
+
+# Summary for Shareholders
+
+This BSIP proposes a minor modification that improves the process of
+using hierarchical account permissions and simplifies the use of
+multisig-setups with only minimal modifications.
+
+# Copyright
+
+This document is placed in the public domain.
+
+# See Also
+
+* https://github.com/bitshares/bitshares-core/issues/138

bsip-0040.md

@@ -0,0 +1,422 @@
+    BSIP: 0040
+    Title: Custom active permissions
+    Authors:
+      Stefan Schießl <https://github.com/sschiessl-bcp>
+    Contributors and Reviewers:
+      Alex Megalokonomos <https://github.com/clockworkgr>
+      Fabian Schuh <https://github.com/xeroc>
+      Abit <https://github.com/abitmore>
+      Peter Conrad <https://github.com/pmconrad>
+    Status: Draft
+    Type: Protocol
+    Created: 2018-07-25
+    Discussion: https://github.com/bitshares/bitshares-core/issues/1061
+    Worker: <Id of worker proposal>
+
+# Abstract
+
+Strengthening user security is one of the main factors to elevate BitShares. In light of recent 
+hacking and phishing attempts this becomes even more important. The need for a more sophisticated
+account security preceeded the idea for a finer-grained control of account permissions.
+We propose to add an additional authority to the account, called Custom Active (Permission). The
+permission contains a list of operationid-to-authority mappings that each grant access to the respective 
+operation as if it were the active permission of the account. Additionally, the arguments of said operation 
+can be restricted.
+
+For the non-technical reader the section Specification can be skipped.
+
+# Motivation 
+
+Any successfull hacking or phishing attempt on any of the web wallets that are powered by the
+BitShares Blockchain is bad publicity. The user needs to be educated in account security, and this BSIP
+aims to ensure all technical possibilities are met while being flexible to allow many use-cases. 
+
+With this BSIP any user can create additional keys with specific purpose (everything else is prohibited). We list some possibilities below:
+ - Witness Key: Only allows update signing key and publish price feed
+ - Trading Key: Only allows limit orders (arguments restricted to desired markets), update margin position and transfers (arguments restricted to certain accounts)
+ - Proposal Update Key: Approve proposals (2FA comes to mind)
+ - Faucet Key: Allow only to create accounts
+ - Withdrawal Key: Allow another account to transfer funds to himself
+ - Cold Storage Key: Only allow to move funds to the Hot Wallet
+ 
+The above list of named keys is nothing that is known to the backend as the backend should have an abstract implementation.
+ The UI could provide a button "Create Trading Key" that properly configures the respective custom active permission entry.
+
+Note: The user can still use the active authority just like used to, no change in existing behavior. The named keys only give an additional possibility. For example: The user can login the UI using the private key of such a named key. Then he only as access to the operations that this named key grants. He can still login with the existing password to gain full access (similar a local wallet can be created that only contains the named key).
+
+This BSIP will be split into parts that will be voted on separately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows stateful restrictions (e.g. allow market orders up to some amount for every month), Milestone 3 gives finer control of how to combine restrictions and Milestone 4 allows to set a number of allowed executions per authority (introduces an additional on-chain dependency). Milestone 2, 3 and 4 will be put up for voting if Milestone 1 proves successful.
+
+# Rationale
+
+Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, 
+an `authority` (just like with active permission) and `restrictions` than can be used to restrict arguments. 
+Furthermore, such a `custom active authority` is only valid in a specified time period (`valid_from` and `valid_to`). 
+When handling incoming signed transactions, the backend checks 
+for each operation if there is a `custom active authority` for any of its required accounts. Check for every required 
+account of the transaction if all its belonging operations have at least one positively matched `custom active authority` 
+(see Specifications for definition of "matching"), and if so behave as if the active authority of the corresponding account is present (recursive authorities are excluded, see Examples).
+
+# Specification
+
+All descriptions in this section are on a pseudo/prosa level and no recommendation how it can best be implemented or serialized. They are meant to facilitate the understanding. If anything in the looping process or order of evaluation is unsuitable for actual implementation, changes can be made accordingly as long the same functionality is achieved.
+
+Note: The impact of Milestone 4 is explained in its own subsection to not hinder the reading flow
+
+### Custom active permission and custom active authority
+
+A `custom active permission` contains a list of `custom active authorities` and looks like follows (in JSON-like/pseudo for clarification):
+```
+custom_active_permission = {
+    account_id,    // account that is assigned to this permission
+    authorities = list of custom_active_authority objects
+}
+custom_active_authority = {
+    enabled,                // status of this authority, true or false. true when created
+    valid_from,             // timestamp when this is active
+    valid_to,               // t