ASIC = The end of decentralized mining

[Dexter770221]

It's only 2 days left when BFL will anounce specs for their wonder ASIC miner. Until then, don't panic Propably they will use their HDL code that was used to implement miner in singles, that why they can made this ASIC so quickly. And that is not very optimal hasher. Efficiency will increase, that's for sure. But it will be somwhere around 10 to 20 times. 10W and 1,5GH/s (my first bet was 5GH/s). That is not a giant leap. Anyone make a bet yet? Let's make one, what efficiency of that miner would be? I say 200MH/W max...

[P4man]

http://rijndael.ece.vt.edu/sha3/publications/DSD11SHA3.pdf
Last page. They achieved 3.7mW for 1.5Gbps SHA256 (single pass) on a 130nm process.  Thats ~2.5mW per bitcoin MH. Or ~2.5W per GH.

Other comparison between 65nm FPGA and 130nm asic on SHA256:
http://filebox.vt.edu/users/xuguo/homepage/publications/CESCA_Seminar_SHA3.pdf
Page 23.  The asic is about 35x as power efficient as the Virtex5 on sha256 hashing.

Its anyone's guess what process node BFL has chosen, but I assume it be 130nm or perhaps even better.

Still want to take that bet?

[P4man]

There's a relatively straightforward licensing model that will allow roll-out for an ASIC manufacturer that shares the risk/reward with the early adopters: have the initial release be analagous to an IPO, where you are buying both X number of ASICS and a small_percent * X royalty slice on all future ASIC purchases. This allows the manufacturer to rapidly recoup their cost, but also allows the early adopters to hedge against ASIC cost reduction.

Thats actually a good idea, but I dont see why BFL would do it. Moreover, it falls apart if you factor in a competitor.

[phelix]

[...]
@phelix - the devs won't change the algo for a variety of reasons, including, but not limited to:
- No one would trust Bitcoin if it can be so easily overcome by ASIC miners.  GPU's and FPGA's are moderate protection, but anyone with a large bank account could create their own ASIC.  Therefore, the sooner ASIC miners are also helping to protect the network, the better.
- No matter what the algorithm is changed to, an ASIC could be developed for it.  Therefore, Bitcoin needs to embrace ASICs, not run from them by changing the algo every 6 months.
- Changing the algo would show people that Bitcoin is wrong/weak/untrustable, and that core pieces of it can be changed at the whim of a handful people.
- Changing the algo would ultimately serve to waste the time, money, and effort of many valuable people in the Bitcoin community currently working on developing ASICs.  We'd likely lose most of them.

Basically, changing the algo would cripple or kill Bitcoin.

these are good arguments.

still, it is interesting to ponder about this... might be something for an alt-chain. systematically changing algorithm based on some random values from the block chain. could make a new cpu only alt-chain.

possibility with asics: banking conglomerates ---> mining conglomerates   

[BoardGameCoin]

There's a relatively straightforward licensing model that will allow roll-out for an ASIC manufacturer that shares the risk/reward with the early adopters: have the initial release be analagous to an IPO, where you are buying both X number of ASICS and a small_percent * X royalty slice on all future ASIC purchases. This allows the manufacturer to rapidly recoup their cost, but also allows the early adopters to hedge against ASIC cost reduction.

Thats actually a good idea, but I dont see why BFL would do it. Moreover, it falls apart if you factor in a competitor.

I think there's more incentive for BFL or their competitors to do this in the face of competition. It offers a competitive advantage, kind of like how BFL's current trade-in-for-credit stance is a net competitive win for them even in the existing FPGA market. With no competitor, the seller can set the terms, but with a competitor its whoever can make the best terms. Obviously if the deal is structured poorly, a seller who has to pay royalties to past clients won't be able to compete with one who doesn't need to. But, if doing a deal like this makes it faster to get to the next round of production, a dealer who does this can maintain better cash-flow and keep their average cost-per-unit-produced lower than their competitors (larger volume earlier). As an aside, I imagine that many miners would take their royalty in product...

[mrb]

