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

[gitr0n1n]

ETC Core Devs Call 22 - Proposed Rejection of Keccak256 ECIP-1049 Call Results
https://ethereumclassic.org/blog/2022-02-23-core-devs-call-22-ecip-1049-call-results

#465
ETC Core Devs Call 22 Recording: https://www.youtube.com/watch?v=lpdZgsAbPXo

ETC Core Devs Call 22: Conclusion

• A new ECIP-1049 Champion was selected in Bob Summerwill. The old champion, Alexander Tsankov has stepped down from the proposal stating he is too busy to champion this proposal.
• It was agreed by the ECIP Editor r0n1n and the new Champion of ECIP-1049, Bob Summerwill, that the ECIP-1049 proposal needs a material rewrite to meet ECIP-1000 compliance and remain in Draft status.
• The new Champion vocalized intent to bring the ECIP-1049 proposal up to ECIP-1000 standards within the coming months during 2022.
• The ECIP Editor and others on the call felt it was reasonable to afford the new champion time to clean up the ECIP-1049 proposal, as it was vocalized that undocumented technical work has been done by the champion's paid staff.
• The ECIP editor vocalized intent to leave PR 465 open to push this proposal to Rejected status should this proposal continue to sit in a state that violates the ECIP-1000. This comes after the CDC 15 meeting where Alexander Tsankov, the old champion of this proposal, vocalized intent to update the proposal after a failed push to Accepted status in 2020 and did not follow through with the ECIP-1000 requirements regarding criticism and dissenting opinions to the ECIP-1049 proposal from the community.
• It was recommended to split the ECIP to multiple ECIPs to align with ECIP-1000 guidelines; technical work, transition strategy, social consensus building, activation plan. These were some examples provided to the champion.
• The elephant in the room on ECIP-1049 has been a documented lack of consensus. The ECIP-1049 proposal aims to displace the current mining ecosystem. This is a violation of the ECIP-1000 in itself.
  Pushing contentious hard forks on the network is a violation of the ECIP-1000 process. It's unlikely the ETChash mining ecosystem will update nodes to this proposal should a hard fork be attempted. Many in the community; mining pools, miners, developers, core development teams, community members have vocalized support for the non-fork ETChash side of a contentious hard fork should the proponents of ECIP-1049 push a contentious hard fork on the Ethereum Classic network.
• The ETChash mining ecosystem was assured continued support from community members should any centralized actor attempt a contentious hard fork on the Ethereum Classic network.
• The opposition to ECIP-1049 has provided the new champion material criticism of ECIP-1049 to address during the champion's material redraft of the proposal.
• The proposal will be reviewed at a later date for ECIP-1000 compliance. Should compliance not be met, this proposal will move to Rejected status. Note: the Champion can always revive a Rejected proposal when ECIP-1000 compliance is met.

Note: This ECIP appears to be contentious, as documented in all the previous threads and recordings. It has a high-probability of a contentious chain split between the Mining Ecosystem on ETCHash (GPUs and ETChash ASICs) and the proposed new mining ecosystem on Keccak256 (FPGA & KEC ASICs).

New Proposal Champion:
Given the new champion is active, Bob Summerwill is provided time to update the ECIP-1049 proposal to be ECIP-1000 compliant. This was recommended in October, 2020 to the previous champion after Core Developers Call 15, but did NOT happen. The hope is with a new champion we will see compliance with the ECIP process.

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

Some comments from Bob Summerwill on the undocumented technical work from his staff:

• Support for Astor already integrated in Besu. There is a pull request for core-Geth (and blocks successfully mined on Astor), but some rearchitecting needed to make that clean enough to integrate.
• The transition is where more client work is needed (ie. having a Testnet which goes through the transition versus being Keccak256 from Genesis). More work needed on mining side software too.
• So not tons left to do, but probably needs a couple of months of focus to do it right. Note - this is the technical work.
• Roll out via testnets, all the social layer etc etc is more time again, of course.
• I was asked where June, 2022 was feasible (end to end). I think that is a pretty clear not really possible.

Here is the open PR to move 1049 to Rejected status if the new champion does NOT bring the ECIP-1049 proposal up to ECIP-1000 standards:

• Rejected Status ecip-1049

Thanks for everyone's participation. Please direct future commentary to the newest ECIP 1049 discussion thread. However, please review the historical threads. There has been plenty of technical discussion on this matter over the years.

• ETC Core Devs Call 22: https://www.youtube.com/watch?v=lpdZgsAbPXo

Note: Issues with the ETC Discord server audio was reported by numerous call participants and observed on the recording. This led to talking over/interruptions during the call. Apologies to those listening after the fact from the organizer of the call and the third-party community member who recorded the call. Future CDC calls will be held on a platform with hand raising and the ability to mute interrupting parties during the call.

Thread 394

---

Original Comment:

Agenda:

https://ethereumclassic.org/blog/2022-02-21-core-devs-call-22-ecip-1049-proposed-rejection
Discuss fate of ECIP-1049 after three years. (ECIP-1000 clause).

Focus: REJECT Keccak-256 Mining Algorithm Change due to a high-probability risk of Contentious Chain Split between GPU Miners on ETCHash and FPGA & ASIC Miners on Keccak-256. ECIP-1049 is in violation of Ethereum Classic founding documents and the ECIP process. At this point, the contentious proposal has negative externalities on the network and is a resource drain. Move to reject the proposal after three years of technical discussion. If the proposal is not rejected, begin plans for a chain split.

Decision to be made:

• Move to Rejected status, or;
• Set a Block and Push Contentious Fork with a Chain Split

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."

The reason for "Rejected" status under this clause is that the champion (Alex Tsankov) has not met this requirement during the three years: "the champion provides revisions that meaningfully address public criticism of the proposal". Rather, the champion (Alex Tsankov) has ignored much valid criticism and abandoned the proposal. https://ecips.ethereumclassic.org/ECIPs/ecip-1000

