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.

[pipermerriam]

As a starting point: This came up from some very brief research into current ASIC resistant mining approaches. This is not my area of expertise so I'm somewhat relying on the community to help fill in the blanks here.

X16R-Whitepaper.pdf

[MicahZoltu]

Is there any reason to believe this problem won't just all go away once full PoS lands? Or in the fear around that still being a ways out and centralization could occur in the meantime?

[Arachnid]

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.

For instance, they could be a parallel keccak256 chip with a large and fast array of DRAM attached; in that event it might be easy for them to reconfigure the microcode, and adapt to new variations that rely primarly on keccak256 and fast memory access.

[Arachnid]

Incidentally, I think X11/X15/X17 etc are terrible ideas - none of the individual algorithms are intrinsically ASIC-resistant, they're just trying to use up lots of silicon area. Since they're chained, an ASIC manfacturer could just produce multiple ASICs that are chained together, if they actually ran out of space on one die (which is unlikely).

In fact, I wouldn't be surprised if the slowdown from using multiple algorithms on CPUs and GPUs - from not being able to do consistent register allocation for the algorithm, for instance - is greater than the impact on an ASIC.

[cslarson]

93% upvote rate on that Reddit post. I'm happy to vote here too but I'm not sure what additional protection it offers against manipulation.

[AtLeastSignificant]

@cslarson I'm undecided on whether a fork will be beneficial or not at this moment, but wouldn't manipulation likely come from ASIC miners who oppose a fork? That reddit post, this EIP, Vlad's tweet, etc. all seem to point mostly in the direction of support for maintaining ASIC resistance.

This stance has been taken by Ethereum since inception, I dare say it's part of the undefined "Ethereum Philosophy" we talk about so much these days. If a hard fork is needed to preserve this, then I support it.

[CryptoBlockchainTechnologies]

Thank you for adding this to the agenda next week. I would also like to see a discussion on methods that could be used to detect ASIC mining. This does not have to be on the blockchain but a way to be able to detect them if possible. I have a lot of faith in this team in figuring out how ASICs can be detected.

[S1nus]

PoS

[Buttaa]

i think this is the most recent news about it:

[pipermerriam]

@Arachnid
We can't make it ASIC proof, but we should be capable of at least rendering anything currently in production either obsolete, or at least requiring more R&D.

Assuming there's was an alternate ASIC resistant algorithm we were happy with, do you think that the act of forking will adequately demonstrate our willingness to fork the protocol, which should deter bitmain and other manufacturers from sinking costs into producing ASIC miners for Ethereum.

[AtLeastSignificant]

I would say the Monero approach has been successful based on the press coverage / sentiment I observe, so yes - forking would demonstrate our willingness to prevent ASIC domination (same attitude as the "poison the well" statement in the whitepaper).

Even if it proves to only be a minor setback (forces 2-4 months more R&D), the process itself is valuable to other blockchains. It may be wise to just have scheduled changes to the algo and not be so reactionary.

[DanielRX]

I think merely showing that we will not support ASICs will make these producers think twice about trying to build an ASIC for ETH, they may then move all the ASICs over to ETC (not sure if that's relevant).

@pipermerriam We only need to show that the protocol and community stand to the opinion of ASICs being a no-go, even if this fixes things for less than a month, it 1) reduces the problem for that month and 2) may open users upto the idea of hardforks being a good thing when used for this case.

Off topic: As discussed in the reddit link, this may allow for a "mini-HF" that means we can add some of the EIPs ready to be forked in along with this

[DanielRX]

@Arachnid who could / will find some form of stats on GPU usages? It seems like we could see at which total difficulty point many GPUs would leave, and then have better stats on how quickly x H/s will make GPUs drop out, and then how big an effect ASICs could have.