You are delusional about the capability of ASICs

The efficiency increases from CPU, to GPU, to FPGAs, and to ASIC are all comparable. Roughly a 10x increase every time:
40nm CPUs do up to about 0.1 to 0.5 Mhash/Joule.
40nm GPUs about 1 to 2 Mhash/Joule.
40nm FPGAs about 20 Mhash/Joule.
40nm ASICs will do about 200 Mhash/Joule.

I think you are vastly underestimating the potential of asics; a 130nm asic is ~40x as energy efficient as current 65nm fpgas for sha256 hashing according to papers ive seen and linked. A 40nm asic would therefore be closer to 100x more efficient than an FPGA.

From your link http://rijndael.ece.vt.edu/sha3/publications/DSD11SHA3.pdf I compute 400 Mhash/J for a 130nm ASIC. So probably ~1000 Mhash/J at 40nm. This is 50x better than a 45nm FPGA (Spartan6 = 20 Mhash/J). Edit: Actually 49 Mhash/J: 1000 (mJ) / 19.75 (mJ/Gbits) * 1e9 (bits/Gbits) / 1024 (bits per bitcoin hash) = 49.4 Mhash/J

But this still does not change my mind: the first mining ASICs will likely be manufactured on the 130nm node, so their 400 Mhash/J characteristic will make them a 20x efficiency increase over 45nm FPGAs. Not much different from past 10x technological leaps.

However I do agree that Mhash/dollar will be a more interesting metric to watch than Mhash/J. I wonder why you think ASIC will contribute a 1000x improvement in this area (going from $1 per Mh/s to $1 per Gh/s)?

[P4man]

I think there's more incentive for BFL or their competitors to do this in the face of competition. It offers a competitive advantage, kind of like how BFL's current trade-in-for-credit stance is a net competitive win for them even in the existing FPGA market. With no competitor, the seller can set the terms, but with a competitor its whoever can make the best terms. Obviously if the deal is structured poorly, a seller who has to pay royalties to past clients won't be able to compete with one who doesn't need to. But, if doing a deal like this makes it faster to get to the next round of production, a dealer who does this can maintain better cash-flow and keep their average cost-per-unit-produced lower than their competitors (larger volume earlier). As an aside, I imagine that many miners would take their royalty in product...

Without competition, BFL would simply be handing out a part of their future profits. That only makes sense if you think miners arent going to buy otherwise, but judging by the posts on this forum, I highly doubt that. Moreover, Im not convinced your scheme would change a lot of minds. If they set that percentage really low, as they probably should, it wont factor in most people's buying decision. ; but BFL cant set it very high either if you assume sold hashrate is going to increase by several orders of magnitude over the next years. It would only help for those people who truly understand the problem, and those arent the customers who are going to bid the highest prices.

When you factor in competition, I cant see it work at all. The protection would be moot for miners, because they wouldnt be protected from difficulty increase created by the competitor; nor can BFL provide safeguards against that, you can hardly expect them to pay old customers for sales their competitors achieve. It would be like giving a difficulty insurance; if you do that, I dont see the point of selling hardware, if you assume the major risk and give away the potential benefits,  you are better off mining yourself.

[P4man]

From your link http://rijndael.ece.vt.edu/sha3/publications/DSD11SHA3.pdf I compute 400 Mhash/J for a 130nm ASIC. So probably ~1000 Mhash/J at 40nm. This is 50x better than a 45nm FPGA (Spartan6 = 20 Mhash/J).

Care to share your math? I suspect you forgot a bitcoin hash consists of two SHA256 hashes.

However I do agree that Mhash/dollar will be a more interesting metric to watch than Mhash/J. I wonder why you think ASIC will contribute a 1000x improvement in this area (going from $1 per Mh/s to $1 per Gh/s)?

I did the math. Using the above PDFs you can get an idea of density compared to FPGAs. To make that math work, you need to know the die size of those FPGAs, which I couldnt find, but I assumed they were between half and full reticle size (1/24th of a wafer). In reality they are almost certainly smaller. Still, even using that assumption, I ended up with well over 1 terrahash per wafer.  A processed 200mm 130nm wafer costs about $1000. Those are ballpark figures, but they give you an idea.

As for FPGAs, they may not cost nearly as much as what we pay, but there is no reason to assume FPGAs are going to drop dramatically in price, and their price certainly wont change with bitcoin difficulty. By contrast an ASIC vendor will eventually have to sell near marginal cost, or not sell anything at all. There will be a race to the bottom because no one is going to buy ASICs that can not generate more bitcoins than it costs.

[MXRider]

Can anyone give me a link to a real and ready ASIC product that would back up all these claims about FPGAs becoming paperweights?

Oh shit, I forgot, there isn't ASIC available to miners at least in two months. No one really knows the hashingspeed, price, power consumption or even the lead time. So why does this thread have so many replies.

[Bitcoin Oz]

Can anyone give me a link to a real and ready ASIC product that would back up all these claims about FPGAs becoming paperweights?

Oh shit, I forgot, there isn't ASIC available to miners at least in two months. No one really knows the hashingspeed, price, power consumption or even the lead time. So why does this thread have so many replies.

ASIC is the elephant in the room.

[melco]

As for me, the only people worried about ASIC are GPU/GPU farm owners. ASIC will kick them off from the business. ASIC itself will replace current CPU and GPU power. It will happen sooner or later.
I belive that  ASIC != The end of decentralized mining, it is the end of profitable GPU mining. There will be less miners but Bitcoin will be more protected overall.

[cablepair]

It is unbelievable that a community of relatively intelligent people cannot see how ASIC will ruin mining profitability for everyone and only make the manufacturers rich.

There is no financial model that can make these work due to their incredibly low marginal operation cost and ridiculously high hashrate.

The ASIC manufacturers would have to control the rate at which these are sold to stand any chance of miners getting a return on their investment and no business is going to do this after spending such a huge initial investment. Especially since after they sell the first several units at high prices, making more is so cheap they can just start unloading them at rock bottom prices.

The early ASIC buyers will never turn them off due to their low operation cost even though they stand ZERO chance of recouping their investment.

This is just standard economics and common sense.

I hope the bitcoin DEVS change the protocol to make ASICS obsolete. It will save the irrational potential buyers from themselves and the rest of us along with it.

+1

[P4man]

Can anyone give me a link to a real and ready ASIC product that would back up all these claims about FPGAs becoming paperweights?

I already did. Granted, its a research chip, but the numbers are there.

[ice_chill]

LOL @ Cablepair guy, he is selling outdated and overpriced FPGA systems, ASIC will kick him out, ofcouse he is gonna hate it LMAO!

[cablepair]

LOL @ Cablepair guy, he is selling outdated and overpriced FPGA systems, ASIC will kick him out, ofcouse he is gonna hate it LMAO!

laugh your ass off all you want

you obviously have no idea what your talking about


outdated? we use the same Spartan6LX150 FPGA chip that all the other manufacturers are , also our unit is the cheapest quad unit currently available and is twice as efficient as the BFL single

we are selling units every single day in big numbers

Oh and by the way just beacause you can't afford it, does not mean its over priced


so before you talk shit - do your research.

[ebereon]

LOL @ Cablepair guy, he is selling outdated and overpriced FPGA systems, ASIC will kick him out, ofcouse he is gonna hate it LMAO!

laugh your ass off all you want

you obviously have no idea what your talking about


outdated? we use the same Spartan6LX150 FPGA chip that all the other manufacturers are , also our unit is the cheapest quad unit currently available and is twice as efficient as the BFL single

we are selling units every single day in big numbers

Oh and by the way just beacause you can't afford it, does not mean its over priced


so before you talk shit - do your research.

+1

[bombo999]

LOL @ Cablepair guy, he is selling outdated and overpriced FPGA systems, ASIC will kick him out, ofcouse he is gonna hate it LMAO!

+1

[DeathAndTaxes]

