Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 30. (Read 119429 times)

12w for 1600MH/s is way too high...


Regards,
BF Labs Inc.

I believe the OpenASIC boys were talking 8gh/s 100w or so...

much more than that over FPGA? I'm very limited in my knowledge on the matter but I just don't see it.  Ztex for example is ~40 watts at 860MH(x 4 chips @45nm).  I'd hazard to guess a 65nm or larger(likely 90nm+ in BFL's build) asic is going to be what? 12w+ per chip and 800-1600MH?

Agreed.
It could be much more than that.

Last September when they did this to negatively affect the BTC FGPA market, they had no such device, just a simulation, which, as we all know, was unable to meet the specifications the simulation said.

I'd not make any bets on them making good anything on a given date until they actually do.

As I have stated before, they have never done anything (related to BTC) in the time estimate they have stated, to anyone, ever.

Jep they announced a lot of things
BTT:

Would be nice to see some FPGAs running that bitstream?

Ah well, yep he can do that - I didn't think of that idea

But it is still 8 rounds longer than an optimised sha256
6.25% longer - as it always has been due to the odd (not even) number of them

So ... anyone gonna try getting 4 into an FPGA? (of course it would need to be a bigger FPGA)

Assuming their announcement ont he 15th is that they HAVE an asic. It is quite likely they will just be formaly announcing details about the one they are having built...


edit; the other thing to bear in mind is that ASIC will not be the 600%~(math check needed) increase in efficiency that cpu to gpu was.

By the timeframe they used to deliver singles and mini rigs that could mean another 4 - 6 weeks of fpga mining profits ..... A lot can happen given that timeframe

With BFL's June 15th announcement looming, however, I believe that all these speculations are mostly academic and of little practical importance. FPGA miners, including the Spartan6-based miners, will soon be obsoleted by ASIC miners, just like CPU miners were obsoleted by GPU miners.
[/quote]

Doh! Havnt seen a date for the announcement, in what thread/source did you find that ? Not so sure of a ASIC revolution yet, but of course it will have an impact on this quite interesting approach.
[/quote]

http://www.butterflylabs.com/production-update/

"Please note:  Until we’re through initial Mini Rig shipments, you may find communications with anyone outside of customer service to be difficult.  Please be patient and reach out to Jody for the time being.  Announcements regarding abbreviated shipping schedules and future product (BitForce SC) release will be made on June 15th.  Until then we will be focusing purely on Mini Rig shipments."

I recall to have  read a post by bitfury  comparing systems.
The 28nm FPGA might still be a competition regarding price / Hash to the ASIC.

[/quote]

With BFL's June 15th announcement looming, however, I believe that all these speculations are mostly academic and of little practical importance. FPGA miners, including the Spartan6-based miners, will soon be obsoleted by ASIC miners, just like CPU miners were obsoleted by GPU miners.
[/quote]

Doh! Havnt seen a date for the announcement, in what thread/source did you find that ? Not so sure of a ASIC revolution yet, but of course it will have an impact on this quite interesting approach.

The input of 512 bits consists of 80 bytes (400 bits) bitcoinblockheader, followed by 512 - 400 - 64 = 48 bits of padding containing all zero's except for the last bit being a one, followed by 64 bits length.
So the last 112 bits are known and can be used for anything and just replaced by 47*0 1*1 64 bits with value 400 for the length.
About the reporting back to the server, I don't know if there is place somewhere.

Kano, each of the 3 half-miners has a decryption algorithm embedded in the first 8 rounds and an encryption algorithm embedded in the last 8 rounds. It's actually quite clear. Upon exiting the first SHA and entering the second SHA (a miner consists of 2 complete SHA256s), the encryption and the decryption cancel each other out.

I think it could be reverse-engineered quite easily -  however, the advent of ASIC-based miners would make that a (largely) futile endeavor.

... except that he's leading you astray

Easily noticeable for the rather obvious reason ...

The FPGA contains 3 sha256's and as I have stated before, this poses the problem that you cannot have different versions of those 64 rounds without restricting which can be used at certain times during the processing which then would mean a reduction in the MH/s
With 3 sha256's you have the problem of which one is available next - thus all 3 must be the same or you will have times when a specific sha256 isn't available (or there is no data for that sha256) and have to wait.
(i.e. the reason why I said that his double sha256 is 8 stages longer than an optimised double sha256)

