Topic: PROOF-OF-WORK submitted upstream. Result: false (Read 3161 times)

You Couldnt have been clearer   thanks again!

You are most welcome I'm glad it was understandable; these concepts are not necessarily straight-forward so I'm always worried what I write will come out as unintelligible spaghetti.

fpgaminer,  

Thats absolutely the best explanation i have been able to find anywhere and answers all my immediate questions.  Thank you so much for taking the time to write that all out!  

This is because, as pointed out in the thread I linked by myself and gigabytecoin, when rpc.target.rewrite is TRUE pushpoold will perform its own check of the submitted work. This amounts to checking for 40 leading 0 bits, which is a difficulty of 256, I believe. This causes a problem on testnet, because testnet's difficult used to be lower than 256 (it's over 500 now, so I don't think this bug will show itself at the moment). Therefore, when rpc.target.rewrite is TRUE pushpoold will actually throw away completely valid work; it will only submit work that surpasses a difficulty of 256.

If rpc.target.rewrite is FALSE, pushpoold will just submit the work to bitcoind without doing that 40 zero bit check, and so it isn't throwing away work. It depends on the miners to correctly check their work against the network target.

NOTE: this is only an issue for testnet. The live network difficulty is far, far above 256, so this bug will not manifest.

It depends on how you want to use pushpoold. Typically it's used for a mining pool, where the miners are paid in proportion to the amount of work they do. The amount of work a miner does is estimated based on the number of Shares they submit, where a Share is a hash that meets at least Difficulty 1. This is where rewrite is used; it gives the miners Difficulty 1 work to perform instead of the much higher network difficulty (over one million currently). It is important to note here that a hash that meets Difficulty 1, has a small chance of also meeting higher difficulties. Hence why Difficulty 1 Shares are used to estimate miner effort.

So rewrite lets you make an estimate of the amount of work a miner has done. If you turn it off, miners will only submit hashes that result in a new block. So, whether you use it or not depends on how you're using pushpool. If you've got a private pool where you just split profits evenly amongst your friends, you might just leave rewrite off. But your friends might like the comfort of knowing their miners are actually working and submitting valid data, so turning rewrite on might be a good idea for that.

how is the rpc.target.rewrite toggle related to this?   I have found that blocks are solved extremely quickly on a testnet when this is set to false but very long when set to true.   Is there any benefit to setting this to false in a production environment on the live net?  It seems that you would not want to rewrite the target but hand it off as received from bitcoind to the client or am i missing something fundamental here?

See my post, which documents the relevant code:

http://forum.bitcoin.org/index.php?topic=10321.msg289044#msg289044

Thank you!    Is it normally for this to be happening 30-40 times an hour with a pool running at 35GH/s ?

1) pushpoold will submit all solutions with at least 40 leading zero bits.

2) cpuminer (and cgminer?) will submit all solutions with at least 32 leading zero bits.

This implies that some solutions will be rejected, because they do not meet the mainnet target difficulty.

Its a couple things actually.   FD and socket limitations in the kernel which need to be tweaked but still have limits,  inefficient coding for this type of thing in bitcoind (which has been vastly improved with some patches by a great guy on this forum).  and then you have large pools getting ddos'd for the lulz by the kiddies.   If a small pool is having problems i would guess misconfiguration of the server,  large pools are probably being ddos'd or have run into limitations in the the kernel, code, or network. 

I don't fully understand, but I will probably need to at some point if I'm going to start writing client software.  Though, even though this simple task doesn't seem like a lot of work, I do see pools like BTCguild constantly struggling to handle the load of the all the connected miners.  Clearly, something is stressing them out, though I suspected it might be a network bottleneck instead.  With even CPUs able to do millions of hashes-per-second, I can't imagine this computation would be a bottleneck even with a million miners connected.

So what is it that causes unbearable loads on the pool servers?

Yeah i was talking to a friend about this the other day and the first thing he said as well was "Well thats a lazy miner!"

But then i started wondering if maybe it has something to do with the mining software knowing that if this one isnt right the next one will overflow and a new getwork() will need to be issued anyway so its faster to just submit and start on the next bit...

I would really like to understand the internal working and logic behind this better as well.

Why doesn't the miner do a full check?  Isn't it a single hash of the block header and a direct comparison of the result to the target?  Seems like it would be an extremely fast calculation, I don't see why there'd have to be a shortcut algorithm.

gotcha!    thanks for the reply anyway!

Sorry, but I'm not a coder myself.  I know this is so because I have asked the same question in the past, and received this response from one of the developers.

This is exactly what my hunch was but im wondering if its documented in the code anywhere and if so if anyone can point me to the bit of code dealiing with this scenario?

Are you sure about this?  Maybe you dont see it happening because you dont have full verbosity debugging enabled?   This is not testnet, to answer your question    

A pool miner doesn't do a full and proper check against it's hash solution to determine if it meets the target.  All it does is a quick check of how many leading binary zeros are present, and if it is close, it submits that work to bitcoind for verification.  If the submitted work does not meet the target, this is what you get in the logs.

Are you running this on testnet?

The only "proof of work" that a pool backend should be submitting to bitcoind is the block solution.

Im seeing this from pushpool and assume its a solution being rejected by bitcoind (the network) but it happens several times a day.  I can specualte as to why this happens but i want to know for sure what condition exists to trigger this message.

like so...

Where are you seeing this?  With a miner?  If so, which one?