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.

[CryptoBlockchainTechnologies]

I think the proper approach is to attack this with a quick short term change and then begin working on a medium term solution.

Lets face it by the meeting this week we probably will not have concrete evidence of ASICs mining ETH or a sure fire tested way to stop them. However, this should not prevent us from making a small quick change to try and disrupt any ASICs already mining or built. The proof of this working would be a significant drop in hash after deployment.

If succesful this would take pressure off the dev team and they can start working on medium term solution and finally long term pending POS rollout and completion.

As far as algorithms, I think a conservative approach should be taken to make a small enough quick change to disrupt any potential ASICs threats. That being said I believe the easiest fit algorithm is Equihash. Most GPU miners can switch between Equihash and Ethhash with minimal memory clocking changes. There are more robust medium term solutions in algorithms but pose more of a risk in disrupting the network if compatibility issues arise.

[ddobreff]

Here's the proof

[cryptomined]

@ddobreff LOL i'm in guangdong (guangdong-pool.ethfans.org)... I should ask local suppliers if they have these yet, or what the numbers are if they know

[ddobreff]

Its not mine, it was sent to my by trusted source.

[crazydart]

@ofpcarnage while I think cryptonite7 sounds good, I have several concerns with that... not that this community would accept it anyhow. First is that you would have 2 major crypto currencies on the same algorithm and it would increase the payoff to developing an asic miner. Second, it would be my hypothesis that part of the unhealthy lifecycle of forking to kill the asic is that the asic developers keep them secret until they pay them off, and are much less harmed by the change, so they still have a good bankroll to develop the next one. Once the fork is announced and set in place, I am sure they quickly get to work developing the next asic. This means development on the cryptonite7 asic start already and by the time ethereum adopted cryptonite7, we might only be weeks away from a new asic. Btw, I would expect any modifications to kill the asic miners would only last a few months. A short term stop the bleeding needs to be put in place, but a mid term frequent change needs to be put in place also to keep this from happening. Clearly every 6 months on Monero isn’t enough.

[cryptomined]

@crazydart https://twitter.com/fluffypony/status/978735054691225600

"We’ve been told by ASIC designers that they can go from design to tape out to delivery in 5 months tops, which is why the Monero process is specifically designed to combat that. Also I think Ethereum miners are just betting the PoS is never going to happen, or be hybrid."

[crazydart]

@cryptomined I don’t think that is right... but maybe. Bitmain has also produced/paid for at least a dozen asics.

https://en.bitcoin.it/wiki/ASIC

[AirSquirrels]

I’m generally against hard forking here as all rumoured ASICs are not even orders of magnitudes better than GPU miners, and thus meet the initial obligations of ASIC resistance. Furthermore I believe the performance gap will be even narrower when the next generation of GPUs is released. Finally I feel strongly that the ETH team needs to focus on the real long term goal, and not cater to the miners here. Miners, of which I am one, are the most vocal and incentivized users to demand a hardfork, but they do not generally have the long term interests of ETH in mind anyway. When you said you wanted rewards to drop 100-1000x on all chains, did you mean the main chain as well? POS and all the other benefits of ETH are the long game - hard forking takes our eyes of the ball and wastes resources.

With all that said, if hard forking is the will of the community might I suggest a novel approach. The task of Trial Factoring as well as LL tests associated with the large mersenne prime finding goals of the GIMPs project are well studied, solutions are highly optimized already for CPU and GPU, and tests accelerating FFTs of that size (for Lucas Lehmer tests). Trial factoring results in a trivial to confirm proof of work that is difficult to fake. At higher bit levels Elliptic curve tests for factoring efforts are memory and Compute hard and have statistical success rates that would lend well to a dynamic difficulty level. Perhaps a group of factors totaling < [target bits]. This would provide actual “useful” theoretical number theory research results from the PoW and use an algorithm that’s has been performance tuned and analyzed for decades.

[jamesray1]

I think that we should at least put more consideration into regularly switching the PoW algorithm, until we switch to full PoS. Obviously the more ASIC resistant and unique the algorithms are (preferably they have not been used in any other blockchain), the better. There's no point switching to an algorithm that ASICs have been manufactured for.

In sustainability there is the precautionary principle. That principle applies here because we have a centralisation risk with ASIC, and acting in a precautionary way by systematically changing the PoW algorithm to minimize that risk prevents much more potential damage to Ethereum, much of which may have already been done if Bitmain had already been using the ASIC miners before publicly selling them. There is some uncertainty as to how long it would take to develop an ASIC for a particular algorithm, and even more uncertainty as to how much damage could be done to Ethereum. Even though damage may have already been done, we should prevent further damage from continuing.

AIUI the Ethereum Foundation has enough funds to pay for the extra resources required to systematically change the algorithm. And in the seemingly unlikely event that funds get tight, more funds could be raised.

[7runks]

@jamesray1, the idea is to use algorithms which were not spoiled by asics. Randomly rotating them in a way the machine itself can't adapt to which algorithm is being used.

[jamesray1]

That would be more ASIC resistant but you could probably still develop an ASIC for that if it is able to be designed for each algorithm and fairly quickly detect which one is being used at a given point in time. So in addition to randomly rotating a fixed number of algorithms in the short term during operation, for more ASIC resistance it would be better to also keep regularly changing the algorithms, say every 6 months.

[7runks]

I'm talking about randomly rotating based on dag change or block found, I myself can see that is the future as right now that would present too much constraints. Need a great mind to implement that and think outside the box.

My point is that only a gpu could keep up, no asics whatsoever would keep up with it, it would be impossible for an asic, only a gpu could do it.

[jamesray1]

Maybe you're right, but maybe an ASIC can be designed for any algorithm.

[crazydart]

@jamesray1 Of course an asic can be developed for any algorithm. The first time I read about ethash I thought, man you could just get a crap load of ram and load small parts of the DAG in it, have a bunch of asics all access the ram to get crazy fast access to the random DAG parts they need, then hash. It actually didn’t seem very asic proof at all... just expensive because of ram.

This is still no excuse for letting it linger. I propose it actually might strengthen ethereum to change more regularly to keep vulnerabilities at bay. The one argument I have heard against it that I agree with is that you could open it up to a new vulnerability. You let anything sit long enough unchanged and something will break it.

[MicahZoltu]

@crazydart In software engineering, change is almost always the cause of things breaking. Things breaking due to sitting around for a long time is actually pretty uncommon relative to things breaking when change is introduced. This is why enterprise companies use operating systems and software that is woefully out of date, because they have learned that change causes things to break, and breaking things costs money.

[hadees]

@ofpcarnage I'm not sure cryptonite7 is the best solution but I do think it makes sense to collaborate with other coins in the same boat. I think we might end up having to tweak the hash forever to kick off ASICs and it would be better to have a common standard on how upgrades for that would go.

[jamesray1]

@hadees not forever, just until full PoS.

[hadees]

@jamesray1 that's assuming PoS works and/or it doesn't have to stay hybrid with PoW forever. Working with other coins like Monero make sense since this is something they'll be able to use after Ethereum's PoS fork. Keeping ASICs off a network is a larger crypto issue and it's a place I think Ethereum can really lead on. Other coins have problems with updating sensitive parts of the software but Ethereum has a set of standards and practices in place that is working and rolling out these type of updates in a timely and orderly manner.

[erikrijn]

I'm all for it. It's either change, or have ethereum become a centralized and industrialized network like bitcoin became as a result of asics.

[jamesray1]

I'm fairly sure that full PoS will work, it's just a matter of implementation.

[archills]

@ddobreff I am impressed that F3's hash rate is more than 1GH/s which mentioned in the news.

I think the big problem is when a single company is controlling the hardware supply and hash power.
Basically, they can do what ever they want.

If bitmain dominates ETH hash power, then I would guess ETH fork is inevitable when moving to POS. ETH Cash would be forked 100%. It is very easy to conclude that any ETH proposal against mining profitability would not be supported by bitmain.

ETH claims asic-resistance in the white paper, i wish dev team could honor the promise. Before bitmain fully control the hash power, at least, there is time to change this.

Someone mentioned do not listen the GPU miner's opinions because of interests of GPU miners. I am a GPU miner, actually I fully support ETH POS. I just don't want asic cartels do same thing again like what happened in bitcoin. People even cannot agree a single scale solution, then they forked bcash, then they even want to overrule bitcoin.

Considering the profits of asic cartel, they have enormous fund to do what ever they want.

Jihan is manipulating the hash power of bitcoin. in the interview, he clearly he mentioned if they want to increase hash power of antpool, they have to sell certain amount of bitcoin miners. of course, to avoid the 51% hash power in a singe pool.

