PSA: (short) ETC Core Dev Call: Confirm New Consensus for Aztlán Network Upgrade (ECIP-1061)
Core Meeting Details:
When: Thursday, December 5, 1 PM UTC (5 AM PST, 8 AM EST)
Where: ETC Discord Server: #ecips channel (Invite link: https://discord.gg/bGAcqq5)
Meeting information: https://github.com/ethereumclassic/ECIPs/issues/215
Why another call?
During last week Ethereum Classic participants gathered in a community-wide call to decide how to move ahead with Aztlán (ECIP-1061). The proposal would either move to the “last call” stage or not. In the time since, many new social issues, GitHub spam, accusations of maliciousness, general disrespect and negativity have since followed.
The goal of this call is to help smooth these tensions, provide clarity on the issues mentioned above, briefly address the underlying issue, and reach a new consensus on moving forward with ECIP-1061 Yingchun Edition. Also, it should be a rather short meeting.
Last Week’s Call and The Problem
Afri Schoedon (official eth_classic hardfork coordinator and typical core dev meeting coordinator) began the meeting by stating that there were two “flavors” of the Aztlán proposal up for discussion. 1061 is the first one, and the other, ECIP-1072, known as the Yingchun Edition, which was created by Wei Tang.
Afri: Let’s move Aztlán to “last call?”
Everybody: No response
Afri: Is this “don’t care” or “rough consensus?”
Everybody: Rough consensus
Wei specifically asks how long ECIP-1072 (Aztlan YingChun Edition) should remain in “Last call stage.”
*ECIP-1072 is ECIP-1061 without gas repricing, EIP-1884*
Wei: Just to be clear? Are we using ECIP 1072? How long should “last call” last?
Afri: Three weeks “last call” would be sufficient to evaluate Istanbul on EF network
Everyone: Sounds good
The above dialogue between Wei and Afri seemed to be the miscommunication that created this issue. It reinforces Wei’s position that ECIP-1072 should be the proposal moved to “last call,” not 1061.
On the other hand, what Afri did is reasonable, and doesn’t appear malicious given the fact that the development call participants had already vocally agreed on, moving “Aztlán Yingchun Edition” to “last call.” Subsequently Afri (eth_classic HF coordinator) added 1072’s contents (Istanbul w/o EIP-1884) to 1061 and moved it to “last call,” as expected. However, moving an ECIP that participants technically did not agree on, is a procedural violation in the ECIP process. Because participants were not asked to specify what number ECIP to move to “last call,” the consensus conveyed an overall agreement to move ahead with “Aztlán Yingchun Edition,” but not on how to move forward with the two ECIP flavors 1072 and 1061.
Meeting “rough consensus” is not in any way binding
Any “rough consensus” reached in these meetings is in no way binding or final. Agreements reached on these core development calls do not constitute any “official” or “final say” on decisions regarding network changes. They primarily serve as a mechanism to help signal sentiment regarding a proposal and its contents.
Always leave your feedback in the “issues” section of the proposal in the ECIP repository. This serves as the primary location where the ECIP editors and reviewers expect to find and review feedback. The ECIP process is the long-standing standardized process for we in ETCLand can discuss, review, debate, and agree (or not) on proposed changes to this open source project, its ecosystem, or operations. This is essentially the only real form of governance Ethereum Classic has.
Please show up ready to participate in this short meeting to reestablish or reach a new consensus on how to move forward with ECIP-1061 Yingchun Edition. I look forward to answering anything I can, and seeing you all in a few hours!
All the best!
