Potential SHA256 Mining Speedup (2.3%)

[mantisdrop]

It seems like there might be a way to speed up mining by a tiny bit. The first 8 0's of the final block hash can be determined by looking at a value calculated in round 61 of the final SHA256 hash (instead of waiting for all 64 rounds and the final step to complete). The second set of 8 0's can be determined by looking at a value calculated in round 62, and the third set from round 63. Therefore, the algorithm should be able to short-circuit and skip some rounds of calculations by checking these values at their respective rounds. Given that there are 128 rounds (http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html), there should be ~2.3% reduction in calculations per hash (at most).

Also, when the mining difficulty reaches 33 0's, another value from round 61 can be examined.

I'm assuming the gain is negligible when considering the cost/difficulty in implementing it. Either way I'm curious to hear some feedback.

(this is helpful for understanding: https://bitcointalk.org/index.php?topic=809430.0)

[1714003570]

1714003570

[1714003570]

1714003570

[1714003570]

1714003570

[achow101]

Given that there are 128 rounds

The second sha256 hash is only hashing 32 bytes (the result of the first sha256 hash) so there are only 64 rounds for that.

Note that the difficulty IS NOT determined by "number of 0's" but rather that the target must be less than a certain value. This happens to result in the hash having a lot of 0's in front of it, but that is not actually what is being checked.

Also, the hash that is actually produced is the byteswapped version of what we actually see presented to us. I'm not sure if that effects this.

[mantisdrop]

The second sha256 hash is only hashing 32 bytes (the result of the first sha256 hash) so there are only 64 rounds for that.

I just mentioned the 128 rounds to calculate the % reduction in overall calculation, 3 out of all 128 rounds (ignoring the other calculations that need to be done).

Note that the difficulty IS NOT determined by "number of 0's" but rather that the target must be less than a certain value. This happens to result in the hash having a lot of 0's in front of it, but that is not actually what is being checked.

Left this out for simplicity

Also, the hash that is actually produced is the byteswapped version of what we actually see presented to us. I'm not sure if that effects this.

This was factored in.

[vipgelsi]

This would help my setup hopefully someone has some insight.

[achow101]

I just mentioned the 128 rounds to calculate the % reduction in overall calculation, 3 out of all 128 rounds (ignoring the other calculations that need to be done).

If you are counting all rounds, then it's 192 rounds. The first SHA256 requires 128 rounds (because the header is larger than 512 bits) and the second only requires 64 rounds (because it is hashing the 256 bit hash).

[aleksej996]

I am not fully familiar with the complete technical detail of SHA256, however to me this sounds like something other's have known about already.
You can check out AsicBoost http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf , it seems to me like your idea might be mentioned there as well.

PS: This technology is patented, as far as I know.

[Crankautist]

I am not fully familiar with the complete technical detail of SHA256, however to me this sounds like something other's have known about already.
You can check out AsicBoost http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf , it seems to me like your idea might be mentioned there as well.

PS: This technology is patented, as far as I know.

Asicboost and op is something different even though results are the same ( decrease of needed computional power ).

Also i think asicboost itself is not patented but rather their algo to find header collisions ( their implementation ). But im not a laywer it would just seem logical.

[gmaxwell]

FWIW early termination has been used by miners since at least 2010.

[mantisdrop]

FWIW early termination has been used by miners since at least 2010.

Ha not surprised. Any sources I can look at?

[mantisdrop]

I just mentioned the 128 rounds to calculate the % reduction in overall calculation, 3 out of all 128 rounds (ignoring the other calculations that need to be done).

If you are counting all rounds, then it's 192 rounds. The first SHA256 requires 128 rounds (because the header is larger than 512 bits) and the second only requires 64 rounds (because it is hashing the 256 bit hash).

This is mentioned here: http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html

Unfortunately the SHA-256 hash works on a block of 512 bits, but the Bitcoin block header is more than 512 bits. Thus, a second set of 64 SHA-256 hash rounds is required on the second half of the Bitcoin block. Next, Bitcoin uses double-SHA-256, so a second application of SHA-256 (64 rounds) is done to the result. Adding this up, hashing an arbitrary Bitcoin block takes 192 rounds in total. However there is a shortcut. Mining involves hashing the same block over and over, just changing the nonce which appears in the second half of the block. Thus, mining can reuse the result of hashing the first 512 bits, and hashing a Bitcoin block typically only requires 128 rounds.

[-ck]

FWIW early termination has been used by miners since at least 2010.

Ha not surprised. Any sources I can look at?

Minerd and the earlier versions of cgminer had CPU mining which had this optimisation pretty much from the beginning. You can also see the same optimisation in the openCL code used in GPU versions of cgminer. The current version of cgminer doesn't contain any CPU or GPU code any more to prevent people doing futile attempts at mining bitcoin with it.