After recent critique, I will try to host this call on Jitsi as alternative, open-source, and federated conference calling platform.

The goal of this is to crowd-source an agenda as we did in the past.

I rescheduled the call to have more time to gather proposals and out of respect for the 9/11 victims.

Hi, I would like to stick with original plan of a meeting on Sept 11 2020 @ 4 PM UTC. I have invited a number of guests for that time to attend the call, and computed a block activation strategy for this time. This fellow gitr0n1n has said in numerous places that he disagrees with this proposal, and has been harassing everyone associated with the proposal. This is another one of his ploys. Also he did not show up to the previous meeting, he can take 90 minutes to show up to this one.

Second of all, the block release schedule of 14,000,000 has been calculated to be aprox. 1 year from date of acceptance. If we move this meeting it's actively affecting the ECIP itself.

I respect GitR0n1n's concerns and will happily talk to him directly during the call and address his concerns, one by one, with actual experts in the field of supply chain and mining. However this 9/11 excuse does not justify moving the meeting. I am an american and New Yorker who knows people directly affected, and Friday is a normal working day. So I say we continue.

@antsankov
Can you answer questions on the SHA3 i have?

#342 (comment)

I will answer all questions that are presented to me on the call, but I am too busy to answer everything posted in the comments. My apologies.

Thank you for adjusting the time away from 9/11. I will be available for the September 25th meeting. @q9f I appreciate you.

Last CDC CDC Results on 8/28: #362

My vote for the agenda is to narrow in on the proposed 51% attack solutions with motions for the following:

• ECIP-1043 Review Ends September 18, 2020 ECIP-1043: Fixed DAG limit restriction #11
• ECIP-1092 motion to move to Last Call or Rejected status for deeper techincal review from Draft status ECIP-1097 Checkpointing for 51% Attack Resistance #348
• ECIP-1097 motion to move to Last Call or Rejected status for deeper technical review from Draft status ECIP-1092 51attack solution: PirlGuard & Callisto proposal #327

And no other topics to prevent distracting from the issue at hand.

@antsankov or @pc3_bot, please keep the personal attack to the discord server. This is for professional conversations. Thank you. There are plenty of criticisms to your proposal that need to be addrssed before you're ready from a proper CDC meeting. But I look forward to attending that.

As you have mentioned personally and I share the sentiment, we have more important topics to discuss than your proposal; the 51% attack solutions are the most important topic. Let's keep our focus there and we can schedule review of your ECIP-1049 SHA3 proposal at 6 weeks mark of Last Call status like was recommended in the 8/28 meeting (October 2nd). #333 (comment)

Thank you for clarifying why this meeting's date was being rushed (#333 (comment)) by pro-SHA3 participants due to their proposal timeline goals, but I don't think ECIP-1049 is more important than addressing the 51% attack solutions with our limited time on this call.

For the record, your ECIP was not present on the agenda when I recommended we don't hold the meeting on 9/11. The meeting's agenda was blank with "To Be Determined". There was no correlation to my recommendation that we move away from the 9/11 date and my opposition to your proposal. This is paranoia of a strong and vocal opposition to your proposal. Let's save that for October 9th as laid out in the 8/28 CDC. #333 (comment)

SonnyRollinsToday at x:32 PM
The sooner we can move past the 51% attacks specifically the better off we’re going to be.

Thank you for your passion to ETC and thank you for contributing to the ECIP process. We can disagree, but be agreeable. We both want whats best for the network or we wouldn't be here. Stay blessed.

When someone write TBD. It gives participants a heads up that a meeting is coming and to expect a date/time sometime later. It seems like we are making concessions on behalf of one individual who failed to read the agenda last week and attend the meeting.

These meetings aren't being sneaked around so that certain people don't show up thats just ridiculous. @q9f has done fantastic jobs setting up and leading thees calls. Besides that Ronin is the champion for the RandomX proposal. I've seen no other supporters for RandomX but Ronin. It's not anyone's fault but their own for missing a meeting.

@developerkevin please keep your comments on the topic of the 9/25 CDC meeting. Thank you. You're welcome to attack me personally in Discord.

