ECIP1043 Fixed DAG

[realcodywburns]

ECIP 1043: 
    Title: Fixed DAG limit restriction 
    Author: Cody Burns <[email protected]>
    Status: Draft
    Type: Standard
    Created: 2018-04-16

ECIP-1043 – Fixed DAG limit restriction

Abstract

The purpose of this ECIP is to set a limit on the maximum size of the DAG to its initial state and no longer increase it on an epoch schedule

Motivation

The original intent of the DAG was to provide ASIC resistance to the mining protocol in order to prevent centralization of mining distributions and thereby provide for an objectively fair distribution of tokens. As evident by ASICs being developed that are capable of matching current GPU miners while being more energy efficient, the DAG has failed at its task and now only serves as a deterrent to broader investment in application specific hardware by competent distributors. Because of this, the increasing DAG has began to have negative impact on long term security and acts as an anti-competitive bug preventing large scale investment in mining development .

As originally discussed in ECIP-? Limit DAG growth #6; a constantly increasing DAG will eventually reach a hard limit of bus speed on GPU memory and forcing GPU’s into obsolesce does not provide an increase in security. To the contrary, smaller DAG sizes allow more GPU’s the ability to mine while providing a lowered initial entry cost to hobbyist miners.

A 5 year vision of the mining landscape would see a transition from general purpose GPU mining to a broader market of application specific hardware being built by current and supported by a diverse group of manufactures similar to the current GPU market.

Specification

if(blkNumber > forkblock) DAG epoch = 0

Risks consideration

This ECIP is not forward compatible and introduces backwards incompatibilities in the DAG file generation, block verification, and block mining. Therefore, it should be included in a scheduled hardfork at a certain block number.

This is a long term PRO applicaton specific hardware proposal. If sufficient interest is not generated by manufactures in the mining field, there is risk of domination by one or more manufactures. (market risk)

Implementation

The following clients implemented ECIP

• Geth-ETC
• Parity
• Mantis
• multi-geth

Copyright

Copyright and related rights waived via CC0.

[pyskell]

Initial comments/thoughts:

1. Should only fork after we see some ASICs, before then it's hard to determine what impact this will have.
   a. Fortunately their release date of June/July is already quite close and will likely naturally happen before this ECIP is adopted and code is written (if it is).
2. There should be some testing on current market low RAM cards to determine their effectiveness.
   a. Can we find availability numbers on low-RAM (<2GB cards) and compare them to current card availability? The idea here being we don't want too few available low-RAM cards because then this proposal doesn't do much; at least not at the outset.
3. Can we reach out to other potential ASIC and GPU manufacturers and get their input?
   a. Sia did this to good effect and had multiple miners released around the same time.
4. If we go ahead we'll likely want a decent delay between announcement and hard fork to even out the competition (prevent one or a few people from buying up tons of cheap cards)
5. Is there any advantage to going to <1GB DAG to make low-RAM cards more competitive?

[chipbit]

Is there a discussion regarding this ECIP 1043? I would like to participate ..or is this it?

[pyskell]

@chipbit This is the discussion so far. Feel free to comment.

[chipbit]

This is an interesting strategy vs. changing the algorithm, so I will go with it:

1. Would power usage on "low price/low memory" video cards be comparable to an ASIC w/equivalent hashrate ? We know that 800 watts is all it takes to make ~200Mh/s for probably under $500 (based on E3 specs/pricing)
2. Seems like less memory would be make an ASIC even cheaper to make, and possibly more efficient then a bunch of old video cards..
3. Has anyone done any testing on old Nvidia Quadro's or AMD 68xx cards to see what hashrate they would get? (with smaller DAG). The point is, how many "old " cards will it take to get the MH/s a 1070 could get? I am thinking these older cards can only hit 5Mh/s, unless there is more to this plan..
4. I am worried the $ cost of total # of cards and watts would equal that of newer cards, defeating the purpose.

• I can do testing if needed

[lowskidev]

From my understanding:

It's not the amount of ram that determines the speed of the hashing power but the memory speeds;

So DDR3 will hash slower then DDR4 and so on and so fourth. I can almost actually prove this with my RX470 8gb vs my RX570 4gb, hashing power on both is maybe 2 MH's difference at most.

I believe I read somewhere that the bitmain ASIC actually just uses wafers of DDR3 memory since, it's probably the cheapest and most available atm.

I also believe that resetting the dag allows everyday DYIer on a budget, to tinker with differ ideas and maybe even give incentive for the community to come up with DIY ASIC type rigs that anyone can build at home with readily available hardware. Since R&D costs will go down significantly and you don't have to worry that the idea you just spend 6 months prototyping will be obsolete at a certain EPOCH.

The above is also very true to even bigger companies like AMD, nVidia, whom at one point showed a lot of interest in releasing their own line of GPU mining only hardware.

[chipbit]

I agree that memory speed is an important factor in mining, but shrinking the DAG size also allows for less memory to be needed for mining (1GB vs. 4GB) , making overall ASIC etherhash machine cost even cheaper. I wasn't saying the amount of RAM determines hashpower. Older cards will hash slower because 1) they have less bandwidth, 2) slower gpu's 3) slower memory - and you will need more of them , that uses even more wattage.

Tinkering is great, but just because I can use a bunch of old video cards doesn't mean I can compete with ASICs manufactured on a large scale that cost 2x to 6x less than a machine a home user or a farmer can build for mining.

NVIDIA and AMD making special mining cards should not be a concern. They are just re-branded video cards, and they don't run their own mining farms, like Bitmain does. We saw how much hash rate they are capable of controlling, with Monero, it was at least 50%.

[pyskell]

Links to additional discussion (since not everyone is commenting on GitHub):
Reddit: https://www.reddit.com/r/EthereumClassic/comments/8cz80m/ecip1043_reddit_discussion/
Discord #mining chat (April 17th): https://pastebin.com/cQj2Fq3k
Forums: https://forum.ethereumclassic.org/t/limit-dag-growth-discussion/2075 (none as of posting)

[pyskell]

Also it's rather clear that there's a lot to do in order to assess the viability of this proposal which has the potential to do the following:

1. Create a market for current generation GPUs with lower RAM specs (ie. cheaper). These cards certainly exist.
2. Make ASIC manufacture cheaper/more accessible to other ASIC manufacturers
3. Potentially make GPU mining with older cards viable again

As a side note/somewhat off-topic point I really like point 1 because it would perhaps create a split in the market where high-RAM cards are for gamers and low-RAM cards are for miners. I imagine PC gamers would be happy about this. Currently it's high-RAM cards are for miners, and low-RAM cards are for gamers without a $600+ budget for a single card.

Anyway, the TODO (before moving forward) would be:

• Test low-RAM cards, need volunteers and some cards.
• Reach out to GPU manufacturers to get their thoughts.
• Reach out to ASIC manufacturers that don't currently make Dagger-Hashimoto ASICs

I'll look into seeing what I can handle from this list.

Volunteers:
@chipbit - Has some old graphics cards

[drd34d]

thanks @pyskell for relaying the discussion from other channels.
This proposal motivations are good but just like @chipbit pointed out, old gpu's would be very inneficient at mining due to bandwith, clock speeds and energy consumption. I believe older gpu's will not stand a chance to be profitable so no one will be benefiting from this except those doing R&D of ASICs. Maybe gpu makers will see an opportunity here? but that's more wild guessing.

for reference:
https://www.cryptocompare.com/mining/nvidia/nvidia-geforce-gtx-750-ti-ethereum-mining/

[pyskell]

Perhaps some clarification is needed. Low RAM GPU != Old GPU. There are plenty of current-market graphics cards with modern day GPUs and < 3GB RAM source. They are significantly cheaper than their >= 3GB counterparts.

As for making ASICs cheaper, yes, that is a definite benefit. Cheaper ASICs can lead to more manufacturers which is why a key part of this proposal would be reaching out to potential ASIC manufacturers and GPU manufacturers.

Lastly for the old GPUs that remains to be seen, what you linked was assuming a price of $150 and mining on ETH. ETC currently has a much lower hashrate and those cards can be found at 1/3rd of the price (~$50-60) source. I'd actually be very surprised if you couldn't find these a lot cheaper in second-hand markets. Break-even is ~1 year at $60 but 6 months at $30 source.

A better example is a GTX 970 2GB, currently selling at $50-$75 source and pulling in $150/year source.

[pyskell]

Even my GTX 460 that's been demoted to driving monitors in my development box seems profitable.

[chipbit]

I think supporting smaller DAG could be viable, but over time, any video cards will not hold up to powerful ASIC's. No one can use video cards for BTC or LTC, or Dash, etc, so history shows this may not work. I am also not convinced there will be competition either. So far, not much competition has appeared on BTC market. How much effort/time is needed to change the ETC hash algorithm to thwart current ASIC's? Could we do that just to see how much of the hashrate is ASIC/Bitmain? I suspect 10-50% already is running on the network.
Is the fixed DAG much simpler to implement? If I remember correctly, it is. Also what was the reason in jump from 8TH to 12TH in ETC network hash rate around Feb 14?

...just throwing around some thoughts..

[pyskell]

Yup, over time ASICs are likely to overtake GPU mining and we're currently working with incomplete information on how powerful ASICs are currently and in the future. We definitely need more information that may only come once some ASICs hit the market.

In the meantime I've reached out to all the ASIC manufacturers I can find as well as AMD/NVIDIA to gauge their interest and thoughts.

Hashrate in February may have spiked because of either secret ASIC mining or high price (~$40).

Lastly, this is merely early-stage planning on one possibility to prevent miner centralization. My own belief is that if we resist/brick ASIC Gen.1 then we discourage smaller manufacturers from entering as they'll rapidly deplete their R&D budget, and only large manufacturers will be able to roll out Gen.2/3/4. This increases centralization rather than reducing it.

[chipbit]

There has been a significant amount of discussion going on in the Zcash community regarding this issue, and am now leaning towards a multi-algo strategy that allows ASIC's and GPU's to work together for a coin. A quick summary of the solution would be that an equal number of blocks are solved by one algorithm using ASIC's, and another second algorithm using GPU's. Meaning, ASIC solves block1 with algo1, GPU's solve block2 with algo2, ASIC pool solves block3 with algo1, GPU pool solves block4, ...and so on. Algo1 is ASIC friendly, and Algo2 would be ASIC resistant. Instead of arguing about whether or not to allow ASIC's, is there a technical reason why this couldn't be implemented? Other coins have done this strategy.

See a good discussion on this topic here: https://forum.z.cash/t/let-s-talk-about-asic-mining/27353/574

[pyskell]

Multi-Algo approaches are also ASIC-able. Dash's X11 got ASIC'd, there's an X17 I believe as well (not yet ASIC'd I think).

So tweaks to Ethash to periodically break a ASICs (a-la Monero) would be a lot easier than completely changing the mining algorithm (which is a lot heavier of an task).

[chipbit]

Since I am not a developer, I believe what you are saying, but still think multi-algo is a good option if you can find a really good asic resistant algo like LYRE2RE2.

That being said, I think the "wait and see" strategy will work through about December, but once the antiminer e3 hits in July, we may see a spike by September in hashrate, and GPU miners may be unable to compete by December based on history (of GPU to ASIC blockchain conversions)

Zcash community is also talking about open source ASIC code and ASIC PCIE boards which sounds like decent options also, to prevent centralization.

[chipbit]

It is starting to look like ProgPOW is going to be a solution for many coins. It is dependent on specific graphics card functions, and making a "mining ASIC" for it, would basically be the same as making another graphics card, so the advantage of customized hardware is very minimal.

That being said, would Ether Classic consider ProgPOW ? The ETC team could watch and learn the potential issues from Ubiq and Expanse coins (who are switching to a ProgPOW type algorithm), And if those coins are successful, then ETC could implement a similar solution. This would assist in further de-centralization of the coin.

[tsauce]

Is there any movement on this ? I'd very much like to see 3GB limit removed since it'll affect a lot of miners out there including myself. I also feel that removing this and adding more cards to do PoW is a benefit instead of having it all being done by some large entities out there.

[W944]

Just an additional vote for ProgPow with a DAG reduction to make current gen energy efficient 3GB cards viable.

[realcodywburns]

Closing, this repo is depreciated . To be reopened on http://github.com/ethereumclassic/ECIPs