what bitmain is doing is not ethic - manufacturing hardware and build antpool to compete with own customers. and considering such a company, i would be very frustrated that this evil company to control second largest coin.

[archills]

@jamesray1 I fully support POS and i have huge belief that ETH dev team would implement best POS. Considering the pow/pos hybrid in casper, I estimate it would still require at least 1-2 years to fully switch to POS. It would still be better to switch the algo to avoid the asic-cartel to fully control the hash power.

[yo6ial]

If Bitmain actually has these asics they surely mine with them and if they do, thst is a form of attack on the network. It is obvious that if they do, they don't boot them in the thousants but gradually.
The very constant increase in hashrate, despite the gpu and vram scarcety, makes me suspect this is true.

I agree that if the ethereum comunity does not like the idea of one sketchy company being the sole provider for a particular algo asic, with poor trusting in their lack of backdoors in their software, a hard fork is the only way to show the comunity's point of view.

[ddobreff]

Silence is usually not a good sign. I suspect that transition to PoS will be forced earlier due to being in the “cat and mouse” game leads to nothing good.

[ofpcarnage]

POS is still a while away despite popular beliefs. If they where to rush POS this could be really really bad. I hope they are looking at options to fork for now.

On Sun, Apr 1, 2018 at 12:40 PM, Dobromir Dobrev notifications@github.com wrote:

Silence is usually not a good sign. I suspect that transition to PoS will be forced earlier due to being in the “cat and mouse” game leads to nothing good.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/958#issuecomment-377780904, or mute the thread https://github.com/notifications/unsubscribe-auth/AWHySta2z1rEPnFY5n6Q1q-04PBWZ-I5ks5tkLy0gaJpZM4TAuxE .

[Eliovp]

Halong is coming out with one as well.

Is someone going to change this... ? https://github.com/ethereum/wiki/wiki/White-Paper#mining-centralization

I'm having a bitcoin deja vu here..

[crypto4techs]

I echo the sentiments of others in that a specific strategy or algorithm direction can't be decided until details regarding the ASICs are known. I do believe Ethereum devs (and all other alt-coin devs) should be as vocal as Monero devs regarding taking a hard stance against ASICs. If ASIC manufacturers know all coin devs are going to take swift action to styme ASICs they may abandon future ASIC R & D in crypto.

I would also suggest that strategies need to be developed to take action when coin devs suspect manufacturers are using prototype ASICs which have not even been announced yet to secretly mine on a coin's network. That income stream needs to disappear for ASIC manufacturers as well.

[locusyam]

If ASIC takes over the network, we are moving towards centralisation which defeats the purpose as an alternative to traditional currencies. Until POS is going live, suggest a hard fork to keep it ASIC resistant.

[AirSquirrels]

@7runks ETH is a massive market and first class cryptocurrency. They can’t make major decisions on the drop of a dime, nor should they. Any change or even signal one way or the other will drastically affect the market. It has to be incredibly carefully audited and reviewed before any algorithm decisions could be made . They will likely discuss it in the meeting on the 6th and only then will you have an answer.

[crazydart]

@7runks I don’t think the price has anything to do with the asics. Also, I am not sure any more comments on this issue will help, they have some “call” this next week to discuss the issue. I think we will learn the results from that. I am sure the developers need a little time to research this as it seems like they got caught off guard/may not care about this issue. We will see.

[krtschmr]

@AirSquirrels they should make a metting on 7th to see how monero got relief.

[AirSquirrels]

@krtschmr I would also be in strong favor of the ETH team waiting a week to watch the XMR hardfork. There are many lessons to be learned, including adoption of the fork, “proof” of contribution of deactivated ASICs, and other observances that can help ETH move forward in the best possible way. I wonder if any of the major XMR pools would be willing to publish some anonymized stats after the fork that would help inform everyone about the concentration of hashpower that went offline and didn’t come back within a few days.

[hadees]

@jamesray1 I don't disagree, PoS is still the end goal. But if we ever want Ethereum to become mainstream we need a belt and suspenders approach. Plan for the worst and hope for the best. Keeping PoW viable in the most decentralized way possible is still a useful goal just as a hedge on PoS.

Has anyone considered possibly not even going after ASICs but instead adding something that lowers difficulty on something that is going to be harder for larger mines to obtain? One approach is to discount difficulty based on say green energy or geolocation. There are problems with both of those but I've done some research into each and I think I've got a way both of them could work.

