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.
extraNonce gets put into the input of the generation transaction. getwork clients can't see transactions, so they can't update extraNonce. Some miners instead modify nTime slightly to give them more nonce space.
extraNonce is used by bitcoind, but it's not part of the protocol. There is no extraNonce field in blocks or transactions.
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 ...
This question is a complicated one, but I'll see what I can do to answer it. Also, I won't try tackling the issue of endianness, as in the case of Bitcoin it gives me a headache...
First, lets see what we have in a block header given to us by getwork. Lets take the Genesis Block for an example.
01000000 - version
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, ...
If you mean a miner as in a computer that only does mining, it should be generally as resistant to DOS attacks as any casual computer on the network - it doesn't open its ports.
If you are worried about a standard client being flooded with many blocks and having to store it - the developers did think of that and they put in the checkpoint system. Basically, ...
1) Yes, it is correct.
2) It is deprecated. Generally, it is used to write the result of the mining over to be sent to the pool. This is to ensure the result is of correct length and adheres to some rules. In practice, it is always the same trailing string of numbers.
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.
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 ...
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.
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 ...
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 ...
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.
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 ...
If you are talking about the Bitcoin API, getwork only requires data field, which is a place to put your solution.
However, I do believe that you are talking about the id field of a JSON RPC command. It is used to identify a response to a given request. Generally, it might not be the best place to put extra information. There are already a few extensions to ...
A valid block that is orphaned is just as expensive to create as a block on top of the longest chain.
It makes no economic sense to create a block that has almost no chance of becoming the longest chain. Today, that costs maybe $500 per block for electricity and amortized capital to solve a block. And to DDoS you would need many many blocks, so you'ld ...
You can find some examples of the GetWork protocol here.
Generally, the pool provides a block header that is to be hashed with various nonces, as well as some additional information, such as:
hash1, which is always "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000"
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.