Guys I have a few points that are not clear for me. 1) In the link below it says there are some fields we have to combine and hash. However when I get a work by saying getwork from a pool. What I get is in the below either. The problem is that I cannot find the fields listed in the first link, Version, hashPrevBlock etc.


Getwork result.

{   'data':'0000000271112b7a1cf8e97b8367102f7e155499bf5c7303cbcdd4360000000000000000427719b35a84bc7732edd34ff3a6278dc4ac0ec2a9544e6088bc0bd719e17a8e52db3b211902666600000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000',

2) It says in the first link "Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root." Should I put extra 32 bits for extranonce?

3) What is the reason reversing the header?

1 Answer 1

  1. the link you posted is referring to for the full process of mining, as you would need if you're using an ASIC or some other hardware solution capable of generating 4 gigahashes or more per second. if you're using getwork, most of that information is irrelevant and confusing.

  2. see (1) above. you don't worry about extraNonce when using getwork; you can just request getwork again and get a new data string from the server.

  3. the reason for reversing the header (actually reversing each 32-bit word in the header) is that it has already been reversed (converted to little-endian) before sending it to you and you need to undo that reversal, putting it back in big-endian form.

all you need to do when using getwork is:

  • convert the data to big-endian
  • get the sha256 hash of the sha256 hash of the 80-byte header
  • if that hash is below the threshold, send your header with current nonce to the server using the appropriate getwork RPC call with data
  • keep trying again with different nonces each time (the last 4 bytes of the 80 bytes are the nonce)
  • you mean the only thing I care about will be the last 4 bytes of the data, right? But whose last bytes, the little-endian one or the other? :) Commented Jan 26, 2014 at 10:42
  • it really doesn't matter. typically, at least on x86 computers, people increment the little-endian number, then convert the block to big-endian for hashing. I just use random numbers so I couldn't care less about endianness; just have to make sure to put it in the right order for submission to the server. Commented Jan 26, 2014 at 18:06
  • remember, it's the same 4 bytes in each case; you're not reversing the 80 bytes, you're reversing every 4 bytes within the 80 bytes, so 0x12345678 becomes 0x78563412. Commented Jan 26, 2014 at 18:13
  • In the example of 0x12345678 you are reversing every 1 byte chunks within a 4 byte value right? 0x12345678 = 00010010-00110100-01010110-01111000. 0x78563412 = 01111000-01010110-00110100-00010010 Commented Jan 27, 2014 at 1:03
  • yes, that's the idea. Commented Jan 27, 2014 at 1:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.