2
When sending a getwork request, one always includes an id value. Does this value have any meaning? Will it cause problems to have multiple miners use the same id? Furthermore, if I wanted to send some extra information to a mining pool server, would id be an okay place to do it or should I add my own extra field?
I'm a little confused about the difference between the Bitcoin API and the JSON RPC API; I'm talking about the command a miner sends to the pool to get (or submit) work. Does this mean that if two miners both use the same
idfield and both find valid shares around the same time, only the share resulting from the more recentgetworkrequest will be accepted by the pool? And is there a problem with adding an extra field to send extra information (not info supported by any current extension), or will that confuse pool servers? – ConstableJoe – 2012-12-07T16:46:27.910@ConstableJoe The difference between Bitcoin API and JSON RPC, is the same as difference between HTML and HTTP - one builds on top of the other. JSON tells you how to send your data, it's like an envelope you address. Bitcoin API is like the stuff you put in that envelope - it can be a letter, but also confetti, strings or something else. Generally, you don't want to mess with the envelope when you can mess with its insides. – ThePiachu – 2012-12-07T20:34:34.557
@ConstableJoe The
idis used to identify the message, but from what I found most people just set it to 1 and it works fine. It might be useful when you are sending many packets. Then you yourself would know what you are receiving and so forth. I guess it's mainly useful for asynchronous communication or something.Adding extra information might confuse the pool. Generally, the pool received an array of data - if it sees a non-empty array, it assumes it's a solution and tries to read it. If it is not formatted like one, the result will most likely be an error. – ThePiachu – 2012-12-07T20:36:26.760