|
Now I remember why I added the option: doesn't the internal miner call CheckWork() if 16 bits are zeroes? ie. this message would be printed a lot for the internal miner, if added unconditionally, right?
|
|
|
|
I'm with Hal-- do we really need another special-case switch? Are there significant costs to just always printing when pow fails?
Always printing is fine, too. That is what my original patch did. Shall I update my pull request to do that? |
|
|
|
Oh, and RE: extracting private keys from the wallet:
I'm less excited about that idea. What if the private keys are stored in a tamper-proof "trusted security module" hardware doo-hickey, and are impossible to export?
I put this under the category of "I own my data, and should be able to do with it what I want." Being able to import and export bitcoin keypairs to/from wallets seems an obvious need to me. |
|
|
|
|
The software is only days old. It is far too early start throwing around the 's' word.
|
|
|
|
Would it be that hard for external miners to do the extra compare, and only return solutions that actually work? I hate to see too many special-case switches.
That doesn't eliminate the utility of external verification -- being able to see what's going on, on bitcoind's side. Any number of things could break on the miner's side, making external verification useful. Maybe the hash check works, but the network code has a problem and garbles data. Or, the hash check works but we forget to byte-reverse somewhere. This patch guarantees output regardless of a PoW solution's validity. |
|
|
|
I also checked in to the bitcoin code, but it seems that the routine I'm trying to accelerate (ScanHash_CryptoPP) is only checking for a certain number of zeroes and then returning.
Correct. The scanner performs a fast-path check, and then a more exhaustive check if the fast-path check exits the scanner loop. Where is the code that checks if you've found a block? I guess it would only be a simple less-than compare in the hardware.
See CheckWork(). It is a less-than compare, on an unsigned 256-bit little endian integer. |
|
|
|
|
DerrikeG, what is your CPU manufacturer and model name?
|
|
|
|
|
Rationale:
cpuminer uses a shortcut check for "hash < hashTarget", testing a number of zero bits, then relying on bitcoin iteself to do a proper check. Several other remote miners behave similarly. Current bitcoin silently discards work that fails PoW verification.
cpuminer users have found this patch useful in observing the behavior of their remote miners. When adding -printpowfail, a bitcoin user is guaranteed that each CheckWork() call is logged, either with (a) the familiar proof-of-work-found message, or (b) this new failure message. I think others will find this minor feature useful as well.
|
|
|
|
I can't get via to work, it just starts and ends without any messages, even when -d and -P flags are provided. Running the windows build on windows XP.
Can you try this? http://yyz.us/bitcoin/cpuminer-installer-0.3.1-i486.zipThe default cpuminer is built "-march=i686", which means the compiler generates and optimizes for Intel chips i686 and later. Some VIA chips lack a few key CPU instructions such as 'cmov' that the compiler generates, and as a result, minerd.exe binaries on these older VIA CPUs will probably crash. |
|
|
|
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. |
|
|
|
|
Version 0.3.1 released. Changes:
- Critical fix for sha256_via
- Retry JSON-RPC failures (see --retry, under "minerd --help" output)
SHA1: c8da4ed8d73d71a73795b153f4ea157041cc51ba cpuminer-installer-0.3.1.zip
MD5: 69c228d4846e9940e3129a395a947080 cpuminer-installer-0.3.1.zip
Still don't know if sha256_via actually works -- testnet or pool testers requested.
|
|
|
|
another fix for Via padlock, the 64 byte offset to the data parameter in the sha256 calls should not be used for via or it should be subtracted back out in the sha256_via.c
Good catch. This seems to imply that sha256_via has never actually worked. I pushed the following change out to git... can anyone test the latest git on testnet and verify that a proof-of-work is actually found? This bitcoind patch may help debugging: http://yyz.us/bitcoin/patch.bitcoin-pow-faildiff --git a/cpu-miner.c b/cpu-miner.c
index ac151f6..138ec9c 100644
--- a/cpu-miner.c
+++ b/cpu-miner.c
@@ -319,7 +319,7 @@ static void *miner_thread(void *thr_id_int)
#ifdef WANT_VIA_PADLOCK
case ALGO_VIA:
- rc = scanhash_via(work.midstate, work.data + 64,
+ rc = scanhash_via(work.midstate, work.data,
work.hash1, work.hash,
&hashes_done);
break;
diff --git a/sha256_via.c b/sha256_via.c
index 45e6821..ef2c102 100644
--- a/sha256_via.c
+++ b/sha256_via.c
@@ -35,7 +35,7 @@ bool scanhash_via(const unsigned char *midstate, const unsigne
unsigned char data[128] __attribute__((aligned(128)));
unsigned char tmp_hash1[32] __attribute__((aligned(128)));
uint32_t *hash32 = (uint32_t *) hash;
- uint32_t *nonce = (uint32_t *)(data + 12);
+ uint32_t *nonce = (uint32_t *)(data + 64 + 12);
uint32_t n = 0;
unsigned long stat_ctr = 0;
int i;
|
|
|
|
You might want to look into reviewboard, if patches are becoming an issue. I'd definitely recommend NOT having a workflow in which people code random stuff and then it's pulled into the main repo, but rather people upload patches that are then reviewed by either you or Satoshi via some code review tool.
Any workflow that skips code review is bonkers. I don't think anybody has ever suggested that. And git has plenty of tools for code review. If you need help, just ask. |
|
|
|
One AMD radeon 5970 (570 Mhash/s) = ~ 50 * xc3s500E (11 Mhash/s). But with FPGAs the Mhash/W should be better as with GPUs.
I'm not sure what Mhash/W is. But, GPUs are ASIC so they begin with a significant advantage over FPGAs. |
|
|
|
|
This might sound strange at first glance, but I would encourage the "Linux kernel" development process, something I call "throwing spaghetti at a wall, so see what sticks."
Following the open source philosophy of "release early, release often" one sends patches (or git pull requests) as soon as a change is available and passes a developer's simple "it works" tests. If you know the change is likely to be controversial, or you cannot guess whether or not it will be accepted, change is marked with 'RFC' in the subject line.
Project maintainer (satoshi or gavin) and community comment on the change. Often, maintainer can be lazy and wait to observe community reaction to a change, before commenting. Public feedback is critically important. Developers will post dumb or off-the-cuff patches. Project maintainers and the community are expected to educate new developers via respectful feedback, posted in an open forum.
If feedback is given, developer is expected to revise their change, and repost the patch/pull request. Often this step is repeated many, many times until the change is "right." Sometimes the developer is a jackhole who persists in reposting the same annoying change over and over. We ignore these people. Sometimes maintainer gives "time is just not right for that change; come back in 6 months" -- this is disappointing, but inevitable.
If no feedback is given, and the change is not controversial, maintainer accepts patch / pulls request into git repo.
Public feedback, especially from project maintainers, is important. Existing developers must teach new developers why a change should look the way it does.
|
|
|
|
And a changelog for every release in the tarball would be nice.
At which depth of information? The full changelog is always available via SVN (and the various source tree browsers on the web), and it seems like a waste to simply "svn log > ChangeLog" for each release. |
|
|
|
Slush, maybe you shouldn't show them that they have a reward until the block is matured. Then they could count down the hours until they actually receive it. May not be too difficulty if you have a time stamp on the reward table.
Yes, there should be a distinction between "mature reward" (may be sent out to pool) and reward from blocks not yet mature. |
|
|
|
|
Current git version will retry, if JSON-RPC call fails.
|
|
|
|
|
Show Posts
