Bitcoin Forum

Hi all! I've built a simple client that works against the JSON-RPC HTTP endpoint, it works OK. Built it using the HttpClient of Microsoft.Net.Http.dll and extensions in the http://wcf.codeplex.com/ release.

Now the question is, what do I do with the results I get from getwork? Is there are good description on the basics of just building a miner? I'm building this on .NET (C#).

Thanks in advance for any help, I did some searching on the forum but couldn't easily find what I was looking for.

I was going to try to explain it, but I'd probably get it wrong.

https://en.bitcoin.it/wiki/Block_hashing_algorithm

If anyone would like to explain the info that the getwork rpc command gives you, here's a page where you can post it: https://en.bitcoin.it/w/index.php?title=Getwork
The explanation of getwork https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list#Full_list (which is just copied from the bitcoin source code) is not very explanatory at all.

I see the block header in the first 80 bytes of the "data", and I see the "target", but I have no idea what the "midstate", last 48 bytes of "data", and "hash1" are for.  The block hashing algorithm is simple, but the info that getwork returns needs more explanation someplace.

Neither of those links explains to me the basics of how to build an miner app, which is what I'm trying to do... Any more links?

You have the json-rpc part done.  The block hashing algorithm explains how to generate a block.  The missing piece is what does all of the information returned from the getwork command mean?  Most of that info is still a mystery to me, which is why I created a link to a wiki page so maybe someone else will explain it there for us.

Otherwise building a miner just means you write a program that calls the getwork command on a bitcoind server and then uses that information as the starting point for generating a block according to the block hashing algorithm linked to above.

I do not believe there are any good explanations of how to build a miner anywhere, yet.  I'm writing a bitcoin client, myself, rather than a miner, so I don't know what some of the getwork information means.

You might have to spend some time digging through the code of some other miners that call the getwork command.  There's a list of 4 different miners down in the "How do I get started?" section of slush's pool page: http://mining.bitcoin.cz/

if anyone knows how to build a miner, please explain. I think the best is to put a pseudo-code in the wiki after all coments...

Just ignore the midstate until you understand the internals of SHA256.

calculate: hash = SHA256(SHA256(data))

If that meets the difficulty, you win!

If not, increment the portion of the data that starts 640 bits in (bytes 76 to 79), and try again.

If the incremented portion overflows, get new work.

You could read this cpu miner C code to learn the algorithm.  It's pretty easy to read:

https://github.com/jgarzik/cpuminer

The algorithm you are looking for is mostly in miner_thread of https://github.com/jgarzik/cpuminer/blob/master/cpu-miner.c and in scanhash_c of https://github.com/jgarzik/cpuminer/blob/master/sha256_generic.c

It would probably be best not to try to build one in C# if you want to be mining for profit.
You will be competing with miners running against bare metal gpus.

Second, you would need to port the whole protocol to c# first if you want to actually mine directly from the network.
This is a huge undertaking. Bitcoinj is still working on it and thats being done by people who understand the protocol.

If you really want to see how the mining works you can look at this piece of code from bitcoinj:
http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/Block.java#203
That part is easy.... its everything going on around it that you have to implement first that will make you pull your hair out.

Thanks, just_someguy.

It looks like midstate is the optimization I was curious about myself: Since SHA-256 works on 64 Byte chunks at a time, and the first 64 Bytes of the data is constant for a header, it doesn't need to be recalculated when you just increment the nonce, since the nonce is in the second 64 Byte chunk.

The other, smaller optimization I see is that, since the nonce is the 4th byte of the second 64 Byte chunk, as long as the first 3 bytes of that chunk are held constant, the sha256_transform iterations up to when W[3] is referenced will be constant, so those values could be cached for all the nonce values tried on an otherwise constant header.