ETC Core Devs Call(s) 2020 Q3: Hardfork

[q9f]

Ref https://doodle.com/poll/yutswfi8ngdts87b

Ref https://medium.com/ethereum-classic-labs/etc-network-security-plan-fed70402b727

ETC Core Devs Call(s) 2020 Q3: Hardfork

• When: Thursday, August 20, 2020, 12pm UTC, 60 minutes max -- proposal gathering and discussion only
• When: Friday, August 28, 2020, 4pm UTC, 60 minutes max -- proposal evaluation and consensus finding
• Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda 08/28 "Focus session"

• Teams Check-in
• Overview:
  • Mining Algorithm ECIPs 1043, 1049, 1093, and 1095
  • Checkpointing and Proof-of-Actors ECIP-1097
  • Other 51% proposals, ECIP 1092, 1094, and 1096
• Focus: ECIP-1049 "Keccak256" vs. ECIP-1095 "Vanilla SHA3"
  • Consider ECIP-1043 DAG-Limit as bridging the gap
  • Reject ECIP-1093 "RandomX"
• Focus: ECIP-1097 Checkpointing through Cardano OBFT
• Focus: ECIP-1094 VeriBlock Proof-of-Proof
• Focus: ECIP-1096 Bitcoin Merged Mining on Rootstock RSK

Audio recording: https://www.youtube.com/watch?v=4W1l5krLPqI

Agenda 08/20 "Overview session"

• Teams Check-in
  • Byzantine Fault
  • ChainSafe Systems
  • ETC Core (& ETC Labs)
  • ETC Cooperative
  • Input Output HK (IOHK)
• Mining Algorithm Change
  • ECIP 1049 "Keccak256"
  • ECIP 1093 "RandomX"
  • (time permitting) ECBP 1076 "Miner Signaling"
• Other Proposals addressing PoW Security
  • ECIP 1092 "Pirlguard"
  • ECIP 1094 "VeriBlock"
  • (unpublished) "Checkpointing and Timestamping"
• (time permitting) Ethereum Berlin Hardfork
  • (time permitting) EIP-2315: Simple Subroutines for the EVM
  • (time permitting) EIP-2537: BLS12-381 curve operations
  • (time permitting) EIP-2046: Reduced gas cost for static calls made to precompiles
  • (time permitting) EIP-2565: Repricing of the EIP-198 ModExp precompile
• (time permitting) Other topics that have to be addressed urgently.
  • (time permitting) Gas Range Discussion: Upper and Lower Bounds
  • (time permitting) Gas limit, backwards compatibility, slower blocks

Please post all relevant proposals below that should be discussed and evaludated.

[gitr0n1n]

Topic request pulled from development channel:

• TOP: Network security solutions. 51% Attack approaches.
• Review Ethereum Berlin for operational parity with Ethereum Classic.
• Mining Algorithm Discussion: Astor SHA3 Change, RandomX Change, Ethash remains but DAG reduction, Ethash with no change, defer discussions to a later date.
• Address the remaining blockers to ETC being considered feature complete, start constructing ETC's long term roadmap.
• Gas Range Discussion: Upper and Lower Bounds
• Gas limit, backwards compatibility, slower blocks (probably won't happen)
• Go over any inactive ECIPs, like chainID=π
• anything else?

[developerkevin]

Wait is there two calls?

[q9f]

Yes.

[q9f]

Updated the agenda. I don't think we will have time for Berlin and Gas stuff, but we can just copy the agenda over to subsequent calls and continue working on items.

Note that we have two calls, the first being a technical discussion only and maybe some opinion forming, and the second being (if possible) focusing on community consensus.

[q9f]

Also, some historical context can be found in #174 #187 and #194 - back then Wei missed to attend a call and blocked all further work on that. But maybe we can recover some of the work and discussion. See #339

[bobsummerwill]

Please could we get the first meeting, on Thursday 20th, moved a few hours later?
That is a horrific 5am here in the Pacific timezone.

[crazypool2019]

Is it possible to implement a hybrid PoW / MN system where the masternodes are in charge of verifying that the longest chain reported is congruent with the longest chain of the majority?

if we have 100 nodes reporting identical chains and we receive the notification of a longer chain that is "unique" then the other 100 chains should ignore this false chain

it's possible ?
(I do not agree with the algorithm change due to the events scheduled for the next 2 years, this would affect miners who made investment in equipment to support the network, it would be to turn their back on those who have been supporting ETC for years)

[ghost]

Thanks @gitr0n1n for redirecting me here.

Repeating what I wrote on the ECIP discussion page:

I think Keccak256 is the way to go for ETC. I support this ECIP-1049 100%.

Just to clarify: The change to SHA3 is not "because ETC wants ASICs". It is a) for ETC to be in a unique mining algo niche and b) to have a clean and proven algo.

Whether machines of several sorts or not can freely compete and win blocks is a different matter.

[crazypool2019]

Thanks @gitr0n1n for redirecting me here.

Repeating what I wrote on the ECIP discussion page:

I think Keccak256 is the way to go for ETC. I support this ECIP-1049 100%.

Just to clarify: The change to SHA3 is not "because ETC wants ASICs". It is a) for ETC to be in a unique mining algo niche and b) to have a clean and proven algo.

Whether machines of several sorts or not can freely compete and win blocks is a different matter.

sending to shit those who support the project is not the solution to the attack problem 51%

[stoweo112]

I ve invested 18'000 us to support ETC by purchasing Innosilicon A10 Master Pro 5g, if you change Algo I can put in the trash all money I spent to add hashing power in the ETC network, and we are thousend in the same situation, if you change algo Network Hash will just drop and our machines we purchased only for ETC, because that's what I did....It's one year salary who's going away for me, let us keep mining Etc for a while please....A10 Master Pro is a really good miner even if it's an asic, reach 450-500MH/S for 850 Watts, so please guy just think about your Cryptominers we are all supporting you, don't push us away....

[stoweo112]

Keep Ethash ppppleaseeee....!!!!

[ghost]

For me the most pressing changes based on goals of security, L2 connectivity, and backward compatibility are:

1. Sha3
2. Flyclient
3. Versionless evm and account versioning

[crazypool2019]

For me the most pressing changes based on goals of security, L2 connectivity, and backward compatibility are:

1. Sha3
2. Flyclient
3. Versionless evm and account versioning

only for u

[stevanlohja]

Related reading: https://medium.com/ethereum-classic-labs/etc-network-security-plan-fed70402b727

[crazypool2019]

Related reading: https://medium.com/ethereum-classic-labs/etc-network-security-plan-fed70402b727

o In addition, we encourage miners to signal in favor of any proposal such as SHA3 or RandomX as soon as possible (Compare: ECIP-1076).

I DO NOT AGREE WITH THE ALGORITHM CHANGE TO SHA3 or RANDOM X

and I don't know of any miner who agrees with this proposal

[wpwrak]

I would suggest to also consider PoW changes that leave the hashimoto algorithm (the "core") intact but change the PoW results through using a different DAG, similar to how Ubiq achieved some degree of separation from ET*. There would be more than one way to achieve such a DAG change: one could just change the seed value (currently 0), follow Ubiq's example, or implement ECIP-1043. The latter would also help to retain miners currently mining ETC, and accelerate the expected migration of miners from ETH to ETC. Such a change is likely to be compatible with any existing ETC mining equipment, and would "only" require an update of the mining software. (Note that deploying such an update would still require a major effort, and any solutions that don't involve touching PoW at all would therefore be preferable.)
Such a simple PoW change would provide a weak barrier, that should nevertheless leave anyone who'd facilitate overcoming it in an ethically as well as legally difficult position. This in turn should serve to limit the instruments available to future attackers.

[q9f]

do you know if Alex Tsankov is available

I reached out but couldn't get through, unfortunately. Also, ECIP-1049 needs a lot of work, so if he is not around anymore, we would need not only a new champion but also a revised proposal potentially.

[q9f]

I'm looking for volunteers that can record it and take notes on action items and decisions.

[q9f]

Ok, done.

Attendees (what I recall):

• ETC Coop
• ETC Labs
• ChainSafe
• Byzantine Fault
• Chippr Robotics
• VeriBlock
• RootStock
• a dozen community members
• Q&A through slido

Main action items/decisions:

• ECIP-1043 fixed DAG size moved to last call with 3 weeks review period end
  • 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-1093 RandomX moved to rejected
• ECIP-1049 Keccak256 and ECIP-1095 SHA3 moved to last call with 6 weeks review period end
  • 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
• IOHK did not attend the call, we skipped discussing checkpointing (ECIP-1097)
• we also skipped PIRLGUARD (ECIP-1092), we need to figure out the language barrier (see below)
• VeriBlock (ECIP-1094) and Merged Mining (ECIP-1096) will organize breakout calls to further discuss this

Misc takeaways:

• language barrier was briefly discussed, I want to investigate this further.
• Discord as platform was criticized, what are the alternatives?

Please post recordings or more detailed notes if you have.

[SergioDemianLerner]

Thanks @q9f for the opportunity to introduce VisibilityProofs. Let's coordinate to do the breakout call.

[developerkevin]

Meeting notes and documented action items as well as a audio/video from today's meeting. Thanks @q9f for leading it. Thanks @SergioDemianLerner for explaining your proposal. Feel free to coordinate with me, on your own time, to set up a breakout meeting to discuss your ECIP and take questions

We would like to give you an adequate amount of time to explain your proposal and help stakeholders understand it's practicality. Feel free to contact me on discord, so we can arrange a date and time. Or DM me for my email address.

[developerkevin]

B### Meeting Recording + Action Items

Exporting Q3 Hard Fork Meeting from Final Cut Pro. Will have it uploaded onto YouTube in the next hour or so. Also, I am creating a shared Google doc re: "Action Items" discussed in today's meeting. Keep your eyes peeled for announcements on ETC Co-op Twitter, ETC Main Twitter, or ClassicIsComing Twitter Account. "Action Items" will also be distributed in the same manner.

[slavserver]

Are you seriously? Now, in no case should the algorithm be changed, ECIP-1092 only (PirlGuard)! I hope you understand why this should not be done .. In the future, it is necessary to monitor ECIP-1092, I'm sure everything will be fine, and only then, gradually, you can think about changing the algorithm, at least in a year. And I am 90% sure that there will be no need to change the algorithm.

[NickNick-tech]

If it is not necessary, changing the algorithm only causes mistrust. In this situation when there is a possibility that some part of the 100 TH/s (4 GB cards that mine ETH, which due to the size of the DAG file will not be able to do it from December 2020) switch to ETC, changing the algorithm to me personally looks like sabotaging ETC. Why has Bitcoin never changed its algorithm and thus piss on its miners? There are even other solutions (in addition to increasing hashrate) to solve 51% attacks (Pirlguard, checkpointing,...).
If ETC goes Asic friendly, I am not interested anymore. I am a small GPU miner with no intention to buy Asic, I think most of the network will agree me. I love decentralization, Asic is against that.

[crazypool2019]

If it is not necessary, changing the algorithm only causes mistrust. In this situation when there is a possibility that some part of the 100 TH/s (4 GB cards that mine ETH, which due to the size of the DAG file will not be able to do it from December 2020) switch to ETC, changing the algorithm to me personally looks like sabotaging ETC. Why has Bitcoin never changed its algorithm and thus piss on its miners? There are even other solutions (in addition to increasing hashrate) to solve 51% attacks (Pirlguard, checkpointing,...).
If ETC goes Asic friendly, I am not interested anymore. I am a small GPU miner with no intention to buy Asic, I think most of the network will agree me. I love decentralization, Asic is against that.

I was banned from discord for opposing SHA3, according to the developers in the general channel you can talk about SHA3, but if you are a GPU miner and you oppose SHA3 you can only express it in the mining channel, the change to SHA3 has a clear interest economic of a few leaving aside the interests of 5700 miners who currently support the ETC network, as a form of rejection of SHA3 a few miners withdrew our "filthy" hashrate from the ETC network and took it to eth.crazypool. org, everyone who is against the change to SHA3 is welcome at eth.crazypool.org

[iUNeIV]

Why not limit the DAG to a lower value of 4GB to be friendly of AntMiner E3 "LOL" Why not propose the option of Masternode + POW To avoid 51% attacks

A masternode with a 250 ETC node

1. It will increase the value of the ETC
2. Increased protection against attack 51%

[mikeyb]

