EIP: Modify block mining to be ASIC resistant.

[pipermerriam]

Disclaimer: My area of expertise does not lend well to me suggesting how to make things ASIC resistant. I hope there are some informed opinions floating around out there who can help fill in the how.

According to "the internet" there is an ASIC based ethereum miner on the horizon.

this may be the original source of that news

If you believe the analysis in the comments on this reddit thread BitMain may already running these miners.

I believe it is the accepted wisdom that ASIC based mining leads to increases centralization when compared to GPU mining.

This leads us to two questions:

1. Should we hard fork to make ASIC mining harder and to demonstrate a willingness to hard fork any future ASIC based ethereum mining.
2. What specifically changes do we make to implement this increased ASIC resistance.

Should we fork?

I propose that people indicate support/opposition with a simple 👍 / 👎 on this main issue. I would prefer this conversation not devolve into deep discussions around this subjective topic so my request is that people refrain from commenting on that specific question here.

How do we implement improved ASIC resistance

This is the primary issue that I think needs to be addressed, after which we can have an informed discussion about whether we should actually do it.

[atlanticcrypto]

@7runks I don't think this should be to penalize Bitmain in particular, it should be to focus on the type of decentralized compute resources the ethereum network wants to incentivize. I think the community is pretty adamant that ASICs are not it.

I also think they are going to take hard-fork threats seriously now that Monero is going to follow through on their threat. How do you treat R&D expense when it's a moving target?

[AirSquirrels]

@7runks it is extremely extremely unlikely that Bitmain represents anywhere close to 50% of the hash rate.

[7runks]

@AirSquirrels, if not yet, it will soon. From December to January, there was almost 50% increase in the network and from that all I'm sure 40% was from bitmain and co asics.

1.4 to 2.8 Is a lot.

[pipermerriam]

@AirSquirrels the bytecode execution piece looks interesting, but I'm very hesitant to go down that route given the inherent security risks that come with increased complexity. I'd rather pursue a minimal modification to the existing algorithm and then iterate from there. I don't think we're aiming to make the chain ASIC proof in this first step, but rather to do the following:

• validate the hypothesis that there are indeed ASICs mining (as measured by a significant drop in hashrate when the fork occurs)
• demonstrate willingness to fork to break ASICs.

After that we can pursue additional changes if necessary to increase ASIC resistance or brick newly developed ASIC miners.

[AirSquirrels]

@7runks feel free to continue this discussion off thread, as we're veering off-topic and these posts should be deleted, but the numbers available don't support that concept. It is far more likely that a very large number of GPUs came online than it is that ASICs were responsible for a majority of that hash-rate increase.

@pipermerriam I agree, although I wanted to present an option for a long term solution to begin discussion around it. If the goal is only to demonstrate that ETH we will take a stand against ASICs, simply change the FNV constant, and use different FNV constants for each of the major operations (DAG item selection, inner-loop mixing, and FNV compression of the mix.

[cryptomined]

@AirSquirrels I dont mean to go "offtopic", sorry, but... "It is far more likely that a very large number of GPUs came online than it is that ASICs were responsible for a majority of that hash-rate increase." is not true at all given how scarce (and expensive) GPUs were during that time period... however it may not only be bitmain producing and testing asics on the network..

[Arachnid]

@AirSquirrels I'm not sure why you'd think that a random bytecode machine would be difficult to implement on an ASIC. Each bytecode instruction will require a bare minimum of two - and likely more like 3-5 - native instructions to execute on a CPU or GPU, while an ASIC could implement it natively and do one instruction per cycle.

[goobur]

At this point, the goal should be to break existing ASIC designs. As an absolute fast and first step in kicking an ASIC off the network, if @AirSquirrels is correct and they are not using programmable logic, then changing the FNV prime in the mixhash would brick their design. Here's an alternative 32 bit FNV prime: 2^24 + 2^8 + 27 = 16777499 = 0x100011 This is an incredibly easy change to make in the short term (it's a simple change of a constant kernel code, and in the eth main branch) and won't affect the network at all. It puts us in no worse position than we're currently in, and kicks any non-programmable ASIC off the network (which we should be able to see in network stats).

