Bitcoin Forum
June 17, 2024, 09:06:59 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Hardware / Re: Official Open Source FPGA Bitcoin Miner (Smaller Devices Now Supported!) on: June 06, 2011, 11:35:29 AM
D) there is 2 rounds of sha256, and one sha256 round is 64 rounds. 2*64=128rounds.
the way to calculate the hash of a block is: sha256(sha256(blockdata))
To be exact, a constant is prepended to the inner sha256 hash to pad it to the 512 data bytes needed for the outer hash.
yes. the first a 1bit then alot of 0bits and then the size(64bit) until we reaches 512, i know that. but it does not matter much, how its done, just that it is done... it is the padding a talked about.
btw. its 512 bytes its 512 bits. a byte is 8 bits.

kokjo, gentakin & TheSeven - Thanks for your replies.  The explanations (and LINKS!) helped me quickly understand what is happening, and in what state the FPGAs are getting the work.  (I knew it was some "midstate" but not exactly where.)  I'll spell it out here so you can check my understanding, and so the next noob can get a head start.

1) The first 1/2 of DATA is *already* hashed, and sitting in MIDSTATE.  Gotcha.  (So toss/ignore the first 1/2 of DATA for hash searching purposes.)

2) The next four 32bit long-words are:
2 a) the last 32bits of merkel tree
2 b) unix time in seconds
2 c) "bits", the current difficulty (encoded slightly)
2 d) nonce 0x00000000, which we iterate through 2^32 combinations looking for golden tickets

3) The remaining 384bits are the SHA256 spec for padding, which states:
Code:
re-processing:
append the bit '1' to the message
append k bits '0', where k is the minimum number >= 0 such that the resulting message
    length (in bits) is congruent to 448 (mod 512)
append length of message (before pre-processing), in bits, as 64-bit big-endian integer
( http://en.wikipedia.org/wiki/SHA-2 )
3 a) Padding starts with 0x00000080, which big-little endian converts to 0x80000000, the high-order bit is the '1' appended to the message.
3 b) followed by all zeros until the last 64bits
3 c) last 64bits specify message length 0x00000000 0x80200000 which big-little endian converts to 0x00000000 0x00000280.  0x280 = 640bits = 80bytes, and ALL header blocks are 80 bytes.  Check ... it all makes sense now.  (THANKS!)

While trying to read the protocols and make sense of FPGAminer's code, I wrote a quick perl script to print out repeated getwork() responses in nice columns for analysis.  If anyone wants, I can post it.  Besides, it's kind of mesmerizing to watch.  Smiley

Thanks again, guys!
2  Bitcoin / Hardware / Re: Official Open Source FPGA Bitcoin Miner (Smaller Devices Now Supported!) on: June 06, 2011, 08:24:30 AM
Well, this is a bit earlier than I had wanted, but I will tweak and improve this as we go along.
...
Please feel free to give me feedback, suggestions, critiques, and of course to submit Pull requests.
...
June 2nd, 2011 - Flexible Unrolling Added
Thanks to the patch submitted by Udif, the code now supports a configurable amount of loop unrolling. The original design was fully unrolled, with 128 total round modules. By adjusting the CONFIG_LOOP_LOG2 Verilog define, you can choose to unroll to 64 round modules, 32, 16, 8, or 4. This makes the design smaller, at the equivalent cost of speed, which should allow it to run on many more FPGAs.

FPGAminer - I've been following this thread for ~2 weeks now and looking at your TCL code for your miner (mine.tcl), and I am still trying to figure out *exactly* what goes into the FPGAs for hashing, and what comes out to be submitted.

It looks like the following takes place:

1) get_work() and send the following to the FPGA:
1 a) MIDSTATE - all 256 bits
1 b) DATA - *ONLY* 256bits [256-511] (DATA string characters 128-191)
1 c) HASH1, TARGET, and the remaining 75% of DATA are discarded. (?!?!)

2) wait up to 20 seconds for a result - [wait_for_golden_ticket 20]

3) upon finding a "golden ticket", submit_work to the bitcoin client containing:
3 a) original DATA string[0-151], plus
3 b) "golden ticket" nonce string replacing DATA characters[152-159], plus
3 c) original DATA string[160-255]
... in essence, the original data string with the 20th 32-bit all-zero data block replaced with the golden nonce.

Side note: it appears that the 18th 32-bit block is Unix seconds - since 01/01/1970 00:00:00.  Any other clues you can give about other fields?  Smiley  Maybe a link to the getwork() definition of returned data?

My questions are the following:
A) When does the FPGA "learn" of the target value to beat ... or does it ever? (Hardcoded?)
B) SHA256 requires 512bit chunks of data to hash over.  Is MIDSTATE really *right-in-the-middle* of a 64-round hash as opposed to just between 512bit chunks?
C) Exactly what gets hashed?  It looks like  the SHA256 engine is "primed" with MIDSTATE, and only gets 256bits of DATA to iterate with (ignoring the other 768bits of DATA).
D) If you only submit MIDSTATE and 256bits of DATA, how do we arrive at 128 round engines in the FPGA?

Any insight would be appreciated.  Especially if an explanation points to a more in-depth description of the algorithm.  (I've read every post here for ~2 weeks.)  I've also refreshed my memory at http://en.wikipedia.org/wiki/SHA-2

BTW - Thanks for all of your work!  GREAT JOB!
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!