Merge branch 'master' into bsip35

README.md

@@ -43,3 +43,5 @@ Number             | Title                                                    |
 [33](bsip-0033.md) | Maker Orders With Better Prices Take Precedence                             | Abit More | Protocol | Draft
 [34](bsip-0034.md) | Always Trigger Margin Call When Call Price Above Or At Price Feed           | Abit More | Protocol | Draft
 [35](bsip-0035.md) | Mitigate Rounding Issue On Order Matching                                   | Abit More | Protocol | Draft
+[36](bsip-0036.md) | Remove expired price feeds on maintenance interval                          | oxarbitrage | Protocol | Draft
+[37](bsip-0037.md) | Allow new asset name to end with a number                                   | oxarbitrage | Protocol | Draft

bsip-0036.md

@@ -0,0 +1,73 @@
+    BSIP: 0036
+    Title: Remove expired price feeds on maintenance interval
+    Author: oxarbitrage <https://github.com/oxarbitrage>
+    Status: Draft
+    Type: Protocol
+    Created: 2018-02-22
+    Discussion: https://bitsharestalk.org/index.php?topic=25996.0
+    Replaces: -
+    Worker: To be done
+
+# Abstract
+
+Currently, expired bitasset feeds remain in the blockchain forever. The only way to get them erased is if operation `update_feed_producers` is called with new publishers on the asset. At this call, and only at this case, old publisher feeds will be deleted from the blockchain. If this operation never occurs or if it occurs maintaining some or all of the same publishers feeds will not be removed.
+
+Some examples of this are the followings, where we can see feeds from 2015:
+
+- http://open-explorer.io/#/objects/2.4.9 - HKD
+- http://open-explorer.io/#/objects/2.4.21 - USD
+- http://open-explorer.io/#/objects/2.4.10 - RUB
+- etc.
+
+This BSIP proposes a protocol change to remove expired feeds at maintenance time.
+
+# Motivation
+
+Improve performance of the bitshares-core.
+
+
+# Rationale
+
+The proposed change only affects the feed price when the feed expiration time is increased. This rarely happens, if ever, so in practice the effect on pricing is negligible. The savings in performance however, is not.
+
+# Specifications
+
+As mentioned in the abstract feeds stay in the blockchain forever unless `asset_update_feed_producers_evaluator::do_apply` is called.
+
+The BSIP proposes to remove expired feeds at maintenance time by adding feed cleanup code at `db_main.cpp`.
+
+Solution is not that simple, `asset_update_bitasset_operation` can change `feed_expiration_time` and `minimum_feeds` required for the asset.
+
+If a feed is expired and the `feed_expiration_time` changes, expired feeds may became valid, similar if `minimum_feeds` (required to calculate the median) is increased, older feeds may became valid and used by the core market engine if available.
+
+This scenario actually happened in the past and that is the reason the change will fail unless a hardfork protection is added.
+
+## The proposed solution
+
+Goal is to remove expired feeds in a safe manner. To do this we need to keep current behavior before hardfork date and only remove feeds at maintenance intervals after the hardfork. This will allow the chain to synchronize and start the cleanup at a point where all the feeds are valid, safely being able to remove them an continue clean from that time on.
+
+This a permanent hardfork, code before hardfork date will work one way(current behavior) and after date new code will work different making the feed cleanup at maintenance times.
+
+Feed cleanup code will only be executed after proposed hardfork date, at the first maintenance interval after date old feeds will be removed, node will not be able to use them anymore as they will not be available in the database. 
+
+If `asset_update_bitasset_operation` is called before hardfork operation will be normal as it is currently is now.
+
+If `asset_update_bitasset_operation` is called after hardfork and increases the `minimum_feeds` while they are not enough feeds `update_median_feeds()` will set a null feed. This is current `asset_update_bitasset_operation`, no need to make any change in the operation.
+
+
+# Discussion
+
+https://bitsharestalk.org/index.php?topic=25996.0
+
+# Summary for Shareholders
+
+[to be added if any]
+
+# Copyright
+
+This document is placed in the public domain.
+
+# See Also
+
+* https://github.com/bitshares/bitshares-core/issues/518
+* https://github.com/bitshares/bitshares-core/pull/598

bsip-0037.md

@@ -0,0 +1,64 @@
+    BSIP: 0037
+    Title: Allow new asset name to end with a number
+    Author: oxarbitrage <https://github.com/oxarbitrage>
+    Status: Draft
+    Type: Protocol
+    Created: 2018-02-23
+    Discussion: https://bitsharestalk.org/index.php?topic=25997.0
+    Replaces: -
+    Worker: To be done
+
+# Abstract
+
+Currently, the bitshares-core do not allow asset creation that start or end with a numerical character. Creation of index style assets like `CRYPTO500` are not possible.
+
+This BSIP proposes a protocol change to allow number characters at the end of the created asset name.
+
+# Motivation
+
+Economical, enable more asset names to be created in the exchange.
+
+
+# Rationale
+
+No valid reason was found until now about why this is not allowed. The creation of index style assets will bring new business to the exchange.
+
+# Specifications
+
+Restriction in asset names are detailed in `asset_ops.cpp`:
+
+```
+/**
+ *  Valid symbols can contain [A-Z0-9], and '.'
+ *  They must start with [A, Z]
+ *  They must end with [A, Z]
+ *  They can contain a maximum of one '.'
+ */
+ ```
+ 
+ BSIP proposes to change third rule to:
+ 
+ `They must end with [A, Z0-9]`
+ 
+As file where the changes are needed(`asset_ops.cpp`) do not have access to the database, we are unable to use `head_block_time()` to create the hardfork guard.
+
+The process is more complicated and it is described as follows:(quote from @abit in github ticker: https://github.com/bitshares/bitshares-core/issues/620#issuecomment-364803143):
+
+"To make the change, need to loose the validation code in `asset_ops.cpp`, add a hard fork guard code with original rule to asset_evaluator to make sure no rule change before the hard fork, add corresponding hard fork guard code in proposal_evaluator. After hard fork, those hard fork guard code can be safely removed."
+ 
+# Discussion
+
+https://bitsharestalk.org/index.php?topic=25997.0
+
+# Summary for Shareholders
+
+[to be added if any]
+
+# Copyright
+
+This document is placed in the public domain.
+
+# See Also
+
+* https://github.com/bitshares/bitshares-core/issues/620
+* https://github.com/bitshares/bsips/issues/52