🚧 🐠 I would like to see and help work toward describing plans and accountable standards for

A. Test network testing protocol

As cody speaks to, testnet outcomes are only as meaningful as the rigors they are subjected to. We ought to be clear and collaborative about the design and implementation of these "live" testnet protocols. Who will participate in this? Who will take responsibility, and for which aspects? What are standards that we expect for these protocols? ... reproducability? ... regression-readiness?

• Kensington
• Kotti
• Morden

B. Cross client integration tests

Like establishing a shared and meaningful idea of what "not breaking" means above, there are clear limitations to the implications of even successful testnet behavior (for example eth-classic/go-ethereum#67 would not have been caught).

This points to the value of shared cross-client test suites, which can prove out edge cases and other important simulations that may not be possible or practical on a test network. ethereum/tests is an example of this, albeit in a very one-trick-pony kind of way.

Since the teams "owning" client development are either independent and/or volunteer-based, and that participation in the network is entirely in the hands of the client operator in the first place, the standards that might be developed here could not be considered with any more earnest than suggested guidelines for client software and operator review, albeit developed with common aims and shared skin in the game.

Ref ECIP-1061 #81 #157 #176

ETC Core Devs Call - ECIP-1061 Aztlán Finalization

When: Wednesday, November 27, 2019, 1pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Parity Ethereum / Parity Tech
  • Geth Classic / ChainSafe, ETCLabs Core
  • Multi-Geth / Multi-Geth, ETCLabs Core
  • Hyperledger Besu / ChainSafe, PegaSys
• Aztlán (ECIP-1061) needs to be either accepted or updated (or rejected)
  • discuss included EIPs
  • discuss a timeline for the protocol upgrade
    • Mordor Classic and Kotti Classic testnet (February?)
    • Ethereum Classic mainnet (March?)
• anything else related to Aztlán

Please comment to add items to the agenda

Discussions for Flyclient

Discussion section for invoke-signer proposal

Markdown view of spec 👉: https://github.com/ethereumclassic/ECIPs/blob/9791c0b59582a2ed80d915afbf410bc104de20ea/_specs/invoke-signer.md

Title

    ECIP: 1057
    Title: Cold Staking
    Author: Dexaran, [email protected]
    Discussions-To: [email protected]
    Status: Draft
    Type: Standard Track - Consensus
    Created: 2019-3-31

Abstract

The following describes the implementation of the protocol, which is designed to reward ETC holders for the long term holding of their coins, thereby creating a scarcity and reducing the actual “circulating supply”. We already have a working prototype and a live version in Callisto Network as well as we have UI and all the necessary descriptions and guidelines.

This proposal is fully compatible with ECIP-1017 since it does not affect the actual monetary policy, but only the distribution of emitted coins.

Motivation

Cold Staking is not a consensus protocol!

1. Rebalance the influence of miners and stakeholders

There are many participants in crypto networks: miners, investors and stakeholders, developers and media resource owners. Miners control the network hashrate, developers and media resource owners participate in hardforks directly, while stakeholders often have not so much power. In addition, the wealth, the hashrate share and the influence of miners increase with time as they receive payments so that they can acquire new mining equipment in order to have more hashpower. In ETC, the share of long term stakeholders do not increase with time.

From a fundamental point of view, it is better if the situation is opposite because:

1. The miners are not interested in the project they are mining. In general, miners are only interested in their income. They can switch at any time regardless of anything, so they have no long-term interest in the network to which they contribute. In most cases, miners have absolutely no incentives to hold assets they are mining. The more power miners have, the greater the dumping potential of the mineable crypto asset.

2. Long term investors and stake holders are interested in project they invest in. In most cases, large investors conduct significant research before making their long-term investments. The more they invest, the more tied to the project they are because they can't just "switch" at any point of time like miners. The more power long-term investors have, the greater the upside potential of the asset.

3. Long term investors are interested in the ecosystem and they have incentives to contribute their resources for the sake of long-term results.

I believe that it is important to implement a protocol that will balance the distribution of influence between miners and stakeholders in order to form a healthy ecosystem for the Ethereum Classic project.

2. Financial incentives

Cold Staking can push the price of a crypto asset higher and increase its upside potential.

The Cold Staking protocol is based on the "gym market theory". You can find a description here. Cold Staking reduces the actual circulating supply by incentivizing long-term stakeholders to lock their funds in a special contract. The more funds are blocked, the scarcer the crypto asset is, the higher the price can become during the bullish phase of the market. The higher the price of a crypto asset is, the greater the incentives for long-term investors (cold stakers) and so on.

Specification

The proposal is to implement a protocol that will reward long-term holders for holding their coins:

• Allocate <X> % of mined block reward for Cold Stakers (cold staking fee).

• Allow any stakeholder to become a Cold Staker by locking his (her) funds in a special smart-contract for 27 days.

• Distribute a total sum of cold staking fees between cold stakers in proportion to their locked stake.

It is proposed to set the Cold Staking fee to 40% at the moment of the implementation and increase the Cold Staking fee share by 5% at block 15,000,000 and block 20,000,000 (these are blocks of mining reward reduction according to ECIP1017).

More detailed calculations are described in this google spreadsheet.

The described system is self-balancing, which means that with the decrease of the staking reward the stakers will pull out, decreasin the total "Cold Staking pool", thus increasing the share of the rest of the stakers, therefore their reward will increase until it will settle at the level where the system is balanced.

However, we should consider the viability of the system assuming that 50% of the total circulating supply will go into Cold Staking. This numbers are empirically proven to be essential.

Most of the stakeable crypto assets such as Dash or PIVX have 4 to 8 % of annual return rate. DASH or PIVX masternode requires a hardware that will participate in the generation of blocks, while Cold Staking do not require cold stakers to perform any actions apart from pressing "start staking" and "claim reward" buttons. The minimal Cold Staking return at 50% of total supply at stake should be comparable to the return of DASH or PIVX masternodes. With that being said I can conclude that 4% of the annual yield from Cold Staking is affordable for the viability of the system at the launch stage.

Staking round length should be equal to 27 days

Traders often make their decisions based on charts and candle closures. Therefore, it is better for them to have their coins available when the time to make a decision will come. That's why I'm proposing 27 days interval.

If you deposit your funds at the beginning of a month then you will have the opportunity to claim it back right before the closure of the (1) week candle and (2) month candle at the same time.

References

• Staking Formula

• Everything you need to know about Callisto Cold Staking

• Cold Staking contract development discussion

• What is Cold Staking? (Callisto)

• Step-By-Step tutorial: Staking with ClassicEtherWallet

• Cold Staking at Testnet

Implementation

This protocol consists of two parts: (1) protocol-level implementation and (2) smart-contract.

1. Protocol-level implementation requires a hardfork. Starting from the hardfork block number, a certain amount of ETC should be allocated for the Cold Staking contract address with each mined block. Protocol-level implementation is only required to enable the Cold Staking.

2. The smart-contract implements the logic of the Cold Staking protocol. The source code of the Cold Staking contract can be found here. Cold Staking contract was audited. Bug bounty was held. The contract has a working implementation at Callisto Network.

Live implementation at Callisto Network

This is the live Cold Staking contract at Callisto Network: 0xd813419749b3c2cDc94A2F9Cfcf154113264a9d6

Cold Staking UI is already implemented in ClassicEtherWallet (only visible when unlocking wallet with CLO network nodes selected).

Cold Staking is supported by Guarda wallet, Trust wallet and some other wallets.

• When: To be decided.
• Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Discuss several signaling proposals, as this is not resolved since last call. cc @soc1c

< Placeholder >

Rendered

An Ethereum Classic Improvement Proposal (ECIP) is a design document providing information to the Ethereum Classic community, or describing a new feature for Ethereum Classic or its processes or environment. The ECIP should provide a concise technical specification of the feature and a rationale for the feature.

We intend ECIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Ethereum Classic. The ECIP author is responsible for building consensus within the community and documenting dissenting opinions.

Because the ECIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

Hey all. The Ethereum main-net repo is formatted as a Jekyll site, so it can be hosted on Github Pages or elsewhere and be browsed as a website. This means making some formatting changes and a few other config files.

I know Jekyll and if this is of interest, I can put a bit of time into it.

Ref #131 ECIP-1056

ETC Core Devs Call - Agharta Finalization

When: Thursday, October 24, 2019, 1pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Geth Classic / ChainSafe, ETC Labs Core
  • Multi-Geth / Multi-Geth, ETCLabs Core
  • Parity Ethereum / Parity Tech
  • Mantis / IOHK
  • Hyperledger Besu / ChainSafe, PegaSys
• Agharta (ECIP-1056) is in "draft" state
  • ECIP-1056 needs to be either accepted or updated (or rejected)
    • discuss EIP 145 (Bitwise shifting instructions)
    • discuss EIP 1014 (Skinny CREATE2 opcode)
    • discuss EIP 1052 (EXTCODEHASH opcode)
    • discuss account versioning ref #86 (EIP-1702)
  • discuss a timeline for the protocol upgrade
    • Morden Classic and Kotti Classic testnet (January?)
    • Ethereum Classic mainnet (March?)
• anything else related to Agharta

Bonus

• Sha3 / ECIP-1049
• DAG Size / ECIP-1043

Please comment to add items to the agenda

ref etclabscore/ECIPs#29

ETC Core Devs Call - Atlantis Hardfork Hands-On

When: Thursday, September 12, 2019, 2:00 pm UTC, during the expected hardfork, 120 minutes max.

latest prediction: 2:50:07 pm UTC | Thursday, September 12, 2019

Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc. Ask for an invite here if you are not on that discord.

This will be an informal call for core developers and everyone else interested to monitor the hardfork and discuss progress, eventually, act if necessary.

Notification of Agharta plan to make known stakeholders aware of the rough timeline and expected upgrades ahead of the fork:

4 contact points:

1. Initial heads up a fork is being discussed, get updated contact info
2. Fork blocks have been decided
3. Fork is 2 weeks out
4. Fork happened and is good to go

List of contacts:

Exchanges

• 55 Global Markets
• ABCC
• Abucoins
• AEX
• BCEX
• Bibox
• BigONE
• Binance
• Bit-Z
• Bitfinex
• BitForex
• Bithumb
• Bitker
• Bitso
• BitStar
• Bittrex
• BTC Markets
• BTC Trade UA
• BTC-Alpha
• BTCC
• BTCTrade
• C2CX
• Changelly
• ChaoEX
• Circle/Poloniex
• Coinbase/Coinbase Wallet
• Coinbene
• Coineal
• CoinEgg
• CoinExchange
• Coinnest
• Coinone
• Coinroom
• Coinsbit
• Coinsquare
• CoinTiger
• Coinut
• Crex24
• CryptoCurrencyX
• CryptoMate
• Cryptopia
• DigiFinex
• DragonEx
• Evercoin
• Exmo
• Exrates
• Gate.io
• Gatehub
• HitBTC
• Huobi
• HuobiGlobal
• IDCM
• Korbit
• Kraken
• Kucoin
• Lbank
• LiteBit.eu
• London Block Exchange
• Mr. Ripple
• OKEx
• Ovis
• P2PB2B
• QBTC
• Qryptos
• Right BTC
• Robinhood
• ShapeShift
• STEX
• Tokok
• Upbit
• Vebitcoin
• YoBit
• ZB com

Miners/Mining Pools

• TED LEUNG
• 0xETH
• 2miners
• 91pool
• AntPool / Bitmain
• ArsMine
• BTC-com
• BW
• Clona Network
• CoinFoundry
• CoinMiners
• Cominers
• Comining
• CruxPool
• daboehlatresh
• epool.io
• Ethermine/Bitfly
• F2Pool
• GlobalPool
• HashOn-Pool
• MinerTopia
• MiningPoolHub
• NanoPool
• PoolCrypto
• ProtonMine
• Rett Anderson
• SoloMiningPools
• UUpool
• ViaBTC
• Wattpool
• Coinotron

Block Explorers

• BlockScout
• Etherhub
• Gastracker
• Google Query
• MinerGate
• Jade Explorer

Wallets

• Atomic Wallet
• Bitpie
• Cobo
• Coinomi
• Emerald Wallet
• Exodus
• Guarda
• JAXX
• Ledger
• MyCrypto
• MyEtherWallet
• Saturn Wallet
• Trezor
• Trust Wallet

Node Services Providers

• Ethercluster
• Ethernode
• BloqCloud

Other/PR

• CoinDesk
• Bitcoin Magazine
• Yahoo Finance
• CoinTelegraph
• NewsBTC
• CryptoGlobe
• CryptoBriefing

I think the link and text to the ECIPs site on ./ethereumclassic/ECIPs should be:

The Ethereum Classic Improvement Proposal repository is at https://ecips.ethereumclassic.org/

Currently it's:

https://ethereumclassic.org/

...which takes you the home, but that is not the ECIPs site.

Discussion page for ECIP-1040.

BIP 001 the following text can be found:

This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list.

the ECIP-1000 points to luke-jr as the copy right holder. If he is, we need to properly link to the license, if not it needs to be addressed with the proper license

ETC Core Devs Call - Mining Algorithm Upgrade

When: Thursday, November 21, 2019, 1pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Parity Ethereum / Parity Tech
  • Geth Classic / ChainSafe, ETC Labs Core
  • Multi-Geth / Multi-Geth, ETCLabs Core
  • Hyperledger Besu / ChainSafe, PegaSys
• Defining a process
  • keeping the call technical?
  • ECBP-1076 "algo change process" ref #187
• Discuss options for mining algorithms
  • ECIP-1049 "SHA-3" @p3c-bot ref #8 #13
  • ECIP-1070 "ProgPOW" @YazzyYaz ref #171 #172
  • Status Quo: "Ethash" ...
• Agree on a joint way forward on the three proposals above
• Commit to a timeline
• Focus on a testnet
• Discuss anything else related to Mining
• Bonus:
  • ECIP-1043 "DAG Size Limit" @realcodywburns @Wolf-Linzhi ref #11 #138
  • ECIP-1047 "Block Gas Limit" @pyskell @zmitton ref #6 #14

Please comment to add items to the agenda

ETC Core Devs Call - Atlantis Finalization

When: Thursday, May 30, 2019, 3pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Geth / Multi-Geth
  • Parity Ethereum
  • IOHK Mantis
• Atlantis (ECIP-1054) is in "last call" state
  • ECIP-1054 needs to be either accepted or updated (or rejected)
  • discuss whether EIP-161 should be included or not @meowsbits @sorpaas
  • discuss any other EIP that might cause uncertainty
  • discuss timeline for the protocol upgrade
    • Morden Classic and Kotti Classic testnet (August?)
    • Ethereum Classic mainnet (September?)
• Anything else related to Atlantis
• Outlook: Agharta (ECIP-1056) if time permits
• Outlook: Astor SHA3 testnet if time permits

Please comment to add items to the agenda

ref etclabscore/ECIPs#25

ETC Core Devs Call - Atlantis Finalization

When: Thursday, June 13, 2019, 3pm UTC, 60 minutes max.

Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc. Ask for invite here if you are not on that discord.

Agenda

• Quick client teams check-in
  • Geth / Multi-Geth
  • Parity Ethereum
  • IOHK Mantis
• Testing updates
  • Kensington Testnet
  • Kotti Testnet
  • Morden Testnet
• Atlantis (ECIP-1054) is in "last call" state
  • ECIP-1054 needs to be either accepted or updated (or rejected)
  • ideally, we agree on how (and when) we accept Atlantis in this call

ECIP-1043: Fixed DAG limit restriction

Discussions for ProgPoW for ETC Discussions concerning this Pull Request: #171

Discussion for #203

This is just a bad idea, and is never going to happen.
Sorry, Jesse.
But we should reject this and clear out cognitive load.

It became apparent that certain parts of the Ethereum Classic community are appreciating an accelerated hardfork schedule. To avoid confusion, rushing protocol upgrades, and putting the network at risk of a potential split, I propose scheduling an intermediate atlantis-upgrade scheduling call to discuss and agree on a realistic timeline for ECIP-1054

ref #79

ETC Core Devs Call - Atlantis Scheduling

When: Friday, June 07, 2019, 1pm UTC, 30 minutes max.

Where: Youtube Livestream https://www.youtube.com/watch?v=hDVrKDSOCWA&feature=youtu.be
You can stream the call and chat and ask questions on Youtube Livestream. If you want access to the Hangouts to chat via voice, you'll need to message @soc1c or @YazzyYaz for a link to that. Due to limit on voice call attendees by Google, we ask that only those who are interested in using voice to ask for the invite to the Hangouts.

Agenda

• Quick client teams check-in
  • Geth / Multi-Geth
  • Parity Ethereum
  • IOHK Mantis
• Discuss timeline for the protocol upgrade
  • Morden Classic and Kotti Classic testnet
  • Ethereum Classic mainnet

There are two competing proposals right now, I will give them letters, and propose a 3rd as a compromise:

• [A] Original ECIP-1054 schedule
  • 1_039_000 on Kotti Classic PoA-testnet (early August 2019)
  • 4_723_000 on Morden Classic PoW-testnet (early August 2019)
  • 8_750_000 on Ethereum Classic PoW-mainnet (mid-September 2019)
• [B] ETCLabs "July 1st" schedule
  • N/A on Kotti Classic PoA-testnet
  • immediately on Morden Classic PoW-testnet (early June 2019)
  • 8_343_000 on Ethereum Classic PoW-mainnet (July 1st 2019)
• [C] Moderately accelerated schedule
  • 716_617 on Kotti Classic PoA-testnet (two weeks from now)
  • 4_729_274 on Morden Classic PoW-testnet (two weeks from now)
  • 8_500_000 on Ethereum Classic PoW-mainnet (six weeks after successfull testnet forks)

The former repository (https://github.com/ethereumproject/ECIPs) was compromised and generally inefficient.

Please transfer from captured repo if you wish your improvement to be recorded in this repo:

@sorpaas

PR:

• ECIP-1000: Proposed ECIP Process
• ECIP-1022: Generalized Version Bits Voting for Consensus Soft and Hard Fork
• ECIP-1023: Combined CarbonVote and MinerVote for Consensus Soft and Hard Forks
• ECIP-1024: A CarbonVote and MinerVote Contract for Consensus Soft and Hard Forks
• ECIP-1025: Precompiled Contracts for zkSNARK Verification
• ECIP-1026: Modexp Precompiled Contract
• ECIP-1029: Include Uncles in Total Difficulty Calculation
• ECIP-1032: Readable Address and Transaction Hash
• ECIP-1033: Mnemonic code for public address
• ECIP-1034: Message Signing and Verification in JSON RPC
• ECIP-1040: Generalized Account Versioning Scheme for Hard Fork

@Dexaran

PR:

• Current implementation of ECIP1021 doesn't match ERC223 token standard.

Issues:

• ECIP-?- Ethereum Classic Naming Service (ECNS)
• EVM 2.0 Wasm
• Integrated Random Number Generator
• Voting mechanism
• ERC223 Token standard
• ERC: Address-to-Address messaging system protocol
• On-chain registry of official media resources.

Dontpanic

PR:

• ECIP1043 Fixed DAG

Issues:

• Evaluate first round of metro hard fork
• ECIP-?: Extension of ecip 1010 timeline

@splix

PR:

• ECIP-1027/28: Scaling ETC with Sidechains [WIP]
• ECIP-1042: GASPAY

Issues:

• ECIP-? Atomic Transactions

@gagarin55

• ECIP-1019

@arvicco

• ECIP-? Limit DAG growth
• ECIP-? Protection from transaction replays
• ECIP-1017 ETC monetary policy and emission schedule

@pyskell

issues:

• Utilizing a second authentication method to prove ownership and facilitate fund recovery in the event of a theft
• Adopt EIP-658

@bmann

• FISSION Status Codes

other

• We didn't have accepted ECIP process user:ghost
• ECIP1011 for Replay Attack Fix Using Change in the Signing Process
• ECIP-1044: Formalize IPFS hash into ECNS resolver
• ECIP-1045: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades
• ECIP-1046: Precompiled contract for verification of Merkle Inclusion Proofs

Needs to add a To-Discussion to ECIP-1053

For now, I propose this link: https://github.com/etclabscore/ECIPs/blob/master/ECIPs/ECIP-1053.md

But it can be changed depending on what is more appropriate for discussions link.

@bmann:Hello Ethereum Classic Team!

We've been speaking with @pyskell and others who encouraged us to submit our FISSION Status Codes so that it can be used in Ethereum Classic. If there is interest, we would then also submit FISSION Translate, which builds on chain translation for smart contract messages.

This is meant to be blockchain agnostic, as bytes are able to be coded in pretty much any system. This is standards track on Ethereum as ERC-1066, and various other standards are starting to use it as a dependency.

On Ethereum Classic, it looks like it would make the most sense as an Informational ECIP -- please let me know if you would prefer it be Standards track instead.

@expede is the author and architect of this work, I'm helping to learn the ECIP process and help explain anything that people have questions about.

The FISSION Suite has its own website, and the web version of this proposal may be more readable there: https://fission.codes/fission-codes/

ethereumproject/ECIPs#98

Discussion section for ratchet-pricing proposal

The current core dev meeting coordinator is informally Afri. Afri has said we "can replace me anytime". Given recent actions that Afri were not exactly following the "protocol" and were not exactly "neutral" in his position, I think it would be important to have some coordinator name list ready, in case we want to appoint a new one for all of our meetings.

Please feel free to propose names or propose yourself. Current list:

@YazzyYaz
@phyro
@tokenhash
@developerkevin
@mikeyb

ECIP: ?
Title: Smart-contract Security Auditing core
Status: Draft
Type: Meta
Author: Dexaran, [email protected]
Created: 2018-12-31

Abstract

The following describes a smart-contract development security enhancement method, its implementation and the underlying funding mechanism as well as a possible unique feature and use case of Ethereum CLassic project.

Motivation

Smart-contract development security is critical for the whole crypto industry and for Ethereum Classic in particular. We know the precedents of large contract hacks, which led to the loss of large amounts of funds as well as undermining confidence in the industry as a whole. For example TheDAO hack, Parity Multisig hack 1, Parity Multisig hack 2, ERC20 vulnerability led to the loss of millions of dollars.

As an information security engineer, I can say that formal verification, better coding standards, new programming languages, and other automated tools cannot significantly improve the fault-tolerance of smart contract systems.

On the other hand, the smart contracting industry still needs security improvements and decentralized, immutable, chain-agnostic environment which will ensure and preserve contract development/auditing history. I propose to establish a team of professional security auditors that will work to enhance the security of smart-contracts (for ETC or for the whole industry).

Advantages:

• ETC is definitely a proper immutable, decentralized, chain-agnostic environment which can serve the above goal.
• ETC benefits from smart-contract security enhancement too, as ETC is a smart-contract development platform.
• The total value of the entire cryptoindustry rises, which is also benefitial for ETC.
• Unique use case for Ethereum CLassic blockchain, which can increase the network effect and boost the growth of the project and ecosystem.

Specification

We must not rely on blockchain technology to verify smart-contracts. We can only use it to provide a registry of audited contracts, publish and manage results of smart-contract audits.

Security auditing team

The detailed description of Security Auditing organization can be found here: https://github.com/EthereumCommonwealth/Auditing

There are two types of participants in the described organization: managers and auditors.

The main task of a manager is to control and verify the work of the auditors.

The main task of an auditor is to review a code of smart-contracts and submit reports. Auditors receive karma for reviewing contracts. They also receive penalties for making mistakes. The statistic reflects each auditors results and determines their reward.

The audit process will be managed through github so that it will be transparently available for everyone. A smart-contract developer should open an issue to submit his smart-contract for auditors review. Then the manager will verify security audit request details and mark the issue as approved. The manager should not mark dummy requests, requests that aim to spam the security audit queue or any requests that does not met coding standard requirements. After that, every auditor can start reviewing the code.

An auditor with a willingness to participate in the code review of a certain contract must create a private gist and send gist URL to the corresponding issue manager by email. E-mail address of each manager or auditor is transparently available at the smart-contract of this organization.

Security Auditing organization governance.

Currently, the security auditing organization relies on Treasury proposal and rights delegation mechanism.

1. Treasury voters owners establish the payment schedule for security auditing department, thus delegate the governance rights to the security auditing manager.

2. Security auditing manager distributes the received payment between the auditing team members.

3. If Treasury voters are not satisfied by the workflow of security department then they must fire the security auditing manager.

It is planned to automate the security auditing team workflow with a SecurityDAO smart-contract in 2019 however the contract is still in development. Security DAO smart-contract is not a critically important detail of this proposal.

Outcome

As the result of the functioning system we receive a well-defined process of smart-contract security auditing. Each smart-contract is reviewed by at least 3 professional security auditors.
Security audits are completely free-of-charge for smart-contract developers, thus every smart-contract developer is capable of ordering a security audit before deploying his/her smart-contract.

• Security Auditing organization structure has a working implementation in Callisto Network.

• 113 succesful security audits were performed during 2018.

• According to Callisto Network statistics for 2018, this costs the ecosystem approx. $4000/month. I think that this is a reasonable price which should be paid to prevent such accidents as TheDAO hack and other hacks which caused much more losses.

Requirements

This requires Treasury Proposal implementation.

@BelfordZ @bobsummerwill are proposing to unify the license of ECIP repo under Apache v2. Since ECIPs are written by many people, we need permission from people who have contributed. If you've contributed code or documentation to ECIP at any point, we would like to get your permission. The recommended way to do this would be to leave a comment at this Github issue. It's also possible to grant the permission privately or anonymously. Please let us know if you have this need.

the contents of: https://ecips.ethereumclassic.org should be published using GH pages.

Ref ECIP-1056 #75 #131 #135

ETC Core Devs Call - Agharta Final Finalization

When: Thursday, December 12, 2019, 1pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Parity Ethereum / Parity Tech
  • Geth Classic / ChainSafe, ETCLabs Core
  • Multi-Geth / Multi-Geth, ETCLabs Core
  • Hyperledger Besu / ChainSafe, PegaSys
• Agharta (ECIP-1056) is in "last call" state
  • ECIP-1056 needs to be accepted
    • evaluate testing on morden testnet
    • evaluate testing on mordor testnet
    • evaluate testing on kotti testnet
  • discuss a timeline for the protocol upgrade
    • agree on a block number for mainnet

Please comment to add items to the agenda

this should shouw up in the ecip room in discord

⛔️ WARNING ⛔️ : http://github.com/ethereumclassic/ECIPS IS UNOFFICIAL AND SHOULD NOT BE USED.

Use https://github.com/openether/ecips to participate in decentralized ETC development.

Discussion related to #183.

"ASIC resistance" is a myth. The ETC ecosystem rejects this myth.

Discussion for #186

ECIP: ?
Title: Ethereum Classic Treasury system
Status: Draft
Type: Standard Track - Consensus
Author: Dexaran, [email protected]
Created: 2018-12-31

Abstract

The following describes the possible implementation of a development funding mechanism.

Motivation

The crypto industry is actively developing. This also applies to Ethereum Classic. In order for the development of the project to continue it is necessary to incentivize developers to take part in it. Having a professional development team also requires a permanent source of funding.

We have a precedent of one of the main ETC development teams being shutdown due to lack of funding. (announcement reference)

Ethereum Commonwealth, the other ETC development team, adheres to the policy of financial transparency. According to our public financial report, you can see that we did not receive any funding since July 2017 to the end of 2018.

Summarizing the above, I can conclude that a permanent source of development funding is essential for further growth and maintenance of the project and ecosystem. This source of funding should be implemented at the protocol level.

The source of funding must ensure:

• financial transparency - this is ensured by the ability to track transactions.
• constant cash flow which must be used to incentivize contributors to develop Ethereum Classic core OR ecosystem.
• agnosticism - third party contributors must have access to the source of funding even if they never contributed to ETC development before.

Specification

General

The proposed solution is based on Callisto Network Treasury.

Callisto Network Treasury advantages:

1. Has a working implementation (geth / parity)
2. Already tested in real market environment.
3. Simple and secure to implement/rollback.
4. Compatible with ECIP-1017: ETC monetary policy.

Technical

The proposed treasury system relies on two system addresses that receive funding at the protocol level. The protocol-level funding is a split of a base block reward. When a new block is mined, the reward is represented by three values: miner's block reward, X and Y where:

• X goes to the first Treasury address.
• Y goes to the second Treasury address.
• (base block reward - (X + Y)) goes to miner's address.

This is possible to implement the described scheme without changing the base block reward, thus keeping the original 5M20 Ethereum Classic monetary policy unaffected.

The ECIPs website does not show all lines of the preambles, so, for example, the discussion link of ECIP-1043 is not showing:

I think it's because the php/html/css is calling only up to 5 lines per ECIP, but I think it could be expanded.

I recommend setting the line count to 15 as that is the max amount of lines on a preamble as per ECIP-1000.

Re: http://ecips.ethereumclassic.org/ECIPs/ecip-1043

Discussion for #200.

Proposal to reject the following ECIPs:

ECIP-1021 - Token standard (= ERC-223 in Ethereum)
ECIP-1051 - Ethereum Classic Treasury system
ECIP-1052 - Smart-contract Security Auditing core
ECIP-1057 - Cold Staking

There is no support for these proposals.
Realistically they will never happen.

If new champions wish to propose similar changes in the future they should create new ECIPs.
We should reduce our cognitive load and the clarify of our "working set" by pruning out such inactive or "never going to happen" proposals.

Dexaran has indicated that his efforts will now be applied against EOS and I wish him the best with that approach. https://twitter.com/BobSummerwill/status/1199718315683237888

Nobody has championed treasury proposals except for Dexaran either, and treasury proposals are deeply unpopular within ETC.

https://github.com/ethereumclassic/ECIPs/search?q=ethereumproject&unscoped_q=ethereumproject

Discussion page for ECIP 1043: Fixed DAG limit restriction.

Atlantis Hardfork Meta
Enable the outstanding Ethereum Foundation Spurious Dragon and Byzantium network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Atlantis to enable maximum compatibility across these networks.

To Discussion to : etclabscore/ECIPs#10

TL;DR

If someone pointed you to this issue, you probably have to upgrade your Ethereum Classic node software in anticipation of the upcoming Atlantis protocol upgrade (ECIP-1054).

You have to run at least one of the following client versions:

• Classic-Geth, version 6.0.8-stable or later: etclabscore/go-ethereum/releases
• Multi-Geth, version 1.9.2-stable or later: multi-geth/multi-geth/releases
• Parity Ethereum, version 2.5.6-stable or later: paritytech/parity-ethereum/releases
• Mantis is no longer supporting Ethereum Classic!

Projected Hardfork Date based on 14.5 seconds block time:

• 9:00 am UTC | Friday, September 13, 2019

Please share this on all channels. That's exactly 1 month from today creating this tracking ticket.

Reach out to Mining Pools

• https://etc.ethermine.org/
• https://etc.nanopool.org/
• https://ethereum-classic.miningpoolhub.com/
• https://2miners.com/etc-mining-pool
• https://etc.f2pool.com
• https://pool.btc.com/
• https://etcpool.maxhash.org/
• https://minergate.com/etc-mining-pool
• https://etc.solopool.org/
• https://etc.arsmine.com/
• http://etc.hvpps.net/
• https://anyhash.net/
• https://comining.io/
• https://etc.cominers.org/
• https://hashon.me/etc/home
• http://tpool.io/pool/etc/stats
• https://etc.matpool.io/
• https://beepool.org/coindetail/etc

Update Websites and Social Media

• https://ethereumclassic.org/
• https://twitter.com/eth_classic?lang=en
• https://ethereumclassic.github.io/
• https://etccooperative.org/
• https://etclabscore.github.io/etclabscore/
• https://etclabs.org
• https://twitter.com/etclabscore
• https://twitter.com/etclabs
• https://en.wikipedia.org/wiki/Ethereum_Classic

Update Block Explorers and Services

• https://blockscout.com/etc/mainnet
• https://gastracker.io/
• https://etcblockexplorer.com/home
• https://etherhub.io/home
• https://0xeth.com/
• https://www.ethercluster.com/

Reach out to Exchanges

• https://hk.coineal.com/trade_center.html?s=etc-btc#en_US
• https://www.cointiger.com/en-us/#/trade_pro?coin=etc_btc
• https://trans.zb.com/etcusdt
• https://trade.coinegg.com/trade/etc_btc
• https://www.bitker.com/#/bbTrades/etc_btc
• https://www.catex.io/trading/ETC/TRX
• https://www.idcm.io/trading/ETC_USDT
• https://www.okex.com/market?product=etc_usdt
• https://www.digifinex.com/en-ww/trade/USDT/ETC
• https://www.55.com/home/#/exchange?symbol=ETCETH&site=B
• https://www.coinbene.com/exchange/en_US/ETCUSDT
• https://www.bitforex.com/en/spot/etc_usdt
• https://www.bibox.com/exchange?coinPair=ETC_USDT
• https://hitbtc.com/ETC-to-BTC
• https://www.digifinex.com/en-ww/trade/ETH/ETC
• https://www.idax.pro/exchange?pairname=ETC_USDT
• https://p2pb2b.io/trade/ETC_USD
• https://www.hbg.com/etc_usdt/exchange/
• https://coinsbit.io/trade/ETC_BTC
• https://www.binance.com/en/trade/ETC_USDT
• https://pro.coinbase.com/trade/ETC-USD
• https://www.bitfinex.com/
• https://international.bittrex.com/Market/Index?MarketName=BTC-ETC
• https://poloniex.com/exchange#btc_etc
• https://trade.kraken.com/markets/kraken/etc/eur

Discussion for #202

Discussion regarding ECIP-1047(#6). Please discuss here and refer to #6 for the latest version of this ECIP.

< Placeholder >

Recent thread moved here (2020+)

lang: en
ecip: 1049
title: Change the ETC Proof of Work Algorithm to the Keccak-256
author: Alexander Tsankov ([email protected])
status: LAST CALL
type: Standards Track
category: core
discussions-to: #13
created: 2019-01-08
license: Apache-2.0

Change the ETC Proof of Work Algorithm to Keccak-256

Abstract

A proposal to replace the current Ethereum Classic proof of work algorithm with EVM-standard Keccak-256 ("ketch-ak")

The reference hash of string "ETC" in EVM Keccak-256 is:

49b019f3320b92b2244c14d064de7e7b09dbc4c649e8650e7aa17e5ce7253294

Implementation Plan

• Activation Block: 12,000,000 (approx. 4 months from acceptance - January 2021)

• Fallback Activation Block: 12,500,000 (approx. 7 months from acceptance - April 2021)

• If not activated by Block 12,500,000 this ECIP is voided and moved to Rejected.

• We recommend difficulty be multiplied 100 times at the first Keccak-256 block compared to the final Ethash block. This is to compensate for the higher performance of Keccak and to prevent a pileup of orphaned blocks at switchover. This is not required for launch.

Motivation

• A response to the recent double-spend attacks against Ethereum Classic. Most of this hashpower was rented or came from other chains, specifically Ethereum (ETH). A separate proof of work algorithm would encourage the development of a specialized Ethereum Classic mining community, and blunt the ability for attackers to purchase mercenary hash power on the open-market.

• As a secondary benefit, deployed smart contracts and dapps running on chain are currently able to use keccak256() in their code. This ECIP could open the possibility of smart contracts being able to evaluate chain state, and simplify second layer (L2) development. We recommend an op-cod / pre-compile be implemented in Solidity to facilitate this.

• Ease of use in consumer processors. Keccak-256 is far more efficient per unit of hash than Ethash is. It requires very little memory and power consumption which aids in deployment on IoT devices.

Rationale

Reason 1: Similarity to Bitcoin

The Bitcoin network currently uses the CPU-intensive SHA256 Algorithm to evaluate blocks. When Ethereum was deployed it used a different algorithm, Dagger-Hashimoto, which eventually became Ethash on 1.0 launch. Dagger-Hashimoto was explicitly designed to be memory-intensive with the goal of ASIC resistance [1]. It has been provably unsuccessful at this goal, with Ethash ASICs currently easily available on the market.

Keccak-256 is the product of decades of research and the winner of a multi-year contest held by NIST that has rigorously verified its robustness and quality as a hashing algorithm. It is one of the only hashing algorithms besides SHA2-256 that is allowed for military and scientific-grade applications, and can provide sufficient hashing entropy for a proof of work system. This algorithm would position Ethereum Classic at an advantage in mission-critical blockchain applications that are required to use provably high-strength algorithms. [2]

A CPU-intensive algorithm like Keccak256 would allow both the uniqueness of a fresh PoW algorithm that has not had ASICs developed against it, while at the same time allowing for organic optimization of a dedicated and financially committed miner base, much the way Bitcoin did with its own SHA2 algorithm.

If Ethereum Classic is to succeed as a project, we need to take what we have learned from Bitcoin and move towards CPU-hard PoW algorithms.

At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. - Satoshi Nakamoto (2008-11-03) [3]

Note: Please consider this is from 2008, and the Bitcoin community at that time did not differentiate between node operators and miners. I interpret "network nodes" in this quote to refer to miners, and "server farms of specialized hardware" to refer to mining farms.

Reason 2: Value to Smart Contract Developers

In Solidity, developers have access to the keccak256() function, which allows a smart contract to efficiently calculate the hash of a given input. This has been used in a number of interesting projects launched on both Ethereum and Ethereum-Classic. Most Specifically a project called 0xBitcoin [4] - which the ERC-918 spec was based on.

0xBitcoin is a security-audited [5] dapp that allows users to submit a proof of work hash directly to a smart contract running on the Ethereum blockchain. If the sent hash matches the given requirements, a token reward is trustlessly dispensed to the sender, along with the contract reevaluating difficulty parameters. This project has run successfully for over 10 months, and has minted over 3 million tokens [6].

With the direction that Ethereum Classic is taking: a focus on Layer-2 solutions and cross-chain compatibility; being able to evaluate proof of work on chain, will be tremendously valuable to developers of both smart-contracts and node software writers. This could greatly simplify interoperability.

Implementation

Example of a Smart contract hashing being able to trustlessly Keccak-256 hash a hypothetical block header.

Here is an analysis of Monero's nonce-distribution for "cryptonight", an algorithm similar to Ethash, which also attempts to be "ASIC-Resistant" it is very clear in the picture that before the hashing algorithm is changed there is a clear nonce-pattern. This is indicative of a major failure in a hashing algorithm, and should illustrate the dangers of disregarding proper cryptographic security. Finding a hashing pattern would be far harder using a proven system like Keccak-256:

Based on analysis of the EVM architecture here there are two main pieces that need to be changed:

1. The Proof of work function needs to be replaced with Keccak-256
2. The Function that checks the nonce-header in the block needs to know to accept Keccak-256 hashes as valid for a block.

A testnet implementing this ECIP, is currently live, with more information available at Astor.host

• Official Keccak Team Implementation Document for Hardware and Software. Located here
• Node Implementation (based on Parity). Located here
• Keccak-256 CPU Miner. Located here
• Block Explorer. Located here
• Live Network Stats. Located here

References:

1. https://github.com/ethereum/wiki/wiki/Dagger-Hashimoto#introduction
2. https://en.wikipedia.org/wiki/SHA-3
3. https://satoshi.nakamotoinstitute.org/emails/cryptography/2/
4. https://github.com/0xbitcoin/white-paper
5. EthereumCommonwealth/Auditing#102
6. https://etherscan.io/address/0xb6ed7644c69416d67b522e20bc294a9a9b405b31

Previous discussion from Pull request

ETC Core Devs Call - Finalization of the Atlantis Finalization

When: Thursday, June 20, 2019, 3pm UTC.

Where: Ethereum Classic Discord #ecips channel.

Agenda

• Quick client teams check-in
  • Multi-Geth
  • Parity Ethereum
  • IOHK Mantis
  • Classic Geth
• Testnet status
  • Kensington
  • Kotti Hardfork
  • Morden Outlook
• Discussion about the hard fork block