Oh you wanted the lucky blocks? Let's try that again.. 


This looks nice. I will think about some changes for the future.

I've added a bot to the chat (IRC) that announces new blocks as they are generated:

That's exactly what it was doing. And the reason not to always run with cheatmode, well... Can you imagine the complaints from other pools if they knew we are hacking instead of hashing?

First block is in...

Engaging fast block cheat now.

(Noone tell Gavin Andresen, he got really mad last time)

Thanks for your continued support, DAT. Have fun on your cruise! Sounds like a nice relaxing time.

Good stuff. Just lacking automation features and some more testing then, to finish version 1.1.

Agreed on CPU-mining. I have a lot of plans and CPU-mining is quite far down on the list. Way down with support for Radeon HD 2000- and 3000-series. They are probably not very profitable for mining either.

And yes, as long as someone is paying enough for litecoins to make them more valuable to CPU-mine than bitcoins, it makes more sense to implement that.

Oops - fixed! Strange bug, didn't happen when started from command line, only when started from browser.


Glad it helped. But I'm at a loss as to what is causing that last bit of a performance hit for you. I can't see what else changed since 1.0.1 that would affect performance. I'll look over things again, though.

Small update today:

• Fixed the loading and saving of settings (mentioned above)
• Workaround for a bug in Java that would cause security errors talking about mixing signed and unsigned code

I can't really be sure the workaround for the second bug is working, since I would only see the bug about once a month. Very rare, but also annoying. Did any of you ever see it?

I'm calling this 1.1.0-beta4 now. Seems like an easier to understand naming scheme for the beta versions.

Thank you to all who are testing, the feedback from all of you is very valuable.

Another beta of the miner released today. Automation coming in the next one.

I hear you guys about CPU-mining. What I will probably do first is implement bitcoin mining with CPU using OpenCL. That should hopefully be just slow and not dead slow. Next step for CPU mining then is to make libraries with native code for the miner to use. Then it could be as fast as any CPU miner. I'll need a way to turn some assembly code into a .dll for Windows, .so for Linux and whatever Mac uses for Mac. If anyone knows a way to build all that on a Linux machine then please let me know.

CPU mining isn't near the top of my list, but it is on it.

Releasing another beta version for testing. Here are the changes:

• Fixed bug that could say your GPU "prefers the work size to be a multiple of
    3539913157759729696 for this work process."
• Index saved settings by MAC address of first network interface. This allows
    different settings on individual networked computers with the same files
    (homedir). Note: this means your settings will be reset to defaults when
    upgrading to this version, and also any time you switch network cards
    or change MAC address.
• Bugfix: ignored new passwords from user after server responded with
    other HTTP response code than 200 or 401
• Added options window under "Settings -> Options..." in the menu, with
    audio configuration
• Remember more settings across restarts: device settings (Tune & Tweak),
    audio settings, hidden devices (individual close buttons),
    hide/show log
• Make OpenCL buffer type selectable for user (Tune & Tweak)
• Default to manual vectors off and BFI_INT off on non-AMD devices

The new options window (settings->options...) is where I will soon add automation options. There's only audio setup there for now. Finally device settings are saved, which is also a must before automating anything.

conspirosphere.tk, and anyone else getting better speed from regular (1.0.1) than beta version: I'd be very happy if you can try out this version and see if it helps. Please try the different types of buffers (new setting in "tune & tweak") if you are using Windows. I can't understand what else could be causing 1.0.1 to run faster. I hope I can figure out this issue before all the new features are done.

Quick update, just started working on the miner again.

• Merged mining friendly, no more high NMC stales
• Fixed bug that could say your GPU "prefers the work size to be a multiple of 3539913157759729696 for this work process."
• Hopefully fixed unstable performance

It would be very useful with some feedback on performance. The previous beta had very unstable performance for some users. I saw this sometimes myself too. With this update it seems stable here.

Use the beta button to test it.

Good that you got it working

Getting AMD drivers working properly is like playing the lottery. And their OpenCL compiler is ridiculous. But.. they make some excellent hardware.

I just upgraded to Catalyst 11.11 too. Running 6990 + 5970 on Win7 64. Runs fine here, maybe even a little bit faster than the old drivers.

Not sure why you are having problems. One time I was switching between different driver versions to make sure the miner worked ok on them and something similar happened to me. I had to wipe the drivers completely and reinstall them to get things working properly again. Did you try another miner? If another miner has the same problem I'd bet it's something wrong with the driver install.

Glad you like the website update. Merged mining and website updates took a lot of time, but I'll have some updates for the miner again soon.

I think I'll do both, when I have a little time. Maybe add datestamps on the shifts too.


