This really helped me understand it:
A solo miner increments Nonce until it overflows. Then it increments extraNonce and resets Nonce. extraNonce is located in the coinbase transaction, so changing it alters the Merkle root. extraNonce is reset based on the time.
Stratum: the server gives the client templates that the client can use to generate its own work. Only the block header and first transaction (generation transaction) are included. Stratum uses the least bandwidth of all the protocols. Stratum also makes it very fast and efficient to switch to new work data when there is a block change, which can help keep ...
getwork is for all intents, completely deprecated due to it's inefficiency. At this point a single ASIC device can completely swamp a bitcoind with requests as they're able to exhaust the 32bit nonce in a fraction of a second. The situation is severe enough that pools like BTC Guild have extraordinary large (6%+) fees on clients using getwork in order to get ...
The miner you are using does not support the stratum protocol. Instead you must use a pool that uses the old and now obsolete getwork protocol
If I see it correctly BTCGuild still offers the getwork access with the following URL:
minerd.exe -o http://btcguild.com:8332 -u username_1 -p password -a sha256d -R 2
Most miners now use Stratum, but the old getwork protocol isn't completely gone yet.
The URL is the root path (/) of the server usually at port 8332, for instance http://mint.bitminter.com:8332. You can see what the data looks like here: How can I code a Bitcoin JSON-RPC "getwork" request in Java?
No, this is JSON-RPC. It's an RPC-style interface, ...
The getwork RPC call was removed from Bitcoin Core. It was deprecated and then superceded by the getblocktemplate RPC call.
It looks like the pool that you are using uses an unspecified protocol. It's just a tcp connection where you are sending JSON formatted strings and receiving JSON formatted strings from the pool server. I figured this out by digging ...
If you run out of work while waiting for longpoll to finish, then what you should do is submit another getwork request.
Note that just because you find a share in a particular piece of work, doesn't mean that you're done with that piece of work. There still might be shares or even a block solution in there somewhere.
The proof of work that miners do is a double sha256 hash on 80 bytes of data.
Where do the 80 bytes come from?
They are build from enough data to describe the current block (and the transactions it contains) and a pointer to the previous block.
4 bytes version number
32 bytes hash of the previous block
32 bytes Merkle root of all the transactions ...
For everyone else, who stumble upon this question :
I've written a Java wrapper around the JSON-RPC provided by bitcoin/litecoin.
It uses Htmlunit & GoogleGson and quite easy to understand and extend.