|
AnnihilaT (OP)
|
 |
July 06, 2011, 11:14:23 AM |
|
Can anyone explain to me what this message means or point me to the bit of code that generates such a response as in the subject above?
Im fairly certain i understand what it means but just would like some validation that my understanding is correct!
thanks alot!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Be very wary of relying on JavaScript for security on crypto sites. The site can change the JavaScript at any time unless you take unusual precautions, and browsers are not generally known for their airtight security.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
Stephen Gornick
Legendary
 Offline
Activity: 2506
Merit: 1010
|
|
July 06, 2011, 10:09:34 PM |
|
Can anyone explain to me what this message means or point me to the bit of code that generates such a response as in the subject above? Where are you seeing this? With a miner? If so, which one? |
|
|
|
|
AnnihilaT (OP)
|
|
July 06, 2011, 11:25:34 PM |
|
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... Jul 4 02:17:52 pool_node01 pushpoold[28216]: [::ffff:<ip>] PROOF-OF-WORK submitted upstream. Result: false
Jul 4 03:38:41 pool_node01 pushpoold[28216]: [::ffff:<ip>] PROOF-OF-WORK submitted upstream. Result: false
Jul 4 07:52:31 pool_node01 pushpoold[28216]: [::ffff:<ip>] PROOF-OF-WORK submitted upstream. Result: false
Jul 4 10:14:27 pool_node01 pushpoold[28216]: [::ffff:<ip>] PROOF-OF-WORK submitted upstream. Result: false
Jul 4 16:41:21 pool_node01 pushpoold[28216]: [::ffff:<ip>] PROOF-OF-WORK submitted upstream. Result: false
|
|
|
|
|
1bitc0inplz
Member
Offline
Activity: 112
Merit: 10
|
|
July 07, 2011, 01:15:15 AM |
|
Are you running this on testnet?
The only "proof of work" that a pool backend should be submitting to bitcoind is the block solution.
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
July 07, 2011, 01:19:43 AM |
|
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.
|
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
|
AnnihilaT (OP)
|
|
July 07, 2011, 01:33:33 AM |
|
Are you running this on testnet?
The only "proof of work" that a pool backend should be submitting to bitcoind is the block solution.
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  |
|
|
|
|
|
AnnihilaT (OP)
|
|
July 07, 2011, 01:34:30 AM |
|
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.
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? |
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
July 07, 2011, 01:36:14 AM |
|
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.
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? 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. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
|
AnnihilaT (OP)
|
|
July 07, 2011, 01:41:22 AM |
|
gotcha! thanks for the reply anyway! |
|
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
July 08, 2011, 04:40:21 AM |
|
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.
|
|
|
|
|
AnnihilaT (OP)
|
|
July 08, 2011, 09:29:53 AM |
|
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.
|
|
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
July 08, 2011, 08:40:40 PM |
|
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?
|
|
|
|
|
AnnihilaT (OP)
|
|
July 08, 2011, 08:45:08 PM |
|
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?
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. |
|
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1091
|
|
July 08, 2011, 09:07:57 PM |
|
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.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
|
AnnihilaT (OP)
|
|
July 08, 2011, 09:24:48 PM |
|
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.
Thank you! Is it normally for this to be happening 30-40 times an hour with a pool running at 35GH/s ? |
|
|
|
|
|
|
|
AnnihilaT (OP)
|
|
July 09, 2011, 12:20:44 AM |
|
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?
|
|
|
|
|
|
fpgaminer
|
|
July 09, 2011, 12:45:47 AM |
|
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? 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 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? 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. |
|
|
|
|
AnnihilaT (OP)
|
|
July 09, 2011, 12:51:08 AM |
|
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! |
|
|
|
|
|
fpgaminer
|
|
July 09, 2011, 12:56:52 AM |
|
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! 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. |
|
|
|
|
