ETC Core Devs Call 14

• When: Friday, September 25, 2020, 4pm UTC, 90 minutes max
• Where: ETC Discord
• Focus: Mining Algorithm, Last-Call Proposals, and other 51%-Attack Solutions.

Agenda

• Last-Call Proposals
  • ECIP 1049 KECCAK256 (Last Call) Moved to call 15 on request
  • ECIP 1099 Calibrate Epoch Duration (Last Call)
• 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 1100 Modified Exponential Subjective Scoring (Draft)

Last-Call Proposals

ECIP 1099 Calibrate Epoch Duration "EtcHash"

TL;DR modify Ethash, cut epoch number in half, reduce DAG size and DAG growth rate significantly, call it EtcHash, requires hard-fork, requires tooling

Proposal has been accepted in call 13, however we need to revise the block numbers, proposal:

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

Which basically means 4 weeks for Mordor and 8 weeks for the Classic main network. Need Besu team to agree. https://github.com/ethereumclassic/ECIPs/pull/371

51%-Proposals

TL;Dr

• ECIP-1092 PirlGuard: mine penalty blocks before allowing privately mined chain; increases attack cost
• ECIP-1094 VeriBlock: proof-of-proof miners endorse ETC blocks on the VeriBlock chain and inherit security from Bitcoin
• ECIP-1096 Merged Mining: visibility-proof scoring allows clients to chose between competing chain heads
• ECIP-1097 Checkpointing: adds proof-of-authority layer to ethereum classic; makes 51% attacks impossible; requires trusted committee
• ECIP-1100 M.E.S.S.: applies exponential scoring to blocks unknown to the client; significantly increases attack cost

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

• ^Adoes it require a hardfork?
• ^Bdoes it break nakamoto conensus?
• ^Cis there a specification for ethereum classic available?
• ^Dis there a transition for activation specified?
• ^Eis there any implementation or simulation available?
• ^Fare test cases available that can be used by the client teams?

Heavy Checklist Matrix:

• Yes
• No
• Unknown

proposal	no-forkA	nakamotoB	subj?	specC	transitD	implE	testF
ECIP-1092 PirlGuard	()1	()2				3
ECIP-1094 VeriBlock
ECIP-1096 Merged Mining	()4	()2
ECIP-1097 Checkpointing	()5					6
ECIP-1100 M.E.S.S.	()1	()2				7

Footnotes:

1. ¹no fork required, but client coordination for mining nodes encouraged
2. ²does not break nakamoto consensus for honest miners (one cpu, one vote), this is not true for privately mined chains though
3. ³chippr-robotics/chippr-geth
4. ⁴if you hard-fork you can get greater protection against certain attacks
5. ⁵could also be a soft fork
6. ⁶input-output-hk/mantis
7. ⁷etclabscore/core-geth

Potential improvements:

• Subjectivity; redundant with hard-fork?
• Persistence, Liveness; rather than Nakamoto Consensus