I've tried the following patch on a VIA Nano L2200 @ 1600 MHz on a Debian unstable amd64 system.

The speed increase is almost negligible. I've compiled minerd with using -O3, and with the patch, I'm getting really close to1700kh/s. Without the patch, I'm getting about 1680. Using the builtin seems to gain 1% speed or so.

I've tried it on the testnet and got a good hash really quickly, so it seems to work ok.

If you found my post helpful, feel free to send a small tip to 1QGukeKbBQbXHtV6LgkQa977LJ3YHXXW8BVisit the BitCoin Q&A Site to ask questions or share knowledge.0.009 BTC too confusing? Use mBTC instead! Details at www.em-bit.org or visit the project thread to help make Bitcoin prices more human-friendly.

sorry--that was a mistype in my post. I am running the command with the proper spelling (I've also gone by IP address). I still get the 400 error, which is a malformed request, so that's why I was guessing compile error?

If you found my post helpful, feel free to send a small tip to 1QGukeKbBQbXHtV6LgkQa977LJ3YHXXW8BVisit the BitCoin Q&A Site to ask questions or share knowledge.0.009 BTC too confusing? Use mBTC instead! Details at www.em-bit.org or visit the project thread to help make Bitcoin prices more human-friendly.

I just have a question about how the miner behaves after it has found a solution to a piece of work. I briefly looked at the code and the run loop goes something like this:

while (running) { get_work();

rc = find_solution(); // NOTE: solution here is for a reduced difficulty than that required to generate a new bitcoin block and generate 50 BTC. if (rc) { submit_solution(); }}

So my question then is what will happen, and what should happen, when a solution is found part-way through a block of work? Does the miner continue looking for further solutions, or does it throw away the rest of the piece of work? (I guess as well the answer partially depends on what the mining server is expecting).

If it throws away the rest of the piece of work that means the miner is behaving differently to the vanilla bitcoin client - in that case the worker loop keeps going until a solution is found (or someone else beats us to the solution). Would there be any reason for the miner not to continue as well?

So my question then is what will happen, and what should happen, when a solution is found part-way through a block of work? Does the miner continue looking for further solutions, or does it throw away the rest of the piece of work? (I guess as well the answer partially depends on what the mining server is expecting).

If it throws away the rest of the piece of work that means the miner is behaving differently to the vanilla bitcoin client - in that case the worker loop keeps going until a solution is found (or someone else beats us to the solution). Would there be any reason for the miner not to continue as well?

If a solution is found, it is pointless to continue work on that block. You cannot solve a block twice.

So my question then is what will happen, and what should happen, when a solution is found part-way through a block of work? Does the miner continue looking for further solutions, or does it throw away the rest of the piece of work? (I guess as well the answer partially depends on what the mining server is expecting).

If it throws away the rest of the piece of work that means the miner is behaving differently to the vanilla bitcoin client - in that case the worker loop keeps going until a solution is found (or someone else beats us to the solution). Would there be any reason for the miner not to continue as well?

If a solution is found, it is pointless to continue work on that block. You cannot solve a block twice.

I should clarify - I meant specifically in the case when the miner is running as part of a pooled mining effort like the one Slush is running.

The blocks the miner is solving are of a lower difficulty than required to generate a new Bitcoin block and generate the 50 BTC, but of a high enough difficulty to earn a share in the 50 BTC. It is the pooled mining server that evaluates whether or not the solution is good enough to meet the main bitcoin difficulty level.

By giving up on this piece of work and moving to the next I might be missing out on a) finding another solution within the same block of work, and therefore another share in the eventual 50 BTC, and b) more importantly, finding a solution within the block that reaches the main bitcoin difficulty threshold and so the whole pool is missing out on a chance of generating 50 BTC.

I've only just started using bitcoin so maybe I missed something obvious - please tell me if this is the case.

By giving up on this piece of work and moving to the next I might be missing out on a) finding another solution within the same block of work, and therefore another share in the eventual 50 BTC, and b) more importantly, finding a solution within the block that reaches the main bitcoin difficulty threshold and so the whole pool is missing out on a chance of generating 50 BTC.

.....

You are right. --- But, consider this:

1. The miner is general purpose. It have to work with the official bincoin client.

2. You have to get a new block when a new block is generated on the network (this is every ~30sec). You need extra lucks to get two blocks in 30s.

Of course you can have it work for more blocks, but the only time saved is one json-rpc request.

Cool, I like simplicity of your code. I want to try similar implementation in javascript. Partially because of curiosity and partialy because (inspired by hashcash) it can generate few hashes by fighting comments spam :-).

I just made few tests. In four javascript threads I get ~4khash/s, which is EXTREMELY slow. Probably because javascript is interpreted and without any JIT yet. Would be great if javascript supports GPU. Flash will support GPU soon, so we will see .

I do find the idea of web sites generating bitcoins using their visitor browsers very entertaining. If nothing else, it's a novel idea to monetize your traffic without having to hope your ad network won't get moody on you. Also, a little devious. No downside.

Random ideas in no particular order:

- Flash Pixel Bender. GPU-rendered shaders. Not too sure how practical it is to use that to compute hashes.- WebGL. more GPU-rendered stuff. meant for graphics too. see above.- Web Workers: where available, will allow CPU-intensive JS code to run without noticeably slowing down the browser UI. Unfortunately, can't be used to control GPU approaches, but good as a CPU fallback method. Note that many JS engines are using JITs now. you'll get very different results on different browsers.- unload event handler using a synchronous XHR: fairly reliable way to sync up whatever the browser computed back to a server when the user navigates away. except on some browsers, where periodic syncs are the only way.

Mix it all in a bag, use shaders creatively ( maybe a pixel could encode whether a bunch of hashes met some criteria for example), and you might get hashrates that don't totally suck, multiplied by whatever amount of traffic your site gets.

Interestingly, if the hashrates somehow approached what a real GPGPU solution can output (unlikely as that may be), then miner pooling sites could offer install-less approaches to participate in the pool..

Thanks so much @tuxsoul!! If I can ever get set up with the pool I'll be sure to send a donation your way. I'm afraid that even with the proper compile I'm getting the http:400 error. Can anybody provide some insight? The full message is:

and appears no matter what options I run minerd with (against http://mining.bitcoin.cz:8332 that is). I have an account set up and am using that user/pass but is there a test account too? Thanks in advance!

If you found my post helpful, feel free to send a small tip to 1QGukeKbBQbXHtV6LgkQa977LJ3YHXXW8BVisit the BitCoin Q&A Site to ask questions or share knowledge.0.009 BTC too confusing? Use mBTC instead! Details at www.em-bit.org or visit the project thread to help make Bitcoin prices more human-friendly.

HTTP 40x server returns when JSON response is different that miner should expect. That means bad login, bad password, malformed request and so on. Typically the JSON response tell you what wrong happen. I don't know why miner does not display this message to user...

Found it! (little bit of egg on my face though ) Usernames are case sensitive, and mine was autofilled as "eMansipater" when signing up for the account. D'oh!

If you found my post helpful, feel free to send a small tip to 1QGukeKbBQbXHtV6LgkQa977LJ3YHXXW8BVisit the BitCoin Q&A Site to ask questions or share knowledge.0.009 BTC too confusing? Use mBTC instead! Details at www.em-bit.org or visit the project thread to help make Bitcoin prices more human-friendly.