Is my idea of getwork protocol for bitminer right? I am trying to understand the idea behind getwork protocol, by sniffing my communication with a bitminter miner pool.

Previously I have read the discussion here, but looking at my packets, I think that there are some things which are implemented differently. I can understand that my question can be too vague, because mostly I am expressing my ideas how the protocol works, which can be totally wrong. But please do not be too harsh.

I want to go through the protocol and explain my thoughts, if I am wrong at any point of time, please explain me were I am wrong:

1) my client is authorizing on the server by sending post request

POST/HTTP/1.1
Content-Type:application/json
Accept:application/json
X-Mining-Extensions:longpollbcidmidstaterollntime
X-BCID:somenumber
X-Mining-Hashrate:my
Authorization:mySignature
Content-Length:39
Host:mint.bitminter.com:8332
Connection:Keep-Alive
User-Agent:BitMinter/1.3.0[BitMinter]


As far, as I understood the client is just telling what extensions it can support, his hashrate (based on this a server will give him a work to do), his authorization credentials.

A few things I can not understand here. What is X-BCID and what prevent client for submitting wrong hashrate? As far as I understood the server can not verify the work of all clients, so he will not be able to spot the wrong hashrate. I understand that most probably I am wrong here, but I just can not understand how is it done

2) after accepting approval for clients credentials it is asking to get work. Sometimes it has a huge string inside the params field. I can not understand what that string represents and why is it appears.

{
  "method":"getwork",
  "params":[],
  "id":1
}


3) the server is replying with the information that he supports, time after which the replies to the server would be outdated. Here also appears this X-BCID which I can not understand.

HTTP/1.1 200 OK
X-Stratum:stratum+tcp://eu1.bitminter.com:3333
X-Long-Polling:/lp
X-BCID:someNumber
X-Roll-NTime:expire=7Date:Mon,07Jan201319:52:20GMT
Server:Outpost/1.1.0 beta1
Content-Length:374
Content-Type:application/json;charset=UTF-8
Connection:Keep-Alive
Keep-Alive:timeout=895,max=5


4) together with the work that client has to do:

{
  "result":{
     "data":"huge string",
     "target":"smaller string"
  },
  "error":null,
  "id":1
}


from the above mentioned source, I understood that huge sting contains the information about the work for client (from which string to which string it has to iterate and calculate hashes) and to compare it to smaller string. So, if during the calculations I will encounter value, hashes of which will give me a smaller string, I will finish a block.
I did not understand why do I have an error field here. What is it testing?

So, my questions are:


what is X-BCID field in request 1 and 3
how the server validates the hashrate, which is submitted by the client in request 1
what is the params field in request 2, why sometimes it is empty
is my understanding about the request 4 correct, and why do we need 'error' : null, response. Is this just because of the standard of JSON-RPC and it is always null, or there can be reasons when it will be null.
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 client. At the BitMinter pool it is currently used by the variable difficulty (vardiff) implementation to determine the initial worker difficulty, until the pool has enough data to estimate a hashrate.

The params for getwork are empty when the client requests new work and has data when the client is sending in a proof of work. This is a silly thing with the getwork protocol, the rpc function is "getwork" both if you are getting work and if you are sending in work results.

The error field in the response is always present as this is required by the JSON-RPC standard. You can read more about JSON-RPC at http://json-rpc.org/