Btw I quite like the solution with checking new blocks using local bitcoind. Not absolutely clean, but do the job. I didn't read the code yet, but you probably need to check if the pool server really served job from new block.

I'll explain a bit. Bitcoin network can be quite slow, you can hit many second latency in block broadcasting. In this way, local bitcoind can have info about new block sooner than pool has it. Then the new request to pool returned still the data from the old one.

There are two possible solutions:

a) Check if merkle hash in new job's 'data' field is different from previous call
b) Send the pool's block height with every getwork (for example as part of HTTP header) and cross check, that this height is the same or higher than in local bitcoind.

b) is much better solution, but needs custom tweak in getwork protocol (the blocknum inside job).
a) does not need to work, because 1) The previous job could be already from new block, so next call is not necessary 2) merkle root can be changed also by new transactions (in period of one minute), not necessary by new block.

As I said, I didn't read the code so apologize if you already do this. Otherwise I hope it helps.

As I explained many times, I was on holiday and the "forced donations" concept was hot fix from crappy line in Internet cafe. Now you can see that I'm talking about "fees" on pool homepage. Don't fuck all people around, I was absolutely clear about that.

Also, please, do your business. I promise that I'll never critize your work, with one condition - stop never ending comparing with your great stuff and my the-worse-pool-ever operated by devillish slush.

No, it should be quite stable, +/- few tens of Mhash/s. As bitjet said, check your temperature (especially VRM temperature, you can use GPU-Z for this). Card is throttling down when is overheated (voltage module over 120 oC).

Also consider turning off crossfire. Many users reported troubles with minning and crossfire on. I cannot confirm that as it was working with CF for me, but it is worth of try.

Then  your earnings are OK (I didn't recalculate it, but I'm 2.2 and have ~2x higher reward).


Well, it is generally true for all current pools - you don't earn anything when you're disconnected .

But if you're asking to score based system - it works quite differently than other pools. Extremely shortly - when you disconnect, reward for your contributed shares is going slightly down (is halved every 5 minutes), but when you connect in, it goes also up faster. When you connect in the middle of the round, after few minutes your reward is almost same as if you connected on the round beginning. So the score based system only affect behaviour of connecting/disconnecting, but does not affect your final reward, at least in long term (1000+ shares contributed to the pool by your miner). As you have >1Ghash/s, this does not affect you at all. So don't be affraid with connecting/disconnecting to the pool as you want.

This works as (quite effective ) defense against some possible pool attacks. Thanks to score based system, pool can also offer all system statistics in realtime (round start, current shares in round etc). Drawback of this method is that it introduce some bigger variance in reward for CPU users (but in all cases, after 1000+ shares it is statistically without difference).

You can read more details & watch pretty graphs done by cosurgi in previous thread post.

Depends on your hashpower . If you have 1Mhash/s CPU, it is quite impressive .


With typical network speed, it takes around 20 hours. You can see block confirmations on Stats page - when block become 'confirmed', your reward from that block is moved from 'unconfirmed' to 'confirmed' (it is recalculated by server once per hour).

Long polling is still off, hope today I'll make a fix for the LP issue. You probably seen more "stale" shares before, because I did some tweaks during those two days and every time I restart server, it refuses currently opened connections.


Welcome on board :-). If is everything working for you, then just sit down and watch your wallet :-).

Depends on your hashrate, it can take a hour to find a share. It is very approximately 1 share/hour for every 1 Mhash/s in average.

Yes, there was peak in network hashrate last week, somebody pulled ~400Ghash/s into the network. This lead to higher difficulty. Now the network hashspeed is back to lower value, so difficulty is higher than should be for this week. It means that average time between two block is higher than 600 seconds so stale percentage is a bit lower.


Yes, in fact it is quite common .

I'm not familiar with this miner, but this dump looks fine for me. Yes, result: false means stale share, so if you don't see them, everything is fine.

With getwork protocol, some rate of stale shares is normal. You can calculate expected share ratio by taking average time between bitcoin blocks and your typical ask rate. Then askrate/avgblocktime = probability to hit stale share. So if you're using default settings, it should be typically something like 5/600 = 0.8%. But this may slightly differ time to time. For example, with current difficulty and hash rate, average time between blocks is longer than 600 seconds (thanks to recent operation of "mystery miner"), which also leads in slightly lower stale rate.

With ask rate of 30 second and average time betweenn blocks 600 seconds, the ineffeciency of "long askrate" is 30/600 = 5%. This is FACT. *headdesk* With this settings, it makes this pool to one of the most expensive ever, by hidden costs which most people don't understand.


I wrotte he *think*, not that he tell.


Yes, I agree. But I don't have enough self-denial to stand away when I'm reading all this. It is not anyhow related to my position of pool operator, it is just because I see how those talks about "most effective pool" can confuse new people.

By the way, I'm not motivated by shooting to everyone else's pool; You can see that I'm leaving Tycho's pool and other alone, because they don't fooling people with pseudo-science. Currently the really most effective pool is Tycho's one, not mine; It's because I had long polling still disabled.


Yes, I proven that with calculation above.


I'm trying to explain this with "normal words". I'm not native speaker and it is very hard to me, but I believe more people will understand longer explanation better than "30/600 = 5% ineffectivity". But it is fact, it is how it works.

Btw geebus didn't response why he think that other (definitely very smart) people didn't implemented longer askkrate, too. This was one of my point.


Those talks annoys me, too. I'm trying to stand outside, trust me . As my homework, I will try to not response to anything after this post .

Common, guys, why do you think that ALL people arround you are idiots? Why do you think that m0mchil, diablo, jgarzik, puddinpop and others implemented frequent ask rate in their miners? Do you really think that they had not an idea to set it to something longer? They had, but all of them understand that it is bad.  You're reinventing wheel. Wheel with four sides.

You are solving something, what is non-issue. Mining is not about shares/getwork, mining is about shares/time! Moving with ask rate, nobody will search more/less shares per unit of time. And nobody pay more bitcoins to user just because he is more effective from side of "shares/getwork".

You still calculate, that less pool load => more available capacity => more ghash. But nobody is even paid for total pool hashrate, everybody is paid for his shares/total shares. When increasing ask rate, you are lowering your pool load, but increasing probability of stale shares. This mean that every single person have LOWER effective hashrate. He has still 100 Mhash/s on his side with single GPU, but thanks to low ask rate, there are (for example) 5% stale, so user is really adding to the pool only 90 Mhash/s.

Yes, it is with minimal pool load, but he is cutting his income! You have nice tables and graphs, but they display something absolutely irrelevant ; pool users are not interested in your pool load, they are intesteted in their payouts. It's fine that you are running pool with minimal cost and for free, but people pay hidden cost in their lower efficiency (miner efficiency, not pool efficiency).

I'll try to explain that better on one absurd example:
Nonce is number with max value 2^32, it was choosen to be 32bit number by satosthi (probably). But there is no direct relation between nonce range and fact that share with difficulty 1 is one from 2^32 tries; those numbers are choosen artifically. Even better, when I did first version of pool, I could pick one share to be difficulty 2 (2^33 tries) or even more. I choosed difficulty 1 just because I liked that and others adopt my choice. So let's imagine that satoshi had good day and decided that nonce is 2^64. Does that mean that the pool will be the most effective when miners will crunch whole nonce space? Definitely not, because there will be few more blocks sooner than common miner crunch such large space and refresh his job, so majority of his done work was useless. But let's imagine, such ineffectivity! Miners are crunching only few % of 64bit nonce space!

So tell me, please, why are you so much amazed with getwork/share ratio 1:1 ? Do you finally see that there is no reason and it does not improve share rate of anybody?

Yes, I discovered problem in long polling loadbalancer, it unfortunately sometimes serve jobs from wrong backend (and then submitting those shares to correct backend leads to stale shares). I temporary turned long polling off and I will play with a configuration a little.

I'd like to announce new experimental feature, which is available on pool from today: long polling

Current "getwork" protocol is not effective enough - every miner is polling pool for new jobs once per few seconds. More frequent requests makes unnecessary network overhead and may slow down overall hashing speed because of network latency. On other side, longer "ask rate" leads to more stale shares (shares, which cannot be valid blocks, because in meantime new bitcoin block appeared on network).

Long polling is simple extension on top of current getwork protocol. Miner opens second connection to pool and pool keeps this request until new block on bitcoin network come (or up to 60 second timeout). Pool then immediately broadcast new jobs to miners in HTTP response of this "extra" connection. Thanks to this improvement, frequent "ask rate" is not necessary; with long polling mode enabled, miner can crunch hashes for whole nonce range (or 60 second timeout, which come first). This leads to higher mining efficiency, less network overhead and less pool load.

Updated miner software is everything you need to enjoy this feature. Currently, only m0mchil's poclbm miner has long polling support and there are also some known (minor) bugs. Please consider this as public beta testing and report all troubles to me or to m0mchil. Please note that pool is already sending special customized getwork response to support long polling by default, but latest poclbm cannot switch modes from command line yet, so you have to use older poclbm (version before 12/03/2011) to disable long polling feature.

Also all miner developers are welcome to support long polling in their software - it can brings crucial improvement especially for CPU mining.

In my case, attack last two hours and used 40Mbit/s of bandwidth full of SYN packets. I don't think that there is different explanation than it was purposed . Yes, somebody is trying to shut down pools.

Almost every pool had DoS issue, at least my own and jgarzik's.

afaik the transcript was discussed at least with Gavin.

Let's discuss about bitcoinpool.org on it's own thread, thank you.

Btw you can use fairuser's miner with my pool too. It is m0mchil's miner with few bullshits around. Then you can achieve the same 'high efficiency' also with my pool. But I don't recommend this to anybody not because I'm jealous to fairuser's pool, but simply because it is bad for YOU and using this modified miner, you are shooting to your leg. It is mathematically approved.

This makes sense to me - when price is going up, many people is interested in buying new cards. I noticed this on IRC weeks ago; once price is going up, much more people is solving issues with their new cards .

Before few minutes I finished important migration of data structures to new version. It is first stage in push based pool, which is in progress. During this stage I also did some performance tests of current pool. I found that because of improvements in miners (for example HTTP keep-alive) and also because many CPU users disconnected (probably because rising difficulty), there is plenty of free space available. Pool is currently running on ~30% of his capacity. Althought pool core is still 'getwork' based, I decided to open registration again to allow new users join to us.


Thanks to recent update, there are also new features and minor improvements:

• I removed "donations" select box. Thanks to all people for previous pool support with higher than (necessary) 2% donations, but now everybody has fixed fee 2%.
• I removed all database locks from calculating rewards. This means there won't be any RPC errors on new round beginning anymore. Round processing is now asynchronous; processing take less than 5 minutes after block is found. In meantime, you will see placeholder on stats page. Your 'unconfirmed reward' for the block will appear on profile page after processing finish.
• Hashmeter and getwork/s meter is fixed, no duplicated values (200+ Ghash/s) any more.
• I added pager on the worker list. This should improve user experience for people with plenty of workers.
• Times in graphs are all in UTC. This fix an issue where dates in legend and in popup differs. Dates in your local time will come soon.

Edit: I broke "active workers" stats, I'll fix it soon.

Yes, I'll open registration today.