The simplest miner would work like this:
1. Request a new [Getwork][1] from a given pool/bitcoind with specified credentials
2. For nonce=0;nonce<0xFFFFFFFF;nonce++
- Set Getwork Data nonce
- SHA-256 hash the Getwork Data ([block header][2])
- Check if hash result is smaller than Getwork Target, if so, submit a share
- If more than 1 second passed since you received Getwork, stop the loop
3. GOTO: 1
Also Found this actual code.
http://pastebin.com/bW3fQA2a
Topic: Hashrate calculation and BFL asic stats. (Read 1538 times)
Hi, thanks for the reply. The Getwork wiki stuff did'nt seem to make sense, but then I can't find a central resource for the detailed mining algorithm.
Got any ideas?
Got any ideas?
Just look at the code.
Hi, thanks for the reply. The Getwork wiki stuff did'nt seem to make sense, but then I can't find a central resource for the detailed mining algorithm.
Got any ideas?
Got any ideas?
You always have to do the full calculation. If you could just calculate part of it and then do the full 2nd hash, then that makes sha256 completely pointless.
Sorry if this has been discussed before, but I'm buggered if I can find any threads that give me the answer.
Lots of pages refer to the 'double' sha256 hash in the bitcoin hashing algorithm. However, there seems to be a concensus that most miners only perform the inner hash once, then use the output digest from it again and again; indeed in the Getwork wiki, it actually says:
"running a full SHA256 round is generally inadvisable. Most miners will precompute the SHA256 "midstate" from the first 512-bit chunk of data, and only repeat the 2nd SHA256 round with the final 512-bit chunk (which contains the nonce). "
This may be out of date, and I'd appreciate some advice as to whether it is true or not.
Question is:
When an asic supplier quotes a hashrate, is it based on a 'true' double hash (taking twice the time) or an 'optimised' one as described above? It makes a big difference, I've only so far seem one supplier - Bitfury - mentioning a double hash. I recently came across the stats of the BFl chip - what a monster! 7.5 x 7.5mm2. That gives a useable chip area of 6.9 x 6.9 or 47.6 mm2. On TSMC's 65nm process, raw gate density is about 850k gates/mm2, so this device probably has a utilisation of 80 - 85% or 32 - 34 million gates.
BFL say there are 16 unrolled pipelines on the chip. If they are 'single' length, ie 64 sections, then each section is roughly 33*10^6/(16 *64), ie 32000 gates (or 16000 if a double length pipeline is used). Yes, I know there is control logic and so on, but it shouldn't take more than 500k gates.
Either way, they seem awfully large, by a factor of 10 or 5. Possibly due to an FPGA conversion?
Anyway, this is bugging me. Can anyone help?
Thanks.
Lots of pages refer to the 'double' sha256 hash in the bitcoin hashing algorithm. However, there seems to be a concensus that most miners only perform the inner hash once, then use the output digest from it again and again; indeed in the Getwork wiki, it actually says:
"running a full SHA256 round is generally inadvisable. Most miners will precompute the SHA256 "midstate" from the first 512-bit chunk of data, and only repeat the 2nd SHA256 round with the final 512-bit chunk (which contains the nonce). "
This may be out of date, and I'd appreciate some advice as to whether it is true or not.
Question is:
When an asic supplier quotes a hashrate, is it based on a 'true' double hash (taking twice the time) or an 'optimised' one as described above? It makes a big difference, I've only so far seem one supplier - Bitfury - mentioning a double hash. I recently came across the stats of the BFl chip - what a monster! 7.5 x 7.5mm2. That gives a useable chip area of 6.9 x 6.9 or 47.6 mm2. On TSMC's 65nm process, raw gate density is about 850k gates/mm2, so this device probably has a utilisation of 80 - 85% or 32 - 34 million gates.
BFL say there are 16 unrolled pipelines on the chip. If they are 'single' length, ie 64 sections, then each section is roughly 33*10^6/(16 *64), ie 32000 gates (or 16000 if a double length pipeline is used). Yes, I know there is control logic and so on, but it shouldn't take more than 500k gates.
Either way, they seem awfully large, by a factor of 10 or 5. Possibly due to an FPGA conversion?
Anyway, this is bugging me. Can anyone help?
Thanks.
Jump to: