Extended operation history for accounts selected by ID or by registrar

[christophersanborn]

Add the following options to account_history plugin to enable extended history tracking for specific identified accounts or for accounts registered by a specific set of registrars:

  --extended-max-ops-per-account arg    Maximum number of operations to keep 
                                        for accounts for which extended history is kept
  --extended-history-by-account arg     Track longer history for these accounts
                                        (may specify multiple times)
  --extended-history-by-registrar arg   Track longer history for accounts with 
                                        this registrar (may specify multiple times)

Note: I am preparing a PR for this.

User Story

As a user, I run my own node, and would like to keep long history for my own accounts. However, setting a large max-ops-per-account is prohibitively demanding on RAM resources. Another option, setting the track-account option, is undesirable as it then retains no history at all for other accounts.

What is desired is a way to retain a "reasonable" amount of history for all accounts, and extended history for my own accounts.

As a simplifying measure, it would also be useful to identify the the extended-history accounts by their registrar, since an LTM who registers sub-accounts would find their sub-accounts automatically included in the extended history. Additionally, selecting accounts by registrar for extended history could also be useful to DEX or gateway operators who register accounts for their customers. Example: "SomeDEX.io" could offer a UI and API nodes that maintain minimal history across the board but extended history for their own customers.

Impacts

Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[abitmore]

Thanks for the good idea.

I think it's even better if we have different max-ops-per-account numbers for different accounts or registrars. Viable?

[christophersanborn]

@abitmore wrote:

I think it's even better if we have different max-ops-per-account numbers for different accounts or registrars. Viable?

I think it could work if we implemented the parameter as a map of [acct_id, max_hist] pairs, and wouldn't add too much complexity implementation-wise.

But I do think it sensible to keep the current new options as is for now, as they are simpler from a user and implementation standpoint, and likely cover a majority of use cases. Can still add extended-history-map and extended-history-by-registrar-map options in the future.

[abitmore]

Done via #2259.