Time for some extremely long posts again.
Let's go into some background first on how it is that NOMP works.
I strongly suggest each of you set up redis-commander, and use it to look at your database. Be careful to use a good password, as someone could maliciously log into your instance of redis-commander and wipe your entire redis db.
https://www.npmjs.org/package/redis-commanderWith NOMP, each coin that you have configured is going to have a seperate redis key. Let's start with what is redis?
Redis is an in-memory key-value store, which means that it exists solely in RAM. This is the reason that NOMP is so much better than MPOS, which uses an on-disk SQL database. Redis can scale up to millions of transactions a second easily, SQL cannot.
So in NOMP, each coin is going to have it's own seperate key.
Inside that key, you will see several other keys:
blocksConfirmed - these are previously solved blocks.
blocksKicked - for all intensive purposes, these are the same as blocksOrphaned
blocksOrphaned - solved blocks that wound up being orphans.
shares - this will usually consist of only a single key, roundCurrent which will contain numerous fields. Each of your workers will be the name of a field, and their appropriate value will be the number of shares that they have successfully submitted for the current round.
hashrate - this will be a live log of the shares that are being submitted by each worker. This is where the hashrate calculation are done from. This is sorted set where the scores are the epoch timestamps, and the values are a string made up of the share difficulty, the worker name and the full javascript epoch time (down to milliseconds).
balances - This is where NOMP keeps track of who has earned what. As blocks are solved, the block reward is divided up proportionately amongst the miners (ie, the currentRound key is checked and all of the value numbers are added together. Each worker then is credited with their particular number of shares (ie, their value in the currentRound divided by the total of all of the values in the currentRound) multiplied by the block reward. This number is then added to any existing balance that may already exist in the balances key (so that a worker can have their reward for multiple blocks in a row add up) - when a payout process happens, this key has to be cleared in order to prevent duplicate payouts.
In my pools, every single payout each coin has it's balances key renamed to the format Prev:<shiftnumber>:<coinname>:balances - this leaves a good audit trail as you can always look back at any previous round and see exactly how many coins each miner has earned, in any previous round.
