Change the ETC Proof of Work Algorithm to Keccak-256 #394
Comments
|
If you need help editing/formatting or anything let me know. Once the dust settles from 1099, we can carefully plan this through. |
|
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). |
|
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. |
|
wonderful |
|
Thanks for the redraft @p3c-bot. I'll set aside some time to catch up with the changes to this proposal. |
|
:-) |
|
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:
|
|
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" |
Why change the Ethereum Classic Proof of Work algorithm to Keccak-256 (Sha-3) |
antsankov
changed the title
antsankov
changed the title
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. |
|
Hi @antsankov, after discussing the Besu implementation of this ECIP with Antoine Toulme, it was clear that what you define as |
|
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... |
|
|
|
Monero now is randomX, and it's ASIC resistance. |
|
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 :)
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.) |
|
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." Request to move this proposal into
We need to make a call on this one after three years: @ethereumclassic/all-hands |
|
"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) |
|
"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." |
|
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. |
|
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.
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. |
|
Based on the call it appears there is rough consensus for this proposal to be moved to
Going forward I suggest:
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 |
|
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. |
|
A list of issues of ECIP-1049 (or successors), that should be addressed: let's start with the Specification part:
|
|
Next, the Motivation needs to be updated.
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.) |
|
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.
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 #394 (comment) |
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.
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: |
|
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:
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). 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., 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. |
|
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
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. 👍 https://github.com/ethereumclassic/ECIPs#ecips-historical-background Comment Copied from: #465 |
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. |
|
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. |
|
This proposal has been withdrawn from the ECIP process by its champion: This issue will be closed in the next 7 days. @ethereumclassic/ecip-editors |
|
12 days has past since the withdrawal of this proposal. @ethereumclassic/ecip-editors |
|
If anyone is still interested in supporting this sort of functionality, we are changing Expanses PoW to something similar to this. |
|
Greetings, @chrisfranko! |
|
I dooo
The XIP
expanse-org/XIPs#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
<#394 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA3BBMORNLGIXOM23ZXBAR3VNEA3LANCNFSM4T4ELTHQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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: #394
created: 2019-01-08
redrafted: 2020-11-19
license: Apache-2.0
Change the ETC Proof of Work Algorithm to Keccak-256
Abstract
A proposal to replace the current Ethereum Classic proof of work algorithm with EVM-standard Keccak-256 ("ketch-ak").
Specification
mixHash.mixHashandnonce, remains unchanged.The reference hash of string "ETC" in EVM Keccak-256 is:
49b019f3320b92b2244c14d064de7e7b09dbc4c649e8650e7aa17e5ce7253294For 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.
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.
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.
Implementation
A testnet implementing this ECIP, is currently live, with more information available at Astor.host
References:
Appendix
Miner Keccak-256 Test Vector
To verify the Result Hash, with make sure to use hex mode.
The text was updated successfully, but these errors were encountered: