ECIP-1043: Fixed DAG limit restriction

[realcodywburns]

ECIP-1043: Fixed DAG limit restriction

[xazax310]

I don't think changing the DAG realizes what you're envisioning. Your only argument is that ASICs are on the network then the DAG is pointless. Why keep Ethhash at all? Move to another Algorithm. Keeping Ethhash and resetting the DAG to allow GPUs with smaller GB limits doesn't accomplish much as most of the network is more than likely AMDs with 4GB + or ASICs. Small percentage makes up 3GB or less GPUs
According to EthOS 5000 1060 3GBs are running, and AMDs with 2GB and lower are in the 100's. Acccording to HiveOS 1060 3GB are about 18%. Of course there are none AMDs with 3GB or less.

It doesn't pull in any more security from smaller GPU miners and unless you ditch the DAG entirely you're still facing the same problem every few years. ETC needs to decide. Are they GPU friendly or ASIC friendly? Choose the appropriate move to an algorithm from there. The DAG will just keep throwing off investments anyone wants to make in ASIC or GPUs if ETC is to stay on PoW for it's lifespan.

Sources
http://ethosdistro.com/versions/
https://hiveos.farm/statistics/

[mikeyb]

I don't think changing the DAG realizes what you're envisioning. Your only argument is that ASICs are on the network then the DAG is pointless. Why keep Ethhash at all? Move to another Algorithm. Keeping Ethhash and resetting the DAG to allow GPUs with smaller GB limits doesn't accomplish much as most of the network is more than likely AMDs with 4GB + or ASICs. Small percentage makes up 3GB or less GPUs
According to EthOS 5000 1060 3GBs are running, and AMDs with 2GB and lower are in the 100's. Acccording to HiveOS 1060 3GB are about 18%. Of course there are none AMDs with 3GB or less.

It doesn't pull in any more security from smaller GPU miners and unless you ditch the DAG entirely you're still facing the same problem every few years. ETC needs to decide. Are they GPU friendly or ASIC friendly? Choose the appropriate move to an algorithm from there. The DAG will just keep throwing off investments anyone wants to make in ASIC or GPUs if ETC is to stay on PoW for it's lifespan.

Sources
http://ethosdistro.com/versions/
https://hiveos.farm/statistics/

Preach on. I have been saying this since 2016

ethereumproject/ECIPs#6 (comment)
ethereumproject/ECIPs#6 (comment)
ethereumproject/ECIPs#6 (comment)
ethereumproject/ECIPs#6 (comment)

[phyro]

do we know how this proposal differs from a DAG that would be of constant size? Specifically, how does a DAG reset impact possible ASIC implementations compared to a DAG where you always keep it at say 3GB but you are swapping the old data with the new one?
I don't know how this exactly works, I'm just wondering if it's possible that ASICs could take advantage of the reset until the DAG grows to a size that is much harder to manage which would be after N epochs.

[gitr0n1n]

DAG rounding 4GB.

[TheEnthusiasticAs]

Yes, now this topic should be the next milestone after the Phoenix Upgrade.

[developerkevin]

Think this needs some more concrete research on how many devices in mining farms are using less than 4gb machines. I’m not for “saving the little guy@ but if 4-5Gb machines make up a substantial share of my name and that’s going to be a problem. Unless the price increases substantially manufacturers have no incentive to build a new ASICS with more memory IMO.

[gitr0n1n]

Join the Core Devs Call to discuss: #333

[gitr0n1n]

If an ethash card can only mine ETC and not ETH, is that an ETC network positive? e.g.; ETC DAG 2GB and ETH DAG 4.1 GB, so any card under 4.1gb ETC would be the majority chain for those cards. Effectively ETH 1.x DAG begins the Ethash miner equipment capture now if ETC DAG is lower than ETH. It's a minimal change compared to other options being discussed that could have a large impact on providing static Ethash hashrate. I'm just thinking through this option out loud. I could be incorrect in my logic, feel free to correct me. I also likely haven't thought through the unintended consequences of this adjustment. But that appears to provide an ETC-centric solution, rather than relying on other blockchains to secure the ETC network.

[ghost]

In the ETC declaration of independence is written: ''forks and/or changes to the underlying protocol shall only be permitted for updating or upgrading the technology on which Ethereum Classic operates''
How does a DAG limit restriction classify as a technology update or upgrade?

[q9f]

This is now in last call (3 weeks) as per #333 - see #353

please note, that this also requires the following action items to be worked on in the next 3 weeks:

• instead of freezing the DAG, just freeze the size and rotate parameters (Cody, James?)
• research current DAG size, project future DAG size, find suitable block number

[NickNick-tech]

From December 2020 it is possible to increase the hashrate for 100 TH/s which comes from the 4 GB cards that are currently mining ETH. By preventing further size increase of the DAG file and keeping the Ethash algorithm, ETC has a fantastic opportunity to have good features from BTC and ETH at the same time. In that case, it would resemble BTC in its decentralization and consistency, while it would have the advantages of programmability as ETH.

[mahofmahof]

yes i think the same too 4 gbs are very important and easier than the others to implement Android için Outlook<https://aka.ms/ghei36>'u edinin

…

________________________________ From: NickNick-tech <notifications@github.com> Sent: Saturday, August 29, 2020 4:59:17 PM To: ethereumclassic/ECIPs <ECIPs@noreply.github.com> Cc: mahofmahof <mahofmahof@hotmail.com>; Manual <manual@noreply.github.com> Subject: Re: [ethereumclassic/ECIPs] ECIP-1043: Fixed DAG limit restriction (#11) From December 2020 it is possible to increase the hashrate for 100 TH/s which comes from the 4 GB cards that are currently mining ETH. By preventing further size increase of the DAG file and keeping the Ethash algorithm, ETC has a fantastic opportunity to have good features from BTC and ETH at the same time. In that case, it would resemble BTC in its decentralization and consistency, while it would have the advantages of programmability as ETH. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AISARWYC7ZKU2ODVF5KT2GLSDECTLANCNFSM4GP7ADYA>.

[realcodywburns]

i have submitted a revision to the ecip to clarify the implementation to allow for the widest number of graphics cards while still computing the dag. After the mahic dag freeze block, every epoch will be epoch 42. #356

Recommended Implementation

Two variables directly control the dag size growth cacheSize and datasetSize

• cacheSize is the size of the ethash verification cache that belongs to a certain block number. The cache size grows linearly, however, we always take the highest prime below the linearly growing threshold in order to reduce the risk of accidental regularities leading to cyclic behavior

• DatasetSize is the size of the ethash mining dataset that belongs to a certain block number. The dataset size grows linearly, however, we always take the highest prime below the linearly growing threshold in order to reduce the risk of accidental regularities leading to cyclic behavior.

These values are calculated as blockNumber / epochLength. To set the dag growth to a number smaller than what would occur through the normal calculation. A Magic Dag Epoch block is of 64 replaces blockNumber / epochLength as the epoch number after the fork block and when the dag is calculated in the future this epoch is always used. Dag generation is uneffected and both cache and data size.

//run prior to calculating cacheSize or dataSize 
 if (blocknumber > ECIP1043Transition) {
		epoch := 64
	} else {
		epoch := int(block / epochLength)
	}

[wpwrak]

I think the goal should be to make the transition as smoothly as possible. Going back to a ~1.5 GB DAG wouldn't be of much benefit for anyone mining ETC today. If someone is sitting on a pile of old 2 or 3 GB cards, maybe, but then then profitability of mining with such old hardware should be considered - eventually, the electricity bill will get you, no matter how small the DAG is.

As I understand Cody's proposal, the DAG content would still change, just the size would be much smaller than today. A ROM DAG would indeed open new possibilities that may lead to ASIC dominance (i.e., the abrupt obsoleting of GPUs, similar to what happened on BTC or, more recently, I've been told, RVN.) I'm aware that the SHA3 proponents actively embrace ASIC dominance, but their plan is more long-termish, and may very well suffer delays.

Also, a major divergence from today's situation may enable different approaches, like on-the-fly DAG calculation, which would produce similarly undesirable results.

I would suggest to choose a) a transition point T, and b) a fixed target epoch F, with F <= T but without a big difference between the two. F should be chosen such that the majority of 4 GB miners will still be happy with it. This would ensure that present-day miners would not suffer any upset and it would avoid the potential issues mentioned above.

Allowing for F < T would also mitigate the risk of miners crossing their hardware's 4 GB barrier before reaching T. They'd still be temporarily excluded from mining ETC, but they'd have the assurance that they'll be able to return before too long.

