|
Title: Getwork RPC call question Post by: TierNolan on June 29, 2011, 02:23:27 PM How does the RPC getwork system work?
From the wiki: Quote [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? Title: Re: Getwork RPC call question Post by: elmigranto on June 29, 2011, 07:13:33 PM You send following json to server if you need data to work on:
Code: {"method":"getwork","params":[],"id":"json"}Code: { "id":"json", "error":null,Quote 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).Quote 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. Title: Re: Getwork RPC call question Post by: TierNolan on June 29, 2011, 07:49:42 PM 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. Title: Re: Getwork RPC call question Post by: Sukrim on July 06, 2011, 12:43:39 AM 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.
Title: Re: Getwork RPC call question Post by: shads on July 06, 2011, 03:44:40 AM "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. Title: Re: Getwork RPC call question Post by: shads on July 06, 2011, 03:55:32 AM 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. Title: Re: Getwork RPC call question Post by: kjj on July 06, 2011, 01:52:50 PM 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 (http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf) You want section 5. Note that the message length is stored in Intel's crazy-endian format. |