Pool not charging fees

[mmitech]

Till now we've mined around 178 block and around 20 uncle, so lets say 1000 Ether total for the sake of argument , the pool's account balance now is 0.05 Ether when it should be at least 10 Ether.

The pool is not charging any fees !

[sammy007]

It's impossible. Fees are tested very well. Show me your unlocker configuration section.

[sammy007]

Also, you spent 0.00042 Ether * 224 (number of payouts) = 0.09 Ether, but it's not even close to 10 Ether. I guess you forgot to specify fee percentage or did it wrong.

[mmitech]

This is my config

"unlocker": {
        "enabled": false,
        "poolFee": 1.0,
        "depth": 120,
        "immatureDepth": 20,
        "interval": "10m",
        "daemon": "http://127.0.0.1:8545",
        "timeout": "10s"
    },

    "payouts": {
        "enabled": false,
        "interval": "120m",
        "daemon": "http://127.0.0.1:8545",
        "timeout": "10s",
        "address": "0xD3d038BCb4F2450C592381F8bb4bee860532ee9d",
        "gas": "21000",
        "gasPrice": "50000000000",
        "autoGas": true,
        "threshold": 500000000

[sammy007]

Config is ok, but what I see is that you have 224 payouts processed and the number of outgoing transfers from pool wallet is A total of 228 transactions found for address according to etherscan. Are you sure you didn't withdrew fees previously or someone else maybe has a control of wallet?

[mmitech]

Nope, I am the only one with access to this server. But I think I know what is the issue now, it is related to the #12, so unlocker stopped working and I had to restart the pool, and when it initiated the payment I restarted it a couple more times (changing settings trying to solve #12) before the TX even confirmed.... does this make sense to you? do we need to wait for a TX to confirm before removing it from the DB ?

[sammy007]

before removing it from the DB

What does it mean? You should not remove anything from redis.

Payout algo:

1. Pool send tx to geth via RPC
2. Then payout module will add TX hash to Redis
3. Wait for confirmation
4. goto 1

http://etherscan.io/tx/0xb9abf3c3e3f5248299f405f3e1a7ed017f6b0edb5b062c4ca18b895df0cf1137 is not registered for example.

[sammy007]

Also, at first look I don't see any duplicate transactions from your pool wallet. Trying to understand what happened...

[mmitech]

I didn't remove anything from redis, I was asking if it is possible that the pool paid a transaction more than once because I was killing it and restarting it few times ?

[sammy007]

Very unlikely you fall into this issue because it takes a millisecond to write tx into redis. You should be very lucky to restart it in a moment when TX is sent to geth and redis request is performing.

[sammy007]

Did you restart server or just pool process?

[mmitech]

mmm, in fact yes I had to restart the server a few times, but I have an upstart script that should kill the pool before shutting down : start on filesystem and static-network-up and (started geth) stop on runlevel [016]

[sammy007]

There are 4 TX unregistered then, they were sent, but not added to redis. But by design redis must flush to disk on shutdown. Weird. I am looking on payout module now to guess something.

[sammy007]

Join gitter (greed button in readme). We are turned issues into a chat.

[mmitech]

Well, probably the fault is on my side so don't punish yourself looking too long for something that doesn't exist, I think by fixing #12 this won't happen again.

[sammy007]

I need to investigate anyway. For now I suggest to run payouts and unlocker in a separate process, don't run it as part of the pool. Copy config, disable payout and unlocker in a main config and in a copy of config enable only unlocker and payout. Run ./ether-pool payouts.json and always shut it down properly before rebooting or killing something.

[mmitech]

OK will do that.

[sammy007]

Also, if you want to restart payouts make sure it's not processing anything or at least wait for a waiting for TX to get confirmed. This can guarantee that double payment will not happen. And always keep logs.

[mmitech]

I will keep a couple of GHs for test, when I get the proxy to support Stratum <=> Stratum and when I get everything tested well I will slowly move the hashing power to this pool (will have around around 40-50 GHs by the end of next month)...of course I will keep donating for as long as possible.

I would appreciate if you add a couple of other things:

• email notification in case of dead worker
• stats for Pool, Account, worker

Then it won't make any sense mining in other pools, this way this pool can be really competitive... I would gladly help, we can work this out if you are interested.

[sammy007]

@mmtech gitter is cool.

First of all I will make payouts more robust. I already know how to do that. Unfortunately I am almost 36 hours without a sleep and I need to relax a bit and tomorrow I will publish some protection to prevent your case. Your case is really edge because as I said i was running pool for several months.

You have to learn redis backups too. Make it save state from RAM to HDD more frequently.

Regarding donations, I have implemented optional donations from fees to pool developers. All code will appear tomorrow in develop branch.

[mmitech]

I am already on gitter, but opening issues here prevent people from asking the same questions again and it is a good way in general to keep project followers updated and informed... we can open the issue here and discuss it on gitter if you like.

Cool, get some rest and do the rest later.

[sammy007]

Well, we have new payments now with withdrawals in develop.

[gazche]

sammy007 can u help me ?