ETC Core Devs Call 14

# ETC Core Devs Call 14 * When: **Friday, September 25, 2020, 4pm UTC,** 90 minutes max * Where: [ETC Discord](https://discord.gg/x3WHgrU) * 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](https://ecips.ethereumclassic.org/ECIPs/ecip-1099) Calibrate Epoch Duration (Last Call) * 51% Proposals * [ECIP 1092](https://ecips.ethereumclassic.org/ECIPs/ecip-1092) 51-percent attack solution PirlGuard by Callisto (Draft) * [ECIP 1094](https://ecips.ethereumclassic.org/ECIPs/ecip-1094) VeriBlock Proof-of-Proof 51%-Attack Prevention (Draft) * [ECIP 1096](https://ecips.ethereumclassic.org/ECIPs/ecip-1096) 51% Attack protection system based on Bitcoin Merged Mining (Draft) * [ECIP 1097](https://ecips.ethereumclassic.org/ECIPs/ecip-1097) Checkpointing based 51% attack resistance (Draft) * [ECIP 1100](https://ecips.ethereumclassic.org/ECIPs/ecip-1100) Modified Exponential Subjective Scoring (Draft) ### Last-Call Proposals #### [ECIP 1099](https://ecips.ethereumclassic.org/ECIPs/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: * :heavy_check_mark: Yes * :heavy_multiplication_x: No * :grey_question: Unknown | proposal | no-forkA | nakamotoB | subj? | specC | transitD | implE | testF | |:----------------------- |:--------------------------------------:|:--------------------------------:|:------------------------:|:------------------------:|:------------------------:|:------------------------------:|:------------------------:| | ECIP-1092 PirlGuard | (:heavy_check_mark:)1 | (:heavy_check_mark:)2 | :heavy_check_mark: | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_check_mark:3 | :heavy_multiplication_x: | | ECIP-1094 VeriBlock | :heavy_multiplication_x: | :grey_question: | :heavy_multiplication_x: | :heavy_check_mark: | :grey_question: | :grey_question: | :grey_question: | | ECIP-1096 Merged Mining | (:heavy_multiplication_x:)4 | (:heavy_check_mark:)2 | :heavy_multiplication_x: | :heavy_check_mark: | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | | ECIP-1097 Checkpointing | (:heavy_multiplication_x:)5 | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_check_mark: | :heavy_multiplication_x: | :heavy_check_mark:6 | :heavy_check_mark: | | ECIP-1100 M.E.S.S. | (:heavy_check_mark:)1 | (:heavy_check_mark:)2 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark:7 | :heavy_check_mark: | Footnotes: 1. 1no fork required, but client coordination for mining nodes encouraged 2. 2does not break nakamoto consensus for honest miners (one cpu, one vote), this is not true for privately mined chains though 3. 3chippr-robotics/chippr-geth 4. 4if you hard-fork you can get greater protection against certain attacks 5. 5could also be a soft fork 6. 6input-output-hk/mantis 7. 7etclabscore/core-geth Potential improvements: - Subjectivity; redundant with hard-fork? - Persistence, Liveness; rather than Nakamoto Consensus