Follow Up from: #382
Formal Proposed Rejection: #394 (comment)
Documented Github Opposition: #394 (comment)

If time permits: review ECIP-1094 and ECIP-1096 for activity. Newer proposals but appear to be abandoned by the authors as well. Should these be Withdrawn?

Please review the issue thread to find the most up to date information.
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 https://vimeo.com/464336957
Change the ETC Proof of Work Algorithm to Keccak-256 #394
Admin Clean Up on ecip-1049: #400
Core Devs Call 19 Recording https://www.youtube.com/watch?v=WySNxZbDEkQ
Community Call 005 Recording https://youtu.be/HaDANZN-ZUU?t=1585
Community Call 010 Recording https://youtu.be/6DRZEaKkpb4?t=3411
Community Call 011 Recording https://www.youtube.com/watch?v=ad_grFagA5k
Community Call 012 Recording https://youtu.be/GCBv1VCN2tE?t=3339
Community Call 013 Recording https://www.youtube.com/watch?v=HQ9IKu3PVkA
ETC Core Devs Call 22: Proposed Rejection of ECIP-1049 #460
Pull Request- Rejected Status ecip-1049: #465

It should be noted in this new discussion thread, this ECIP appears to be contentious (as documented in all the previous threads/recordings) and has a high-probability of a chain split between the GPU Miners on ETCHash and the FPGA & ASIC miners on Keccak-256.

How to join:
Topic: ETC Core Devs Call 22: Proposed Rejection of ECIP-1049
Time: February 21, 2022
Time: 17:00 UTC

Meeting Link: https://ethereumclassic.org/discord
Channel: community-calls
@ethereumclassic/all-hands

[gitr0n1n]

"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]

"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."
hyperledger/besu#1882 (comment)

[bobsummerwill]

IHMO this meeting should not occur until after the Mystique hard-fork.
I would suggest two weeks later than the current suggested date.

On a personal note, I will be unable to attend any meeting at this time-slot because it falls at 7am for me and I have parental responsibilities at that time of day. Two hours later is workable. Mondays and Wednesdays are the best days.

[bobsummerwill]

I would argue against the premise of this meeting, and the obvious bias in the two "decision to be made" choices.
There is a simple third choice, which is to leave the ECIP in Draft status, which I would argue is entirely appropriate for the current state of the proposal.

The assertion that there has been "no progress" on the proposal within the last three years is demonstrably false.

• A PoC on Besu was implemented by Whiteblock
• Production quality support in Besu was implemented in Besu by @atoulme, together with other rework and cleanup to the mining support in Besu generally. Vanilla Besu today includes support for Keccak256 mining and the Astor testnet.
• Support for Keccak256 in Core-Geth was implemented and tested, though not integrated yet.
• Support for Keccak256 in mining pool software was implemented.
• Henry Quan wrote a whitepaper and blog post analyzing mining options and potential transition landscape.

The cherry picked quotes above are a year old and were part of the review process which ended in the changes being merged into Besu. They were not show-stoppers.

[bobsummerwill]

With regard to the bullet-points in the Formal Proposed Rejection:

• Change the ETC Proof of Work Algorithm to Keccak-256 #394 (comment)

One point which I would agree with is that a new champion is required, and I would be happy to step into that role myself.

The ECIP text itself should also be updated to reflect the work which has been done since 2019, and to note its own issues, shortcomings and remaining TODOs. As a Draft proposal I would be happy to agree that it is still a work-in-progress. That is no reason to reject it, especially given the work which has gone into implementation and testing and given the broad interest in the proposal (on both sides of the fence).

All of the other bullet-points I would argue are fairly subjective.

[gitr0n1n]

Another snippet from ECIP-1000:

"The ECIP editor will not unreasonably reject an ECIP."

"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."

Aside from numerous other cited issues in the "Formal proposal to Reject ECIP-1049", on this specific bullet ECIP 1049 could be Rejected via:

• disregard for formatting rules
• being too unfocused or too broad
• being technically unsound
• not providing proper motivation
• not in keeping with the Ethereum Classic philosophy

But there are many more reasons cited:
#394 (comment)

For these reasons, I believe it is important we have this conversation in a timely manner and come to a decisive conclusion. Especially given the recent tactics of the ECIP-1049 proponents to attack Ethereum Classic's social layer via using sock puppets to gaslight, fearmonger, disinform, FUD, paint doomsday scenarios, and hijack other productive agenda items.

A clear decision on this will end the consensus debate that is gridlocked and hindering progress on more pressing topics that lack the contention we see on ECIP-1049.

[gitr0n1n]

The ECIP text itself should also be updated to reflect the work which has been done since 2019, and to note its own issues, shortcomings and remaining TODOs. As a Draft proposal I would be happy to agree that it is still a work-in-progress. That is no reason to reject it, especially given the work which has gone into implementation and testing and given the broad interest in the proposal (on both sides of the fence).

I believe this is an admission by @bobsummerwill that this proposal is WIP at best. I agree with this sentiment because it has been redrafted two or three times already and we also had the Vanilla SHA3 (1095) proposal die. This would be the fourth of fifth draft of the proposal in three years.

This ECIP-1049 proposal simply is not ready in the slightest for a $3B network to consider- which is why the opposition to the proposal has suggested numerous times that the proponents should start up this idea on a brand new EVM to develop the idea. If this idea was in a more mature state, it may be applicable for the ECIP process- but instead this is a resource drain on the Ethereum Classic network- a network with scarce resources. For these reasons, the proponents of ECIP-1049 should really take a look in the mirror and understand the damage they have caused this network over the past three years by ignoring many steps in the ECIP process to push this proposal on the network at all costs.

I look forward to the pragmatic and honest conversation during CDC 22.

[gitr0n1n]

There was strong opposition to this proposal when it was submitted in 2019 after the first wave of 51% attacks.

After the second wave of 51% attack there was strong opposition 1.5 years ago in 2020.

