search

ethereumclassic / ECIPs

https://ecips.ethereumclassic.org
81 stars 61 forks source link

ECIP-1043: Fixed DAG limit restriction #11

Closed realcodywburns closed 4 years ago

realcodywburns commented 5 years ago

ECIP-1043: Fixed DAG limit restriction

xazax310 commented 5 years ago

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 commented 5 years ago

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

https://github.com/ethereumproject/ECIPs/issues/6#issuecomment-250349532 https://github.com/ethereumproject/ECIPs/issues/6#issuecomment-250445495 https://github.com/ethereumproject/ECIPs/issues/6#issuecomment-250454321 https://github.com/ethereumproject/ECIPs/issues/6#issuecomment-343998329

phyro commented 4 years ago

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 commented 4 years ago

DAG rounding 4GB.

TheEnthusiasticAs commented 4 years ago

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

developerkevin commented 4 years ago

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 commented 4 years ago

Join the Core Devs Call to discuss: https://github.com/ethereumclassic/ECIPs/issues/333

gitr0n1n commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

NickNick-tech commented 4 years ago

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 commented 4 years ago

yes i think the same too 4 gbs are very important and easier than the others to implement

Android için Outlookhttps://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 GitHubhttps://github.com/ethereumclassic/ECIPs/issues/11#issuecomment-683294158, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AISARWYC7ZKU2ODVF5KT2GLSDECTLANCNFSM4GP7ADYA.

realcodywburns commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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=_activationepoch,_fixedepoch

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 commented 4 years ago

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

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 commented 4 years ago

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:

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

Thanks !

q9f commented 4 years ago

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 commented 4 years ago

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

ref #368 (epoch duration calibration)