[REQUEST] Archive rounds instead of deleting them

[nicoschtein]

I would like to keep rounds instead of deleting them after being paid: https://github.com/zone117x/node-open-mining-portal/blob/master/libs/paymentProcessor.js#L441

I would move them to a different branck coin_sharesArchive and leave them there with a configurable max rounds, like a logrotate but with rounds.

What do you think?

[bonesoul]

+1

[zone117x]

I can implement this really easily,however, I would need to make it a config option which defaulted to false - as this could lead to redis db growing quit large. And I'm hesitant to add more config options for people to have to read and learn before setting up.

But I will definitely consider adding it. Once I get global pool options setup then I'd be more willing to add additional configs for small things like this.

[nicoschtein]

It should be as easy as using same thing as the move block from pending to verified, or delete it, depending on config option, default to delete. I will try to do it and submit PR, I'm new to nodeJS and redis but ill do my best!

On Monday, May 5, 2014, Matthew Little notifications@github.com wrote:

I can implement this really easily,however, I would need to make it a config option which defaulted to false - as this could lead to redis db growing quit large. And I'm hesitant to add more config options for people to have to read and learn before setting up.

But I will definitely consider adding it. Once I get global pool options setup then I'd be more willing to add additional configs for small things like this.

— Reply to this email directly or view it on GitHubhttps://github.com/zone117x/node-open-mining-portal/issues/143#issuecomment-42205108 .

[bluecircle]

I'm working on something like this right now to track "shifts" of work. It's needed to do multipool, single coin payouts.

I'm trying to decide how to treat this as well. We should keep the redis db production/running data to maximize performance and efficiency. For things like previous rounds and historical stats, it may make sense to store the data in a database such a a MongoDB or MySQL.

Is it possible to setup a second redis database that isn't stored in memory but only queried from disk when necessary? That would be ideal.

[zone117x]

Bluecircle, I know almost exactly what needs to be done in terms of data structure and storage for doing payouts in single coins (auto-exchange)

Upon some config like paymentProcess: {enabled: true, mode: 'shareMerging'} or something similar..

All shares from all workers from all coins should go into a single hashtable, for example workerShares_current. This would use a really small amount of memory in redis as each share just increments a number. Then on some interval the exchange processor would rename workerShares_current to workerShares_1 (the number 1 should increment each time the exchange processor runs). Then exchange processor then dumps all coins mined into an exchange, then withdrawals a specific type of coin, then uses the shares from workerShares_1 to determine how much of our newly withdrawn coin we owe to each miner.

This is the advice I gave to the blackcoinpool people and they were able to do it easily and plug into their existing auto-exchange system (which was coded in rust I believe ?). And I'm pretty confident its the best way to do it. Except our auto-exchanges processor will just be another node script in NOMP.

Bluecircle, I know how all of this can be done in a way that's scales and requires no additional software (such as another DB).

[nicoschtein]

Where are we at this?

[bonesoul]

@zone117x, your idea will then break the normal single-coin pools as every miner will be forced to mine in multi-port.

Instead I suggest a plan like this;

Normal miners can just connect to direct port of a coin (XYZ coin) and he can submit shares to XYZ_shares table on redis.

A miner can connect to to multiport profit switching port, where his shares will be sent to multiport_Shares table (in details, like his payment address in BTC as username and amount of share sent). Additionally, a common multipoolShares key will be added to XYZ_shares table and holds the total share of the all users from multipool mining.

So once a new XYZ block is found, the payment processor will just pay the direct XYZ miners coins and reserve the multipool based miners.

And once in everywhile multipool_ExchangeProcessor will rename multipoolShares_current to multiPoolShares_1 and then widthdraw coins reserved for multipool, dump them to a exchange and pay the miners in BTC or whatever coin based on the share amount stored in multiPoolShares_1

This plan will allow normal XYZ miners to mine without being forced to use multipool feature too.

[TheMightyX]

I'm very interested in this feature. I'm not sure we need an elaborate automatic system such as raistlin suggested. Either way we would be happy to have this functionality.