There remains strong opposition in 2022 with a healthy network.

Why is this opposition to this proposal so ossified and firm?

The author/proponents are not addressing NUMEROUS concerns that have been identified by the larger community. These concerns are material and not out of bias. The proponents refuse to acknowledge the merit of the heavily documented concerns, some of which are unsolvable and kill this proposal due to the lack of compatibility to Ethereum Classic's philosophy. Due to these concerns, this proposal has been a bad idea from the original submission. Setting up a Proof of Concept of a bad idea, does not then make it a good idea for this network.

No one is arguing the proponents can't technically achieve what this proposal is striving to do, but is it a good fit for this network, its philosophy, and equitable to the existing participants on it? Many would, and have, argued that this proposal is an awful fit for this network. That is why it has been recommended many times to pursue 1049 on a different EVM and develop the idea and the supply chain around the idea.

You can not get around the argument that this will centralize the mining ecosystem under Henry Quan and EPIC Blockchain. That is what the proponents designed in back rooms (as shown in the attachments). This is a trojan horse- flat out. I am 100% in opposition of this attempt to centralize the hashrate for Ethereum Classic through the disingenuous narrative that centralized hashrate is "safer" than the mature GPU mining ecosystem Ethereum Classic operates on today.

For these completely valid reasons, I am urging the participants to Reject 1049 and let the proponents work on this on a different EVM. If they mature the idea and mechanics involved, perhaps then this might be valid to submit to the ECIP process. But it is disheartening to see @bobsummerwill spending ETC Coop funds on a proposal that is this contentious and should be executed on a new EVM as a testnet.

I wish the SHA3 proponents good fortune on a new EVM, but am 100% committed to the GPU side should a chain split be forced on this network by @bobsummerwill (funding), Alexander Tsankov (Proposer), Henry Quan (ASIC Manufacturer) that plotted this centralized capture in backrooms 3 years ago. As shown in the screen caps that recently surfaced:

[gitr0n1n]

From @iquidus :

This proposal currently appears incomplete.

It proposes changing ethash (a complete consensus engine) for keccak-256, a hashing function, and does not at all go in to detail regarding the rest of the consensus engine. As is, blocktimes, monetary policy, hashing function(s), difficulty algo, ghost protocol/uncles, DAG/caches, block validation and sealing are all part of the ethash consensus engine. Disabling or removing ethash, disables/removes ALL of this.

If the proposal is proposing to replace ethash, it should cover the entire engine, not just one componenet of it. Otherwise it should be proposed as a modification to the existing engine (ethash).

#13 (comment)

EDIT: whether this proposal introduces a new consensus engine (along side clique and ethash), or simply modifies the existing engine (ethash), is sorta crucial for implementation. No evm based chains have changed consensus engines mid chain. It's uncharted terroritory requiring massive refactoring of client software, as this behaviour was never intended. A very different scenario to modifying the existing ethash engine.

#13 (comment)

I'm aware many bitcoin forks, based on bitcoins code, have performed these kinds of changes, but can you show an example of an ethereum based chain doing the same? They function quite differently...

Regarding refactoring. At least in terms of core-geth (which makes up majority of the nodes on network). All logic assumes a single chain, uses a single engine. e.g https://github.com/etclabscore/core-geth/blob/master/core/block_validator.go#L37
A single chain, with multiple engines, and a change over, would require significant refactoring.

It would be less intrusive as a modification to the existing engine, imo.

#13 (comment)

I'm referring to implementation, which happens to be key here, given a hard fork is required, and in which the proposal is lacking in much information in terms of the changeover.

• Activation Block: 12,000,000 (approx. 4 months from acceptance - January 2021)
• If not activated by Block 12,500,000 this ECIP is voided and moved to Rejected.
• We recommend difficulty be multiplied 100 times at the first Keccak-256 block compared to the final Ethash block. This is to compensate for the higher performance of Keccak and to prevent a pileup of orphaned blocks at switchover. This is not required for launch.

A consensus breaking change such as multiplying the difficulty by 100x, can not be a recommendation, is it part of the specification or not?

EDIT: Such an intervention, would result in the chain having an artificial weight, given chains compete by weight, this recommendation breaks everyones beloved nakamoto consensus, giving the 1049 chain, a significant and unfair advantage over the non 1049 chain. Also, why 100x, how was this mysterious figure derived?

Given the scope of the change (requires hard fork) I would like to see more information on how the specification is intended to be implemented on a live network that currently uses ethash as the consensus engine. The only reference client provided, doesnt handle a changeover, and is based on a client that no longer supports the network. https://github.com/antsankov/parity-ethereum/blob/sha3/astor.json#L5 This would imply we are simply modifying the ethash engine, yet language like "the final Ethash block" would imply it's being replaced.

I, as a client dev, am seeking clarity as the proposal, as is, leaves me with questions on the intended implementation.

EDIT: Also, there's only activation blocks for mainnet, I assume given this is a PoW related hardfork, that it is intended to be activated on mordor first?

#13 (comment)

[gitr0n1n]

From @Dexaran :

I am totally against this proposal.

This proposal is counter-productive. It only proposes to change things but there are no benefits in doing so.

This will bring no improvement to the network and thus it is just an unnecessary stress for the ecosystem and a waste of development resources. This will also discourage significant part of the community and potentially lead to the ideological split that ECIP process suggests to avoid at all costs.

There are two reasons why this proposal must be rejected:

1. It is unnecessary because it does not propose to improve any aspect of the Ethereum CLassic project. It only proposes to change things without actually improving anything.

2. It goes directly against the principle of decentralization and neutrality.

This proposal goes stright against the principles of the network because SHA-3 is an ASIC-friendly algorithm. ASICs will lead to centralization of mining power. This goes against the Crypto Decentralists Manifesto.

It’s impossible to achieve these blockchain characteristics without the system being truly decentralized. If any aspect of the blockchain system becomes subject to centralized control, this introduces an attack vector enabling the violation of one or more of the key blockchain characteristics.

Without neutrality, the system is skewed towards one set of participants at the expense of others. In that case, it’s less likely to gain universal acceptance and maximize network value for everyone.

In case of adopting the SHA-3 mining algorithm the system will be definitely skewed to the benefit of ASIC owners. GPU mining is more decentralized than ASIC mining.

The "Rationale" of this proposal is completely improper

Enhanced security: Sha-3 is the latest member of the Secure Hash Algorithm family of standards and certified by the Federal Information Processing Standards (FIPS) [2].

Yes it is true. However it has nothing to do with the Ethereum CLassic, the network and the mining algo. This phrase is just a fact. It is not a proper rationale to change things. It is not a description of any benefit that the network will get from adopting this ECIP.

Reduced risk of non-compliance: Software agreements can have complex compliance criteria and compliance audits can be time consuming or simply a deal-breaker. Having a standardized cryptographic hash function would reduce the risk of non-compliance as vanilla Sha-3 is certified by trusted organizations and has been thoroughly vetted to obtain its place in the Sha family [3].

This is fact as well. Not a rationale for changing the mining algo.

Enhanced productivity: Sha-3 is a solidified cryptographic function with certification and documentation. This reduces research and maintenance costs for engineers especially since Sha-3 ASIC chip designs are available.

ASIC-friendly mining algorithms are not what a decentralized network must adopt.

Less PoW Competition: There are no major public blockchains whom use Sha-3 for PoW. Ethereum Classic's current market status to adopt Sha-3 would make it the majority chain for its respective PoW without having to compete in existing PoW ecosystems for miners.

It is a double edged sword. Not only ETC will gain a status of "unique" mining chain but also it will become incompatible with ETH mining hardware which represents a significant part of the hashpower market.

#342 (comment)

#342 (comment)
#342 (comment)

[wpwrak]

A transition plan would also have to include an analysis of the safety of the consensus process at all stages of the transition. This analysis should not only consider technical issues immediately tied to protocol changes, but also the impact on the ETC ecosystem, in particular where it relates to mining.

Specifically, a rapid change to SHA3 would reset the ETC mining ecosystem to a state where only CPUs, GPUs, and FPGAs would be able to participate in the PoW process, but it is generally assumed that ASICs would not become available for a significant amount of time (at least for several months, maybe more than a year). While Ethash/ETChash maintains a relatively level playing field between GPUs and ASICs, SHA3 would have a very steep technology gradient, with large performance differences between CPUs, GPUs, FPGAs, and ASICs. Also, ASICs at different technology nodes would show large performance differences.

In most of the discussion about SHA3, the present "stable state" of the ETC ecosystem with ETChash was compared to a "stable state" as it is found in BTC mining, where mining technology has fully matured, and the mining ecosystem has grown as part of the overall BTC economy. A transition process to SHA3 would have a period where technology gaps would still have to be filled, and major new investment in mining equipment would be required. A "stable state" would therefore not exist until the (technological and economical) transition process has completed.

An analysis should quantify the expected performance of miners using different technologies, both in terms of hashes per equipment cost (e.g., some ETChash equipment is in the 100-200 kH/s per USD range, some BTC (SHA256) equipment is in the 5-10 GH/s per USD range.), as in terms of hashes per energy (e.g., some ETChash miners operate at around 1 MH/J, some BTC miners operate at around 30 GH/J), for calculating the hashrate that can be expected, based on the initial GPU miner population, possible FPGA mining, and then ASICs, considering projected investment into mining equipment. (Assuming here that CPU mining will be insignificant; also, the numbers in this paragraph are picked somewhat arbitrarily, and are for illustration only.)

The inrush of Ethash/ETChash hashrate from miners migrating to ETC after the ETH "merge" is likely to upset ETC mining profitability, for at least some time. SHA3 proponents have claimed that miners threatened with no longer being able to mine profitably (i.e., an excess of available hashrate would squeeze them out of the mining ecosystem) are likely to conspire to perform coordinated attacks against ETC. A transition to SHA3 would also create numerous situations where similar conditions would exist, e.g.,

• before a transition, for ASIC miners, which are not able to transition to SHA3;
• for GPU miners, if a significant amount of "cheap" FPGA hashrate may squeeze them out of the ecosystem;
• for GPU and FPGA miners, if and when SHA3 ASICs are developed, and squeeze both out of the ecosystem;
• possibly for early ASICs miners, if substantially more efficient ASICs are developed, and squeeze them out of the ecosystem.

Also, if a transition to SHA3 were to happen before the ETH "merge", and ETC would thus be in the phase where GPUs provide most of the (SHA3) hashrate, the massive increase of available GPU-based hashrate following the "merge" would affect SHA3-based ETC mining in similar ways as the ETChash-based mining will be affected if ETC is still using ETChash. This risk is in addition to the risks caused by the performance leaps during the "ramp-up" process.

[gitr0n1n]

I am asking ETC Coop to draft a document and post it to all socials acknowledging that SHA3/ECIP-1049 is contentious in nature and all previous articles published by the proponents citing SHA3 as a sure thing for ETC were inaccurate. This is to repair the damage the misinformation campaign has had on the network and its relation with GPU miners/participants. Which appears to be against the purpose of the funds Grayscale donated to the ETC Coop:

"In order to promote the growth and development of the Ethereum Classic network, Grayscale will donate up to one third of the Trust's annual fees to the ETC Cooperative."
https://etccooperative.org/posts/2020-01-19-grayscale-extends-support-of-etc-cooperative

These articles were extremely disingenuous to the retail users on ETC, GPU miners, and those following from the peripheral. As many read those articles and thought, "oh so this is already planned for activation".

If needed I'll crawl back and pull up these tweets and articles to illustrate the misinformation campaign ETC Coop executed in a disingenuous attempt to manufacture support for ECIP-1049 which has since failed the consensus building over the course of three years of technical debate.