With green energy we require a certain number of Renewable Energy Certs. After using a REC it would be effectively burned and not usable in another block. The trick for this is making sure you can't just sell them after.

For geolocation we could use sim cards and grab the location information from the tower which should be pretty hard to fake. That still has the problem of a proxy but I bet there is something you could do with latency that would make that hard.

[QuintLeo]

Proof of Stake will kill mining period, not just ASIC mining. Also, unless the claims about the performance of the Bitcoin ASIC miner end up including power usage at well under 1 KW (which would be rare for a Bitmain ASIC miner in recent years, most have been in the 1.3 KW and up range, and NONE of the rumors have included any "power usage" indication) means it will take a LOT of those miners to have a noticeable impact on Ethereum mining profitability. They likely have a few, perhaps even a few hundred, mining right now as "engineering test units" but it's not likely they have been mining on them for many months in any significant quantity.

The X16R approach is NOT "ASIC resistant" any more than any of the other X-series protocals like X11/X13/X15 proved to be - note that Baikal had a multi-algorithm ASCI miner running X11/X13/X15 and several of the "component" X15 algorithms well over a YEAR ago. The only change X16R would need would be a programable input/output matrix to the part of the ASIC for each "component" algorithm, and a small amount of logic to control that matrix.

By the time a Bitmain ASIC, at their usual pace and size of batches, managed to achieve 50% of all Ethash network hashrate (for both ETH itself and the spinoff coins like ETC) Ethereum itself SHOULD be into at least the "hybrid" stage of POS - and in that case the odds are good that anyone that bought one of these ASIC units would never pay it off.

On the other hand, if the POS work keeps missing it's deadlines, it MIGHT be worthwhile to fork once for an algorithm change if anti-ASIC is a major Ethereum goal.

[crazydart]

@hadees I don’t think I am alone in saying that you will never get me to put a physical tracking device on my miners. Also, location can be spoofed very easily... potentially giving more savvy and well funded miners a huge advantage.

[goobur]

I think this is a matter that needs to be taken very seriously and we have to rationally come to a solution, but so far most discussion seems to be fairly split between "PoS will make this not matter" and "We should change the algorithm to X".

First of all, miners are important -- at least for the current state of Ethereum. Even with the planned switch to PoS, it's prudent to remember that miners are the backbone of the network as it stands right now. If the network is compromised now, it ultimately becomes a threat when PoS is introduced. Moreover we should adhere to the promise of being ASIC resistant as stated in the whitepaper -- if an ASIC is mining on the network, then it should be necessarily seen an attack on the network.

To clarify -- PoS will absolutely make this a non issue in the future, but we cannot rely on it right now. We don't know when it's going to be completely implemented, and if it's going to be successful when it is finally implemented. Thus, we should focus on a modification to the PoW.

So where is ethash weak? Really, the question to ask is how they solved the bandwidth problem. All other parts of ethash are relatively easy and cheap to implement in hardware (keccak, and the other parts needed for the mix hash can take up very little die space). I see two possible ways they got around this.

1. They duplicated the dag across multiple memory chips, effectively creating a redundant array of chips with incredible bandwidth. I feel like this is an extremely expensive solution
2. They don't do memory accesses at all for the dag, and use a trick to calculate dag nodes on the fly (I may be off on this one, but it looks like you can do this with a small structured lookup, and multiple iterations of keccak -- which you could translate to multiple instances of keccak on die) if anyone can get pictures of an Antminer F3 PCB, we could confirm whether or not this is true by looking for a large collection of RAM ICs

To me, the most appealing solution is to "test the waters" right now. We can currently take minimal precautionary measures. I propose that we change ETHASH_CACHE_ROUNDS from 3 to something (much) higher, 16 or 32. This affects light cache generation time, however that can easily be mitigated by other solutions (precomputing in parallel a few blocks before epoch switch, for example, if it's even necessary). This appeases all old miners (basically, nothing needs to change in the mining code, only the cache generation code) and in the best case scenario defeats the approach for point 2 above. In the average case scenario, it at least messes with the current production of ASICs and boots them off the network. In the worst case scenario current ASIC miners can be adapted to this change, but we lose almost nothing by making it.

I also propose that we change ETHASH_ACCESSES from 64 to something higher, say 72. This won't defeat point 1. But will likely temporarily kick ASIC miners off the network. This has the disadvantage of increasing verification time (miners will also mine at a lower speed, but that speed will be uniformly lower among miners so their income shouldn't change). What would likely defeat point 1 for the short to mid term, would be to artificially increase the dagsize over 4gb -- if they parallelize dag access, it's likely that they only pack enough ram on one of those boards to parallelize memory accesses for dag sizes under 4gb. This, however, has the negative effect of kicking legitimate miners off the network.