@Isanderthul I agree that it's better to know what the problem is before trying to solve it, however, if a there is an actor working against the network's best interests, why would they reveal themselves? The option of "wait and see" is totally bogus in this situation because you (and every other member of the ethereum community) are being actively exploited right now -- you cannot expect your adversary to give up their advantage until it is truly no longer an advantage (perhaps another ASIC on the market, or they realise that the moment the community catches wind of ASICs, they'll try to fork away from them). The "best effort" option right now, is to try to figure out what their advantage is, then stop it with minimal changes on our part, the above solution is a very minimal way of doing so in the short term.

The next step, which is another good suggestion by @AirSquirrels, would be to change either the inital/final keccak, similar to how cryptonight does it. Although, if the first option works, this isn't worth pursuing until the next batch of ASICs are out (but they may be programmable then, and the point might be moot). This is an emergency 2nd solution, imo.

I also agree that there should be an investigation into changing the mixhash part of the algorithm -- in conjunction with a more thorough analysis of the algorithm by more people. I do like @AirSquirrels general bytecode idea here, but I'm with @pipermerriam -- it's too complicated of a solution at this stage and merits actual academic research before mainstream implementation and acceptance. It risks upsetting the current miner eco-system with little warning to them -- I'm fine with upsetting miners, but not on short notice.

[7runks]

@AirSquirrels, gpu's were very scarce, there was no way such heavy hashrate which took 2 years and half to build up to appear just in 2 months. Fair enough, I will not discuss this anymore however make a point and check how much the hashrate will crash once an anti asic method on eth network is implemented.

@cryptomined, he is in denial like many.

[AirSquirrels]

@cryptomined @7runks Production didn't decrease, you're reading the scarcity indicator the wrong direction. The scarcity was because all of the produced GPUs were being placed into service (mining ETH). It is backwards logic to view the scarcity as a reason why a lot GPUs couldn't be placed into service. If difficult went up while GPUs were not scarce it would be a larger indicator of heavy ASIC activity. In addition a large number of otherwise occupied existing GPUs were also sold at premiums on the second hand market or switched from gaming to mining on perceived profit.

@Arachnid while some op-codes could be implemented in one cycle, all ops would be dependency chained to previous ops and you're still subjecting the ASIC to instruction fetching, decoding, branching, etc. I believe modern CPUs have lower cycle count 64 bit multiplication, integer division ops than most programmable logic can achieve in serial latency. Pipelined throughput would be a different concerned if op-ports were shared between pipelines, but with enough macro ops I don't think you'd have the logic/chip area to do so. I also viewed macro ops such as AES, keccak rounds, other hash algorithms from the finalizers, etc. as part of the pool, which would require either multiple cycles or a large amount of area. The goal is not to make them ASIC impossible, but to make the cost and complexity of the ASIC similar to that of a CPU or GPU and limit each physical chip to a small number of parallel hash pipelines.

[7runks]

@AirSquirrels, you made your point and I made mine, let's see who was right all along once the anti asic method is implemented.

[cryptomined]

@AirSquirrels but it would not have increased so much due to only GPU's, and I do think i remember from watching Gamers Nexus that GPUs were kinda inbetween production... And... Nvidia based board partners are not really producing more pascals since the end of last year due to preparing for the new GPUs to come out, And Nvidias p102 only recently came out, they were not out in January...

It is a real shame as GPU Manufacturers, specifically NVidia, were just now becoming efficient at producing Mining Only GPUs (p014 and p102 compared to the fail on p106)... Supporting GPU manufacturers is much better than supporting ASICs from an economic standpoint as those companies actually produce things that benefit the general public... the R&D budget they gained in the last year will benefit gamers for example... and AI...

As I am sure all of us here are computer lovers in general... I would much rather support computer companies directly... and if ASICs take over... i have to quit as they are just against my ethics.

anyways, right, back to discussion on how to alter the algo. :)