Why not limit the DAG to a lower value of 4GB to be friendly of AntMiner E3 "LOL" Why not propose the option of Masternode + POW To avoid 51% attacks

The ECIP for the DAG does propose this. "LOL"

A masternode with a 250 ETC node

1. It will increase the value of the ETC
2. Increased protection against attack 51%

Write up a proposal, I think you are the only one who wants this though.

[crazypool2019]

There is no use making payments after 80k confirmations, this because the payments sent during the attack (reorg) disappeared, the balance did not reach its destination or return to the issuer, then
90k confirmations => does not work
80k confirmations => does not work
10k confirmations => does not work
This happens because the output of the coins was registered from a wallet_A to a wallet_B, but after that registration a "reorg" was generated where the TXNs do not exist, the coins sent are lost, these coins never reach their destination and these coins also do not return to the issuer .... and you want to wait a year to implement SHA3 instead of implementing pirlGuard and / or checkpoints or even inject hashrate from nicehash with your resources (developers), you should do this today .. ... you (developers) are children playing developer ..... ETC was better off without you. good luck kids!

[q9f]

Just because as a moderator of these calls, I usually get all the beating, I want to transparently document that it was not my idea to put RandomX on the agenda, but the proposal's author himself.

[gitr0n1n]

This is a copy and paste of a wish list from ALL the topics in the discord development channel. Your agenda was listed as "To Be Determined" with an ask to come here to recommend items. You're german so maybe its in your culture that you just take all of them and don't filter. But you just took that massive list for a 60 minute call. This tells me you're not qualified to run these meetings since anyone who has ran meetings knows this is far too many topics for a 60 minute meeting.

Additionally you didn't even do the top bullet which was the most requested of anyone.

Lastly, you didn't even update the Agenda. It was still listed as "To Be Determined" after the meetings when I came to recap! Your ability to never take blame for your actions is amazing. And you continue to rehash your failures to try to rewrite the past.

Let's move on, we fixed your screw ups. There is no need to KEEP wasting valuable time on mudane process BS. You did this with sorpaas in all of 2019/2020 and you're doing it with MANY others like Charles, Dexaran, and myself. Correct your behavior, you are PART of the problem, not all of it.

So this doesn't look like it is just me commenting on this due to you rejecting my proposal in 21 days from drafting it because I wasn't at your vaguely scheduled meeting. You can search discord and find many complaints but this one was from the person documenting the calls for the recaps:

"Classic_Kevin_ECC08/20/2020
I suggest people listen to Charles video re decision making. Every point in there is right on point. We’re skipping so many things that should give people time to discuss, provide feedback and ask questions and jumping straight to the philosophical side. Obviously not everyone understands all 4 of these proposals before we had a meeting that wasted time. Obviously not everyone knows if these proposals are even practical for this project if there’s already code written, if they are already in production or what. But we jump straight to the philosophical questions without fully understanding. Imo"

Results of your calls:
So now we have three ECIPs in Last Call status and no one has any idea about them so we are all scrambling to read about them. The people behind the proposals are scrambling to get the ECIP in order and wasting the purpose of the Last Call time. Example: ECIP-1043 is already changing its approach and ironing out details which is more in line with the Last Call purpose. ECIP-1049 and ECIP-1095 authors are not engaging the opposition to their proposals because they have no responses to the huge glaring holes in the proposals and are not technically competent to respond. For my proposal, I had to waste a night to bring back my ECIP from Rejected status to Draft status.

On me:
I should have been more clear on the message and stated "This is an EXHAUSTIVE list from development channel. Please filter appropirately due to merit and time." That is my bad and I will do better next time. I also should have left a public note that I would be out of service in the middle of the mountains, miles from civilization and not able to attend these vague "Agenda: TBD" calls you scheduled. I should have clearly pinged you. I left the notes in discord, but did not ping you. That is my bad. Also I will step up at times a take over hosting these meetings for topics i am vested in if I have to. I realize you're paid to do this by ETC Labs, but it is clear people are not satisfied with the service you're delivering in these calls to the network. Which is why teams are starting to hold thier own calls and removing you as a bottleneck to the process.

This will be my last message regarding the issue. It is done and over with, we are moving forward and have too much to do and too little time.