Ytterbium,
Thanks for the correction on rounds (65 vs 80) and for the link. Link saved. I assumed 80 because SHA-2 is a 80 round cipher they must do some preprocessing or optimization which makes sense and it roughly fit with likely frequency range.
As aerobatic stated the GN die efficiency is 1.23 GH/mm² (nominal), 1.66 GH/mm² (overclocked).
Saying Bitfury has a theoretical speed of 5 GH/s is kinda pointless, it was the design goal but never acheived in real world not even once under lab conditions. Real world Bitfury is more like 1.5 GH/s (nominal), 3.0 GH/s (overclocked)*. That gives Bitfury (@55nm) a die efficiency of 0.10 GH/mm2 (nominal), 0.21 GH/mm2 (overclocked). You stated 40nm but Bitfury is actually 55nm, and the efficiency (both GH/mm2 and J/GH) are impressive for 55nm**. The numbers might look low to some reading but that is the power of a couple doublings. To show you some bad efficiency BFL for example is 65nm but lets boost their stats by 40% (65^2/55^2) to put BFL and Bitfury on the same 55nm process node. BFL's die efficiency is 0.062 GH/mm2, with a 40% boost for 55nm vs 65nm for apples to apples it is still only 0.087 GH/mm2. Now that is with the chips overvolted and driven pretty hard and hot. Ouch BFL.
So how would a Bitfury @ 28nm compare to HashFast Golden Nonce? Note: this shouldn't influence anyone purchase decision as we don't even know if Bitfury plans a 28nm, when it will be released, if they will hand place it, and if these theoretical gains are possible. With that caveat, a die shrink from 55nm to 28m means 4x the transistor density (552/282 = 4.0). Lets be generous and say 50% higher clocks are possible (real world is probably going to be less than what raw capacitance and switching time would indicate but I am trying to err towards the upper limit) Between clock increase and transistor density performance is likely going to be capped at 6x. A theoretical "Bitfury28" would be ~0.60 GH/mm2 (nominal), 1.26 GH/mm2 (overclocked). This is with no architecture changes just same design and smaller features (the "tock" in Intel's "tick tock" strategy) and scaled out parallel (more cores similar chip dimensions). There are power issues which prevent Bitfury from achieving the 5 GH/s (420 Mhz) design spec at 55nm. If they were solved efficiency would be higher. This is somewhat academic as the 5 GH/s spec was simulated due to the highly efficient use of hand placing. However hand placing has a lot of pitfalls and Bitfury fell into one making real world performance lower. "Bitfury28" while having the same general design may not be hand placed. It is time consuming and more risky. At 55nm it didn't pay off all the extra work and effort produced a chip which is roughly what we would expect from a cell library design. Still to be totally exhaustive if the Bitfury had performed as expected it would be 5 GH / (3.8mm * 3.8mm) = 0.34 GH/mm2. With 6x performance improvement that would be ~ 2.00 GH/mm2 with a more realistic 4x performance improvement ~ 1.36 GH/mm2.
To add to what Aerobatic said about Bitfury being a hand placed chip, this has some implications going forward. Very few designers hand place large ASICs because of the increased time and cost. Cell libraries are used to assist with the feature change size, without them you are essentially hand placing a new chip at each process node. While the design may be exactly the same, the position of each transistor is going to change. One also needs to consider risk vs reward. Bitfury's power issues stem from the fact that design was not capable of delivery the power intended, without the intended power the intended clock frequency couldn't be achieved. The chip "worked" but had to be clocked slower. It is possible this type of error could have been avoided using a cell library. So had Bitfury used a cell library maybe they would have got 4 GH per chip, less than what hand placing could do in theory but more than it did in reality. In mid 2013 Bitfury mistake wasn't fatal. BFL was not delivering, margins were massive, and other competitors were using much large process nodes. In 2014 the scenario won't be the same. A similar mistake would make an offering less attractive than competitors.
*Based on reference design of ~25 GH/s per "H-board" with 16 chips. A few higher clocked variants (like S-board project) have pushed that to 42-45GH/s. Assuming I am missing some marginally higher clocked board I optimistically used 3 GH/s as realistic overclock limit.
** Moved this down here because most people probably don't care. A side note, it may seem I am critical of Bitfury but I am not, I am just interested (obsessed maybe?) with finding good data. Hell IMHO it is impressive that Bitfury is even still around. Right at the point where they had perfected their FPGA design (better than anyone else on the same hardware) and were looking to mass produce (summer 2012) BFL began the obviously false campaign of "ASICs in 3 months". Remember when BFL was going to delivery ASICs by fall 2012? BFL may be crooked but they are smart. By offering upgrade value on their FPGA and over-promising ASICs almost a year early it killed the rest of the FPGA market while still keeping BFL FPGA sales alive (they could be upgraded). Many startups wouldn't have survived seeing their entire market disappear with no revenue potential for a year. It was unfair, dishonest, and a sucker punch but it wouldn't have surprised me if BFL had killed Bitfury. Instead the Bitfury team transitioned their FPGA design to a hand placed ASIC in a short period of time, delivered solid performance and did so without the ability to collect (and sit on) preorder money in 2012. So I am impressed by what Bitfury has done but that doesn't diminish the impressive die efficiency of the Golden Nonce processor.
Topic: HashFast launches sales of the Baby Jet - page 28. (Read 119626 times)
Ytterblum -
i remember reading the hashfast chip had 4 dies each of 9x9 mm... thus a total of 324mm² to get a nominal 400 GH/s and a max of 540 GH/s, thus their perf per mm is between 1.23 GH/mm² (nominal) and 1.66 GH/mm² (max overclock and not recommended to be run at this speed, as mentioned in their latest specs)
comparing 40nm to 28nm isn't a linear comparison like you did. its two dimensional, thus maybe you could fit four times (or at least more than two times since 40 isn't a doubling of 28) as many transistors in a similar die area.
also, don't forget that the bitfury chip is 'full custom' which means he laid out his circuit by hand - painstaking work thats not likely to be repeated very often. all the other bitcoin chips are standard cells using someone else's cell library (apart from the vmc/amc, which is an eAsic, and thus can probably be written off in perf and power terms)
-- Jez
i remember reading the hashfast chip had 4 dies each of 9x9 mm... thus a total of 324mm² to get a nominal 400 GH/s and a max of 540 GH/s, thus their perf per mm is between 1.23 GH/mm² (nominal) and 1.66 GH/mm² (max overclock and not recommended to be run at this speed, as mentioned in their latest specs)
comparing 40nm to 28nm isn't a linear comparison like you did. its two dimensional, thus maybe you could fit four times (or at least more than two times since 40 isn't a doubling of 28) as many transistors in a similar die area.
also, don't forget that the bitfury chip is 'full custom' which means he laid out his circuit by hand - painstaking work thats not likely to be repeated very often. all the other bitcoin chips are standard cells using someone else's cell library (apart from the vmc/amc, which is an eAsic, and thus can probably be written off in perf and power terms)
-- Jez
unrolled cores are not necessarily crappy cores.
Agree however they can't be compared directly. It takes 80 clock cycles for a Bitfury rolled core to complete a hash where as an unrolled core will complete a hash in one clock cycle. So clock for clock Bitfury 756 rolled cores complete about the same number of hashes are 9 unrolled cores. This isn't to say one method is better than another. They are just different. Given similar die efficiency a 9 unrolled core chip and a 756 rolled core chip would be comparable size, power usage, and hashpower.
Another way to look at it is GN's 768 nonces per clock cycle would be the equivalent of Bitfury announcing they have a new processor with 61,440 rolled cores.
Any way you slice it a single GN processor is a staggering number of cores each one processing a full nonce every clock cycle. No existing design comes close to putting as much hashpower in a small package (Cointerra probably will be similar but so far specs are unknown).
Quote
And much of that can be expressed as a GH's / Die area, that would give you a measure of efficiency - or in its simplest terms, GH's/S. per square mm of die area - at least when comparing like for like (all 28nm's for instance)
Agreed and by that metric the GN is extremely dense. A huge amount of hashing power per mm2.
I remember reading that the Hashfast was about 6.5x6.5mm, or 42mm2 The bitfury chips are only 3.8x3.8, or 14mm2, about 3 times the surface area.
According to this it only takes 65 cycles for a bitfury core to compute a hash, not 80.
1. 756 double sha256 cores. 61+4 kernel (61 clock cycle computation 4 clock cycle load).
2. There's asynchronous 'match' signal - the only thing that core sends out. And some busses to load data.
3. wirebond. die is laid normally in cavity. i.e. it is not flip-chip and not arranged to give heat into anything else, but PCB.
It is actually not complex to dissipate 3W... Maybe even 5W with metal-core PCB and proper cooling. That's what we'll see.
Also, the theoretical speed of the bitfury chips (which is what we're comparing) was about 5Gh/s. 40nm2/28nm2 = 2.25, so HF should be able to cram 2.25 times twice as many transistors in the same amount of space. And those transistors should be faster, with about 0.75 times the transistor gate capacitance.
So, if you were able to scale the bitfury design to 28nm, and increase the surface area to 42mm2, you would expect the theoretical speed to equal 2.25*1.5*3* = 50.6Gh/s. On the other hand, it would only take about 33W as well.
It's interesting that the W/Gh/s would actually be a little better, for bitfury while the surface area efficiency seems to be about 10x for HashFast.
It could be that the BF chips may have been deliberately spread out in order to make it easier to keep the chips cool, obviously the HF chips require a lot more cooling. It's actually likely that complete miners are actually cheaper to build and deploy using bitfury chips due to the reduced cooling requirements.
650PH predictions make no sense because of all these reasons and are based on "well, if it keeps going on forever like it has for just the last two months then this is where we'll be" and not on all the things you are bringing up.
FWIW, I end up with very similar numbers when calculating the "end game", using todays BTC value and estimating costs based on HF's chip efficiency and estimated production costs:
The big unknown is how fast we will get there, it will probably take longer than a year, but I have no doubt we will get there if todays BTC value holds.
I know it is the obligation of everyone in the forum to chase everyone off (moar BTC for me!) , so I know an optimistic outlook is a faux pas,
As if that would work. Many of us have been predicting this bloodshed among virtually all asic customers for years now, it didnt change a thing, and wont change a thing.
Quote
Quote
but there is a cap on how many people want to buy ASICs and we're going to hit an inflection where hardware supply will simply exceed demand.
Doesnt everybody want to make money without working? As long as asics are at least marginally profitable, people will buy.
Quote
And when people no longer buy, prices will just drop until they buy again. The capacity is there, its going to be used one way or another. Even if miraculously miners no longer buy, these asics will just end up in large private mines.
We're agreeing. The point at which supply exceeds demands is an example of one reason to lower prices - to increase demand again.Quote
BTW, Im sure there are loads of (ex)miners like me, sitting out the current onslaught, but who want to get in to the game again once things have settled down a bit, say next summer or so. I dont mind thin margins and long ROI times, I just dont want it to be a 100% gamble if my chosen manufacturer will be shipping one week sooner or later and how much the others will ship in the 6 weeks thereafter. Satoshi dice gives you far better odds. But that doesnt mean I wont buy an asic ever, if the opportunity presents itself, Ill buy. But thats not gonna happen anytime soon.
Also a great point. I'm saying is that there is a limit to how many miners people will buy and that is bound by common sense (like you), your available electrical capacity (home or what you're willing to host somewhere), the BTC market conditions (CURRENTLY not being a factor, but not a guarantee) and physics (28mm is the min size for BTC ASICs for the near term). 650PH predictions make no sense because of all these reasons and are based on "well, if it keeps going on forever like it has for just the last two months then this is where we'll be" and not on all the things you are bringing up. The last two months are not normal and long-term predictions based on a very unique period in BTC history is what everyone is doing and its misguided.
I would be interested to know what method the dies are attached to the heatspreader.
well, i told you the magic was going to be in the modules.
unrolled cores are not necessarily crappy cores.
Agree however they can't be compared directly. It takes 80 clock cycles for a Bitfury rolled core to complete a hash where as an unrolled core will complete a hash in one clock cycle. So clock for clock Bitfury 756 rolled cores complete about the same number of hashes are 9 unrolled cores. This isn't to say one method is better than another. They are just different. Given similar die efficiency a 9 unrolled core chip and a 756 rolled core chip would be comparable size, power usage, and hashpower.
Another way to look at it is GN's 768 nonces per clock cycle would be the equivalent of Bitfury announcing they have a new processor with 61,440 rolled cores.
Any way you slice it a single GN processor is a staggering number of cores each one processing a full nonce every clock cycle. No existing design comes close to putting as much hashpower in a small package (Cointerra probably will be similar but so far specs are unknown).
Quote
And much of that can be expressed as a GH's / Die area, that would give you a measure of efficiency - or in its simplest terms, GH's/S. per square mm of die area - at least when comparing like for like (all 28nm's for instance)
Agreed and by that metric the GN is extremely dense. A huge amount of hashing power per mm2.
Bitfury chips actually have 756 cores.
Sounds like they're using "unrolled" (i.e. crappy) cores.
Not exactly, they say they say each core has two units which "share work" across one "job". Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.
Sounds like they're using "unrolled" (i.e. crappy) cores.
actually the doc says double hash or 768
Not exactly, they say they say each core has two units which "share work" across one "job". Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.
Regardless of how they share work each "sub core" completes one hash per clock cycle so it isn't like they are only partial work engines.
So 4 * 96 * 2 = 768 hashes per clock cycle.
At 550 Mhz that is 768 * 0.550 = 442.4 GH/s.
So making an analogy if they are using "unrolled" cores(bitfury) the chips will have 221 GH/s and the power consumption if denying refund(BFL) must be bigger by a factor of 4(BFL missed their power specs by 4 right?) achieving only 2.6W/GH
Bitfury chips actually have 756 cores.
Sounds like they're using "unrolled" (i.e. crappy) cores.
Not exactly, they say they say each core has two units which "share work" across one "job". Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.
Sounds like they're using "unrolled" (i.e. crappy) cores.
actually the doc says double hash or 768
Not exactly, they say they say each core has two units which "share work" across one "job". Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.
Regardless of how they share work each "sub core" completes one hash per clock cycle so it isn't like they are only partial work engines.
So 4 * 96 * 2 = 768 hashes per clock cycle.
At 550 Mhz that is 768 * 0.550 = 442.4 GH/s.
Bitfury chips actually have 756 cores.
Sounds like they're using "unrolled" (i.e. crappy) cores.
Actually, no. They say they say each core has two units which "work together" on one "job". Whatever that means.
Sounds like they're using "unrolled" (i.e. crappy) cores.
actually the doc says double hash or 768
Actually, no. They say they say each core has two units which "work together" on one "job". Whatever that means.
unrolled cores are not necessarily crappy cores.
all we care about is the GH/s... we don't mind whether they achieved it from rolled or unrolled hash engines.
some implementations will do better with rolled cores and some with unrolled. depends completely on the design.
with rolled cores you can cram more of them on a die, but run at a slower speed. with unrolled, you can run at a higher clock speed, but fit less of them on a die. either of them could be better... depends on many factors, but the bottom line... Performance, Power consumption, and Cost... are what we care about. And much of that can be expressed as a GH's / Die area, that would give you a measure of efficiency - or in its simplest terms, GH's/S. per square mm of die area - at least when comparing like for like (all 28nm's for instance)
-- Jez
Bitfury chips actually have 756 cores.
Sounds like they're using "unrolled" (i.e. crappy) cores.
Not exactly, they say they say each core has two units which "share work" across one "job". Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.
Sounds like they're using "unrolled" (i.e. crappy) cores.
actually the doc says double hash or 768
Not exactly, they say they say each core has two units which "share work" across one "job". Whatever that means. Presumably a nonce range, so one chip would work on nonce 0xFFFF0001 while the other would work on 0x0001FFFF, or some other distribution.
actually the doc says double hash or 768
It is a lot, but not unheard of. Small Bitfury 2.7 GHs ASIC has 50+ (or was it 70?) cores, KNC ASIC has 192.
More detailed specifications are published for the Golden Nonce chips.
From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf
Quote
The general parameters of a HashFast GN ASIC are:
Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.
Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.
Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.
Modules which are over-clocked will contain logs of such operation, which may void warranty.
It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.
1 Preliminary data – subject to change
- Each ASIC substrate contains 4 separate die.
- Each die contains 96 cores.
- Each core contains two complete double hash engines, which share work across one job
- Hash cores may nominally be clocked at 550 Mhz1
- Hash cores are rated for clocking at up to 700 Mhz under standard operating conditions
- Clock rates higher than this, and voltage levels lower than the nominal 0.81V, are outside of
normal operating conditions. - Cores search for nonces at (host specifiable) hardware based levels of Bitcoin Difficulty up to
the ridiculously high limit of 7.922x1028
Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.
Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.
Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.
Modules which are over-clocked will contain logs of such operation, which may void warranty.
It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.
1 Preliminary data – subject to change
From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf
184 cores per chip!?
384
More detailed specifications are published for the Golden Nonce chips.
From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf
Quote
The general parameters of a HashFast GN ASIC are:
Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.
Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.
Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.
Modules which are over-clocked will contain logs of such operation, which may void warranty.
It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.
1 Preliminary data – subject to change
- Each ASIC substrate contains 4 separate die.
- Each die contains 96 cores.
- Each core contains two complete double hash engines, which share work across one job
- Hash cores may nominally be clocked at 550 Mhz1
- Hash cores are rated for clocking at up to 700 Mhz under standard operating conditions
- Clock rates higher than this, and voltage levels lower than the nominal 0.81V, are outside of
normal operating conditions. - Cores search for nonces at (host specifiable) hardware based levels of Bitcoin Difficulty up to
the ridiculously high limit of 7.922x1028
Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.
Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.
Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.
Modules which are over-clocked will contain logs of such operation, which may void warranty.
It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.
1 Preliminary data – subject to change
From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf
184 cores per chip!?
More detailed specifications are published for the Golden Nonce chips.
From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf
Quote
The general parameters of a HashFast GN ASIC are:
Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.
Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.
Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.
Modules which are over-clocked will contain logs of such operation, which may void warranty.
It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.
1 Preliminary data – subject to change
- Each ASIC substrate contains 4 separate die.
- Each die contains 96 cores.
- Each core contains two complete double hash engines, which share work across one job
- Hash cores may nominally be clocked at 550 Mhz1
- Hash cores are rated for clocking at up to 700 Mhz under standard operating conditions
- Clock rates higher than this, and voltage levels lower than the nominal 0.81V, are outside of
normal operating conditions. - Cores search for nonces at (host specifiable) hardware based levels of Bitcoin Difficulty up to
the ridiculously high limit of 7.922x1028
Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.
Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.
Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.
Modules which are over-clocked will contain logs of such operation, which may void warranty.
It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.
1 Preliminary data – subject to change
From: https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf
I know it is the obligation of everyone in the forum to chase everyone off (moar BTC for me!) , so I know an optimistic outlook is a faux pas,
As if that would work. Many of us have been predicting this bloodshed among virtually all asic customers for years now, it didnt change a thing, and wont change a thing.
Quote
but there is a cap on how many people want to buy ASICs and we're going to hit an inflection where hardware supply will simply exceed demand.
Doesnt everybody want to make money without working? As long as asics are at least marginally profitable, people will buy. And when people no longer buy, prices will just drop until they buy again. The capacity is there, its going to be used one way or another. Even if miraculously miners no longer buy, these asics will just end up in large private mines.
BTW, Im sure there are loads of (ex)miners like me, sitting out the current onslaught, but who want to get in to the game again once things have settled down a bit, say next summer or so. I dont mind thin margins and long ROI times, I just dont want it to be a 100% gamble if my chosen manufacturer will be shipping one week sooner or later and how much the others will ship in the 6 weeks thereafter. Satoshi dice gives you far better odds. But that doesnt mean I wont buy an asic ever, if the opportunity presents itself, Ill buy. But thats not gonna happen anytime soon.
The days of Avalon Batch 1 selling out in 5 hours are over.
seems really happened years ago, right? the old days ...
When you plug your numbers into this calculator, do you ever stop to think about the practicality of 91B difficulty/650PH in a year? Is difficulty just a number that keeps going up inexplicably to you?
Ill grant you 650PH in a year is at the extreme upper end of what I think is even conceivable. But only a very small % of all bitcoins mined by the device will happen after the 6 month mark, which at 9B isnt exactly far fetched, so the last 6 months or so of that simulation are irrelevant compared to the first 6 months; just as 650PH at the end of 1 year isnt very likely, its equally unlikely to me the next 10 difficulty adjustments will all be smaller than the past 10. The next 10 will coincide with KnC B2+, Hashfast, ActM, Bitmine, Cointerra, Black arrow perhaps even BFL Monarch, next gen avalons and next gen asicminers hitting the market, the previous 10 were caused basically by just 2 vendors.
Quote
SO the simulation is very flawed (why doesnt anyone implement a calculator with a sigmoid function for difficulty?), the conclusion might still be true for the simple reason that I cant think of a mechanism that would cause asic manufacturing and deployment to stop as long as each of these miners is operationally reasonably profitable for those with access to cheap electricity. The real question therefore becomes how fast these vendors can produce and deploy, and KnC shipping up to 600 boxes per day gives us a glimpse of how fast this could go, particularly with 10 competing suppliers (at least one of which is using monster sized manufacturing facilities)..
I know it is the obligation of everyone in the forum to chase everyone off (moar BTC for me!) , so I know an optimistic outlook is a faux pas, but there is a cap on how many people want to buy ASICs and we're going to hit an inflection where hardware supply will simply exceed demand. Jump to: