Getwork - Revision history

Mikeqin: /* midstate， Typo */

2015-04-01T03:00:57Z

midstate， Typo

← Older revision		Revision as of 03:00, 1 April 2015
Line 88:		Line 88:

	=== midstate ===		=== midstate ===
	This should be advertised ~~iff~~ the miner supports generating its own midstates. In this case, the pool may decide to omit the now-deprecated "midstate" and "hash1" fields in the work response.		This should be advertised if the miner supports generating its own midstates. In this case, the pool may decide to omit the now-deprecated "midstate" and "hash1" fields in the work response.

	=== noncerange ===		=== noncerange ===

Luke-jr: /* noncerange */

2013-08-15T02:39:11Z

noncerange

← Older revision		Revision as of 02:39, 15 August 2013
Line 95:		Line 95:
	In addition to X-Mining-Extensions, the miner should also send X-Mining-Hashrate, with an integer value of expected hashrate measured in full hashes per second.		In addition to X-Mining-Extensions, the miner should also send X-Mining-Hashrate, with an integer value of expected hashrate measured in full hashes per second.
	The server may then add an additional field to the JSON response, "noncerange", which contains two 32-bit integers specifying the starting and final nonce the miner is allowed to scan.		The server may then add an additional field to the JSON response, "noncerange", which contains two 32-bit integers specifying the starting and final nonce the miner is allowed to scan.
	While both values are ~~(as with the rest of the response)~~ given in big endian, miners should iterate over the range in their native 32-bit integer type (SHA256 works with 32-bit integers, not character data).		While both values are given in big endian, miners should iterate over the range in their native 32-bit integer type (SHA256 works with 32-bit integers, not character data).
	The miner should implement rollntime by starting from the first nonce in the range every second.		The miner should implement rollntime by starting from the first nonce in the range every second.

Luke-jr: /* Pseudocode */

2013-08-13T23:23:42Z

Pseudocode