Ah, I see.

Well, in that case, it would not even be necessary to remove your decryption algorithm from the first 8 stages.
It would only be necessary to reverse-engineer it.

Upon reverse engineering this 8-stage decryption algorithm, one could then pre-encrypt the pool vectors in software, so that they, upon decryption, form a valid input vector.

Previously, you had alleged that changing [LUTs and] routes/lines would be needed to "break" this protection.
Nonsense.
Judging from your recent post, that seems completely unnecessary.

The encryption of the golden nonce could be broken in a similar way, without changing LUTs, without rerouting connections:
One could merely undo it in software.

Nonsense.  You change not only the input bits, but the algorithm too.

Here's a thought experiment: what if you add k[1] to data[1] in software before loading the work onto the device?  Then, in the second stage only, leave out the k-adder.  You have to then compensate by subtracting k[1] in the message expander (again, second stage only) so this "optimization" doesn't actually improve performance or reduce area.  Finally, push that k-subtracter from the second stage to the third stage, since w[1] isn't used in any calculations (it becomes w[0] of the next stage and gets used there).

There are tons of operations like this that you can do in software and then undo during the first eight stages.  If you cobble together enough of them, you can even implement simple decryption algorithms.  The important part is that the decryption is intermingled with the first eight stages, so you can't just bypass it without major changes to the circuit.


I never said I was adding stages.

Well actually you can modify any part of it you like as long as you use a reversible function that's implemented in the bitstream ...
You could even encrypt it and decrypt it by having the decryption key in the bitstream ...
... and of course do the same with what comes out ...
(and yes this would mean a minor performance drop - however, once or twice every 4 billion hashes isn't very often)

One cannot modify the 512 input bits of the SHA-256 algorithm, because otherwise nonce-detection would be impossible. A golden nonce would still be computed, but it would be a meaningless golden nonce.

I realize, however, that one can add some pseudorandom bits, which may or may not be a crypto hash of some or all of the 512 legitimate input bits, to the input bits, and thus "extend" SHA-256 with respect to its WIDTH.

In an unmodified SHA-256, what percolates down the 64 stages are 512 bits of w and 256 bits of ABCDEFGH.
By adding a few bits (how many bits has not been disclosed, but this will be trivial to find out) to these 768 bits, one can "extend" SHA-256 without messing it up. In other words, a kind of mini-SHA can be run along the full-fledged SHA, keeping the full-fledged SHA intact.
Similarly, for the second SHA iteration.

Then, at the end of the 2nd iteration, the pseudorandom result of the mini-SHA can be used to encrypt the golden nonce, making it unsuitable for direct submission to a pool, requiring submission to the ET-owned server farm instead.
At the ET-owned server farm, the quite-trivially-but-still-sufficiently-encrypted nonce is quickly decrypted, and 95% of these nonces are then returned to the miner, while 5% are retained by ET.

So, in other words, while I don't believe ET is adding any STAGES to the double-SHA, not even one, as that would directly impact the hash rate, I now think he's running a "mini-SHA" alongside both stages of the double-SHA. Maybe 16 bits wide. Maybe 32 bits wide. Maybe only 8 bits wide, partly relying on security-through-obscurity.

While undoubtedly ingenious, such an approach would needlessly increase the power consumption of the FPGA, which is already hitting various limits, mostly thermal ones, but in the ZTEX case also an Amp limit.

With BFL's June 15th announcement looming, however, I believe that all these speculations are mostly academic and of little practical importance. FPGA miners, including the Spartan6-based miners, will soon be obsoleted by ASIC miners, just like CPU miners were obsoleted by GPU miners.

Although my general policy is not to discuss the signcryption technique, I'll bend the rules this one time...


I do.


You are correct: if you can predict the change in output bits caused by a change in input bits (or vice versa), the function you're using isn't a good hash function.

The full 64 rounds of SHA-256 are a good hash function.

The first eight rounds of SHA-256 alone are not a good hash function.

In fact, there are pretty serious attacks that work against even 46 rounds of single-SHA-256; I suspect that this line of research might be why Satoshi chose double-SHA.  SHA-2 really isn't a hash function until you've done a lot of rounds.