I'm not paranoic, but don't trust anyone's security just because it's big player. Facebook logins can be hacked, too. Personally I also use facebook login to some pages, but I'll think twice to use it for my bank account login (which mtgox is)...

It is possible, but the network latency is big problem then. It will slow down your miner a lot.

Man, everybody is talking you that finding a share from work is random. There is nothing as 'exactly one share hidden in every getwork'. There is 1 share in every getwork in AVERAGE, because difficulty 1 means there is one solution per every 2^32 attempts. And 2^32 is the size of nonce, which miners iterate. Nothing more.

And no, title of this topic should not be 'how is poclbm skipping blocks', because it isn't true.

Yes, this will work.


Irrelevant in this discussion. You are skipping some nonces, but you are crunching another nonces instead. No block lost.


As pool hashrate is +- constant in one round, you can keep getwork/s * round time to get this.


I don't calculate it now, because I simplified the code with the last update, but I have those number for ~5 millions of shares. Stale blocks were something around 2 %.


I have those numbers, but I'm not interested to make fancy GUI to provide this. I can publish database dump if you're interested.

I'm not interested because pool does not earn bitcoins on getwork/share efficiency. Going to 1:1 ratio is mostly irrelevant, it's only game with numbers. I think you still don't understand this . What to do with slow CPU miners, which crunch whole space for 2-3 minutes? They should crunch whole nonce just to have fancy 1:1 ratio on pool page?

Of course effectivity of network transfers is nice. You can buy stronger GPU and your getwork/submit efficiency will be higher. But this is not a point. The point is to consistently crunch valid blocks. Thats all.

Btw I think we're slightly offtopic here.

You can call it whatever, but with long getwork period, you are hashing shits for many % of time :-).


Well, getwork is not a puzzle. It is random walk, when you hit valid share time to time. Nonces are just numbers. It's irrelevant if you are trying to hash 0xaaaa or 0xffff. The probability that you hit valid share is still the same.


Well, this is the only point which make sense. Diablo already implemented this and if it isn't in m0mchil's, it would be nice to implement it, too. But it's definitely on m0mchil decision, not on us.

Also sorry for some impatient responses, but I'm responding those questions to pool users almost every day and it become little boring . It isn't anything personal. To be honest, it isn't long time ago when I had very similar questions as you have right now. But thanks to m0mchil, Diablo and few other people on IRC, now I know how much wrong I was .

Did you noticed that it is the same nonce? It is absolutely fine that second attempt was rejected. As I wrote before, I don't know the reason *why* there was second attempt. Afaik, nonces should be sorted from 0 to ffffffff, but maybe there is some simple answer behind mixing of nonces (more solving thread or whatever). Maybe it was only reupload after lost connection, whatever. Maybe m0mchil will response this, I don't know miner internals.


because - as I already wrote - share can be rejected for more reasons. The reason for this rejection is that miner uploaded same nonce twice. It is not relevant to any bug in getwork, skipping some nonce ranges or any other weird stuff you are arguing here.


Because with skipping some nonce range, shit happen. In fact, you are skipping zillions of existing nonces. How can you live with that? :-)


And I said it is nice, but not necessary optimization of miner. This only optimize network latencies, because miner is asking less often, but it does not improve probability that share will be found.

Maybe I'm wrong, but you are not paid for higher getwork/submit efficiency, but for finding valid blocks. So you are optimizing wrong thing . Maybe you can get 100% getwork/submit ratio, but you are crunching old jobs. But it is your choice and your hashing power.

There is no reason why there should be valid share in every getwork.


No overlapping, every getwork is unique. Read more how getwork() works. Especially the extranonce part.


No. It may be because another bitcoin block was introduced in meantime between getwork() and submit. Then share from old block cannot be candidate for new bitcoin block. Read my last posts in pool thread. By the way, this is not pool/m0mchil miner related, it is how bitcoin works.


And he was true. Longer ask rate, more hashing overhead.


By skipping some nonce space, you don't cut your probability to find valid share/block. There is the same probability of finding share/block by crunching any nonce.


Definitely not. It is only nice optimization for pool to continue hashing of current job, it save some network roundtrips, but it basically does not affect pool success rate.

I see no problem here.


I don't know why miner uploaded same nonce twice, but it is fine that second attempt wasn't counted. Btw I'm expecting that nonce is rising from zero, so looks weird for me that nonces are mixed.


That's fine, isn't it?


I thought that miner is already doing this. At least Diablo's isn't stopping when 'block' is found. Don't forget that this is tweak only for pool, because with crunching real-difficulty hashes, second nonce cannot be valid bitcoin block in any case...


You should put it back. Otherwise you are crunching invalid work for long time (~ 30/600 seconds, so 5% of time is wasted). Plus pool now reject shares which cannot be valid bitcoin blocks, for more info read pool thread. So this isn't improvement in any case.


how did you calculated 20-30%? It isn't correct.

Yes, less often getwork update saves some resources, but will make mining much less effective.

Personally I don't understand why are you posting this, because I already answered all those questions in PMs...


Nothing or not any significant amount. Learn basics of statistics and visit pool stats page...

...which doesn't solve current problem with testnet. Testnet difficulty is not insanely high, it is still possible to mine a block with a decent hardware in a hour or so. But it is too high to effective testing some software, where you need many blocks to pass all tests.

I see your point and partially agree. Some better algorithm to lower difficulty should be adopter both to testnet and main net. But for current situation, changes which Gavin proposed are fine for me.

Yes, looks like we had hard times in previous 20 hours. Hope it is behind us :-).

It is weird, but I don't see any troubles on the pool side. We already had days where only few blocks were found.

Correction. Price is almost at 0.5, so many people begin to withdraw their bitcoins because they don't believe it will cross over 0.5 easily. Same situation as you highlighted @ 0.3 level...

I think you didn't get the point of the last update. This change does not affect calculating rewards in any way, because everybody has the same probability to hit 'stale' share. It only affect absolute numbers of shares in round, there will be ~1% less shares per round (in global and also per worker).

Worker doesn't get an 'invalid or stale', but the share from previous block cannot be valid Bitcoin block, so I don't see the reason why to accept this.


Well, I'm sure. This change affected only counting of shares, not validating hashes against bitcoind. Even if I made some strange mistake in this update (which I don't expect), pool don't miss any block, because every share is still fully checked.

Hi FairUser,

'invalid or stale' for unique nonces can be explained by pool update. Pool now doesn't accept shares when new bitcoin block come (see pool thread for more). Now it works in the same way as standalone mining.

About same getworks - it looks like network troubles, which are more and more common. I hope that it will be solved by protocol change, which significantly reduce network communication. Will be introduced this week.

Today's pool update introduced small change in counting shares. Only submitted shares which are valid for current Bitcoin block are calculated. So if your miner ask for job and submit a share, it isn't calculated if new Bitcoin block arrived in meantime and your share cannot be a candidate for next Bitcoin block. This does not affect fairness of pool, when your miners are configured correctly. Please check your miners, if they does not use custom getwork timeout. Default period of getwork (typically 5 seconds) is the best settings. In this way, you should obtain 'stale' shares only with ~1% probability.

Please note, that also other miner settings can affect time between getwork() and share submit. For example, "-f 1" parameter in Diablo miner rised latency between getwork and submit significantly (from <5s to >10s for ATI 5970). I solved this by "-f 5".

I don't think so, but I'm not an expert for this.  You can ask anybody else in #bitcoin-dev, because this is not pool-related question.

I just restarted pool server application. All of you who changed worker passwords on website recently, please check if your workers are working correctly. I see some "Bad password" messages in server log. This is because I still didn't fixed reloading worker credentials from database to running application, so if you changed passwords before few days, NOW it was applied O:-).