← Older revision		Revision as of 23:23, 13 August 2013
Line 56:		Line 56:
	If that meets the [[difficulty]], you win (generated a [[Blocks\|block]] or share)!		If that meets the [[difficulty]], you win (generated a [[Blocks\|block]] or share)!

	If not, increment the [[Nonce]] that is a number stored in portion of the data that starts ~~640~~ bits in (bytes 76 to 79), and try again.		If not, increment the [[Nonce]] that is a number stored in portion of the data that starts 608 bits in (bytes 76 to 79), and try again.

	If the incremented portion overflows, get new work (see also [[#rollntime\|rollntime extension]]).		If the incremented portion overflows, get new work (see also [[#rollntime\|rollntime extension]]).

Luke-jr: /* Protocol */

2013-02-11T00:40:32Z

Protocol

← Older revision		Revision as of 00:40, 11 February 2013
Line 38:		Line 38:
	020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad18020000		020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad18020000
	0000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e		0000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e
	~~312ba443105315513c1f051a0000000~~		312ba443105315513c1f051a00000000

	Note that since the result you must provide to getwork submissions is in the same format as data, you must reverse this process when you make your submission.		Note that since the result you must provide to getwork submissions is in the same format as data, you must reverse this process when you make your submission.

Luke-jr: /* Pseudocode */

2013-02-11T00:39:55Z

Pseudocode

← Older revision		Revision as of 00:39, 11 February 2013
Line 52:		Line 52:
	(Just ignore the midstate until you understand the internals of SHA256.)		(Just ignore the midstate until you understand the internals of SHA256.)

	calculate: hash = SHA256(SHA256(~~bigEndianToLittleEndianForEach32BitBlock~~(data)))		calculate: hash = SHA256(SHA256(EndianFlipForEach32Bits(First80BytesOf(data))))

	If that meets the [[difficulty]], you win (generated a [[Blocks\|block]] or share)!		If that meets the [[difficulty]], you win (generated a [[Blocks\|block]] or share)!

Luke-jr: /* Protocol */ Target endian is a complicated topic :(

2013-02-08T20:05:40Z

Protocol: Target endian is a complicated topic :(

← Older revision		Revision as of 20:05, 8 February 2013
Line 15:		Line 15:
	\| data \|\| {{Yes}} \|\| String \|\| Pre-processed SHA-2 input chunks, in little-endian order, as a hexadecimal-encoded string		\| data \|\| {{Yes}} \|\| String \|\| Pre-processed SHA-2 input chunks, in little-endian order, as a hexadecimal-encoded string
	\|-		\|-
	\| target \|\| {{Yes}} \|\| String \|\| Proof-of-work hash target~~, in big endian order,~~ as a hexadecimal-encoded string		\| target \|\| {{Yes}} \|\| String \|\| Proof-of-work hash target as a hexadecimal-encoded string
	\|-		\|-
	\| algorithm \|\| {{No}} \|\| String \|\| Brief specification of proof-of-work algorithm. Not provided by bitcoind or most poolservers.		\| algorithm \|\| {{No}} \|\| String \|\| Brief specification of proof-of-work algorithm. Not provided by bitcoind or most poolservers.
Line 44:		Line 44:
	Many optimizations are possible with SHA256, so running a full SHA256 round is generally inadvisable.		Many optimizations are possible with SHA256, so running a full SHA256 round is generally inadvisable.
	Most miners will precompute the SHA256 "midstate" from the first 512-bit chunk of data, and only repeat the 2nd SHA256 round with the final 512-bit chunk (which contains the nonce).		Most miners will precompute the SHA256 "midstate" from the first 512-bit chunk of data, and only repeat the 2nd SHA256 round with the final 512-bit chunk (which contains the nonce).

			The target is in standard SHA256 order (big endian), but note that Bitcoin target comparisons are done as 256-bit little endian.
			This means for pdifficulty 1, you want to check that the ''last'' 32 bits are zero.

	==Pseudocode==		==Pseudocode==

Luke-jr: Elaborate the protocol in much more detail

2013-02-08T19:47:19Z

Elaborate the protocol in much more detail

← Older revision		Revision as of 19:47, 8 February 2013
Line 1:		Line 1:
	An RPC method used by a miner to get hashing work to try to solve.		An RPC method used by a miner to get hashing work to try to solve.
			It has mostly been superceded by the newer [[getblocktemplate]] mining protocol, but the data format is still often used internal to some miner structures.

			==Protocol==
			getwork is a JSON-RPC method sent over a HTTP transport.
			It accepts one optional parameter;
			if provided, this must be the "data" provided by a prior request modified to meet the server's proof-of-work requirements.

			getwork without arguments provides a block header for a miner to find a solution for:
			{\| class="wikitable"
			!colspan=4\|getwork job
			\|-
			! Key !! Required !! Type !! Description
			\|-
			\| data \|\| {{Yes}} \|\| String \|\| Pre-processed SHA-2 input chunks, in little-endian order, as a hexadecimal-encoded string
			\|-
			\| target \|\| {{Yes}} \|\| String \|\| Proof-of-work hash target, in big endian order, as a hexadecimal-encoded string
			\|-
			\| algorithm \|\| {{No}} \|\| String \|\| Brief specification of proof-of-work algorithm. Not provided by bitcoind or most poolservers.
			\|}

			Because the data key has been preprocessed, if you have a generic SHA256 function you must first reverse the pre-processing.
			This is two steps:
			* Because getwork provides the data in little endian, and SHA256 works in big endian, for every 32-bit chunk you need to swap the byte order
			* Chop off the SHA-2 padding; for Bitcoin, you can just take the first 80 bytes, but otherwise you can find the correct length (in bits) as the last 64 bits of the (byteswapped) data

			So for example, if you receive this data:
			000000020597ba1f0cd423b2a3abb0259a54ee5f783077a4ad45fb6200000218
			000000008348d1339e6797e2b15e9a3f2fb7da08768e99f02727e4227e02903e
			43a42b31511553101a051f3c0000000000000080000000000000000000000000
			0000000000000000000000000000000000000000000000000000000080020000
			You first byteswap each 32-bit chunk from little-endian to big-endian:
			020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad18020000
			0000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e
			312ba443105315513c1f051a0000000080000000000000000000000000000000
			0000000000000000000000000000000000000000000000000000000000000280
			Then read the final 64 bits in big-endian - 0x0000000000000280 = 640 bits = 80 bytes - and chop off everything after that:
			020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad18020000
			0000000033d14883e297679e3f9a5eb108dab72ff0998e7622e427273e90027e
			312ba443105315513c1f051a0000000

			Note that since the result you must provide to getwork submissions is in the same format as data, you must reverse this process when you make your submission.

			Many optimizations are possible with SHA256, so running a full SHA256 round is generally inadvisable.
			Most miners will precompute the SHA256 "midstate" from the first 512-bit chunk of data, and only repeat the 2nd SHA256 round with the final 512-bit chunk (which contains the nonce).

	==Pseudocode==		==Pseudocode==

Luke-jr: /* Extensions */ Alphabetize stratum extension

2012-12-08T00:01:04Z

Extensions: Alphabetize stratum extension

@@ Line 77: / Line 77: @@
 # when current time is past <time@1+getwork expire> minus <duration of longest getwork/submit since we started this work> times 4, begin a request for new work
 # when new work arrives, discard old work and begin using the new work.
 === submitold ===
@@ Line 91: / Line 99: @@
 Example:
   X-Switch-To: {"host":"temporary.tld","port":8332,"ttr":10}
 ==See Also==
 * [[Getwork support]]

Slush at 12:45, 1 December 2012

2012-12-01T12:45:28Z

← Older revision		Revision as of 12:45, 1 December 2012
Line 91:		Line 91:
	Example:		Example:
	X-Switch-To: {"host":"temporary.tld","port":8332,"ttr":10}		X-Switch-To: {"host":"temporary.tld","port":8332,"ttr":10}

			=== stratum ===
			The server may include a X-Stratum header containing URL to its Stratum interface. If this header is present, the Stratum-capable miner should switch to the specified URL immediately

			Example:
			X-Stratum: stratum+tcp://example.com:3333

			Stratum+tcp indicates Stratum protocol with TCP transport. Theoretically pool can implement other transports as well, although at this date Stratum miners implement only TCP transport.

	==See Also==		==See Also==
	* [[Getwork support]]		* [[Getwork support]]

Luke-jr at 23:44, 27 January 2012

2012-01-27T23:44:37Z

← Older revision		Revision as of 23:44, 27 January 2012
Line 91:		Line 91:
	Example:		Example:
	X-Switch-To: {"host":"temporary.tld","port":8332,"ttr":10}		X-Switch-To: {"host":"temporary.tld","port":8332,"ttr":10}

			==See Also==
			* [[Getwork support]]