New getwork

I uploaded a redesign of m0mchil’s getwork to SVN rev 189 (version 31601)

m0mchil’s external bitcoin miner idea has solved a lot of problems.  GPU programming is immature and hard to compile, and I didn’t want to add additional dependencies to the build.  getwork allows these problems to be solved separately, with different programs for different hardware and OSes.  It’s also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.

The interface has a few changes:

getwork [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.  [data] is the same 128 byte block data that was returned in the “data” field, but with the nonce changed.

Notes:

• It does not return work when you submit a possible hit, only when called without parameter.
• The block field has been separated into data and hash1.
• data is 128 bytes, which includes the first half that’s already hashed by midstate.
• hash1 is always the same, but included for convenience.
• Logging of “ThreadRPCServer method=getwork” is disabled, it would be too much junk in the log.

Nice, that will save a lot of patching Smiley

That’s really nice. Will it be a drop-in replacement a patched client already used by GPU miners ?

I understand the use case for external miners, but I rather like the all-in-one approach. Will I still be able to compile in my own mining code? I really enjoyed the revamped interface you introduced some time ago, and would very much like to keep on using it.

It’s not an exact drop-in replacement.  I wanted to clean up the interface a little.  It only requires a few changes.

ScanHash_ functions aren’t going away.  BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1).

Just started working on a simple CPU miner in C, mainly as a demonstration, and to understand ‘getwork’.

Repository is at git://github.com/jgarzik/cpuminer.git

Implementation is complete… but it does not work, so don’t get too excited. I suspect something weird going on with ByteReverse (or lack thereof). It’s quite unclear whether or not ‘data’ and ‘nonce’ must be byte-reversed, and in what way.

Satoshi, please fix your implementation of getwork so it complies with m0mchill’s specification

No need to do this, I’ll change the miner to comply. I am just a little busy right now.

Quote from: jgarzik on November 24, 2010, 04:47:42 AM

I suspect something weird going on with ByteReverse (or lack thereof).  It’s quite unclear whether or not ‘data’ and ‘nonce’ must be byte-reversed, and in what way.

getwork does the byte-reversing.  midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don’t have to do any byte-reversing.  They’re the same data that is passed to the ScanHash_ functions.  You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone).  If a nonce is found, patch it into data and call getwork.

I should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they’re consistent.

target is little endian, it’s supposed to be the same as how m0mchil’s did it.  (if it’s not, then it should be fixed)  That’s the only case where you would use byte reverse.  I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].

Quote from: DiabloD3 on November 24, 2010, 11:31:11 AM

Satoshi, please fix your implementation of getwork so it complies with m0mchill’s specification

This is the new spec.  It shouldn’t be hard to update your miner to use it.

The changes are:

• It does not return work when you submit a possible hit, only when called without parameter.
• The block field has been split into data and hash1.
• state renamed to midstate for consistency.
• extranonce not needed.

Figured out the problem. My sha256 algo was byteswapping the input into big endian, when it was already big endian.

First version of this new CPU miner now described here: topic 1925

Quote from: satoshi on November 24, 2010, 05:21:01 PM

• It does not return work when you submit a possible hit, only when called without parameter.

It would be immensely useful if you’d return if what I sent to the client actually was an actual hit. It makes it easier to debug issues in miners due to sanity checking.

That’s what it does, it returns true/false.