See notes section, below, to understand this format.
Edit: This is maintained as a patch, at
http://yyz.us/bitcoin/patch.bitcoin-pow-failPlease pull from branch 'pow-fail' of
git://github.com/jgarzik/bitcoin.git pow-fail
to receive the following updates:
Jeff Garzik (1):
Add -printpowfail to display hash data when proof-of-work verification fails
main.cpp | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/main.cpp b/main.cpp
index 8db6c39..d0eac7c 100644
--- a/main.cpp
+++ b/main.cpp
@@ -3397,8 +3397,12 @@ bool CheckWork(CBlock* pblock, CReserveKey& reservekey)
uint256 hash = pblock->GetHash();
uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
- if (hash > hashTarget)
+ if (hash > hashTarget) {
+ if (GetBoolArg("-printpowfail"))
+ printf("proof-of-work check FAILED...\n hash: %s\ntarget: %s\n",
+ hash.GetHex().c_str(), hashTarget.GetHex().c_str());
return false;
+ }
/// debug print
printf("BitcoinMiner:\n");
----------------------------------------------------------------------------------------------------------------------------------------
NOTESNote1: this is standard Linux kernel git pull request format; often the patches have gone through at least one round of review prior to the pull request, where the kernel subsystem maintainer has reviewed an individual submittor's changes; with this post, I'm collapsing two steps from a larger software project into one, for the sake of brevity and ease of commenting.
Note2: although the English text says "please pull", implying success, submittors never
assume success. instead, one assumes a basic loop:
- Step 1: post pull request
- Step 2: if acceptable, maintainer will pull request. yay, your change is accepted!
- Step 3: otherwise, revise based on feedback (or abandon entire approach!), and go to step #1
Note3: yes, the branch name is listed twice in "Please pull" and following line. The second line is designed to be cut-n-pasted, to make life easier for the person issuing "git pull".
Note4: the section following "receive the following updates" is the output of "git shortlog"
Note5: after that section, the statistics of the diff, as generated by diffstat(1)
Note6: then, what follows is the full patch for public review, quoting and commenting.
Note7: typically you want to pull from third parties onto a merge branch, and
then pull merge branch into the main branch, after satisfying yourself that nothing broken or "evil" has been pulled.
