Bitcoin Forum
December 04, 2016, 10:38:35 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
Author Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards  (Read 109493 times)
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
June 07, 2012, 07:55:30 AM
 #401

Another thing is what if bitfury gets the same idea and they release their 300 mh/s bitstream with 5% comission.

Yeah, aside from the fact that he's going to make a killing on his own hardware (which has the best power supply of any system I've seen, by a huge margin) and on hosting for it (which I think is a major untapped market -- finding a place to put my mine was a gigantic headache), I've already explained why in his thread.

The "sea of tiny hashers" approach is really easy to reverse-engineer: there's a repeating pattern you can use to easily separate the hashers from the countermeasures, so you don't have to genuinely understand what's going on.  In a 64-unrolled ring every stage is different (and the first 8 and last 4 stages are really different) so you have to actually understand the circuit -- or at least the funky stages at the start and end -- in order to separate the signcryption countermeasures from the hasher.

I also encode my public key in the wiring pattern of the circuit, not the LUT tables.  So if you want to change the public key you have to actually move wires, which has a high probability of disturbing nearby critical paths.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
1480891115
Hero Member
*
Offline Offline

Posts: 1480891115

View Profile Personal Message (Offline)

Ignore
1480891115
Reply with quote  #2

1480891115
Report to moderator
1480891115
Hero Member
*
Offline Offline

Posts: 1480891115

View Profile Personal Message (Offline)

Ignore
1480891115
Reply with quote  #2

1480891115
Report to moderator
1480891115
Hero Member
*
Offline Offline

Posts: 1480891115

View Profile Personal Message (Offline)

Ignore
1480891115
Reply with quote  #2

1480891115
Report to moderator
Satoshi is no god. He did not come down from the mountain with 10 golden rules engraved in stone for no one to question.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
June 07, 2012, 07:57:18 AM
 #402

It makes me sad thinking of all the time he spent on this code ... that could have been spent on a better bitstream.

Oh, I don't know.  It was actually more fun than implementing SHA-256.  I found out that Galois fields are actually useful for something practical!  The only irritating part is I can't show off the details of the signcryption system the way I post chip plots of the SHA circuit.  Like right now, for example, I have to bite my tongue and refrain from responding to Inspector2211's posting.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
June 07, 2012, 08:00:09 AM
 #403

BTW, change the title of the thread. Its no longer 245.

I know, I know.  I keep telling myself "after the next build finishes, I'll post the final numbers".  But these infernal three-ring builds take an insane 48 hours to finish, and I've somehow managed to botch three of them in a row.  The stupid Xilinx tools can't use more than 2 cores (sometimes only 1) either so more hardware doesn't help.

I'm only caught up to "Entropy-uc"'s post in this thread… I am stuck in meetings all day tomorrow but once that's over with I will respond to the rest of the thread, and also post more goodies (assuming the synthesis-tool-gods continue smiling on the rest of the current run).

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
Keninishna
Hero Member
*****
Offline Offline

Activity: 551



View Profile WWW
June 07, 2012, 10:50:48 AM
 #404

Another thing is what if bitfury gets the same idea and they release their 300 mh/s bitstream with 5% comission.

Yeah, aside from the fact that he's going to make a killing on his own hardware (which has the best power supply of any system I've seen, by a huge margin) and on hosting for it (which I think is a major untapped market -- finding a place to put my mine was a gigantic headache), I've already explained why in his thread.

The "sea of tiny hashers" approach is really easy to reverse-engineer: there's a repeating pattern you can use to easily separate the hashers from the countermeasures, so you don't have to genuinely understand what's going on.  In a 64-unrolled ring every stage is different (and the first 8 and last 4 stages are really different) so you have to actually understand the circuit -- or at least the funky stages at the start and end -- in order to separate the signcryption countermeasures from the hasher.

I also encode my public key in the wiring pattern of the circuit, not the LUT tables.  So if you want to change the public key you have to actually move wires, which has a high probability of disturbing nearby critical paths.

Yeah, bitfury said he won't be copying your style. I think if he licenses out the bitstream he was going with a hardware AES scheme. The only threat now is just when/if the open source community can catch up to your speed, which might be a while. I'm interested in what enterpoint co can come up with too but I doubt they will be able to match your performance.
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
June 07, 2012, 09:44:54 PM
 #405

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

By the way, I don't believe that EldenTyrell modifies the INPUT of the double-SHA.

I do.

Changing even one input bit will change all output bits in a non-trivial, seemingly stochastic, way.
After all, this is the very idea of SHA-256.

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
June 07, 2012, 11:33:05 PM
 #406

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

By the way, I don't believe that EldenTyrell modifies the INPUT of the double-SHA.

I do.

Changing even one input bit will change all output bits in a non-trivial, seemingly stochastic, way.
After all, this is the very idea of SHA-256.

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.

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.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
June 08, 2012, 12:42:28 AM
 #407

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)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
June 08, 2012, 01:14:13 AM
 #408

One cannot modify the 512 input bits of the SHA-256 algorithm, because otherwise nonce-detection would be impossible.

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.

So, in other words, while I don't believe ET is adding any STAGES to the double-SHA, not even one,

I never said I was adding stages.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
June 08, 2012, 01:39:37 AM
 #409

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.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
June 08, 2012, 02:49:04 AM
 #410

... except that he's leading you astray Smiley

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)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
June 08, 2012, 04:24:28 AM
 #411

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.
pieppiep
Sr. Member
****
Offline Offline

Activity: 402



View Profile
June 08, 2012, 07:02:22 AM
 #412

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.
uuidman
Full Member
***
Offline Offline

Activity: 121


View Profile
June 08, 2012, 04:38:33 PM
 #413


[/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.
O_Shovah
Sr. Member
****
Offline Offline

Activity: 410


Watercooling the world of mining


View Profile
June 08, 2012, 07:55:22 PM
 #414

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.

Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
June 08, 2012, 08:38:46 PM
 #415



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."
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 08, 2012, 10:05:27 PM
 #416

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 Tongue

sadpandatech
Hero Member
*****
Offline Offline

Activity: 504



View Profile
June 08, 2012, 10:09:51 PM
 #417

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 Tongue

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.

If you're not excited by the idea of being an early adopter 'now', then you should come back in three or four years and either tell us "Told you it'd never work!" or join what should, by then, be a much more stable and easier-to-use system. - GA
It is being worked on by smart people. -DamienBlack
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
June 08, 2012, 10:11:09 PM
 #418

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.
Ah well, yep he can do that - I didn't think of that idea Smiley

But it is still 8 rounds longer than an optimised sha256 Tongue
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? Cheesy (of course it would need to be a bigger FPGA)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 08, 2012, 10:14:11 PM
 #419

Quote
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...

Jep they announced a lot of things Cheesy
BTT:

Would be nice to see some FPGAs running that bitstream?


kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
June 08, 2012, 10:17:13 PM
 #420

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 Tongue

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...
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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!