These are some simple changes that involve very little effort and have the opportunity to kick asic miners off the network in the short term -- however it's stopgap solution until we know exactly how Bitmain beat Ethash. When we know that, we can redesign a PoW algorithm around their solution.

[AirSquirrels]

@goobur I have done some fairly extensive analysis of the ETHash algorithm, including probing it several ways for solutions to the “bandwidth problem” in hardware or optimized solution. I have suggest in the past that a light-cache attack is possible, however I place the likely hood of this being the path Bitmain took as extremely unlikely.

Currently it requires a good bit of Keccak (trivial) and about 257 times the memory bandwidth of the DAG based calculation to accomplish a light-cache attack. It also involves 514 64 byte passes through the light cache for each of the 64 accesses, vs 128 byte accesses through the DAG.

The rumors have pegged three different sets of numbers as the F3’s possible implementation. The latest video leak I have determined for several reasons is almost certainly fake, and even a person connected to Bitmain said it was faked with an S-9. With that said, the rumors have been:

• 1500 MH @ 1400W or less (three blades of 43 ASICs each) - the likely faked video (label, form factor, physics).
• 600 MH @ 1200 W - variants of the 250/280 rumor. Always accompanied by pictures of the much larger box than Bitmain’s normal miner form factor.
• 250-280 MH @ 750 W - rumored to be 6 boards (or chips?) with 72 DDR3 chips each, also generally accompanied by the larger box pictures. All blurry.

For these three scenerios, the light-cache attack would require 40MByte (320MiB) or more on-chip or off-chip light cache SRAM. It requires 8192 bytes of DAG access for one full ETHash, thus the total DAG access bandwidths for these rumors range from 13 TBytes/s down to 2 TBytes/s. That places the light access method at 3.3 PBytes/s or 526 TB/s.

Taking largest count of ASICs (the video rumor), 43 ASICs x 3 blades =26 TB/s of SRAM bandwidth, that is not possible with off-chip ICs, and 129 extremely expensive ASIC chips with 320 MiB SRAM if on-chip. Even then the only compatible device I know of with on-chip SRAM that big is > $5000/chip Xilinx Ultrascale FPGAs, whose Dual-ported ultraram tops out at 10 TBytes/second @ 500 Mhz (video core clock). Even the 250 MH variant would need 21 such extremely expensive chips. Thus I think Light-cache attack at these numbers, and competitive with GPUs isn’t practice even with state of the art.

The more likely options are external ram with some variety of DDR or GDDR. HBM would also be an option that would neatly solve the bandwidth problem per ASIC. You would only need low-end stacks per ASIC in the 129 chip configuration, and power would be great, but the interposer costs would almost certainly be outside the realm of the cost parameters for that quantity of chips. The 1500 MH rumor I hold is fake would require a easy 11.6 MH/chip, aka 95 GB/second. No sweat for HBM but still $100s/chip by the time you package it and put it on the board.

Outside of HBM, the 1500 MH unit is neigh impossible with DDR3. This would require x16 components operating at up to 2Gbps/pin, with a total of 3,300+ chips. Cost and power alone would be impossible to achieve.

For ~220 MH DDR3 remains an option. 6 boards with 72 chips each, 2Gbps pin x16 components would closely match those numbers. The rumours was 1GB or 1Gb chips, so between 4-32 memory chips per controlling ASIC. That’s a lot of chips on a board but would match the pictures, which looked to have 5 rows of 8 or so chips on each side of the large boards. (80 chips, so 72 DRAM and 8-9 ASICs with 8 chips each?) that would be a typical 2-channel 64 bit interface @32 GB/s per asic / 3-4 MH per asic and 54 ASICs for the whole unit. That gives 128 bits with up to 8n burst for ideal access patterns. This could be built relatively cheaply with cheap ASICs, cheap memory, and just big boards. Power checks out as well, especially with read only memory access. It is important to not that this is essentially 54 fairly poor performing but very power efficient GPUs in one case. It would be also possible to build a custom PCIe backplane and drivers to accomplish 54 similar output with old or MxM GPU boards running low core clocks on old chips that competes similarly.