These documented actions are those of Bad Actors, if ETC Coop is not a bad actor, then a correction article would be appropriate. A link to the CDC 15 video from October 2020 with a mention of the Rejection proposal on February 21, 2022 17:00 UTC would be great items to include in this corrective article.

Also in good faith, I'm asking @bobsummerwill to stop committing ETC Coop funds to this ECIP-1049 proposal that is a 100% chain split event, destabilizing in nature and violates the Ethereum Classic founding documents and the ECIP process. But rather commit these donated funds to non-contentious proposals moving forward; proposals that have an immediate positive impact to the well-being of the network. I'll bring this up in the meeting so we have a recording of your official response @bobsummerwill . 👍

If @bobsummerwill is unable to vocalize the intent to allocate these funds in a positive manner, I'd be happy to register a 501(c)3 and invite Greyscale and the ETC Coop Board to continue donating funds into a less contentious organization. these funds would be distributed via the ETC DAO and other decentralized mechanisms highlighted during the Community Call 010 discussion.
Ethereum Classic Community Call 010: https://www.youtube.com/watch?v=6DRZEaKkpb4

cc: @ethereumclassic/all-hands

Proof of misleading effects of the misinformation campaigns and paid articles: https://duckduckgo.com/?q=ethereu+classic+sha3

Notice ETC Coop's involvement:
Pinned on their page: https://medium.com/etccooperative/why-change-the-proof-of-work-algorithm-to-keccak-256-sha3-e327b8313824
Misinformation: https://etccooperative.org/posts/2020-02-10-etc-coop-support-switch-to-keccak256

[bobsummerwill]

So I can make 17:00 ETC on 21st February.

[stevanlohja]

@gitr0n1n Your title, content, and thread loaded with false premises and bias. Also, there's interest in others being assigned to it such as @bobsummerwill has suggested. I agree a Sha3 meeting is necessary, but definitely not a consensus-defining meeting and general reconciliation of the proposal is more productive. Dev calls shouldn't be a straw man campaign based on your own immediate feelings and conflicts of interest against the proposal. This is Github and ECIPs, not Discord so please handle your privilege here more effectively.

[gitr0n1n]

@stevanlohja Please refrain from censoring the ECIP process with your personal agenda. We have seen you executing social attacks via sock puppets on Discord, posting misleading information on the Ethereum Classic twitter and denigrating the network everywhere. You are acting and have been acting in bad faith at every step of this proposal. Closing this issue is just another example of these malicious actions as a proponent that has misinformed the general public on the state of the ECIP-1049 proposal and ECIP-1095.

Please think about how you are violating the network at every step of the way to push your single agenda.

[gitr0n1n]

@ethereumclassic/ecip-editors can we do an audit of @stevanlohja permissions? I believe he stepped down as an ECIP editor and should not have the authority to maintain this repo, especially given his recent unhinged malicious actions.

We saw a similar need when Wei Tang abused his permissions to push his singular point of view on the network. We likely should review @stevanlohja 's permission across the board and monitor his actions moving forward to see if intervention is needed.

http://ecips.ethereumclassic.org/ECIPs/ecip-1000

ECIP Editors

Current ECIP editors:

• Antoine Toulme (@atoulme)
• gitr0n1n (@gitr0n1n)
• Istora Mandiri (@IstoraMandiri)
• Mr. Meows D. Bits (@meowsbits)
• Talha Cross (@soc1c)

Former ECIP editors:

• Wei Tang (@sorpaas)
• Yaz Khoury (@YazzyYaz)
• Cody Burns (@realcodywburns)
• Stevan Lohja (@stevanlohja)
• Zachary Belford (@BelfordZ)
• Felipe Faraggi (@faraggi)

[gitr0n1n]

From @realcodywburns :

DontPanicBurns | Chippr Bots — 01/30/2022
i was shaddow tagged somewhere above. My official position is that sha3 has been an utter failure by all measures. Iohk was tricked into wasting development effort on sha3 and failed to develop their client. There is nothing to gain by switching. It is a huge risk with zero gain. The topic itself is brought up by nontechnical blowhards whenever any other progress is being discussed and it is exhausting. ignore this proposal and anyone who supports it, they are an enemy of etc. I hope this makes my position clear. lfg

[bobsummerwill]

Just to reiterate that I cannot make the meeting at its current time of 17:00 UTC.

19.00 UTC works for me.

[gitr0n1n]

Just to reiterate that I cannot make the meeting at its current time of 17:00 UTC.

19.00 UTC works for me.

Bob, I previously adjusted the time from 15:00 UTC (7am your time) to 17:00 UTC (9am your time) per your request.
#460 (comment)

To verify, does this move to 9am (17:00 UTC) your time work for you?
Or do we need to move the meeting a second time to 11am (19:00 UTC) your time? @bobsummerwill

Please confirm the desired time, I'd like to make sure this is the last change, if possible. Thanks.
FYI, 15:00 UTC is the most favorable time for the global participants. 19:00 UTC would be quite late for the Asian/Oceanic side of the world.

[bobsummerwill]

My bad.
I was confusing myself with the UTC to PST conversion.
The current time does work for me.
Thanks.

[gitr0n1n]

From @BelfordZ :

I will never support a mining algorithm change, regardless of technical merits.

I also refuse to spend more time above writing this comment on the matter. I have read all of the above discussion, reviewed each stated benefit and weakness, and thought long and hard about as many of the ramifications of this as possible. While each benefit on its own can be nitpicked over, having it's 'value added' objectively disseminated, there is 1.5 reasons that trump all benefit. It's an unfortunate reality of the world and humanity.

The main point is that ruling out collusion being a driving force behind any contribution is impossible. This is especially true the closer the project gets to being connected with financial rewards. Every contribution has some level of Collusive Reward Potential. A change that adds a new opcode has a much higher CRP than fixing a documentation typo. Ranking changes with the highest CRP, my top 3 would be:

1. Mining algorithm changes ('fair launch' being the oxymoron that we would be, for the 2nd time, subjected to)
2. Consensus changes (blacklisting addresses, dependence on anything even remotely centralized for block validation)
3. Protocol defined Peering rules (ie drop a peer if they support protests in HK type of rules)

So, going back to the 1.5 reasons that trump all...

1 - To explain by counterposition, let's assume I was a large supporter of a mining algo change. What's to say I've not been paid by ASIC maker xyz to champion this change, giving them the jump on all other hardware providers?

Spoiler: nothing.

0.5 - How can something which is designed to be inefficient be changed in the name of efficiency WITHOUT raising suspicion?

Spoiler: it can't.

To conclude, this might be a great proposal... for a new blockchain... And I urge you to reconsider this PR, as I believe there are more useful ways of spending development efforts.

#13 (comment)

[gitr0n1n]

re: current logic behind this proposal.

So if we state the logic of the proponents out in steps:

Create Dooms Day Event:

1. GPU miners are a risk to Etchash future. They can mine anything, so they're not loyal. Bad hashrate.
2. We need to rely on ASIC to secure this network
3. Ethash/Etchash have known ASIC in the hashrate. But these aren't the ASIC we want- so they're now enemies of the network as well.
(so now anyone mining ETH or ETC today is a bad actor)

Save Network from Dooms Day Event while making $$$:

4. Since GPUs are enemies of the network and ETHash/ETChash ASIC are enemies of the network: ETC has no friendly hashrate and is in dire straights. (Fearmongering)
5. However if you change to SHA3- we will make ASIC for you. And we are friendly. (White Knighting by Epic Blockchain and friends)
6. While you come over to our friendly hashrate (we promise we won't 51% attack you), we can apply arbitrary `ratios` of consensus.
7. In the end, you will all be stuck buying our SHA3 ASIC, or we will create these chips and mine for ourselves to assure our ROI is met if there is not purchasing demand. (Inflation capture by Epic Blockchain)
(Risk pushed on the network for Epic Blockchains benefit.)

[antsankov]

I will attend the discussion on 2/21/22 (Monday next week) at 17:00 UTC time to give updates on the ECIP-1049 proposal.

Also, Bob Summerwill is now a co-author of the proposal and its current champion, see #394 (comment)

[gitr0n1n]

I will attend the discussion on 2/21/22 (Monday next week) at 17:00 UTC time to give updates on the ECIP-1049 proposal.

Also, Bob Summerwill is now a co-author of the proposal and its current champion, see #394 (comment)

Thanks for the response @antsankov . We will get that change of Champion on record on the CDC 22. You can expect a similar discussion format like the CDC 15, where everyone will have a chance to communicate. The goal here being to either get this proposal in a state where:

• its proponents set a block and trigger a contentious chain split via a new fork SHA3 ASIC network. Simple Logic: Etchash GPU miners and Etchash ASIC miners will not support this 1049 proposal. Additionally, Ethash GPU miners and Ethash ASIC miners will join the current Etchash miners to help reinforce/secure the non-fork Etchash network moving forward, or;

• reject and the small group of 1049 proponents can stop hijacking every ETC conversation and call, allowing the rest of the network participants to move forward building on top of a stable, mature PoW algo ecosystem in Etchash (which already has the keccak cryptography embedded in it).

See you Monday.

[DonaldMcIntyre]

@gitr0n1n you are conflating a technical ECIP process issue with your personal SHA3 change politics. This developer meeting was called to address a possibly stale ECIP (ECIP-1049) because you argued that 3 years had passed since its proposal, it is still in draft mode, that supposedly the champion did not make any changes or work on it all this time, and thus it had to be moved to accepted or rejected, where rejected is your preference because of your personal politics.

Regarding the ECIP technical issue, your argument that the ECIP has to be moved to rejected because the champion has not worked on it and that the community issues have not been addressed is false:

• ECIP-1049 is the most currently debated change in the ETC ecosystem.

• The new champion, Bob Summerwill, has not only been defacto champion of 1049 for several years, but he has invested money in development to advance it through the ETC Coop.

• All developer teams have worked on it and even integrated it into their clients.

• All developer teams have tested it on the ETC testnets.

• There are plenty of videos and community calls about the SHA3 change in ETC that show that this is the most important and expected change in ETC.

• In fact, the last community call was precisely about ECIP-1049 and a proposal to add "hybrid proof of work": https://youtu.be/HQ9IKu3PVkA

In summary: ECIP-1049 is not only alive but the most active ECIP in the ETC ecosystem. To move it to rejected as you propose would not only be wrong and unethical, but a violation of the ECIP process.

Regarding your personal politics about SHA3 and your opinions, you can keep on arguing on social channels. To use an ECIP process technicality is not the way to take down a proposal just because you don't like it.

Again, the politics of the SHA3 change belong in the debate forums, a call to reject ECIP-1049 has to be on the grounds of a clear rejection of it signaled from all stakeholders, but that is far from true.

[gitr0n1n]

@gitr0n1n you are conflating a technical ECIP process issue with your personal SHA3 change politics. This developer meeting was called to address a possibly stale ECIP (ECIP-1049) because you argued that 3 years had passed since its proposal, it is still in draft mode, that supposedly the champion did not make any changes or work on it all this time, and thus it had to be moved to accepted or rejected, where rejected is your preference because of your personal politics.

Regarding the ECIP technical issue, your argument that the ECIP has to be moved to rejected because the champion has not worked on it and that the community issues have not been addressed is false:

• ECIP-1049 is the most currently debated change in the ETC ecosystem.
• The new champion, Bob Summerwill, has not only been defacto champion of 1049 for several years, but he has invested money in development to advance it through the ETC Coop.
• All developer teams have worked on it and even integrated it into their clients.
• All developer teams have tested it on the ETC testnets.
• There are plenty of videos and community calls about the SHA3 change in ETC that show that this is the most important and expected change in ETC.
• In fact, the last community call was precisely about ECIP-1049 and a proposal to add "hybrid proof of work": https://youtu.be/HQ9IKu3PVkA

In summary: ECIP-1049 is not only alive but the most active ECIP in the ETC ecosystem. To move it to rejected as you propose would not only be wrong and unethical, but a violation of the ECIP process.

Regarding your personal politics about SHA3 and your opinions, you can keep on arguing on social channels. To use an ECIP process technicality is not the way to take down a proposal just because you don't like it.

Again, the politics of the SHA3 change belong in the debate forums, a call to reject ECIP-1049 has to be on the grounds of a clear rejection of it signaled from all stakeholders, but that is far from true.

Please note, prior to this CDC 22 meeting being called- the proposal was abandoned after three years. The fact that the proponents are now recognizing they have not been following the ECIP does not negate the need for the call.

It's great the @bobsummerwill has volunteered to act as the champion for this abandoned proposal. But that only happened after this meeting was put on the docked.

I have not concealed that I am personally in opposition of ECIP-1049 becuase i believe its a very bad idea from its foundation and has violated the ECIP process at many points in its existence, including the proponents attempt to push this incomplete and vague proposal to Accepted status in September 2020- which triggered the CDC 15 call to push this to Draft/Rejected status if the concerns weren't addressed. These concerns have not been met since that meeting.
#382 (comment)

However, none of those personal opinions relate to the proponents failure to follow the ECIP process at many different stages. As cited, there are numerous reasons this proposal is in violation of the ECIP process- an abandoned proposal with no champion was just ONE of many reasons.

The reason for "Rejected" status under this clause is that the champion has not met this requirement during the three years: "the champion provides revisions that meaningfully address public criticism of the proposal". Rather, the champion has ignored much valid criticism and abandoned the proposal. https://ecips.ethereumclassic.org/ECIPs/ecip-1000
The referenced champion in this clause being the absent @antsankov .
#460 (comment)

[gitr0n1n]

Note, the formal PR to move ECIP-1049 to Rejected status has been drafted:
#465

[ETCpunk2]

@gitr0n1n I was able to grab this before you deleted it the other night in discord, so that we can discuss its full implications with the community present.

Call to Action:
Ronin has threatened the network and community multiple times over the last few months, attempting to hold it hostage to his will, which is to maintain the current etchash algorithm. While he himself may not be a "bad actor" as he calls others, his actions are that of a terrorist conducting large scale extortion. My motion is that he should cease making open threats against the community, should maintain an willingness to cooperate on whatever community decisions get made, or else his role as an ECIP Editor be revoked immediately and that he be ejected from the community social channels.

Evidence:

Point #1
You have previously claimed that ETC is a totally decentralized network, and yet in the same chat room you now express (see picture below) concern about the Coop being the only development group in the community. The timing and contradictions in your actions are very confusing and you must clarify them.

• Is there a reason why you weren't addressing this concern at any point in the last 12 months, since the withdrawal/dissolution of Core and Labs? What about when IOHK re-entered the community and you/pistov/et al successfully drove them back out, leaving Coop on their own again?
• What is it about this proposal that has you so worried about having a decentralized development community that you suddenly, without discussing it in the community, arrange a backdoor contingency of private and unknown developers who, apparently are instructed to support the network ONLY if this proposal goes through?
  see this comment from you: https://discord.com/channels/223674353001168906/750122538629070888/944800521997406299

My thoughts on Point #1:
It surely can't be Bob that concerns you, because Bob has been in charge of the Coop as the only active dev group remaining in the ecosystem for over a year (I don't count IOHK as they were only engaged here for a few months before withdrawing). The Coop has been the only group maintaining ETC client software for quite some time now. Throughout a window of time in which the ETC developers have been about as centralized as you can possibly get, Bob, as the leader of the Coop, has shepherded his power and authority with humility, open-mindedness, and transparency. They have been responsible for two successful hardfork upgrades in that period, they put out thorough quarterly reports, and they communicate frequently with informative monthly newsletters.

I don't see a single piece of meaningful evidence that Bob and Coop have bad intentions, underhanded dealings, or malevolence towards ETC (including toward you). You have had over a year to communicate your concern and put together an action plan. I don't feel this is necessary to make my point, but I'm pretty sure I could look through discord and GitHub and find that you were VERY active in pushing IOHK out of the community.

My opinion on the contradictions in your newly disclosed actions to procure a "backup" dev team to assist you in maintaining the network in the event you were unsuccessful in stopping ECIP-1049 is that by you doing said actions, you have now demonstrated that you are in fact vying for centralized control of ETC. If you weren't, you would have been pushing to start a secondary and tertiary dev group this whole time. But clearly it is only this specific proposal that does not suit your plans; you are unable to pressure Coop into compliance, and have now gone to extremes (in terms of contradicting yourself), to get your way. It is pure hypocrisy.

Point #2
I have pointed out previously that ETC is currently extremely centralized in hashrate, pools, developers, and even the list of exchanges. I am in full support of creating and/or inviting more dev groups into the ecosystem as that would be a boon for the network. However, it goes without saying that if a dev group wants a warm welcome, there should be an open conversation with the community on the matter well ahead of time.

• Who are these developers?
• What is their motivation for working on ETC?
• What segment(s) of the ecosystem are they interested in? Core, Defi, Meta, NFTs?
• What if ECIP-1049 is approved? To what degree will that affect their interest?
• What if ECIP-1049 is denied? To what degree will that affect their interest?
• Funding source?
• Are their team members self-doxxed like many of the other great devs in ETC were?
• Would they join a community call to field questions?

My thoughts on Point #2:
If this dev team is only here to act as your personal "guard dogs" against ECIP-1049, then I will not support their participation in the community or on ETC. But if they are willing to answer those questions above, speak to us on a community call about their interesting and timely interest in ETC, and most importantly, they are willing to stick around regardless of the outcome ECIP-1049, then it may in fact be a good idea to get them involved here.

