antsankov commented 3 years ago

lang: en ecip: 1049 title: Change the ETC Proof of Work Algorithm to Keccak-256 author: Alexander Tsankov (alexander.tsankov@colorado.edu) co-author: Bob Summerwill (bob@etccooperative.org) status: Draft type: Standards Track category: core discussions-to: https://github.com/ethereumclassic/ECIPs/issues/394 created: 2019-01-08 redrafted: 2020-11-19 license: Apache-2.0

Change the ETC Proof of Work Algorithm to Keccak-256

This is a redraft, which means the original V1 of this proposal was not able to reach critical consensus while in Last Call. For more information, see here.

Abstract

A proposal to replace the current Ethereum Classic proof of work algorithm with EVM-standard Keccak-256 ("ketch-ak").

Specification

Replace the use of Ethash with Keccak256 to hash block headers and generate the mixHash.
The current outer-level Keccak256 hash of mixHash and nonce, remains unchanged.
The switchover takes place on XXX block, with a fallback block of YYY

NEW PoW:  keccak256(keccak256(rlp(unsealed header)), nonce) <= 2^256 / difficulty
OLD PoW:  keccak256(ethash(rlp(unsealed header)), nonce) <= 2^256 / difficulty

The reference hash of string "ETC" in EVM Keccak-256 is: 49b019f3320b92b2244c14d064de7e7b09dbc4c649e8650e7aa17e5ce7253294

For the official miner Keccak256 test vector, see Appendix.

Motivation

A response to the recent (6+, as of 2021) double-spend attacks against Ethereum Classic. Most of this hashpower was rented or came from other chains, specifically Ethereum (ETH). A separate proof of work algorithm would encourage the development of a specialized Ethereum Classic mining community, and blunt the ability for attackers to purchase mercenary hash power on the open-market.
As a secondary benefit, deployed smart contracts and dapps running on chain are currently able to use keccak256() in their code. This ECIP could open the possibility of smart contracts being able to evaluate chain state, and simplify second layer (L2) development. We recommend an op-cod / pre-compile be implemented in Solidity to facilitate this.
Ease of use in consumer processors. Keccak-256 is far more efficient per unit of hash than Ethash is. It requires very little memory and power consumption which aids in deployment on IoT devices.

Rationale

Reason 1: Similarity to Bitcoin

The Bitcoin network currently uses the CPU-intensive SHA256 Algorithm to evaluate blocks. When Ethereum was deployed it used a different algorithm, Dagger-Hashimoto, which eventually became Ethash on 1.0 launch. Dagger-Hashimoto was explicitly designed to be memory-intensive with the goal of ASIC resistance [1]. It has been provably unsuccessful at this goal, with Ethash ASICs currently easily available on the market.

Keccak-256 is the product of decades of research and the winner of a multi-year contest held by NIST that has rigorously verified its robustness and quality as a hashing algorithm. It is one of the only hashing algorithms besides SHA2-256 that is allowed for military and scientific-grade applications, and can provide sufficient hashing entropy for a proof of work system. This algorithm would position Ethereum Classic at an advantage in mission-critical blockchain applications that are required to use provably high-strength algorithms. [2]

A CPU-intensive algorithm like Keccak256 would allow both the uniqueness of a fresh PoW algorithm that has not had ASICs developed against it, while at the same time allowing for organic optimization of a dedicated and financially committed miner base, much the way Bitcoin did with its own SHA2 algorithm. The image below shows the excellent performance profile of Keccak in FPGAs:

If Ethereum Classic is to succeed as a project, we need to take what we have learned from Bitcoin and move towards CPU-hard PoW algorithms.

At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. - Satoshi Nakamoto (2008-11-03) [3]

Here is an analysis of Monero's nonce-distribution for "cryptonight", an algorithm similar to Ethash, which also attempts to be ASIC-Resistant it is very clear in the picture that before the hashing algorithm is changed there is a clear nonce-pattern. This is indicative of ASICs being found and showing a failure state of an ASIC resistant alogrithm.

example

Reason 2: Value to Smart Contract Developers

In Solidity, developers have access to the keccak256() function, which allows a smart contract to efficiently calculate the hash of a given input. This has been used in a number of interesting projects launched on both Ethereum and Ethereum-Classic. Most Specifically a project called 0xBitcoin [4] - which the ERC-918 spec was based on.

0xBitcoin is a security-audited [5] dapp that allows users to submit a proof of work hash directly to a smart contract running on the Ethereum blockchain. If the sent hash matches the given requirements, a token reward is trustlessly dispensed to the sender, along with the contract reevaluating difficulty parameters. This project has run successfully for over 10 months, and has minted over 3 million tokens [6].

With the direction that Ethereum Classic is taking: a focus on Layer-2 solutions and cross-chain compatibility; being able to evaluate proof of work on chain, will be tremendously valuable to developers of both smart-contracts and node software writers. This could greatly simplify cross-chain interoperability.

Example of a Smart contract hashing being able to trustlessly Keccak-256 hash a hypothetical block header. example

Implementation

A testnet implementing this ECIP, is currently live, with more information available at Astor.host

Java Node Implementation (HyperLedger Besu). Supports Stratum mining. Located here
Keccak-256 CPU Miner. Located here
Official Keccak Team Implementation Document for Hardware and Software. Located here
TODO Block Explorer. Located here
TODO Live Network Stats. Located here

References:

Appendix

Miner Keccak-256 Test Vector

nonce: 0x0000000000000038
mixhash (AKA mining hash): 0xec1e0af050c8c5b9e2b59c65da7d9dd62eaf5a17f9ff6a91da60858a0233e444
Outer Keccak Input (mixhash + nonce): 0xec1e0af050c8c5b9e2b59c65da7d9dd62eaf5a17f9ff6a91da60858a0233e4440000000000000038
Keccak Result Hash: 0x0116ad248e0dc3f7f843f73a62803c5f6b7c0427700b70c8b1aab39db404089f
Result Hash (int):492378471644473844779041230572681759021515627522456897855697138922293561503
Difficulty (int):1157920892373161954235709850086879078532699846656405640394575840079131296399
Difference (hash - diff): -665542420728688109456668619514197319511184219133948742538878701156837734896

To verify the Result Hash, with make sure to use hex mode.

q9f commented 3 years ago

If you need help editing/formatting or anything let me know. Once the dust settles from 1099, we can carefully plan this through.

bobsummerwill commented 3 years ago

Thanks for the redraft, @p3c-bot.

I have just recently ChainSafe for a SOW on implementing and upstreaming Keccak256 in Besu (picking up and continuing the work which Whiteblock started earlier in the year).

antsankov commented 3 years ago

Thank you for the support @q9f and @bobsummerwill , at this stage the primary goal for the network is short term stability, to the point at which exchanges and mining pools feel comfortable to handle ETC once again.

When we are in a stable position post-Thanos, we can have a more nuanced conversation about the future of Proof of Work on the network, without the pressure or baggage of the previous thread from 2019.

chrisfranko commented 3 years ago

wonderful

gitr0n1n commented 3 years ago

Thanks for the redraft @p3c-bot. I'll set aside some time to catch up with the changes to this proposal.

TheEnthusiasticAs commented 3 years ago

:-)

gitr0n1n commented 3 years ago

Alex @antsankov , can you please add this to your top post so everyone can follow the other discussions on this evolving ECIP? Thank you!

Related Discussions:

antsankov commented 3 years ago

Just to submit for the record: Keccak-256 and the wider SHA3 family has been analyzed and determined by researchers to be quantum-resistant. I believe this will be important for ETC over the next few years.

Source: "Estimating the cost of generic quantum pre-image attacks on SHA-2 and SHA-3" https://eprint.iacr.org/2016/992.pdf

stevanlohja commented 3 years ago

Why change the Ethereum Classic Proof of Work algorithm to Keccak-256 (Sha-3)

🔗 https://etccooperative.org/posts/2020-12-03-why-keccak

gitr0n1n commented 3 years ago

Alex @antsankov , can you please add this to your top post so everyone can follow the other discussions on this evolving ECIP? Thank you!

Related Discussions:

ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8

ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13

ETC Core Devs Call(s) 2020 Q3: Hardfork #333

ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342

ETC Core Devs Call 13 & 14 #362

ETC Core Devs Call 15 - ECIP-1049 Breakout Session Keccak-256 #382

SHA3 Precompile ethereum/EIPs#2951

Core Devs Call 15 Recording

Change the ETC Proof of Work Algorithm to Keccak-256 #394

Core Devs Call 19 Recording

Community Call 005 Recording

Community Call 010 Recording

ETC Core Devs Call 22: Proposed Rejection of ECIP-1049 #460

It should be noted in this new discussion thread, this ECIP appears to be contentious (as documented in all the previous threads/recordings) and will likely result in a chain split.

leo-bogastry commented 3 years ago

Hi @antsankov, after discussing the Besu implementation of this ECIP with Antoine Toulme, it was clear that what you define as mixhash is just a preliminar hashing of the header (without nonce and mixhash). What you call Outer Keccak Input (in the Test Vector) should be called mixhash instead.

Jaska8 commented 3 years ago

So GPU minig will not work in future and ASIC/FPGA manufacturers (Mainly asia, because it's too expensive to manufacture anything decent cheaply) will take over the network hashrate while selling overpriced equipment which will be useless and e-waste if ETC does not shoot up to the moon? Who mines for no-profits jus to secure the etc network?

This sounds like a really bad plan, from miner perspective.

gitr0n1n commented 3 years ago

So GPU minig will not work in future and ASIC/FPGA manufacturers (Mainly asia, because it's too expensive to manufacture anything decent cheaply) will take over the network hashrate while selling overpriced equipment which will be useless and e-waste if ETC does not shoot up to the moon? Who mines for no-profits jus to secure the etc network?

This sounds like a really bad plan, from miner perspective.

That is why this is being pushed on the network by some rouge developers in the "SHA-3 Coalition" as they call themselves. It's not very well thought out. However, once they make this split they will have full control of their own chain (not the original) and not have to deal with decentralized development that comes with Ethereum Classic.

No surprise it's backed by someone from the Ethereum Foundation (Trojan Horse). Literally pulling an Ethereum Foundation (DAO Fork) and securing it with a Bitcoin Segwit2x New York Agreement approach. Not to mention they pushed this when the network was at its weakest during the 51% attacks while FUDDING the ETC chain. If that doesn't scream bad actors, I don't know what does...

Best of luck to them

DirtyRusski commented 3 years ago

So GPU minig will not work in future and ASIC/FPGA manufacturers (Mainly asia, because it's too expensive to manufacture anything decent cheaply) will take over the network hashrate while selling overpriced equipment which will be useless and e-waste if ETC does not shoot up to the moon? Who mines for no-profits jus to secure the etc network? This sounds like a really bad plan, from miner perspective.

That is why this is being pushed on the network by some rouge developers in the "SHA-3 Coalition" as they call themselves. It's not very well thought out. However, once they make this split they will have full control of their own chain (not the original) and not have to deal with decentralized development that comes with Ethereum Classic.

No surprise it's backed by someone from the Ethereum Foundation (Trojan Horse). Literally pulling an Ethereum Foundation (DAO Fork) and securing it with a Bitcoin Segwit2x New York Agreement approach. Not to mention they pushed this when the network was at its weakest during the 51% attacks while FUDDING the ETC chain. If that doesn't scream bad actors, I don't know what does...

Best of luck to them

Cool story bro...

gitr0n1n commented 3 years ago

On record comments in opposition to this proposal:

vieyang commented 3 years ago

keccak256() is just a solidity function, we can also add sha256() if we want.

vieyang commented 3 years ago

Monero now is randomX, and it's ASIC resistance.

wpwrak commented 2 years ago

In the 2021-08-20 devcall, issues to consider when forking the KEC chain off the ETC chain were brought up. I posted a few thoughts on Discord, re-posting here per request, with slight editing, mainly formatting and capitalization, to better preserve it for posteriority.

A few comments on the kec issues in the devcall (written text seems better for this than a half-hour monologue :)

1) The big problem with estimating hash rate is that you don't know a) what fraction of available GPU miners you get, b) how many of the available FPGA will join, and c) if there are already ASICs and if/when they'll join. I'd expect a 1st gen KEC ASIC to be > 1000x more efficient, in terms of H/$, than a GPU, possibly 10'000. Just look at the hashrates of modern BTC miners. This huge difference also means that you can't extrapolate beyond that moment. Not sure what the GPU vs. CPU ratio looks like. The difference gets even worse if you compare Etchash 1:1 on a per-hash basis with KEC. so better don't do that :)

2) To attract miners for such trial runs, you may want to create a financial incentive. e.g., allocate some nominal number of ETC. run testnet over time X. then distribute these ETC nominal ETC according to the number of hashes people have contributed to the testnet. Either pay them immediately, if the amount is small enough that someone could just offer a mining bounty, or, if it's too big, plan to airdrop them on the KEC/SHA3 fork.

3) Speaking of a fork, instead of forking, you could start a new chain, wait until it settles, maybe even reset to zero if it goes too wild, then airdrop the entire ETC ledger onto the new chain.

4) Or save yourself all that hassle and start from zero. keep ties at the developer level between ETC and KEC so that the existing shared codebase continues to be shared. (I've suggested this as an "umbrella".) In any case, if you start with a clean slate and whether or not you airdrop the ETC ledger later, you'll have very little value on that chain at the beginning, so even if anything goes terribly wrong, it won't do much damage and it won't be a PR problem either.

And i should add that the maximum ASIC:GPU performance gap might be around 50'000:1 if i read the numbers right (extrapolating from BTC miner data). I guess ASICs won't jump immediately to the most efficient (= expensive) process, though. Of course that also means that early adopters are likely to get squeezed off KEC mining if and when a new generation rolls in. Like it happened on BTC, but much faster, since the major players are already familiar with the base technology (from BTC), so it all depends on whether and when it makes sense to them economically to step up their game.

There are also a number of other knobs a manufacturer can control, like the number of chips: you can either make a relatively big and very efficient but also expensive miner with a lot of chips, or you can use just one or two chips for a low-end miner, which has a poorer performance/price ratio. The problem for miners in this case would be that a follow-on product that puts them under pressure can be made very quickly, since you only need to change the PCB and maybe controller/interfaces, but not the ASIC itself. (All these issues don't exist with Etchash, since the large DAG imposes a relatively large minimum miner size. and the DAG RAM size also ensures that you can't scale so easily by just switching to a better process - you can still scale this way, but you have more inertia with Etchash.)

gitr0n1n commented 2 years ago

ECIP-1000 Clause: "ECIPs should be changed from Draft or Last Call status, to Rejected, upon request by any person, if they have not made progress in three years. Such a ECIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Last Call if it meets the criteria required as described in the previous paragraph." https://ecips.ethereumclassic.org/ECIPs/ecip-1000

Request to move this proposal into Rejected status on the next CDC call for the following reasons:

This proposal is from January 7, 2019. It has been three years (ECIP-1000 requirement) since it was proposed and this proposal continues to remain contentious with a guaranteed chain split.
The proposal failed on a push to Accepted status in October 2020 due to lack of clarity on a transition plan from the author among many documented issues on the CDC 15 call. The core developers found this proposal to be incomplete and contentious in its form. The author and proponents were asked to go back to the Draft status and address the documented issues or Withdraw the proposal. These issues have not been addressed. https://github.com/ethereumclassic/ECIPs/issues/382
The author has abandoned championing the proposal after the 2020 failure.
To anyone that has been following this proposal it is clear it is still at the WIP phase after three years as an ECIP proposal. Even if this proposal was pushed to Accepted status, there is not a fully detailed transition plan to execute the proposal. It simply is incomplete in its current state.
The rationale to push this proposal has changed multiple times since its inception. There just isn't a clear reason for this proposal which is required in the ECIP process. ECIP-1099 was the network's preferred choice to addressing this proposals original intention.
This proposal is wasting valuable network resources by pulling attention/group think/resources away from legitimate proposals/issues that are not contentious in nature and are more pressing to the network's overall health. Coop should be funding non-contentious proposals, not using donated funds to divide this network.
This proposal has failed the ECIP by not following these: https://ecips.ethereumclassic.org/ECIPs/ecip-1000
- Step 1: "Vetting the Idea Publicly before writing an ECIP", "Is the idea applicable to the entire community, not just the Author"
- Step 2: "to address additional concerns about the proposal.", "ECIP authors are responsible for collecting community feedback on both the initial idea and the ECIP before submitting it for review.", "However, wherever possible, long open-ended discussions on public groups or mailing lists should be avoided."
- Step 3: "Reasons for rejecting ECIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Ethereum Classic philosophy.", "For a ECIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly."
- Step 4: "It occasionally becomes necessary to transfer ownership of ECIPs to a new champion.", "A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the ECIP process, or has fallen off the face of the net (i.e. is unreachable or not responding to email)."
- "An ECIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement."
- "An ECIP may only change status from Draft (or Rejected) to Last Call, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to Final status."
- "ECIPs should be changed from Draft or Last Call status, to Rejected, upon request by any person, if they have not made progress in three years. Such a ECIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Last Call if it meets the criteria required as described in the previous paragraph."
- "Draft ECIPs which may be in a very early stage may be entered as WIP ECIPs, which means they are a work in progress."
- "Why is this necessary at all? Many ECIPs with significant real-world use have been left as Draft or Last Call status longer than appropriate."

We need to make a call on this one after three years: Rejected status or push a contentious chain split for 1049 and set a block.

@ethereumclassic/all-hands

gitr0n1n commented 2 years ago

"So the Implementation section of ECIP-1049 doesn't have that level of clarity (this one correct? #13). It seems to be an extension of the rational section. That is perhaps my biggest beef in that the spec doesn't in fact specify anything with clarity. It has some hints but is missing actual details, such as what is H sub 'n bar'?

There needs to be a "specification" section in ECIP-1049, as noted by the ecip template. These three bullet points should be in that section. There also needs to be clear specification as to the proposed difficulty bump. And some justification of the 100x difficulty bump, it appears to be pulled from thin air.

Also, there are so many versions of ECIP floating around I think the PR description and ultimate merge commit needs to reference the "official" location of the ECIP it's implmementing."

hyperledger/besu#1882 (comment)

gitr0n1n commented 2 years ago

"I'm going to be a bit of a hard nose about this, but until the referenced ECIP (https://ecips.ethereumclassic.org/ECIPs/ecip-1049) specifies what has been discussed in this PR I'm not going to give it a serious review. If we are implementing what should be specified in an ECIP then the ECIP should actually specify something.

I'm not looking for yellow paper equations but at least "this field now has this data (xxxx)" "this field now has this data (yyy)" "to calculate that value do XYZ." "If I J and K then the block is valid, otherwise it is invalid." https://github.com/hyperledger/besu/pull/1882#issuecomment-784499616

antsankov commented 2 years ago

Bob Summerwill, leader of the ETC Coop, is now a co-author of the proposal and will be the new champion for it. I'm happy for his leadership in ECIP-1049 and will continue to assist in getting this proposal moved to accepted/ implemented in ETC clients.

ETCpunk2 commented 2 years ago

ECIP-1049 Consensus Tracker

Hello Everyone, I have created a new document not previously found in the community here called ECIP-1049 Consensus Tracker. It is open, public, and revisable. Its purpose is to compile over three years of conversation around ECIP-1049 from the ETC GitHub and the Discord channels so that we can attempt to precisely quantify the community's aggregated opinion on the proposal. It has been declared contentious by some, amazing by others, but there has never been a comprehensive catalogue that tracks these statements. Now we have one.

Links to all statements have been embedded in the "Argument" column, links to GitHub profiles are embedded in the "Name" column, and totals of "For" votes and "Against" votes can be found at the bottom.
There is a Rough Consensus calculation cell that is set to display Yes if there is a SuperMajority vote (>67%) and No if there is less than a SuperMajority. ECIP-1000 states that proposals should achieve Rough Consensus and defines this by saying it must be more than a Simple Majority (>51%) but does not need to be total consensus (100%). We can slide the scale of the calculation cell in whichever way we determine, but I see SuperMajority as a middle ground to start with.

NOTE: If you feel that there is a piece of information missing or incorrect, please DM me so that I can update it. The Consensus Tracker does not represent an official Core Developer vote, but does provide transparency into the historical data and the broader community sentiment.

https://docs.google.com/spreadsheets/d/e/2PACX-1vRa4wOJE8hiMbR44FUTqds8y8mBVkRjbfGsEuAhy9hgTOEoxi48QjvbLbzplj8oeno68YU9u3HXG9Y4/pubhtml

antsankov commented 2 years ago

Based on the call it appears there is rough consensus for this proposal to be moved to Last Call ECIP-1049:

Major node developers (core-geth, Besu) have indicated they are ready to support this switch over in their node software.
At the time of post: The community consensus tracker shows 65 community members for, and 26 on the record against.
The technical specification has been solidified, and is ready to be merged into clients.

Going forward I suggest:

Activation time for this proposal is suggested to be 16,000,000 (approx. November 2022) and fallback 16,500,000 (approx. February 2023).
We move this proposal to Last Call as soon as possible, and we move to Accepted within three weeks from today (March 14)
Any technical specification/implementation issues can be addressed within this period of time before acceptance. Once proposal is accepted, send out press releases to community members and begin work merging into clients.

At this point, I hand over the reigns to Bob Summerwill to champion from here, and will continue work on this proposal once it is in Last Call and Accepted

antsankov commented 2 years ago

One thing that was mentioned is we create a separate implementation/network activation ECIP, and this ECIP-1049 becomes just the specification itself for how the network runs Keccak256 Proof of Work, I support this approach as well as activation at 16,000,000.

wpwrak commented 2 years ago

A list of issues of ECIP-1049 (or successors), that should be addressed: let's start with the Specification part:

The proposed new hash function and its interfaces should be stated clearly, e.g., given the general structure (currently used by ETChash) of (Result, Digest) = Hash(Header, Nonce) (and assuming Ethash/ETChash needs no further explanation in this context), and the first part of the Ethash function being s = KEC512(KEC256(Header) + Nonce) where + means concatenation, the proposed change is to implement Hash() as Hash(Header, Nonce) := f(KEC256(Header), Nonce) f(HeaderHash, Nonce) = KEC256(HeaderHash + Nonce) using the same byte orders as in Ethash/ETChash.
At least one set of example vectors, at the byte level, using a real block header, should be provided, to enable implementers to verify their implementation.

wpwrak commented 2 years ago

Next, the Motivation needs to be updated. First summarizing the key concept of the respective item in current ECIP-1049, then the criticism:

Hashrate from other chains (using the same algorithm) was used against ETC. This has already been addressed in the Thanos update, by including ECIP-1099, which changed the algorithm sufficiently to make ETChash no longer identical to Ethash, but in a less invasive way than proposed by ECIP-1049, and with the added benefit of temporarily enabling 3 GB and 4 GB miners to produce ETC, thus contributing to the desired network hashrate increase.
Smart contracts would find it easier to directly verify blocks. This has been discussed extensively, but no plausible scenario emerged where it would make sense for a smart contract to do this. The closest case that was presented is [1], but that does not require any smart contract (neither for proof generation nor for verification) to verify the validity of the nonce. Furthermore, verifying a nonce would only make sense if the block's presence in the chain could be verified, which is possible in some cases, but then already implies that the nonce of the block in question has been verified. The supposed use case therefore does not exist, and the item should be removed, or a use case should be provided.
Consumer processors can compute KEC-256 very efficiently. Again, this hardly matters, given that, if "consumer equipment" was to independently verify blocks, it would also have to ensure that these are actually part of the chain. Processing the whole chain is a major effort, and an application running on a performance-limited system would try to avoid having to do this in the first place, especially not repeatedly. The supposed use case is therefore weak or nonexistent, and the item should be removed, or a stronger use case should be provided.

In recent discussions, the proponents of ECIP-1049 have stated numerous times that the key motivation for why, in their opinion, ECIP-1049 needs to be implemented, is to avoid 51% attacks resulting from hashrate currently on Ethereum being released onto smaller coins, like ETC, when the ETH Merge occurs. If the ECIP-1049 proponents want to uphold that argument, this should be included in the motivation (and then adequately discussed.)

[1] https://github.com/aragon/evm-storage-proofs

wpwrak commented 2 years ago

Last but not least, Compatibility. ECIP-1049 proposes a profound change to the entire ETC ecosystem. The impact of this change in the ecosystem needs to be discussed, both where they result advantageous, and where they create or worsen problems and risks. This should probably be in a document (ECIP or other) separate from the technical specification.

I expect the proponents of a change to KEC-256 to be fully capable to extol the benefits of their proposal, so I shall focus only on aspects I perceive as negative, and that would need to be discussed. I'd also like to apologize in advance that some of the potential issues may sound like fearmongering, but they merely reflect concerns presented by ECIP-1049 proponents, and, assuming they were honest, need to be addressed.

Given that, after ETH going PoS, ETC (using ETChash) will be the by far largest coin in the Ethash family, it will be the only viable future option for mining for most existing Ethash-type ASIC miners, and it will be one of the most attractive coins to mine for GPU miners. A change to KEC would immediately take away this possibility from Etash-type ASIC miners, and would severely limit the time during which GPU miners would be able to mine ETC (using KEC), given that dedicated ASICs are expected to appear within a year (1) and render GPUs uncompetitive. A scenario where current ETC miners, as well as ETH miners seeking refuge after the Merge, would not accept to be obsoleted by a "last minute" change of the ETC PoW algorithm, continue mining ETC using ETChash, and the proposed algorithm change thus resulting in a split of chain and community, is considered likely by many, myself included, if ECIP-1049 should be implemented as proposed. (2)
Given that a change to KEC-256 would eventually obsolete all existing mining hardware for ETC, a completely new mining ecosystem would have to be created, with competitive new hardware. In particular, given that ASICs for compute-only PoW algorithms like the one proposed can easily outperform all other technology (CPUs, GPUs, FPGAs) by orders of magnitude, the ETC mining ecosystem would only reach stability once efficient ASICs have been
- developed,
- manufactured, and
- deployed.
We should consider that the replacement cost of current Ethash hardware is estimated to be in the order of 10 Bn USD. If we assume that about half that equipment will stop mining after the Merge (due to lack of profitability), and the rest will be divided among all the Ethash-type coins and GPU-friendly coins, we can expect ETC (on ETChash) to receive at least 1-2 Bn USD worth of mining equipment. Anyone trying to attack ETC would have to be able to control equipment matching that value, which is thus a strong "anchor" for the ETC ecosystem. If the mining ecosystem is to be reset, as ECIP-1049 proposes, the expected investment in development and deployment of mining infrastructure need to be discussed, to ensure a suitable strong "anchor" will be available, not only once the KEC-256 mining ecosystem has matured, but also throughout the ramp-up process leading there.
This discussion should also consider uncertainty about the future of ETC in the weakened state in which an algorithm change would leave it, and that potential investors may be reluctant to trust the ETC community after what they may perceive as a "rug pull".
If doubts are strong enough, they could delay or prevent development or deployment of efficient hardware, which could leave ETC in a "limbo" where only inefficient hardware would be available for mining, and it would thus remain a comparably easy victim.
During the ramp-up, investors, exchanges, and other operators may choose to protect themselves from perceived risks of the ramp-up process, and take actions including reducing their ETC assets, suspending operating with ETC, and similar. This in turn could also feed back into delaying the ramp-up.
While the algorithm change aims to establish ETC as the dominant coin on SHA3/Keccak, there are other coins that are also using SHA3/KEC, or considering to do so, and could end up competing and even overtaking ETC. This would result in ETC being once again a minority coin, with all the problems this brings. In contrast to this, if staying on ETChash, ETC is the uncontested leader in the Ethash space after ETH, with the next most important coin orders of magnitude smaller in several metrics. Possible SHA3/KEC competitors include Monero, Quitmeer, and Tari. Especially Tari may (3) use SHA3/KEC in a away that is very similar to what ECIP-1049 proposes, and may even be indistinguishable to hashrate brokers. (4)
ECIP-1049 proponents have presented the hypothesis that miners who have nothing to lose (because of them mining would no longer be profitable after the Merge, due to the influx of Etash hashrate) would resort to crime, and conspire in a coordinated attack against ETC. A similar situation would exist with an imminent algorithm switch. If we consider disgruntled miners a real risk, why would they not withdraw from mining ETH a little earlier than the Merge (or the switch, whichever comes first), and attack ETC before such a change ? Note however, that they would also have a completely legal alternative to this, see (2).
ECIP-1049 proponents have presented the hypothesis that miners finding they can no longer mine profitably after the Merge will turn to crime, and conspire in a coordinated attack against ETC. Miners would find themselves in much of the same situation after the Merge, even if ETC will already have switched to SHA3/KEC. Given that ASICs are expected to appear only much later, KEC mining would be based on GPUs and FPGAs, and most likely have less compute power than the hypothetical attackers could field. Such a threat would persist until the development and deployment of KEC ASIC miners on ETC would be able to "neutralize" vacant GPU hashrate.

The above isn't meant to be an exhaustive list of potential concerns. Other considerations were mentioned in discussions on discord.

Footnotes:

(1) When that year would start depends on how confident the prospective investors in ASIC development would feel about a) the algorithm change to be beneficial for ETC, b) the algorithm change to be accepted, c) the algorithm change to be implemented in an adequate timeframe, and d) there to be sufficient market demand (unless the investors plan to self-mine). E.g., while a very confident investor may already have started designing and producing ASIC miners, a more cautious one may want to wait until ECIP-1049 is actually and irreversibly deployed.

(2) Ethash miners would have little to lose by supporting a chain split, given that ETC is by far their best option for continuing to mine after the ETH merge. And they wouldn't even have to break any laws, as some ECIP-1049 proponents have suggested miners facing a loss of profitability would.

(3) This is still work in progress, but since current Tari is based on Mimblewimble, a structure (especially placement of the nonce in the block header) very similar to ETC's seems likely.

(4) Which would enable the 2020 attack scenario, see also https://github.com/ethereumclassic/ECIPs/issues/394#issuecomment-1047257870

IstoraMandiri commented 2 years ago

@antsankov

* At the time of post: The community consensus tracker shows 65 community members for, and 26 on the record against.

In discord some have noted that this consensus tracker is misleading as it conflates the positions of many (including myself) who are against 1049 but supporting the eventual long term implementation of SHA3 via some other approach as "Neutral" or "For" as opposed to "Against" this particular ECIP.

Saying "I think chocolate is good" doesn't mean "I am neutral about shoving chocolate bars up my nose"

Far from supporting the implementation of this ECIP, I view this tracker as evidence that no significant community consensus has been reached about 1049 specifically; it is contentious.

Some examples picked out, but I'm sure there are more:

developerkevin | participant | Neutral | Keccak possible in future, but not now.
realcodywburns | participant | Neutral | wants to see proposal completed, also treasury dropped first
BelfordZ | participant | Neutral | Contradicts himself. Against improving efficiency in github, then pro efficiency on twitter.
phyro | participant | Neutral | Recognizes Keccak256 is superior and makes case for gradual transition to it I'm far more interested in Sha3... better pow due to it being cheaper I'm Pro sha3 but anti solves 51% attack | Nov
Brotherlal#3637 | participant | For | Pro sha3 but does not believe 2022 is the year
IstoraMandi | ECIP Editor | Neutral | supports the algo change with a laddered transition implemention
q9f | participant | For | helping plan the ECIP through

wpwrak commented 2 years ago

Looking at other coins that use or contemplate using SHA3/KEC (0xBitcoin, Bitgesell, MaxCoin, SmartCash, Quitmeer, Tari, Monero, possibly more), there seem to be basically two types of ways how SHA3/KEC is used for PoW:

In the BTC way, where the block header mimics a BTC block header, the nonce is only 32 bits, and there is an extranonce. When the extranonce changes, one path in the merkle tree needs to be recomputed, and a new header hash has to be calculated.
In the ETH/ETC way, where only the nonce changes, and the rest of the PoW input remains fixed for the block being mined. In the case of ETH/ETC, the fixed part is the header hash (with the nonce in that header set to 0), but it could be just any blob. ECIP-1049 proposes (obviously) to do this the ETH/ETC way: f(HeaderHash, Nonce) = KEC256(HeaderHash + Nonce)

Since it is easily conceivable that a different coin could use SHA3/KEC in the same way, this could result in a situation where a hashrate broker would not be able to distinguish hashrate going to ETC from hashrate going to a different coin. As we saw in 2020, this can be a problem. The inability of brokers/miners to distinguish ETH from ETC was resolved by implementing ECIP-1099.

Since SHA3/KEC is still relatively new as a PoW algorithm, it would be prudent to protect against such a situation. ECIP-1099 accomplished this by changing the size and content of the DAG, but since ECIP-1049 removes the DAG completely, this approach is not available for ETC-KEC. However, a way to "tag" ETC hashes could be added with minimal effort, for example by XORing the hash result with a non-zero value that is unique to ETC (e.g., "ETC ETC Ethereum Classic ETC ETC", 32 bytes). I.e., instead of f(HeaderHash, Nonce) = KEC256(HeaderHash + Nonce) the PoW function would become f(HeaderHash, Nonce) = KEC256(HeaderHash + Nonce) ^ Tag with ^ being the bit-wise XOR operation.

From a system point of view, the XOR would be inside the mining loop, between KEC and the comparison with the difficulty target. Any other coin not using such a tag, or a different tag value, would produce results that do not satisfy the expected difficulty. (If they use no tag, the results when trying to verify their - worthless - nonces would even begin with "ETC ETC [...]".)

While this would not stop anyone from making an ASIC that can mine both with or without such a tag (or any other simple modification of this kind), it would allow separating ETC hashrate from non-ETC hashrate, and act as a "stop sign". This in turn would enable hashrate brokers to limit or entirely disallow hashrate to be directed at ETC. Even if a broker does not wish to make an effort to prevent hashrate they trade from being used against ETC, failing to do so could easily expose them to legal risks.

Such a "stop sign" is therefore likely to be effective against this attack scenario that is particularly convenient for attackers, and would force them to obtain their hashrate from a less convenient source, or leave ETC in peace and look for an easier target.

If a stronger protection would be desired, it could be obtained by adding a secondary hash function. That hash function should have a size cost similar to KEC-256. E.g., f(HeaderHash, Nonce) = OtherHash(KEC256(HeaderHash + Nonce)) (possibly with the addition of a tag, as above.)

This would make ASICs that support both ETC-KEC and some other SHA3/KEC-based coin(s), the latter by bypassing the OtherHash block, twice as expensive as a "pure" SHA3/KEC ASIC, and, provided that the other coin(s) are at least half as profitable per hash as ETC, would make producing or operating such ASICs unattractive.

However, this would be a more complex change, and the "stop sign" alone would be sufficient to have ETC-KEC not regress below present-day ETC (with ECIP-1099) in terms of security against attacks using "foreign" hashrate.

gitr0n1n commented 2 years ago

ronin: bobsummerwill I'm going to leave this PR open while you work on these identified issues from the ECIP-1000 document.

ECIP-1049 - ECIP Process Violations.pdf

I believe there is more public criticism to address from the CDC 15 call, community calls, the GitHub threads, and now the CDC 22. But these basic changes for the ECIP-1000 document should be very helpful in getting this proposal to where it ought to be:

the champion provides revisions that meaningfully address public criticism of the proposal

Thanks for participating in the call and stepping up to champion this ECIP and vocalizing intent to approaching the ECIP process in a pragmatic way. :+1:

https://github.com/ethereumclassic/ECIPs#ecips-historical-background

Comment Copied from: https://github.com/ethereumclassic/ECIPs/pull/465 https://github.com/ethereumclassic/ECIPs/pull/465#issuecomment-1047187415

gitr0n1n commented 2 years ago

@antsankov
* At the time of post: The community consensus tracker shows 65 community members for, and 26 on the record against.
In discord some have noted that this consensus tracker is misleading as it conflates the positions of many (including myself) who are against 1049 but supporting the eventual long term implementation of SHA3 via some other approach as "Neutral" or "For" as opposed to "Against" this particular ECIP.

Saying "I think chocolate is good" doesn't mean "I am neutral about shoving chocolate bars up my nose"

Far from supporting the implementation of this ECIP, I view this tracker as evidence that no significant community consensus has been reached about 1049 specifically; it is contentious.

Some examples picked out, but I'm sure there are more:
developerkevin | participant | Neutral | Keccak possible in future, but not now.
realcodywburns | participant | Neutral | wants to see proposal completed, also treasury dropped first
BelfordZ | participant | Neutral | Contradicts himself. Against improving efficiency in github, then pro efficiency on twitter.
phyro | participant | Neutral | Recognizes Keccak256 is superior and makes case for gradual transition to it I'm far more interested in Sha3... better pow due to it being cheaper I'm Pro sha3 but anti solves 51% attack | Nov
Brotherlal#3637 | participant | For | Pro sha3 but does not believe 2022 is the year
IstoraMandi | ECIP Editor | Neutral | supports the algo change with a laddered transition implemention
q9f | participant | For | helping plan the ECIP through

I also noted duplicates of the same person counted in this document, e.g. the original author of this proposal is counted three separate times in this consensus tracker. This is in addition to inaccurate representation of participants opinions, which are used to misrepresent a more favorable opinion of 1049, which aligns with the consensus tracker author's viewpoint.

ETCpunk2 commented 2 years ago

Regarding the Consensus Tracker, the opinion was marked as "Neutral" in most of the lines cited because those individuals were looking for a finalized proposal before determining their stance. In other cases, it was simply unclear what their stance was.

I published the tracker so that our community could aggregate years of commentary on the ECIP in a way that was simple to read and yet transparent enough to be auditable. I appreciate your feedback and have updated some of the specified participants accordingly. The latest results are 69% in favor and 31% against.

As noted in my original post anyone can message me with any specific line items you believe may be incorrect along with links to the up-to-date opinion of the participant.

gitr0n1n commented 2 years ago

This proposal has been withdrawn from the ECIP process by its champion: https://github.com/ethereumclassic/ECIPs/pull/486

This issue will be closed in the next 7 days. @ethereumclassic/ecip-editors

gitr0n1n commented 2 years ago

12 days has past since the withdrawal of this proposal. @ethereumclassic/ecip-editors https://github.com/ethereumclassic/ECIPs/pull/486

chrisfranko commented 2 years ago

If anyone is still interested in supporting this sort of functionality, we are changing Expanses PoW to something similar to this.

bobsummerwill commented 2 years ago

Greetings, @chrisfranko! Got a link to share?

chrisfranko commented 2 years ago

I dooo

The XIP https://github.com/expanse-org/XIPs/issues/5

All the implementations https://github.com/frkhash/

On Thu, 2 Jun 2022 at 15:06, Bob Summerwill @.***> wrote:

Greetings, @chrisfranko https://github.com/chrisfranko! Got a link to share?

— Reply to this email directly, view it on GitHub https://github.com/ethereumclassic/ECIPs/issues/394#issuecomment-1145215250, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3BBMORNLGIXOM23ZXBAR3VNEA3LANCNFSM4T4ELTHQ . You are receiving this because you were mentioned.Message ID: @.***>

ethereumclassic / ECIPs