This design is pretty hard to fight, and the ASIC isn’t doing much. It could also have 54 cheap FPGAs with the same memory channels and accomplish the same bandwidth flexibly.

You could also double or triple the performance to meet the 600MH rumors with 4-6 64 bitmemory channels per ASIC, but that’s a lot more board area with ASICs that require a lot of IO pins and die size, and would it be nearly impossible to meet cost constraints . You need over 1000 pins minimum for a 6 channel DDR3/600MH option.

The higher hashrate rumors in the smaller case could not be achieved with GDDR5 in the board area of standard Bitmain cases as shown in the video. Even with 9 Gbps x32 chips you would need 114 GDDR5 chips per board, or 22,000mm^2 of board area not including space for power and the ASICs and trace routing. Cost would also be prohibitive, at least $2500 for the memory chips alone to get on the board.

The only feasible implementation of 1500 MH unit is with GDDR6 chips. 129 ASICs on three boards with one 64bit (2x32 components), 16n prefetch 12 Gbps GDDR6 interface. A total of 258 memory chips and 129 ASICs. Power would be within the 1400W envelope. Cost for the ASICs (memory controllers) and boards to run 12 Gbps chips wouldn’t be cheap, and they couldn’t go mass production till next gen GPUs do (maybe late Q2 when GDDR6 is in volume). There are no FPGAs I am aware of that could inteface with the POD135 GDDR6 chips, but I’m sure Xilinx could make them if you had enough volume. That said, costs and component supply lines are similar to GPU vendors and it would almost certainly have to be ASICs as the logic,, though the ASICs would afford some power savings as compared to similarly powered GPU miners. All said I don’t personally think these would have any significant advantage vs next generation GPUs, at most 2x operating cost efficiency at a compatible or even higher upfront cost. The decision to hardfork is up to the community, I’m just here providing numbers.

Your comment on spreading the DAG amongst a lot of chips for maximum bandwidth isn’t anything special. Stripping the pages across all DRAM chips is normal for all PC and GPU memory chips as well.

[crypto4techs]

To everyone saying "PoS will solve this problem", this entire issue is bigger than Ethereum by itself. There are multiple coin hashing algorithms under attack from ASICs. All these coins and algorithms were originally designed to be ASIC resistant. A decentralized network was the original vision for all these coins and algorithms and they all knew from the beginning that ASICs were a threat to that and took their own unique measures to try and make their hashing algorithms ASIC resistant. One by one they have been falling, against the original intent and vision of the coin devs. All dev teams for all coins need to put up a united front against ASICs and collaborate with each other to protect all of their original visions. This boils down to all the coin dev teams and miners combined against the ASIC manufacturers. Let's stop thinking individually and start thinking as a larger group / community.

[atlanticcrypto]

@airsquirrels - great post - best analysis I've seen of the hardware science thus far. We aren't convinced this is going to be a step change in technology, as it seems you agree.

Full disclosure, I operate a set of large GPU mining facilities. We are extremely opposed to Bitmain's ASIC rush into historically resistant algorithms. We have a different set of reasons that I haven't seen discussed yet.

First thing first, our facilities represent approximately .25pct of the global ethash resource base. I know what our instantaneous power loads are, and on a scale basis, it's peanuts. In a former life I ran a power and gas trading desk, and the global power load for the eth network doesn't even move the needle on real time grid errors in a single regional grid in the US. This idea that the eth network consumes an insane amount of power is absurd. There is no scale reference. Single plants can produce more power than the entire mining community uses. Having a single energy asset powering an entire coin economy seems reasonable.

Now, onto the real reason for this post.

The decentralization of these systems has done something marvelous. Something not talked about anywhere near enough. It's incentivized the construction of a massive decentralized processing resource base. Granted, it's not being optimally used as the only real economic uses so far are to run coin algos, but that's not the miners fault. We responded to a price signal, exactly how markets are supposed to work. So the question is, do you not want these computing resources to exist in a decentralized manner? Do you want AWS and MSFT to hold the reins on this next series of compute technology? Being that we're in an AI revolution, these computing resources are going to be incredibly valuable. Don't force them out before the development community figures out how to use them.

Now, ASICs are NOT flexible devices like GPU facilities. A Bitmain ethash ASIC won't be able to port to something like Golem. A Bitmain ethash ASIC won't be able to do deep learning computation. They are purely built to respond to the ethash price signal. I do not believe that's what this development team envisioned.

