Not logged in | Sign Up
  My account  
Pool rate: 0 Gh/s
17 May 2014
17 Mar 2012
9 Mar 2012
5 Feb 2012
13 Dec 2011
13 Dec 2011
31 Oct 2011
26 Sep 2011
23 Sep 2011
10 Aug 2011
4 Jun 2011 00:00
30 May 2011
23 May 2011
17 May 2011
27 Apr 2011
2 Apr 2011
28 Mar 2011
13 Mar 2011
5 Mar 2011
28 Feb 2011
25 Feb 2011 09:16
24 Feb 2011


Long Polling protocol

Intended audience

Authors of bitcoin miners and pools.

Rational and Goals

Usually the pool gives each miner some "job" to be done - a bitcoin block header that miner will hash in search for the share. This "job" is unique for every block and should be changed every time when new block is found or new transaction is added to possible block by the pool. If someone finds a block and after this you submit your share, calculated from the old "job", it's considered stale and is wasted.

Most GPU miners need about 10-30 seconds to try all the possible hashes in this "job" and then should ask the pool for the next one, but currently it happens more frequently - about every 10 seconds miner just drops it's current job and asks for the next just to be sure that it's fresh and has all new data. Miners do have options to configure this number. The longer is this interval - the higher is your chance to submit stale share.

We decided to implement a special extension to bitcoin RPC protocol that allows pool to notify the miner about new blocks, so it can drop calculations currently in progress and immediately start the new ones without loosing time and power. We expect this to cause up to 2% rise in miner's efficiency.

Long polling protocol description

1) Miner initiates connection to the mining pool just as usual, requests getwork and starts working on it.

2) If mining pool does supports Long Polling, it should include a special header:
X-Long-Polling: /long-polling-url
where /long-polling-url is a path for long polling connection. It can be a full URL with separate port too.

3) Miner starts a request to long polling URL with GET method and same basic authorization as on main connection.
This request is not answered by server until new block is found by bitcoin network. The answer is the same as getwork on the main connection. Upon receiving this answer, miner should drop current calculation in progress, discard it's result, start working on received data and make a new request to a long polling URL.

4) If all the nonce space is exhausted during calculation or 60 seconds passed since receiving the data, the miner should request new one by means of main connection. 60 seconds limit is set to allow adding new transactions into the block.

Network stats
USD/BTC rate
Reward estimation
Stats by date
Difficulty history