We could simply pick a tentative value for F in the near future, without having to have all the rest ready. If there's no large outcry from 4 GB miners in the week after reaching that epoch, we'll know the choice has been safe. If there's an outcry, we fix it :)

I would advise against continued DAG growth, even if reduced. That just adds complexity, and given the undesirability of F << T, it might still be a risk for 4 GB miners.

[wpwrak]

By the way, we now have a channel called #ecip-1043-fixed-dag, dedicated to technical discussion regarding ECIP-1043 (the choice of parameters, implementation and integration, testing, deployment), on the "ETC - Ethereum Classic" discord. Anyone who wants to join the discussion and isn't on Discord yet can find a button with an invite link on https://ethereumclassic.org/

[wpwrak]

A few pending issues, for the specification:

1. What block number do we set for the activation block ? Also, should activation coincide with an epoch change or should it be inside an epoch ?
2. What epoch shall be the fixed/frozen epoch ?
3. For programs that take their configuration from the command line, I'd like to informally proposed a common format for the option to set the ECIP-1043 parameters: --ecip1043=activation_epoch,fixed_epoch

Regarding 1), I think having an epoch that is both with and after ECIP-1043 would only complicate things needlessly.

Regarding 2), the possibility of bringing back 3 GB miners that have been forced to migrate/leave a bit more than a year ago has been brought up. This would still mean a significant DAG size reduction, but perhaps still imply a tolerable risk. These miners are probably on smaller coins like Pirl, Callisto, Ubiq, and QuarkChain now.

The purpose of 3) would be to make instructions to set up miners et al. more universally applicable, easing the transition.

[wpwrak]

To help with ECIP-1043 evaluation and testing, I've written/adapted (on behalf of Linzhi) the following three small programs:

• a cleaned-up and runnable version of the ethash.py reference implementation,
• a variant extended with the ECIP-1043 change (activation and fixed epoch must be set externally to activate it),
• a small pool server that can be used to test miners. This is still work in progress.

Code (everything ist in Python 2.7, to keep it close to the Ethash reference) and documentation can be found here.
https://github.com/LinzhiChips/ethash-ecip1043

The pool server speaks only the eth_getWork protocol. It can generate random jobs, change the epoch, and verifies results using the Ethash + ECIP-1043 module. This is meant to be a test tool, not intended for any sort of production use.

The pool server so far only fully supports regular Ethash. I plan to complete ECIP-1043 support in the next days. In its present shape, the pool server can be used to test the memory limits of miners, which is information that will be useful for choosing the fixed epoch.

If you encounter any problems with the Ethash implementations or the pool server, please create an issue on the ethash-ecip1043 repo, or catch me on #ecip-1043-fixed-dag.

[wpwrak]

It woul d be good if we could compile a database of real-life memory limits of ETC mining hardware. Of special interest would be to know the last epoch popular miners with 3 GB and 4 GB can mine, GPU and also ASICs. The pool server I mentioned in the previous comment can be used for this:

• clone the repo and start the pool server in "quick" mode, for example,
  ./pool.py -d 32 -e 250 -q 9999
  would start the pool server in "quick" mode (no verification of results) on port 9999, with the epoch set to 250, difficulty to 32 bits.
• direct your miner to stratum+tcp://foo@your-pc:9999
  ("stratum" refers to the protocol using eth_getWork. May not be called the same on all miners.)
• you miner should now request a job and start mining. The pool server will show its network traffic on the console.
• you can change the epoch by entering the following commands on the pool.py console:
  epoch N
job
epoch N sets the epoch to the specified decimal value. job sends new jobs to all the miners that are connected.

After determining at which epoch your miner runs our of DAG space, please report the following, either here or on #ecip-1043-fixed-dag:

• the highest-numbered epoch at which you could still mine,
• the nominal memory size of your mining hardware,
• manufacturer and model name of your hardware,
• the operating system you're using,
• the mining software you're using, and its version,
• whether the hardware is used exclusively for mining, or whether the machine is also used as a desktop and only part-time mines.

Thanks !

[q9f]

Please also review and consider #368 (ECIP-1099).

It turns out we missed the window for safely activating 1043 by a couple of months (~ epoch 350).

[q9f]

replaced by ECIP-1099 in #370 on call #362 (13)

ref #368 (epoch duration calibration)