Thank you for this update. I believe it will improve overall pool stability. I had to revert json error back to original HTML output, because current miners are crashing. But I will change it to json response after few days, when majority of users will use fixed miners.

In next release is also email notification about worker crash. I think it solve this problem better than watching account page manually...

Already coded (on dev version). Will be released in nearest big update.

I don't have those stats with exact numbers yet, but there are some strong players with >200mhash/s and many (say ~60) workers with few mhash/s. But it isn't surprising and it does not affect pool fairness or performance in any way. Of course many of blocks was found by strong players, but we have already few blocks between weak workers.

I'm working on better pool statistics right now so maybe I include also this performance histogram.

AFAIK helmut (nick on #bitcoin-dev IRC) is working on python implementation (based on Twisted). Personally I'm looking forward alternative python implementation...

For info: I made little tweak on pool side; it returns json rpc error in case of site maintenance (instead of 500 Server Error and some HTML stuff). I believe this is more correct for miners, but it may lead to errors like 'midstate not found', because on getwork there is simply result:null and some error text.

Hey, thanks a lot! I will add link to first thread post...


You are probably alone who like this idea  . Still I hope you won't leave us although reward formula won't change

There are few reports from users that cryptopp_asm32 is not working correctly for them. Is it known issue?

doublec has good point; please try miner with another algo and report your crash to jgarzik.


In term of pool, one share is 'block' with very low difficulty (terms 'block' and 'difficulty' are not related to pool). When you connect miner to pool, your miner thinks he is solving real blocks, but he is solving those low difficulty blocks (shares). So when miner tell you 'block found', it does not mean full block (50 BTC), but only one share in pool.

But time to time this 'share' is also valid block for Bitcoin network (reasons behind it are bit technical), so when worker submit share which is also block, 50 BTCs from Bitcoin network are divided between users using formula, which is described on pool homepage.

I hope it is cleaner to you now.

Well, during last day I talked with few people and the most of you don't like the idea, even you with strong GPUs in pool. So I decided to let it be as it is; every share has the same price and pool does not divide workers to 'strong' and 'poor' in any way.

I see your workers in system, but they have no shares yet. Please wait until miners show you found block. Then shares should be something >0. I wrote that you should have one block per hour, but of course it is still probabilistic. Maybe you are unlucky and have to wait much more for your first share.

In terms of pooled mining, share is one 'solved block' by your miner on very low difficulty. Your reward from pooled mining is adequate to "your shares / total shares * 50". More shares, more reward.


Looks like you are not connected to pool. Did you provide URL and user/pass on miner commandline? On 1000-2000khash machine you should see one solved block (=share) in ~1 hour.

Thank you Diablo for many hours of debugging and fixing this strange bug. I confirm that latest version is working very well and no shares are missing anymore. All of you using Diablo's miner, please update. It should slightly improve your shares in pool.

Also thanks for all proposals for new service name :-D. I renamed it to "Bitcoin Pooled Mining", BPM is AFAIK not related to any controversal topic :-). I also want to have 'pool' and 'mining' inside to not confuse newcomers.

After many days looking at pool stats, I see that many users which succesfully submitted winning hashes suddenly disconnected from pool. I asked few of them and their response was (in short) 'I was lucky, I found three blocks, but my pool reward was deeply under 100BTC. I don't need the pool'. Pooled mining works exactly like this; it is fair in middle/long term, not in short term. Sometimes is lucky John (and he sponsors others) and sometimes is lucky Pepa. Nobody knows when he will be lucky and when he will need 'support' from others.

Personally I understand this demotivation, because strong players who contribute 100s mhashes are de facto sponsoring tens of others for long time, until others find a valid block (but it already happen, pool has blocks also from relative poor workers).

This leads me to the idea which Satoshi described in his earlier post in this thread:


Originally, I didn't understand, why somebody should get 'premium' just because he was lucky and submit valid block. Now I'm changing my mind; it is not about probability and statistics, but also about psychology and motivation. With current rules, the biggest motivation is between slow miners, because it is their only way how to make a reward in finite time; but without strong players, there won't be thousands of mhashes in pool and no daily rewards for all participants.

I'm thinking about adding 10% (5BTC) from block as 'premium' to block founder. This should solve not only motivation of strong players to contribute to pool, but also possible problem with pool sabotages (not submitting valid block by false miner); when saboteur miss this premium, it is much bigger loss than only miss reward from share calculations. So adding 'premium reward' into pool economy should make pool stronger in two ways at once.

Final formula for calculating reward would be:
(user's shares / total shares) * 45BTC for all participating in round; next 5 BTC for block founder.
This should motivate players which pool needs and should not make big loss for others (it is only 10% less in reward if user never find valid block, which is unlikely for loyal miners)

I'm only thinking about it, I'm definitely not sure with this and I would like to discuss it with you, pool users. Please comment it and tell me your opinion. I'm also sorry for mostly incoherent content in my pseudoEnglish  

I thought puddinpop's miners are using 'proprietary' protocol (not compatible with getwork() from bitcoin RPC). I will test it on my dev environment. If it really works with pool, I'll add them to homepage.

Everytime pool find a block, all shares are set to 0 for next round. Adding new workers cannot affect it.


Shares dropped to zero because next block was found , miner segfault cannot affect it, too. But I believe it is very annoying. Please report all crashes to miner developer (you are using CPU miner, so report to jgarzik, please). Bug reports can help a lot with miner stability, because developers cannot test their software on all types of platforms.


No one share was lost during your 'problems'. Please read instruction on mining.bitcoin.cz homepage, there is described handling with shares.

Thanks Essjay for your donation. I really appreciate it!

I restarted service before few minutes because of some compatibility fixes for Diablo's miner. Please check your workers if they didn't crash during update and if so, please update to the latest version of your miner software. Main miners already solved those crashing issues.

Many thanks to RichardG and Delia for correcting and writing better texts for pool site. I will update it soon!

Please note that I'm leaving Internet for few days now. Few people from forum have phone contact to me and in case of pool problems, I can go online and fix it soon.

So, Merry Christmas and Happy Mining!

Also many people ask me why separate logins for each worker. This is just because those security checks. I'm locking job registry for each worker during checks of PoW to avoid double spending of the same PoW in parallel. So using the same login for more workers may also affects worker's performance because they have to wait for releasing worker lock.

No, not on my pool. I'm checking if PoW corresponds with job sent to worker before.