Wow, 154.68299211 BTC is pretty decent income for a block.

If it had been on a pool that keeps transaction fees that would be almost a 68% fee. Yes, avoiding such steep fees is probably wise. 

Yes, increasing PPLNS's N up to 4x Difficulty will definitely reduce variance when you have some downtime. Just like it reduces the variance in the income of a non-24/7 miner, it will also reduce the variance in loss due to downtime for a 24/7 miner. Less chance of a big loss because your miners went down just before we found 3 quick blocks. It would still be a loss, but a smaller one.

It's not possible to pool hop on BitMinter though, and this won't make any difference in that regard. Of course you can move in and out of the pool as you wish, but since you can't predict beforehand whether you get high or low pay you can't "pool hop".

Making pool hopping impossible is really that simple. Just use a fair reward system. It's a shame some pools refuse to do so. And it is outright strange that so many miners still use those pools.

Well, my pool does. If you get a 401 (Unauthorized) response I would recommend at a minimum setting a much larger delay between retries. Maybe 30 or 60 seconds? My own miner just pops up a password dialog, like a browser would.

I don't think any pools are so broken that they respond with a 401 when there is nothing wrong?

P.S. Try http://mint.bitminter.com:8332/lp in a browser

A user at my pool retrying the same wrong password 10 times per second with DiabloMiner. Is that how it's supposed to run?

Might be an idea to give up and shut down if the password is wrong, or at least use a much longer delay. It may be that 10 times per second is because of running multiple instances, but still if it is once per second it is pretty extreme.

In my opinion the total cost of mining at a pool is more interesting than any single part of the equation.

Deepbit: 3% fee + loss to pool hoppers + loss of transaction fees = about 5% ?
P2pool: loss to orphaned blocks = about 5%

Don't blind yourself by looking at just one of the numbers.

The block finder's bonus at P2pool will cause higher variance for small miners. The big miners who create a block per day will not notice it. If you create a block per year, you will certainly experience higher variance because of it. That's the downside.

The upside is that it helps make blockwithholding attacks more expensive. If you withhold a block from P2pool you don't just lose your regular share of the income but also the bonus. This means pools with a block finder bonus are the most expensive to attack. The cheapest are PPS pools. You can destroy them for free (requires some hashpower though).

Yes, this is what roll-ntime is about. Miners are allowed to generate new work to hash by fiddling with the block's timestamp (referred to as "ntime"). This way they don't have to talk to the server several times per second (in the case of fast miners) to get new work. As long as you don't get too far away from actual time this is OK and the block will be accepted by the rest of the bitcoin network.

Sometimes you will see 5% rejected for a moment after a new round starts. This is because rounds always start with rejects, then the accepted proofs of work start to come in.

But 250 rejected out of 1300 proofs of work sounds like something is very wrong. Pool-wide the rejects are pretty low too.

Did you get reject after reject in all 4 separate cgminer instances?


No, if it went down it must have been because a new round (block) started.

Duplicate proof of work is often caused by network issues. Also 52 second delay could also be due to a network problem.

Could you try "ping mint.bitminter.com" at commandline and see how that looks? Packetloss maybe?


The time the pool starts building upon a new block is usually the only time you get rejects.

How high a reject percentage are you getting?

No, it was my own code. I reworked the data structures to increase parallelism. Accidentally ended up with proofs of work being kept in memory indefinitely. After a couple days the mining backend was lugging around 3.7 GB of proofs of work.


Hmm, I only see one failed login from you in the server logs, at 2012-10-01 11:51:05 UTC, which is 22 hours ago as I write this.

Did you change password on a worker recently?

Does it help if you shut down the client and start it fresh again?

P2pool is one of the most expensive pools to mine at because of the high orphan rate.

But no, I don't expect pool fees to change because of the reward halving.

A more interesting problem is ASICs and the increased orphan rate they will cause until the difficulty catches up. This could be a big expense for pools that pay out orphaned blocks. For my own pool (which pays orphans for a donation), I haven't decided yet what to do in case orphans get really bad.

Something tells me I better get the server ready for some big miners. 


I fixed the memory leak in the mining backend. Hopefully it can sit there for a while now without requiring any more restarts or work.

Made some changes just now to the web application as well. Hopefully it will fix the issue with it locking up.

If there is still a problem I'll have a look at writing a script to detect when the website is unresponsive and automatically restart it.

A user at my pool is retrying the same wrong password 10 times per second with phoenix/v1.7.5
Is this intentional behavior from phoenix?

Thanks, guys

Sorry, had to restart the mining backend just now. A memory leak is causing slow response after it's been running a couple of days.

I'll be working on that memory leak today, and also the issue with the website locking up.

Back up again. There's a problem with the web server. It locks up randomly with no error message and becomes completely unresponsive. So it's a bit difficult to figure out what the problem is. I'll keep a watch on it and see if I can find out what's going on. Sorry for the instability.

Even after clearing the cache in the browser?


That's on my TODO list.

The server is running very smoothly now. We had 1.8 TH/s earlier today and the server load was pretty low. Sorry for the daily restarts and sometimes high response times the last couple days. Hopefully it will be smooth sailing now. It is certainly looking pretty solid.


Not a bad idea. Is it annoying to have one ticking away at the top of the page?

I suppose better might be to display the timestamps in a timezone chosen by the user, but that would take a bit more work.

If you have Java plugin activated in your browser then a hacker could leave something on a webpage to take control of your computer if you view that webpage. It can happen to anyone using a browser with Java plugin turned on.

It's a bit annoying because Java is how BitMinter client is so easy to start, just clicking on a webpage. If you turn off Java in the browser to protect yourself from hackers then you can't start the miner that way. But as long as Java is still installed it should be possible to start it from commandline with "javaws http://bitminter.com/client/bitminter.jnlp". So you can protect yourself and still use the client.


I just restarted the mining server, that causes some rejects. Sorry about that, I try to keep it to a minimum.

Update now is faster authentication, which should speed up response a bit especially just after a restart when all users have to get re-authenticated. Also turned off rollntime for cgminer and bfgminer below version 2.7. Please upgrade to the latest version if you use one of those two miners.

Once in a while when those old miners start DDoSing the server some miners experience response times up to 30 seconds. It is worst in the "slow response queue", so those miners are mostly DoSing each other. But hopefully this update will help reduce the problem.

Lately they are finding security holes in Java every day. It is recommended to disable the Java plug-in in your browser.

If you are using BitMinter client this should not be a problem. You can start it from the command line instead:

Website is back up again. Sorry for the downtime.

Mining, payments, everything was running, you just couldn't access the website. And yeah, it was the backend behind Apache that locked up. I might switch to Nginx, I was actually planning to, but Apache has actually done a surprisingly good job.

Thanks for the "votes" guys, I am flattered.

I'd like to nominate Fefox instead. I think he'd do a great job, and I wouldn't have to suffer so much jetlag and an expensive plane ticket from Europe. He's been mining since the olden days when we were using calculators.