I absolutely do no think we should move it back nearly a week. We should stick with the original date and time, as @antsankov said as well. Those are not attacks. They are facts.

Perhaps you would rather it be 9/10? Or the monday following 9/11? Some people might be mourning the death of loved ones, the scheduler made the decision to honor their mourning and the date was adjusted within 24 hours from being posted. I believe that was an empathic decision and I appreciate him for that. So we should likely just keep moving on here and discuss the agenda for 51% attacks as that is the pressing issue for the network.

But to entertain your thoughts and opinions, outside of the human element of this scheduling:
9/10 is a bit tight of a timeline for the 51% attack proposals. Are you sure that is enough time for the general public to digest these topics? The last thing we want to do is rush proposals and have inefficient meetings as you have vocally stated. So let's keep that in mind to keep this a productive meeting. Thanks!

Personaly, I think 9/25 is a good time as that is plenty of time for the public to become aware of the CDC meeting for large attendence and sufficient time to digest the 51% attack proposal presentations.

No I think we should keep it at Sept. 11, 2020 @ 4 PM UTC. One week from now is plenty of time.

Has ECIP-1092 scheduled their presentation? #364

The ECIP-1097 presentation was today #361 and ECIP-1043 is humming along in Last Call status #11 .

Assuming @Dexaran and the people presenting ECIP-1092 are comfortable presenting their proposal prior to 9/11 and think the community will have sufficient time to digest the material, then I think you can make a case for a rushed 9/11 meeting for the ECIP-1049 timeline.

But then we have to fit the ECIP-1049 discussion on top of the 51% conversation. Which is a very large meeting with high impact on the network. it will likely be one of the biggest meetings Ethereum Classic has ever held. While it might not be an exceptional day and may result in surpressed turnout, is a satisfactory date and could be poetic due to the significance of 9/11. So there is that element to the idea.

I personally am a bit more conservative and think the general public needs more time to digest the material, as they are not likely as plugged in as all of us. That is why I think 9/25 was a good alternative by @q9f. Also i think if we try to jam too many important large topic ECIPs in this meeting we will lose focus and the ECIPs at the end of the meeting will likely suffer proper discussion due to time constraints.

I will answer all questions that are presented to me on the call, but I am too busy to answer everything posted in the comments. My apologies.

Last Call - An ECIP that is done with its initial iteration and ready for review by a wider audience.
Accepted - An ECIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.

Should we be eating up time on a CDC so you can hold a Q&A on your ECIP-1049 proposal that has so many comments you don't have time to answer them? (#8 , #13 , #342)

Let's think of a productive approach to this:

Can you host your own Q&A outside of the CDC process like other development teams are doing (1097 and 1092)? This is a win/win because it does not drain the limited CDC resources to your proposal and let's ECIP participants focus on the immediate 51% attack solutions that could improve the network right now. And it allows you to host a ECIP-1049 specific Q&A meeting on 9/11.

That feels like a nice accommodation. Format thought: You could read through every comment that is unanswered, Record the response to them on 9/11 for the public to consume and digest. Then your proposal can continue to be reviewed on the October 9th date that was set on the 8/28 CDC 6 week review timeline. #333 (comment)

That seems like a fair compromise to the process and the proponents of ECIP-1049. Your proposal would not help the network for at least a year if I am reading correctly. So that is why I am suggesting we prioritize the 51% attack solutions that help in the immediate over long term approaches to network stability like ECIP-1049. @antsankov

So:
ECIP-1043 #11
ECIP-1092 #327
ECIP-1097 #348

@q9f Can you clarify what the intent of Call 13 for clear messaging to the general public?

Are we doing Q&A and engaging in Last Call for deeper review?
or
Are we voting on Rejected or Accepted status during these meetings?
or Both?

Can you explain the process for those of us that are new? Thank you @q9f. You are appreciated.

This is what i see from the 8/28 CDC results: #333 (comment)

Main action items/decisions:

ECIP-1043 fixed DAG size moved to last call with 3 weeks review period end (September 19, 2020)

