That's the Java virtual machine crashing, most likely inside the AMD drivers. If you look a little further down it probably says it crashed in amdocl.dll (AMDs OpenCL drivers on Windows).

If you uninstall the AMD drivers, run driver sweeper to clean up, and then reinstall an older version, you should be ok.

Welcome Let us know if you have any problems.

AMD uninstall never uninstalls properly.

You may want to try driver sweeper: http://www.guru3d.com/content_page/guru3d_driver_sweeper.html
I haven't had to do this in a long time, if there's a better tool for this now, someone speak up.

So you uninstall, run driver sweeper, then re-install Catalyst 13.1.

If you turn off BFI (click the little green arrows to expand the display then click the wrench for settings), then it will perhaps work, but it will run rather slowly without BFI.

Have you tried Catalyst 13.1, which is the latest stable release? 13.2 is still just a beta.

If you go to myid.net it redirects you to another site which displays a message in korean. It's an image so you can't paste it into google translate. But one miner told me that myid.net have shut down permanently.

The OpenID identity provider myid.net appears to have shut down. If you can't get into your BitMinter account because of this, contact me at operator@bitminter.com


Haven't seen that one. An online wallet? I hope it's temporary.

It pretends like one proof of work mined at difficulty 32 is 32 proofs of work at difficulty 1. So the payout is fair, but there is a little more variance at higher difficulty. As far as I know this is how all the pools handle variable difficulty.

If you want to know more about that I'd suggest you check out organofcorti's blogpost about it: http://organofcorti.blogspot.com/2012/10/71-variable-pool-difficulty.html

My recommendation is to not use proxies unless you actually need them. Bfgminer has Stratum and vardiff support built in, so you'd be better off connecting it directly to the pool. But  if you have multiple mining computers on a local network, you may save a little bandwidth by using a Stratum proxy instead of having each connect to the pool directly.

This looks good. Thanks for including the user-agent in there as well.


If the resume fails, how should the server respond? Give an error, or just a new extranonce1?

If the old connection is still there, I guess the server could disconnect it. That means the session ID must be hard to guess so you can't disconnect other people. You must also be very sure that you don't give out the same session ID twice, or you'll have two workers disconnecting each other all day.

It's safer to never resume a connection that still appears up to the server. But I wonder how often it will happen that a client tries to resume before the server discovers that the old connection is dead.

Letting both connections stay seems like a bad idea. They'd both be doing the same hashes in the unlikely event that they both keep hashing.

Back up again. Sorry for the downtime.

bitcoind went haywire with disk accesses, but a restart cleared it up.

Having an issue with the server. Looking into it now.

Bitminter adjusts the diff quite quickly. Asicminer tested the pool with much more hashrate than one Avalon and the pool adjusted (it maxed out at 64 at the time, but I have set a higher max now). That said, there are plans to allow setting a minimum diff.


Yep, that's also on the TODO list.

Is this an extension? Where are those documented?

Of course. Anonymize out your IP address if you want. I didn't do that as I was sending it only to your email address and it could be helpful to you.

If your proof of work hash is above difficulty 1.6 million then it is also above difficulty 8, so there won't be any problems. Any proof of work that can create a valid block will be submitted by the client.

Edit: I emailed the data that was logged about your proof of work to the email address registered with your Bitminter account.

Maybe this is a bug in cgminer. Or if you have multiple workers, did you check them all?


You mean above the required difficulty to solve the block. Above difficulty = below target.


The difficulty given by the pool (1-4096 currently) will always be lower than the difficulty for creating a block (currently 3.6 million).

Even if the mining difficulty was not capped (currently at 4096) you would still need a worker with a hashrate that would produce 20 bitcoin blocks per minute on average, for the server to give you a mining difficulty that is higher than the difficulty to create a block. If you receive enough ASICs for that then I recommend splitting them up over multiple worker accounts, at least until the network difficulty goes up.


It could be a potential problem if you added a new worker that had 200 times the hashpower of the rest of the network. So if the current network hashrate is 30 TH/s and you add hardware doing 6000 TH/s on a single worker account, then we need to look into it. In that case, please let me know in advance.

Ask your pool operator to upgrade or switch to a different pool.

Sounds good to me, mine is just hardcoded to "1" at the moment. I'll make it unique when it is actually used for something.


Can this go in the docs?

As well as mining.resume and mining.identify or whatever the "which client version are you" message is called.

What are those reasons?

How would it work? Would it be a suggestion that the server can take under advisement and choose to ignore?

Yeah, 9% is ridiculous. Something is wrong there. I guess somewhere in your dual proxy setup things get slowed down a lot. Try connecting cgminer directly to the pool and see how that works.

Poolwide rejects for the current round is 0.16% as I write this. I'd expect some getwork users are above and most Stratum users are below that.