FIP: Improve mining pool visibility and miners status

[hairtail]

Description

Distinguish different miners behind one publicaddress. To do this:

1. Add miner name for different miners behind one publicaddress.
   • PR open
2. Refactor data struct for submitted share:
   • Miner name from which this share is submitted so that we know the last time we see this miner.
   • More share status such as Valid, Invalid, Stale so that we know if there's something wrong like network. Much more stale shares indicates bad network performance.
3. Rpc based miner status query:
   • Route for miner status query instead of use stratum directly.

[NullSoldier]

Related to https://github.com/iron-fish/ironfish/pull/1729

[NullSoldier]

3. Rpc based miner status query: Route for miner status query instead of use stratum directly.

You cannot do #3 because the node no longer has miner status information. We've moved to a model very common to other coins where you only expose a basic set of information from the node, and don't tie the node to any one miner or pool. The pool doesn't run a node so it cannot provide the RPC layer either.

[NullSoldier]

Refactor data struct for submitted share:

1. Miner name from which this share is submitted so that we know the last time we see this miner.
2. More share status such as Valid, Invalid, Stale so that we know if there's something wrong like network. Much more stale shares indicates bad network performance.

I think these two should be done completely separately. I understand how #1 will be done, but how do you intend to do #2 (share statuses)? What makes a share valid, invalid, or stale? Can you elaborate on those?

[hairtail]

Refactor data struct for submitted share:

1. Miner name from which this share is submitted so that we know the last time we see this miner.
2. More share status such as Valid, Invalid, Stale so that we know if there's something wrong like network. Much more stale shares indicates bad network performance.

I think these two should be done completely separately. I understand how #1 will be done, but how do you intend to do #2 (share statuses)? What makes a share valid, invalid, or stale? Can you elaborate on those?

1. Add status attribution for share data struct(sql table).
2. Status:
   • Valid: shares meet difficulty distributed by pool server.
   • Stale: shares meet difficulty but out of date (requestId < requestIdRunningNow).
   • Invalid: shares do not meet difficulty or block template.
3. More miner status info in response of miners:pools:status:
   • Last seen time for each miner, the time when the latest share is submitted from miner.
   • Share status, number of valid, invalid, stale shares during last share count round. Large number of invalid and stale shares indicates bad network performance in most cases.

[NullSoldier]

2. Status:
   • Valid: shares meet difficulty distributed by pool server.
   • Stale: shares meet difficulty but out of date (requestId < requestIdRunningNow).
   • Invalid: shares do not meet difficulty or block template.

You don't want to store invalid shares. This will provide a way for a malicious actor to DDOS the server's storage by sending many stale / invalid shares unless you also punish people with exponential falloff in punish score for sending invalid shares.

3. More miner status info in response of miners:pools:status:
   • Last seen time for each miner, the time when the latest share is submitted from miner.
   • Share status, number of valid, invalid, stale shares during last share count round. Large number of invalid and stale shares indicates bad network performance in most cases.

• Last seen means adding persistence to connected clients. How will you identify miners? How will you prune that persistence so the list doesn't infinitely grow or will you keep track of all miners connected forever?
• When the last valid share is submitted seems like a fine statistic and it's very easy to implement. That should be its own PR probably.