Summary:
Since you have now publicly announced a back door agreement with an anonymous dev team that will provide "redundancy" to the network, only if 1049 gets approved, and you have procured this arrangement in secret without transparency to the community, it is clearly unacceptable behavior that goes well outside the bounds of the community guidelines and

-- I motion that further efforts to hold the community hostage should be returned with an immediate removal of your ECIP Editor status and ejection from community channels. --

You are behaving contrary to the Founding Principles on decentralization that you claim to embody so much. Your call on today is unsubstantiated, divisive, a waste of all our time, and avenue for you to weaponize your status as ECIP Editor. If this dev team that you have procured was honest, then they would introduce themselves and face the music of inquiry; and you certainly wouldn't attempt to use them as leverage against the Coop (the very folks who have been working hard to keep this chain going amidst a relentless onslaught of challenges) and ECIP-1049 proponents.

Re: "redudancy"
In discord @gitr0n1n claims that I am against redundancy. I am not. That's the point of decentralization, to have so many point of redundancy that the network can't fail or be broken.

I am posting my response to him here to the conversation congruent, as well as to address that false logic:

[gitr0n1n]

ETC Core Devs Call 22 - Proposed Rejection of Keccak256 ECIP-1049 Call Results
https://ethereumclassic.org/blog/2022-02-23-core-devs-call-22-ecip-1049-call-results

#465
ETC Core Devs Call 22 Recording: https://www.youtube.com/watch?v=lpdZgsAbPXo

ETC Core Devs Call 22: Conclusion

• A new ECIP-1049 Champion was selected in Bob Summerwill. The old champion, Alexander Tsankov has stepped down from the proposal stating he is too busy to champion this proposal.
• It was agreed by the ECIP Editor r0n1n and the new Champion of ECIP-1049, Bob Summerwill, that the ECIP-1049 proposal needs a material rewrite to meet ECIP-1000 compliance and remain in Draft status.
• The new Champion vocalized intent to bring the ECIP-1049 proposal up to ECIP-1000 standards within the coming months during 2022.
• The ECIP Editor and others on the call felt it was reasonable to afford the new champion time to clean up the ECIP-1049 proposal, as it was vocalized that undocumented technical work has been done by the champion's paid staff.
• The ECIP editor vocalized intent to leave PR 465 open to push this proposal to Rejected status should this proposal continue to sit in a state that violates the ECIP-1000. This comes after the CDC 15 meeting where Alexander Tsankov, the old champion of this proposal, vocalized intent to update the proposal after a failed push to Accepted status in 2020 and did not follow through with the ECIP-1000 requirements regarding criticism and dissenting opinions to the ECIP-1049 proposal from the community.
• It was recommended to split the ECIP to multiple ECIPs to align with ECIP-1000 guidelines; technical work, transition strategy, social consensus building, activation plan. These were some examples provided to the champion.
• The elephant in the room on ECIP-1049 has been a documented lack of consensus. The ECIP-1049 proposal aims to displace the current mining ecosystem. This is a violation of the ECIP-1000 in itself.
  Pushing contentious hard forks on the network is a violation of the ECIP-1000 process. It's unlikely the ETChash mining ecosystem will update nodes to this proposal should a hard fork be attempted. Many in the community; mining pools, miners, developers, core development teams, community members have vocalized support for the non-fork ETChash side of a contentious hard fork should the proponents of ECIP-1049 push a contentious hard fork on the Ethereum Classic network.
• The ETChash mining ecosystem was assured continued support from community members should any centralized actor attempt a contentious hard fork on the Ethereum Classic network.
• The opposition to ECIP-1049 has provided the new champion material criticism of ECIP-1049 to address during the champion's material redraft of the proposal.
• The proposal will be reviewed at a later date for ECIP-1000 compliance. Should compliance not be met, this proposal will move to Rejected status. Note: the Champion can always revive a Rejected proposal when ECIP-1000 compliance is met.

Note: This ECIP appears to be contentious, as documented in all the previous threads and recordings. It has a high-probability of a contentious chain split between the Mining Ecosystem on ETCHash (GPUs and ETChash ASICs) and the proposed new mining ecosystem on Keccak256 (FPGA & KEC ASICs).

New Proposal Champion:
Given the new champion is active, Bob Summerwill is provided time to update the ECIP-1049 proposal to be ECIP-1000 compliant. This was recommended in October, 2020 to the previous champion after Core Developers Call 15, but did NOT happen. The hope is with a new champion we will see compliance with the ECIP process.

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

Some comments from Bob Summerwill on the undocumented technical work from his staff:

• Support for Astor already integrated in Besu. There is a pull request for core-Geth (and blocks successfully mined on Astor), but some rearchitecting needed to make that clean enough to integrate.
• The transition is where more client work is needed (ie. having a Testnet which goes through the transition versus being Keccak256 from Genesis). More work needed on mining side software too.
• So not tons left to do, but probably needs a couple of months of focus to do it right. Note - this is the technical work.
• Roll out via testnets, all the social layer etc etc is more time again, of course.
• I was asked where June, 2022 was feasible (end to end). I think that is a pretty clear not really possible.

Here is the open PR to move 1049 to Rejected status if the new champion does NOT bring the ECIP-1049 proposal up to ECIP-1000 standards:

• Rejected Status ecip-1049

Thanks for everyone's participation. Please direct future commentary to the newest ECIP 1049 discussion thread. However, please review the historical threads. There has been plenty of technical discussion on this matter over the years.

• ETC Core Devs Call 22: https://www.youtube.com/watch?v=lpdZgsAbPXo

Note: Issues with the ETC Discord server audio was reported by numerous call participants and observed on the recording. This led to talking over/interruptions during the call. Apologies to those listening after the fact from the organizer of the call and the third-party community member who recorded the call. Future CDC calls will be held on a platform with hand raising and the ability to mute interrupting parties during the call.

Thread 394