Getwork RPC call question

[TierNolan]

How does the RPC getwork system work?

From the wiki:

[data]     If [data] is not specified, returns formatted hash data to work on:

    * "midstate" : precomputed hash state after hashing the first half of the data
    * "data" : block data
    * "hash1" : formatted hash buffer for second hash
    * "target" : little endian hash target

If [data] is specified, tries to solve the block and returns true if it was successful.

You have solved the block if it is

sha-256(sha-256(data)) < difficulty target

Is block data just the header?

Also, is midstate the sha-256 of the first 76 bytes (to where the nonce starts)?

Presumably, this would allow the miners to save state of their SHA calculation and reset to byte 76 instead of doing the calculations over and over.

When a miner hits the target, how does it send the nonce back?

[1715658763]

1715658763

[1715658763]

1715658763

[elmigranto]

You send following json to server if you need data to work on:

Code:

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

Sever responds with:

Code:

{	"id":"json", "error":null,
	"result":{
		"midstate":"0e8a0e8d83ae508c1a0859c3a298d86676904b83803ac67323ed2c51d8e2d7f3",
		"target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
		"data":"00000001cddc2362bc4b15ef5ebf6fef9dd58bcb24ca1f05596bcd9e0000078400000000f5354d24f29a46e2c1ecf861795ffe4f26ee7cc0755098b2421dc823b42b16264e0b78c41a0c2a1200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
		"hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"
	}
}

Is block data just the header?

It's header in big-endian hexademical format with additional bytes for SHA256 (see wiki on SHA256 for details).

When a miner hits the target, how does it send the nonce back?

Same getwork reqeuest as first one in this post, except params isn't empty and has work-data with valid nonce. In hexademical big-endian ofcourse.
See source code of any miner for more details.

[TierNolan]

Same getwork reqeuest as first one in this post, except params isn't empty and has work-data with valid nonce. In hexademical big-endian ofcourse.
See source code of any miner for more details.

Thanks for the info.

[Sukrim]

Could someone enlighten me what this "id" field is good for? poclbm puts "json" in there, phoenix a single lonely 1... both receive the same getwork data though from a pool server.

[shads]

"id" is part of the JSON-RPC spec.  All requests are supposed to have an id unique to that client, the server response should include the same id.  Presumably for matching asyncronous requests with response though you'd be able to track it by connection anyway.

It's supposed to be an integer.  I think most bitcoin related implementations ignore it.

[shads]

It's header in big-endian hexademical format with additional bytes for SHA256 (see wiki on SHA256 for details).

Can you give a link for this?  I've search all over and can't find anywhere that explains how the padding should be done?  I'm currently trying to work out how to turn a header in byte array form back into a valid getwork hex string.

[kjj]

It's header in big-endian hexademical format with additional bytes for SHA256 (see wiki on SHA256 for details).

Can you give a link for this?  I've search all over and can't find anywhere that explains how the padding should be done?  I'm currently trying to work out how to turn a header in byte array form back into a valid getwork hex string.

FIPS 180-3

You want section 5.  Note that the message length is stored in Intel's crazy-endian format.