Last four bytes of address are check sum. Not sure what happens to first byte though.

I guess there is some minor discrepancy between what Hal used to 'encode' his private key and what we use.

0x6763, what public key do you get?

17KzV7RfQnmqcFC3cnS3RqWXQm1CREtNmj or something else?

Hal, could you please provide HEX encoded private key ?

@wolfangel91

Disregard this error, it doesn't affect functionality at all. I just missed to handle and show server-side problem properly, will do so in next release this weekend.

I have nothing against Compute4Cash.

Please just make a separate thread to promote it.

Thanks

Or perhaps we should use something like protocol buffers, even for core bitcoin messages?

This is the meaningful part of block hash. If mining by yourself you can search for it at blockexplorer.com and take a look at this exact block. It should be in your bitcoind debug.log too. When mining with pool it doesn't have much meaning - all you can see is some 'real' block found by your miner. Right now this will look something like '0002xxxx'.

The 'Unexpected error:' doesn't affect mining at all. I just missed to handle HTTP exceptions. Will add it in next version.

@[Tycho]: For example trying to figure out why 20101126 works but later ones don't. I just don't have 5970 to test on Windows right now.

Keep-alive reuses same connection if the other party (pool) supports it. Using python standard libraries 'httplib' and 'json' makes poclbm to not depend on python-jsonrpc anymore. I was actually unaware that there is 'json' in python.

If '--verbose' is specified there are no more '\r' (carriage returns) in output. You can redirect all output to file (poclbm [params] > filename). In this mode everything is on its own line, including hash rate. You may wish to use '-r 60' to have less hash rate entries in the log. Also, every single 'difficulty = 1' candidate is logged unless actual difficulty is 1.

Version is now embedded in miner - allows user to check actual version. Pools can gather statistics about different miners and report eventual problems.

Handler methods allow someone willing to create GUI for example to receive more information from the miner.

New version, please update.

Changes:

- using httplib + json, keep-alive
- optional verbose output suitable for redirection to log file
- version in code
- handler methods for hash rate, difficulty=1 candidate checks, failure



Yes, I'm aware of this problem. Unfortunately I'm still unable to resolve it. Any help from someone with 5970 on windows will be appreciated. The problem does not exist on Linux, but I can't figure out why it appeared on Windows only after the 20101126 release.

I personally run it on Win 7 64bit, but with cat 10.12 and Stream SDK 2.2 and CPU utilization is pretty low, actually close to 0% Could you please try with Stream 2.2 and post results?


There was a version which had a problem, generally not calculating correct hashes above first 32 bits. But with 20110204 I was able to find blocks on test net (which had significantly higher than 32 bits difficulty by the time).

Do you at least get 'invalid or stale' message? This should show up from time to time even if miner is broken. Bitcoin will reject the solution. But I really can't imagine other reason for not seeing anything, not even 'invalid' message - the one and only reason to not see any message for a long time is difficulty.

There are two ways to get something like this - first one is using ask rate of more than ~12 seconds with an overclocked 5870 (stock max -a is 10 seconds). Other one is network problems triggering resubmission of results - this mechanism is removed since last version. Since you said it happened with stock miner I vote for the latter. 

(OT)

@Famulus

Hi Mark, glad to see you here. I am one of your kickstarter supporters. Really nice to see you around!

How is the 'Sidney experiment' replication going?

@LobsterMan, the default '-f' is 30 now, use '-f 60' (previous default) or more if it hogs your desktop

tcatm, thank you for this miner.

Just wanted to mention that since yesterday (Feb 4) poclbm and Diablo miners changed the way of getting kernel results back to host, reducing lost results to below 0.03% (or even less).

Fixed issue with lost results due to single output per kernel run (thanks OneFixt, ArtForz).

With which version? POCLBM uses separate IO thread since 18 December, around first appearance of the pool. It however sets maximum socket timeout to 5 seconds, everything above that would result in old jobs anyway.

May I kindly ask to move this discussion to another/separate thread, please?

I had private discussion with geebus already. Will try to explain one more time here.


With bitcoin you have many much 'boxes' than 'tickets'. To be exact, the boxes and small prize tickets (pool shares) are 2^224. Grand prize tickets are currently ~ 2^209. Only one in 2^15 boxes contains a grand prize ticket. Deciding to begin another box is a probabilistic win - see the Monty Hall problem. OK, not a win, but every box is equal - checking 100 tickets from a new box completely compensates not checking 100 tickets from the previous box.

@FairUser - poclbm makes some assumptions which are counter intuitive at first look. Because it pulls jobs, there is assumption that job should live at most N seconds because otherwise you risk solving already solved block. The probability for this is roughly N/600, but practically always worse because network is growing.

Because there is no single GPU capable of exhausting the 2^32 nonces in 5 (and even in 10) seconds, poclbm does not check for nonce overflow.

Again, I kindly ask to open another thread for discussions not related to poclbm.

Miner is now fixed. It found blocks on testnet. Added verification of kernel result in host.

I will highly appreciate any reports about hash speed with this version.

Follow pyopencl instructions for manual installation.

http://wiki.tiker.net/PyOpenCL/Installation/Linux/Ubuntu

python-pyopencl depends on nvidia drivers