Bitcoin Forum
December 06, 2016, 08:31:18 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: PROOF-OF-WORK submitted upstream. Result: false  (Read 2707 times)
AnnihilaT
Full Member
***
Offline Offline

Activity: 196



View Profile
July 06, 2011, 11:14:23 AM
 #1

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!
1481013078
Hero Member
*
Offline Offline

Posts: 1481013078

View Profile Personal Message (Offline)

Ignore
1481013078
Reply with quote  #2

1481013078
Report to moderator
1481013078
Hero Member
*
Offline Offline

Posts: 1481013078

View Profile Personal Message (Offline)

Ignore
1481013078
Reply with quote  #2

1481013078
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481013078
Hero Member
*
Offline Offline

Posts: 1481013078

View Profile Personal Message (Offline)

Ignore
1481013078
Reply with quote  #2

1481013078
Report to moderator
1481013078
Hero Member
*
Offline Offline

Posts: 1481013078

View Profile Personal Message (Offline)

Ignore
1481013078
Reply with quote  #2

1481013078
Report to moderator
1481013078
Hero Member
*
Offline Offline

Posts: 1481013078

View Profile Personal Message (Offline)

Ignore
1481013078
Reply with quote  #2

1481013078
Report to moderator
Stephen Gornick
Legendary
*
Offline Offline

Activity: 1988



View Profile
July 06, 2011, 10:09:34 PM
 #2

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
Full Member
***
Offline Offline

Activity: 196



View Profile
July 06, 2011, 11:25:34 PM
 #3

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...

Code:
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 Offline

Activity: 112


View Profile
July 07, 2011, 01:15:15 AM
 #4

Are you running this on testnet?

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

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
July 07, 2011, 01:19:43 AM
 #5

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
Full Member
***
Offline Offline

Activity: 196



View Profile
July 07, 2011, 01:33:33 AM
 #6

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 Smiley   
AnnihilaT
Full Member
***
Offline Offline

Activity: 196



View Profile
July 07, 2011, 01:34:30 AM
 #7

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 Offline

Activity: 1666



View Profile
July 07, 2011, 01:36:14 AM
 #8

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
Full Member
***
Offline Offline

Activity: 196



View Profile
July 07, 2011, 01:41:22 AM
 #9

gotcha!  Smiley  thanks for the reply anyway!
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 08, 2011, 04:40:21 AM
 #10

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
AnnihilaT
Full Member
***
Offline Offline

Activity: 196



View Profile
July 08, 2011, 09:29:53 AM
 #11

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
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 08, 2011, 08:40:40 PM
 #12

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?

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
AnnihilaT
Full Member
***
Offline Offline

Activity: 196



View Profile
July 08, 2011, 08:45:08 PM
 #13

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
*
qt
Offline Offline

Activity: 1470


View Profile
July 08, 2011, 09:07:57 PM
 #14


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, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
AnnihilaT
Full Member
***
Offline Offline

Activity: 196



View Profile
July 08, 2011, 09:24:48 PM
 #15


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! Smiley   Is it normally for this to be happening 30-40 times an hour with a pool running at 35GH/s ?
fpgaminer
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW
July 08, 2011, 11:30:30 PM
 #16

Quote
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?
See my post, which documents the relevant code:

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

AnnihilaT
Full Member
***
Offline Offline

Activity: 196



View Profile
July 09, 2011, 12:20:44 AM
 #17

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
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW
July 09, 2011, 12:45:47 AM
 #18

Quote
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.

Quote
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
Full Member
***
Offline Offline

Activity: 196



View Profile
July 09, 2011, 12:51:08 AM
 #19

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!  Smiley

fpgaminer
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW
July 09, 2011, 12:56:52 AM
 #20

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!  Smiley


You are most welcome Smiley 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.

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!