Maybe I can add this sort of thing to the JSON API later. But you can grab it pretty easily from the html source. If you "view source" in your browser you will find 2 huge javascript arrays. The first is actual share values, the second is the expected average values. For each line there is first an index number and then the numbers you see when you mouse over the lines in the graph. The second graph just uses the same data after adding up the values with some javascript. Hmm, come to think of it, the expected average values are easily calculated with javascript too - I should do that instead.


I didn't handle it, I just listed it as an error source at the top of the page. It uses the difficulty at the end of the shift, pretending it was the same throughout the shift. It looks like the difficulty only changed in 4 places, so it should not matter much. But for those 4 shifts I think I could calculate the average difficulty and use that. I'll look into that later.

Anyway, to me it's a little surprising that we are that far from the expected average. Do we have any probability experts here? What is "the long run" for bitcoin mining? 46x difficulty number of shares definitely looks like the short run.

So I have to admit, to PPS fans, that variance can be a bigger factor than one might expect. Just remember, though, luck isn't always bad luck, and taking a 50/50 risk doesn't always mean you lose.

The second graph is what someone with 1% of the pool's hash power would have earned since the time we switched to PPLNS. Maybe +26% makes more sense, instead of picking some arbitrary hash power.


I felt it was wrong to call the second graph "actual earnings" because noone hashed at 1% of the hash power the entire time. It's a bit hypothetical. Maybe it's ok to call it actual earnings if I put percentages on it like DAT suggested.

Also, the graph is PPLNS vs PPS (for this specific pool for the time we've been using PPLNS). The higher earnings came from pool luck, yes. But it was paid out to miners because of PPLNS. In this case we were lucky and payout was higher than PPS. But it could of course have been the opposite. It shows the variance from PPLNS. And as we see, 46x difficulty is not enough shares to even this out.

In this case, with PPLNS, the +26% earnings from good luck went to the miners. If it was PPS it would have gone to the pool op. Same thing of course if it had been -26%. With PPLNS the miners get the variance, with PPS the pool op does.


That's just the pool having better than average luck for a while near the beginning.


The timeframe for both graphs is 46x difficulty number of shares. Which is a while at a 70 Ghps pool, but I guess only about a day on deepbit? You can see that every area with zero pay in the first graph leads to a flat line in the second graph where earnings don't increase. Everything matches up between the graphs on the X-axis.

It would have made very much sense to mine here at the lucky period near the beginning, yes. But of course noone can predict that, and that's what makes PPLNS safe from pool hopping.

Glad you like the changes.

I added today an extra chart on the rewards statistics showing the earnings accumulating over time.

Also forgot to mention in the big update earlier that I added a QR button in the cash out addresses. Click it and a QR code representing the address is shown. You can scan it from the screen if you use the bitcoin wallet program for Android. Will be more useful later perhaps, with more bitcoin addresses on the website.


You said it. This block has the highest CDF the pool has seen on a BTC block so far. I really hope this ends soon.

That's exactly what I was missing, thanks! Added: https://bitminter.com/stats/rewards

I removed the first shifts (proofs of work are grouped in shifts, each of size difficulty/10). I started recording these before I switched to PPLNS, so the first ones naturally had no rewards.

This is just 46x difficulty worth of proofs of work. We are a small pool, and it wasn't always PPLNS, so we don't have that much data to go on yet.

You can see some bad luck in the beginning put us below average. Then a nice streak of good luck put us at about twice the expected earnings. From there up until now it's been pretty average. Right now we are having a really bad block, which is the reason for no earnings towards the end. Luckily we had some short blocks just before that.

Obviously the big lucky streak at the beginning takes a while to even out. Ending at 29 rather than 23 BTC is a big difference.
Since switching to PPLNS we made 58 blocks rather than the expected 46. Too small sample size maybe? Any other pool ops have some data?

I added a new statistics page at my pool showing real life data: http://bitminter.com/stats/rewards

You can see how actual payouts compare to the expected average income per share (basically 0% fee PPS). I can probably improve this with some stats for "all time average" and "average last X time", but I think it is already useful. There are also charts of the pool's luck here: http://bitminter.com/stats/luck

Quick way to get some data without taking months to run a test.

I'm sorry to hear that. If you let me know the time (and timezone) this happened, I can have a look in the logs if there is anything to indicate this was a server-side problem.


Thank you. I will add some averages. Also, it seems the timestamps on the blocks and shifts in the live stats are not UTC like they should be. The audio alarm seems a little trigger happy too, going off when there are no new blocks. Will fix these things very soon.

The live stats full size? What is not working with it?