New getwork

[satoshi]

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.

[1714124900]

1714124900

[1714124900]

1714124900

[1714124900]

1714124900

[1714124900]

1714124900

[1714124900]

1714124900

[wumpus]

Nice, that will save a lot of patching

[davout]

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

[nelisky]

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.

[satoshi]

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).

[davout]

Btw satoshi, you should give a shot at git, it's so much better than svn, especially with lots of patches and forks going around =)

[jgarzik]

Fantastic stuff, this eliminates one of my patches completely.

I am also tempted to work on an external CPU miner...

[jgarzik]

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.

[DiabloD3]

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

[m0mchil]

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

[satoshi]

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].

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.

[jgarzik]

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:  http://bitcointalk.org/index.php?topic=1925.0

[DiabloD3]

- 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.

[satoshi]

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

[balboah]

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

I agree, and it can even be used together with the svn repository without having to migrate anything

[DiabloD3]

My miner has now been updated to use the new getwork.