[AirSquirrels]

@cryptomined I agree, I have no stake in being right so it will just be interesting to see when a fork occurs.

@goobur Regarding switching out the initial and final hash algorithm, it would generally be better to switch both, but we should keep in mind that the final hash has less opportunity for weakness exploitation as its input is particularly random. That makes it the "safer" option to change to a less proven function.

I should also indicate that the initial and final hash could be done off-asic or in one programable logic chip per board. The bandwidth for sending that data to / from ASICs isn't much for modern transceivers (96 MB/s full duplex per MH) and one chip (or GPU) can do an order of magnitude or two more hashes than the chips with the memory need.

[pipermerriam]

@goobur I don't have the expertise needed to really evaluate your proposal (new FNV) but it sounds wonderfully simple to implement and low risk.

It seems like the next step would be to create a formal EIP. Again, this is something that I don't feel qualified to do. Would you be up for writing up an EIP for this with a spec for the new algorithm. I'd be happy to help with writing up the copy parts for things like abstract, etc, as well has helping "champion" this through the process. If we can get something written up by mid-week that would give core devs time to look it over so that it can be discussed in the all-core-devs meeting this Friday.

[pipermerriam]

@goobur feel free to contact me directly Gitter/email/keybase if you want to talk about this out-of-band.

[Buttaa]

@7runks "1.4 to 2.8" ... this is just 2x since december

https://blockchain.info/en/charts/hash-rate?timespan=1year Bitcoin's went ~3x in the same time and they already had asics.

[7runks]

@ButtaTRiBot, 10.7, 01 december - january 30 - 15.1, that is 50%. I don't see 3x.

Also like you said they are already asics which can be produced unlimited if bitmain has the in chips which they have, now concerning gpu's it can't as nvidia had stopped production prior to end of year and amd hardly manufacture that many gpus.

[Eliovp]

Regarding the hashrate, there's no way this is due to GPU's.

I'm almost absolutely sure it isn't.

