No, not specifically my address.  Although after I posted this someone did send a small amount there.  If you look at the blocks in the first post there are other addresses with previous activity that have had very small amounts sent to them recently.

Has anyone else been the recipient of unexpected subcent transactions?  I've received some very small (<0.000001) transactions in the last few days.  They weren't from myself and I wasn't expecting them.  Browsing the block chain, I see other address receiving such transactions as well.  I find this very odd, as they are paying more in tx fee than the transaction itself.  Is this some sort of probing attack, or is it just a misbehaving client?  I hope nothing nefarious is happening.  Does the client handle receiving transactions for yourself differently than other transactions?  Is there any info leak here?  I could see someone trying to probe clients with transactions to get info on which client owns what and then go into attack mode when a suitable target is found.

Here are a few examples of some blocks I noticed with these small transactions.  The destination addresses seem to be used, so I don't think these are the change address.  There are many more than these.
block 132736 has an output for 0.0000001
block 132738 has an output for 0.00000001
block 132751 has an output for 0.00000005
block 133374 has 3 outputs for 0.00000001
block 133431 has 2 outputs for 0.00000001

If anyone knows what's happening here, I'd be interested in the explanation.

There's a crash caused by accessing an array element past the last one in base58.h, in the SecretToASecret function.
vchSecret.size() is one past the last element, so it crashes here.

Since vchSecret is just a vector anyway, we can use this safer alternative:

It means you edit the serialize.h file in a text editor, and add the line
after the #include lines.


Because not everyone has the same version or configurations of the necessary libraries and compile tools, and it would be next to impossible to test all possible configurations.  This is released free and open source.  This means that while it may not work out of the box, you are free to modify it to make it work.  This does not mean you can or should expect it to work out of the box with your particular configuration.

Maybe I'll add long poll support if I'm incentivized enough to do so.


I have given a significant amount of my time to develop this and release it for anyone to use.  A few good words from a few people and a bunch of complaints from others isn't really enough to provide motivation to continue to enhance this.

Update first post with latest release.  The connection to the RPC server will now be kept open if the server supports it instead of opening a new connection for each request.

Update first post with latest release.  The connection to the RPC server will now be kept open if the server supports it instead of opening a new connection for each request.

It's returning unauthorized because you're not supplying the password correctly.  The parameter is -password not -pass.

Updated first post with latest release.  The only major change is this release will let you know if there was an issue getting work from the server and will stop hashing stale blocks.

Whatever version of libCURL you linked against isn't redirecting to the correct URL.  Use the correct URL and password parameter in the arguments instead and it should work.

If you don't see a line that says "Target = " with something other than all ffs, then the miner couldn't connect to the RPC server and couldn't download work.  Check that your arguments are correct, particularly the login info.

Aggression would be the main parameter that affects desktop responsiveness.  Set it to 1 and slowly increase it until you find a balance you like.



258.96 is an old driver.  You need a driver that supports at least CUDA 3.2 if you use the supplied binaries.  Alternately, you can compile the source with whatever CUDA toolkit you have available.



As I said before, if you don't see a line that says "Build program rval=0" the kernel didn't get built successfully and you're not going to be doing any hashing.  You can try this kernel.  If that doesn't work you'll have to edit the kernel and find out what's causing it not to build.

What rendering issues, specifically, are you referring to?  I compiled SVN revision 241 just fine on Windows, and I'm not seeing any rendering issues.  The only issue that I occasionally see is the status bar clearing all values and only repopulating when the window is resized, but it's been like that even in the vanilla client for a long time.

Did it build the kernel successfully or not?  You'll just have to find out what in the kernel is causing it not to build on your machine.


You don't need wxWidgest to compile just the rpc miners.  Set the appropriate CMake options to not compile the GUI.


bitcoinr is the remote miner that works with my open source pool.  It does not work with the various RPC pools that others have.  And the readme does include the various options for the different binaries.



4way uses SSE2 instructions, which may be faster depending on the CPU.  The -cpu miner just uses the standard CPU mining found in the vanilla GUI client.


You need to compile the .cu file targeting the 1.1, 1.2, and 2.0 CUDA architecture, and give the resulting cubin the appropriate name, and place it in the working directory before you start the miner.


Maybe try to #include in minerheaders.h, before serialize.h is included.

Updated source to bitcoin SVN rev 241.  Download available in the first post.

Updated source to bitcoin SVN rev 241.  Downloads available in the first post.

You need to install the Microsoft Visual C++ 2005 Redistributable Package (x86)

Did you put the screensaver and related files in the SysWOW64 directory?  If you put it in the system32 directory, that might be why you cannot see the settings.  system32 is only for 64 bit files on 64 bit Windows, but the screensaver is a 32 bit application.

The last release does not need cutil when compiling the CUDA RPC miner, and likewise the CUDA daemon or GUI miners, since they all share the same miner code.  Only the remote miners still need it.  If you are using CMake to create makefiles, it is likely you didn't turn off building of the remote miners.

Did you get it to work with the older kernel?



No.  The hash rate is constant here whether the window is in the foreground or background.  You can try different graphics drivers (newer AND older) to see if that helps.  It could also be something with Windows 7 interfering with the priority of background apps.

You can use the .cl file from the last release.  If you are so inclined, you can edit the current .cl file and see which changes are keeping the kernel from building.  There weren't too many changes, so it should be obvious what the culprit is.