The mining infrastructure of eth is an incredibly flexible resource base, one that's been built in parallel to a lot of HUGE GPU based commercial facilities for the likes of AWS. In all honesty, we are going to respond to whatever price signals the market provides us. If that means we are better paid doing protein sequencing, so be it.

The issue here and the problem that we have with this new "threat", is that these machines will be completely devoid of value should the eth network disappear, and their existence, whether they are a game changer efficiency wise (1500mh) or are just an incremental source of hardware supply (220mh), they don't provide any resource base value to the global development community.

[trustfarm-dev]

@pipermerriam Your proposal doesn't prevent ASIC. most of algorithm is ASIC Friendly . so, multiple algorithm in ASIC then, It is not helpful prevent asic.

@AirSquirrels good analysis of FPGA and ASIC. But, I guess Antminer F3 is not a rumors, It may be realized now. I've heard rumors from 3Month ago,

Basically, I don't like ASIC comprehensive mining, because there's 1~2 sole vendors provide Asic miners. If there's several many vendors and types of miner product. it may be distributed and decentralized mining in view of device using. Recent days, I also changing the thinking, GPU only mining. becasue all GPU has dramaticcally increased prices and miner's have spent their earns for GPU and electricity fees.

@Arachnid , If ethash makes the ASIC resistance and prevent future ASIC attacks, I think 1st things is changing keccak to other algorithms, and change MIX algorithm to modify diffrently. And then, modified ethash will resistants asic mining for some times. and Next things apply and check rum-time update of newer hash algorithm. http://doi.org/10.8080/1020160054419 , Basic idea is dynamic updates. please check it. changing block format and add meta selector fields for new hash algorithms for prevent centralized hash. If it looks good , I have mind on contributions for fair use and blockchain innovations.

[goobur]

@AirSquirrels Thanks for the in depth crunching of the numbers -- looking at the light cache code in more detail I agree that any attack on light cache needs an infeasible amount of SRAM.

For ~220 MH DDR3 remains an option. 6 boards with 72 chips each, 2Gbps pin x16 components would closely match those numbers. The rumours was 1GB or 1Gb chips, so between 4-32 memory chips per controlling ASIC. That’s a lot of chips on a board but would match the pictures, which looked to have 5 rows of 8 or so chips on each side of the large boards. (80 chips, so 72 DRAM and 8-9 ASICs with 8 chips each?) that would be a typical 2-channel 64 bit interface @32 GB/s per asic / 3-4 MH per asic and 54 ASICs for the whole unit. That gives 128 bits with up to 8n burst for ideal access patterns. This could be built relatively cheaply with cheap ASICs, cheap memory, and just big boards. Power checks out as well, especially with read only memory access. It is important to not that this is essentially 54 fairly poor performing but very power efficient GPUs in one case. It would be also possible to build a custom PCIe backplane and drivers to accomplish 54 similar output with old or MxM GPU boards running low core clocks on old chips that competes similarly.

This seems reasonable. If this is indeed true, it's somewhat troubling. If the chips they use are old GPUs with low core speed, then we're in a tough position, theoretically they could be changed to whatever algorithm Bitmain wishes -- effectively "beating" memory hardness as an ASIC-resistance measure. However, this means we could replace keccak with a more compute intensive hash function in an effort to cripple their miners -- if we tune the algorithm so that compute becomes the bottleneck on older cards. On the other hand, if they're using 54 cheap FPGAs to accomplish this (or a custom ASIC) then by changing the algorithm to something that won't fit on a cheap FPGA, you effectively brick their miners. This now seems like the minimal "Occam's razor" change to make.

[krtschmr]

Let me qoute from Bitmain.com Website at the X3 Product page

"3. One major cryptocurrency which is using CryptoNight hash function is about to change their PoW algothrim, and according to their public statement, it is purposely to brick ASIC mining rigs including X3. When you buying it, you are betting that they are wrong."

Source: https://shop.bitmain.com/product/detail?pid=000201803132107063379CD35Gxy064F

Ethereum should immediately fork...

[krtschmr]

@crazydart i did indeed send a quick photo to my friends on whatsapp and just uploaded it for you

there is a screenshot in a reddit-thread

link to scree: https://imgur.com/a/pRb7F

[krtschmr]

the thing with no shipping to hongkong is also gone...

