Topic: information on technical / hardware side of things. (Read 889 times)
cheers guys, highly appreciated.... makes more sense now!
When you're brute-forcing a cryptographic algorithm or, for that matter, a cryptographic hash, you're just trying test vector X, test vector X+1, test vector X+2 and so on. Thus, on the input side you have some bits which can be pre-set via USB and some bits which originate from a counter.
There is no output (and thus, no further input either) until one of two things happen:
1. a match is found
2. the counter is exhausted
There is no output (and thus, no further input either) until one of two things happen:
1. a match is found
2. the counter is exhausted
SHA256 has a blocksize of 512 bits, 64 bytes.
To find a winning block that gives 50 BTC you need to have a block of 80 bytes that give a low enough value hash.
In the 80 bytes block are 4 bytes you can fill in yourself, those are located after the first 64 bytes.
So the mining software sends 80 bytes to the miner.
The miner hashes the first 64 bytes to a midstate.
The miner fills in 0 for the 4 bytes and calculates the hash for midstate+last part.
The miner fills in 1 for the 4 bytes and calculates the hash for midstate+last part.
The miner fills in 2 for the 4 bytes and calculates the hash for midstate+last part.
The miner fills in 3 for the 4 bytes and calculates the hash for midstate+last part.
...
The miner fills in for the 4 bytes and calculates the hash for midstate+last part.
The hash is low enough so the miner tells the mining software about it.
This way, 2^32 hashes can be done with just sending 80 bytes once and receiving on average 80 bytes back.
2^32 hashes is 4.294967296 Ghash/s.
So a 4 Ghash/s miner only needs 160 bytes/seconds.
Probably a little more for the protocol used, but you get the point.
To find a winning block that gives 50 BTC you need to have a block of 80 bytes that give a low enough value hash.
In the 80 bytes block are 4 bytes you can fill in yourself, those are located after the first 64 bytes.
So the mining software sends 80 bytes to the miner.
The miner hashes the first 64 bytes to a midstate.
The miner fills in 0 for the 4 bytes and calculates the hash for midstate+last part.
The miner fills in 1 for the 4 bytes and calculates the hash for midstate+last part.
The miner fills in 2 for the 4 bytes and calculates the hash for midstate+last part.
The miner fills in 3 for the 4 bytes and calculates the hash for midstate+last part.
...
The miner fills in
The hash is low enough so the miner tells the mining software about it.
This way, 2^32 hashes can be done with just sending 80 bytes once and receiving on average 80 bytes back.
2^32 hashes is 4.294967296 Ghash/s.
So a 4 Ghash/s miner only needs 160 bytes/seconds.
Probably a little more for the protocol used, but you get the point.
I wondered if anyone could point me in the right direction on where I could find information on the technical hardware side of things for both FPGA & ASIC boards.
For example:
How are the hashes measured?
An SHA256 needs 32 bytes in and 32 bytes out so the Butterfly labs system doing 832^6 hashes per second would need ~24^9 bytes in and out every second but it says "easy usb connectivity". USB has a bandwidth of ~60^6 byes/ second so I'm missing something.
Is a hash calculated as one step in the process?
What are these hashes run against? How do you get the data in and out fast enough?
For example:
How are the hashes measured?
An SHA256 needs 32 bytes in and 32 bytes out so the Butterfly labs system doing 832^6 hashes per second would need ~24^9 bytes in and out every second but it says "easy usb connectivity". USB has a bandwidth of ~60^6 byes/ second so I'm missing something.
Is a hash calculated as one step in the process?
What are these hashes run against? How do you get the data in and out fast enough?
Jump to: