Quote from: phzi on February 17, 2014, 10:22:24 AM

Everyone should have a fail-over in-case of emergency set anyway... basic mining principle.

This is the best advice. While I'd love to have 100% uptime, while wafflepool is growing like this, we are going to have some outages as things break. I'll try my best to make sure what happened earlier doesn't happen again (server accepting connections/shares and not reporting them), and instead goes straight offline. But its on you guys to make sure you have a (or two) backup pools enabled. Just a good habit when you're using any pool

Quote from: phzi on February 17, 2014, 10:22:24 AM

Issues like lost shares do happen (probably a fair bit on places like middlecoin that just pause stats for ages...), but poolwaffle always seem to be on top of them for wafflepool.

Yep, thats one disadvantage of openness

If/when things happen, I'm here to hear about it (and you guys can see it happen more), whereas with some other pools that don't share as much info publicly, it might happen often, just hidden from sight.

Quote from: phzi on February 17, 2014, 10:22:24 AM

But, PoolWaffle, why are you Blocks Found stats blank? Data not lost I hope?

That data isn't really used for anything (other than listing for user sake). It has been disabled for now (we'll see if it comes back - not sure yet). The issue with it has to do with the way we're submitting blocks, and the way we're saving shares.

Shares get sent from endpoints to a collecting server (so they're all processed the same regardless of which endpoint you're on), and at the time that they're sent to the share processor, we don't know if they're a valid block yet. We have a guess, but there are plenty of reasons the daemon might reject it (new block just came in, invalid data for some reason, etc), so we can't mark it as accepted on our side when we send to the share processor. We then submit it to the blockchain, and know if its a valid block. This was unfortunately one of the many things slowing down our original implementations. Once we know it was accepted, we could go back and mark the previous share as an accepted block, but the share is buried in a pile of shares that are being actively processed. It may have been processed already, it might still be waiting, so changing the flag to "accepted" requires that the queue be paused from additions, processed completely, update the share record, and reactivated. The waiting for share queue to flush completely was causing the block finding server instance to lag a bit for upwards of 2-3 seconds.

Based on the fact that we really don't use it anywhere (we don't play extra to the block finder), during the mass changes a couple days ago I just went "too much to deal with right now", and removed the updating for now.

I can see what it will take to add it back in, if people think it is important. One simple answer is to just queue up one additional share (the same share once with a "not a block" flag, once with "valid block" flag). It makes accepted shares differ from what cgminer/etc shows, but not by a terrible amount. Also could potentially make that fake share worth more as a block finders fee (fake share difficulty worth 1% of current shift total shares or something).

All that said. I think the next step for the pool (other than making sure things don't break again), is adding per-worker stats to the miner stats page. As well as going through some of the new coins to be added.

I looked at a few new coins to add, but either they've done some odd things that would require major upgrades to our server to support (odd transaction messages, etc), or the coin daemon isn't stable (cosmoscoin), or they're not supported on an exchange with the APIs we need. I've reached out to both coins-e, and coinmarket.io about adding some APIs we would need to be able to auto-trade on their exchanges. No progress there yet though.