Masternode Rewards list, estimator & calculator

[JSKitty]

Abstract

This feature request aims to improve the experience of Masternodes on MPW with a huge increase in monitoring and tools for the user to keep up with information about their node(s).

The exact UI design is undetermined, but I'd initially like to propose three additions (could be three extra 'boxes' in the Masternode Dashboard, but this may take up 'too much' screen space and instead be designed a better, more compact way).

1. Rewards list (essentially a clone of the Staking rewards list, keeps users updated on their rewards history).
2. Reward hit estimator (use the last reward date, if any, and the total enabled MN count, to predict roughly when the next reward arrives, i.e: "In 6 hours"), could even have a neat little purple progress bar!
3. Live Calculator (a calculator, without inputs, showing Daily / Monthly / Yearly reward estimations).

Rather than hardcoding PIVX chainparams such as 'MN rewards' (for the calculator), we should instead base the calculation on the last reward generated in the list (if any), since if PIVX changes it's emissions, MPW will automatically correct itself then.

All in all, this is one UI element that users will love - folks enjoy watching how their numbers / portfolios are doing.

Note

Ideas to change this proposal are more than welcome! This is just a quick concept to help add additional juicy "context" for Masternode owners, if you think something should be dropped, changed, or added, leave a comment and we'll discuss!

[panleone]

I would also add:
4. Masternode support for ledger

[JSKitty]

I think Ledger support should be a separate PR (would make this scope pretty large), this idea is mainly an upgrade to the MN dashboard UI for monitoring/stats/portfolio reasons.

[panleone]

Hmm ok, I also don't like the idea of having a bar that tells you when you will have the next reward... Since it will be most of the time wrong

[Liquid369]

Hmm ok, I also don't like the idea of having a bar that tells you when you will have the next reward... Since it will be most of the time wrong

In terms of the masternode list we can actually use a form of parsing list masternodes and getmasternodewinners for the upcoming rewards that should/could be fairly accurate.

[JSKitty]

We can easily achieve estimations within a ~15-20 minute accuracy with simple calculations, which is more than good enough IMO, near the end of the reward queue, it can simply be full and state "Reward Incoming".

[panleone]

4.1 since we have the new mempool system a nice add is preventing the user from clicking the activate masternode if the tx has less than 15 confirmations

[Liquid369]

Picking back up here, I think for something like this do we want to expand on @Duddino RPC/API thats being used for starts/votes?

One consistent add-on for the additions and if we bring it here we can have similar standardization, and can offload some more heavy lifting from the browser if we wanted to

Thoughts?

[JSKitty]

Hm, depends how far we want to 'server-compute', I'm generally in favor of putting as much in to the client-side as possible, rather than adding upon layers of dependency on RPC servers. (Even worse, if we do custom endpoints that perform multiple RPCs at a server level, then MPW is truly 'dependent' on that implementation).

For instance, I think we'd be safe with two RPC calls, one for the masternode count, one for our masternode's data (which we can find queue status, etc), this basic data can estimate reward times and such.