<p>Unless I'm corrected otherwise, I'll offer this analogy:</p>

<p>There's two closets filled with files. You've searched through Closet 1 already (personally, or work done by another team) and want to save yourself the time of searching the same closet again the next day. So you (cryptographically) seal the door so as to be certain the state remains (no one alters files). This allows you to concentrate your efforts on the second closet. </p>

<p>Again, I am on the fence between whether to comment or answer but I've chosen the latter </p>

CC BY-SA 3.0
2015-03-27T04:57:15.210Z
This doesn't seem like a very good analogy. You're not trying to narrow the search space, you're trying to speed up individual attempts.
Nick ODell
CC BY-SA 3.0
2015-03-23T07:37:10.043Z
2015-03-23T07:37:10.043Z
Wizard Of Ozzie
<p>People often talk about SHA256 like it's a single operation, but it isn't. Rather, the input is broken up into 64-byte chunks, and then each chunk is put into a compression function. The state of the hash partway through hashing something does not depend on future parts of the data. Since the nonce is found in the second chunk, changing the nonce doesn't change the the state of the hash function after hashing the first chunk.</p>

<p>This is useful in other applications. For example, if you're hashing a large file, it means that you can hash it without loading the entire file into memory at once or loading it from disk multiple times.</p>

<p>The practical consequence of this for Bitcoin miners is that 99.99999998% of the time, you only need 2 iterations of the SHA256 compression function to check a possible block solution, instead of 3. In other words, you can mine 50% faster. Of course, since everyone else does this, that just means that the difficulty is higher for everyone.</p>

<p>midstate is literally the <em>state</em> <em>mid</em>way through hashing.</p>

<p>See also: <a href="https://bitcoin.stackexchange.com/questions/36601/did-satoshi-intend-to-allow-midstate-computation-to-speed-up-hashing">Did Satoshi intend to allow midstate computation to speed up hashing?</a></p>

CC BY-SA 3.0
2015-05-28T03:54:37.243Z
I thought it was broken up into 32 _bit_ chunks. At least that's how I interpret [`sha256_generic.c`](https://github.com/luke-jr/bfgminer/blob/bfgminer/sha256_generic.c#L60).
Geremia
CC BY-SA 3.0
2015-05-28T09:19:42.497Z
@Geremia It's split into 64 byte chunks, then copied, 32 bits at a time, into the message schedule array. 16 times 32 divided by 8 equals 64.
Nick ODell
CC BY-SA 3.0
2015-06-18T04:40:15.780Z
But we're talking about double SHA-256 (SHA-256d) here. How does that factor into things?
Geremia
CC BY-SA 3.0
2015-06-18T04:41:15.083Z
SHA-256d (`b`) on input `data` is: `b=SHA(a=SHA(data))`. Thus is `a` the "midstate"?
Geremia
CC BY-SA 3.0
2015-06-19T22:32:24.103Z
@Geremia `a` isn't the midstate itself. You can use the midstate to more efficiently compute `a` because the first half of `data` doesn't change. `b` must be done from scratch (although because `a` is only 32 bytes long, computing `b` only involves a single SHA-256 block).
Christopher Gurnee
CC BY-SA 3.0
2015-06-19T23:19:37.473Z
[related discussion](http://chat.stackexchange.com/transcript/message/22245997#22245997)
Nick ODell
CC BY-SA 3.0
2015-03-27T05:35:16.760Z
2015-06-19T23:17:13.227Z
2017-04-13T12:47:33.610Z
Nick ODell
<p><a href="https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list" rel="nofollow">This</a> defines "midstate" as the "precomputed hash state after hashing the first half of the data."</p>

<p>I've heard "midstate" used in the context of speeding up hashing. How does using a midstate speed up hashing?</p>

CC BY-SA 3.0
2015-03-23T18:44:25.023Z
Possible duplicate of http://bitcoin.stackexchange.com/q/5034/18196.
morsecoder
<hash><sha256><midstate>
What is a midstate? How does using a midstate speed up hashing?
Geremia
# What is a midstate? How does using a midstate speed up hashing?

(Asked by: username_0 on 2015-03-23)

[This](https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list) defines "midstate" as the "precomputed hash state after hashing the first half of the data."

I've heard "midstate" used in the context of speeding up hashing. How does using a midstate speed up hashing?

**Tags:** hash, sha256, midstate

> **Comments:**
> **username_1**: Possible duplicate of http://bitcoin.stackexchange.com/q/5034/18196.  

---

## 2 answers

### Answer by username_3 on 2015-03-27. Score: 6 | Accepted answer

People often talk about SHA256 like it's a single operation, but it isn't. Rather, the input is broken up into 64-byte chunks, and then each chunk is put into a compression function. The state of the hash partway through hashing something does not depend on future parts of the data. Since the nonce is found in the second chunk, changing the nonce doesn't change the the state of the hash function after hashing the first chunk.

This is useful in other applications. For example, if you're hashing a large file, it means that you can hash it without loading the entire file into memory at once or loading it from disk multiple times.

The practical consequence of this for Bitcoin miners is that 99.99999998% of the time, you only need 2 iterations of the SHA256 compression function to check a possible block solution, instead of 3. In other words, you can mine 50% faster. Of course, since everyone else does this, that just means that the difficulty is higher for everyone.

midstate is literally the *state* *mid*way through hashing.

See also: [Did Satoshi intend to allow midstate computation to speed up hashing?](https://bitcoin.stackexchange.com/questions/36601/did-satoshi-intend-to-allow-midstate-computation-to-speed-up-hashing)

> **Comments:**
> **username_0**: I thought it was broken up into 32 _bit_ chunks. At least that's how I interpret [`sha256_generic.c`](https://github.com/luke-jr/bfgminer/blob/bfgminer/sha256_generic.c#L60).  
> **username_3**: @username_0 It's split into 64 byte chunks, then copied, 32 bits at a time, into the message schedule array. 16 times 32 divided by 8 equals 64.  
> **username_0**: But we're talking about double SHA-256 (SHA-256d) here. How does that factor into things?  
> **username_0**: SHA-256d (`b`) on input `data` is: `b=SHA(a=SHA(data))`. Thus is `a` the "midstate"?  
> **username_4**: @username_0 `a` isn't the midstate itself. You can use the midstate to more efficiently compute `a` because the first half of `data` doesn't change. `b` must be done from scratch (although because `a` is only 32 bytes long, computing `b` only involves a single SHA-256 block).  
> **username_3**: [related discussion](http://chat.stackexchange.com/transcript/message/22245997#22245997)  

---

### Answer by username_2 on 2015-03-23. Score: 0

Unless I'm corrected otherwise, I'll offer this analogy:

There's two closets filled with files. You've searched through Closet 1 already (personally, or work done by another team) and want to save yourself the time of searching the same closet again the next day. So you (cryptographically) seal the door so as to be certain the state remains (no one alters files). This allows you to concentrate your efforts on the second closet.

Again, I am on the fence between whether to comment or answer but I've chosen the latter

> **Comments:**
> **username_3**: This doesn't seem like a very good analogy. You're not trying to narrow the search space, you're trying to speed up individual attempts.  

---

