Author

Topic: New getwork (Read 6756 times)

legendary
Activity: 1162
Merit: 1000
DiabloMiner author
December 04, 2010, 02:27:47 PM
#16
My miner has now been updated to use the new getwork.
newbie
Activity: 17
Merit: 0
November 26, 2010, 05:51:29 PM
#15
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
founder
Activity: 364
Merit: 7423
November 26, 2010, 04:31:13 PM
#14
That's what it does, it returns true/false.
legendary
Activity: 1162
Merit: 1000
DiabloMiner author
November 26, 2010, 04:17:07 PM
#13
- 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.
legendary
Activity: 1596
Merit: 1100
November 24, 2010, 07:46:34 PM
#12
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:  https://bitcointalksearch.org/topic/new-demonstration-cpu-miner-available-1925
founder
Activity: 364
Merit: 7423
November 24, 2010, 12:21:01 PM
#11
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.
full member
Activity: 171
Merit: 127
November 24, 2010, 06:56:34 AM
#10
No need to do this, I'll change the miner to comply. I am just a little busy right now.
legendary
Activity: 1162
Merit: 1000
DiabloMiner author
November 24, 2010, 06:31:11 AM
#9
Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification
legendary
Activity: 1596
Merit: 1100
November 23, 2010, 11:47:42 PM
#8
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.
legendary
Activity: 1596
Merit: 1100
November 23, 2010, 05:46:05 PM
#7
Fantastic stuff, this eliminates one of my patches completely.

I am also tempted to work on an external CPU miner...
legendary
Activity: 1372
Merit: 1008
1davout
November 23, 2010, 05:39:07 PM
#6
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 =)
founder
Activity: 364
Merit: 7423
November 23, 2010, 03:55:27 PM
#5
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).
legendary
Activity: 1540
Merit: 1002
November 23, 2010, 03:43:52 PM
#4
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.
legendary
Activity: 1372
Merit: 1008
1davout
November 23, 2010, 03:42:34 PM
#3
That's really nice.
Will it be a drop-in replacement a patched client already used by GPU miners ?
hero member
Activity: 812
Merit: 1022
No Maps for These Territories
November 23, 2010, 03:11:20 PM
#2
Nice, that will save a lot of patching Smiley
founder
Activity: 364
Merit: 7423
November 23, 2010, 02:50:12 PM
#1
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.
Jump to: