Merge pull request #251 from pmconrad/bsip-84a

Add retally_interval to BSIP-84

README.md

@@ -84,3 +84,4 @@ Number             | Title                                                    |
 [76](https://github.com/bitshares/bsips/issues/221) | Committee-Defined SmartAsset Collateral Threshold | Abit More | Informational | Draft
 [77](https://github.com/bitshares/bsips/issues/161) | Require Higher CR When Creating/Adjusting Debt Positions | Abit More | Protocol | Draft
 [81](https://github.com/bitshares/bsips/issues/229) | Simple Maker-Taker Market Fees | Abit More | Protocol | Draft
+[84](https://github.com/bitshares/bsips/issues/81) | Elections Based on non-Core Asset | Peter Conrad | Protocol | Draft

bsip-0084.md

@@ -17,7 +17,9 @@ This BSIP proposes changes that will enable elections based on dedicated assets.
 
 # Motivation
 
-The feature has been requested from independent businesses as well as from within the community. In addition, it paves the way for a to-be-proposed change to BitAsset governance, i. e. the decoupling of BitAsset management from blockchain governance.
+The feature has been requested from independent businesses as well as from within the community.
+
+It allows the definition of more fine-grained roles in any kind of governance, and offers the possibility to elect people with the specific knowledge required for specific tasks.
 
 
 # Rationale
@@ -28,7 +30,7 @@ BTS balances are affected by almost every operation, due to transaction fees. Th
 
 BTS is used in a multitude of ways, e. g. as collateral, as the counterpart in most active markets, as payment for workers and witnesses, as cashback for fees and so on. Contrarily, it is assumed that the primary purpose of the voting tokens will be voting. They are unlikely to be used as collateral.
 
-These differences allow for various simplifications and optimizations. In particular, we propose to allow only liquid balances for voting. Because these presumably change rarely in comparison to the number of distinct balances, it is more efficient to recalculate votes on the fly instead of once per maintenance interval (see STEEM for comparison).
+These differences allow for various simplifications and optimizations. In particular, we propose to allow only liquid balances for voting. Because these presumably change rarely in comparison to the number of distinct balances, it is more efficient to recalculate votes on the fly instead of once per maintenance interval (see STEEM for comparison). Nevertheless, the Elected Authority can be configured that the actual accounts that are in control of the Authority only change every given time interval (e.g. only every hour).
 
 Furthermore, we make no distinction between voting and elections. Voting (as in making a yes/no decision) can be emulated with an election where only the votes for two designated candidates are counted and compared to each other. Depending on voting rules (to be defined externally on a case-by-case basis), the one with more votes wins, or perhaps the one with an absolute majority of eligible votes.
 
@@ -64,6 +66,7 @@ The flag must not be used before the time of the hardfork.
 * `optional<asset> candidates_hold_min` - an asset and minimum amount of it that candidates must hold to be eligible for voting
 * `bool proxy_allowed` - indicates if proxy voting is allowed
 * `optional<time_point_sec> vote_until` - an optional ending date after which voting slates are frozen
+* `optional<uint32_t> retally_interval` - if present, the vote tally result is applied to the authority only every `retally_interval` seconds
 
 **Validation:**
 
@@ -79,6 +82,7 @@ The operation must not be used before the time of the hardfork.
     * `candidates_hold_min` must not be present.
 * If `candidates_hold_min` is present the `candidates` must be empty.
 * `vote_until`, if present, must be in the future
+* `retally_interval`, if present, must be greater than the block time
 
 **Evaluation:**
 
@@ -162,7 +166,7 @@ The operation must not be used before the time of the hardfork.
     * Let `voting_balance` be the sum of the `voter`'s token balance of the asset plus his proxy token balance.
     * The voting delta is the `voting_balance` for each vote to be added and for the new `number`, the negative `voting_balance` for each vote to be removed and the previous `number`.
     * The voting delta in votes is applied to the vote tally of `authority`.
-    * The resulting differences in the election outcome (if any) are reflected in the respective `authority` object.
+    * If `retally_interval` is absent, the resulting differences in the election outcome (if any) are reflected in the respective `authority` object.
 
 **Note:** the intent is to have vote tallying work in the same way it is currently performed when voting with BTS. The same goes for determining the number of accounts that make up the authority, unless it is fixed.
 
@@ -185,6 +189,12 @@ If the wrapped `elected_authority` has been deleted, the `special_authority` wil
 
 **Note:** for simplicity, it is left to the implementers to decide if `account_create_operation` is modified accordingly.
 
+## 7. `apply_block`
+
+Code is added to `database::apply_block` to check if any `retally_intervals` have passed. For each such `elected_authority_object`,
+* the current vote tally result is applied to the authority
+* the point in time of the next retally is calculated as the next multiple of the `retally_interval` (the intent is to have the retally happen at predictable "natural" times, e. g. at the full hour, just like the maintenance interval)
+
 # Discussion
 
 ## Deletion