we all made it up? :-)

[hamdyaea]

By modifying the protocols every 6 months they will have to modify the asics

[AirSquirrels]

@hamdyaea and others - modifiying the algorithm regularly isn’t likely to help. I suspect after 1-2 rounds of this we’re going to see ASICs transition to programmable logic, which is advancing quickly to become nearly competitive with ASICs in speed and power. If enough scale were gained we could add cost to that list.

@goobur I would be surprised if they used programmable logic this round, but I bet they would the next round - and that could be weeks from the announcement of any hard fork. Computational intensity may help, however you’re also unlikely to be at programmable logic with computations that are reasonable on GPUs. Raw Keccak is computationally intense, and I can outperform it for cost versus a GPU. If you really want to kill ASIC and programmable logic, you need to take advantage of random dynamic execution.

I made an interesting thought when reviewing CryptoNight7. I proposed an algorithm based on CryptoNight7:

1. A few Keccak rounds to expand state to 1600 bytes. (Existing)

2. Use AES to fill a scratch pad (2MB is fine)

3. Define each word as opcode + data from a minimum set of bytecodes. Include addition, multiplication, xor, aes round, Keccak round, branch back % position in scratch pad with flag (so you only branch once), etc. you could also include a DAG and DAG read ops to introduce memory hardness.

4. Execute the random bytecode serially through the scratchpad in an RPN like stack, replacing each opcode/data item with the intermediary result of that calculation step.

5. Use iterative AES to again collapse the state to 1600 bytes. (Existing)

6. Keccak + existing randomly chosen finalizer hash algorithms.

I believe this would be incredibly difficult to gain an ASIC /FPGA advantage with. You would need 254 (1 nop) opcode processing paths + pipelines for 56 bit words, and you would need dynamic branch support per hash. The execution is serial, so at that point you’re limited to a count of cycles, and clock rates are at a disadvantage on FPGAs and CPUs tend to be more competitive than ASICs. GPUs would also be hurt by this change, because there would be no concept of threadgroups doing the same operations, however they could still be used as 64 or so core CPUs fairly power efficiently,

I’ve yet to see any other proposed hash algorithm that couldn’t get at least some small gain in programmable logic. My previous thinking had been the community was content with ASICs and FPGAs only being able to match performance, but the general sentiment here has been that they are unwanted even as supplemental hardware.

[pipermerriam]

This thread has grown quite a bit and I'm glad to see some real discussion on options we have to try and implement some level of ASIC resistance.

@goobur and @AirSquirrels you two seem to have a solid handle on this topic. I'm wondering if either of you would mind posting a summary of what you think the best path forward would be. Do you see a route that allows us to make minimal changes to the mining algorithm (ethash) but which is likely to break current asics?

[AirSquirrels]

Let me do some analysis and I will suggest a few levels of minimal changes. I think the tiers are:

1. Only break existing ASIC chips. The simplest option here is a change of FNV constant. Synthesis would have likely optimized that multiplication and there are other suitable primes.
2. Break existing batches of ASIC and possible FPGA. This will require some more structural changes to increase chip area by a factor of at least 2. Replacing the current initial Keccak with a second hash algorithm, or replacing the final Keccak with a pool of 256 bit hash functions similar to cryptonight would likely require enough of a chip area increase to require at least an FPGA upgrade (if ball compatible), or cut performance by a factor of more than 4 by taking up pipeline space.

In both cases all new hardware designs could easily work around these changes, but you likely have a few months.

3. The last option is to make changes that would provide substantial long term asic resistance. Replacing the FNV mix in step inside the inner DAGGER loop with a byte-code execution step as described above utilizing the new dag item + existing mix would likely accomplish this but I welcome other commentary.

If there is interest I can create a proof of concept implementation.

[Isanderthul]

Changing things before the problem is understood would be wasteful and could introduce problems. In addition this could be chasing fake news. ASIC mining in itself is not the issue. The issue would be a future concern of long term market and system manipulation. As the Ethereum Alliance gains more members, this seems like a topic that should fall squarely on their shoulders as part of an Alliance strategy. The issue is a long term problem, and should be dealt with by means of considered member input.

[7runks]

@Isanderthul, I agree with you to an extent but do you think is okay to leave bitmain with thousands of eth asic miners secret mining. So if bitmain does not sell its miners then we don't know and bitmain can continue mining privately with almost 50% the hashrate?