6

Bitcoin block headers are 80 bytes. 

int32_t nVersion;       // 4 bytes
uint256 hashPrevBlock;  // 32 bytes
uint256 hashMerkleRoot; // 32 bytes
uint32_t nTime;         // 4 bytes
uint32_t nBits;         // 4 bytes
uint32_t nNonce;        // 4 bytes
                        // total: 80 bytes

A SHA256 ASIC is specifically designed to (double) hash theses fields over and over until the resulting value is below the difficulty level, which is encoded by nBits.

Since it is a double hash, the ASIC has to be able to hash initial messages of length 80 and 32. After the padding required for SHA256, the byte strings that will be hashed have lengths 128 and 64, respectively. So, bitcoin ASICs obviously have to able to hash messages of length 128 and 64.

But say I have a file on my computer that is considerably longer (10,000x longer). Could I hash it with a SHA256 bitcoin ASIC?

Does it vary from SHA256-ASIC to SHA256-ASIC depending on how they are made?

Improve this question

2 Answers 2

Reset to default
2

Are Bitcoin ASICs Optimized for Fixed Length Messages?

It would really surprise me if they weren't. If you can make your cores 10% smaller by reducing the amount of memory available, then it's a no-brainer.

But say I have a file on my computer that is considerably longer (10,000x longer). Could I hash it with a SHA256 bitcoin ASIC?

In theory, it might be possible, but there's no point to it. Before the ASIC can hash your 800 KB file, it needs to be transferred to the ASIC. That's not so bad if the ASIC has a USB or Ethernet driver, but many don't; it's cheaper to use serial and buy a serial-to-USB converter from FTDI. These interfaces generally top out at 192 kilobaud, so it would take about 33 seconds to transfer the file.

However, most ASICs support a "midstate," which represents the internal state of the hash function partway through the input. The practical upshot of this is that you could hash the first 800 KB of the file with your CPU, then use your ASIC to vary the last 4 bytes of the file to search for a nonce below the target.

Lastly, I want to note that none of these ASICs are calculating SHA256. They're calculating SHA256d.

Improve this answer
1
  • That's a good point about the midstate, so bitcoin ASICs might be optimized only for using an arbitrary midstate and only messages of 64 bytes. In that case, though, that means they can hash arbitrarily long messages as long as there is a feed supplying the data to be hashed.
    – morsecoder
    Commented Jan 10, 2015 at 15:58
2

What do you mean by "really long"? If it's bigger than (2^64-1)/8 bytes (~2,097,152 terabytes) then it's not going to work anyway because this is the theoretical limit of SHA256 and on top of that it would take a huge amount of time to complete, but then again I am not aware of many computers that can hold such great amounts of data.

For significantly smaller inputs it all comes down on the way the ASIC's SHA256 engine is implemented, what is the size of message (input) block in bits, how much memory is available per core in your SHA256 ASIC, etc. As per market standard, these cores are usually equipped with 128 kilobytes of memory. Of course nothing stops you from deploying external units of DRAM memory chips across memory-bus enabled ASICs but this will fire back in processing speed anyway.

Improve this answer
2
  • Thanks for the info. So is the answer yes, existing SHA256 ASICs can hash anything less than 128 kilobytes in length?
    – morsecoder
    Commented Jan 9, 2015 at 19:27
  • @StephenM347 if the ASIC's SHA256 engine implementation is smart enough to support block-based hashing of messages (most do) then the theoretical limit is (2^64-1)/8 bytes. More memory per processing core will allow for bigger blocks thus faster processing.
    – user11221
    Commented Jan 9, 2015 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.