<blockquote>
  <p>Are Bitcoin ASICs Optimized for Fixed Length Messages?</p>
</blockquote>

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

<blockquote>
  <p>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?</p>
</blockquote>

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

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

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

CC BY-SA 3.0
2015-01-10T15:58:14.893Z
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
CC BY-SA 3.0
2015-01-09T22:26:58.330Z
2015-01-09T22:26:58.330Z
Nick ODell
<p>Bitcoin block headers are 80 bytes. </p>

<pre><code>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
</code></pre>

<p>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 <code>nBits</code>. </p>

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

<p>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?</p>

<p>Does it vary from SHA256-ASIC to SHA256-ASIC depending on how they are made?</p>

<hash><sha256><asic>
Are Bitcoin ASICs Optimized for Fixed Length Messages?
morsecoder
# Are Bitcoin ASICs Optimized for Fixed Length Messages?

(Asked by: username_0 on 2015-01-09)

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?

**Tags:** hash, sha256, asic


---

## 1 answers

### Answer by username_1 on 2015-01-09. Score: 2 | Accepted answer

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

> **Comments:**
> **username_0**: 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.  

---