• action item: instead of freezing the DAG, just freeze the size and rotate parameters (Cody, James?)
• action item: research current DAG size, project future DAG size, find suitable block number

ECIP-1049 Keccak256 and ECIP-1095 SHA3 moved to last call with 6 weeks review period end (October 9, 2020)

• action item: working group to merge these proposals (Stevan & Alex)
• action item: figure out and specify a proper transition from Ethash to the new algorithm

I will answer all questions that are presented to me on the call, but I am too busy to answer everything posted in the comments. My apologies.

Great @antsankov I am compiling every unanswered question for your team to address during this 9/11 Q&A on ECIP-1049. Right now I count 27 questions (#8 , #13 , #342), some are multi-pointed questions though. So we should schedule a substantial amount of time for this review as it is not my intent to dominate the entire conversation, but to give your proposal a thorough review for the general public to digest the full ramifications of what you're pushing on the network during these chaotic times.

I've posted two large lists of the questions in the ecip-1049 and ecip-1095 channels in discord and pinged you. Please read through those questions prior to the meeting so you're not caught off guard and can adequately address every concern on the call itself. They were sourced from these SHA3 threads (#8 , #13 , #342).

While I heavily disagree with your proposal and will be there to represent the vocal opposition, I'm looking forward to learning how your team has addressed the abundant criticism of ECIP-1049 in detail. (#8 , #13 , #342) Thank you.

@q9f i'm reading the discussion in #general occurring right now. Since we are hold a 9/11 call. Should we prioritize the 51% solutions to get them moving through the process? I am having a hard time mentally justifying prioritizing ECIP-1049 (a one year plus roll out) over the 51% attack solutions that address the immediate threat to the network:

So high priority ECIPs:
ECIP-1043 #11
ECIP-1092 #327
ECIP-1097 #348

Once these three ECIPs are in motion we have ALL year to discuss moving the network to SHA3, as the network will then be out of the current fire.

Do any of the current ECIP participants feel that the priority should be on these three 51% attack ECIPs right now and we shouldn't be rushing a miner algorithm change before addressing these solutions and stabilizing the network?

Maybe my logic is flawed regarding this issue. Feel free to explain why.

@q9f i'm reading the discussion in #general occurring right now. Since we are hold a 9/11 call. Should we prioritize the 51% solutions to get them moving through the process? I am having a hard time mentally justifying prioritizing ECIP-1049 (a one year plus roll out) over the 51% attack solutions that address the immediate threat to the network:

So high priority ECIPs:
ECIP-1043 #11
ECIP-1092 #327
ECIP-1097 #348

Once these three ECIPs are in motion we have ALL year to discuss moving the network to SHA3, as the network will then be out of the current fire.

Do any of the current ECIP participants feel that the priority should be on these three 51% attack ECIPs right now and we shouldn't be rushing a miner algorithm change before addressing these solutions and stabilizing the network?

Maybe my logic is flawed regarding this issue. Feel free to explain why.

The priority is the "51% attack protection", in which the ECIP-1043 #11 is the most favorite at the moment (there are no objections till now).

But sure, there should be no rush. The proposal championings and discussions can run parallel, if the capacity of the developers/network participants allow it.

ECIP-1043: Just some findings regarding the DAG size.

• ethminer 0.17.0 on my 4GB Radeon RX 470 is limited to epoch 351 (3.74GB)
• claymore 15.0.0 on my 4GB Radeon RX 470 is limited to epoch 351 (3.74GB)
• teamredminer 0.7.10 on my 4GB Radeon RX 470 is limited to epoch 382 (3.98GB)

The theoretical possible limit should be epoch 383 (3.99GB), however, we didn't manage to find a miner that is capable to actually deal with that.

Current epoch is 372 (3.91GB) at the time of writing.

So we have a soft limit of around 351 and a hard limit of 383. Therefore, we already entered the critical phase of DAG size.

B: (current spec) stop growth at block 10,000,000 (DAG is about 3.6GB then)

This really needs to be updated. It looks like this is no longer a viable option.

Edit: and block 10M passed a while ago. We should freeze on epoch 382 which starts on block 11_460_000.

@q9f I would suggest to test Phoenix Miner 5.1c as it seem to be the most effective from my previous experience.

Phoenix does not work on my operating system.

ECIP-1049: Just some findings on interoberability - I did some research on the implications of vanilla Sha3 and I would strongly encourage to go for Keccak256 rather than Sha3.

The main reason is having an OPCODE 0x21 SHA3 is very unlikely to convince the Ethereum Foundation community to realize and accept. Going solo with such an OPCODE on Ethereum Classic would mean we would have to fork all tooling including Solidity compiler.

As an alternative, we could implement a SHA3 precompile but that's also unlikely on Ethereum Foundation network. That way we might lose the freshly gained protocol parity indefinitely. Adopting Keccak256 does not only reduce the complexity but also retains highest compatibility between these ecosystems without much effort as the OPCODE 0x20 KECCAK already exists for both chains and no further tooling would be required.

just a generic concern around adding opcodes, if we added 0x21 SHA3 and ETH adds 0x21 as something else then we will face some issues with tooling across the ecosystem as well.

just a generic concern around adding opcodes, if we added 0x21 SHA3 and ETH adds 0x21 as something else then we will face some issues with tooling across the ecosystem as well.

That's exactly what I tried to say. ref ethereum/EIPs#2951

meeting was just moved to Discord because of a security flaw in jitsi https://discord.gg/bNgqUb7

^ will continue at 4:20 pm UTC. please get setup.

sucks jitsi didn’t work out but the moderation in the other discord prevents many of the team from joining the call.

We can make Jitsi work if we have our own server. This enables us proper moderation roles and tools as far as I understand.

I'm sorry that I didn't look into that earlier.

Hello, I just have to lift the opposition to the Algo change that some people wants to see here.

In my eyes, this is very clear; and i don't know who you panic and cry for a CHANGE of algo.

We have to keep in mind that a BIG part of ETH mining is ASIC rigs, we know that there are some different ASIC creators that can resume the production if its needed.

WE ALSO KNOW that ETH have a thing called ProgPOW in the making, wouldnt this alone make 51% attacks nearly impossible???

What im saying is straight forward and not hard to get.

Dont change algo, you will regret it. Upgrade the system to prevent 51%:s, but dont miss out on the big network change with ETH 2.0 Rollup!!!

I am suggesting to make the Call 14, 25th of September, on ETC discord as well: https://discord.gg/3J7ztm. @q9f I need your confirmation to update your first post here. Thank you.

Yes, let's do discord.

I am suggesting to make the Call 14, 25th of September, on ETC discord as well: https://discord.gg/3J7ztm. @q9f I need your confirmation to update your first post here. Thank you.

Your link is dead. I believe this is an active invite: https://discord.gg/hQs894U. I've updated a PR for the website's blog.

Given that ECIP-1049 has dominated CDC 11, 12, and 13. It's probably great to allow other proposals to be addressed within the limited 90 minute call on CDC 14 @q9f:

• ECIP-1092
• ECIP-1096
• ECIP-1097
• ECIP-1099
• ECBP 1100

I've scheduled a 120 minute max CDC 15 specifically to talk about ECIP-1049. The author has agreed to show up to that call. So continued conversation on ECIP-1049 can likely wait a week to let all these other proposals have a chance to be discussed.
#382

I am suggesting to make the Call 14, 25th of September, on ETC discord as well: https://discord.gg/3J7ztm. @q9f I need your confirmation to update your first post here. Thank you.

Your link is dead. I believe this is an active invite: https://discord.gg/hQs894U. I've updated a PR for the website's blog.

Yes, @gitr0n1n, it got invalid. I took your shared one. cc @q9f

I won't be able to speak at the 14 Dev Call, but will be able to listen. However on October 2nd @ 4PM UTC, I will be doing a full call that will be devoted entirely to the subject of ECIP-1049 and Keccak256.

Ideally this call can be entirely focused on PirlGuard and Mess, and which one is a better approach.

The 14th's call link was updated again.

Please can we add "ECIP 1097: Checkpointing based 51% attack resistance (Draft)" to the agenda, @q9f?
Thanks!

Good point @bobsummerwill I also see 1094 was proposed, but not sure where that one is at.

Agenda

51% Proposals

• ECIP 1092 51-percent attack solution PirlGuard by Callisto (Draft)
• ECIP 1094 VeriBlock Proof-of-Proof 51%-Attack Prevention (Draft)
• ECIP 1096 51% Attack protection system based on Bitcoin Merged Mining (Draft)
• ECIP 1097 Checkpointing based 51% attack resistance (Draft)
• ECIP 1099 Calibrate Epoch Duration (Last Call)
• ECBP 1100 Modified Exponential Subjective Scoring (Draft)

OK, removed ECIP-1049 and added the other proposals 👍

I'm assuming that the authors of the proposals are informed, otherwise this will be confusing on the call.

Thanks for adding ECIP 1096. We'll be there to present and respond to questions. What is your idea? How much time will be assigned to ECIP 1096 ?

Updated the block numbers for 1099:

• For the Ethereum Classic main network: ETCHASH_FORK_BLOCK := 11_700_000 (Epoch 390)
• For the Mordor Classic test network: ETCHASH_FORK_BLOCK := 2_520_000 (Epoch 82)

Which basically means 4 weeks for Mordor and 8 weeks for the Classic main network.

We will reevaluate this in tomorrow's call.

Thanks for adding ECIP 1096. We'll be there to present and respond to questions. What is your idea? How much time will be assigned to ECIP 1096 ?

So, first thing will be finalizing ECIP 1099 which is in last call and we need to update the block numbers to allow for Besu to implement the changes and second part will be discussing the "51% proposals."

In the end we will have to decide for one as we most likely will not implement all of them and the core devs have to evaluate if it's sufficient to just implement one protective measure or whether we need multiple.

The community sentiment appears to either favor 1092 "Pirlguard" by Callisto or the 1100 "MESS" proposal by the ETC Core working group. The discussion on 1092 was cut off last time, unfortunately, so we will start with that and also allow for comparing with the other proposals.

What we could do, because it's five different proposals, that I ask 3-4 questions that each proposal champion has to answer and this will allow us to create some matrix of what the proposals do, what they don't do, and what they require. I'll come up with something by tomorrow.

Will the Berlin HF eips be included in this fork or will there be another later fork for bls12-381 and simple subroutines?
Or do we need a thread for the HF separate from this stream?

@realcodywburns There has been no discussion about ETH Berlin changes for ETC to my knowledge.
I doubt that there are any kind of priority for them given everything else we have on our plate.

I'm unsure if we should have the Veriblock ECIP on the table for this call as they have not presented their proposal, but plan to. I've been in contact with Max.

He says, "We are writing up a ETC-focused "what is PoP and how will it protect ETC" layman's explanation article which we want to publish prior to the call [presentation]."

Based on the fact they haven't presented, although having much time to do so, I'm unsure if it would be fair to them to measure a consensus on moving their ECIP either way in the process. They plan on presenting their solution mid-next week as noted by Max here: #360 (comment)

To be honest based on what I've seen I see the MESS solution as being the most effective out of the bunch. It also seems it would be much easier to implement into Besu given Chainsafe's affiliation in its creation. Mess seems much less complex and more in line with ETC's decentralized manifesto and declaration of independence, more than nearly all the others which either introduce layers of unnecessary complexity i.e. through new mining mechanisms, adding validators which will require some sort of on-chain governance mechanism (also we've maintaining a network with validators become a bit difficult on Kotti), or relying on a trusted third party whether it be another network or validators.

By the way thanks for coordinating this call Afri! .

@bobsummerwill in your absence prior to the attacks we had initial discussions on berlin. Then it was delayed on eth due to geth being the majority client and was postponed until the fall for eth. But it looks to still be un planned for eth so no real rush.

What we could do, because it's five different proposals, that I ask 3-4 questions that each proposal champion has to answer and this will allow us to create some matrix of what the proposals do, what they don't do, and what they require. I'll come up with something by tomorrow.

I like to see the following questions answered during the call (1 min/proposal max):

• does it require a hardfork? (backwards-compatibility)
• does it break nakamoto consensus? (one cpu, one vote)
• is there a specification for ethereum classic available? (some proposals come from other ecosystems)
• is there a transition for activation specified? (does it need one? activation block? smooth transtion?)
• is there any implementation or simulation available? (python, go, crystal, c++, rust, ...)
• are test cases available that can be used by the client teams?

I will add all answers live to the matrix: https://hackmd.io/@q9/etc-dev-14

ECIP 1096 :

1. does it require a hardfork? (backwards-compatibility)
   (edited) No. It's possible to implement it without a hard-fork, and still get a high protection from almost all attacks. If you hard-fork you can get greater protection against certain attacks.

2. does it break nakamoto consensus? (one cpu, one vote)
   No.

3. is there a specification for ethereum classic available? (some proposals come from other ecosystems)
   The ECIP provides guidance on implementation, but it's not 100% complete. We could finish it in a short time if the ETC community is really interested in moving forward.

4. is there a transition for activation specified? (does it need one? activation block? smooth transtion?)
   We haven't yet specified. It can be smooth or drastic. The proposal enables the level protection to be gradually incremented.

5. is there any implementation or simulation available? (python, go, crystal, c++, rust, ...)
   are test cases available that can be used by the client teams?
   No.

I would also like to mention that ECIP 1096 provides some key benefits, such being a decentralized solution.
And it could also allow to build pre-compiles in ETC to access the Bitcoin headers for further interoperability, as the Bitcoin headers will be attached to ETC headers in an censor-resistant way.

To be more precise on (1) I should add:

If ETC wants the solution to be fully decentralized, then some part of the subsidy must be channeled to visibility proof miners by a hard fork.
The payments can also come from a treasury (i. .e ecip-1098). In that case the best implementation is having a federation (which can be either RSK's current federation or IOHK proposed federation) to issue the visibility proofs.

Thanks everyone. Kevin has a recording.

Here are my rough notes:

• ECIP 1049 was skipped, remains in "last call" for another two weeks, please join the breakout call next week to further discuss keccak mining algorithm, see ETC Core Devs Call 15 - ECIP-1049 Breakout Session Keccak-256 #382
• ECIP 1099 remains in "last call" but new block numbers (pushed back to allow besu to implement it), this will move to "accepted" next friday unless you raise your concerns, core developers start working on implementations and preparing releases, see ECIP 1099: Add block numbers and move to Last Call #371
• ECBP 1100 was demonstrated on the "messnet" testnet, it moves to "active" with a mordor block number for testing, mainnet decision depends on testnet progress, no mainnet block number yet, ECIP/ECBP-1100: MESS: status update, block numbers #385
• ECIP 1092 was skipped, nobody spoke in favor of it
• ECIP 1094 was skipped, there will be a presentation by max next week
• ECIP 1096 was discussed
• ECIP 1097 was discussed, requires either a hardfork or optinally a soft fork, we would have to chose trusted parties for committee

Important items are bold.

@SergioDemianLerner I have a question regarding your comment below.

The payments can also come from a treasury (i. .e ecip-1098). In that case the best implementation is having a federation (which can be either RSK's current federation or IOHK proposed federation) to issue the visibility proofs.

Hypothetically if there was some collaboration between the two, would there still be a required tax on mining rewards to pay for "visibility proof miners?" I recall you saying it is possible to use your solution without the need to give any portion of the miner's block rewards to visibility proof miners—would that make this proposal non viable? Would the subsidy provided be temporary and what are the reciprocations of not providing any subsidy to them?

To be honest, I don't think taking away a portion of block rewards to subsidize third party miners in order to temporarily protect the network will sit well with the people in ETC, especially the ETC miners and given the many other solutions that don't involve such a mechanism and incentive to outside miners.

An audio recording for the Call 14 was added in the first post (q9f).