Show Posts
|
Pages: [1] 2 3 4 5 6 7 »
|
I'm curious about making a bot that can buy and sell from multiple markets (Bter, Poloniex, etc.) but I'm not familiar with API's, JSON, or anything like it  . Are their any recommendations or guides for how to do this? Any books that might get me started?
|
|
|
Sorry about that. I just wanted to make sure I knew W and K like the back of my hand. Thank you for all the help. I am extremely grateful for it. Sorry if it was really troublesome.
|
|
|
 I understand what is going on with K here, its the constants that the NSA provided. I also notice that W does not go to each round. Is their a formula/rule for when W gets inputted?
|
|
|
Values as in inputs?
I know they denote SHA256 as having 8 inputs with A-H, each capable of taking in 32 bits. Inputs A and E require processing but everything else just gets shifted over.
|
|
|
How does the padding work? I had another question, not sure if its related, but Avalon documentation shows they do some form of preprocessing before sending it to the actual ASIC to "improve efficiency". Is it padding or something to do with expansion? 
|
|
|
Does Bitcoin just use the standard 64 rounds or does it require less?
|
|
|
Wt is derived from the inputted data, which gets expanded by the expander and Kt are just the constants. One constant is used per 64 rounds.
Would it be detrimental if you failed to perform 64 rounds?
|
|
|
I notice that a lot of these diagrams show the expander as a seperate component to the compressor ( which is understandable ) However, I keep getting confused between the diagrams I see in official documents and this one  I hate to ask these seemingly simple questions but if I'm understanding this right, Kt are the predefined constants and Wt is derived from the inputted data. They get combined each round. right?
|
|
|
Why does it need to be expanded if the input has already been compressed/padded?
You state that is expands it into an array of 64 x 4 bytes which turns into the message schedule.
From what I'm seeing, the data in the message scheduler is also part of the data you're compressing but it is somehow separate from the "compressor" as labeled in the diagram. This "Expander", which is part of the message scheduler, takes in "Wt", a chunk of data from the message schedule and "Kt", a predefined constant. I assume I understand this correctly?
|
|
|
 The scheduler also appears to have the same two functions as this "Expander" which I have no clue what it's for.
|
|
|
Since Bitcoin uses a Double SHA256, I've heard you can "carry over" data. And why 64 rounds? Is that a standard? I realized the more rounds you have, the harder it gets to "reverse".
|
|
|
SHA-256 involves 64 rounds per block (512 bit input) and each block is broken into eight 32 bit words. The message schedule refers to the movement of the words through the algorithm.  Word A for round n becomes word B for round n+1 is part of the message schedule. So the data from the previous round just gets shifted? And what exact are Wt and Kt? From what I can gather, they are where you put the initialization values the NSA supplies.
|
|
|
What is it pretty much. I've wrapped my head around the four functions ( five if you count the Modulo 32 ) and compression to a degree ( padding and splitting or "chunking" as I like to call it). What is this "Message Scheduler"? I've been looking through the NIST documents on SHA256 and I see something called a "message scheduler" not sure what that is  Any ideas or explanations?
|
|
|
I've got a pretty good idea of how the hashing actually woks although I have difficulty wrapping my head around the compression.
From what I've gathered, the data is split into suitable chunks and then hashed. If its less then ideal, it becomes padded although I doubt Bitcoin hashing requires it.
The Avalon data sheets point to a method of sorts for preprocessing where the data is split up outside the chip before being sent to it.
I also remember TheRealSteve telling me that a difference exists between typical SHA256 and the Merkle-Damgard construct...or Merkle Tree, if my vernacular is correct.
|
|
|
The instructions were easy. I had difficulty finding the right PDF. Thank you and sorry for the extra work you had to put in to link it.  Tip me a coffee, I think that's fair recompense  ( wait, does that tip bot thing even monitor BCT yet? Dangit. ) Maybe when I actually have BTC to start with.
|
|
|
The instructions were easy. I had difficulty finding the right PDF. Thank you and sorry for the extra work you had to put in to link it. 
|
|
|
That looks like real useful piece of information. Is it possible to get that e-mailed please?
|
|
|
Are you trying to design a generic SHA256 ASIC, or a Bitcoin mining ASIC? There's a fair bit of difference there. If the latter, I'd suggest looking at some of the public documents for the older FPGA miners, Avalon's chips, the data mining software sends to simple chips (i.e. not miners with their own controller board). etc. For a quick "ahhh", see: http://crypto.stackexchange.com/questions/1862/how-can-i-calculate-the-sha-256-midstateBitcoin mining ASIC. Thanks for the link. I'll look it over 
|
|
|
Thanks. Is it possible to get this moved?
|
|
|
I have been trying to design my own SHA256 ASIC for a while now and I'm starting to nearly grasp how the entire hashing algorithm works. The only thing I seem to have difficulty understanding is how the hash function deals with "extended" strings of data.
That is, its ability to deal with varying lengths of data. How does it deal with it and does it interfere much with ASIC hashing?
|
|
|
|