<p>If you are talking about the <a href="https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list" rel="nofollow">Bitcoin API</a>, getwork only requires <code>data</code> field, which is a place to put your solution.</p>

<p>However, I do believe that you are talking about the <code>id</code> field of a <a href="http://json-rpc.org/wiki/specification" rel="nofollow">JSON RPC command</a>. 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 <a href="https://en.bitcoin.it/wiki/Getwork" rel="nofollow">extensions to the getwork protocol</a> that you might want to use instead.</p>

CC BY-SA 3.0
2012-12-07T16:46:27.910Z
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 `id` field and both find valid shares around the same time, only the share resulting from the more recent `getwork` request 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
CC BY-SA 3.0
2012-12-07T20:34:34.557Z
@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
CC BY-SA 3.0
2012-12-07T20:36:26.760Z
@ConstableJoe The `id` is 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
CC BY-SA 3.0
2012-12-07T09:30:16.257Z
2012-12-07T09:30:16.257Z
ThePiachu
<p>When sending a <code>getwork</code> request, one always includes an <code>id</code> value. Does this value have any meaning? Will it cause problems to have multiple miners use the same <code>id</code>? Furthermore, if I wanted to send some extra information to a mining pool server, would <code>id</code> be an okay place to do it or should I add my own extra field?</p>

<mining-pools><miner-configuration><getwork>
Does the getwork id value do anything?
ConstableJoe
# Does the getwork id value do anything?

(Asked by: username_0 on 2012-12-07)

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?

**Tags:** mining-pools, miner-configuration, getwork


---

## 1 answers

### Answer by username_1 on 2012-12-07. Score: 1 | Accepted answer

If you are talking about the [Bitcoin API](https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list), 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](http://json-rpc.org/wiki/specification). 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 the getwork protocol](https://en.bitcoin.it/wiki/Getwork) that you might want to use instead.

> **Comments:**
> **username_0**: 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 `id` field and both find valid shares around the same time, only the share resulting from the more recent `getwork` request 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?  
> **username_1**: @username_0 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.  
> **username_1**: @username_0 The `id` is 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.  

---