I have sources in both the green and the red camp who have an almost spot on idea about how much hardware (GPU's) has been sold the past couple of months. Due to non disclosure agreements, i am not allowed to go into detailed numbers. However, what i can tell you is that by the numbers i've seen, by simply converting those into an avarage hashrate (ETH speeds), the increase in hashrate is not even close to that.

Yes i'm well aware that there's still a gaming market and a few other specific markets out there. So this drops the numbers even more..

Also realize that i didn't even look at all the other coins/algo's out there that are as well being mined with GPU's and where the hashrate has only increased over the past couple of months.

It is not just clear, it's more than obvious that there are ASICS in play here. It is also very well known that certain companies such as bitmain, utilize their hardware for a pretty long time before they even think about selling them to the massess and while doing that keeping them as private as they can.

A product that is extremely profitable, why would one sell that? Exactly, one doesn't.. (yet)

A stitch in time saves nine...

[goobur]

@pipermerriam To give credit where credit is due, changing FNV is not my idea, credit belongs to @AirSquirrels. The question you have to ask is whether this change is going to introduce some sort of vulnerability in the mining code. My question, then, is whether the FNV hash is meant to provide any sort of security in a cryptographic sense? As far as I see it, no -- it's there to compress/mix dag nodes, which themselves are cryptographically secure. FNV isn't considered a cryptographic hash, so I assume it's not there for its security, but rather its speed.

FNV primes have a very specific definition [1]:

  ... Now, consider any n-bit FNV hash where n is >= 32 and
  also a power of 2, in particular n = 2**s. For each such n-bit FNV
  hash, an FNV_Prime p is defined as:

  When s is an integer and 4 < s < 11, then FNV_Prime is the
  smallest prime p of the form:

        256**int((5 + 2**s)/12) + 2**8 + b

  where b is an integer such that:

        0 < b < 2**8
        The number of one-bits in b is 4 or 5

  and where ( p mod (2**40 - 2**24 - 1) ) > (2**24 + 2**8 + 2**7).

  Experimentally, FNV_Primes matching the above constraints tend to
  have better dispersion properties. They improve the polynomial
  feedback characteristic when an FNV_Prime multiplies an intermediate
  hash value. As such, the hash values produced are more scattered
  throughout the n-bit hash space.

By definition, there's only one true FNV prime for a given bitlength. However, relaxing the minimality condition gives a set of FNV primes, this python code generates them:

candidates = [2**24 + 2**8 + _ for _ in xrange(256)]
candidates = [_ for _ in candidates if is_prime(_)]
["0x%x" % _ for _ in candidates if _ % (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7)]

which gives: ['0x1000181', '0x1000193', '0x10001a1', '0x10001a7', '0x10001ab', '0x10001c5', '0x10001cf', '0x10001d1', '0x10001e3', '0x10001ef', '0x10001f9', '0x10001fb'] Notice that the prime we currently use (0x1000193), is not the minimal prime (also notice that the prime I suggested originally is not in this list, as it doesn't satisfy the inequality in the last line of python code). So I assume that choosing a different FNV constant (one that's in this list) won't compromise the FNV hash.

To be clear on my skill set, I'm a fledgling mathematician and computer scientist, I've implemented ethash multiple times, but I am not an expert in cryptography. Moreover, I can't seem to find any thorough academic analysis/reference of the FNV hash. @pipermerriam I don't feel comfortable pushing this solution forward without an opinion from somebody who /is/ an expert in cryptography.

[1] https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1

[pipermerriam]

@goobur 👍 and understood. @AirSquirrels thoughts? Do you feel comfortable at least being the initial author of an EIP for this minimal change? (sorry for the mis-attribution of who originally proposed the FNV change).

I don't think we have to have something that we know is cryptographically secure at this stage, as much as a proposal with a specific enough specification that the experts can help refine it to something that's viable.

[AirSquirrels]

@pipermerriam @goobur I don't mind being the author of the EIP, however I am not completely familiar with the ETH teams formal EIP process or format guidelines. I have experience in the math and design/hardware side of this but I am also not a formal cryptography expert - although I don't believe that is a requirement for this change. Perhaps @pipermerriam would like to create a draft EIP from the template and I can finalize and submit a pull request.

Aside from the change to ethash itself, which we are proposing as a simple change from one static FNV constant to three new relaxed-constraint FNV constants, there are other considerations that need to be addressed and formalized for the EIP

1. Timing of the proposed hard-fork. You need to give time for all node software and miner authors to create and test updates, as well as time for miners and node / pool operators to update. I think this is requires an absolute minimum of two weeks, and 30 days would be even better from the perspective of those users. The flip side of this discussion is you have already given dedicated hardware development that much time to anticipate and make changes. That puts us at or around block 5555555, but the exact block is arbitrary. Since many pools only provide the seed hash, 5550000

2. FNV Constant selection. I concur with @goobur that his option list is a good candidate list. I also agree FNV isn't supposed to be super cryptographically secure, we are relying on Keccak for that. With that said, it would be ineffective given the amount of random data introduced through the DAG mixing to take advantage of any FNV pattern when using appropriate primes as @goobur described. How about 0x1000181 for DAG item address selection (the best candidate FNV value for the most sensitive place FNV is employed), 0x10001a7 for mixing, and 0x10001f9 for compression? Using three different FNVs is trivial effort protection against an ASIC that may have been developed anticipating the easiest breaking changes, as it would break the expectation that only the shared FNV constant would change.

3. Backwards Compatibility/Signaling Current miners that mine on other chains would need signaling or configuration to know they are mining using the ethashV2 algorithm. XMR had a more flexible Blob input rather than 32byte header+nonce. This would require stratum changes, or additional input fields. On the plus side, if you introduced a 32 byte header with pre-pended 1-byte hash version field (33 bytes) assumed to be zero if not present into the job and work, you could easily change hash algorithm versions in the future, and nodes could choose to accept or reject individual algorithms. Ideally you would want the additional field included in the blockchain as well, which makes this change even deeper. This would allow other chains to optional allow ASICs while remaining compatible with ETH miners/node software. If there is some other mechanism to handle PoW changes included in ETH's design I am unaware of it.

[pipermerriam]

@AirSquirrels mind reaching out to me over email or gitter?

[kimicg]

@AirSquirrels How will this impact gpu mining or will change DAG size?

[AirSquirrels]

@kimicg If adopted, this FNV change will have no performance effect on mining or the DAG size. The mechanisms to indicate that the new mining algorithm should be used will likely use a trivial bit more network bandwidth.

[hadees]

@crazydart a physical address attached to your miners through it's ip. I'm talking about using SIM cards and they can't be spoofed as easily because the SIM cards aren't going to be providing the location directly, it's gotten from the towers that connect to them. Just to be safe don't trust just one tower owned by one company, check a few different ones. Most SIM cards can see multiple ones from various providers. If you do it right an attack on the location would have to come from multiple big telecom companies working together, which is possible but seems unlikely.

Anyway the FNV seems like a better change for now.

[DanielRX]

@hadees No one in this space would willingly tag all devices with a public location. It's a target for hackes and robberies.

[ruowoz]

I don't think it's practical to design a new asic-resistant algorithm until we have a better idea how the current ASICs (if they exist) function.

[krtschmr]

@ruowoz of course, we are fishing in the dark. however, Bitmain and Baikal now understood, that at least Monero/Cryptonight don't want them and threat to hardfork.

I believe, this will be a good warning for them. There will be a tremendous shitstorm of their customers soon (TM).

If Ethereum hardforks only once, which most likely will break ASICs, then Bitmain/Baikal are already warned, again. I doubt in this case they will ever release the F3 to the public, unless they have an S5 with FPGAs. In this case, we will never have the chance to get hands on such a unit for reverse engineering.

So your proposal is to let them mine with their ASICs and unless we hardfork, they can even stock-up?

mmmmh

[kylerchin]

Got another damn article: https://cointelegraph.com/news/ethereum-community-considers-hard-fork-to-fight-asic-miners

@hadees That is a bad idea, just the idea of relying on another technology is scary, as well as geo locating miners. @krtschmr I think if the Ethereum Foundation worked with Bitmain, we could get their asic script and then hard fork the blockchain into an asic resistant one.

Hopefully there isn't another Ethereum Cash because of this.

[jamesray1]

@pipermerriam @AirSquirrels happy to help with the development of an implementation, e.g. seeking analysis and feedback from cryptography and security experts. I would probably have to read a lot more to be able to provide helpful analysis and feedback, and I also have work to do with sharding development, so it would probably be more efficient for me to help by seeking help from experts.

[Arachnid]

@AirSquirrels RE 'opcode hashing', this ultimately comes down to the question "can you emulate another architecture at native speeds"? The answer is no - and typically the slowdown is anywhere from 2x-5x. An ASIC can implement any optimisation a CPU has, plus any of its own that improve performance for that specific application.

[jamesray1]

@Arachnid I get your drift—but doing nothing seems worse than regularly changing the algorithm, IMHO.

[Elijah17]

Why delete comments voting for a hardfork? What is the use of this thread then? I vote for hardfork and then since @Arachnid does not agree it gets deleted? Wow nice one! Thanks!

[jamesray1]

@Elijah17 these EIPs are not meant for voting and repetitive comments, they are meant for technical discussion, which the process of rough consensus is useful for. As suggested:

Should we fork?

I propose that people indicate support/opposition with a simple +1 / -1 on this main issue. I would prefer this conversation not devolve into deep discussions around this subjective topic so my request is that people refrain from commenting on that specific question here.

[CryptoBlockchainTechnologies]

We also need to consider the possibility the ASIC miners, if they exist, might try to keep the old ETH fork going. I believe the way to ensure the new fork is widely adopted by everyone except the ASIC miners is to only make a small change to the existing algorithm as being discussed.

[andre-brongniart]

It's interesting to note how much the ETH mining difficulty has being escalating so much. Yes, could be do to the recent peaks in the market and more miners hoping on board. However, it's peculiar to see this rate and would argue with others that bitmain and others with access to these ASIC are already mining with them. It only makes sense for profits to keep the ETH ASIC secret and mine the hell out of ETH with them before releasing them to the public for sell.

In that sense it would be beneficial to fork and see how the ETH mining difficulty changes.

[AirSquirrels]

@arachnid you’re absolutely right that any program logic can be implemented faster in ASIC than CPU, this is the origin of the idea that it is pointless to fight ASICs, combined with the fact that they can interface to the same memory as a GPU.

You may be right the opcode hashing isn’t the right path, but I believe you are misinterpreting my argument as being for blocking the speed of ASICs. ETHash would continue to be heavily memory bound, and the mixing opcodes would execute at least an order-of magnitude faster than the memory reads. The argument is for complexity/lack of parallelism. The idea is both CPUs and GPUs/ASICs/FPGAs would remain memory bound and complete their calculation and then have to wait for memory.

ASICs and FPGAs are both subject to similar (serial) raw calculation and now memory speed limits. The advantages they gain are from sticking dozens to thousands of pipelines in parallel on the chip, allowing the memory bandwidth to be saturated. By requiring an entire RISC or macro-op core for each pipeline, you drastically reduce the number of pipelines they can have on a chip. This makes it economically impossible to do anything but build an actual GPU or CPU, and sets an upper cap on memory bandwidth that can be utilized.

In short it doesn’t matter that they can process the mix opcode step faster - by making them dedicate mostly idle area to processing it you’re forcing them to have a similar number of parallel threads waiting for memory as a CPU does.

Part of the reason ethash can see such GPU/ASIC advantages right now over CPUs is how trivial it is to do thousands of Initial keccak rounds in parallel, and have tens of thousands of memory requests in-flight at any moment to saturate memory bandwidth. The opcode idea or another idea that doesn’t require simply burning more power but limits the use of SIMD elements reduces the GPU to 64 parallel pipelines (lower power) or so, and similarly limits ASICs.

This was just one idea. I’d love to discuss other ideas for long-term ASIC resistance.

[AirSquirrels]

@kylerchin and others - I do wish someone would update the white paper with a note that mining did NOT get implemented that way. It doesn’t work on transactions, only a hash of the transactions is submitted to miners. There is no way to alter the work a miner does or Poison the Well.

[aurusmx]

it is here

https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7&utm_source=facebook&utm_medium=social&utm_campaign=e3-announcement

[AirSquirrels]

@alonzollamas that’s about exactly what I expected. They’re hedging hashrate a bit lower even.

[crazydart]

@alonzollamas Great find. At 180mh/s with 800watts you would never pay it off. Even if they are being really conservative and it is really 250mh/s like we have seen, it is no where near worth it. I am sure with the threat of the fork and rising difficulty, they need to get a bunch of presales before they lose money.

I say keep the pressure on and let’s get the new algorithm developed. This could all be a ploy to play to those who think this is less of a big deal.

[OmarWazzan]

@crazydart

It's also $800. For people with cheap power (like I do), it'll be more than worth it.

[crazydart]

@OmarWazzan It’s $800 now in crypto for something you can start using until July. By July that crypto may be worth double. On top of that, those specs are almost exactly the same as a rig running 4 Vega 56 gpus. I can tell you that the profits are a little disappointing right now. You would come out far better buying $800 in ethereum. Even with crazy low power of $0.05 per kWh and if the difficulty stays the same as today (it should go up at least 50% really) it would take you 6 months just to pay off the miner... that’s December.

https://www.cryptocompare.com/mining/calculator/eth?HashingPower=180&HashingUnit=MH%2Fs&PowerConsumption=800&CostPerkWh=0.05&MiningPoolFee=1

[yo6ial]

Well, it looks like no more than a better PandaMiner (which is a gpu based rig) but this still does not change the outcome. They are cheap. They will be on by the thousands.

[OmarWazzan]

@crazydart $0.05/kWh isn't crazy low. I pay $0.0048. At even double the price - it is cheaper than a GPU rig.

[atlanticcrypto]

Okay, so it's supplemental supply. If you PV back the mining rewards before delivery, I'm not sure how I feel about it. Being pigeon holed into a single algorithm requires a pretty large discount. I am close to indifferent between a rig built today and this delivered in August.

[OmarWazzan]

@Njcrypto That is true, but you forget the main benefit of ASICs: they're easily managed and expanded. For a small-time miner like me, I wouldn't buy an ASIC, but go for the GPU route. When massive mining operations are already way into profit; why care if they barely ROI; they're free hashrate and diversification.

Look at it from the big players side; not the small fish.

[krtschmr]

This is no suprise. The only suprise is the low spec, but that is also no suprise then.

Let's summarize facts or speculations

• Bitmain develops ASICs
• Bitmain runs them for their own pockets getting the real first runner advantage
• Bitmain develops next gen ASIC and starts releasing the used Hardware
• Bitmain/Baikal were mining Monero/CN in the dark. Only speculations about ASICs came to the surface
• As soon the Hardfork came public (or better say, the algo change was in all news) the ASICs go for sale. For hilarious prices.
• Rumors of Ethereum ASICs getting stronger and stronger, discussions of considering a hardfork pop up and et voila, Bitmain announces the worlds leading Ethereum miner

Now lets keep it real: If we wouldn't have talked about it, if we would have ignored it, this would never been released. Bitmain would still digg plenty of ETH every day. We don't know it, but we all know, they only announced it today as we pressure them and they try to get a shitload of non-smart people into buying these ASICs.

What bothers me most is the low Hashrate of this thing. This simply doesn't make any sense to be an up to date ASIC. I highly doubt, Bitmain would try to make an ETH ASIC for the public, if they can get the same hashrate as a 6 GPU Rig. I run 6x RX470 4GB Samsung RAM for 180 MH/s and less then 800W(!). Of course my initial cost is way higher, but i also have resell value or can do other things with it.

These rumors that they ordered a gigantic amount of RAM, all these speculations of Hashrates and efficiencies... no chance that it will be an 180 MH/s machine. The price is okay. But i suspect them to have at least 50.000 of these on. That would be only 9 TH/s which would be only 3.5% of the current network Hashrate. At least!! Just think about it, there is no sense for Bitmain to release it, if they didn't mine the crap out of it already.

Specs are also weired: 13KG is 5KG more then a regular ASIC (8KG) and the size is crazy. double size of a regular one with double fans.

At the end of my text, there can only be one conclusion: Hardfork, now! Either we change Dagger so that ASICs wil brick, OR we move immediately to PoS (which won't be here yet)

[Buttaa]

@krtschmr I agree , pretty low specs, the miner was "sold out" on their website within 1 hour. I highly doubt that these are the real specs.

[AirSquirrels]

@krtschmr I’m not sure why you are so convinced the perform specs should have been higher. Ethash has and will always be memory constrained and there’s no hidden trick to getting around that that only Bitmain know, thus they are subject to the same component performance and physics rules as everyone else. It isn’t magic.

Their only option for higher performance is moving to GDDR6, which it is no coincidence will be in volume in July. I expect they are shipping these current tech units right about the time they will be able to move from prototype stage to production on next-gen GDDR6 units. But it is also when GPU vendors will be making their same bump.

I also disagree that Bitmain can just pump out unlimited of these. Memory is extremely constrained, I’d be surprised if they can build much more hash power than the GPU vendors can per unit time - most likely less! The math just doesn’t add up to the FUD level.

We still hardfork and call the bluff, but let’s keep the raw paranoia based on no actual numbers and magic under control. It doesn’t help anyone here and only contributes to driving down ETH prices.