You and Tyran are off course right. The target for difficulty 1 is (16^56-16^52 = 2^224-2^208), but it can be approximated to 2^224. Since we draw random number from a pool of 2^256 we are left with a chance of 2^224/2^256=2^32, so our average number of draws for 1 block with difficulty 1 is 1/(2^32), giving us an expected 2^32 draws for a winning number.

You both get a +1 from me :-)

Next up, how does this relate to other difficulties?

I have 2.1 installed:
And with other miners it doesn't happen. I'm using a vanilla snapshot from git (without my JMX modifications).

Will do ^^

I've been mining for quite some time, but lately one of my GPUs (an ATI 5850 OC) started locking up after an average of 12 hours. I'm wondering what I could do to avoid these lockups and what the causes are.

The problem started when I switched to the phoenix miner (from Diablo), I think it might be due to a higher usage of the cores (since Diablo in my case was slowed down by CPU, no idea why), so while I now get the advertised hashing speed this single core locks up, making the whole thing not very productive after all.

Any idea?

I'm having a few problems with the CPU usage of the miner, it's uses 100%. I remember that this wasn't always the case, so I wonder what changed it. I could start the JVM in profiling mode if you'd like

So news pools are desirable because some will fly under the radar and those who don't will divide the attack power of the DDoS between them. It's just a matter of providing enough targets to become too hard to take down

Great proposal, I wish many would be so elaborate

While I too don't like the sudden halving of the reward it is a pretty nice and simple algorithm. What is especially nice about it is that the reward from the coinbase (generated coins) never really reaches 0, so miners will not have to rely completely on fees.

I somehow feel there is a simpler solution than to estimate backwards from the calculator. As far as I know the target for difficulty 1 is 0x00000000ffff0000000000000000000000000000000000000000000000000000 (https://en.bitcoin.it/wiki/Target#What_is_the_maximum_target?) and we have to aim below that target. So out of 16^65-1 (the above with only FFs) we have to find a number that is lower than 16^56 + 16^53 + 16^52 + 16^51.

So a simple division might get us how many hashes we need for a share, but somehow I get the feeling I'm off by one somewhere. Any confirmations?

Edit: just noticed that I can actually keep the hex numbers and calculate with them. WolframAlpa says the chances of guessing such a number are ~1.45 * 10^-11 (http://bit.ly/jfJ3Kq ).
Did I get something wrong?

My knowledge about probability is a little rusty, and I haven't been able to find a simple solution to my problem. Given n difficulty 1 shares submitted in 24 hours I'd like to estimate the hashing speed. It all comes down to the average amount of hashing attempts to find a difficulty 1 block, but that's exactly thing that I can't figure out.

Any help? A step by step example would be incredibly helpful ^^

I love this one. It make switching really painless, especially after todays outage of slush's pool this proved a timesaver. What I noticed however that the failing pool will still be asked for work, and only he doesn't return any, the next one will be asked. Are there plans for exponential backoff in order to avoid the extra request and the extra idle time? Just a mechanism to automatically blacklist a pool should it fail, and increase the blacklist time on each subsequent failure would be cool.
The problem today is that slush sometimes gives me work, but does not accept the result (timeout/502 errors/...).

Also I get a lot of these:
Which makes me think that the diablo miner does not really take advantage of the long polling feature, and I start feeling bad for bombing pools with all those long poll requests. Any ideas?

Actually no, the difficulty is adjusted each 2016 blocks, so a sudden drop right after an adjustment might take really long to have an effect on the actual difficulty (if we are left with 25% of the hashing power it takes up to 8 months to adjust the difficulty)

Yes, having a single instance with >50% is bad for the network, deepbit just happens to be the first ever to reach that limit. I'd encourage people to start creating new pools. Having slush's pool down (for whatever reason) should provide you with enough users to justify investments
And hopefully slush's pool comes back up soon

Would be nice though if mining pools and miners would implement session tokens which could be used to identify different instances running with the same credentials

Let's hope we never experience a huge drop in hashing power, otherwise we'd have a similar problem like the one we already experienced back when ArtForz, for fun, redirected his rigs to the testnet. Once he stopped the remaining nodes where left with an incredibly high difficulty and the rebalancing would have taken months (2016 blocks at 3-4x the actual hashing power in the network would take 2 months to rebalance) and confirmations would be really slow.
It's hard to make promises but if my mining equipment survives that long I'll continue mining ^^

Would you consider shipping overseas?

I'd start by asking Magnatune to accept Bitcoins. Magnatune is a "pay as much as you feel is right" kind of site and it has a decent selection of artists

If you are tech savvy you could create a ram-disc, copy the datadir to it and then start the client against it. This works especially well when you download a snapshot from one of the HTTP mirrors
Once your client has caught up you can stop the client, copy the updated datadir to the original datadir.

HTH,
cdecker

Isn't there a problem with 6990 Cards? Or are they supported by 2.1 too?

Some miners do check the results before submitting them to a pool or bitcoin client (DiabloMiner does for sure).

And there I was thinking that I figured out everything ^^ Thanks for the correction.