# Can a Bitcoin miner generate SHA2 hashes on arbitrary data?

I'm not asking about bitcoin's design...but am interested in the hashing capacity of a bitcoin miner.

To be short: do bitcoin miners(or some of them) accept customizable inputs and hash them in bulk(instead of accepting some more high-level instruction and do mining works automatically)?

The real question is, I've read some articles about a signing scheme of post-quantum cryptography, the Merkle Signature Scheme(MSS):

This new way of doing digital signature requires lots amount of hashes being calculated, for example:

1. a single One-Time-Signature(OTS) requires at least 512 times of hashes if we use SHA-256 with an output size of `512*256/8=16kBytes`.

If smaller output is desired, which requires a time-memory tradeoff, e.g. to reduce the size by nearly 8, it requires `2^8 * (256 / 8) = 8192` hashes with an output size about `256 * 256 / 8 / 8 = 1024 Bytes`; to reduce by 16, it requires `2^16 * (256 / 16) = 1048576` hashes with an output size about 512 bytes.

2. each signature of MSS consists several OTSes, which are authenticated by chained binary trees(the OTS on one leaf is used to authenticate the underlying tree's root public key), which means, for n trees there exists n OTSes to be done.

3. to calculate the tree's root public key, it may be necessary to hash the whole tree: with m levels, it takes about 2^m hashes.

And finally, in this way a life of `n*m` may be achieved(the limit of doing signature). For example: if `2^80` signatures are being designed, with `n=4, m=20` and a tradeoff with 16, for worst case it takes `4*1048576 + 4*2^20=8388608` hashes(but with an attractive output size about `(256*256/16*4+80*256)/8=4608Bytes` compared with popular algorithms).

This requirement seems too high for software(OpenSSL may do that in 3 seconds, but if one signature takes 3 seconds, why should we design a life of `2^80` signs?), but for hardware like bitcoin miners, it seems still too easy(not sure, I've never played with that). So I've been considering the possibility of adapting a bitcoin miner into a hardware acceleration for such signature algorithm. In order to do so, it's necessary to feed the miner with inputs that we want it to calculate. Is this possible?(I think it should, since they should at least allow some user-related parameters to be customized into hashcash tests...)

• Perhaps a better title would be "Can a Bitcoin miner generate deterministic SHA2 hashes on arbitrary data?"... the title as it is now makes me want to vote to close. Commented Feb 20, 2015 at 3:45

Do bitcoin miners(or some of them) accept customizable inputs and hash them in bulk(instead of accepting some more high-level instruction and do mining works automatically)?

Bitcoin miners generally take a parameter called "target" and "header" and return a nonce+overflow. I don't think it's possible to hash X times, resulting in predictable output (e.g. you want to compare hashes). The Bitcoin game is one of "finding a lower number" and "hash as fast as you can until you do".

Yes, Bitcoin is literally comparing the SHA2 output of two values as a BigInteger and should only return when this is found. (maybe what you need is possible, but I would think this feature would introduce inefficiencies for the Bitcoin game and would be undesirable)

Here is what goes on inside bitcoin miners:

Note: step 3 and 4 is Bitcoin Hardware, the rest is your custom driver software

Step 1

At a high level, the miner software takes a list of active transactions, and then groups them together in something called a "block".

Or more accurately stated: The miner software coverts all the transactions into a summary view called a "merkle root", and hashes it, which is representative of the transactions.

Step 2

Then mining software converts this to into a binary format called a Block Header, which also references the previous blocks (also called a chain).

``````Field           Purpose                          Updated when...               Size (Bytes)
Version         Block version number             You upgrade the software and   4
it specifies a new version

hashPrevBlock   256-bit hash of the previous     A new block comes in          32
hashMerkleRoot  256-bit hash based on all        A transaction is accepted     32
the transactions in the block

Time            Current timestamp as seconds     Every few seconds              4
since 1970-01-01T00:00 UTC

Bits            Current target in compact format   The difficulty is adjusted   4

Nonce           32-bit number (starts at 0)       A hash is tried (increments)  4
``````

Step 3:

The miner hardware changes a small portion of this block called a "nonce".

Step 4:

The block header is hashed and compared to the Target as if it were simply a large number like 10,000,000 > 7,000,000 (the real numbers are much bigger, and in hex). The target is compressed and stored in each block in a field called bits.

An expanded target looks like this:

``````  Target   0000000000000083ef00000000000000000000000000000000000000000000000
``````

And the goal is to make sure the SHA256 hash of the block is less than this value. In the example below "`83ee`" is smaller than "`83ef`"

To simplify this concept, you can ballpark the target by counting the leading zeros (as the other answer here explains). Here is an example:

Here is a sample block with transactions you can view on BlockChain.info. Look in the upper right hand corner of the webpage for this hash:

``````   Hash 0000000000000083ee9371ddff055eed7f02348e4eda36c741a2fc62c85bc5cf
``````

That previous hash was from today and has 14 leading zeroes. Let's compare that to what was needed 3 years ago with block 100 which has 8 leading zeros.

``````   Hash 00000000a8ed5e960dccdf309f2ee2132badcc9247755c32a4b7081422d51899
``````

Summary

So at the end of the day, all a miner does is:

1. Take a block header as input
2. Change the Nonce
3. Test if the Block Header hash is less than the Target. If it is, you win.
4. Go to step 2 (or go to step 1 if someone else won the block)