Kano, you are a brazen troll.
At first you accuse me of my code doing two SHA256 rounds, and at the same time claim that it is not necessary.
Here is your quote:
'Your' verilog code says it does an SHA256 double hash.
4) You say it does a double SHA256 - but no miner does a double SHA256
They only do a partial single SHA256, since that's all that's necessary
And then, when I told you directly that you are ignorant about this, you went to check the information and realized that you could lose your reputation. And now you already claim that the miners perform 2 rounds. At the same time, again accuse me of being wrong?
Here is your new statement:
The ASIC does not do 3 rounds as I explained above, it only does 2 (or to be exact a little less than 2)
You complain about me not watching you silly video or reading your white paper on some other web site, yet I've written here above EXACTLY how mining works and you don't bother to read or understand it, and thus get your reply WRONG.
Your a joke. Full on.
Sigh - we are talking about 2 different things here.
Bitcoin block header hashing is a double SHA256, but the ASIC internally doesn't do the first half of the first SHA256, and doesn't complete the second SHA256.
So saying that the ASIC does a double SHA256 is not correct.
I will admit that the way I wrote it the first time is a little misleading when I now reread it now, since I didn't mention the 2nd part of the process:
4) You say it does a double SHA256 - but no miner does a double SHA256
They only do a partial single SHA256, since that's all that's necessary, the first hash is done once by cgminer when it generates work for the mining hardware, that the hardware then hashes another 4 billion (2^32) times with the changing nonce.
i.e. it's WAY faster than doing the double SHA256 every time.
Have I missed something in your descriptions about this?
But the point of that was to say that it doesn't do a double SHA256.
Part of the first SHA256 is done in cgminer, before it gets to the ASIC
Also, the 2nd SHA256 isn't completed in the ASIC since it doesn't need the full result.
So it's not doing a double SHA256, it's only doing half of the processing of the first and 97% of the second.
The bitcoin block header hash is: the first SHA256 hash is 80 bytes - so it takes setup, 2 runs through the 64 step loop, then output, to do the first SHA256
The output is then used to do the second SHA256, and the full second SHA256 does setup, 1 run through the 64 step loop, then output.
This produces the block hash displayed for a block header.
But in the first case, the ASIC doesn't do a double SHA256, it does the 2nd half of the first SHA256, and that is followed by an incomplete second SHA256.
If we are talking in terms of runs through the 64 step loop, as you later wrote:
...
One round of SHA256 is 64 cycles (steps as you write).
Bitcoin hashing requires 3 rounds of SHA256 with 64 cycles = 3 * 64 = 192 cycles (steps). If you do 2 cycles = 64 * 2 = 128 steps, you will not get a Bitcoin hash.
Then you are not talking about the double SHA256, you are talking about the internal rounds though the 64 step loop, that depend on the size of the input data, to get each of the 2 single SHA256 results, to give the final (incomplete) double SHA256 result (the 2nd one).
So in this case the ASIC does (almost) 2 times though the 64 step loop.
You verilog file says
(2 cycles of SHA-256 hashing)
So if what you meant by that was not 2 times SHA-256 hashing, but 2 times though the internal 64 step loop, that is only a part of the SHA256 hash, then yes that's (almost) correct (it's a few % less than 2 times), but if you mean 2 times though SHA256, then no that's not correct.
To explain it in simple terms:
You have a hash called SHA256
The code calculates the SHA256 hash (of course) of any input (of any length) you give it and it gives a single fixed size output.
But the process of doing that hash involves multiple steps, including one or more times though a part of the hashing code, an internal 64 step loop, and the number of times depends on the size of the input.
That internal loop is not a SHA256 hash, it's just a part of the SHA256 hash code.