I think you are vastly underestimating the potential of asics; a 130nm asic is ~40x as energy efficient as current 65nm fpgas for sha256 hashing according to papers ive seen and linked. A 40nm asic would therefore be closer to 100x more efficient than an FPGA.

From your link http://rijndael.ece.vt.edu/sha3/publications/DSD11SHA3.pdf I compute 400 Mhash/J for a 130nm ASIC. So probably ~1000 Mhash/J at 40nm. This is 50x better than a 45nm FPGA (Spartan6 = 20 Mhash/J).

But this still does not change my mind: the first mining ASICs will likely be manufactured on the 130nm node, so their 400 Mhash/J characteristic will make them a 20x efficiency increase over 45nm FPGAs. Not much different from past 10x technological leaps.

The 400MH/J was based on the chip which was optimized to allow all SHA-3 algorithms perform at their optimal clock rate.  It shouldn't be considered the pinacle of SHA-256 performance as including SHA-256 wasn't the main purpose of the chip.  It should be taken as the bare minimum of what an underclocked and unoptimized design can acheive and as you point out that is already 20x.  

Take a look at figure 9.  Notice the line for SHA-256 is nearly vertical.  This means the clock could be ramped up significantly without increasing the transistor count.  The chip as evaluated ran @ 200 Mhz however you can see that 300 Mhz requires an insignificant increase in kGE.  Now 300Mhz is already 50% higher performance but that shouldn't be taken as a max.  The "sweet spot" is likely 600 Mhz or higher.  Maybe a 1Ghz.  So why didn't they test it at 1Ghz?  That wasn't the point of the chip.  The clock speed chosen was a compromise to neither hinder nor help any of the SHA-3 candidates.  

Then you have to consider the algorithm used was inefficient from Bitcoin's perspectives.  It is a streaming hash design where the output of one block is combined with input of a second block.   Bitcoin is a static single block operation which significantly cuts the resources required.   No communication lines back to the input have to be made because it is simply data -> data out.  then new data in -> new data out.  

20x is the performance for an unoptimized design running at an inefficient clock speed.   A bitcoin optimized single pass double hasher (with all the shortcuts) running at 1Ghz on 130nm process is probably more like 40x to 50x.  The move to smaller processes will be combined with increased experience and optimization so the jumps in performance beyond that are going to happen faster than Moore's law.  The end game of 100x FPGA (and 500x GPU) performance on MH/W is likely conservative when at same manufacturing process (i.e. 28nm GPU, FPGA, ASIC).  

However I do agree that Mhash/dollar will be a more interesting metric to watch than Mhash/J. I wonder why you think ASIC will contribute a 1000x improvement in this area (going from $1 per Mh/s to $1 per Gh/s)?

Basing on the square mm and a clock speed of 1 Ghz the raw manufacturing cost would be closer to $0.10 per GH/s.  Now granted you have the NRE, the capital cost, the profit magins, yield losses, salaries, etc but even with 1000% markup <$1 per GH/s would be possible.

One way to look at it is the SHA-256 hasher only took 20kGE.    Lets say scaling it to 1 Ghz required twice as many GE and you want to make it perform a double hash; so 80 kGE. Obviously you wouldn't make a chip that small.  But hashing is perfectly parallel.  Instead of 1 single hashing engine running 1Ghz you could lay down 20 parallel engines.  So that on each clock 20 nonces are calculated simultaneously (20 GH/s @ 1Ghz).  Even that would only be ~ 1.6M GE.  Tiny small by modern chip standards (which have transistor counts in the billions).   The $20 CPU in your smartphone likely has a higher transistor count.

[Dexter770221]

1 gate != 1 transistor. Simplest NOT gate requires 2 transistor. AND XOR gates even more, not to mention adders that required at least 3 gates.

[DeathAndTaxes]

1 gate != 1 transistor. Simplest NOT gate requires 2 transistor. AND XOR gates even more, not to mention adders that required at least 3 gates.

I never said that it was.  Regardless 1.6M GE is downright tiny.  Lets assume every GE took 5 transistors. 

A 7970 GPU has 4.3 BILLION transistors.