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
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 ...
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 advantage of getblocktemplate is that work units from it last longer, because you can change the extraNonce field. That's nice if you're writing an fpga miner, because it saves bandwidth.
getwork will probably never go away. It's useful and not very hard to maintain. Note that that's a personal opinion; I'm not one of the Bitcoin developers.
Pools don't measure mining rate by how many times a client calls GetWork. They measure mining rate by how many shares are submitted. A share is just like a normal block solution, except that it is million times easier to find. If you don't mine, you don't find shares.
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.
An answer can be found on bitcoin talk
Quote from deepceleron on bitcoin talk
This is your GPU returning invalid hashes from it's kernel. This is
because new drivers are crap for older cards.
Uninstall AMD APP SDK
Uninstall AMD Catalyst Install manager: choose "uninstall ...
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 ...
Isnt it supposed to be 2. The above is a really large number in big endian.
It's a small number in big endian. Think about it; big digits at the end.
Now the previuos hash block
I don't know why Bitcoin does this, but block hashes are stored in normal order internally, then byte-reversed before displaying them.
If so, what would be the max amount that a mining client can increment the ntime value?
bitcoind will accept a block and push it out to the network as long as it is valid. Because of that, it's incredibly lenient. Quoting from bitcoin wiki:
A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than ...
A nonce is just a value that you keep changing in the hope that after you hash all the data the hash will be less than the target value. See https://en.bitcoin.it/wiki/Block_hashing_algorithm (litecoin is similar only uses scrypt instead of sha256 hash function.)
In KC705_experimental, the readme says the device should return 0E33337A and two other results. It just so happens the bit of test work described in the readme has three different solutions to it. A mining script should return all three solutions to the server.
fpgaminer, the author of the KC705_experimental code, has written an addon for the Modular ...
Look at http://www.jsonrpc.org/specification: "An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null  and Numbers SHOULD NOT contain fractional parts ." To put it simply, it is really just an identifier for a ...
X-BCID is a custom extension used only by BitMinter's getwork implementation. It's a block change ID. In case long poll isn't working optimally or block changes happen too fast for long poll to catch all of them, seeing a new block change ID makes the client aware that it missed a block change.
The server doesn't validate the hashrate submitted by the ...
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.