If it isn't permanent and the error appears only time to time, it might be problem on my side. Please PM me your pool login and time (ideally in UTC) when the problem appeared last time.

Ok ok, I didn't know it when I wrote the post .

It's still above 0.7, today's low is 0.73 (mtgox)

Your "efficiency" measure is your hashrate. Nothing more. If your pool admin doesn't like the traffic which you generate to the server, choose another pool.

+1 for cigar shops on the street corners exchanging Bitcoins.

Hello Kiv,

as I expected, there are already people who don't know 7z and cannot handle it. Is the exe installer coming soon?

It's the GPU miner with graphic interface. You only need to download EXE file, click it and fill login/password for some pool. That's the simplest setup which I can imagine...

(I expect that you have already installed drivers with OpenCL support, but it is not Bitcoin-related).

Edit: Oh, I see that there is no official EXE version of poclbm GUI. Then you have to install 7zip extractor (let's google it) and unpack 7z file. The executable is inside that.

From side of the miners? Yes. There is no reason to ban CPU users and build "GPU clusters".

There is only one exception; 1000 GPU users will make less pool load per ghash than CPU users. But this does not cut miner's income, it is just the problem of the pool operator.

To explain it better. There are two variables in the game - miner's hashrate and pool hashrate.

a) Miner hashrate affect his income. Less individual hashrate - less payouts.
b) Pool hashrate affect the frequency of payouts. Less pool hashrate - less steady payouts.

There is nothing more behind that. Pool hashrate, type of miners in the pool or anything else does NOT affect miner's income. So I don't see any reason for making "GPU only" clusters. Only potential reason might be the pool (server) load, but it can be done by another solutions than by banning  CPU users.

What kind of 'effectivity' are you talking about? Why it should be more "effective" to join my CPU miner to pool full of CPU miners? Or 5970 to pool full of 5970? It would be great if you can do the math showing improvement in pool clusters like this...


I probably don't see the improvement in your model.

Where do you see that??

Immediately after block is found, pool is asking bitcoind for last blocknum. But there is a bitcoind balancer, every request may go to another bitcoind instance (except submitting the block, where the instance must be the same for getwork and submit). This problem with blocknum happen when instance performing getblocknum() does not info about newly mined block yet.

P.S. To avoid confusing you, Thor, I corrected the blocknum manually .

I added page with payout history. Now you can check when and how many bitcoins the pool sent you.

Teoretically - yes. Practically - I'm doing tests for more than 50% of time spent on the development. I'm sure that pool operator(s) of other big pool(s) does the similar. In fact, my pool started up 16.12.2010 and except two server restarts in January and slightly lower hashrate (drop around 30%) during 2hours of DoS attack in February, it is up all the time.

And yes, I have development environment and even stage environment on other machines in the same data center.

Small update today. I added JSON API for profile page and token mechanism to authenticate against it without need of login/password in your scripts. I see that many of you are downloading profile page and parse it periodically. This API is now preferred way to check your account balance.

For API interface instructions, follow the link on top of your profile page.

Not yet, but I read the code right now. Looks like a lot of work . I'll add link to the first post and I'll consider to adopt some info you've tweaked into main GUI. Mainly switch the "last share at" to "last share before", which I consider as really useful. But there are lot of other feature requests, so I cannot promise it to some date .

I know, no need to poke me here .

From my investigation the sending part of the payment is definitely not this pool. You probably used the same wallet somewhere else . I checked my bitcoind logs, database logs and blockexplorer details and it is absolutely clear .

Who has access to the escrow with those 8400 BTC (1NLPqEyWo9HzPmXG2H8uGG4NBFCV31NarD)? I see that wallet from head post is almost empty...

There is demand for Ghash contracts from people who don't want to run their own rigs. I don't see why there should not be a demand for preinstalled HDDs for people who don't want to play with Linux. Personally I enjoyed building my rig and learning the stuff around, but I started to not judge this kind of business, because 'we' are not 'they' .

The point is that nobody knows when the round finish. You'll probably miss many rounds by connecting after the half of expected round duration. You can do this, you'll have +/- same payouts for those blocks, but much less often, so it is not a vulnerability. There are some graphs and analysis done in this thread before. It shows that connecting after some time is not worth of the effort.

It's only minor bug on stats page. Number goes to zero when round is longer than one hour, but there are constantly over 1000 active workers now.


No, there is just some delay before block is shown in blockexplorer. Now you can see all the blocks in BE too.

Looks like you're not familiar with geeky stuff as black-and-white terminals, command line parameters and Matrix style logging. Then you should definitely try GUI for poclbm ;-).