Add virtual operations for referral program fee split

[abitmore]

User Story
As a lifetime member I want to track my referral income.

Additional Context (optional)
Strictly this is not a consensus change, however, it impacts numbering in account history, which is relied on by many 3rd-party applications, so it's fair to make it a consensus-upgrade style change, say, only populate the virtual operations after a special time.

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

[pmconrad]

This is a very desirable feature, and important too for businesses. I'd like to extend the suggestion to also report witness income like this.

Plus, I'd suggest to implement this as an additional kind of history, possibly through a plugin. I think we should avoid re-numbering account history.

[abitmore]

@pmconrad essentially you mean to do it retroactively, but with another history plugin. That's a bigger change and need more work for UI/elastic search and etc. My suggestion in OP was to treat it like a hard fork, aka no retroactive data, thus no renumbering for account history.

[jmjatlanta]

Here is how I read the two options mentioned:

1. virtual method: Adds entries to account history for referral and witness pay. Account history numbering preserved by hardfork-like protection.

2. plugin: Adds entries to account history for referral and witness pay. Account history numbering will be affected if they choose to turn on this plugin.

I personally like option 2, as it gives node admins flexibility. They will not pay (processing and memory) for what they do not use. Those that choose to run it can also get ancient history should they want it. Downsides are a larger coding effort (server and ui side) and different results to clients of nodes, depending on which node they are connected to.

[pmconrad]

plugin: Adds entries to account history for referral and witness pay. Account history numbering will be affected if they choose to turn on this plugin.

I meant this plugin to create a separate history for these rewards, parallel to account history. Account history numbering should be preserved with both options. Having some nodes use "classic" history numbering and some use a "modern" history numbering including rewards will create confusion and lead to problems.

[jmjatlanta]

I meant this plugin to create a separate history for these rewards, parallel to account history. Account history numbering should be preserved with both options. Having some nodes use "classic" history numbering and some use a "modern" history numbering including rewards will create confusion and lead to problems.

Thank you for the clarification. In old db parlance, the plugin would fill a new table. This solves the problem of history numbering, but requires API calls (to query, summarize, etc.) the data. If we can establish a true business need, I would certainly prefer this.

The "hardfork" idea seems to force it on everyone, to avoid coding effort. That works sometimes. But with an established business need, we can determine if the extra cost of developing a plugin is worth the benefits.