Full CorpusaskETC full context pack

A Crypto-Decentralist Manifesto By Bit Novosti

Blockchains are going to rule the world, providing a mechanism for scaling
social and economic cooperation to an unprecedented level — a truly global
scale. Such cooperation will involve not only human beings, groups and
associations but also a growing multitude of increasingly independent
artificial agents.

Every blockchain creates a social network around its applications, with network
value growing exponentially with the number of participants in accordance with
Reed’s Law https://en.wikipedia.org/wiki/Reed%27slaw. This value isn’t
extracted by intermediaries or controllers, as with previous centralized
models. Instead, it’s shared among participants, providing economic incentives
for cooperation without coercion.

Not all blockchains are created equal. There are three key characteristics that
make scalable blockchain-enabled cooperation possible: openness, neutrality and
immutability.

Openness is necessary. It goes without saying that the rules of the game
should be open for anyone to see and understand. Anyone should be able to
participate in any layer of the system without asking for any permission
whatsoever. Anyone should be able to use the network in accordance with its
rules. Anyone should be able to create their own client implementing the open
protocol. Anyone should be able to contribute to network security, and so on. No
registration, identification or other preconditions should limit
participation. All such limitations prevent the network from scaling and their
enforcement creates centralization risks.

Neutrality is necessary. It’s important for anyone participating in
blockchain-enabled cooperation to be on an equal footing with everyone else. It
doesn’t matter if you wield huge economic power or only a tiny amount. It
doesn’t matter whether you’re a saintly Mother Theresa or a vicious drug
dealer. It doesn’t matter whether you’re a human or a refrigerator. It doesn’t
matter what you believe in, what political theory you subscribe to, or whether
you’re a moral or immoral person. A participant’s ethnicity, age, sex,
profession, social standing, friends or affiliations, make or model, goals,
purposes or intentions — none of this matters to the blockchain even a bit. The
rules of the game are exactly the same for everyone, period. Without neutrality,
the system is skewed towards one set of participants at the expense of
others. In that case, it’s less likely to gain universal acceptance and maximize
network value for everyone.

Immutability is necessary. The blockchain is a truth machine preserving one
universally accepted version of history, one immutable sequence of
events. What’s true once is always true, regardless of political or business
interests, and no amount of lobbying can change that. If it’s simply not
possible to change history, then no resources are wasted on the effort. If there
are any loopholes at all, then sufficiently motivated and determined interest
groups will exploit them at the expense of others, diminishing network value for
everyone.

The rules governing the blockchain network are known in advance. They’re exactly
the same for everyone and not subject to change other than with 100%
consensus. Yes, it must be 100%. Because any change to the system’s rules that
not all participants freely agree to creates a network split, diminishing
network value for everyone.

It’s impossible to achieve these blockchain characteristics without the system
being truly decentralized. If any aspect of the blockchain system becomes
subject to centralized control, this introduces an attack vector enabling the
violation of one or more of the key blockchain characteristics. It may be
possible to limit participation (such as by enforcing AML/KYC rules), thus
violating openness. It may be possible to enforce discriminatory policies (such
as by filtering “illegal” transactions), thus violating neutrality. It may be
possible to rewrite the history of events (such as by confiscating or
“redistributing” funds), thus violating immutability. Introducing centralized
chokepoints creates a precondition for the introduction of “blockchain
intermediaries or controllers” who can siphon value out of the system at other
participants’ expense.

So decentralization is the most important feature of blockchain systems, the one
everything else depends on. With decentralization, blockchains will come to rule
the world. Without it, they’ll be “contained” and railroaded into niche
applications.

We decentralists are committed to keeping blockchains open, neutral and
immutable. We’re committed to keeping blockchain systems decentralized. This
informs all our actions and positions towards any developments in the crypto
world and beyond. All attempts to violate any of the key blockchain
characteristics should be fought. All changes to a blockchain’s rules that
introduce new centralization risks or strengthen existing ones should be
fought. Only developments that are clearly beneficial to decentralization or
strengthen the three key blockchain characteristics should be supported and
encouraged.

The blockchain revolution won’t be centralized. Let’s make sure of it.

Onward.

Accounts

Accounts are associated with users and
:ref:smart contracts . All accounts contain the
following five components:

address
 These are sets of numbers used to identify accounts.

balance
 All funds are associated with accounts. This is a balance of classic ether,
 also know as ether or ETC.

code (smart contract)
 All smart contracts are associated with accounts. This component is
 an empty string for user accounts.

storage
 All smart contracts have associated memory. This component is an
 empty string for user accounts.

nonce
 Nonces are counters. For user accounts, these equal the number of associated

 equal the number of associated smart contracts created.

All components of all accounts together comprise the state of the world
computer.

Addresses

All accounts are identified by addresses which are derived from secret random
numbers unique to each account. These secret random numbers are referred to as
private keys. Private keys must be kept private because they are used to
digitally sign transactions from accounts. These transactions can transfer
funds, create smart contracts, and, execute smart contracts. Strictly speaking,
private key numbers must be between 1 and

 115792089237316195423570985008687907852837564279074904382605163141518161494336

inclusive. This requirement is necessary for their use in ETC digital
signatures. Some may be concerned that two users might unintentionally select
the same private key. The odds of that happening are vanishingly small. In fact,
the number of possible private keys is approximately equal to the number of
atoms in the entire universe!

All private keys are associated 64 byte numbers derived from them which are
referred to as public keys. The calculation of public keys involves an odd
type of arithmetic with respect to pairs of numbers. Here is a Python script
that calculates public keys from private keys:

 #!/usr/bin/env python3

 """
 Calculates ETC public keys from ETC private keys.

 Usage: etcpubkey
 """

 import random
 import sys

 A = 0
 N = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
 P = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
 GX = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
 GY = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
 HEXADECIMAL = 16
 NUMFORMAT = "{{:0{}x}}".format(len(hex(P)[2:]))

 def inverse(number):

 def add(pair1, pair2):

 def multiply(number, pair):

 def convert(pair):

The reason for this convoluted process is so that private keys cannot be derived
from public keys. This allows public keys to be safely shared with anyone. If
you want to learn more, investigate elliptic curve cryptography. The reason for
this name is that historically it followed from calculations of the arc lengths
of ellipses. Together, public and private keys are often referred to as
wallets.

Addresses are formed from the first 20 bytes of the Keccak 256 hashes of public
keys. These are more often used to identify accounts rather than public
keys. Interestingly, public keys cannot be determined solely from addresses.
Here is a Python script that calculates addresses from public keys. It requires
the PySHA3 package. Addresses are typically expressed in hexadecimal notation
and that convention is followed in this script:

 #!/usr/bin/env python3

 """
 Calculates ETC addresses from ETC public keys.

 Usage: etcaddress
 """

 import sha3
 import binascii
 import sys

 NADDRESSBYTES = 20
 NPUBKEYBYTES = 64

 publickey = (int(sys.argv[1])).tobytes(NPUBKEYBYTES, byteorder = "big")
 print(sha3.keccak256(publickey).hexdigest()[-2 * NADDRESSBYTES:])

Here is a slightly edited session, on a Linux computer, that calculates a public
key and address with regards to a random private key. It uses the aforementioned
scripts saved in files called etcpubkey and etcaddress respectively:

 % PRIVATEKEY="92788259381212812445638172234843282167646237087212249687358593145563035518424"

 % PUBLICKEY=etcpubkey $PRIVATEKEY

 % ADDRESS=etcaddress $PUBLICKEY

 % echo $PRIVATEKEY
 92788259381212812445638172234843282167646237087212249687358593145563035518424

 % echo $PUBLICKEY
 9808854183897174607002157792089896992612613490844656534725423301978228163634425857099752732031947328803605451685330420628756154476771607661633738743568351

 % echo $ADDRESS
 89b44e4d3c81ede05d0f5de8d1a68f754d73d997

Ether & Gas

To create and utilize smart contracts, user submit transactions. Transactions
must pay for these services in classic ether. Classic ether can be obtained by
purchasing it or by mining. The smallest denomination of classic ether used in
the ETC system is 1 wei. One billion billion (10¹⁸) weis equal a single classic
ether. Due to the mining reward formula, the total supply of classic ether will
never exceed 210.6 million tokens.

The cost of creating and executing all smart contracts is measured in a made up
unit referred to as gas units. Users submit transactions that pay for gas units
in terms of classic ether. Notice that while the price of classic ether
fluctuates, the price of various services in terms of gas units does not. In
transactions, user specify how much classic ether they are willing to pay per
gas unit. For security reasons, the amount of gas that can be purchased and
used by blocks is limited.

Appendices

blank

 recursivelengthprefix
 roothashes
 bloomfilters
 digitalsignatures
 hownodesfindeachother
 codeislawprinciple
 cryptodecenman
 decofind
 glossary

Blocks

The ETC blockchain is composed of an array of blocks. Blocks contain three
categories of information: computation, consensus and context. Blocks
contain transaction related information (computation), mining related
information (consensus), and, information to properly locate blocks
on the blockchain (context). All components except for two lists form the block
headers.

Computation

Transactions initiate all activity on the world computer. This category
contains information related to this computation. Specifically, these
block components consist of the following:

transaction list
 lists of transactions

transactions root (transaction list root hash)

gas used (transaction list total gas requirement)
 gas requirements for all the transactions in the transaction list

state root (transaction list final state root hash)

 is applied

receipts root (transaction log list root hash)

logs Bloom (transaction log list Bloom filter)

It may seem problematic that blocks only contain root hashes of states and
transaction logs. Nevertheless, the full specification of any state or
transaction log can always be obtained by reapplying all the transactions on the
blockchain with respect to the initial state.

Consensus

Mining is the process of creating and validating new blocks. This is referred to
as mining because the participants (miners) are rewarded with newly created
ETC. The mining procedure is referred to as the consensus algorithm as it helps
users of ETC agree on an ordered set of transactions. This involves a race to
find certain numbers necessary to create new blocks. These numbers are referred
to as proof of work information because they are "proof" that a certain amount
of computational work was done. The block candidates that lose this race are
referred to as the uncle blocks since they are related to the parents or last
blocks added. These block components consist of the following:

extra data (miner extra data)
 32 unused bytes added by miners

beneficiary (miner address)
 addresses with respect to block mining rewards

mix hash (miner validation help)
 values that help miners validate blocks faster

gas limit (miner gas maximum)
 maximum possible gas requirements to apply all transactions in blocks

nonce (proof of work information)
 the number required to add blocks to the blockchain

difficulty (proof of work difficulty)
 difficulty of finding proof of work information for the block

ommer header list (uncle header list)
 lists of the headers of the associated uncles

ommers hash (uncle header list root hash)
 Keccak 256 hashes of uncle header lists

The miner validation help components are necessary because slow block validation
risks certain denial of service attacks. Miners are able to make slight
adjustments to the miner gas maxima of the next blocks they create if desired.
Uncles improve security by making attacks require performing more work. The
consensus algorithm automatically increases the proof of work difficulty for the
next blocks when new blocks are being added too quickly. Likewise, the proof of
work difficulty decreases when new blocks are being added too slowly.

Context

Blocks must always located correctly in the blockchain. Here are the blockchain
components pertaining to context.

number (block number)
 the numbers of blocks that must precede blocks on the blockchain

parent hash (parent header hash)
 Keccak 256 hash of parent block headers

timestamp (date & time)
 dates and times that blocks were added to the blockchain

The parent block of a block is the preceding block on the blockchain. Dates and
times are denoted by the number of seconds since 1970–01–01 00:00:00 UTC.

Accounts

There is no explicit account information in the blockchain. The only account
information is the state root hash. To obtain account information, all the
transactions in all the blocks of the blockchain must be implemented on the
world computer with respect to the initial state.

Bloom Filters

Millions of people search the Internet, government databases, private databases
and blockchains everyday for medical advice, financial updates, weather reports,
maps and more. Likewise, millions of people want or need fast searches.

An effective method to speed up many searches is the use of indexes. Indexes,
like those at back of textbooks, provide the locations of all search terms. A
possible drawback is that they require large amounts of storage.

An effective method to speed up many searches, with less storage requirements,
is the use of Bloom filters. These are important in many areas such as mobile
and embedded devices.

Bloom filters are binary strings used to quickly determine set membership with
nominal storage requirements. Browsers use them to detect malicious
websites. Databases use them to avoid searching for nonexistent data.

Bloom filters require less memory than indexes, but, they sometimes give false
positives. In other words, they might claim an object is a member of a set when
it is not. It is noteworthy that Bloom filters never give false negatives. They
never claim an object is not in a set when it actually is. Browser Bloom filters
might incorrectly claim safe websites are malicious, but, they will never claim
malicious websites are safe. Fortunately, extra checks can always be performed
to eliminate any false positives.

To build a Bloom filter for the set {X₁, X₂, X₃, ..., X:subscript:n}, with
hash function H, calculate H(X₁) | H(X₂) | H(X₃) | ... | H(X:subscript:n). |
is the bitwise OR operator. H is only valid if the number of set bits (ones) in
all hashes is always less than or equal to some selected maximum.

Larger Bloom filters have less false positives. Bloom filters of several
megabytes are not uncommon. As hash functions typically do not have large enough
hashes, not to mention hashes with required number of set bits, adequate hashes
are often constructed from multiple hash functions. A common recipe is to have a
group of hash functions each set a single bit in the construction of a valid
hash. For example, to set a bit in a hash with 2²³ bits, the first 23 bits of
the Secure Hash Algorithm 1 (SHA1) hash can be used to select the position of a
bit to set.

To determine if an object X might be in a set with Bloom filter B, built with
hash function H, determine if H(X) & B = H(X). & is the bitwise AND
operator. Notice that the test only returns true if all the set bits in H(X) are
also set in B. Basically, groups of set bits in B correspond to elements. X
might be a member of the set if and only if its group of set bits corresponds to
a group in B. The reason B can only determine if X might be in the set is
because B contains the bits of several elements.

Bloom filters also allow light clients to
quickly and privately obtain account information without downloading the entire
blockchain.

Bloom filters are a powerful tool that allows additional innovation in
blockchain applications and many other areas in the twenty first century.

Clients

To interact with the ETC world computer requires communicating with a computer
on the ETC network. It is relatively easy to set up a computer to become part
of the network. This requires the installation of an implementation of the ETC
communication protocols.

Ethereum Classic Network Clients

Last Update: March 2020

+---------------------------------------------------------+------------+---------------------------------------------------------------------+-----------------------------------------------------+
| Client Name | Status | Repository | Support |
+=========================================================+============+=====================================================================+=====================================================+
| Core-Geth https://core-geth.org/ | Maintained | releases https://github.com/etclabscore/core-geth/releases | gitter https://gitter.im/core-geth/community |
+---------------------------------------------------------+------------+---------------------------------------------------------------------+-----------------------------------------------------+
| Hyperledger Besu https://besu.hyperledger.org/ | Maintained | releases https://github.com/hyperledger/besu/releases | rocket chat https://chat.hyperledger.org/ |
+---------------------------------------------------------+------------+---------------------------------------------------------------------+-----------------------------------------------------+
| Multi-Geth https://github.com/multi-geth | Maintained | releases https://github.com/multi-geth/multi-geth/releases | gitter https://gitter.im/multi-geth/community |
+---------------------------------------------------------+------------+---------------------------------------------------------------------+-----------------------------------------------------+
| OpenEthereum https://github.com/openethereum | Maintained | releases https://github.com/openethereum/openethereum/releases | discord http://discord.io/openethereum |
+---------------------------------------------------------+------------+---------------------------------------------------------------------+-----------------------------------------------------+

To use ETC, it is not necessary to set up a new computer on the
network. Applications can simply request information from other network
computers. Such applications are referred to as light clients. Whether using
a light client or setting up a full network computer, users can communicate with
the ETC network using Web 3.

Web 3

Web3 refers to a standard set of ETC application programming interfaces using
the Javascript Object Notation Remote Procedue Call (JSON RPC) protocol. Web3
provides a convenient way to interact with ETC nodes and the ETC system. The
name Web3 refers to the most ambitious goal for Ethereum Classic (ETC) which is
to replace the World Wide Web (Web). Blockchain based replacements for the Web
are often referred to as Web 3.0.

The Web was developed by Tim Berners-Lee and first made publicly available in
1991. It is a user friendly general purpose system based on the Internet.
Initially the Web mainly contained simple static content such as primitive
personal home pages. As the Web evolved, greater dynamism and interactivity was
possible such as with social media. This improved Web is often referred to as
Web 2.0. The term was popularized by Tim O’Reilly.

Neither the Internet nor the Web were initially designed to be trustless
systems. Components have been steadily introduced to improve security such as
Transport Layer Security (TLS), certificate authorities, and, Domain Name System
Security Extensions (DNSSEC). Unfortunately, many such improvements are only
partially adopted.

Gavin Wood popularized the term Web 3.0 for blockchain based trustless
alternatives to the Web. Confusingly, Web 3.0 also sometimes refers to the
Semantic Web.

Web 3.0 is a peer to peer replacement for the Web. A peer to peer architecture
is required to build trustless systems. Web 3.0 users are pseudonymous. They
are only identified by their accounts, unlike the Web, where addresses can be
associated with identities. ETC requires access to additional short and long
term storage systems to replace the Web. The InterPlanetary File System (IPFS)
is an example of a compelling peer to peer storage system that can integrate
with ETC.

The Web currently coexists with blockchain systems. Websites access these
systems to provide additional functionality. As ETC and related systems mature,
browsers will increasingly just point to these Web alternatives thus ushering in
the era of Web 3.0.

Code Is Law Principle

The code is law principle is the principle that no one has the right to censor
the execution of code on the ETC blockchain.

Creative Commons Legal Code
CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER.

# Creative Commons Attribution 4.0 International Public License
By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.

## Section 1 – Definitions.
Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
Licensor means the individual(s) or entity(ies) granting rights under this Public License.
Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
## Section 2 – Scope.
License grant.
Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
reproduce and Share the Licensed Material, in whole or in part; and
produce, reproduce, and Share Adapted Material.
Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
Term. The term of this Public License is specified in Section 6(a).
Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
Downstream recipients.
Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
Other rights.

Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
Patent and trademark rights are not licensed under this Public License.
To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
## Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

Attribution.

If You Share the Licensed Material (including in modified form), You must:

retain the following if it is supplied by the Licensor with the Licensed Material:
identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
a copyright notice;
a notice that refers to this Public License;
a notice that refers to the disclaimer of warranties;
a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License.
## Section 4 – Sui Generis Database Rights.
Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:

for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and
You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
## Section 5 – Disclaimer of Warranties and Limitation of Liability.
Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
## Section 6 – Term and Termination.
This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:

automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
upon express reinstatement by the Licensor.
For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
## Section 7 – Other Terms and Conditions.
The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.

## Section 8 – Interpretation.
For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.

This work is licensed under a Creative Commons Attribution 4.0 International License .



 Declaración del Futuro de Ethereum Classic

-

 Hace poco tiempo en un navegador muy, muy cerca ...

ETHEREUM CLASSIC Declaración del Futuro

 ARTÍCULO 1
Declaración del Futuro de Ethereum Classic

 Que se sepa en todo el mundo que el 20 de Julio de 2016, en el bloque 1.920.000, nosotros como una comunidad de individuos soberanos permanecemos unidos por una visión común de continuar la cadena de bloques original de Ethereum que está verdaderamente libre de censura, fraude o interferencia de terceros. Al percibir que la cadena de bloques representa la verdad absoluta, reafirmamos nuestro apoyo a su inmutabilidad y su futuro. No hacemos esta declaración a la ligera, no sin prevenir las consecuencias de nuestras acciones.

 Mirando atras

 Debemos recalcar con gran gratitud que reconocemos la creación de la plataforma de la cadena de bloques de Ethereum por la Fundación Ethereum y sus desarrolladores fundadores. Ciertamente podemos decir sin ninguna objeción, que sin su trabajo duro y dedicación nosotros como comunidad no estaríamos donde estamos hoy.

 Desde su comienzo, la cadena de bloques de Ethereum se presentó como una plataforma descentralizada “para aplicaciones que se ejecutan exactamente según lo programado sin ninguna oportunidad de fraude, censura, o interferencia de terceros" 1 . Proporciona un lugar para la libre asociación de ideas y aplicaciones desde todas partes del mundo sin temor a discriminación mientras que también proporciona pseudo-anonimidad. En esta plataforma descentralizada muchos de nosotros vimos grandes posibilidades.

 Lista de Agravios

 Sin embargo, es un profundo pesar que como comunidad hayamos tenido que organizarnos espontáneamente 2 para defender la plataforma de cadena de bloques Ethereum de sus miembros y organización fundadora debido a una larga cadena de abusos, específicamente por los líderes de la Fundación Ethereum. Estos agravios son los siguientes:

 - - Por acelerar la creación de un soft fork, el cual era un cambio menor del código de la cadena de bloques de Ethereum con el solo propósito de crear una lista negra y censurar transacciones que normalmente deberían haber sido permitidas.

 - - Por descuidar las implicaciones completas del soft fork de la cadena de bloques de Ethereum como una advertencia de que estaban violando los principios y valores codificados en el mismo. 3

 - - Por la creación de un mecanismo de votación no representativo llamado el “voto de carbono”, el cual manifestaron inicialmente que no era oficial 4 para contradecir esto un día antes de decidir el hard fork. 5

 - - Por apresurar la creación de un hard fork, el cual estaba compuesto de un cambio irregular de estado en el código de la cadena de bloques de Ethereum que violó las propiedades de inmutabilidad, fungibilidad y la santidad del ledger

 - - Por decidir deliberadamente no incluir protección contra “ataque por repetición” en el hard fork, una acción que ha costado a las casas de cambio y miles de usuarios la propiedad legítima de sus fichas de Ether.
 6

 Respeto de los valores esenciales de las cadenas de bloques

 Uno puede preguntar qué daño puede causarse por cambiar el código de la cadena de bloques de Ethereum y rescatar 7 a los dueños de sus fichas de “THE DAO”, lo cual no es una pregunta sin sentido. Muchos de nosotros tenemos un sentido innato de lo correcto e incorrecto, por lo que en un primer vistazo rescatar “THE DAO” parece correcto. Sin embargo, se violaron dos aspectos fundamentales que dan al dinero peer-to-peer 8 y a sistemas basados en contratos inteligentes su principal valor: fungibilidad e inmutabilidad.

 Inmutabilidad significa que la cadena de bloques es inviolable. Que solo transacciones validas acordadas via un protocolo criptográfico determinado por matemáticas son aceptadas por la red. Sin esto, la validez de todas las transacciones podría ser cuestionada, ya que si la red de bloques es mutable, cualquier transacción podría ser modificada. Esto no sólo deja las transacciones abiertas a fraude, sino que podría significar un desastre para cualquier aplicación corriendo sobre la plataforma.

 Fungibilidad es la característica del dinero por la cual una unidad es igual a otra unidad. Por ejemplo, un Euro es igual a otro Euro lo mismo que un Bitcoin es igual que otro Bitcoin. Desafortunadamente, un ETH ya no es igual a otro ETH. El ETH del presunto atacante ya no era tan bueno como tu ETH y era digno de ser censurado, algo considerado necesario por la supuesta mayoría.

 En última instancia, estos incumplimientos de la fungibilidad e inmutabilidad fueron posibles por los juicios morales subjetivos de los que sintieron un ardiente deseo de llevar al supuesto atacante ante la justicia. Sin embargo, al hacerlo comprometieron un pilar fundamental de Ethereum pensando que era en interés del “bien común”.

 Profundamente alarmados de que estos principios básicos fueron ignorados por muchos de los desarrolladores de la Fundación, y una parte considerable de los participantes de Ethereum, nosotros, como comunidad, hemos organizado y formado un código de principios a seguir para la cadena de Ethereum Clásico.

 Código de principios de Ethereum Clásico

 Creemos en una cadena de bloques descentralizada, resistente a la censura y de libre acceso. Creemos en la visión original de Ethereum como un ordenador global que no puede ser apagado, ejecutando de forma irreversible contratos inteligentes. Creemos en una fuerte separación de intereses, donde bifurcaciones sólo son posibles cuando tratan de solucionar vulnerabilidades a nivel del protocolo, errores, o proporcionar mejoras de funcionalidad. Creemos en la intención original de construir y mantener una plataforma resistente a la censura, desconfiada e inmutable.

 En este documento se escriben los valores declarados en cuales los participantes de la comunidad de Ethereum Classic están de acuerdo. Animamos a que estos principios no se puedan cambiar a través de un edicto por cualquier individuo o grupo que diga tener el poder, autoridad o credibilidad para hacerlo.

 Como comunidad estamos de acuerdo en:

 - - El propósito de Ethereum Classic es de proporcionar una plataforma descentralizada que corre aplicaciones descentralizadas que se ejecutan exactamente tal y como fueron programadas, sin ninguna posibilidad de inactividad, censura, fraude o interferencia de terceros.

 - - Código es ley; No habrá cambios en el código de Ethereum Classic que violen las propiedades de inmutabilidad, fungibilidad o santidad del ledger. Bajo ningún motivo se podrán modificar o invertir las transacciones o el historial del ledger.

 - - Forks y cambios del protocolo subyacente sólo estarán permitidos para la actualización de la tecnología en la que Ethereum Classic opera.

 - - El desarrollo interno del proyecto puede ser financiado por cualquier persona, ya sea a través de un tercero de confianza o directamente, usando la moneda de su elección o por proyecto y siguiendo un protocolo de financiación colectiva abierto y descentralizado.

 - - Cualquier individuo o grupo de individuos pueden proponer mejoras, ampliaciones o actualizaciones a las propuestas existentes o planteadas sobre Ethereum Classic.

 - - Cualquier individuo o grupo de individuos pueden utilizar la plataforma descentralizada Ethereum Classic para construir aplicaciones descentralizadas, crear ventas colectivas, crear organizaciones/corporaciones autónomas, o para cualquier otro propósito que se estime conveniente.

 Mirando hacia adelante

 Por las razones anteriormente mencionadas, hemos optado por renombrar el nombre de la cadena de bloques original "Ethereum Classic" con el símbolo "ETC" para que la comunidad y otros participantes puedan identificar la cadena de bloques original, sin forks e inmutable.

 Nuestro más sincero agradecimiento va para todos los desarrolladores dentro y fuera de la Fundación que se opusieron a interferir en la cadena de bloques de Ethereum y permitieron la supervivencia de Ethereum Classic. Sabemos que son muchas las personas interesadas y les damos la bienvenida a los que quieran unirse a nuestra comunidad descentralizada.

 Vamos a continuar con la visión de un gobierno descentralizado para la cadena de bloques de Ethereum Classic y mantendremos nuestra oposición ante cualquier intento de dirección centralizada, especialmente por la Fundación Ethereum, así como por los desarrolladores que han declarado en repetidas ocasiones que no van a continuar trabajando en la cadena de bloques de Ethereum Classic.

 Así mismo vamos a resistir abiertamente a la “tiranía de la mayoría” y no permitiremos que los valores del sistema sean comprometidos. Como una comunidad unida, continuaremos organizándonos por la defensa y promoción, según sea necesario, para la continuidad y garantía de este gran experimento. La plataforma Ethereum Classic, su código y tecnología, están ahora abiertas al mundo como software de código abierto 9 . Ahora es de libre acceso para todos los que deseen mejorar y construir sobre ella; una computadora mundial realmente libre que nosotros, como comunidad, hemos demostrado y continuaremos demostrando que es “antifrágil” 10 .



 Declaración del Futuro de Ethereum Classic

-

 Hace poco tiempo en un navegador muy, muy cerca ...

ETHEREUM CLASSIC Declaración del Futuro

 ARTÍCULO 1
Declaración del Futuro de Ethereum Classic

 Que se sepa en todo el mundo que el 20 de Julio de 2016, en el bloque 1.920.000, nosotros como una comunidad de individuos soberanos permanecemos unidos por una visión común de continuar la cadena de bloques original de Ethereum que está verdaderamente libre de censura, fraude o interferencia de terceros. Al percibir que la cadena de bloques representa la verdad absoluta, reafirmamos nuestro apoyo a su inmutabilidad y su futuro. No hacemos esta declaración a la ligera, no sin prevenir las consecuencias de nuestras acciones.

 Mirando atras

 Debemos recalcar con gran gratitud que reconocemos la creación de la plataforma de la cadena de bloques de Ethereum por la Fundación Ethereum y sus desarrolladores fundadores. Ciertamente podemos decir sin ninguna objeción, que sin su trabajo duro y dedicación nosotros como comunidad no estaríamos donde estamos hoy.

 Desde su comienzo, la cadena de bloques de Ethereum se presentó como una plataforma descentralizada “para aplicaciones que se ejecutan exactamente según lo programado sin ninguna oportunidad de fraude, censura, o interferencia de terceros" 1 . Proporciona un lugar para la libre asociación de ideas y aplicaciones desde todas partes del mundo sin temor a discriminación mientras que también proporciona pseudo-anonimidad. En esta plataforma descentralizada muchos de nosotros vimos grandes posibilidades.

 Lista de Agravios

 Sin embargo, es un profundo pesar que como comunidad hayamos tenido que organizarnos espontáneamente 2 para defender la plataforma de cadena de bloques Ethereum de sus miembros y organización fundadora debido a una larga cadena de abusos, específicamente por los líderes de la Fundación Ethereum. Estos agravios son los siguientes:

 - - Por acelerar la creación de un soft fork, el cual era un cambio menor del código de la cadena de bloques de Ethereum con el solo propósito de crear una lista negra y censurar transacciones que normalmente deberían haber sido permitidas.

 - - Por descuidar las implicaciones completas del soft fork de la cadena de bloques de Ethereum como una advertencia de que estaban violando los principios y valores codificados en el mismo. 3

 - - Por la creación de un mecanismo de votación no representativo llamado el “voto de carbono”, el cual manifestaron inicialmente que no era oficial 4 para contradecir esto un día antes de decidir el hard fork. 5

 - - Por apresurar la creación de un hard fork, el cual estaba compuesto de un cambio irregular de estado en el código de la cadena de bloques de Ethereum que violó las propiedades de inmutabilidad, fungibilidad y la santidad del ledger

 - - Por decidir deliberadamente no incluir protección contra “ataque por repetición” en el hard fork, una acción que ha costado a las casas de cambio y miles de usuarios la propiedad legítima de sus fichas de Ether.
 6

 Respeto de los valores esenciales de las cadenas de bloques

 Uno puede preguntar qué daño puede causarse por cambiar el código de la cadena de bloques de Ethereum y rescatar 7 a los dueños de sus fichas de “THE DAO”, lo cual no es una pregunta sin sentido. Muchos de nosotros tenemos un sentido innato de lo correcto e incorrecto, por lo que en un primer vistazo rescatar “THE DAO” parece correcto. Sin embargo, se violaron dos aspectos fundamentales que dan al dinero peer-to-peer 8 y a sistemas basados en contratos inteligentes su principal valor: fungibilidad e inmutabilidad.

 Inmutabilidad significa que la cadena de bloques es inviolable. Que solo transacciones validas acordadas via un protocolo criptográfico determinado por matemáticas son aceptadas por la red. Sin esto, la validez de todas las transacciones podría ser cuestionada, ya que si la red de bloques es mutable, cualquier transacción podría ser modificada. Esto no sólo deja las transacciones abiertas a fraude, sino que podría significar un desastre para cualquier aplicación corriendo sobre la plataforma.

 Fungibilidad es la característica del dinero por la cual una unidad es igual a otra unidad. Por ejemplo, un Euro es igual a otro Euro lo mismo que un Bitcoin es igual que otro Bitcoin. Desafortunadamente, un ETH ya no es igual a otro ETH. El ETH del presunto atacante ya no era tan bueno como tu ETH y era digno de ser censurado, algo considerado necesario por la supuesta mayoría.

 En última instancia, estos incumplimientos de la fungibilidad e inmutabilidad fueron posibles por los juicios morales subjetivos de los que sintieron un ardiente deseo de llevar al supuesto atacante ante la justicia. Sin embargo, al hacerlo comprometieron un pilar fundamental de Ethereum pensando que era en interés del “bien común”.

 Profundamente alarmados de que estos principios básicos fueron ignorados por muchos de los desarrolladores de la Fundación, y una parte considerable de los participantes de Ethereum, nosotros, como comunidad, hemos organizado y formado un código de principios a seguir para la cadena de Ethereum Clásico.

 Código de principios de Ethereum Clásico

 Creemos en una cadena de bloques descentralizada, resistente a la censura y de libre acceso. Creemos en la visión original de Ethereum como un ordenador global que no puede ser apagado, ejecutando de forma irreversible contratos inteligentes. Creemos en una fuerte separación de intereses, donde bifurcaciones sólo son posibles cuando tratan de solucionar vulnerabilidades a nivel del protocolo, errores, o proporcionar mejoras de funcionalidad. Creemos en la intención original de construir y mantener una plataforma resistente a la censura, desconfiada e inmutable.

 En este documento se escriben los valores declarados en cuales los participantes de la comunidad de Ethereum Classic están de acuerdo. Animamos a que estos principios no se puedan cambiar a través de un edicto por cualquier individuo o grupo que diga tener el poder, autoridad o credibilidad para hacerlo.

 Como comunidad estamos de acuerdo en:

 - - El propósito de Ethereum Classic es de proporcionar una plataforma descentralizada que corre aplicaciones descentralizadas que se ejecutan exactamente tal y como fueron programadas, sin ninguna posibilidad de inactividad, censura, fraude o interferencia de terceros.

 - - Código es ley; No habrá cambios en el código de Ethereum Classic que violen las propiedades de inmutabilidad, fungibilidad o santidad del ledger. Bajo ningún motivo se podrán modificar o invertir las transacciones o el historial del ledger.

 - - Forks y cambios del protocolo subyacente sólo estarán permitidos para la actualización de la tecnología en la que Ethereum Classic opera.

 - - El desarrollo interno del proyecto puede ser financiado por cualquier persona, ya sea a través de un tercero de confianza o directamente, usando la moneda de su elección o por proyecto y siguiendo un protocolo de financiación colectiva abierto y descentralizado.

 - - Cualquier individuo o grupo de individuos pueden proponer mejoras, ampliaciones o actualizaciones a las propuestas existentes o planteadas sobre Ethereum Classic.

 - - Cualquier individuo o grupo de individuos pueden utilizar la plataforma descentralizada Ethereum Classic para construir aplicaciones descentralizadas, crear ventas colectivas, crear organizaciones/corporaciones autónomas, o para cualquier otro propósito que se estime conveniente.

 Mirando hacia adelante

 Por las razones anteriormente mencionadas, hemos optado por renombrar el nombre de la cadena de bloques original "Ethereum Classic" con el símbolo "ETC" para que la comunidad y otros participantes puedan identificar la cadena de bloques original, sin forks e inmutable.

 Nuestro más sincero agradecimiento va para todos los desarrolladores dentro y fuera de la Fundación que se opusieron a interferir en la cadena de bloques de Ethereum y permitieron la supervivencia de Ethereum Classic. Sabemos que son muchas las personas interesadas y les damos la bienvenida a los que quieran unirse a nuestra comunidad descentralizada.

 Vamos a continuar con la visión de un gobierno descentralizado para la cadena de bloques de Ethereum Classic y mantendremos nuestra oposición ante cualquier intento de dirección centralizada, especialmente por la Fundación Ethereum, así como por los desarrolladores que han declarado en repetidas ocasiones que no van a continuar trabajando en la cadena de bloques de Ethereum Classic.

 Así mismo vamos a resistir abiertamente a la “tiranía de la mayoría” y no permitiremos que los valores del sistema sean comprometidos. Como una comunidad unida, continuaremos organizándonos por la defensa y promoción, según sea necesario, para la continuidad y garantía de este gran experimento. La plataforma Ethereum Classic, su código y tecnología, están ahora abiertas al mundo como software de código abierto 9 . Ahora es de libre acceso para todos los que deseen mejorar y construir sobre ella; una computadora mundial realmente libre que nosotros, como comunidad, hemos demostrado y continuaremos demostrando que es “antifrágil” 10 .



 Declaração sobre o Futuro da Ethereum Classic
-

 Há pouco tempo atrás em um navegador muito, muito perto…

ETHEREUM CLASSIC Declaração de Independência

 ARTIGO 1
Declaração de Independência da Ethereum Classic

 Que seja conhecido por todo o mundo que em 20 de julho de 2016, a partir do bloco 1.920.000, nós, como uma comunidade de indivíduos soberanos, ficamos unidos por uma visão comum de continuar a cadeia de blocos original da Ethereum que é verdadeiramente livre de censura, fraude ou interferência de terceiros . Em percebendo-se que a cadeia de blocos representa a verdade absoluta, nós permanecemos ao lado dela, apoiando a sua imutabilidade e seu futuro. Nós não fazemos esta declaração de ânimo leve, nem sem premeditação para as consequências de nossos atos.

 Olhando-se para Trás

 Deve-se afirmar com grande gratidão que nós reconhecemos a criação da cadeia de blocos da plataforma Ethereum pela Fundação Ethereum e seus desenvolvedores fundadores. Certamente pode ser dito sem objeção, que sem seu trabalho árduo e dedicação nós como uma comunidade não estaríamos onde estamos hoje.

 Desde a sua incepção, a cadeia de blocos Ethereum foi apresentada como uma plataforma descentralizada para "aplicativos que são executados exatamente como programados sem qualquer possibilidade de fraude, censura ou interferência de terceiros" 1 . Ela forneceu um lugar para a associação livre de idéias e aplicações de todo o mundo, sem medo de discriminação enquanto também proporciona pseudonimato. Nesta plataforma descentralizada, muitos de nós viu uma grande promessa.

 Lista de Queixas

 É, no entanto, com profundo pesar, que nós, como uma comunidade tivemos que espontaneamente organizar-nos 2 para defender a plataforma de cadeia de blocos Ethereum de seus membros fundadores e organização devido a uma longa série de abusos, especialmente pela liderança da Fundação Ethereum. Estas queixas são conforme a seguir:

 - - Por apressar a criação de uma "bifurcação suave", que foi composta de uma pequena alteração no código da cadeia de blocos Ethereum com o único propósito de criar uma lista negra e censurar transações que normalmente teriam sido autorizadas.

 - - Por negligenciar as plenas implicações da "bifurcação suave" pela cadeia de blocos Ethereum como um aviso de que eles estavam violando os princípios e valores nela codificadas 3 .

 - - Por criar um mecanismo de votação não representativo chamado de "voto de carbono", que eles inicialmente declararam ser "não oficial" 4 , apenas para contradizer essas declarações um dia antes de determinar a bifurcação dura. 5

 - - Por apressar a criação de uma "bifurcação dura", que foi composta de uma mudança de estado irregular no código da cadeia de blocos Ethereum que violou as propriedades de imutabilidade, fungibilidade e da santidade da contabilidade.

 - - Por voluntariamente decidir não incluir a proteção de repetição na "bifurcação dura", uma ação que tem desnecessariamente custado a casas de câmbio e milhares de usuários o pleno direito à titularidade das suas fichas éter.
 6

 Respeitando os Valores Essenciais para as Cadeias de Bloco

 Pode-se perguntar que mal pode ter sido feito a partir da alteração do código da cadeia de blocos Ethereum e resgatar 7 os detentores de fichas da “The DAO”, que não é uma pergunta insensata. Muitos de nós têm um senso inato de certo e errado, por isso, à primeira vista resgatar a "The DAO" parecia certo. No entanto, o resgate violou dois aspectos-chave do que dá valor ao dinheiro ponto-a-ponto 8 e a sistemas baseados em contratos inteligentes: fungibilidade e imutabilidade.

 Imutabilidade significa que a cadeia de blocos é inviolável. Que somente as transações válidas, acordadas através de um protocolo criptográfico determinado pela matemática, são aceitas pela rede. Sem isso, a validade de todas as transações poderia vir à tona, uma vez que se a cadeia de blocos é mutável, qualquer transação poderia ser modificada. Não somente isto deixa as transações abertas à fraude, mas pode significar um desastre para qualquer aplicação distribuída rodando sobre a plataforma.

 Fungibilidade é a característica do dinheiro onde uma unidade é igual a outra unidade. Por exemplo, um Euro é igual a outro Euro assim como um bitcoin é igual a outro bitcoin. Infelizmente, um ETH não é igual a outro ETH. Os ETH do suposto atacante já não eram tão bons quanto os seus ETH e eram dignos de censura, considerada necessária pela tão chamada maioria.

 Em última análise, estas brechas na fungibilidade e na imutabilidade tornaram-se possíveis pelos julgamentos subjetivos de moralidade daqueles que sentiram um desejo ardente de trazer o suposto agressor à justiça. Entretanto, ao fazê-lo eles comprometeram um pilar fundamental da Ethereum apenas para fazer o que eles sentiam que atendia ao interesse do 'bem maior'. Em uma comunidade global onde cada indivíduo tem suas próprias leis, costumes e crenças, quem está para dizer o que é certo e errado?

 Profundamente alarmados que esses princípios fundamentais não foram considerados por muitos dos desenvolvedores da Fundação, e uma parcela considerável dos participantes da Ethereum, nós, como uma comunidade, organizamos e formamos um código de princípios a seguir para a cadeia Ethereum Classic.

 O Código de Princípios da Ethereum Classic

 Acreditamos em uma cadeia de blocos de acesso livre, resistente à censura. Nós acreditamos na visão original da Ethereum como um computador mundial que não pode ser desligado, executando contratos inteligentes irreversíveis. Acreditamos em uma forte separação de interesses, onde só são possíveis bifurcações de sistema da base de código quando corrigem vulnerabilidades a nível de protocolo, falhas, ou fornece atualizações de funcionalidade. Acreditamos na intenção original de construir e manter uma plataforma de desenvolvimento imutável, desconfiada e resistente à censura.

 Aqui estão escritos os valores declarados pelo qual os participantes de dentro da comunidade Ethereum Clássica concordam. Nós encorajamos que estes princípios não sejam alterados via edital por qualquer indivíduo ou facção que alegue exercer o poder, autoridade ou credibilidade para o fazê-lo.

 Nós, como comunidade concordamos que:

 - - O propósito da Ethereum Classic é fornecer uma plataforma descentralizada que executa aplicações descentralizadas que executam exatamente como programadas sem qualquer possibilidade de tempo de inatividade, censura, fraude ou interferência de terceiros.

 - - Código é lei; não haverá alterações no código Ethereum Classic que violem as propriedades de imutabilidade, fungibilidade, ou santidade da contabilidade; transações ou história da contabilidade não podem, por qualquer motivo serem anuladas ou modificadas.

 - - Bifurcações e/ou alterações no protocolo subjacente só deverá ser permitida para atualizar ou melhorar a tecnologia na qual Ethereum Classic opera.

 - - O desenvolvimento de projetos internos podem ser financiados por qualquer pessoa, quer seja através de um terceiro confiável de sua escolha ou diretamente, usando a moeda da sua escolha em uma base por projeto e seguindo um protocolo de financiamento coletivo transparente, aberto e descentralizado.

 - - Qualquer indivíduo ou grupo de indivíduos pode propor melhorias, aperfeiçoamentos ou atualizações de ativos Ethereum Classic existentes ou propostos.

 - - Qualquer indivíduo ou grupo de indivíduos pode utilizar a plataforma descentralizada Ethereum Classic para construir aplicações descentralizadas, manter vendas coletivas, criar organizações / empresas autônomas, ou para qualquer outra finalidade que considere adequada.

 Olhando-se para Frente

 Por muitas razões listadas acima, optamos por mudar o nome da cadeia de blocos original "Ethereum Classic" com o símbolo "ETC", de modo que a comunidade e todos os outros participantes podem identificar a plataforma de cadeia de blocos original, não bifurcada, e imutável.

 Nossa mais sincera gratidão vai para os desenvolvedores dentro e fora da Fundação que se opuseram a interferir na contabilidade da cadeia de blocos Ethereum e permitiram que a cadeia Ethereum Classic pudesse sobreviver e viver. Sabemos que há muitos de vocês e nós lhes damos as boas vindas para a qualquer momento se juntarem à nossa comunidade descentralizada.

 Vamos continuar a visão de governança descentralizada para a cadeia de blocos Ethereum Classic e manter a nossa oposição a qualquer aquisição de liderança centralizada, especialmente pela Fundação Ethereum, bem como pelos desenvolvedores que têm afirmado repetidamente que eles deixariam de desenvolver a cadeia Ethereum Classic.

 Nós, igualmente, resistiremos abertamente a "tirania da maioria," e não permitiremos que os valores do sistema sejam comprometidos. Como uma comunidade unida, continuaremos a organizar pela defesa e anvanço, conforme necessário, para a continuação e garantia deste grande experimento. A plataforma Ethereum Classic, seu código e tecnologia, estão agora abertos para o mundo como software de código fonte aberto 9 . Agora está livremente disponível para todos os que desejam melhorar e construir sobre ele: um computador mundial verdadeiramente livre e desconfiado, que nós juntos como uma comunidade provamos e continuaremos a provar, é anti-frágil 10 .

Declarația de Independență Ethereum Classic
-

 Cu puțin timp în urmă, într-un browser foarte, foarte apropiat…

ETHEREUM CLASSIC Declarație de Independență

 DOCUMENT 1
Declarația de Independență Ethereum Classic

 Să fie cunoscut întregii lumi că, la 20 iulie 2016, la blocul 1.920.000, noi, ca o comunitate de
indivizi suverani, am rămas uniți de o viziune comună: continuarea blockchain-ului original Ethereum,
cu adevărat liber de cenzură, fraudă sau interferență din partea terților. Înțelegând că blockchain-ul
reprezintă adevărul absolut, îl susținem, apărându-i imuabilitatea și viitorul. Nu facem această declarație
cu ușurință și nici fără a lua în calcul consecințele acțiunilor noastre.

 Privind înapoi

 Trebuie spus, cu mare recunoștință, că recunoaștem crearea platformei blockchain Ethereum de către
Ethereum Foundation și dezvoltatorii săi fondatori. Se poate afirma, fără obiecții, că fără munca și
dedicarea lor, noi, ca comunitate, nu am fi ajuns unde suntem astăzi.

 Încă de la început, blockchain-ul Ethereum a fost prezentat ca o platformă descentralizată pentru
„aplicații care rulează exact așa cum sunt programate, fără nicio șansă de fraudă, cenzură sau
interferență din partea terților” 1 . A oferit un loc pentru asocierea liberă a
ideilor și aplicațiilor din întreaga lume, fără teama de discriminare, oferind în același timp pseudonimitate.
În această platformă descentralizată, mulți dintre noi am văzut o mare promisiune.

 Lista nemulțumirilor

 Totuși, cu profund regret, noi, ca comunitate, a trebuit să ne organizăm spontan 2
pentru a apăra platforma blockchain Ethereum de propriii membri fondatori și de organizația lor,
din cauza unui lung șir de abuzuri, în special din partea conducerii Ethereum Foundation.
Aceste nemulțumiri sunt următoarele.

 - - Pentru grăbirea creării unui „soft fork”, constând într-o modificare minoră a codului blockchain-ului
Ethereum, cu scopul exclusiv de a crea o listă neagră și de a cenzura tranzacții care, în mod normal,
ar fi fost permise.

 - - Pentru ignorarea implicațiilor complete ale „soft fork”-ului de către blockchain-ul Ethereum, deși acesta
reprezenta un avertisment că erau încălcate principiile și valorile codificate în el. 3

 - - Pentru crearea unui mecanism de vot nereprezentativ numit „carbon vote”, despre care s-a spus inițial
că este „neoficial” 4 , doar pentru ca aceste afirmații să fie contrazise cu o zi înainte de
luarea deciziei de hard fork. 5

 - - Pentru grăbirea creării unui „hard fork”, care a constat într-o schimbare neregulată a stării în codul
blockchain-ului Ethereum, încălcând proprietățile de imuabilitate, fungibilitate și sanctitatea registrului.

 - - Pentru decizia deliberată de a nu include protecție împotriva replay în „hard fork”, acțiune care a costat
în mod inutil exchange-urile și mii de utilizatori dreptul legitim de proprietate asupra tokenurilor lor Ether. 6

 Respectarea valorilor esențiale ale blockchain-urilor

 Unii ar putea întreba ce rău poate fi făcut prin schimbarea codului blockchain-ului Ethereum și „salvarea” 7
deținătorilor de tokenuri „The DAO”, iar această întrebare nu este una nerezonabilă.
Mulți dintre noi avem un simț înnăscut al binelui și răului, astfel că, la prima vedere, salvarea „The DAO”
părea corectă. Totuși, ea a încălcat două elemente-cheie care dau valoare banilor peer-to-peer 8
și sistemelor bazate pe contracte inteligente: fungibilitatea și imuabilitatea.

 Imuabilitatea înseamnă că blockchain-ul este inviolabil. Numai tranzacțiile valide, acceptate printr-un protocol
criptografic determinat de matematică, sunt aprobate de rețea. Fără acest principiu, validitatea tuturor
tranzacțiilor ar putea fi pusă sub semnul întrebării, deoarece, dacă blockchain-ul este mutabil, orice tranzacție
ar putea fi modificată. Acest lucru nu doar că lasă tranzacțiile deschise fraudei, dar ar putea însemna un
dezastru pentru orice aplicație distribuită construită deasupra platformei.

 Fungibilitatea este caracteristica banilor prin care o unitate este egală cu alta. De exemplu, un Euro este egal
cu alt Euro, la fel cum un Bitcoin este egal cu alt Bitcoin. Din păcate, un ETH nu mai este egal cu alt ETH.
ETH-ul presupusului atacator nu a mai fost considerat la fel de valoros ca ETH-ul tău și a fost considerat
acceptabil pentru cenzură, lucru considerat necesar de o așa-zisă majoritate.

 În cele din urmă, aceste încălcări ale fungibilității și imuabilității au fost posibile din cauza judecăților morale
subiective ale celor care au simțit o dorință puternică de a-l aduce pe presupusul atacator în fața justiției.
Însă, făcând asta, au compromis un pilon de bază al Ethereum doar pentru a face ceea ce au considerat că
este în interesul „binelui comun”. Într-o comunitate globală, în care fiecare individ are propriile legi,
obiceiuri și credințe, cine poate decide ce este bine și ce este rău?

 Profund alarmați că aceste principii de bază au fost ignorate de mulți dintre dezvoltatorii Foundation,
și de o parte semnificativă a participanților Ethereum, noi, ca comunitate, ne-am organizat și am formulat
un cod de principii de urmat pentru lanțul Ethereum Classic.

 Codul de principii Ethereum Classic

 Credem într-un blockchain descentralizat, rezistent la cenzură și fără permisiuni. Credem în viziunea
originală a Ethereum ca un computer global care nu poate fi oprit, rulând contracte inteligente ireversibile.
Credem într-o separare fermă a responsabilităților, în care fork-urile sistemului sunt posibile doar pentru
corectarea vulnerabilităților la nivel de protocol, a erorilor sau pentru adăugarea de îmbunătățiri funcționale.
Credem în intenția inițială de a construi și menține o platformă de dezvoltare rezistentă la cenzură,
fără încredere implicită și imuabilă.

 Aici sunt consemnate valorile declarate asupra cărora participanții din comunitatea Ethereum Classic sunt de
acord. Încurajăm ca aceste principii să nu fie schimbate prin edict de către niciun individ sau facțiune care
pretinde că deține puterea, autoritatea sau credibilitatea de a face acest lucru.

 Noi, ca comunitate, suntem de acord că:

 - - Scopul Ethereum Classic este de a oferi o platformă descentralizată care rulează aplicații descentralizate
executate exact așa cum au fost programate, fără nicio posibilitate de oprire, cenzură, fraudă sau
interferență din partea terților.

 - - Codul este lege; nu vor exista schimbări în codul Ethereum Classic care să încalce proprietățile de
imuabilitate, fungibilitate sau sanctitatea registrului; tranzacțiile ori istoricul registrului nu pot fi,
din niciun motiv, anulate sau modificate.

 - - Fork-urile și/sau modificările protocolului de bază vor fi permise doar pentru actualizarea sau
îmbunătățirea tehnologiei pe care funcționează Ethereum Classic.

 - - Dezvoltarea internă a proiectului poate fi finanțată de oricine, fie printr-un terț de încredere ales,
fie direct, folosind moneda preferată, pe bază de proiect, și urmând un protocol de crowdfunding
transparent, deschis și descentralizat.

 - - Orice individ sau grup de indivizi poate propune îmbunătățiri, extensii ori actualizări ale activelor
Ethereum Classic existente sau propuse.

 - - Orice individ sau grup de indivizi poate folosi platforma descentralizată Ethereum Classic pentru a
construi aplicații descentralizate, a organiza crowdsale-uri, a crea organizații/corporații autonome sau
pentru orice alt scop pe care îl consideră potrivit.

 Privind înainte

 Din numeroasele motive enumerate mai sus, am ales să redenumim blockchain-ul original „Ethereum Classic”,
cu simbolul „ETC”, astfel încât comunitatea și toți ceilalți participanți să poată identifica blockchain-ul original,
nefork-uit și imuabil.

 Cele mai sincere mulțumiri merg către acei dezvoltatori din interiorul și din afara Foundation care s-au opus
intervenției asupra registrului blockchain Ethereum și au făcut posibilă supraviețuirea lanțului Ethereum Classic.
Știm că sunteți mulți și vă primim oricând să vă alăturați comunității noastre descentralizate.

 Vom continua viziunea guvernanței descentralizate pentru blockchain-ul Ethereum Classic și ne vom menține
opoziția față de orice tentativă de preluare a unei conduceri centralizate, în special din partea Ethereum Foundation,
precum și a dezvoltatorilor care au declarat în repetate rânduri că nu vor mai dezvolta lanțul Ethereum Classic.

 De asemenea, vom rezista deschis „tiraniei majorității” și nu vom permite compromiterea valorilor sistemului.
Ca o comunitate unită, vom continua să ne organizăm pentru apărarea și avansarea, atunci când este necesar,
a acestui mare experiment. Platforma Ethereum Classic, codul și tehnologia sa sunt acum deschise lumii ca
software Open Source 9 . Sunt acum disponibile liber pentru toți cei care doresc
să le îmbunătățească și să construiască pe baza lor: un computer global cu adevărat liber și fără încredere
implicită, despre care noi, ca comunitate, am demonstrat și vom continua să demonstrăm că este anti-fragil 10 .

Digital Signatures

Ethereum Classic (ETC) digital signatures secure transactions. These involve
elliptic curve cryptography and the Elliptic Curve Digital Signature Algorithm
(ECDSA). I will describe ETC digital signatures without these topics using only
small Python functions.

Signing and verifying will be implemented using the following four constants and
three functions:

 N = 115792089237316195423570985008687907852837564279074904382605163141518161494337
 P = 115792089237316195423570985008687907853269984665640564039457584007908834671663
 Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
 Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424

 def invert(number, modulus):

 def add(pair1, pair2):

 def multiply(number, pair):

The invert function defines an operation on numbers in terms of other numbers
referred to as moduli. The add function defines an operation on pairs of
numbers. The multiply function defines an operation on a number and a pair of
numbers. Here are examples of their usage:

>> invert(82856, 7164661)
 3032150
>> add([84672, 5768], [15684, 471346])
 [98868508778765247164450388534339365517943901419260061027507991295919394382071, 110531019976596004792591549651085191890711482591841040377832420464376026143223]
>> multiply(82716, [31616, 837454])
 [82708077205483544970470074583740846828577431856187364454411787387343982212318, 30836796656275663256542662990890163662171092281704208118107591167423888588304]

Private keys are any nonzero numbers less than the constant N. Public keys are
the products of these private keys and the pair (Gx, Gy ). For example:

>> privatekey = 296921718
>> multiply(privatekey, (Gx, Gy))
 [29493341745186804828936410559976490896704930101972775917156948978213464516647, 14120583959514503052816414068611328686827638581568335296615875235402122319824]

Notice that public keys are pairs of numbers.

Signing transactions involves an operation on the Keccak 256 hashes of the
transactions and private keys. The following function implements this operation:

 import random

 def sign(hash, privkey):

For example:

>> hash = 0xf62d00f14db9521c03a39c20e94aa10a82ff5f5a614772b25e36757a95a71048
>> privatekey = 296921718
>> sign(hash, privatekey)
 [12676003675279000995677412431399004760576311052126257887715931882164427686866, 17853929027942611176839390215748157599052991088042356790746129338653342477382]
>> sign(hash, privatekey)
 [18783324464633387734826042295911802941026009108876130700727156896210203356179, 41959562951157235894396660120771158332032804144867595196194581439345450008533]

Notice that digital signatures are pairs of numbers. Notice also that the sign
function can give different results for the same inputs!

Verifying digital signatures involves confirming certain properties with regards
to the Keccak 256 hashes and public keys. The following function implements
these checks:

 def verify(sig, hash, pubkey):

For example:

>> hash = 0xf62d00f14db9521c03a39c20e94aa10a82ff5f5a614772b25e36757a95a71048
>> privatekey = 296921718
>> publickey = multiply(privatekey, (Gx, Gy))
>> publickey
 [29493341745186804828936410559976490896704930101972775917156948978213464516647, 14120583959514503052816414068611328686827638581568335296615875235402122319824]
>> signature = sign(hash, privatekey)
>> signature
 [54728868372105873293629977757277092827353030346967592768173610703187933361202, 18974025727476367931183775600389145833964496722266015570370178285290252701715]
>> verify(signature, hash, public_key)
 True

To verify that public keys correspond to specific ETC account addresses, confirm
that the rightmost 20 bytes of the public key Keccak 256 hashes equal those
addresses.

Strictly speaking, ETC digital signatures include additional small numbers
referred to as recovery identifiers. These allow public keys to be determined
solely from the signed transactions.

I have explained ETC digital signatures using code rather than
mathematics. Hopefully seeing how signing and verifying can be implemented with
these tiny functions has been useful.

Ethereum Classic Technical Reference
================================================================================

Run "make" to create HTML, LaTeX and PDF versions.

Ethereum Classic Technical Reference (BETA)

(The ETC Classic Technical Reference is still a work in progress. Feel free to
send suggestions, feedback and corrections to me, Chris Seberino, at
cs@etcplanet.org or through the Github pull request mechanism.)

 docs/introduction
 docs/worldcomputer/index
 docs/worlddatabase/index
 docs/appendices/index

| Ethereum Classic |
| --- |
| |
| website: https://ethereumclassic.org |
| code repository: https://github.com/ethereumclassic |
| ticker symbol: ETC |
| genesis block: 2015-07-30 |
| updated: 2020-02 |

# Frequently Asked Questions
## Contents
- Basics
- What is Ethereum Classic?
- How is Ethereum Classic (ETC) related to Ethereum (ETH)?
- How is Ethereum Classic related to Bitcoin?
- What is a blockchain?
- What is a smart contract?
- What is ether?
- What is gas?
- Software
- What is a dapp?
- How do I create a dapp?
- How do I purchase ether for an account?
- What smart contract programming languages are there?
- Mining
- What is mining?
- What is proof of work information?
- What is a coinbase?
- What is an uncle?
- Social Channels
- Public Service Announcement
- Chat
- Forum
- Podcasts
- Repository
- Twitter
- Websites

 Table of contents generated with markdown-toc

## Basics
### What is Ethereum Classic?
Ethereum Classic is a secure, censorship resistant, reliable, public, trustless and decentralized platform for running applications. Ethereum Classic is the continuation of the original Ethereum technology stack launched in 2015.

Video Explainers:
- What is Ethereum Technology? A Beginner's Explanation in Plain English
- Decentralizing Everything with Ethereum's Vitalik Buterin | Disrupt SF 2017

### How is Ethereum Classic (ETC) related to Ethereum (ETH)?
To understand the relationship it is important to know the history. It is especially important to be familiar with the DAO attack and how the Ethereum Foundation responded to it.

Also, it is important to be familiar with the strong objections described in the Ethereum Classic Declaration Of Independence.

Article: The Night Poloniex Listed Ethereum Classic

Video Explainers:
- What’s the difference between Ethereum and Ethereum Classic?
- Ethereum vs Ethereum Classic: Why Did They Split?
- The History & Future Of Ethereum Classic - By Charles Hoskinson
- Gavin Wood presentation hack of the DAO smart contract and options Ethereum community
- Gavin Wood on how $60M hack of DAO happened and what to do next
- Understanding smart contracts & The DAO hack in detail

### How is Ethereum Classic related to Bitcoin?
Bitcoin was the first blockchain application. Ethereum Classic is a general blockchain platform to run many more types of applications than Bitcoin can.

Articles:
- Ethereum Classic (ETC) is Philosophically the Same as Bitcoin and Technically the Same as Ethereum
- Bitcoin and Ethereum Classic (ETC) will be Complementary Base Layer Systems

Video Explainers:
- Ethereum vs Bitcoin | Explained (For Beginners)
- Ethereum Vs. Bitcoin: What Sets Them Apart?
- Ethereum vs Bitcoin Technical Differences | Which Blockchain Technology is Better?

### What is a blockchain?
A blockchain is a special type of distributed database. The most significant attribute of blockchains is that no one controls them! There is no one everybody needs to trust to manage it. That is why they are referred to as being trustless. Users submit tasks in transactions that are grouped into blocks that are linked together to form chains.

Video Explainers:
- How does a blockchain work - Simply Explained
- Blockchain In 7 Minutes
- Blockchain Technology for Dummies - Blockchain Explained Simply
- Blockchain Explained

### What is a smart contract?
Smart contracts are computer systems that manage assets such as automatic teller machines and the Bitcoin system. Ethereum Classic is able to run many types of smart contracts. If Ethereum Classic smart contracts are not mainly financial, it makes more sense to emphasize their autonomy by referring to them as agents.

Video Explainers:
- A Beginner's Guide to Smart Contracts
- Smart contracts - Simply Explained
- Smart Contracts - What Are They? (Plus Examples)

### What is ether?
Ether and ETC denote the native cryptocurrency used to pay for tasks such as installing new smart contracts.

Video Explainer: What is Ether and Ethereum?

### What is gas?
Gas is a made up unit used to denote the amount of resources required to do tasks such as installing new smart contracts.

Video Explainers:
- Ethereum Gas Explained
- Ether vs Gas difference | Programmer explains

## Software
### What is a dapp?
A dapp is a decentralized application. They are also referred to as smart contracts on the Ethereum Classic system. The term is used to distinguish applications that run on blockchains from centralized applications.

Video Explainers:
- What is a Dapp?
- What is a dApp? Decentralized Application on the Blockchain

### How do I create a dapp?
To create a dapp for Ethereum Classic you must program one in a smart contract programming language. Then, you must compile that dapp and install it on the blockchain from a funded account.

Video Explainers:
- Build Your First Blockchain App Using Ethereum Smart Contracts and Solidity
- Build 5 Dapps on the Ethereum Blockchain - Beginner Tutorial

### How do I purchase ether for an account?
You can purchase ether on several exchanges. You can also mine for ether.

### What smart contract programming languages are there?
Solidity is similar to Javascript and the most popular. Serpent is similar to Python and also available. LLL is yet another choice that is similar to Lisp. There are other smart contract languages being developed as well.

Video Explainers:
- Solidity Tutorial - A Full Course on Ethereum, Blockchain Development, Smart Contracts, and the EVM
- Understanding Vyper: The slick New Ethereum language

## Mining
### What is mining?
There are computational tasks involved in adding blocks of transactions to the blockchain. Computers on the Ethereum Classic network that voluntarily perform these tasks get a reward of ether. For security reasons, miners compete to complete these tasks first and win these rewards. This effort is referred to as mining.

Video Explainers:
- What is Proof of Work?
- Bitcoin and cryptocurrency mining explained
- A Brief Introduction to LLVM
- EVM LLVM

### What is Proof-of-Work information?
Mining involves doing computational tasks whose sole purpose is to intentionally make mining difficult! This difficulty is required to secure the network against certain attacks. These tasks involve finding certain numbers related to each block. These numbers are referred to as proof of work information.

Video Explainer: Proof of Work vs Proof of Stake - Clearly Explained

### What is a coinbase?
A coinbase is a special transaction, in every block, that creates new ether added to an account selected by the miner of that block. It can also refer to the primary account of a user. Bitcoin: Coinbase

### What is an uncle?
Several miners compete to submit blocks to the blockchain. Inevitably some miners will lose the competition. The blockchain references the losing blocks to make the blockchain more secure. These losing blocks that contribute to the security of the blockchain are referred to as uncles. The term comes from the fact that blocks have preceding parent blocks. The losing blocks are not parents but are still related to the parents. Hence they are like uncles.

Video Explainer: https://youtu.be/iIhxtuIhTg

## Social Channels
### Public Service Announcement
There is NO OFFICIAL ANYTHING.
Ethereum Classic is an open source, decentralized project with a global permissionless ecosystem. Ethereum Classic's history is checkered with attempts at social attacks on the Ethereum Classic network and it's assets or commons (e.g.; code repository, website, brand, network history). We see similar social engineering in the Bitcoin ecosystem. It's a negative externality that comes with a truly decentralized project.

### Chat
- Discord
- Facebook
- Kakao: Korea
- Matrix (Developer Chat): Riot.im
- Slack: Ethereum Classic
- Telegram: Arabic, China, English, English, Español, German, Italia, Russia, Russia, Viet Nam
- Tencent QQ: ETC Asia-769408114
- WeChat: [insert link] Note: source QR images from ETC Coop and Chinese Websites.

### Forum
- BitcoinTalk: ETC Current, ETC Archived
- Reddit: r/EthereumClassic

### Podcasts
- EVM61
- Explore The Chain
- Let's Talk ETC!

### Repository
- Github
- ETC Awesome List

### Twitter
- Twitter: China, China, English, English, Español, France, Germany, Italia, Japan, Korea, Korea, Netherlands, Philippines, Sri Lanka, Turkey, Viet Nam

### Websites
- EthereumClassic.org
- Region Specific Sites: Asia, China, Korea, Korea

Note: If your social channel is not listed, please reach out to the community via the Ethereum Classic Discord.

Glossary

51% attack
 attacks against blockchain systems that are possible if attackers control over half of the mining resources

account
 data structure associated with Ethereum Classic users and smart contracts

address
 unique numbers that identify blockchain accounts and are derived from the associated private keys

ASIC
 application specific integrated circuit, devices optimized for specific tasks such as blockchain mining

block
 sets of blockchain transactions and related logistical information

block explorer
 website presenting information about a blockchain

block header
 all the fields of Ethereum Classic blocks except the transaction and uncle header lists

block propagation
 distribution of copies of blocks throughout blockchain networks

blockchain
 linear arrays of blocks each of which met the requirements of the blockchain system

bootstrap nodes
 Ethereum Classic network computers that are always available and accepting of new connections from other network computers

classic ether
 the native cryptocurrency of Ethereum Classic, also referred to as ether

coinbase
 blockchain account that receives mining rewards

compiler
 programs that translate programs from one programming language to others

consensus
 agreements among blockchain miners regarding the selection of the official chain

cryptocurrency
 money systems implemented on blockchain systems

daemon
 autonomous software agents

DAG
 directed acyclic graph, used in the Ethereum Classic proof of work calculations

dapp
 applications that run on blockchain systems, also referred to as decentralized applications

decentralization
 the elimination of centralized control entities from software and network designs

decentralized application
 applications that run on blockchain systems, also referred to as dapps

decentralized autonomous enterprise
 sophisticated smart contracts that perform many of the functions of organizations

difficulty
 difficulty of a proof of work calculation in a blockchain system

digital signature
 strings associated with other strings that prove the creators has access to a private key

digital signature
 authentication mechanism in which text snippets appended to data establishing that the creator had access to the associated private key and did a calculation on the data with it,

elliptic curve cryptography
 type of cryptography typically used in blockchain public and private key systems

encryption
 a cryptographic process used to protect the privacy of information

ether
 the native cryptocurrency of Ethereum Classic, also referred to as classic ether

event
 requests in smart contracts to log some information

EVM
 Ethereum Virtual Machine

exchange
 place to buy and sell cryptocurrencies

external account
 one of the two types of Ethereum Classic accounts, used by external clients

fast syncing
 updating blockchain copies and downloading instead of calculating state information

gas
 units used to measure resource usage in the Ethereum Classic system

gas limit
 limits on the maximum possible of gas units, blocks for example have limit on the amount of gas all their transactions can require

gas price
 prices of gas units in classic ether

genesis block
 first blocks of blockchains

GHOST
 Greedy Heaviest Observed Subtree blockchain protocol

hash
 fixed length string calculated from another possibly much longer string with many uses such as confirming data integrity and naming objects

hashrate
 total mining capacity of a blockchain as measured by how fast hashes can be calculated

hexadecimal
 compact method of representing numbers involving numbers and letters, is especially used for big numbers

IPC
 interprocess communication, used to communicate between processes on a computer

keyfile
 file containing a private and public key pair, typically encrypted

light client
 blockchain client that submit that can utilize a blockchain but does not maintain a complete copy of the blochchain

Merkle Patricia trie
 data structures which represents key value pairs

message
 smart contract account requests to other smart contract accounts, may transfer funds as well as invoke or create smart contracts

mining
 process of creating, verifying and distributing blocks in a blockchain

mining pool
 group of miners working together

mining reward
 new cryptocurrency tokens given to miners for performing mining

node
 computers in a network such as a blockchain network

node discovery
 process of finding other nodes in a network such as blockchain network

nonce
 numbers used once (Number ONCE) for various purposes in blockchain systems such as proof of work calculations and preventing replay attacks

peer to peer network
 decentralized network without a centralized control entity

private key
 secret numbers of blockchain accounts used to authorize transactions from it

proof of work
 results of difficult calculations in some blockchain systems used to increase security

protocol
 set of rules to accomplish something like a process in a blockchain system

public key
 pairs of numbers derived from the private keys of blockchain accounts used to identify blockchain accounts and determine account addresses

receipt
 transaction logs

RPC
 remote procedure call, used to invoke code on the same or different computers

serialization
 process of converting a data structure into a linear array of bits

Serpent
 high level smart contract language which is similar to Python

sharding
 mechanism to increase the scalability of blockchain systems by dividing blockchains into subsets (shards) managed by different parts of the network

sidechain
 blockchain that is associated with but still separate from another blockchain

smart contract
 autonomous software agents such as software running on blockchains

Solidity
 high level smart contract language which is similar to Javascript

state
 in Ethereum Classic, all account information for all accounts at some point in time

syncing
 updating blockchain copies

transaction
 external account requests to the Ethereum Classic system, may transfer funds as well as invoke or create smart contracts

transaction fee
 gas costs to execute transactions

trustless
 property of public blockchain system whereby no entity has special permissions

uncle
 losing blocks in mining contests that are used to increase the security of blockchain systems

virtual machine
 computing resource implemented in software

Vyper
 high level smart contract language which is similar to Python

wallet
 set of public and private keys, may also refer to other associated information and software

web 3
 name that refers to the vision of a more secure, trustless blockchain based World Wide Web replacement

How Nodes Find Each Other

Ethereum Classic (ETC) network nodes have accurate information about the network
in spite of it being decentralized and constantly changing. I will describe how
this happens.

Some network nodes are always available and accepting of new connections from
other network nodes. These are referred to as bootstrap nodes. New network nodes
first connect to bootstrap nodes to obtain information. Here is the current Geth
bootstrap node list with network nodes specified using “enode” strings:

 enode://e809c4a2fec7daed400e5e28564e23693b23b2cc5a019b612505631bbe7b9ccf709c1796d2a3d29ef2b045f210caf51e3c4f5b6d3587d43ad5d6397526fa6179@174.112.32.157:30303
 enode://6e538e7c1280f0a31ff08b382db5302480f775480b8e68f8febca0ceff81e4b19153c6f8bf60313b93bef2cc34d34e1df41317de0ce613a201d1660a788a03e2@52.206.67.235:30303
 enode://5fbfb426fbb46f8b8c1bd3dd140f5b511da558cd37d60844b525909ab82e13a25ee722293c829e52cb65c2305b1637fa9a2ea4d6634a224d5f400bfe244ac0de@162.243.55.45:30303
 enode://42d8f29d1db5f4b2947cd5c3d76c6d0d3697e6b9b3430c3d41e46b4bb77655433aeedc25d4b4ea9d8214b6a43008ba67199374a9b53633301bca0cd20c6928ab@104.155.176.151:30303
 enode://814920f1ec9510aa9ea1c8f79d8b6e6a462045f09caa2ae4055b0f34f7416fca6facd3dd45f1cf1673c0209e0503f02776b8ff94020e98b6679a0dc561b4eba0@104.154.136.117:30303
 enode://72e445f4e89c0f476d404bc40478b0df83a5b500d2d2e850e08eb1af0cd464ab86db6160d0fde64bd77d5f0d33507ae19035671b3c74fec126d6e28787669740@104.198.71.200:30303
 enode://5cd218959f8263bc3721d7789070806b0adff1a0ed3f95ec886fb469f9362c7507e3b32b256550b9a7964a23a938e8d42d45a0c34b332bfebc54b29081e83b93@35.187.57.94:30303
 enode://39abab9d2a41f53298c0c9dc6bbca57b0840c3ba9dccf42aa27316addc1b7e56ade32a0a9f7f52d6c5db4fe74d8824bcedfeaecf1a4e533cacb71cf8100a9442@144.76.238.49:30303
 enode://f50e675a34f471af2438b921914b5f06499c7438f3146f6b8936f1faeb50b8a91d0d0c24fb05a66f05865cd58c24da3e664d0def806172ddd0d4c5bdbf37747e@144.76.238.49:30306
 enode://6dd3ac8147fa82e46837ec8c3223d69ac24bcdbab04b036a3705c14f3a02e968f7f1adfcdb002aacec2db46e625c04bf8b5a1f85bb2d40a479b3cc9d45a444af@104.237.131.102:30303

All enode strings contain Elliptic Curve Digital Signature Algorithm (ECDSA)
public keys and internet sockets (addresses and ports).

Additional network nodes are found by network nodes storing and sharing lists of
network nodes that have recently communicated with them. Ignoring older activity
decreases the probability of sharing information about nonexistent network
nodes. Network nodes continually communicate and thereby continually share their
information. The whole process starts with bootstrap nodes and quickly includes
many other network nodes.

Here is the current list for my Parity ETC node:

 enode://9fe33f0ebc5b0ce51879afa3f767b2a180536dafb34b5af24cef11bb1c136b90d7839d6340d912ccd1f8e917a9e24d0d908ca4811a15889fcbf70733d7411608@122.215.240.147:30303
 enode://e1520f00ff23e82c87411964a70c08e77592aab16647ddc2b53a5617808330184aaaac786002d31e40a1db6ec1447d6b0d8ebc7d9099cc90d606b7936fd9b908@172.86.120.213:30303
 enode://a68a96163c842f1175d8eb515ca60ab93e80ab581cded1a11527f53e89f1f1cfb624e3f0a79a5dd76ee0fad54758ec9515be38158b2cf01635dcf444db6716db@46.101.169.110:30303
 enode://e5ddf2ea2373697136681eaba314039ce60b99656c4eefabb2d01032d77dae384919941589f1d9309c340a854310b556d059521414db93c3b0d5ed5ff1308dc4@13.125.218.87:30303
 enode://f5d269ebbfb94494e7e2251a49f430df5d7f510cf04173dad1229b12e4929e6a65f4c76cf9cb0f789c30f7a9d2e50a453a64bb0f797429fe3f2e30cbd0198c0b@35.230.160.215:30303
 enode://efce38b6ee1baa4fa0a48c4202cc175fe4668a376365bbd0b9735a06de04593c822e9064d6664e346af5c98efc0dd0e4f3f1b8b64364aba5f2c51b259accc41c@47.98.232.156:30303
 enode://c38fadc7d03341aaa856c41d8af9733d535cbbde3e3e103dd97c1bf6a0e15f8a6ed77c7bfb04784d9be7bdef884172a1fca8367f3750d4e3d0e9a0e95db57e29@47.97.72.201:30303
 enode://10a0e3e2e4d9be6eab3615cd441da32dcebc7d51df9639c92eae35a7a434cf2c8e2bec756573ca9f49f48d6ed65917d4fbd220658d21888ee75799de955f2580@13.125.156.101:30303
 enode://c1e0e9f8607afc20b70dc6f2b19258e879841561360385c63d004a9cdb1a93f1122e061ad405ff98a03f3413a945c9299e19d6bd6bc86a17682e34f811f12d32@52.57.166.35:30303
 enode://f4a1153780ccb0b4e2c86bdf11837035f621ddc09bcf7d874a9879bc20adf5a32ce0b5cda91674873ad4cd89ca0b6da6a89197102922ea58d3f98ec421368240@167.114.236.10:30303
 enode://7c253d4172cb27a7c514c35ee1cad1ff0fa1a6d2d2ca1c3a6f67d7416173bf0f36c64d6caf5f3cf13700e81104b10642787c17bbfb00e67d1a85c5a88c613cd6@13.125.206.176:30303
 enode://ed81e7f825a5309c3c93698a440055f10fa617342f6e8c62645b3ee813515c488addee22a3175223b4d0bc410c0b3f0a2bc25d67ee2d75cfa4f8bac6006a8f6a@109.236.81.109:30307
 enode://8d45cb061b744f444d38c58f2fd972214f565e24539eb5ccd85612290a66d9da885a1012576784ab2a2cb93050a4ef99e6ba0931963fe7ed4370def400349dbf@149.202.174.161:30303
 enode://1275a4224ee8ee7cedc5ab62a118428f6f4ec2841440cefacf8d01c368ac345d687052c667204e52cc22f0b85de0fc8195aceee5d2d28d2c69d3a3644aecb840@115.22.91.166:30303
 enode://c60ae3bccd9ccded51ad5e8c2aa6bad8fad072c1809779566c85ca17f2f5d810fd6c11761e892c45787e9f27a213cc9ade3244f7a8f8e9fb071e8281b263740e@61.100.182.189:40404
 enode://feaf167dad6e117bc07c507b8cf4aa1978cdcc592d218bde7782c67abc53dbf02ea8aa6799946aee4f8e5f73c58dbc28eadaa8739431bc0233f78562c5266c24@13.125.25.106:30305
 enode://ba8efe932cbf32f0d8ee9a0af45ade59dd26e81cafdc86497e57aca0ae5e9bcc64ee058a4c844bc0d06ceea2db062f377705870b14c72db2977f110485d809cf@5.9.6.244:30303
 enode://c989f4ceea49188426561d2a1833c157cfd137948ae054ab47e770f4032b7708ac59121e13d0c267c23779b96cae258d39e4c05ac55b6a7300fbaa79dd19b541@52.30.37.160:30305
 enode://4329eb2c7e62206421469d413ddc6f8bdf10eb176aaec065282bd31d198ace82871034fa4af34ad0ed5051d2d9d82845a6729f254220fffd91175cddb20318cd@167.114.236.167:30303
 enode://485f2c2368cfb6614026058e37c4d1a63aba7285df77663198c96824dc9b44b2d3861198d42d8c00f7f2d3ee7a00619ebb6e2f70ee96cfd0ca13d7a98a438b52@52.221.229.254:30303
 enode://78f960f4cc378980409704957818e55bb671775d3ca3f731fb8a0468a1156b7158a42e921f4077eaf9de3e8a6905360fca629dfbdb089b083aa0e46a0554ce09@159.65.3.132:30303
 enode://5eb58e0bda31307b19b6d25350bba7b812fc0337cb34e79a5796bbdcaf3bace0535d56e2f485cab7839d03754d5bacb98d666c8c2e9a2ca3c8fe5a9e2b0f63a1@47.91.28.47:30305
 enode://ad132e9609f8288c07e8958af5b1c77dad6001af774e5a5b3d3e06bd339b8a52e63a70ba92df917ddaa1494ed228c735cc5be00f4d59cffe995eb574eb467827@120.131.14.202:30303
 enode://f926fb79061578191b8d125d6fca889f711c94d1dab19f3c106671812a098bb7837b5b40c67f8f0ae2bd0a0410cfa57a00270af8ebe7e9162e3f7b034df554eb@13.78.23.204:30303
 enode://a38b8841524f4a0f6e4161511ef9ed60b7da1a5303a316fd99d997c5f2642313eab3cbe560b1c62dab1ac9be8e92fe61611c41728c3628b59d2a23ae731ea717@165.227.151.104:30303

Amazingly, ETC nodes can find each other within a headless and ever changing
system. There are many such brilliant riches to appreciate in the ETC design
when one looks.

Introduction

Ethereum Classic (ETC) is the most exciting technology today. It promises to
upend governments, the financial industry, supply chain management and much
more. The marriage of ETC with the Internet of Things is a game changer. Some
think ETC may replace the World Wide Web!

ETC is composed of the world computer and database. The ETC world computer is
also referred to as the ETC virtual machine. The ETC world database is also
referred to as the ETC blockchain. These two components have several noteworthy
properties:

censorship resistance
 It is virtually impossible to stop the execution of code or
 to deny access to information.

security
 Security is built in with cryptography.

pseudonymity
 Users are anonymous except for pseudonyms.

openness
 All the software is open source, and, all the activity for all time
 is available for inspection.

reliability
 It is always available and virtually impossible to shut down.

trustlessness
 There is no need to rely on any single person or entity.

All of these properties, except trustlessness, are possible without blockchain
technology. For example, consider a web server securely configured with several
identical backup servers geographically distributed. Suppose these web servers
were only accessible using onion routing
https://en.wikipedia.org/wiki/Onionrouting. This setup can provide
significant censorship resistance, security, pseudonymity, openness and
reliability. Note however how much effort is required. With ETC, these
properties are present by default!

Because ETC is trustless, no one has special powers. Therefore, it
is possible to implement extremely sensitive applications on ETC such as
financial and identity services.

Final note, everyone effectively runs their applications on the same single
computer, the ETC world computer. However, this virtual computer is actually
implemented by a worldwide network of computers. All the computers in the
network run all applications in parallel. This extreme redundancy is a main
reason the ETC world computer has its amazing properties.

Logs

For every transaction, the following information is logged:
- final state root hash
- cumulative gas usage

For example, the final state root hash logged with regards to the third
transaction of block 5,889,421 is:

 0x915dd6ca7dca0c1d68c3cc84e0d8551394f353042af35bd6b5cf21084d643a27

That is the state root hash after the first three transactions have been
applied. Since all transactions for that block require 21,000 gas, the
cumulative gas usage logged with regards to the third transaction is 63,000
gas. Smart contracts can request the logging of additional information.

Logging Requests

Smart contracts can request the logging of additional information. Specifically,
smart contracts can request the logging of named lists of values. For example,
suppose a smart contract based game wanted to record the following information
for a player:
- account address
- health points
- gold coins

This information could be placed in a list named Player as in the following
Solidity code declaration:

 event Player(address user, uint256 health, uint256 gold);

Here is Solidity code to write specific player data to the blockchain:

 emit Player(0xdf0b7310588741cad931de88bc6c4f687cdf0e16, 234, 198);

Note that variable values are stored but not variable names. Note also that user
interfaces can access this logged information but that smart contracts cannot.

Logging requests are identified on the blockchain by hashes formed from their
list names and list value types. For example, the aforementioned Player
logging request is found on the blockchain by searching for the Keccak 256 hash
of the string “Player(address,uint256,uint256)”.

contract logging requests. Bloom filters are hashes created from data to speed
up searches with minimal storage requirements.

Indexed Values

Another way to speed up logging request searches is to store logging request
values in a special way. Specifically, they can be stored as if they were
additional logging request identifiers. This avoids having to extract them from
the bytes encoding all the logging request values. Values stored in this manner
are referred to as indexed values. For example, the Ethereum Token Standard
specifies logging requests with indexed values as in this Solidity code:

 event Transfer(address indexed sender, address indexed receiver, uint256 amount);

The log for transaction

 0x104068d21afd428ce8eb5d9da155e11ba53414e40e088c884a678c6c203083d7

contains three logging request identifiers:

 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef

 0x000000000000000000000000efb32e82cf9d65a828d6d99e12f0beab01a467a6

 0x000000000000000000000000e71ac6142eaffc85ee3b9049facbcb13bc11402a

The first value is the Keccak 256 hash of the string
“Transfer(address,address,unit256)”. The other values are the sending and
receiving addresses with regards to the corresponding token transfer.

Mining

Mining is the process of creating, validating, adding and distributing blocks.
Computers, and their administrators, that perform this service are referred to
as miners. Anyone computer on the network can become a miner. People are
incentivised to become miners because of the financial rewards. Mining
amazingly allows the Ethereum Classis system to be managed and secured in a
trustless decentralized manner.

Proof Of Work Information

Valid blocks must contain certain numbers referred to as proof of work
information. These numbers are also referred to as nonces. Miners compete to
be the first to find this proof of work information and thereby add new blocks
to the blockchain. Finding proof of work information is intentionally made
difficult. This difficulty is a main reason for the security of the blockchain.

The difficult process of finding adequate nonces involves the following. Nonces
must be found such that certain hashes of the blocks, with the nonces added,
have numerical values below specified maxima. The only way to find such hashes
is to simply try as many nonce guesses as possible until adequate hashes are
found. The maxima are automatically adjusted to keep the average block addition
time around 15 seconds. Ethash is the hashing algorithm in this process.

Ethash

The Ethash hashing algorithm requires the determination of a certain extremely
large directed acyclic graph that depends on block numbers. Quickly calculating
several Ethash hashes requires storing the entire directed acyclic graph in
memory. These large memory requirements thwart attempts to dominate the mining
process by building application specific integrated circuits (ASICs).

Uncle Blocks

In the contest to add blocks to the blockchain, the losing blocks can be
leveraged to increase the security of the blockchain. These losing blocks, to
be used this way, must have parent blocks that are at most six blocks from the
growing end of the blockchain. Miners gain additional financial rewards when
they mention the hashes of the headers of these losing blocks in blocks that are
accepted. This uncle block system is referred to as the GHOST protocol.

Here is why uncle blocks increase the security of the blockchain. The mining
contest will inevitably create multiple chains of blocks. The convention is
that the official chain is the one that is the most difficult to
reproduce. Adding uncle blocks increases the difficulty of reproducing the
official chain.

Uncle blocks are especially useful when blocks are not propagating quickly
throughout the network. This leads to many losing blocks as miners keep adding
blocks to outdated versions of the official chain. As block creation times
thereby increase, the security of the network decreases. This is fortunately
mitigated with uncle blocks.

Mining Pools

Because of the nature of the mining contest, the average expected mining rewards
are proportional to the amount of computational resources dedicated to mining.
There can still be variability in payout frequencies due to the random nature of
the mining process. In order to deal with this variability, miners often join
groups referred to as mining pools.

Some mining pools may lead to large amounts of mining resources in the control
of a few individuals. Fortunately, there are trustless decentralized mining
pools that avoid this risk.

Mining Rewards

Mining rewards consists of three parts:

Base Rewards

 E = (N - 1) // 5000000

Then the base reward is as follows:

 5 ⋅ 0.8:superscript:E

Uncle Rewards
 This part depends on the number of uncle blocks included as well as the block
 numbers. It is also paid with newly created funds. Each block can include at
 most two uncle blocks. The reward for each uncle block is an additional
 3.125% of the base reward.

 For the block era E and number of uncles U, the total uncle reward is as
 follows:

 0.03125 ⋅ U ⋅ (5 ⋅ 0.8:superscript:E)

After block number five million, miners that create the uncle blocks began
getting this same reward per uncle block.

Gas Rewards
 This part depends on the transactions included. It is paid from the
 originating accounts. Miners execute the transactions and receive payments
 for the gas required. Each transactions specifies a price paid per unit gas.

 For gas requirements G₁, G₂, G₃, … and corresponding gas prices P₁, P₂, P₃,
 …, the total gas reward is as follows:

 G₁ ⋅ P₁ + G₂ ⋅ P₂ + G₃ ⋅ P₃ + …

Therefore, the total reward for creating a block is the following:

 (1 + 0.03125 ⋅ U ) ⋅ (5 ⋅ 0.8:superscript:E) + G₁ ⋅ P₁ + G₂ ⋅ P₂ + G₃ ⋅ P₃ + …

Here is a Python script that uses this mining reward formula to calculate
mining rewards:

 #!/usr/bin/env python3

 BASEINITIAL = 5
 BASEPERCENT = 0.8
 UNCLEPERCENT = 0.03125
 NERABLOCKS = 5e6

 def miningreward(blocknumber, numuncles, gasreqs, gasprices):

Here are some example calculations on real ETC blockchain data:

>> miningreward(5425392, 0, [], [])
 4.0
>> miningreward(5423326, 1, [], [])
 4.125
>> miningreward(5424471, 0, [36163, 36163] , [2e-8, 2e-8])
 4.00144652
>> miningreward(5421363, 1, [21000, 21000, 21000, 21000, 21000], [5.5e-8, 2e-8, 2e-8, 1.6e-8, 1e-8])
 4.127541

The mining reward formula bounds the supply of ETC. Notice only the base and
uncle rewards increase the supply since the gas rewards just transfer existing
funds. Because the uncle rewards vary, the eventual total supply of ETC can only
be approximated.

The formula for the future increase in supply per era, assuming a constant
number of uncle blocks, is the following:

 5000000 ⋅ (1 + 2 ⋅ 0.03125 ⋅ U ) ⋅ (5 ⋅ 0.8:superscript:E)

The factor of 2 is necessary to include the uncle block creator rewards. The
total supply can be estimated from this formula by adding the contributions for
the remaining eras. Era 192, which will occur around the year 2474, is the last
era which increases the supply.

Assuming no more uncle blocks gives a lower bound of about 198.3 million
ETC. Assuming the maximum number of uncle blocks gives an upper bound of about
210.6 million ETC.

Recursive Length Prefix

Serialization is the process of encoding data structures into byte sequences. It
is also referred to as marshalling and pickling. Serialization is necessary when
storing and sending data structures.

RLP is a serialization format created by Ethereum developers for storage and
communications. It is used for all data structures such as accounts,
transactions and blocks. RLP is simpler than the alternatives such as Extensible
Markup Language (XML), JavaScript Object Notation (JSON), Binary JSON (BSON),
Protocol Buffers and Bencode.

RLP is also consistent. The same inputs are always converted to the same byte
sequences. This is not true of all serialization formats. For example, when
encoding sets of key value pairs, some schemes do not specify an ordering.

RLP operates on byte sequences and lists. Lists can contain byte sequences and
other lists. The interpretation of all inputs is handled by other protocols. For
byte sequences, small headers are added which depend on the length. For lists,
the elements are encoded separately and concatenated. As with byte sequences,
small headers are added which depend on the length. Lastly, all lengths are
encoded in big endian format.

Here are Python functions which implement RLP encoding and decoding:

 #!/usr/bin/env python3

 import math

 NBITSPERBYTE = 8

 def nbytes(integer):

 def getlen(input, extra):

 def rlpencode(input):

 def rlpdecode(input):

Notice that the functions are recursive. Notice also that the functions work for
inputs requiring up to about 18 million terabytes. Here are examples of their
usage:

>> rlpencode(b"A")
 b'A'
>> rlpencode(b"12345")
 b'\x8512345'
>> rlpencode(20 b"12345")
 b'\xb8d12345123451234512345123451234512345123451234512345123451234512345123451234512345123
>> rlpencode([b"12345"])
 b'\xc6\x8512345'
>> rlpencode([b"abcde", 3 [b"12345"], [b"fghij"], b"67890", 4 * [b"klmno"]])
 b'\xf8\x85abcde\xd2\x8512345\x8512345\x8512345\xc6\x85fghij\x8567890\xd8\x85klmno\x85klmno
>> rlpdecode(b"\x8512345")
 b'12345'
>> rlpdecode(b"\xc6\x8512345")
 [b'12345']
>> rlp_decode(b"\xf8\x85abcde\xd2\x8512345\x8512345\x8512345\xc6\x85fghij\x8567890\xd8\x85klmno\x85klmno\x85klmno\x85klmno")
 [b'abcde', [b'12345', b'12345', b'12345'], [b'fghij'], b'67890', [b'klmno', b'klmno', b'klmno', b'klmno']]

RLP is an elegant and approachable serialization format used extensively by
ETC. It can be quickly mastered thereby illuminating this important aspect of
the system.

Root Hashes

The Ethereum Classic (ETC) blockchain contains "root hashes" that help maintain
the integrity of various components of the ETC system. I will describe these
root hashes including how to calculate them.

Some important ETC data structures are sets of key value pairs that are stored
as Merkle Patricia tries. Tries are trees of nodes. The top nodes correspond to
the "roots" of the trees. Therefore, hashes associated with the top nodes of
Merkle Patricia tries are referred to as root hashes. Specifically, root hashes
are the Keccak 256 hashes of the Recursive Length Prefix (RLP) encodings of the
top nodes.

ETC block headers contain root hashes for states, transaction lists and receipt
lists. ETC block headers also implicitly specify storage root hashes in the
state root hashes.

Here is Python code that implements RLP encoding and decoding:

 import math

 BYTELEN = 8

 def nbytes(integer):

 def getlen(input, extra):

 def encode(input):

 def decode(input):

Here is Python code that calculates root hashes using the PySHA3 package. It
requires the RLP code above to be saved to an accessible location with the file
name rlp.py. Invoke the roothash function on Python dictionaries representing
sets of ETC key value pairs. All keys and key values must be Python byte
strings:

 import sha3
 import rlp

 HASHLEN = 32
 HEXADEC = 16

 def remove(dict, segment):

 def select(dict, segment):

 def find(dict):

 def patriciar(dict):

 def patricias(dict):

 def patricia(dict):

 def merkle(element):

 def merklepatricia(dict):

 def roothash(dict):

Here are sample calculations for all of the root hash types found in the ETC
blockchain. They require the root hash code above to be saved to an accessible
location with the file name roothash.py. The RLP code above must be saved to an
accessible location with the file name rlp.py. Lastly, the following code to
convert integers to Python byte strings must be saved to an accessible location
with the file name inttobytes.py:

 def inttobytes(number):

For state root hash calculations, the keys of the Python dictionaries must be
the Keccak 256 hashes of the account addresses. The key values must be the RLP
encodings of lists containing the corresponding account nonces, balances,
storage root hashes, and, smart contract hashes. One way to obtain state
information is with an ETC Geth node. For example, the following ETC Geth node
command prints the state information for block 1,000,000:

geth dump 1000000

Here is the beginning of the voluminous output:

 {

 ...etc.

The following code prints the state root hash for block 1,000,000 which is
0x0e066f3c2297a5cb300593052617d1bca5946f0caa0635fdb1b85ac7e5236f34. It requires
the aforementioned state information to be saved to an accessible location with
the file name state1000000:

 import roothash
 import sha3
 import rlp
 import inttobytes

 dict = {}
 state = eval(open("state1000000", "r").read())
 for address in state["accounts"]:

 print(roothash.roothash(dict))

For transaction list root hash calculations, the keys of the Python dictionaries
must be the RLP encodings of the transaction indices starting from zero. The key
values must be the RLP encodings of lists containing the corresponding
transaction nonces, gas prices, gas usage maxima, destination addresses, ether
sent, data sent and digital signature components. The following code prints the
transaction list root hash for the transactions in block 4,000,003 which is
0xad79d498b7e407d3a2b32c13a380ee93635da2b3e0696c39563cbd5c32d368b2:

 import roothash
 import sha3
 import rlp
 import inttobytes

 key1 = rlp.encode(inttobytes.inttobytes(0))

 nonce = inttobytes.inttobytes(1514565)
 gasprice = inttobytes.inttobytes(20000000000)
 gasmax = inttobytes.inttobytes(50000)
 dest = 0x7b96a5006d5fc86d05f8799fe1fc6f7d23b24969
 dest = inttobytes.inttobytes(dest)
 ether = inttobytes.inttobytes(1001525814273650153)
 data = b""
 v = inttobytes.inttobytes(157)
 r = 0x8815ebbcdb56717a30193db4629fa7565d2fb06c6fba2aaf0db06deaf932955d
 r = inttobytes.inttobytes(r)
 s = 0x4dbd4dcb648114859f57122d804b85c2dd60d0b502fb93d0ef770d50bfa3a59d
 s = inttobytes.inttobytes(s)
 trans = [nonce, gasprice, gasmax, dest, ether, data, v, r, s]
 value1 = rlp.encode(trans)

 key2 = rlp.encode(inttobytes.inttobytes(1))

 nonce = inttobytes.inttobytes(43565)
 gasprice = inttobytes.inttobytes(20000000000)
 gasmax = inttobytes.inttobytes(21000)
 dest = 0x7ccfb3028404225e4e9da860f85274e30ccc9275
 dest = inttobytes.inttobytes(dest)
 ether = inttobytes.inttobytes(109404508089999998976)
 data = b""
 v = inttobytes.inttobytes(28)
 r = 0x8d6e2fcfe032d2612d2ea56da6d07b6a94004a4ec7cbe2c3f086db1a194aa679
 r = inttobytes.inttobytes(r)
 s = 0x6ed1333497c12b4549e55d117977bf60bb96872dfb05816fb7ce25c7396ef23a
 s = inttobytes.inttobytes(s)
 trans = [nonce, gasprice, gasmax, dest, ether, data, v, r, s]
 value2 = rlp.encode(trans)

 print(roothash.roothash({key1 : value1, key2 : value2}))

For receipt list root hash calculations, the keys of the Python dictionaries
must be the RLP encodings of the receipt indices starting from zero. The key
values must be the RLP encodings of lists containing the corresponding receipt
state root hashes, cumulative gas amounts, log Bloom filters and logs. The
following code prints the receipt list root hash for the receipts in block
4,000,003 which is
0x4b3b43affc2927a152b9d6f18e378cf33671f8606e8549de292ae36b8a691584:

 import roothash
 import sha3
 import rlp
 import inttobytes

 key1 = rlp.encode(inttobytes.inttobytes(0))

 state = "abca6dd8fb332962c1c14c02d13b2082aee152496dc809d9642e2deca07fb7c2"
 gas = 0x5208
 bloom = 256 "00"
 logs = []
 receipt = [bytes.fromhex(state),

 value1 = rlp.encode(receipt)

 key2 = rlp.encode(inttobytes.inttobytes(1))

 state = "029b0eb2c76ff08a1cf47aba4be53ff1c20b01026206eca248b47e0657f97524"
 gas = 0xa410
 bloom = 256 "00"
 logs = []
 receipt = [bytes.fromhex(state),

 value2 = rlp.encode(receipt)

 print(roothash.roothash({key1 : value1, key2 : value2}))

For storage root hash calculations, the keys of the Python dictionaries must be
the Keccak 256 hashes of the storage indices for all nonzero storage values. The
key values must be the RLP encodings of the corresponding storage values. The
following code prints the storage root hash for the account with the address
0xd4eae4ae8565f3ecf218191fb267941d98a2c77a which is
0x9f630ea9c8cc6e9f7ecbc08cb7f9e901c14b788cc8f2ae64e3134cf3cb089f55. Note that
this result was correct as of block 5,874,861 but may possibly change
afterwards:

 import roothash
 import sha3
 import rlp
 import inttobytes

 KEYLEN = 32
 ZERO = b"\x00"

 dict = {}
 storage = [(0, 0x51f24771a5a2720456076e7c81d59753dac20e1f),

 for e in storage:

 print(roothash.roothash(dict_))

Root hashes are vital for the operation of the ETC world computer. The ETC
system utilizes state, transaction list, receipt list and storage root
hashes. These ETC root hashes can be found with a detailed recipe involving RLP
encodings, Keccak 256 hashes and Merkle Patricia tries.

Smart Contracts

Smart contracts are autonomous software applications that manage agreements.
Agreements may be trivial or extremely complex. An alternative equivalent term
is software agents. Consider vending machines. They specify and enforce
agreements to release various items for various payments. They do not require
humans to operate. Vending machine are therefore examples of smart contracts.
They notion of smart contracts was conceived by Nick Szabo and predates
blockchain technology:

 "A smart contract is a computerized transaction protocol that executes the
 terms of a contract. The general objectives of smart contract design are to
 satisfy common contractual conditions (such as payment terms, liens,
 confidentiality, and even enforcement), minimize exceptions both malicious
 and accidental, and minimize the need for trusted intermediaries. Related
 economic goals include lowering fraud loss, arbitration and enforcement
 costs, and other transaction costs."

ETC makes an excellent smart contract platform. ETC programs autonomously
manage countless agreements in a secure, reliable and trustless manner. For
this reason ETC programs are referred to as smart contracts.

ETC smart contracts can read and write to their own storage as well as invoking
other smart contracts. In this way, smart contracts can work together to
provide increasingly sophisticated services.

Some, like Nick Szabo, envision smart contracts streamlining voluntary
contractual agreements and disrupting the legal profession. Clearly software is
less prone to misunderstanding and ambiguity than spoken languages! Others see
a future where complex smart contracts replace entire corporations. Such
programs are referred to as distributed autonomous enterprises (DAEs). For
example, imagine a smart contract implementing a ride sharing service. The
smart contract could bring riders and drivers together in an efficient flexible
manner. Note that ETC smart contracts can not only make existing agreements
more efficient, but, they can also make possible contracts which previously were
not possible due to overhead costs. For example, in addition to assisting
multinational corporations, ETC can help teenagers running a small business and
people providing microservices to third world countries.

Because the ETC world computer is implemented by a network of
computers, ETC smart contracts are also referred to as decentralized
applications, or dapps for short.

Smart Contract Languages

Typically smart contracts are written in high level languages. The
corresponding source code is compiled to the equivalent ETC virtual machine
instructions. The most popular high level smart contract language is Solidity.
There are also other possible choices such as Vyper. Solidity is a Javascript
like language designed to be easily adopted by new developers. Here is the
Solidity source code for a simple program. All it does is maintain a counter
variable. The counter can be incremented by anyone. Only the user account that
created the smart contract can reset the counter value:

 pragma solidity ^0.4.18;

 /
 This smart contract maintains a counter which anyone can increment but only
 the author can set to an arbitrary value.
 /

 contract Counter {

 }

Here is Solidity source code for a more complex program. This one implements a
new token:

 pragma solidity ^0.4.18;

 /
 Implements ChrisCoin which adheres to the Ethereum Token Standard.
 /

 contract ChrisCoin {

 }

Multisig Smart Contracts

Multisig smart contracts will likely be the dominant smart contract type in the
future. The security and other benefits are that compelling.

Malware, keyboard loggers and “man in the middle attacks” are just some of the
ways passwords can be stolen. Therefore, many use multifactor authentication to
increase security. For example, accessing a website from a laptop may require a
password and approval from a smartphone.

Ethereum Classic (ETC) and other smart contract systems can also benefit from
multifactor authentication. ETC users are associated with accounts. ETC account
authentication involves digital signatures. Therefore, ETC smart contracts
requiring multifactor authentication are referred to as multisig smart
contracts.

One of the most common types of multisig smart contracts requires digital
signatures from any two of three accounts. Here are some applications where this
is useful:

Single Individuals
 Imagine always requiring a digital signature from a laptop based account and
 a smartphone based account. To protect against the loss of either device,
 store the information for the third account in a secured paper wallet.

Online Shopping (Trusted Escrow)
 When purchasing products and services online, imagine buyers placing funds in
 multisig smart contracts. Have buyers and sellers each control an associated
 account. Allow an arbiter to control the third associated account. Notice
 buyers and sellers can together release funds without the arbiter. In the
 event of disagreements notice the arbiters can, together with buyers or
 sellers, release funds to the desired choices. Because the arbiter does not
 control any funds, this is referred to as trusted escrow.

Small Businesses
 Imagine a small business controlling one associated account. Imagine a
 separate inspection service company controlling the second associated
 account. All transactions must be approved by the inspection service. To
 protect against any issues with the accounts, store the information for
 the third associated account in a secured paper wallet.

Here are two more multisig smart contract types and applications:

Majority Rule
 Imagine all members of a group controlling separate associated
 accounts. Imagine requiring digital signatures from any majority of the
 accounts. This would implement a majority rule arrangement.

Unanimity Rule
 Imagine all members of a group controlling separate associated
 accounts. Imagine requiring digital signatures from all of the accounts. This
 would implement a unanimity rule arrangement.

There are currently no ETC multisig smart contract standards. However, open
source templates are available - such as from the OpenZeppelin project.

There are several common scenarios where multisig smart contracts are useful and
significantly increase security. Therefore, it is likely they will take over ETC
and the world.

What is Ethereum Classic?

Ethereum Classic is a secure, censorship resistant, reliable, public, trustless and
decentralized platform for running applications.

How is Ethereum Classic related to Ethereum?

To understand the relationship it is important to know the history. It is
especially important to be familiar with the DAO
attack and how the
Ethereum Foundation responded to it. Also, it is important to be familiar with
the strong objections described in the Ethereum Classic Declaration Of
Independence.

How is Ethereum Classic related to Bitcoin?

Bitcoin was the first blockchain application. Ethereum Classic is a general
blockchain platform to run many more types of applications than Bitcoin can.

What is a blockchain?

A blockchain is a special type of distributed database. The most significant
attribute of blockchains is that no one controls them! There is no one
everybody needs to trust to manage it. That is why they are referred to as
being trustless. Users submit tasks in transactions that are grouped into
blocks that are linked together to form chains.

What is a smart contract?

Smart contracts are computer systems that manage assets such as automatic teller
machines and the Bitcoin system. Ethereum Classic is able to run many types of
smart contracts. If Ethereum Classic smart contracts are not mainly
financial, it makes more sense to emphasize their autonomy by
referring to them as agents.

What is ether?

Ether and ETC denote the native cryptocurrency used to pay for tasks
such as installing new smart contracts.

What is gas?

Gas is a made up unit used to denote the amount of resources required to do
tasks such as installing new smart contracts.

What is a dapp?

A dapp is a decentralized application. They are also referred to as smart
contracts on the Ethereum Classic system. The term is used to distinguish
applications that run on blockchains from centralized applications.

How do I create a dapp?

To create a dapp for Ethereum Classic you must program one in a smart contract
programming language. Then, you must compile that dapp and install it on the
blockchain from a funded account.

How do I purchase ether for an account?

You can purchase ether on several exchanges. You can also mine for ether.

What smart contract programming languages are there?

Solidity is similar to Javascript and the most popular. Serpent is
similar to Python and also available. LLL is yet another choice that is similar
to Lisp. There are other smart contract languages being developed as well.

What is mining?

There are computational tasks involved in adding blocks of transactions to
the blockchain. Computers on the Ethereum Classic network that voluntarily
perform these tasks get a reward of ether. For security reasons, miners
compete to complete these tasks first and win these rewards. This effort is
referred to as mining.

What is proof of work information?

Mining involves doing computational tasks whose sole purpose is to
intentionally make mining difficult! This difficulty is required to secure the
network against certain attacks. These tasks involve finding certain numbers
related to each block. These numbers are referred to as proof of work
information.

What is a coinbase?

A coinbase is a special transaction, in every block, that creates new ether
added to an account selected by the miner of that block. It can also refer
to the primary account of a user.

What is an uncle?

Several miners compete to submit blocks to the blockchain. Inevitably some
miners will lose the competition. The blockchain references the losing blocks
to make the blockchain more secure. These losing blocks that contribute to the
security of the blockchain are referred to as uncles. The term comes from the
fact that blocks have preceding parent blocks. The losing blocks are not
parents but are still related to the parents. Hence they are like uncles.

## Social Channels
### Public Service Announcement
There is NO OFFICIAL ANYTHING.
Ethereum Classic is an open source, decentralized project with a global permissionless ecosystem. Ethereum Classic's history is checkered with attempts at social attacks on the Ethereum Classic network and it's assets or commons (e.g.; code repository, website, brand, network history). We see similar social engineering in the Bitcoin ecosystem. It's a negative externality that comes with a truly decentralized project.

### Chat
- Discord
- Facebook
- Kakao: Korea
- Matrix (Developer Chat): Riot.im
- Slack: Ethereum Classic
- Telegram: Arabic, China, English, English, Español, German, Italia, Russia, Russia, Viet Nam
- Tencent QQ: ETC Asia-769408114
- WeChat: [insert link] Note: source QR images from ETC Coop and Chinese Websites.

### Forum
- BitcoinTalk: ETC Current, ETC Archived,
- Reddit: r/EthereumClassic

### Podcasts
- EVM61
- Explore The Chain
- Let's Talk ETC!

### Repository
- Github
- ETC Awesome List

### Twitter
- Twitter: China, China, English, English, Español, France, Germany, Italia, Japan, Korea, Korea, Netherlands, Philippines, Sri Lanka, Turkey, Viet Nam

### Websites
- EthereumClassic.org
- Region Specific Sites: Asia, China, Korea, Korea

Note: If your social channel is not listed, please reach out to the community via the Ethereum Classic Discord.

# Star Wars Style - Ethereum Classic - Declaration Of Independence

Shows the Declaration of Independence in a Star Wars scrolling style.

Original English document for reference here.

Finished:
- English (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/
- Spanish (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/es-es/
- Spanish Colombia (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/es-co/
- Portuguese (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/pt-br/
- Russian (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/ru-ru/
- Romanian (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/ro-ro/

Under development:
- German (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/de/
- Chinese (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/cn-cn/
- Japanese (edit). Result: https://ethereumclassic.github.io/DeclarationOfIndependence/jp/

The Ethereum Classic Declaration of Independence
-

 A short time ago in a browser very, very close…

ETHEREUM CLASSIC Declaration Of Independence

 WHITEPAPER 1
The Ethereum Classic Declaration of Independence

 Let it be known to the entire world that on July 20th, 2016, at block 1,920,000, we as a community of sovereign
individuals stood united by a common vision to continue the original Ethereum blockchain that is truly free from
censorship, fraud or third party interference. In realizing that the blockchain represents absolute truth, we stand
by it, supporting its immutability and its future. We do not make this declaration lightly, nor without forethought to
the consequences of our actions.

 Looking Back

 It should be stated with great gratitude that we acknowledge the creation of the Ethereum blockchain platform by
the Ethereum Foundation and its founding developers. It certainly can be said without objection, that without
their hard work and dedication that we as a community would not be where we are today.

 From its inception, the Ethereum blockchain was presented as a decentralized platform for “applications that run
exactly as programmed without any chance of fraud, censorship, or third-party interference” 1 . It provided a place
for the free association of ideas and applications from across the globe without fear of discrimination while also
providing pseudonymity. In this decentralized platform, many of us saw great promise.

 List of Grievances

 It is however, with deep regret, that we as a community have had to spontaneously organize 2 to defend the
Ethereum blockchain platform from its founding members and organization due to a long train of abuses,
specifically by the leadership of the Ethereum Foundation. These grievances are as follows.

 - - For rushing the creation of a “soft fork,” which was comprised of a minor change in the Ethereum
blockchain code for the sole purpose of creating a blacklist and censoring transactions that normally
would have been allowed.

 - - For neglecting the full implications of the “soft fork” by the Ethereum blockchain as a warning that they
were violating the principles and values coded therein. 3

 - - For creating an unrepresentative voting mechanism called the “carbon vote”, which they initially stated
was “unofficial” 4 only to contradict these statements a day before determining to hard fork. 5

 - - For rushing the creation of a “hard fork,” which was comprised of an irregular state change in the
Ethereum blockchain code that violated the properties of immutability, fungibility, and the sanctity of the
ledger.

 - - For willfully deciding to not include replay protection in the “hard fork”, an action which has unnecessarily
cost exchanges and thousands of users the rightful ownership of their Ether tokens. 6

 Respecting the Values Essential for Blockchains

 One might ask what harm can be done from changing the code of the Ethereum blockchain and bailing out 7 “The
DAO” token holders, which is not an unreasonable question. Many of us have an innate sense of right and
wrong, so at first glance rescuing "The DAO" felt right. However, it violated two key aspects of what gives
peer-to-peer cash 8 and smart contract-based systems value: fungibility and immutability.

 Immutability means the blockchain is inviolable. That only valid transactions agreed upon via a cryptographic
protocol determined by mathematics are accepted by the network. Without this, the validity of all transactions
could come into question, since if the blockchain is mutable, any transaction could be modified. Not only does
this leave transactions open to fraud, but it might spell disaster for any distributed application running atop the
platform.

 Fungibility is the feature of money where one unit equals another unit. For instance, a Euro equals another Euro
just as a Bitcoin equals another Bitcoin. Unfortunately, an ETH no longer equals another ETH. The alleged
attacker’s ETH was no longer as good as your ETH and was worthy of censorship, deemed necessary by a
so-called majority.

 Ultimately, these breaches in fungibility and immutability were made possible by the subjective morality
judgements of those who felt a burning desire to bring the alleged attacker to justice. However, in doing so they
compromised a core pillar of Ethereum just to do what they felt was in the interests of the “greater good”. In a
global community where each individual has their own laws, customs, and beliefs, who is to say what is right and
wrong?

 Deeply alarmed that these core tenets were disregarded by many of the Foundation’s developers, and a sizable
portion of Ethereum participants, we, as a community, have organized and formed a code of principles to follow
for the Ethereum Classic chain.

 The Ethereum Classic Code of Principles

 We believe in a decentralized, censorship-resistant, permission-less blockchain. We believe in the original vision
of Ethereum as a world computer that cannot be shut down, running irreversible smart contracts. We believe in a
strong separation of concerns, where system forks of the codebase are only possible when fixing protocol level
vulnerabilities, bugs, or providing functionality upgrades. We believe in the original intent of building and
maintaining a censorship-resistant, trustless and immutable development platform.

 Herein are written the declared values by which participants within the Ethereum Classic community agree. We
encourage that these principles not be changed via edict by any individual or faction claiming to wield power,
authority or credibility to do so.

 We, as a community agree that:

 - - The purpose of Ethereum Classic is to provide a decentralized platform that runs decentralized
applications which execute exactly as programmed without any possibility of downtime, censorship, fraud
or third party interference.

 - - Code is law; there shall be no changes to the Ethereum Classic code that violate the properties of
immutability, fungibility, or sanctity of the ledger; transactions or ledger history cannot for any reason be
reversed or modified.

 - - Forks and/or changes to the underlying protocol shall only be permitted for updating or upgrading the
technology on which Ethereum Classic operates.

 - - Internal project development can be funded by anyone, whether via a trusted third party of their choice or
directly, using the currency of their choice on a per project basis and following a transparent, open and
decentralized crowdfunding protocol.

 - - Any individual or group of individuals may propose improvements, enhancements, or upgrades to
existing or proposed Ethereum Classic assets.

 - - Any individual or group of individuals may use the Ethereum Classic decentralized platform to build
decentralized applications, hold crowdsales, create autonomous organisations/corporations, or for any
other purpose they deem suitable.

 Looking Forward

 For the many reasons listed above, we have chosen to rename the original blockchain “Ethereum Classic” with
the ticker symbol “ETC”, so that the community and all other participants can identify the original, unforked, and
immutable blockchain platform.

 Our most sincere gratitude goes to those developers within and outside the Foundation who opposed interfering
with the Ethereum blockchain ledger and enabled the Ethereum Classic chain to survive and live on. We know
there are many of you and we welcome you at anytime to join our decentralized community.

 We will continue the vision of decentralized governance for the Ethereum Classic blockchain and maintain our
opposition to any centralized leadership takeover, especially by the Ethereum Foundation as well as the
developers who have repeatedly stated that they would no longer develop the Ethereum Classic chain.

 We likewise will openly resist the “tyranny of the majority,” and will not allow the values of the system to be
compromised. As a united community, we will continue to organize for the defense and advancement, as
required, for the continuation and assurance of this grand experiment. The Ethereum Classic platform, its code
and technology, are now open to the world as Open Source software 9 . It is now freely available for all who wish
to improve and build upon it: a truly free and trustless world computer that we together as a community have
proven and will continue to prove is anti-fragile 10 .

The Ethereum Classic Declaration of Independence
-

 A short time ago in a browser very, very close…

ETHEREUM CLASSIC Declaration Of Independence

 WHITEPAPER 1
The Ethereum Classic Declaration of Independence

 Let it be known to the entire world that on July 20th, 2016, at block 1,920,000, we as a community of sovereign
individuals stood united by a common vision to continue the original Ethereum blockchain that is truly free from
censorship, fraud or third party interference. In realizing that the blockchain represents absolute truth, we stand
by it, supporting its immutability and its future. We do not make this declaration lightly, nor without forethought to
the consequences of our actions.

 Looking Back

 It should be stated with great gratitude that we acknowledge the creation of the Ethereum blockchain platform by
the Ethereum Foundation and its founding developers. It certainly can be said without objection, that without
their hard work and dedication that we as a community would not be where we are today.

 From its inception, the Ethereum blockchain was presented as a decentralized platform for “applications that run
exactly as programmed without any chance of fraud, censorship, or third-party interference” 1 . It provided a place
for the free association of ideas and applications from across the globe without fear of discrimination while also
providing pseudonymity. In this decentralized platform, many of us saw great promise.

 List of Grievances

 It is however, with deep regret, that we as a community have had to spontaneously organize 2 to defend the
Ethereum blockchain platform from its founding members and organization due to a long train of abuses,
specifically by the leadership of the Ethereum Foundation. These grievances are as follows.

 - - For rushing the creation of a “soft fork,” which was comprised of a minor change in the Ethereum
blockchain code for the sole purpose of creating a blacklist and censoring transactions that normally
would have been allowed.

 - - For neglecting the full implications of the “soft fork” by the Ethereum blockchain as a warning that they
were violating the principles and values coded therein. 3

 - - For creating an unrepresentative voting mechanism called the “carbon vote”, which they initially stated
was “unofficial” 4 only to contradict these statements a day before determining to hard fork. 5

 - - For rushing the creation of a “hard fork,” which was comprised of an irregular state change in the
Ethereum blockchain code that violated the properties of immutability, fungibility, and the sanctity of the
ledger.

 - - For willfully deciding to not include replay protection in the “hard fork”, an action which has unnecessarily
cost exchanges and thousands of users the rightful ownership of their Ether tokens. 6

 Respecting the Values Essential for Blockchains

 One might ask what harm can be done from changing the code of the Ethereum blockchain and bailing out 7 “The
DAO” token holders, which is not an unreasonable question. Many of us have an innate sense of right and
wrong, so at first glance rescuing "The DAO" felt right. However, it violated two key aspects of what gives
peer-to-peer cash 8 and smart contract-based systems value: fungibility and immutability.

 Immutability means the blockchain is inviolable. That only valid transactions agreed upon via a cryptographic
protocol determined by mathematics are accepted by the network. Without this, the validity of all transactions
could come into question, since if the blockchain is mutable, any transaction could be modified. Not only does
this leave transactions open to fraud, but it might spell disaster for any distributed application running atop the
platform.

 Fungibility is the feature of money where one unit equals another unit. For instance, a Euro equals another Euro
just as a Bitcoin equals another Bitcoin. Unfortunately, an ETH no longer equals another ETH. The alleged
attacker’s ETH was no longer as good as your ETH and was worthy of censorship, deemed necessary by a
so-called majority.

 Ultimately, these breaches in fungibility and immutability were made possible by the subjective morality
judgements of those who felt a burning desire to bring the alleged attacker to justice. However, in doing so they
compromised a core pillar of Ethereum just to do what they felt was in the interests of the “greater good”. In a
global community where each individual has their own laws, customs, and beliefs, who is to say what is right and
wrong?

 Deeply alarmed that these core tenets were disregarded by many of the Foundation’s developers, and a sizable
portion of Ethereum participants, we, as a community, have organized and formed a code of principles to follow
for the Ethereum Classic chain.

 The Ethereum Classic Code of Principles

 We believe in a decentralized, censorship-resistant, permission-less blockchain. We believe in the original vision
of Ethereum as a world computer that cannot be shut down, running irreversible smart contracts. We believe in a
strong separation of concerns, where system forks of the codebase are only possible when fixing protocol level
vulnerabilities, bugs, or providing functionality upgrades. We believe in the original intent of building and
maintaining a censorship-resistant, trustless and immutable development platform.

 Herein are written the declared values by which participants within the Ethereum Classic community agree. We
encourage that these principles not be changed via edict by any individual or faction claiming to wield power,
authority or credibility to do so.

 We, as a community agree that:

 - - The purpose of Ethereum Classic is to provide a decentralized platform that runs decentralized
applications which execute exactly as programmed without any possibility of downtime, censorship, fraud
or third party interference.

 - - Code is law; there shall be no changes to the Ethereum Classic code that violate the properties of
immutability, fungibility, or sanctity of the ledger; transactions or ledger history cannot for any reason be
reversed or modified.

 - - Forks and/or changes to the underlying protocol shall only be permitted for updating or upgrading the
technology on which Ethereum Classic operates.

 - - Internal project development can be funded by anyone, whether via a trusted third party of their choice or
directly, using the currency of their choice on a per project basis and following a transparent, open and
decentralized crowdfunding protocol.

 - - Any individual or group of individuals may propose improvements, enhancements, or upgrades to
existing or proposed Ethereum Classic assets.

 - - Any individual or group of individuals may use the Ethereum Classic decentralized platform to build
decentralized applications, hold crowdsales, create autonomous organisations/corporations, or for any
other purpose they deem suitable.

 Looking Forward

 For the many reasons listed above, we have chosen to rename the original blockchain “Ethereum Classic” with
the ticker symbol “ETC”, so that the community and all other participants can identify the original, unforked, and
immutable blockchain platform.

 Our most sincere gratitude goes to those developers within and outside the Foundation who opposed interfering
with the Ethereum blockchain ledger and enabled the Ethereum Classic chain to survive and live on. We know
there are many of you and we welcome you at anytime to join our decentralized community.

 We will continue the vision of decentralized governance for the Ethereum Classic blockchain and maintain our
opposition to any centralized leadership takeover, especially by the Ethereum Foundation as well as the
developers who have repeatedly stated that they would no longer develop the Ethereum Classic chain.

 We likewise will openly resist the “tyranny of the majority,” and will not allow the values of the system to be
compromised. As a united community, we will continue to organize for the defense and advancement, as
required, for the continuation and assurance of this grand experiment. The Ethereum Classic platform, its code
and technology, are now open to the world as Open Source software 9 . It is now freely available for all who wish
to improve and build upon it: a truly free and trustless world computer that we together as a community have
proven and will continue to prove is anti-fragile 10 .

The Ethereum Classic Declaration of Independence
-

 A short time ago in a browser very, very close…

ETHEREUM CLASSIC Declaration Of Independence

 WHITEPAPER 1
The Ethereum Classic Declaration of Independence

 Let it be known to the entire world that on July 20th, 2016, at block 1,920,000, we as a community of sovereign
individuals stood united by a common vision to continue the original Ethereum blockchain that is truly free from
censorship, fraud or third party interference. In realizing that the blockchain represents absolute truth, we stand
by it, supporting its immutability and its future. We do not make this declaration lightly, nor without forethought to
the consequences of our actions.

 Looking Back

 It should be stated with great gratitude that we acknowledge the creation of the Ethereum blockchain platform by
the Ethereum Foundation and its founding developers. It certainly can be said without objection, that without
their hard work and dedication that we as a community would not be where we are today.

 From its inception, the Ethereum blockchain was presented as a decentralized platform for “applications that run
exactly as programmed without any chance of fraud, censorship, or third-party interference” 1 . It provided a place
for the free association of ideas and applications from across the globe without fear of discrimination while also
providing pseudonymity. In this decentralized platform, many of us saw great promise.

 List of Grievances

 It is however, with deep regret, that we as a community have had to spontaneously organize 2 to defend the
Ethereum blockchain platform from its founding members and organization due to a long train of abuses,
specifically by the leadership of the Ethereum Foundation. These grievances are as follows.

 - - For rushing the creation of a “soft fork,” which was comprised of a minor change in the Ethereum
blockchain code for the sole purpose of creating a blacklist and censoring transactions that normally
would have been allowed.

 - - For neglecting the full implications of the “soft fork” by the Ethereum blockchain as a warning that they
were violating the principles and values coded therein. 3

 - - For creating an unrepresentative voting mechanism called the “carbon vote”, which they initially stated
was “unofficial” 4 only to contradict these statements a day before determining to hard fork. 5

 - - For rushing the creation of a “hard fork,” which was comprised of an irregular state change in the
Ethereum blockchain code that violated the properties of immutability, fungibility, and the sanctity of the
ledger.

 - - For willfully deciding to not include replay protection in the “hard fork”, an action which has unnecessarily
cost exchanges and thousands of users the rightful ownership of their Ether tokens. 6

 Respecting the Values Essential for Blockchains

 One might ask what harm can be done from changing the code of the Ethereum blockchain and bailing out 7 “The
DAO” token holders, which is not an unreasonable question. Many of us have an innate sense of right and
wrong, so at first glance rescuing "The DAO" felt right. However, it violated two key aspects of what gives
peer-to-peer cash 8 and smart contract-based systems value: fungibility and immutability.

 Immutability means the blockchain is inviolable. That only valid transactions agreed upon via a cryptographic
protocol determined by mathematics are accepted by the network. Without this, the validity of all transactions
could come into question, since if the blockchain is mutable, any transaction could be modified. Not only does
this leave transactions open to fraud, but it might spell disaster for any distributed application running atop the
platform.

 Fungibility is the feature of money where one unit equals another unit. For instance, a Euro equals another Euro
just as a Bitcoin equals another Bitcoin. Unfortunately, an ETH no longer equals another ETH. The alleged
attacker’s ETH was no longer as good as your ETH and was worthy of censorship, deemed necessary by a
so-called majority.

 Ultimately, these breaches in fungibility and immutability were made possible by the subjective morality
judgements of those who felt a burning desire to bring the alleged attacker to justice. However, in doing so they
compromised a core pillar of Ethereum just to do what they felt was in the interests of the “greater good”. In a
global community where each individual has their own laws, customs, and beliefs, who is to say what is right and
wrong?

 Deeply alarmed that these core tenets were disregarded by many of the Foundation’s developers, and a sizable
portion of Ethereum participants, we, as a community, have organized and formed a code of principles to follow
for the Ethereum Classic chain.

 The Ethereum Classic Code of Principles

 We believe in a decentralized, censorship-resistant, permission-less blockchain. We believe in the original vision
of Ethereum as a world computer that cannot be shut down, running irreversible smart contracts. We believe in a
strong separation of concerns, where system forks of the codebase are only possible when fixing protocol level
vulnerabilities, bugs, or providing functionality upgrades. We believe in the original intent of building and
maintaining a censorship-resistant, trustless and immutable development platform.

 Herein are written the declared values by which participants within the Ethereum Classic community agree. We
encourage that these principles not be changed via edict by any individual or faction claiming to wield power,
authority or credibility to do so.

 We, as a community agree that:

 - - The purpose of Ethereum Classic is to provide a decentralized platform that runs decentralized
applications which execute exactly as programmed without any possibility of downtime, censorship, fraud
or third party interference.

 - - Code is law; there shall be no changes to the Ethereum Classic code that violate the properties of
immutability, fungibility, or sanctity of the ledger; transactions or ledger history cannot for any reason be
reversed or modified.

 - - Forks and/or changes to the underlying protocol shall only be permitted for updating or upgrading the
technology on which Ethereum Classic operates.

 - - Internal project development can be funded by anyone, whether via a trusted third party of their choice or
directly, using the currency of their choice on a per project basis and following a transparent, open and
decentralized crowdfunding protocol.

 - - Any individual or group of individuals may propose improvements, enhancements, or upgrades to
existing or proposed Ethereum Classic assets.

 - - Any individual or group of individuals may use the Ethereum Classic decentralized platform to build
decentralized applications, hold crowdsales, create autonomous organisations/corporations, or for any
other purpose they deem suitable.

 Looking Forward

 For the many reasons listed above, we have chosen to rename the original blockchain “Ethereum Classic” with
the ticker symbol “ETC”, so that the community and all other participants can identify the original, unforked, and
immutable blockchain platform.

 Our most sincere gratitude goes to those developers within and outside the Foundation who opposed interfering
with the Ethereum blockchain ledger and enabled the Ethereum Classic chain to survive and live on. We know
there are many of you and we welcome you at anytime to join our decentralized community.

 We will continue the vision of decentralized governance for the Ethereum Classic blockchain and maintain our
opposition to any centralized leadership takeover, especially by the Ethereum Foundation as well as the
developers who have repeatedly stated that they would no longer develop the Ethereum Classic chain.

 We likewise will openly resist the “tyranny of the majority,” and will not allow the values of the system to be
compromised. As a united community, we will continue to organize for the defense and advancement, as
required, for the continuation and assurance of this grand experiment. The Ethereum Classic platform, its code
and technology, are now open to the world as Open Source software 9 . It is now freely available for all who wish
to improve and build upon it: a truly free and trustless world computer that we together as a community have
proven and will continue to prove is anti-fragile 10 .

The Ethereum Classic Declaration of Independence
-

 A short time ago in a browser very, very close…

ETHEREUM CLASSIC Declaration Of Independence

 WHITEPAPER 1
The Ethereum Classic Declaration of Independence

 Let it be known to the entire world that on July 20th, 2016, at block 1,920,000, we as a community of sovereign
individuals stood united by a common vision to continue the original Ethereum blockchain that is truly free from
censorship, fraud or third party interference. In realizing that the blockchain represents absolute truth, we stand
by it, supporting its immutability and its future. We do not make this declaration lightly, nor without forethought to
the consequences of our actions.

 Looking Back

 It should be stated with great gratitude that we acknowledge the creation of the Ethereum blockchain platform by
the Ethereum Foundation and its founding developers. It certainly can be said without objection, that without
their hard work and dedication that we as a community would not be where we are today.

 From its inception, the Ethereum blockchain was presented as a decentralized platform for “applications that run
exactly as programmed without any chance of fraud, censorship, or third-party interference” 1 . It provided a place
for the free association of ideas and applications from across the globe without fear of discrimination while also
providing pseudonymity. In this decentralized platform, many of us saw great promise.

 List of Grievances

 It is however, with deep regret, that we as a community have had to spontaneously organize 2 to defend the
Ethereum blockchain platform from its founding members and organization due to a long train of abuses,
specifically by the leadership of the Ethereum Foundation. These grievances are as follows.

 - - For rushing the creation of a “soft fork,” which was comprised of a minor change in the Ethereum
blockchain code for the sole purpose of creating a blacklist and censoring transactions that normally
would have been allowed.

 - - For neglecting the full implications of the “soft fork” by the Ethereum blockchain as a warning that they
were violating the principles and values coded therein. 3

 - - For creating an unrepresentative voting mechanism called the “carbon vote”, which they initially stated
was “unofficial” 4 only to contradict these statements a day before determining to hard fork. 5

 - - For rushing the creation of a “hard fork,” which was comprised of an irregular state change in the
Ethereum blockchain code that violated the properties of immutability, fungibility, and the sanctity of the
ledger.

 - - For willfully deciding to not include replay protection in the “hard fork”, an action which has unnecessarily
cost exchanges and thousands of users the rightful ownership of their Ether tokens. 6

 Respecting the Values Essential for Blockchains

 One might ask what harm can be done from changing the code of the Ethereum blockchain and bailing out 7 “The
DAO” token holders, which is not an unreasonable question. Many of us have an innate sense of right and
wrong, so at first glance rescuing "The DAO" felt right. However, it violated two key aspects of what gives
peer-to-peer cash 8 and smart contract-based systems value: fungibility and immutability.

 Immutability means the blockchain is inviolable. That only valid transactions agreed upon via a cryptographic
protocol determined by mathematics are accepted by the network. Without this, the validity of all transactions
could come into question, since if the blockchain is mutable, any transaction could be modified. Not only does
this leave transactions open to fraud, but it might spell disaster for any distributed application running atop the
platform.

 Fungibility is the feature of money where one unit equals another unit. For instance, a Euro equals another Euro
just as a Bitcoin equals another Bitcoin. Unfortunately, an ETH no longer equals another ETH. The alleged
attacker’s ETH was no longer as good as your ETH and was worthy of censorship, deemed necessary by a
so-called majority.

 Ultimately, these breaches in fungibility and immutability were made possible by the subjective morality
judgements of those who felt a burning desire to bring the alleged attacker to justice. However, in doing so they
compromised a core pillar of Ethereum just to do what they felt was in the interests of the “greater good”. In a
global community where each individual has their own laws, customs, and beliefs, who is to say what is right and
wrong?

 Deeply alarmed that these core tenets were disregarded by many of the Foundation’s developers, and a sizable
portion of Ethereum participants, we, as a community, have organized and formed a code of principles to follow
for the Ethereum Classic chain.

 The Ethereum Classic Code of Principles

 We believe in a decentralized, censorship-resistant, permission-less blockchain. We believe in the original vision
of Ethereum as a world computer that cannot be shut down, running irreversible smart contracts. We believe in a
strong separation of concerns, where system forks of the codebase are only possible when fixing protocol level
vulnerabilities, bugs, or providing functionality upgrades. We believe in the original intent of building and
maintaining a censorship-resistant, trustless and immutable development platform.

 Herein are written the declared values by which participants within the Ethereum Classic community agree. We
encourage that these principles not be changed via edict by any individual or faction claiming to wield power,
authority or credibility to do so.

 We, as a community agree that:

 - - The purpose of Ethereum Classic is to provide a decentralized platform that runs decentralized
applications which execute exactly as programmed without any possibility of downtime, censorship, fraud
or third party interference.

 - - Code is law; there shall be no changes to the Ethereum Classic code that violate the properties of
immutability, fungibility, or sanctity of the ledger; transactions or ledger history cannot for any reason be
reversed or modified.

 - - Forks and/or changes to the underlying protocol shall only be permitted for updating or upgrading the
technology on which Ethereum Classic operates.

 - - Internal project development can be funded by anyone, whether via a trusted third party of their choice or
directly, using the currency of their choice on a per project basis and following a transparent, open and
decentralized crowdfunding protocol.

 - - Any individual or group of individuals may propose improvements, enhancements, or upgrades to
existing or proposed Ethereum Classic assets.

 - - Any individual or group of individuals may use the Ethereum Classic decentralized platform to build
decentralized applications, hold crowdsales, create autonomous organisations/corporations, or for any
other purpose they deem suitable.

 Looking Forward

 For the many reasons listed above, we have chosen to rename the original blockchain “Ethereum Classic” with
the ticker symbol “ETC”, so that the community and all other participants can identify the original, unforked, and
immutable blockchain platform.

 Our most sincere gratitude goes to those developers within and outside the Foundation who opposed interfering
with the Ethereum blockchain ledger and enabled the Ethereum Classic chain to survive and live on. We know
there are many of you and we welcome you at anytime to join our decentralized community.

 We will continue the vision of decentralized governance for the Ethereum Classic blockchain and maintain our
opposition to any centralized leadership takeover, especially by the Ethereum Foundation as well as the
developers who have repeatedly stated that they would no longer develop the Ethereum Classic chain.

 We likewise will openly resist the “tyranny of the majority,” and will not allow the values of the system to be
compromised. As a united community, we will continue to organize for the defense and advancement, as
required, for the continuation and assurance of this grand experiment. The Ethereum Classic platform, its code
and technology, are now open to the world as Open Source software 9 . It is now freely available for all who wish
to improve and build upon it: a truly free and trustless world computer that we together as a community have
proven and will continue to prove is anti-fragile 10 .

The Ethereum Classic Declaration Of Independence

Let it be known to the entire world that on July 20th, 2016, at block 1,920,000,
we as a community of sovereign individuals stood united by a common vision to
continue the original Ethereum blockchain that is truly free from censorship,
fraud or third party interference. In realizing that the blockchain represents
absolute truth, we stand by it, supporting its immutability and its future. We
do not make this declaration lightly, nor without forethought to the
consequences of our actions.

Looking Back

It should be stated with great gratitude that we acknowledge the creation of the
Ethereum blockchain platform by the Ethereum Foundation and its founding
developers. It certainly can be said without objection, that without their hard
work and dedication that we as a community would not be where we are today.

From its inception, the Ethereum blockchain was presented as a decentralized
platform for “applications that run exactly as programmed without any chance of
fraud, censorship, or third-party interference” [1] https://ethereum.org
. It provided a place for the free association of ideas and applications from
across the globe without fear of discrimination while also providing
pseudonymity. In this decentralized platform, many of us saw great promise.

List of Grievances

It is however, with deep regret, that we as a community have had to
spontaneously organize [2]
https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelpethereum
to defend the Ethereum blockchain platform from its founding members and
organization due to a long train of abuses, specifically by the leadership of
the Ethereum Foundation. These grievances are as follows.
- For rushing the creation of a “soft fork,” which was comprised of a minor
 change in the Ethereum blockchain code for the sole purpose of creating a
 blacklist and censoring transactions that normally would have been allowed.
- For neglecting the full implications of the “soft fork” by the Ethereum
 blockchain as a warning that they were violating the principles and values
 coded therein. [3]
 https://blog.ethereum.org/2016/06/28/security-alert-dos-vulnerability-in-the-soft-fork
- For creating an unrepresentative voting mechanism called the “carbon vote”,
 which they initially stated was “unofficial” [4]
 https://www.reddit.com/r/ethereum/comments/4s0rz6/avotethatnobodyknowsaboutisnotavote/d55nye3
 only to contradict these statements a day before determining to hard fork. [5]
 https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork
- For rushing the creation of a “hard fork,” which was comprised of an irregular
 state change in the Ethereum blockchain code that violated the properties of
 immutability, fungibility, and the sanctity of the ledger.
- For willfully deciding to not include replay protection in the “hard fork”, an
 action which has unnecessarily cost exchanges and thousands of users the
 rightful ownership of their Ether tokens. [6]
 https://pbs.twimg.com/media/CopwJVHXEAABEKd.jpg

Respecting the Values Essential for Blockchains

One might ask what harm can be done from changing the code of the Ethereum
blockchain and bailing out [7]
https://dictionary.cambridge.org/us/dictionary/english/bailout “The DAO”
token holders, which is not an unreasonable question. Many of us have an innate
sense of right and wrong, so at first glance rescuing "The DAO" felt
right. However, it violated two key aspects of what gives peer-to-peer cash [8]
https://bitcoin.org/bitcoin.pdf and smart contract-based systems value:
fungibility and immutability.

Immutability means the blockchain is inviolable. That only valid transactions
agreed upon via a cryptographic protocol determined by mathematics are accepted
by the network. Without this, the validity of all transactions could come into
question, since if the blockchain is mutable, any transaction could be
modified. Not only does this leave transactions open to fraud, but it might
spell disaster for any distributed application running atop the platform.

Fungibility is the feature of money where one unit equals another unit. For
instance, a Euro equals another Euro just as a Bitcoin equals another
Bitcoin. Unfortunately, an ETH no longer equals another ETH. The alleged
attacker’s ETH was no longer as good as your ETH and was worthy of censorship,
deemed necessary by a so-called majority.

Ultimately, these breaches in fungibility and immutability were made possible by
the subjective morality judgements of those who felt a burning desire to bring
the alleged attacker to justice. However, in doing so they compromised a core
pillar of Ethereum just to do what they felt was in the interests of the
“greater good”. In a global community where each individual has their own laws,
customs, and beliefs, who is to say what is right and wrong?

Deeply alarmed that these core tenets were disregarded by many of the
Foundation’s developers, and a sizable portion of Ethereum participants, we, as
a community, have organized and formed a code of principles to follow for the
Ethereum Classic chain.

The Ethereum Classic Code of Principles

We believe in a decentralized, censorship-resistant, permission-less
blockchain. We believe in the original vision of Ethereum as a world computer
that cannot be shut down, running irreversible smart contracts. We believe in a
strong separation of concerns, where system forks of the codebase are only
possible when fixing protocol level vulnerabilities, bugs, or providing
functionality upgrades. We believe in the original intent of building and
maintaining a censorship-resistant, trustless and immutable development
platform.

Herein are written the declared values by which participants within the Ethereum
Classic community agree. We encourage that these principles not be changed via
edict by any individual or faction claiming to wield power, authority or
credibility to do so.

We, as a community agree that:
- The purpose of Ethereum Classic is to provide a decentralized platform that
 runs decentralized applications which execute exactly as programmed without
 any possibility of downtime, censorship, fraud or third party interference.
- Code is law; there shall be no changes to the Ethereum Classic code that
 violate the properties of immutability, fungibility, or sanctity of the
 ledger; transactions or ledger history cannot for any reason be reversed or
 modified.
- Forks and/or changes to the underlying protocol shall only be permitted for
 updating or upgrading the technology on which Ethereum Classic operates.
- Internal project development can be funded by anyone, whether via a trusted
 third party of their choice or directly, using the currency of their choice on
 a per project basis and following a transparent, open and decentralized
 crowdfunding protocol.
- Any individual or group of individuals may propose improvements, enhancements,
 or upgrades to existing or proposed Ethereum Classic assets.
- Any individual or group of individuals may use the Ethereum Classic
 decentralized platform to build decentralized applications, hold crowdsales,
 create autonomous organisations/corporations, or for any other purpose they
 deem suitable.

Looking Forward

For the many reasons listed above, we have chosen to rename the original
blockchain “Ethereum Classic” with the ticker symbol “ETC”, so that the
community and all other participants can identify the original, unforked, and
immutable blockchain platform.

Our most sincere gratitude goes to those developers within and outside the
Foundation who opposed interfering with the Ethereum blockchain ledger and
enabled the Ethereum Classic chain to survive and live on. We know there are
many of you and we welcome you at anytime to join our decentralized community.

We will continue the vision of decentralized governance for the Ethereum Classic
blockchain and maintain our opposition to any centralized leadership takeover,
especially by the Ethereum Foundation as well as the developers who have
repeatedly stated that they would no longer develop the Ethereum Classic chain.

We likewise will openly resist the “tyranny of the majority,” and will not allow
the values of the system to be compromised. As a united community, we will
continue to organize for the defense and advancement, as required, for the
continuation and assurance of this grand experiment. The Ethereum Classic
platform, its code and technology, are now open to the world as Open Source
software. [9] https://github.com/ethereumclassic It is now freely available
for all who wish to improve and build upon it: a truly free and trustless world
computer that we together as a community have proven and will continue to prove
is anti-fragile. [10] https://en.wikipedia.org/wiki/Antifragile
- The Ethereum Classic Community

Transactions

Transactions are requests sent to the ETC network from user accounts.
Transactions can send funds, create new smart contracts, or, execute existing
smart contracts. Transaction resource requirements are measured in gas
units. Gas is purchased with classic ether. All transactions contain the
following six elements:

to (receiving address)
 Transactions contain receiving account addresses. This component is an empty
 string for smart contract creation transactions for which new accounts,
 with new addresses, will be created.

init or data (constructor or calling arguments)
 For smart contract creation transactions, this contains the
 associated constructors. For smart contract execution transactions, this
 contains the data operated on.

value (transfer amount)
 amount of classic ether, in units of wei, to be transferred to the receiving
 account

gas price
 offer of classic ether willing to pay per gas unit

gas limit (maximum gas purchase)
 maximum number of gas units willing to purchase

nonce
 originating user account nonces

v, r, s (digital signature)
 three numbers comprising the digital signature of the transaction with
 respect to the private key of the originating account

If applying transactions requires more gas to complete than the maximum gas
amount allowed, then all the effects are reversed except that the user is still
charged for the gas utilized.

World Computer (Virtual Machine)

The world computer is a single virtual machine implemented by a worldwide
network of computers. Programs on the world computer are referred to as
:ref:smart contracts . Because the world computer is
Turing complete https://en.wikipedia.org/wiki/Turingcompleteness,
smart contract can be arbitrarily complex. Users interact with the world
computer through :ref:clients using
:ref:accounts . In fact, all actions on the world computer are
initiated by :ref:transactions sent from users.

 accounts
 smartcontracts
 clients

World Database (Blockchain)

The world database stores requests sent to the world computer. These requests
are referred to as transactions. The transactions are collected into sets
referred to as blocks. The blocks form a tree and a single path through that
tree defines the blockchain. The blockchain stores other information in
addition to transactions such as transaction logs. Lastly, process of
creating, verifying and adding new blocks to the blockchain is referred to as
mining.

The blockchain distributed database architecture was first introduced to the
world in the Bitcoin system.

 transactions
 blocks
 logs
 mining

Декларация Независимости Ethereum Classic
-

 A short time ago in a browser very, very close…

ETHEREUM CLASSIC Декларация Независимости

Декларация Независимости Ethereum Classic

 20 июля 2016 года, на 1 920 000-ом блоке, мы — сообщество независимых людей — объединились с общей целью
 продолжить оригинальный блокчейн Ethereum, который будет по-настоящему свободен от цензуры, мошенничества и
 вмешательства третьих сторон. Осознавая, что блокчейн представляет собой абсолютную истину, мы выступаем
 на его стороне, поддерживая его неизменность и его будущее. Мы относимся к нашему заявлению всерьёз и
 делаем его с полным осознанием последствий наших действий.

 Оглядываясь назад

 Следует отметить, что мы благодарны Ethereum Foundation и основавшим её разработчикам
 за создание блокчейна Ethereum. Вне всяких сомнений, без их тяжёлого и самоотверженного
 труда мы, как сообщество, никогда не стали бы тем, чем являемся сегодня.

 С момента своего создания блокчейн Ethereum позиционировался как децентрализованная
 платформа для “приложений, которые работают без какого-либо риска мошенничества, цензуры
 или вмешательства третьих лиц”. Он предоставил место для свободной ассоциации идей и
 приложений со всего мира без страха дискриминации, обеспечивая в то же время псевдонимность.
 Многие из нас увидели надежду в этой децентрализованной платформе.

 Наши Претензии

 К великому сожалению, в результате длинной череды злоупотреблений,
 произошедших под руководством Ethereum Foundation, нам пришлось объединиться
 для защиты блокчейна Ethereum от его собственных основателей. Наше недовольство
 заключается в следующем:

 - - В поспешном осуществлении “софт-форка”, состоявшего из изменений в коде
 блокчейна Ethereum, единственной целью которых являлось создание чёрного списка
 и цензурирование транзакций, которые иначе были бы разрешены.

 - - В пренебрежении последствиями “софт-форка” для блокчейна Ethereum, несмотря
 на тот факт, что они нарушают принципы и ценности, заложенные в самом Ethereum. 3

 - - В создании нерепрезентативного механизма голосования под названием “carbon vote”,
 который они изначально объявили “неофициальным” и который за день до хард-форка был вдруг объявлен обязывающим.
 4

 - - В поспешном проведении “хард-форка”, который состоял из изменения в коде блокчейна
 Ethereum, нарушающего принципы неизменности, взаимозаменяемости и неприкосновенности цифровой книги.

 - - В принятии самовольного решения не включать защиту от атак повторения в “хард-форке”, что привело
 к потерям для бирж и тысяч полноправных владельцев токенов Ethereum. 6

 Уважая Принципы Блокчейна

 Какой вред может быть от изменения кода в блокчейне Ethereum с целью выручить инвесторов DAO,
 спросите вы? Этот вопрос звучит резонно. Многие из нас имеют врождённое чувство справедливости,
 так что на первый взгляд спасение DAO кажется благородной целью. Тем не менее это нарушило два
 ключевых аспекта, которые лежат в основе систем P2P-транзакций и смарт-контрактов:
 взаимозаменяемость и неизменность. 8

 Неизменность означает, что блокчейн неприкосновенен. Что сетью принимаются только действительные
 транзакции, подтверждённые криптографическим протоколом с помощью математики. Без этого доказанность
 всех транзакций может оказаться под вопросом, так как если в блокчейн можно внести изменения,
 то и любую транзакцию можно тоже изменить. Это не только открывает уязвимость транзакций перед мошенниками,
 но и может вызывать катастрофические последствия для любого распределённого приложения,
 работающего на платформе.

 Взаимозаменяемость является свойством денег, когда одна единица равна другой единице. К примеру,
 один евро всегда равен другому евро, также как один биткойн равен другому биткойну. К сожалению,
 ETH больше не равен другому ETH. ETH предполагаемого хакера были обесценены и подвержены цензуре
 по инициативе так называемого большинства.

 В конечном счёте это нарушение принципов неизменности и взаимозаменяемости стало возможным из-за
 субъективных суждений о морали со стороны тех, кто горячо желал восстановить справедливость в
 отношении злоумышленника. Они скомпрометировали один из основополагающих столпов Ethereum, действуя
 в интересах, как считали они, “большего добра”. В мире, где каждый человек имеет свои законы,
 обычаи и веру, кто может сказать, что есть добро, а что зло?

 Будучи глубоко обеспокоенными тем, что эти основные принципы были проигнорированы большинством
 разработчиков Ethereum Foundation, мы организовали сообщество и сформировали свод принципов блокчейна
 Ethereum Classic.

 Свод Принципов Ethereum Classic

 Мы верим в децентрализованный, устойчивый к цензуре, открытый блокчейн. Мы верим в первоначальное
 видение Ethereum как мирового компьютера, который невозможно выключить, исполняющего необратимые
 смарт-контракты. Мы верим, что форки системы возможны лишь для исправления уязвимости системы на
 уровне протокола, устранения багов или доработки функциональных возможностей. Мы верим в изначальную
 цель создать и поддерживать устойчивую к цензуре, надёжную и неизменную платформу.

 Здесь мы приводим свод ценностей, с которыми согласны участники сообщества Ethereum Classic. Мы
 призываем, чтобы эти ценности не изменялись путём эдикта любым человеком или группой лиц, какой бы
 властью, авторитетом или доверием они не обладали.

 Мы, как сообщество, согласны с тем, что:

 - - Целью Ethereum Classic является предоставление децентрализованной платформы для
 запуска децентрализованных приложений, которые работают так, как они были запрограммированы,
 без какой-либо возможности вынужденного простоя, цензуры, мошенничества или вмешательства
 третьих сторон.

 - - Код — это закон; в код Ethereum Classic не будут внесены никакие изменения, нарушающие
 свойства неизменности, взаимозаменяемости или неприкосновенности цифровой книги; транзакции
 и журнал изменений ни в коем случае не могут быть отменены или изменены.

 - - Форки и иные изменения в протоколе блокчейна могут быть осуществлены только с целью
 обновления или улучшения технологии, на основе которой работает Ethereum Classic.

 - - Внутренняя разработка проекта может быть финансирована любым лицом через выбранную
 им третью сторону либо напрямую, используя любую выбранную им валюту и следуя прозрачному,
 открытому и децентрализованному краудфандинговому протоколу.

 - - Любой человек или группа лиц могут предлагать улучшения, доработки или обновления существующих
 или предложенных активов Ethereum Classic.

 - - Любой человек или группа лиц могут использовать децентрализованную платформу Ethereum Classic
 для создания децентрализованных приложений, проведения краудсейлов, создания автономных организаций
 и корпораций, либо для любых других целей, которые они считают подходящими.

 Заглядывая В Будущее

 По вышеописанными причинам мы решили переименовать оригинальный блокчейн в “Ethereum Classic” с символом “ETC”,
 так чтобы сообщество и любые другие участники рынка могли легко определить оригинальную, неискаженную и незыблемую
 блокчейн-платформу.

 Мы искренне благодарны тем разработчикам (как из Ethereum Foundation, так и со стороны), которые выступили против
 вмешательства в блокчейн Ethereum и сохранили возможность работы цепочки Ethereum Classic. Мы знаем, что вас много,
 и мы всегда рады принять вас в ряды нашего децентрализованного сообщества.

 Мы продолжим продвигать своё видение децентрализованного управления Ethereum Classic и выступать против любых
 попыток централизованного управления блокчейном, особенно со стороны Ethereum Foundation и тех разработчиков,
 которые неоднократно заявляли, что более не будут работать над блокчейном Ethereum Classic.

 Мы будем открыто выступать против “тирании большинства” и не позволим поставить ценности системы под угрозу.
 Мы как сообщество продолжим объединяться с целью обеспечить защиту и продвижение, необходимые для успешного
 продолжения этого великого эксперимента. Платформа Ethereum Classic, её код и технология теперь открыты для
 всего мира как программное обеспечение с открытым исходным кодом. 9 .
 Всё это теперь доступно совершенно бесплатно всем, кто хочет улучшать Ethereum Classic и создавать на его базе
 свои приложения. Это по-настоящему свободный и надёжный мировой компьютер, антихрупкость которого мы как
 сообщество уже доказали и продолжим доказывать.

# Awesome Ethereum Classic

An awesome list of resources for the Ethereum Classic (ETC) project. This is an open-source project contributed by the ETC community. See contribute to get started supporting this project.

# Overview & History
- ETC Asset Profile - Asset profile provided by Messari.
- ETC Declaration of Independance
- ETC Timeline

## ETC EVM Networks

| Name | Network | Chain ID | Concensus | Clients |
| --- | :---: | :---: | :---: | :---: |
| Ethereum Classic | MainNet | 61 | PoW | Core-geth, Besu |
| Astor | TestNet | 212 | PoW | Besu |
| Kotti | TestNet | 6 | PoA | Core-geth, Besu |
| Mordor | TestNet | 63 | PoW | Core-geth, Besu |

## Core Organizations
- ETC Cooperative
- ETC Core

# Public Utilities

## Network Public Utilities
- Mainnet
- Block Explorer
- Metrics/ Dashboards
- Astor
- Faucet
- Kotti
- Block Explorer
- Faucet
- Mordor
- Block Explorer
- Faucet

# Developers

## Clients
- Core-geth - An ETC protocol providing clients written in Go.
- Hyperledger Besu - An ETC protocol providing client written in Java.

## Infrastructure Providers
- Bloq Cloud - BloqCloud delivers highly-optimized, always available access to blockchain networks.
- Ethercluster (free) - Ethercluster is an open-source Infura-like alernative based on GKE.
- Rivet - Cloud-based Ethereum APIs that truly just work.

## Tooling
- BUIDL IDE - Second State BUIDL IDE is a web-based IDE that requires no software download or install. It provides a one-stop development and deployment environment for smart contract and dapp developers.
- Dappkit - A ledger-agnostic, high-performance infrastructure and libraries for developers to build and scale decentralized applications. In short, collaborative Firebase for Dapps.
- Embark Framework - Framework for serverless Decentralized Applications using Ethereum, IPFS and other platforms.
- Emerald Platform - Platform for building Dapps for ETC blockchain.
- ESerialize - The goal of this module is to provide easy functions to serialize and deserialize data for the Ethereum Stack.
- Ethereum JSON-RPC API - A specification of JSON-RPC methods that an EVM-based blockchain client must implement.
- Eth Fiddle - Online editor for smart contracts.
- EVM-LLVM - Not only can developers use a large scope of programming languages (Rust for smart contracts!) other than Solidity to target the Ethereum Virtual Machine (EVM), they can also immediately benefit from various development tools built around LLVM infrastructure.
- Ganache - Personal Ethereum blockchain to run tests.
- Jade Suite - The Jade suite of tools empowers developers to create peer-to-peer decentralized applications on top of EVM-based blockchains like Ethereum Classic.
- Mythx - MythX is the premier security analysis service for Ethereum smart contracts. Our mission is to ensure development teams avoid costly errors and make Ethereum a more secure and trustworthy platform.
- Open-RPC - The OpenRPC Specification defines a standard, programming language-agnostic interface description for JSON-RPC 2.0 APIs.
- OpenZeppelin - Battle-tested framework of secure, reusable smart contracts.
- Quorum - Quorum is an open source blockchain platform that combines the innovation of the public Ethereum community with enhancements to support enterprise needs.
- Remix Online IDE - A useful in-browser IDE that can compile and publish smart contracts to various Ethereum networks. Includes a linter.
- Signatory - An offline transaction and message signer for the Ethereum Stack.
- SOLL - The LLVM compiler is finally coming to Solidity. With it, we can easily create smart contracts across multiple blockchain VMs. The EVM on Ethereum Classic and ETH 2.0's eWASM are among the first we support.
- Sputnikvm - SputnikVM is an open source standalone implementation of Ethereum Virtual Machine (EVM). It aims to be an efficient, pluggable virtual machine for different Ethereum-based blockchains.
- Truffle Suite - A world class development environment, testing framework and asset pipeline for blockchains using the Ethereum Virtual Machine (EVM), aiming to make life as a developer easier.

## EVM Interoperability Projects
- BTC-to-wBTC - Wrapped Bitcoin delivers the power of Bitcoin with the flexibility of an ERC20 token. Bitcoin tokenized on EVMs.
- ETC-to-wETC - The Ethereum Classic Bridge connects ETC-to-ETH, where ETC is available as wETC on the Ethereum (ETH) chain.
- EVM-to-BNC Bridge - The EVM-to-BNC bridge combines the TokenBridge approach with a TSS to approve relay operations and facilitate asset transfer between an EVM chain and the Binance chain.
- Token Bridge - The TokenBridge allows users to transfer data (e.g. digital asset ownership information) between two chains in the Ethereum ecosystem. Cross-chain bridges provide fast and secure connections between blockchains, creating scalability and connection - interoperability - between Ethereum EVM networks.

## Tutorials

Step by step guides on using the Ethereum tech stack.
- CryptoZombies - Learn to Code Ethereum DApps By Building Your Own Game.
- Hitchhikers Guide to Smart Contracts - Build smart contracts on Ethereum using Truffle, testrpc and Solidity.
- A 101 Noob Intro to Programming Smart Contracts on Ethereum - Smart contract tutorial with a focus on building up understanding before code.
- Parity DApp Tutorial - 10 part tutorial on how to write DApps.
- Start Ethereum DApp Development Career - Informal guide to starting developing DApps.
- Full Stack DApp Tutorial Series - Full stack DApps using various frameworks.
- Ethereum Builders Guide - Gitbook for building on Ethereum that goes deeper into understanding technical functionality.
- Learning Solidity Tutorial Series - Building smart contracts with Metamask and Remix IDE.
- End to End DApp Tutorial - Create a gambling DApp using Metamask, Truffle, Remix, React and IPFS.
- Various Ethereum & Solidity Tutorials - How to create smart contracts, deploy your own DApps, create tokens, and more — from beginner to intermediate topics.

## Crowdfunding and freelance
- GitCoin - Crowdfunding and Freelance Developers for Open Source Software Projects.

# User Showcase
- Commonwealth - A peer-to-peer savings fund that allows its users to own micro-equity and share fees from its use.
- Grayscale® Ethereum Classic Trust - ETCG is solely and passively invested in Ethereum Classic, enabling investors to gain exposure to ETC in the form of a security while avoiding the challenges of buying, storing, and safekeeping ETC directly.

# Investors

## Exchanges
- Binance
- Binance US
- Bitfinex
- Bithumb
- Bittrex
- Coinbase Pro
- eToro
- eToroX
- Gate
- HitBTC
- Huobi Global
- Huobi Korea
- Kraken
- Kucoin
- OKCoin
- OKEx
- OKEx Korea
- Poloniex
- Upbit
- Yobit

## Instant Exchanges
- ABRA
- ALFACashier
- AtomicWallet
- ChangeAngel
- Changelly
- ChangeNOW
- CoinSwitch
- Coinveer
- Edge
- Exodus
- SecureShift
- Exolix
- FixedFloat
- GoDex
- Infinito Wallet
- InstaEx
- SimpleSwap
- StealthEx
- SwapSwop
- Swapzone
- Switchain
- Voyager
- XChange

## Payment Processors
- AnyCoinDirect
- Bit4Sale
- Bitladon
- CoinDirect
- CoinGate
- Coinmerce
- CoinPayments
- Cryptomate
- Cryptonator Merchant
- Fud Desk
- LiteBit
- NOWPayments
- Paxful
- RoundlyX
- Utrust

## Portfolio Trackers
- AltPocket
- Blockfolio
- Delta
- GEM
- Coinfolio
- CoinFYI
- CoinStats
- CoinTracking
## Screeners
- CNBC
- CoinCodex
- CoinGecko
- CoinLib
- CoinRanking
- CryptoRating
- CryptoReport
- CryptoCompare
- CryptocurrencyChart
- CryptocurrencyLivePrices
- LiveCoinWatch
- MarketWatch
- Messari
- Prices.org
- TradingView
- WorldCoinIndex
- Yahoo Finance

## News Aggregators
- Blockfolio Signal
- Bloomberg Crypto
- Coinstats News
- CryptoPanic
- Delta Direct
- TokenInsight

### Dapp Lists
- CoinCodex
- CryptoGround
- Dapp.com
- DappDirect
- DappRadar
- Dapp.Review
- DappStatus
- State of the Dapps

## Taxation Tools
- Accointing
- CoinTracker
- CoinTracking
- Koinly
- CoinLedger

# Wallets
- MyCrypto
- MetaMask
- MyEtherWallet
- Nifty Wallet

## Hardware Wallet

Hardware wallets are secure wallets designed for long term storage.
- Bitski
- Ellipal
- Ledger
- SafePal
- Trezor

## Software Wallets

Software wallets are Desktop or Mobile devices designed for short-term storage.
- Alpha Wallet
- AToken
- Atomic Wallet
- Button Wallet
- Citowise
- Cobo
- Coinbase Wallet
- Coinomi
- Cryptonator
- Edge
- Emerald Wallet
- Ethos
- eToro Wallet
- Exodus
- Guarda
- Infinito Wallet
- Jaxx
- Midas Protocol
- Ownbit
- Trust Wallet
- Zelcore Wallet
- Hebe Wallet

## Metal Wallets
- BillFodl
- Blockplate
- ColdTi
- Crypto Key Stack
- CRYPTOTAG
- Hodlinox
- Steely

# Mining
## Mining Pools
- Ethermine
- Nanopool
- Hiveon Pool
- MiningPoolHub
- 2Miners

See more mining pools: https://tinyurl.com/2xpd86p3
### Mining Software
- NanoMiner
- LolMiner
- GMiner
- T-Rex
- NBMiner
- SRBMiner-Multi
- TeamRedMiner
- PhoenixMiner

### Mining Pool Software
- Open ETC Pool
- Stand-alone etchash library (go)

# Community

## Chat
- Discord: ETC - Ethereum Classic
- Telegram: Arabic, China, English, English, Español, German, Italia, Russia, Russia, Viet Nam

### Forum
- Reddit: r/EthereumClassic

### Podcasts
- EVM61
- Explore The Chain
- Let's Talk ETC!

### Repository
- Github

### Twitter
- Twitter: @eth_classic
### Websites
- EthereumClassic.org
- Region Specific Sites: , China

# Education

## Papers
- Ethereum Project White Paper - Non-technical introductory description of the Ethereum project.
- Ethereum Project Yellow Paper - Technical description of the Ethereum project. Technically outdated, but interesting.

## Wiki
- Ethereum Classic chain's Wiki (ETC) - Ethereum Classic wiki covering all things related to Ethereum Classic. The go-to place for all things Ethereum Classic (ETC) chain.
- Ethereum chain's Wiki (ETH) - Ethereum wiki covering all things related to Ethereum. The go-to place for all things Ethereum (ETH) chain.
- Ethereum chain's Community Wiki (ETH) - Ethereum's ETH community wiki. An alternative wiki for the Ethereum chain (ETH).

## Smart Contract Documentation
- Solidity Documentation - Programming language of choice for smart contracts.
- Vyper Documentation - Experimental smart contract programming language intended to replace Solidity.

## Theory and Concepts
Learn about the theory behind the Ethereum project.
- Ethereum Stack Exchange - Question and answers about Ethereum.
- Smart contract safety - Ethereum wiki on best practices for safety in smart contracts.
- Accounts, Transactions, Gas, and Block Gas Limits in Ethereum - Functional description of Ethereum accounts, gas and transactions.
- Ethernaut Smart Contract Capture the Flag - Practice hacking Smart Contracts.
- Ethereum Syllabus - Syllabus to learn Ethereum.
- Cryptocurrency Security: University of Illinois 2016 - Cryptocurrency Security Course.
- Stanford CS 251(p): Bitcoin and Crypto Currencies - Stanford Bitcoin and Cryptocurrency Course.
- Introduction to Digital Currencies: University of Nicosia - Digital currency introductory MOOC.
- Bitcoin and Blockchain Technology: Concordia University - Introduction to Bitcoin and blockchain technology MOOC.
- Smart Contract Best Practices - Security related best practices for smart contracts.
- Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network
- The idea of Smart Contracts - Nick Szabo's idea of smart contracts post from 1997.
- Bitcoin: A Peer-to-Peer Electronic Cash System - Satoshi Nakamoto's original paper is still recommended reading for anyone studying how Bitcoin works.
- Making Smart Contracts Smarter - Smart contract security attacks.
- Ethereum Classic (ETC) Wiki Philosophy - Some of the core philosophies of Ethereum's ETC chain.
- Ethereum Classic (ETC) Improvement Proposals - Standards for the Ethereum's ETC platform, including core protocol specifications, client APIs, and contract standards (ECIPs).
- Ethereum (ETH) Wiki Philosophy - Some of the core philosophies of Ethereum's ETH chain.
- Ethereum(ETH) )Improvement Proposals - Standards for Ethereum's ETH platform, including core protocol specifications, client APIs, and contract standards (EIPS).
- Understanding the DAO
- The Ethereum Classic Declaration of Independence
- A Crypto-Decentralist Manifesto
- Phyro's Recap of ETC History
- Ethereum Classic Principles
- Ethereum Classic Vision
- Ethereum Classic Opportunities
- Ethereum Classic vs Ethereum 2.0, What is the Difference?
- Why Proof of Stake is Less Secure Than Proof of Work
- How to Have a Vision for Ethereum Classic Without Creating a Governance Orgy
- The Ethereum Classic vs Ethereum 1.x Dichotomy
- Into the Ether with Ethereum Classic - The Store of Value Commodity to Power the Internet of Things
- What is Ethereum Classic (ETC)? - A Beginner's Guide to the The Coin that Got Away

## Consensus Algorithms
- Dagger Hashimoto
- Clique
- EtcHash -
- EthHash -
- Sha-3

## Ethereum Project Protocols
Descriptions and implementations of Ethereum-related protocols.

### Swarm
- Introduction to Swarm - Swarm is a distributed storage platform and content distribution service.

### Whisper
- Introduction to Whisper - A communication protocol for DApps to communicate with each other.

### zk-SNARKS
- Introduction to zk-SNARKS with examples - A practical overview of zk-SNARKS, verify knowledge of a secret without revealing it.
- A practical beginner's guide to creating, proving, and verifying zkSNARKs - Introduction to zk-SNARKS and implementation as a smart contract.
- zk-SNARKS: Under the Hood - Technical explanation of zk-SNARKS.
- zk-SNARKs in a nutshell - Technical explanation of zk-SNARKS.
- Practical zk-SNARKs for Ethereum EVM's - A short and practical introduction to using zk-SNARKs.

## Token Bonding Curves (TBC)
- Bonding Curves Explained - Mathematically sound price-supply relationship curves., a thorough introduction to TBCs with code.
- Token Bonding Curves in Practice - Exploring a universal distribution of IP via non-fungible tokens and curation markets.
- Bonding Curve Playground - An interactive bonding curve webapp.

# Ethereum Classic Media and Other Content
## Blogs, Mailing Lists, Newsletters
- Etherplan - Donald McIntyre's research, articles, & podcast about Ethereum Classic, Bitcoin, and decentralized applications.
- Grayscale® Ethereum Classic Trust - Grayscale Ethereum Classic Trust enables investors to gain exposure to the price movement of ETC through a traditional investment vehicle, without the challenges of buying, storing, and safekeeping ETC.
- Messari's Ethereum Classic News and Research - Messari brings transparency to the cryptoeconomy. We want to help investors, regulators, and the public make sense of this revolutionary new asset class, and are building data tools that will drive informed decision making and investment.
- Ethereum Classic Today - A weekly summary of everything happening in ETCLand.
- Week in Ethereum News - A summary of everything happening in Ethereum each week.
- Ethereum Worldwide Meetups - Meet up with the local Ethereum community via meetup.com.
- ETC Gifs - Ethereum Classic social media meme repository
- Coingecko Reports - high quality market reports with graph visuals.
- Ethereum Classic Community Art - a collection of Ethereum Classic art.

## Books
- Mastering Ethereum - A developers guide to the operation and use of the Ethereum project.
- Introduction to Ethereum and Solidity - Learn Solidity development from concept to deployment.
- Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations - Learn about Ethereum (and blockchains) from an IBM blockchain liaison.

## Conferences
### ETC Summit 2017
- ETC Summit 2017 Hong Kong: Full Livestream - November, 2017

### ETC Summit 2018
- ETC Summit 2018 Seoul: Full Livestream - September 12, 2018

### ETC Summit 2019
- ETC Summit 2019 Vancouver: Full Day 1 - October 3rd, 2019
- ETC Summit 2019 Vancouver: Full Day 2 - October 4th, 2019

## Crypto Podcasts
- CryptoBasic
- Epicenter
- EVM61
- Explore The Chain
- Fintech Legal
- Into the Ether
- Let's Talk ETC!
- Programming Throwdown
- Software Engineering Daily - Blockchain
- Software Engineering Radio
- This Week in Crypto
- Unchained
- Zero Knowledge

## Videos
- Ethereum Classic Explained - 2016
- Ethereum vs Ethereum Classic - 2018
- Ethereum Classic: Complete Review of ETC - 2019
- Ethereum Explained (22:00) - Introductory explanation to the Ethereum platform.
- A Guide to Building Your First Decentralized Application (37:00)
- Ethereum YouTube Channel - Mostly older videos of Devcon 1 and before.
- Ethereum Foundation YouTube Channel - Most up to date events and streams including the Ethereum Devcon conferences and dev meetings.
- Unstoppable Code: The Difference Between Can't and Won't - In this talk, Andreas discusses what is interesting about both Bitcoin and Ethereum: unstoppable code. He looks at cryptography and decentralized systems as defensive mechanisms to assert and enforce our human rights, and the effect of the Silk Road on the public's perception of cryptocurrencies. He also warns that the Ethereum community will soon need to reconcile diverse ethical codes and legal jurisdictions, and make a decision about whether they will build "won't" or "can't" governance systems. What is the unstoppable code worth running?
# Contribute

To contribute to this document, simply submit an issue or pull request to the feature branch and the maintainers will review. See the Contributing guide for additional information.

# License

CCO

# Contributing Guidelines

We'd love for you to contribute to this project. This contributing guide provides some basic information for existing and new contributors.
1. Fork the repo.
2. Make changes to the feature branch.
3. Submit a pull request.

## Resources
- How to fork a repo.
- About branches
- How to swtich branches with Git CLI
- How to create a pull request

## Decentralized Governance

There are many problems that fester due to centralization and opaqueness; corruption, unaccountability, nepotism, inefficiency and stagnation. Ultimately, centralization leads to fragility; only decentralized systems can stand the test of time.

These problems can be only solved by adhering to governance systems that do not rely on a central point of failure. Just like distributed networks and the consensus protocol itself, we believe that only truly decentralized projects can survive in the long run.

Ethereum Classic manifests these values by relinquishing control by a formalized central foundation. The only hierarchy is that of transparent meritocracy and mutual reputation. No backroom deals or behind-closed-doors unilateral decision making; just free and open discourse.

# ECIPs

## Summary

This document is a summary of the Ethereum Classic Improvement Proposal (ECIP) process. To view the full description of the ECIP process please read ECIP-1000 which is the formal document generally acknowledged by the Ethereum Classic (ETC) ecosystem, by rough consensus, as the most suitable system to propose new standard changes to the ETC protocol, informational documents, or ECIP process suggestions.

## Getting Started
After reading ECIP-1000, fork the repository and add your ECIP to it, using the provided ECIP markdown template. Submit by creating a Pull Request to the Ethereum Classic ECIPs repository.

## Types of Participants

As you will see by reading this summary and the other documents suggested above, there are several parties that participate in the life cycle of an ECIP:
- ECIP Author: This is you! The author is the person interested in improving ETC by making a new ECIP. Therefore, responsible for learning how the process works, so he or she can effectively propose protocol changes, informational or procedural improvements. The author is also responsible for following up on the ECIP life cycle throughout all the status steps, from 'draft' to 'active' as described below, so the proposal becomes a reality. If not, it is possible that the ECIP will be eventually rejected.
- Editors: Editors are developers, mainly ETC volunteers, members of the Ethereum Classic Github Organization whose responsibilities include, but are not limited to, assigning numbers to ECIPs, merging them, listing them in the ECIP directory, checking if they are ready, sound and complete, if the status steps are followed, and to check their motivation, accuracy and proper licensing terms.
- Developer Teams: ETC has several developer companies and volunteer developers who work on different node clients. Because these developers are dedicated to maintaining the core protocol of Ethereum Classic, they are categorized as "core developers" or "core developer teams". Core developers are in charge of making new proposals or reviewing and accepting or rejecting proposals from other developers or teams. When they accepts new changes, they merge them into the respective clients they maintain for the ETC network.
- Implementors: Once an ECIP is accepted and merged, the last step is for miners, mining pools, wallet operators, exchanges, and other full node operators to implement the changes by installing or upgrading their nodes to integrate the new changes. These operating network participants are called "implementors".
- Users: Users or end users may be regular consumers, businesses, governments, non-economic node operators, investors, or other kinds of users who see when the implementors upgraded their systems and adopt the new rules for sending transactions and managing smart contracts or using applications on top of ETC.
- Discussion Participants: According the ECIP process, when moving ECIPs forward, authors will open for discussion their proposals. These discussions are located in public forums, Github or developer calls. Discussion participants may be core or volunteer Ethereum Classic client developers, any developers on Github willing to contribute their well reasoned opinions, and other interested stakeholders or participants in the ETC ecosystems.

## Contributing

### Steps
1. Review ECIP-1000.
2. Fork the repository by clicking "Fork" in the top right.
3. Add your ECIP to your fork of the repository. There is a ECIP markdown template.
4. Submit a Pull Request to Ethereum Classic's ECIPs repository.

### Format and Numbering

Your first PR should be a first draft of the final ECIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new ECIP and assign it a number before merging it. Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the ECIP as a whole.

### Images

If your ECIP requires images, the image files should be included in a subdirectory of the assets folder for that ECIP as follow: assets/ecip-X. When linking to an image in the ECIP, use the related links such as ./assets/ecip-X/image.png.

### Tips

When you believe your ECIP is mature and ready to progress past the draft phase, you should do one of two things:
- For a Standards Track ECIP of type Core, ask to have your issue added to the agenda of an upcoming core developer team meeting. There, it can be discussed for inclusion in a future hard fork. If developers agree to include it, the ECIP editors will update the state of your ECIP to 'Accepted'.
- For all other ECIPs, open a PR changing the state of your ECIP to 'Final'. An editor will review your draft and ask if anyone objects to its finalization. If the editor decides there is no rough consensus - for instance, because contributors point out significant issues with the ECIP - they may close the PR and request that you fix the issues in the draft before trying again.

# ECIP Status Terms
- Work in progress (WIP) -- An ECIP where the author has asked the Ethereum Classic community whether an idea has any chance of support, he/she will write a draft ECIP as a pull request. However, if the idea is still in a very early stage, and will have a lot of commits and changes by the author, editors or contributors, it may be better to enter it as a WIP. Make sure to add [WIP] in the title (example: [WIP] ECIP-X) of the early stage ECIP so other members can mute it if they are not interested in participating at this stage.
- Draft - An ECIP that is still undergoing iteration and changes, but is ready for general review. Make sure to remove [WIP] from the title so those who have muted the ECIP get the new status and can participate.
- 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.
- Final - An ECIP that was accepted, implemented, and no longer can be modified without submitting a new proposal, e.g. it has been released in a hard fork.
- Deferred - An ECIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.
- Replaced - When a Final ECIP is no longer relevant, its status may be changed to Replaced or Obsolete.
- Rejected - Reasons for rejecting ECIPs include duplication of effort, disregard for formatting rules, unfocused or too broad, being technically unsound, not providing proper motivation, or obvious popular disapproval.
- Withdrawn - ECIP authors may decide to change the status between Draft, Deferred, or Withdrawn. The ECIP editor may also change the status to Deferred if no progress is being made on the ECIP.
- Active -- Some Informational and Process ECIPs may also be moved to a status of “Active” instead of "Final" if they are never meant to be completed, e.g. ECIP-1000.

## ECIP List

See ECIPs website for the complete list of ECIPs.

## Process Overview

Ethereum Classic Improvement Proposals (ECIPs), are technical write-ups that describe suggested changes to the Ethereum Classic Protocol. Finalized proposals agreed by core and volunteer client developers, implementers and other users of the Ethereum Classic mainnet are implemented by the core developer team into their respective clients.

Every pull request will be reviewed and discussed by core and volunteer Ethereum Classic developers and any developers on Github willing to contribute their well reasoned opinions. Regardless whether there is general agreement, you are still able to use the information generated in the discussions to create a second draft. This can be done by either updating the pull request or submitting a new pull request. This process may be repeated (See figure 1) until the ETC developer community agrees to add the pull request.

Figure 1: Status Terms and Process

Having an ECIP within the folder of the repository does not make it a formally accepted standard until its status becomes "Final". For an ECIP to become Final it requires the common consent of the ecosystem. Those proposing changes should consider that, ultimately, consent may rest with the consensus of the Ethereum Classic implementers and users.

## Discourse Archives

The ECIP Process (and thus, ECIP content) is informed by discourse around it.

Listed below are sovereign archives of discourse pertaining to this ECIPs repository. If you'd like to collect your own archives, a basic tool you can use for reference to collect them can be found at this gist. If you have or regularly collect archives, please feel welcome to add to this list.
- https://github.com/meowsbits/ECIPs/tree/gh

## ECIPs Historical Background

ECIPs were born out of the Ethereum (or Ethereum Foundation) EIP repository after TheDAO hard fork). At that time no other differences between Ethereum Classic (the original mainnet) and Ethereum existed besides TheDAO hard-fork. Changes have since been added such as the early defusal of the difficulty bomb and a change of the monetary policy to a fixed supply.

### Avoiding Network Splits

Pushing changes to the protocol without consensus will cause a network split. The ECIP process should not be skipped, as previously done by Ethereum Foundation developers who unilaterally implemented a rushed hard-fork in the most widely used client, therefore creating a network split at block 1920000.

### Decentralized Decision Making

The Ethereum Foundation raised money from the community to work towards the "mission to promote and support research, development and education to bring decentralized protocols", but failed at that goal when, shortly after TheDAO exploit, Vitalik Buterin announced, using the Ethereum Foundation blog, that they had already unilaterally decided to fork. A chat log from an internal chat reveals this decision was made prior to the announcement, and comments like "default behavior of Geth to be pro-fork as per internal discussions" found in DAO hard-fork pull requests, and the unwillingness to use their own proposal system, show that the narrative in which the Ethereum Foundation followed the will of the community was clearly wrong. What the Ethereum foundation did was the opposite of decentralized decision making.

## Conclusion

Decentralized decision making is part of the deep security that protects the integrity of the Ethereum Classic blockchain. It is critical for keeping the promise of "applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference."

In other words, please follow the ECIP process!

## Transaction Finality

We believe the core value proposition of any blockchain is immutability; valid transactions can never be erased or forgotten. Individuals interacting on Ethereum Classic are governed by this reality; Code is Law.

This does not necessarily mean that code replaces existing laws, or that only code is law (there are many geographical jurisdictions), but it gives users the opportunity to enter into a new blockchain-based jurisdiction where agreements are governed by code.

By entering into contracts on Ethereum Classic, you can be certain that the network remains neutral. The outcome of transactions will be dictated by code you voluntarily interact with. Unless explicitly defined by the contract code, there are no reversals, no undos, no opt-outs.

Transactions are final; applications are unstoppable.

## Why Classic?

Ethereum Classic is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.

Ethereum Classic is a continuation of the original Ethereum blockchain - the classic version preserving untampered history; free from external interference and subjective tampering of transactions.

# Wiki

## The Ethereum Classic Wiki

All of the content in this repository lives in the Wiki.

There is no code or documentation stored in this repository.

# Connect (move to own section)
Reddit - https://reddit.com/r/ethereumclassic
Discord - https://discord.gg/HW4GckH
Forum - https://forum.ethereumclassic.org/
Podcast - https://www.youtube.com/watch?v=4KqF1zG98tM&list=PLKO8sMfwkZQqGH3Ny2OJSRcAvSf0gx5

@ethclassic - https://twitter.com/ethclassic
@ClassicIsComing - https://twitter.com/classiciscoming
@ETCCooperative - https://twitter.com/ETCCooperative

Ethereum Project - https://github.com/ethereumproject
ETCDEV Team - https://github.com/ETCDEVTeam/
Ethereum Commonwealth - https://github.com/EthereumCommonwealth

ETH Classic (English) - http://telegram.me/ethclassic
ETC Chat (English) - http://t.me/etcchat
ETC Russia (Russian) - http://telegram.me/etcrussia
ETC RU (Russian) - http://telegram.me/etcru
ETC Italia (Italian) - http://t.me/ETC_Italia

# ethereumclassic.org-redesign-text
This was originally a staging repo for the ethereumclassic.org website and the website has now outgrown this repo. Feel free to continue to make Issues/PRs here but as it's not actively managed you should also reach out to @pyskell on Twitter or Telegram if you need changes.

# Guides / FAQ / Info
ETC FAQ - https://github.com/ethereumclassic/faq - Probably exclude

Guides - https://forum.ethereumclassic.org/c/help-me/guides - Do we want to copy these over to the main site?

ETC Guide - https://ethereum-classic-guide.readthedocs.io/en/latest/ - Need to update or rewrite, very outdated

ETC Today - http://etc.today/

ETCDEV Team - https://www.etcdevteam.com/

Grothendieck Team - https://iohk.io/projects/ethereum-classic/#team

Ethereum Commonwealth - https://dexaran.github.io/ICO/

Investment Thesis - https://grayscale.co/wp-content/uploads/2018/03/Grayscale-Ethereum-Classic-Investment-Thesis-August-2017.pdf

Monetary Policy - https://github.com/ethereumproject/ECIPs/blob/master/ECIPs/ECIP-1017.md

Declaration of Independence - https://ethereumclassic.github.io/assets/ETCDeclarationofIndependence.pdf

Decentralist Manifesto - https://ethereumclassic.github.io/blog/2016-07-11-manifesto/

# Wallets
## Desktop
Emerald Wallet (Windows, Linux, Mac; Beta) - https://github.com/ethereumproject/emerald-wallet/releases

## Web
CEW Web Wallet - https://ethereumproject.github.io/etherwallet/

MEW Web Wallet - https://myetherwallet.com

MyCrypto.com

## Hardware
Ledger Hardware Wallet - https://www.ledgerwallet.com/products/12-ledger-nano-s

Trezor Hardware Wallet - https://trezor.io

## Mobile
Guarda Wallet (Android, iOS, Web) - https://guarda.co/wallet/etc

Trust Wallet (Android, iOS) - https://trustwalletapp.com

JAXX (Windows, Linux, Mac, Android, iOS) - https://jaxx.io/

# Nodes
Geth - https://github.com/ethereumproject/go-ethereum/releases

Parity - https://github.com/ethcore/parity/releases

Mantis - https://github.com/input-output-hk/mantis/releases

Network Status - http://etcstats.net - TODO: Replace with something else, site is nearly dead

# Mining Pools / Mine ETC
Epool - https://epool.io

2Miners - https://2miners.com/etc-mining-pool

91 Pool - http://91pool.com

BW.com - https://etc.bw.com

Clona.ru - http://clona.ru/

Coinfoundry.org - https://coinfoundry.org

Coin-Miners - https://ethc.coin-miners.info

ETCPool.pl - http://etcpool.pl/

Ethermine - https://etc.ethermine.org/

ETHteam.com - http://ethteam.com

ETC-Poolcrypto - http://etc-poolcrypto.org/

f2pool - https://www.f2pool.com/help

Fairpool.io - https://etc.fairpool.xyz/

Minertopia.org - http://etc.minertopia.org/

Minergate - https://minergate.com

Nanopool - http://nanopool.org

Pandapool.io - https://pandapool.io

UUpool - http://uupool.cn/

# Block Explorers / Network Stats
Gastracker.io - https://gastracker.io

Etherhub.io - http://etherhub.io

Mining Status - https://gastracker.io/stats/miners

Network Monitor - https://etcstats.epool.io

# Exchanges / Buy ETC
Bittrex - https://bittrex.com/Market/Index?MarketName=BTC-ETC

Bitfinex - https://bitfinex.com

BitMex - https://www.bitmex.com/app/trade/ETC24H

BitSquare - https://bitsquare.io

BTER - https://bter.com/trade/etcbtc

Changelly - https://changelly.com/exchange/BTC/ETC/1

ChangeNow - https://changenow.io?utmsource=etc&utmmedium=ref&utmcampaign=etcexchanges

CHBTC - https://trans.chbtc.com/etc

Coinexchange - https://coinexchange.io/market/ETC/BTC

CoinSwitch - https://coinswitch.co

C-CEX - https://c-cex.com/?p=etc-btc

Korbit - https://korbit.co.kr/etcmarket

Kraken - https://www.kraken.com

Godex - https://godex.io

Poloniex - https://poloniex.com/exchange#btcetc

Shapeshift - https://shapeshift.io

Yobit - https://yobit.net/en/trade/ETC/BTC

Yunbi - https://yunbi.com/

# Using ETC (Beginner)
ETC is one of the easiest chains to use, and if you're just getting started you can quickly start using ETC with Emerald Wallet.
## Emerald Wallet - Quick Start
Download: https://github.com/ETCDEVTeam/emerald-wallet/releases
Run.
Select "Remote Node" (starts instantly), or "Full Node" (takes a few hours).

That's it!

# Getting ETC
You have two options to get ETC, one is to buy it on an exchange, the other is to mine it with computer hardware.

## Exchanges
To purchase ETC with cash or other Cryptocurrencies you can join one of the many exchanges linked in the Exchange section.

## Mining
To mine ETC you'll need to have the appropriate computer hardware and join one of the many ETC mining pools available. If you've never mined before then make sure to read up on what's required first. You can find more information at the websites of the linked mining pools.

# What is a Contract?
A Contract is a computer program that runs on the ETC network without anyone being able to interfere with it. This is advantageous because you can create a contract that everyone agrees to and then not have to worry about someone backing out.

## A simple example
Say every couple of weeks you and your coworkers go out for beers. Some members of the group start to become concerned that they're buying too many rounds while others are not. To solve this you create a pool of money, everyone throws in 10 ETC, and when the bar tab comes you pay with it.

This works great, but then you have an issue, sometimes some people don't show up and you agree it's not fair to use the pool of funds when some people aren't around. However some people aren't very good at sticking to this rule, and they occassionally forget to not dip into the funds whenever Todd is traveling on business.

So you create a contract on the ETC network that says each member of the group needs to tell the contract that it's okay to spend the funds. Then whenever you want to spend your ETC the contract enforces this rule without needing to rely on everyone following the rules; they're required to by the contract.

The possibilities for such contracts are endless, with applicability across industries. This is but one small, illustrative example.

# ETC History
ETC has a long history relative to most blockchains and came about at the start of the second wave of blockchains.

Ultimately you can break down blockchains and Cryptocurrencies into two waves:

Wave 1 (2009-2013): Bitcoin, and Bitcoin clones (aka. "altcoins").
Wave 2 (2014-Present): Contract coins, Privacy coins, etc.

Ethereum Classic belongs to the second wave of coins.

Ethereum Classic is the Ethereum blockchain, much like Coca Cola Classic is the original and better Coke, we are the original and better Ethereum. Where-as New Coke (or New Ethereum) is a compromise that ruined a lot of what made Ethereum great.

To truly understand ETC and its history our decentralist manifesto, declaration of independence, and early history are required reading.

## A History Lesson
Ethereum launched on July 30th 2015. At this time there was only one Ethereum with the goal of being a decentralized, immutable, blockchain-powered machine.

ETC's very own EtherNinja is permanently recorded in block 4: https://etherscan.io/block/4

The first Bitcoin-proponent made it into block 18, funny that they were mining Ethereum: https://etherscan.io/block/18

For the first year the Ethereum community was one small but happy family.

### The DAO Incident
Then some of the leaders at Slock.It and The Ethereum Foundation decided to create a Decentralized Autonomous Organization ("The DAO"). The goal of The DAO was to create a funding mechanism for various ecosystem projects.

The DAO had a litany of issues from the start, it was quickly written, it had known bugs (one of which the attacker exploited), it had undergone a very poor security audit, and it was heavily promoted.

Ultimately a contract was deployed on the Ethereum chain that created The DAO. Participants could send Ether to it, vote on proposals, and be rewarded with Ether if these proposals created profitable projects.

Shortly after deployment The DAO contained ~15% of all Ether in existence at the time (worth ~$150 million), the attacker took about 40% of this (or $60 million). A group of "whitehats" secured the rest, preventing the attacker from getting the whole bag.

A vote was quickly held on carbonvote.com, over the course of a little over a week Ether holders were able to vote with their wallets on whether or not to undo the attack with a change to the network that went against its principles. 6% of the total economy voted, not even a small majority; less Ether than the amount affected by The DAO. 94% did not vote. 94% were not represented. Ohh, and 1/4th of the pro-fork vote was a single rich voter.

So Ethereum forked, they created an irregular state change that undid the past and moved The DAO funds to a refund contract so people could reclaim their Ether.

### Aftermath
After The DAO incident the original agreement for The DAO (which stated that the code on the network is the final say), the daohub.org website, and carbonvote.com all lost their history. Some were taken down quickly (The DAO agreement), the rest disappeared over time. Daohub.org now links to a website for a children's game. Rather loose handling of information related to a $60 million incident.

Finally, the original Ethereum chain continued on, now under the name Ethereum Classic. While Ethereum Foundation should have renamed their augmented chain to something like "New Ethereum" they refused to, and since they had the domain names, the subreddits, and most of the money, they got to "win" with their 6% vote.

ETC continues moving forward.

When you want to change the blockchain without the permission of account holders: https://github.com/ethereum/go-ethereum/blob/master/consensus/misc/dao.go#L82

# What is a blockchain?
Put simply, blockchains provide a way to keep track of digital assets (money, things) without the need for intermediaries, such as banks and other financial institutions.

# What is Ethereum Classic?
Ethereum Classic (ETC) is a smarter blockchain, a network, a community, and a cryptocurrency that takes digital assets further. In addition to allowing people to send value to each other, ETC allows people to create complex contracts that operate autonomously and cannot be modified or censored. This can be a difficult concept to grasp for those new to the blockchain space. For now, imagine Bitcoin as a landline phone—it does one thing very well. From this perspective ETC is like a smartphone or the Internet; it can do everything Bitcoin can and much more.

## An analogy
Imagine Bitcoin as a landline phone, it was a revolutionary idea that connected people across the world in ways no one could have imagined.

From there those same lines that carried phone signals were adapted to carry digital signals and birthed the Internet that connected people in even more advanced ways.

In this way Bitcoin is the revolutionary idea that connected people in brand new ways.

ETC is the more advanced connection, it takes the blockchain idea into the future, enabling us to do much more than simply send money.

## More than just a blockchain
If the Internet was simply a bunch of interconnected computers, and didn't have any users or people creators making websites, it would be largely useless. In much the same way a blockchain needs users and creators. ETC has both and we're working on solving real world problems of interconnecting people and their devices.

Beyond a blockchain, we are:
- A fair and open community
- A blockchain with a long history of operation
- A blockchain on which all transactions are immutable, or permanent; if someone sends you value on the ETC blockchain, it is yours forever
- The future of the internet of things (IoT)

[NEEDS MORE ABOUT IoT]

# Why ETC?

## Performance
ETC has some of the largest network activity of any blockchain, consistently higher than Bitcoin Cash, and neck-and-neck with Litecoin. We have multiple developer teams, all of whom are committed to the long term ETC vision. We are in the top-10 in programmer activity (measured by code commits). We have numerous sources of funding, and we continue to grow, day-by-day, commit-by-commit, line-by-line of code to create a bullet-proof network that anyone can use without fear of reprisal from a highly influential minority.

## Principles
Immutability. Technology. Community.

The short answer is that blockchains only work as long as everyone agrees to honor them. They are essentially rules to which everyone needs to agree, if they don't then they cannot participate, or they split into other blockchains. Splits are bad for blockchains, they make working and connecting with others difficult.

ETC takes a conservative approach to changes here, and this conservatism avoids splits and protects your money; much like Bitcoin.

ETC is new and reliable technology. It's the longest running smart blockchain in existence.

ETC is a strong and principled community. Many of our members have stuck around since the beginning. We look beyond the hype and keep to the principles that keep blockchains functioning

## Immutability
ETC "accounts" cannot be modified by others. This feature is a philosophy we share with Bitcoin, Litecoin, and other cryptocurrencies.

Some blockchains follow a different philosophy ("governance") which allows participants to use their social and economic power to vote on the account balances of others. Imagine if all the members of your bank believed you had broken a law. Instead of going to the police, those with the biggest balances and notoriety voted to take away your money. Imagine a system where the wealthy and celebrities have the final say over your money. A fundamental aspect of ETC is that this will never be allowed to happen, and historical precedent has demonstrated this to be the case.

## Technology
ETC allows highly efficient value transfers (more so than Bitcoin and its variants), has a focus on IoT applications, and runs a mathematically verified Ethereum Virtual Machine, or EVM. What this means is that ETC is great at what it sets out to do: be a highly efficient means of exchange that connects the world's devices.

IoT features are under active development and will be available later this year.

[NEEDS MORE ABOUT IoT]

## Community
Many blockchain communities have centralized leadership, meaning a few people at the top make the decisions for everyone else. ETC's community is purposely structured to avoid this. Responsibility for development and discussion are distributed between many parties. This prevents the biased form of "governance" that other blockchains are susceptible to.

Blockchains are going to rule the world, providing a mechanism for scaling
social and economic cooperation to an unprecedented level — a truly global
scale. Such cooperation will involve not only human beings, groups and
associations but also a growing multitude of increasingly independent
artificial agents.

Every blockchain creates a social network around its applications, with network value growing exponentially with the number of participants in accordance with Reed’s Law. This value isn’t extracted by intermediaries or controllers, as with previous centralized models. Instead, it’s shared among participants, providing economic incentives for cooperation without coercion.

Not all blockchains are created equal. There are three key characteristics that make scalable blockchain-enabled cooperation possible: openness, neutrality and immutability.

Openness is necessary. It goes without saying that the rules of the game should be open for anyone to see and understand. Anyone should be able to participate in any layer of the system without asking for any permission whatsoever. Anyone should be able to use the network in accordance with its rules. Anyone should be able to create their own client implementing the open protocol. Anyone should be able to contribute to network security, and so on. No registration, identification or other preconditions should limit participation. All such limitations prevent the network from scaling and their enforcement creates centralization risks.

Neutrality is necessary. It’s important for anyone participating in
blockchain-enabled cooperation to be on an equal footing with everyone else. It doesn’t matter if you wield huge economic power or only a tiny amount. It doesn’t matter whether you’re a saintly Mother Theresa or a vicious drug dealer. It doesn’t matter whether you’re a human or a refrigerator. It doesn’t matter what you believe in, what political theory you subscribe to, or whether you’re a moral or immoral person. A participant’s ethnicity, age, sex, profession, social standing, friends or affiliations, make or model, goals, purposes or intentions — none of this matters to the blockchain even a bit. The rules of the game are exactly the same for everyone, period. Without neutrality, the system is skewed towards one set of participants at the expense of others. In that case, it’s less likely to gain universal acceptance and maximize network value for everyone.

Immutability is necessary. The blockchain is a truth machine preserving one universally accepted version of history, one immutable sequence of events. What’s true once is always true, regardless of political or business interests, and no amount of lobbying can change that. If it’s simply not possible to change history, then no resources are wasted on the effort. If there are any loopholes at all, then sufficiently motivated and determined interest groups will exploit them at the expense of others, diminishing network value for everyone.

The rules governing the blockchain network are known in advance. They’re exactly the same for everyone and not subject to change other than with 100% consensus. Yes, it must be 100%. Because any change to the system’s rules that not all participants freely agree to creates a network split, diminishing network value for everyone.

It’s impossible to achieve these blockchain characteristics without the system
being truly decentralized. If any aspect of the blockchain system becomes
subject to centralized control, this introduces an attack vector enabling the
violation of one or more of the key blockchain characteristics. It may be
possible to limit participation (such as by enforcing AML/KYC rules), thus
violating openness. It may be possible to enforce discriminatory policies (such as by filtering “illegal” transactions), thus violating neutrality. It may be possible to rewrite the history of events (such as by confiscating or
“redistributing” funds), thus violating immutability. Introducing centralized
chokepoints creates a precondition for the introduction of “blockchain
intermediaries or controllers” who can siphon value out of the system at other participants’ expense.

So decentralization is the most important feature of blockchain systems, the one everything else depends on. With decentralization, blockchains will come to rule the world. Without it, they’ll be “contained” and railroaded into niche applications.

We decentralists are committed to keeping blockchains open, neutral and
immutable. We’re committed to keeping blockchain systems decentralized. This informs all our actions and positions towards any developments in the crypto world and beyond. All attempts to violate any of the key blockchain
characteristics should be fought. All changes to a blockchain’s rules that
introduce new centralization risks or strengthen existing ones should be fought. Only developments that are clearly beneficial to decentralization or strengthen the three key blockchain characteristics should be supported and encouraged.
The blockchain revolution won’t be centralized. Let’s make sure of it.

Onward.

### NOTE

The ECIP was replaced by ECIP-1017 and
ECIP-1039 which fixed a rounding error in the
ECIP-1017 specification. This ECIP was never activated.

Both of the other ECIPs were activated at block 5,000,000 on the ETC mainnet on 11th December 2017. This ECIP is being retained for historical purposes.

### Abstract

This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with absolute finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a hard limit upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. This occurs in such a way there is a constant decay in miner/uncle reward every epoch until reaching 0, where gas fees are the sole source of reward. This proposal does not include any solution to changes in protocol introducing PoS or other block forging scheme.

### Motivation

At its core, the purpose of adjusting the current monetary policy of the ETC network, to a policy which places a hard limit upper bound on the number of tokens issued and decreases the rate at which ETC is introduced into the system over time, is to "bootstrap" the network’s security. By increasing the security of the network, a proper monetary policy indirectly nurtures the network, providing a secure platform for which smart contract development will be more likely to occur.

If we accept that speculation, a demand function, is the main economic driver of any new system, that the Ethereum Classic Network is a new system, and that speculation will drive the value of the Ethereum Classic token until the utility value of the Ethereum Classic token exceeds its speculative value, it is reasonable to assume that rewarding speculation will help to secure and nurture the network:

Large scale, high risk, and/or high profile applications will be less likely to be developed on a blockchain with weak security ie. a low hashrate. Increasing demand for the Ethereum Classic token will, all else being equal, increase the price of the Ethereum Classic token. An increase in the price of the token incentivizes mining operations to direct their efforts on the Ethereum Classic Network or to begin operations on the Ethereum Classic Network. The additional mining power that is directed towards the network, because of this incentive, further secures the network. An increase in the security of the network assists in building trust between the network and both current and potential users and developers of the network. This increase of trust in the network provides an incentive for large scale, high risk, and/or high profile applications to be developed on the network. Thus, rewarding speculation helps to secure and nurture the Ethereum Classic network.

Especially important to early stage cryptocurrencies, assuming all other variables are equal, a network with a decreasing rate of production and an upper bound on the number of tokens that will be issued will provide more incentive for high risk speculation to occur than one without a known rate of production or an upper bound.

Above all, it is important to recognize that a monetary policy does not directly create value for the network. A stable platform with useful applications and a vibrant community are the variables that drive value. The purpose of a properly structured monetary policy is to create an incentive for people to take a risk on a system that has not yet reached its full potential, providing an additional reason for those who may not otherwise be interested, who cannot or have not developed anything on the platform (yet), or who remain skeptical, to involve themselves in an otherwise nascent platform.

### Specification

#### Current Ethereum Classic Monetary Policy

Source

The current mining rewards on the Ethereum Classic Network are as follows:
- A "static" block reward for the winning block of 5 ETC
- An extra reward to the winning miner for including uncles as part of the block, in the form of an extra 1/32 (0.15625ETC) per uncle included, up to a maximum of two (2) uncles.
- A reward of 7/8 (4.375ETC) of the winning block reward for a miner who has mined an uncled block and has that uncle included in the winning block by the winning miner, up to a maximum of two (2) uncles included in a winning block.
- This reward structure is set to continue in perpetuity.

#### Proposed Ethereum Classic Monetary Policy

Source

##### Block Reward Adjustment Period: 10 Epoch (300,000 blocks)

##### Reward Decay Starting Block: 5,010,000 (Epoch 167)

##### Pre-calculated Decay Options

|Decay Option #|Decay Percentage|Miner Decay Amount|Uncle Decay Amount|Years to Decay|Estimated Supply (Current Reward)|Block Height Reward Ends|
|--------------|----------------|------------------|------------------|--------------|---------------------------------|------------------------|
|1|5.00%|0.2500|0.02500|5.236872146|99,851,032|11,010,000|
|2|4.00%|0.2000|0.02000|5.950342466|100,226,032|12,510,000|
|3|3.00%|0.1500|0.01500|7.139454909|100,851,532|15,009,990|
|4|2.00%|0.1000|0.01000|9.517694064|102,101,032|20,010,000|
|5|1.00%|0.0500|0.00500|16.65239726|105,851,032|35,010,000|
|6|0.50%|0.0250|0.00250|30.92180365|113,351,032|65,010,000|
|7|0.25%|0.0125|0.00125|59.46061644|128,351,032|125,010,000|

### Rationale
- Gradual decay of rewards to 0. Length of time depends on decay rate.
- Dead simple to understand.
- Starting at Epoch 167 (Block # 5,010,000) the decay activates
- Rewards for mining block start at: 5 ETC
- Rewards for mining uncled start at: 0.5 ETC
- Decay persists every 10 Epoch until reaching 0, in which gas costs are the only collected fees
- Simple, nearly straight line supply growth on chart. Only fluctuation is gas rewards/uncle rates, as this is not predictable in all long term models.
- The Epoch Decay model provides a balance between providing an acceptable depreciating distribution rate for rewarding high risk investment into the system, and maintaining an active supply production over time, maintaining a future supply rate and keeping that potential price of the ethereum token suppressed enough to ensure transaction prices can remain lower than if the supply were to reduce to zero at an earlier date. This serves as a "blow off valve" for price increase in the case that a dynamic gas model cannot be implemented for the foreseeable future.
- Having the monetary policy reward decay begin at block 5,010,000 (Epoch 167) provides a balance between delaying the implementation to provide enough time for code development and testing, and accelerating the implementation to provide an incentive to potential early adopters and high risk investors. Based on community discussion, beginning before block 4,000,000 is too soon for development, testing, and implementation of the policy, and later than block 6,000,000 is too long to interest many potential early adopters/investors.
- Not changing the monetary policy of ETC provides no benefit to risk taking early on in the life of the system, speculation wise. It will be difficult for the network to bootstrap its security. While bitcoin has what is considered to be the generally accepted ideal monetary policy, with its 50% reduction every four years, this model is not likely to yield optimal investment for ETC. If ETC were to adopt the bitcoin halving model, it is arguable that too much of the supply would be produced too soon: 50% of the estimated total ETC supply would be mined 75% sooner than traditional bitcoin because of the pre-mine of 72,002,454.77 ETC that was initially created in the genesis block. While the Epoch Decay model does not completely eliminate the effects of the premine, since 50% of total estimated production occurs sooner than would the bitcoin model, it makes up for this, to an extent, depending on how much decay is decided upon.
- In the current ETC reward schedule, the total reward for uncles is higher than the reward received by the miner who also includes uncles. In this state, a miner is significantly diluting the value of his reward by including these uncled blocks. By equalizing the rewards to uncle block miners with the rewards to miners who include an uncle block, the reward structure is more fairly distributed. In addition, equalizing the uncle rewards reduces the incentive for miners to set up an ETC "uncle farm," and instead drives them to better secure the network by competing for the latest "real block."
- Because the rate at which uncled blocks can vary with extreme, reducing the reward for uncle blocks assists considerably with being able to forecast the true upper bound of the total ETC that will ultimately exist in the system.
- The model is the best attempt at balancing the needs to incentivize high risk investment into the system in order to bootstrap security and create a potential user base, be easy to understand, include a reduction to the rate of production of ETC over time, include an upper bound on supply, and also provide for a long term production of the ETC token.

### Implementation
- Timeline for the implementation and the code required to execute after approval.

##### Shout out to @snaproll for the great ECIP template to use. Your time on this is greatly appreciated.

### Abstract

This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with absolute finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a hard limit upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. This occurs in such a way there is a constant decay in miner/uncle reward every epoch until reaching 0, where gas fees are the sole source of reward. This proposal does not include any solution to changes in protocol introducing PoS or other block forging scheme.

### Motivation

At its core, the purpose of adjusting the current monetary policy of the ETC network, to a policy which places a hard limit upper bound on the number of tokens issued and decreases the rate at which ETC is introduced into the system over time, is to "bootstrap" the network’s security. By increasing the security of the network, a proper monetary policy indirectly nurtures the network, providing a secure platform for which smart contract development will be more likely to occur.

If we accept that speculation, a demand function, is the main economic driver of any new system, that the Ethereum Classic Network is a new system, and that speculation will drive the value of the Ethereum Classic token until the utility value of the Ethereum Classic token exceeds its speculative value, it is reasonable to assume that rewarding speculation will help to secure and nurture the network:

Large scale, high risk, and/or high profile applications will be less likely to be developed on a blockchain with weak security ie. a low hashrate. Increasing demand for the Ethereum Classic token will, all else being equal, increase the price of the Ethereum Classic token. An increase in the price of the token incentivizes mining operations to direct their efforts on the Ethereum Classic Network or to begin operations on the Ethereum Classic Network. The additional mining power that is directed towards the network, because of this incentive, further secures the network. An increase in the security of the network assists in building trust between the network and both current and potential users and developers of the network. This increase of trust in the network provides an incentive for large scale, high risk, and/or high profile applications to be developed on the network. Thus, rewarding speculation helps to secure and nurture the Ethereum Classic network.

Especially important to early stage cryptocurrencies, assuming all other variables are equal, a network with a decreasing rate of production and an upper bound on the number of tokens that will be issued will provide more incentive for high risk speculation to occur than one without a known rate of production or an upper bound.

Above all, it is important to recognize that a monetary policy does not directly create value for the network. A stable platform with useful applications and a vibrant community are the variables that drive value. The purpose of a properly structured monetary policy is to create an incentive for people to take a risk on a system that has not yet reached its full potential, providing an additional reason for those who may not otherwise be interested, who cannot or have not developed anything on the platform (yet), or who remain skeptical, to involve themselves in an otherwise nascent platform.

### Specification

#### Current Ethereum Classic Monetary Policy

Source

The current mining rewards on the Ethereum Classic Network are as follows:
- A "static" block reward for the winning block of 5 ETC
- An extra reward to the winning miner for including uncles as part of the block, in the form of an extra 1/32 (0.15625ETC) per uncle included, up to a maximum of two (2) uncles.
- A reward of 7/8 (4.375ETC) of the winning block reward for a miner who has mined an uncled block and has that uncle included in the winning block by the winning miner, up to a maximum of two (2) uncles included in a winning block.
- This reward structure is set to continue in perpetuity.

#### Proposed Ethereum Classic Monetary Policy

Source

##### Block Reward Adjustment Period: 1 Epoch (30,000 blocks)

##### Reward Decay Starting Block: 5,010,000 (Epoch 167)

##### Pre-calculated Decay Options

|Decay Option #|Decay Percentage|Miner Decay Amount|Uncle Decay Amount|Years to Decay|Estimated Supply (Current Reward)|Estimated Supply (1.5% Growth Reward)|Block Height Reward Ends|
|--------------|----------------|------------------|------------------|--------------|---------------------------------|-------------------------------------|------------------------|
|1|0.5000%|0.025000|0.002500|5.236872146|130,071,034.98|130,073,443.73|11,010,000|
|2|0.2500%|0.012500|0.001250|8.090753425|161,716,038.24|161,720,708.59|17,010,000|
|3|0.1250%|0.006250|0.000625|13.79851598|225,006,044.76|225,018,362.75|29,010,000|
|4|0.0625%|0.003125|0.0003125|25.2140411|351,586,057.80|351,991,724.60|53,010,000|

### Rationale
- Gradual decay of rewards to 0. Length of time depends on decay rate.
- Dead simple to understand.
- Starting at Epoch 167 (Block # 5,010,000) the decay activates
- Rewards for mining block start at: 5 ETC
- Rewards for mining uncled start at: 0.5 ETC
- Decay persists each Epoch until reaching 0, in which gas costs are the only collected fees
- Simple, nearly straight line supply growth on chart. Only fluctuation is gas rewards/uncle rates, as this is not predictable in all long term models.
- The Epoch Decay model provides a balance between providing an acceptable depreciating distribution rate for rewarding high risk investment into the system, and maintaining an active supply production over time, maintaining a future supply rate and keeping that potential price of the ethereum token suppressed enough to ensure transaction prices can remain lower than if the supply were to reduce to zero at an earlier date. This serves as a "blow off valve" for price increase in the case that a dynamic gas model cannot be implemented for the foreseeable future.
- Having the monetary policy reward decay begin at block 5,010,000 (Epoch 167) provides a balance between delaying the implementation to provide enough time for code development and testing, and accelerating the implementation to provide an incentive to potential early adopters and high risk investors. Based on community discussion, beginning before block 4,000,000 is too soon for development, testing, and implementation of the policy, and later than block 6,000,000 is too long to interest many potential early adopters/investors.
- Not changing the monetary policy of ETC provides no benefit to risk taking early on in the life of the system, speculation wise. It will be difficult for the network to bootstrap its security. While bitcoin has what is considered to be the generally accepted ideal monetary policy, with its 50% reduction every four years, this model is not likely to yield optimal investment for ETC. If ETC were to adopt the bitcoin halving model, it is arguable that too much of the supply would be produced too soon: 50% of the estimated total ETC supply would be mined 75% sooner than traditional bitcoin because of the pre-mine of 72,002,454.77 ETC that was initially created in the genesis block. While the Epoch Decay model does not completely eliminate the effects of the premine, since 50% of total estimated production occurs sooner than would the bitcoin model, it makes up for this, to an extent, depending on how much decay is decided upon.
- In the current ETC reward schedule, the total reward for uncles is higher than the reward received by the miner who also includes uncles. In this state, a miner is significantly diluting the value of his reward by including these uncled blocks. By equalizing the rewards to uncle block miners with the rewards to miners who include an uncle block, the reward structure is more fairly distributed. In addition, equalizing the uncle rewards reduces the incentive for miners to set up an ETC "uncle farm," and instead drives them to better secure the network by competing for the latest "real block."
- Because the rate at which uncled blocks can vary with extreme, reducing the reward for uncle blocks assists considerably with being able to forecast the true upper bound of the total ETC that will ultimately exist in the system.
- The model is the best attempt at balancing the needs to incentivize high risk investment into the system in order to bootstrap security and create a potential user base, be easy to understand, include a reduction to the rate of production of ETC over time, include an upper bound on supply, and also provide for a long term production of the ETC token.

### Implementation
- Timeline for the implementation and the code required to execute after approval.

##### Shout out to @snaproll for the great ECIP template to use. Your time on this is greatly appreciated.

## Abstract

We present a proposal for ETC to use blocks mined with SHA-256 in Bitcoin to detect blockchain branches that have been mined in private and rise alarms that can prevent double-spend attacks. The proposal enables full nodes to take local decision to prevent certain attacks, but also the existence of a public view of the different competing ETC branches enables the use a Fork Monitoring System that can provide more detailed alerts to full nodes and to the community.

## Motivation

During August 2020, Ethereum Classic was the target of two successful 51% attacks. The events have shown that the current levels of security provided by the Ethash miners are not enough.

To make ETC more secure, this proposal presents an enhancement that allows full nodes to know if the best chain they have choosen was publicly available at the time of creation or it was hidden to the network. Two measures are computed by the node: the cumulative visibility score and the average visibility score over a period of 1000 blocks. The higher the cumulative score, the highest the amount of information that was timely made public about this blockchain. Alarms can be established when the average visibility score drops below a certain threshold, such as 70%.
ETC users can buy visibility proofs using a trustless contract running on the RSK blockchain. A Visibility proof contains a checkpoint in the ETC blockchain that the user wants to be visible. The contract is queried by Bitcoin miners, which take the checkpointed block and publishes it in the coinbase of blocks.

By leveraging RSK network’s existing merged mining capabilities with Bitcoin, RSK can forward the ETC checkpoint information to Bitcoin miners in order to link it to a Bitcoin block and access Bitcoin SHA-256 security levels. The process that allows this is called Universal Merged Mining (UMM) and currently provides access to 100% of the Bitcoin Network Hashrate, at a frequency of one checkpoint every 20 minutes.

## Specification

Changes must be done in different parts of the ETC protocol. A description of changes follows:

### VisibilityProof

Every block can be referenced by zero, one or more than one VisibilityProof messages. A VisibilityProof message that references a block can be included in any of the following 256 blocks of the referenced block. A VisibilityProof message therefore attests that Bitcoin hashrate has confirmed the referenced block.

VisibilityProof messages are non-interactive SHA256 proofs-of-work and they can be verified by ETC without connecting to the Bitcoin network, similar to merge-mining proofs.

A VisibilityProof score is measured by sum of the scores of the Bitcoin headers that reference it, either from a single VisibilityProof message or from multiple messages. The score of a Bitcoin header is the difficulty of the block, specified in the header.

Each VisibilityProof message m contains P(m) merge-mining proofs. Each merge-mining proof contains a Bitcoin header. Each header must have a hash that matches the difficulty established by the header.

There are two types of Bitcoin headers: a hit and a hit confirmation. A hit must have a merge-mining proof that relates the header unequivocally to an ETC block. A hit confirmation is a child of a hit or a child of another hit confirmation. Hit confirmations are proven to not reference any other ETC block. Hit confirmations are "unclaimed" proof-of-work that ETC claims to protect from private miners. Hit confirmations must come after hits in the VisibilityProof message. Each hit confirmation must have the prior block header as parent. For example, the following is a valid VisibilityProof message (in brackets we show 16-byte truncated block hashes, merge-mining proofs are omitted):

Hit Confirmations can prove not to contain the merge-mining tag and merge-mining tree root, or they can prove to contain the tree, but not an ETC block in the tree (proof of non-membership). To prove non-membership the Merge-Mining tree has nodes augmented with the minimum blockchain ID and maximum blockchain IDs of the contained children. ETC Blockchain ID is 61.

### VisibilityProof Message Format

The format of a VisibilityProof message is the following:

For Membership Proofs("RSKBLOCK:"):
Terminal-Hash = Keccack(ChainID | ETC-Block-Hash | ETC-Address | Armadillo-Data)[0..11]

Each Bitcoin header is associated with a its coinbase transaction by a Merkle membership proof for the Bitcoin Transaction Merkle Tree root. Not all the coinbase transaction needs to be presented, but only the tail, containing the merge-mining tag ("RSKBLOCK:"). The tail contains up to 128 bytes of coinbase transaction. To prove the tail corresponds to the coinbase transaction hash, a SHA256 mid-state is given. This mid-state is extender with the tail to finalize the coinabse and obtain the coinbase transaction hash. Since the believed bit-security of a SHA256 freestart colission attack is much higher than the proof-of-work established by the Bitcoin Header, the compression provided by the coinbase tail does not pose a security risk. For hits (membership proofs) the tail contains the merge-mining tag, followed by the hash digest of the root of a merge-mining tree of block hashes. For hit confirmations (non-membership proofs) the tail must not contain the tag or must contain the tag and the tree but without an ETC block in it. The Terminal-Hash is a 20-byte Keccak hash digest prefix of the ChaiID, the ETC-Block-Hash and the ETC-Address to pay the reward. This address can be the same as the miner address that includes the VisibilityProof or it can be a different address. Finally, for a Merkle membership proof of the ETC block hash in this new tree is added to the proof. The ETC-Block-Hash must match the block in the ETC blockchain at height ETC-Block-Height.

The ETC-Address is verified so that all blocks presented must belong to the same ETC-Address. If the miner address does not match the ETC-Address, then the ETC-Address fields must be present. The signature signs the Payload with the private key associated with the ETC-Address address. This ensures that the payload comes from the owner of the ETC-Address.

### Armadillo Data Verification

The Armadillo Data allows a Fork Monitoring System to build a DAG of all the ETC forks in existence by connecting individual Bitcoin headers. The Armadillo Data is submitted along with the ETC-Address and ETC-Block-Hash to the Bitcoin mining system (through RSK). The ETC Blockchain consensus must verify that the Armadillo data is correct. Armadillo data contains 2 elements: the Commits-To-Parent-Vector and the Total-Difficulty-Compressed. The first element is an array of 8 element. Each element e(i) is an Uint16 that representsthe 16 less significant bits of the ETC block hash at position n-(n mod 32)-(i*32), where n is the height of the block being checkpointed.
The total difficulty is compressed simply by taking the 64 most significative bits.

### Proof Size

The size of a VisibilityProof message is variable. Normally it will contain a single Bitcoin block. However, it could contain more. We establish a maximum size of 10 Kilobytes per VisibilityProof proof. The additional bandwidth and storage space required by VisibilityProof messages is irrelevant to ETC.

### Alarm Thresholds

We propose that for each window of 1000 blocks (with a delay of 256 blocks), the average visibility score is computed. If the visibility score decreases below 80% of the score of the previous interval, the node will enter a safe-mode and stop confirming transactions (in case of an exchange, it will not confirm an ETC deposit).

Because RSK handles the construction of the merge-mining tag to be included in Bitcoin blocks, the ETC community will be able to detect immediately if the Bitcoin network is producing VisibilityProof for a bock different from the ETC honest bestchain. Such event can trigger automatic notifications to exchanges and other economic actors.

### Block Format

To avoid changing the ETC block header format, the VisibilityProof proof can be included as an uncle, with a specil magic prefix to distiguish it from normal uncles. It can also be added in the ExtraData field. Of course, a new special field visibilityProofs can be added to the ETC block header.

 >

### Inclusion of VisibilityProof Proofs

On a first version, EtHash miners will be the only ones that will have the possibility to add VisibilityProofs to their blocks.

In the future, the ETC network can propagate VisibilityProofs messages and we can let any user participate and collect fees from this system. This requires no changes to consensus.

### Rewards

If a miner decides to add a VisibilityProof message in a slot, it will be rewarded by an extra subsidy. To prevent changing the ETC supply function, the extra subsidy will be obtained by diluting all remaining block subsidies by a fixed percentage. The exact amount is to be decided by the community but we propose this to be 10% of the current subsidy, starting at 1% and increasing until 10% during a period of 3 months. This will allow for EtHash miners to adapt and provides enough incentives for them to start using the RSK UMM system to obtain VisibilityProofs for their blocks.

To enable the creation of an independent and open VisibilityProofs market, a small percentage (i.e. 5%) of the Visibility subsidy is paid to the miner who included the VisibilityProof message. The remainder is paid to the ETC-Address (funds are directly added to the account balance without contract code execution). If the miner address matches the ETC-Address, then all reward will be paid to the same account.

### Timestamp Validation

The timestamp of Bitcoin hit header must be not higher than 10 minutes and not lower than 10 minutes of thetimestamp of the ETC checkpoint referenced by the VisibilityProof. This prevents Bitcoin miners from creating visibility proofs for old or future branches of the ETC blockchain.

### JSON-RPC Interface
Expose two new methods:
- getSHAWork: retrieves SHAsh to be used for merged mining with Bitcoin.
- submitSHAPoW: receives all the needed elements to validate the PoW and then create the UMM uncle block.

## Rationale

The spirit of this proposal is to present a simple way to provide ETC with an otional system that can temporarily or permanently protect it from 51% attacks by establishing a strong deterrent. To achieve that:
- VisibilityProof messages are included as uncles so the system is the least invasive way as possible.
- In the current version, VisibilityProof messages are included by mining nodes. However, the system allows any user to participate in the VisibilityProof system. This extension requires adding a new message to the wire protocol the relay of VisibilityProof proofs.
- By having a non-mandatory addition of VisibilityProof messages, ETC blockchain can keep working normally even if with no VisibilityProof on the blocks.

## Universal Merged Mining

Universal Merged Mining offers access to Bitcoin SHA-256 PoW by forwarding the to-be-validated information through smart-contracts deployed on the RSK blockchain.

In order to get the information validated, "merge-mining proof time" must be bought in advance. A smart-contract that runs a public blind auction exists in RSK for that purpose. The auction will be open for a fixed period of time and once finished the winner will get the right to include the information in all the merge-mined Bitcoin blocks for the time he bought. Initially the contract will auction one hour intervals, but this value can be chosen freely. The auction floor will be a value that covers the a number K of Bitcoin blocks that can be mined for the auctioned period of time (i.e K=12). A winner gets the chance to submit the ETC block Hash (that corresponds to a VisibilityProof) to the contract during the acquired interval. The auction contract monitors all Bitcoin blocks mined for the winner and counts the actual number of hit blocks and hit confirmations that occurred during the time interval bought by the buyer. If less than K blocks are mined during the interval, then the funds overpaid are immediately refunded to the buyer at the end of the period.

Internally, once the contract receives the data from the auction winner, RSK mining nodes start mining Bitcoin blocks with the given information in the merge-mining Merkle tree, whose root is specified in the coinbase transaction.
Not all RSK blocks fulfill Bitcoin difficulty, and therefore the UMM system only focuses on the blocks that occur after the first hit (including the hit).

## Detecting and Preventing Visible Double-Spend Attacks

An ad-hoc double-spend monitoring system similar to RSK's Armadillo protection system should be deployed.
This system can product succinct proofs that can convince any node that an attack is ongoing without the need for this node to connect to the Bitcoin network. This enables the creation of an alert system embedded into the ETC network that can propagate alerts and automatically protect nodes, increasing the soundness at the cost of availability. However, the sole existence of the system is enough of a deterrent to prevent attacks and therefore availability is not normally affected.
Exchanges can stop confirming deposits during attack periods to prevent being affected by double-spend attacks.

## Detecting and Preventing Hidden Double-Spend Attacks

We've shown that the VisibilityProof system provides monetary incentives to include visibility proofs, but the incentives are too low to guarantee protection against a hidden attacker that double-spends against an online exchange. We must ensure that there are stronger incentives for VisibilityProofs to exists, forcing the malicious fork to be become public. Once the fork is public, the Armadillo monitoring system can produce useful alerts.
Since several methods are possible to increase the need of VisibilityProofs, we think the method chosen should be specified in a separate ECIP.

However, here we present some possibilities:
- Request at least 33% of the Bitcoin hashrate providing visibility proofs with at least one visibility proof every 3 hours, in order to consider the fork valid. The forked chain can achieve this by including a single VisibilityProof hit every 3 hours.
- Using a system such as PirlGuard to penalize forks that do not provide visibility proofs. Our suggestion is that a fixed visibility threshold is chosen, and penalization either occurs or not (boolean). It's also possible to penalize in inverse proportion to the visibility of a fork, but the effects on the stability of the blockchain in this case must be further studied.

## Copyright/Licensing

GNU Lesser General Public License v3.0.

# Abstract

The following describes a method of preventing a 51% attack on Ethash-based POW chains.

# Motivation

Ethereum CLassic suffered a number of 51% attacks already. Here you can find an article from Cointelegraph describing the 51% attack on 6 Aug 2020. Here you can find another article describing the 51% attack on 10 Jan 2019. As long as ETC protocol remains unchanged it is susceptible for more 51% attacks.

# Specification

The proposed solution refers to the PirlGuard protocol.

The description of the protocol states that instead of automatically syncing with any privately-mined chain branch the new protocol should require the peer proposing the privately-chain (and the reversal of the publicly mined and synced blocks) to mine a number of "penalty" blocks. The number of penalty blocks must depend on the number of the original blocks that would be reverted if the chain will reorganize and sync to the proposed (privately-mined) branch. Thus the cost of the 51% attack will dramatically increase as the attacker will not be able to mine his private branch and then broadcast it to the network thus reverting all the transactions from the "main" branch.

# Rationale

This protocol is already implemented in Pirl and Callisto Network. The protocol has a working time tested reference implementation. The proposed change requires minimal modifications of the Ethereum CLassic protocol while offers a reliable method of protecting against the recent attacks and the relevant threat of newer similar attacks.

# Implementations

Here is a reference implementation of the protocol in GO lang: https://github.com/EthereumCommonwealth/go-callisto/blob/master/core/pirl_guard.go

https://github.com/EthereumCommonwealth/go-callisto/blob/master/core/blockchain.go#L1540

# Copyright

This ECIP is licensed under GNU Lesser General Public License v3.0.

lang: en
ecip: 1028
title: Private Sidechain checkpoints
author: Igor Artamonov
status: Draft
type: Standards Track
category: Interface
created: 2017-07-18

# Abstract

This proposal is a part of Multi Chain proposal defined by ECIP-1027. It provides a solution for a Private Chain
based on Proof of Authority [1] connected to ETC Main Chain.

# Motivation

Private Chains with PoS or PoA consensus algorithms are common solution for global business that needs a
distributed way of processing data on blockchain. This types of blockchain are executed in trusted environment in
a private network, and don’t need any communication with external entities. PoS/PoA are able to provide most of
functionality required for such processing, but lack of security and data immutability usually provided by PoW.

Checkpoints proposed in ECIP-1027 are able to improve security and data immutability
of such Private Chains.

# Specification
- Network has a custom Private Chain working under Proof-of-Authority
- Network has a Checkpoint Contract in public ETC mainnet with methods makeCheckpoint and getLastCheckpoint
- Network has set of trusted nodes with access to external network to make checkpoint, this can be same nodes as
 PoA or different set of nodes. Checkpoint is made every N blocks, where N can reflect from 1 minute to few hours
 of blockchain time and it does not affect Private Chain performance under normal conditions.
- Checkpoint Contract has list of addresses with granted access to make checkpoints
- Only one possible checkpoint is possible per Block Height, and height of a new checkpoint must be higher that
 existing checkpoint. Otherwise Trusted Nodes should come to agreement about Correct Fork if a
 network split is observed, this logic can be implemented in the Checkpoint Contract as well.
- A checkpoint is a Hash of State Root + Block Height in the Private Chain, which does not leak any internal data
 to public chain (Hash(StateRoot | BlockHeight))
- A Private Chain peer periodical check Checkpoint Contract and in case of chain split chooses chain cornered to
 that contract most recently.

# Implementation

WARNING: following code is is for illustrative purpose only. It’s a very simplified implementation, should not
be used in a production system.

## Contract

## Consensus:

# References
1. Proof of Authority Chains - https://github.com/paritytech/parity/wiki/Proof-of-Authority-Chains
2. Factom - Business Processes Secured by Immutable Audit Trails on the Blockchain (Paul Snow, Brian Deery,
 Jack Lu, David Johnston, Peter Kirby)

## Simple Summary

Specification for an extension of ECIP-1040 to allow contract creation
transaction to create multiple versions.

## Abstract

This ECIP defines an extension to the base layer of account versioning
(ECIP-1040) to allow multiple account versions to be used in contract
creation transaction. Although this is not necessary at this moment,
it will once we have multiple independent VMs (such as eWasm).

## Motivation

The base account versioning layer only allows contract of the
newest version to be deployed via contract creation transaction. This
is a reasonable assumption for current Ethereum network, because most
of new features added to EVM are additions, and developers almost
never want to deploy contracts that are not of the newest version. In
this section, we provide an extension to allow multiple versions of
contracts to be deployed via contract creation transaction.

## Specification

Add an additional field version (256-bit integer) in contract
creation transaction. So it becomes nonce, gasprice, startgas,
to, value, data, v, r, s, version. When signing or
recovering, sign ten items, with v, r, s as defined by EIP-155.

The transaction would be executed with the code's version in
version supplied, and deploys contract of version. If version is
not supported or validation does not pass, return out-of-gas.

## Rationale

By providing the additional field version, a contract creation
transaction can specify which version it wants to deploy. In case of
two independent VMs such as EVM and eWASM, we can allow two
LATEST_VERSIONs to be specified -- one for EVM and another for
eWASM. Both of them then can deploy new contracts via transactions.

## Backwards Compatibility

This ECIP only changes transaction formats and does not change any VM
execution logic, thus it has no backwards compatibility issue.

## Test Cases

Not yet provided.

## Implementation

Not yet implemented.

## Copyright

This work is licensed under Apache License, Version
2.0.

## Simple Summary

Specification for an extension of ECIP-1040 to allow an EVM contract to
create multiple versions.

## Abstract

This ECIP defines an extension to the base layer of account versioning
(ECIP-1040) to allow an EVM contract to create sub-contracts of
multiple versions. Although this is not necessary at this moment, it
will be a nice-to-have add-on.

## Motivation

The base account versioning layer only allows contracts of the same
version to be deployed through CREATE and CREATE2. In this
section, we provide an extension to allow different versions of
contracts to be deployed via them, by providing two new opcodes,
VCREATE and VCREATE2.

## Specification

Define two new opcodes VCREATE and VCREATE2 at 0xf6 and 0xf7
respectively. VCREATE takes 4 stack arguments (version, value, input
offset, input size), and VCREATE2 takes 5 stack arguments (version,
endowment, memorystart, memorylength, salt). Note that except the
stack item version, other arguments are the same as CREATE and
CREATE2.

The two new opcodes behave identically to CREATE and CREATE2,
except that it deploys contracts with version specified by stack item
version.

The network at all times maintains a constant list within the client
of all deployable versions (which can be different from supported
versions). Upon VCREATE and VCREATE2, if the specified version
is not on the list of deployable versions, return out-of-gas.

## Rationale

By providing two additional opcodes VCREATE and VCREATE2, contract
developers can deploy new contracts that take advantage of them to
create new sub-contracts of multiple versions. This may be useful for
situations like upgradable contracts (while it currently still can be
done via proxy contacts using only base layer account versioning).

## Backwards Compatibility

This ECIP introduces two new opcodes for EVM runtime. Based on current
assumed invariants, it should not have any noticeable backward
compatibility issues.

## Test Cases

Not yet provided.

## Implementation

Not yet implemented.

## Copyright

This work is licensed under Apache License, Version
2.0.

# Abstract
### What is this?

This is a proposal to add OpenRPC support to existing and future JSON-RPC services by adding the method rpc.discover to the projects JSON-RPC APIs, enabling automation and tooling.

# Motivation
### What is the problem?
- Maintenence time and accuracy on:
- Not all JSON-RPC servers return the same methods or return the same version of the API.
- There is nothing that provides both human and machine-readable interfaces to be able to interact with JSON-RPC.
- Communication between services in different programming languages is not easy.
- Implementation usually comes at the cost of user experience consuming the API.

# Implementation
### How do I Solve the problem?
JSON-RPC APIs can support the OpenRPC specification by implementing a service discovery method that will return the OpenRPC document for the JSON-RPC API. The method MUST be named rpc.discover. The rpc. prefix is a reserved method prefix for JSON-RPC 2.0 Specification system extensions.

### Use Case
This is the vision for the use case of OpenRPC and how it would relate to multi-geth:

# Specification

### What is OpenRPC?
The OpenRPC Specification defines a standard, programming language-agnostic interface description for JSON-RPC 2.0 APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenRPC, a consumer can understand and interact with the remote service with a minimal amount of implementation logic, and share these logic patterns across use cases. Similar to what interface descriptions have done for lower-level programming, the OpenRPC Specification removes guesswork in calling a service.

##### Structure
This is the structure of an OpenRPC Document:

The OpenRPC Document that specifies all the methods an EVM-based blockchain should implement can be found here.

# Rationale
### Why would we do this?
Services need to figure out how to talk to each other. If we really want to build the next generation of automation, then having up to date libraries, documented APIs, and modern tools are going to provide easy discovery, on-boarding, and enable end user and developer interaction.

Use cases for machine-readable JSON-RPC 2.0 API definition documents include, but are not limited to:
- A common vocabulary and document will keep developers, testers, architects, and technical writers all in sync.
- Server stubs/skeletons generated in many languages
- Clients generated in many languages
- Mock Server generated in many languages
- Tests generated in many languages
- Documentation Generation

# Alternative
OpenRPC documents just describe JSON-RPC APIs services, and are represented in JSON format. These documents may be produced and served statically OR generated dynamically from an application and returned via the rpc.discover method. This gives projects and communities the flexibility to adopt tools before the rpc.discover method is implemented.

### Simple Summary

Enable the outstanding Ethereum Foundation Constaninople and Petersburg network protocol upgrades on the Ethereum
Classic network in a hard-fork code-named Agharta to enable maximum compatibility across these networks.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the
Constaninople and Petersburg hardforks. The proposed changes for Ethereum Classic's Agharta upgrade include:
- Constantinople bitwise shifting instructions
- Constantinople skinny CREATE2 opcode
- Constantinople EXTCODEHASH opcode

This document proposes the following blocks at which to implement these changes in the Classic networks:
- 5000381 on Morden Classic Testnet (November 13, 2019)
- 301243 on Mordor Classic Testnet (November 20, 2019)
- 1705549 on Kotti Classic Testnet (December 11, 2019)
- 9573000 on Ethereum Classic Mainnet (January 15, 2020)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification
section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes shall be added to the Ethereum Classic
networks, all of which have been in use on the Ethereum Foundation networks since early 2019.

### Specification

Enable the following three hard fork features:
- EIP 145 (Bitwise shifting instructions)
- EIP 1014 (Skinny CREATE2 opcode)
- EIP 1052 (EXTCODEHASH opcode)

### Rationale

Atomicity: This protocol specification notably merges the scheduled features of the anticipated Petersburg
protocol upgrade, which would removes the buggy proposal SSTORE net-gas metering.

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for
developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden,
Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing
contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of
them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM
increases its functionality and should be considered a feature upgrade rather than a modification.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Constaninople and Petersburg features currently:
- Geth Classic: full support in v6.1.0 and later
- Parity Ethereum: all features due to Ethereum Foundation compatibility
- Multi Geth: all features due to Ethereum Foundation compatibility
- IOHK Mantis: no support_
- Hyperledger Besu: all features due to Ethereum Foundation compatibility

## Copyright

Copyright and related rights waived via CC0.

## Simple Summary

Defines a new transaction type that has a field for a constraint on ancestor block hash.
Transactions with this field are only valid on chain segments that include the defined ancestor.

## Abstract

We introduce a new EIP-2718 transaction type with the format 0x4 || rlp([chainId, ancestorHash, nonce, gasPrice, gasLimit, to, value, data, accesslist, yParity, senderR, senderS]).

This proposed ancestorHash element adds a constraint on the validity of a transaction to a chain segment containing the cited ancestor in its graph.

## Motivation

Establish a protocol-based mechanism with which transactions are able to articulate a constraint on some chain state.

Generally, this constraint gives the consumer (the transactor) an ability to express requirements about the transaction's relationship to blockchain data and its provenance.
- Restrict transaction applicability to a chain context that is currently available and reasoned about under some subjective view.
- Restrict transaction applicability to a chain context following some foregoing block (and its transactions).

## Specification

### Parameters
- FORKBLOCKNUMBER TBD
- TRANSACTIONTYPENUMBER 0x4. See EIP-2718.

As of FORKBLOCKNUMBER, a new EIP-2718 transaction is introduced with TransactionType TRANSACTIONTYPENUMBER.

The EIP-2718 TransactionPayload for this transaction is rlp([chainId, ancestorHash, nonce, gasPrice, gasLimit, to, value, data, accesslist, yParity, senderR, senderS]).

The EIP-2718 ReceiptPayload for this transaction is rlp([status, cumulativeGasUsed, logsBloom, logs]).

### Definitions

### Validation

The values defined below act as a constraint on transaction validity.
Transactions defining constraints which are not satisfied by their chain context should be rejected as invalid.
Blocks containing invalid transactions should be rejected as invalid themselves, per the status quo.

#### ancestorHash
- ancestorHash bytes. A byte array 32 bytes in length.

The ancestorHash is a reference to a specific block by hash.
If a transaction filling this field is included in block number n, the annotated value must match some block numbered <= n-1 and existing as a direct (canonical; non-ommer) ancestor of the transaction's containing block.
A "direct ancestor" means that the hash of the block must exist in the parentHash tree of the chain.

The ancestorHash value should be RLP encoded as a byte array for hashing and transmission.

## Rationale

The ancestorHash field allows the transactor to express and guarantee an assumption about some contemporary chain state for their pending transaction.

Reference to some assumed blockchain state for transaction composition is already the common case.
A transaction sender might reference their view of the chain to fill the transaction's nonce field, to check their balance, and even to determine the availability or pricing of some op code (via a hypothetical fork upgrade).

Currently, these references to a chain state during transaction composition are tacit and passive.
If the transactor's assumption breaks, their transaction may yield an unintended or undesired outcome.
ancestorHash facilitates the declaration of these state assumptions, and demands their correctness in order for the transaction to be permitted.

Chain state on Ethereum only approaches finality, while its transactions are subject to somewhat arbitrary inclusion and ordering.
This mechanism allows transactors to express demands about foregoing chain state for the eligibility of their transactions.

In this way, ancestorHash values can operate as an observable heuristic for confidence (on behalf of transactors) about the finality of the chain state.
These measurements could be used to inform confirmation delay values of creditors.

### Example Scenarios

#### Finality duping

Elon owns 1000000ETH.
Fred owns 100ETH.
Elon issues a transaction sending his balance to a known currency exchange, apparently selling this share in the currency.
This transaction is included at block number 1,000,000 with hash 0xb2957ab683ae69176b2eb7858f2baedb93752cb7cb45284529d543eebe20652e.

Upon the publication of this block, Fred sees this transaction and thinks that he should follow in Elon's footsteps to protect his capital from speculative devaluation.
Fred constructs and publishes a similar transaction, which he expects to be included in some subsequent block.

By accident or design, block 0xb2957ab683ae69176b2eb7858f2baedb93752cb7cb45284529d543eebe20652e is orphaned, replaced with 0x51c7fe41be669f69c45c33a56982cbde405313342d9e2b00d7c91a7b284dd4f8.
This replacement block does NOT contain Elon's transaction (or contains an alternative, replacement transaction from Elon), but it does contain Fred's transaction.

Fred has been duped into a sale, while Elon hodls and profits.

If Fred can cite 0xb2957ab683ae69176b2eb7858f2baedb93752cb7cb45284529d543eebe20652e as an ancestorHash dependency, his transaction will be inapplicable on the newly reorganized chain, and he won't get duped.

#### Double-spend

Transactions citing ancestors on a public chain will not be valid on an attacker's secret chain if the citations reference post-fork blocks.

Under the current protocol conditions, a double-spend attacker can choose to include none, some, or all-but-one of the public chain's transaction on their attack chain.

We assume for the sake of this scenario's argument that all transactors on the public chain use ancestorHash values four blocks prior to their time of issuance.
Four blocks after the attacking fork, the attack chain will be entirely absent of those public transactions (thus approaching the 'none' option).

This scenario forces the hand of the attacker away from a targeted attack with a single victim toward an attack that jeapordizes the interests of all transactors during that time.
Although risk is increased for the public users in this scenario, so too -- and at a larger, aggregated, magnitude -- is the risk for the attacker in the potential for a counterattack on behalf of the original public chain.

### Redundancy to chainId

This pattern can be understood as a correlate of EIP-155's chainId specification.
EIP155 defines the restriction of transactions between chains; limiting the applicability of any EIP-155 transaction to a chain with the annotated ChainID.
ancestorHash further restricts transaction application to some subsection ("segment") of a chain defined under EIP-155.

From this constraint hierarchy, we note that an alternative implementation of ancestorHash could make chainId conceptually redundant.

#### So why keep chainId?

chainId is maintained as an invariant because:
- The use of the transaction type proposed by this EIP is optional, implying the continued necessity of chainId in the protocol infrastructure and tooling for legacy and other transaction types.
- The presence of ancestorHash in the transaction type proposed by this EIP is optional. If the value is not filled by an RCC transaction, the demand for chainId remains.
- A chainId value is not necessarily redundant to ancestorHash, namely in cases where forks result in living chains. For example, an ancestorHash reference to block 1919999 would be ambiguous between Ethereum and Ethereum Classic.
- It would be possible to specify the omission of chainId in case of ancestorHash's use. This would add infrastructural complexity for the sake of removing the few bytes chainId typically requires; we do not consider this trade-off worth making.

### EIP-2930 Inheritance
The EIP-2930 Optional Access List Type Transaction is used as an assumed "base" transaction type for this proposal.
However, this is NOT a conceptual dependency; the included accessList portion of this proposal (the only differential from post-EIP-155 legacy transaction fields) can readily be removed.
Standing on the shoulders of EIP-2930 is only intended to support and further the adoption of next-generation transactions.

### Signature target

The signature signs over the transaction type as well as the transaction data.
This is done to ensure that the transaction cannot be “re-interpreted” as a transaction of a different type.

## Backwards Compatibility

There are no known backward compatibility issues.

## Security Considerations

### Validation costs

Validation of ancestorHash demands the assertion of a positive database hit by block hash.
This requires that the chain validator fills the role of a chain reader.
This necessary lookup can be cached (and maybe already is for some clients), but we must expect less than 100% hits on cached values, since the lookup value is arbitrary.
With that in mind, however, the value provided to a transaction using a deep ancestorHash is increasingly marginal, so we should expect
most transactions using this field to use a relatively small set of common, shallow, cache-friendly values.

### Transaction size increase

The proposed additional fields, if used, increase transaction size by 32 bytes.

## Copyright

Copyright and related rights waved via CC0.

### Simple Summary

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.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the
Spurious Dragon and Byzantium hardforks. The proposed changes for Ethereum Classic's Atlantis upgrade include:
- Spurious Dragon state-trie clearing.
- Spurious Dragon contract-code size limit.
- Byzantium EVM opcodes, namely REVERT, RETURNDATASIZE, RETURNDATACOPY, and STATICCALL.
- Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve altbn128,
 optimal ate pairing check on the elliptic curve altbn128, and BIGINT modular exponentiation.
- Replacing the intermediate state root field in transaction receipts with the contract return status.
- Change difficulty adjustment to target mean block time including uncle.

This document proposes the following blocks at which to implement these changes in the Classic networks:
- 100 on Kensington Classic PoW-testnet (early June 2019)
- 716617 on Kotti Classic PoA-testnet (mid June 2019)
- 4729274 on Morden Classic PoW-testnet (early July 2019)
- 8772000 on Ethereum Classic PoW-mainnet (mid September 2019)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification
section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes and precompiled contracts shall be added
to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017.
Adoption of the receipt status feature provides a helpful method for decentralized-application developers to access
the successful or failed state of a contract. This would establish a higher level of interoperability between Foundation
and Classic EVMs, and make a more extensive array of tooling available for the ETC network (e.g., Solidity version,
contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment
algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable
issuance rate that cannot be manipulated upward by manipulating the uncle rate.

### Specification

Technical specifications for each EIP can be found at those documents respectively:
- EIP 100 (Change difficulty adjustment to target mean block time including uncles)
- EIP 140 (REVERT instruction in the Ethereum Virtual Machine)
- EIP 161 (State-trie clearing)
- EIP 170 (Contract-code size limit)
- EIP 196 (Precompiled contracts for addition and scalar multiplication on the elliptic curve altbn128)
- EIP 197 (Precompiled contracts for optimal ate pairing check on the elliptic curve altbn128)
- EIP 198 (Precompiled contract for BIGINT modular exponentiation)
- EIP 211 (New opcodes RETURNDATASIZE and RETURNDATACOPY)
- EIP 214 (New opcode STATICCALL)
- EIP 658 (Embedding transaction status code in receipts)

In case any of the before mentioned proposals define a variable similar to the pattern *FORKBLKNUM named after Spurious Dragon or Byzantium, it shall be replaced by a ATLANTISFORKBLKNUM.

### Rationale

Atomicity: This protocol specification notably omits the scheduled features of the anticipated Constantinople
protocol upgrade, which would be expected to include various further EVM upgrades. This allows for dedicated testing of
the proposed changes in light of multiple delays of the Constantinople fork
(a postmortem of the latest delay).

Interoperability: establishing and maintaining interoperable behavior between Ethereum clients is essential for
developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden,
Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing
contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of
them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes and precompiled
contracts to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Spurious Dragon and Byzantium_ features currently:
- Geth Classic: partial support for EIP-658 receipt status code change
- Parity Ethereum: all features due to Ethereum Foundation compatibility
- Multi Geth: all features due to Ethereum Foundation compatibility
- Mantis: all features due to Ethereum Foundation compatibility

## Copyright

Copyright and related rights waived via CC0.

### Simple Summary

Enable the outstanding Ethereum Foundation Istanbul network protocol upgrades on the Ethereum
Classic network without any gas-cost assumptions in a hard-fork code-named Aztlán (Yingchun Edition) to enable
maximum compatibility across these networks.

The Yingchun Edition refers to the preferred variant of Aztlán without any repricing of state-trie
dependent opcodes as previously proposed in ECIP-1072.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the
Istanbul hardforks. The proposed changes for Ethereum Classic's Aztlán upgrade include:
- Add Blake2 compression function F precompile
- Reduce altbn128 precompile gas costs
- Add ChainID opcode
- Calldata gas cost reduction
- Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

This document proposes the following blocks at which to implement these changes in the Classic networks:
- ~~778507 on Mordor Classic PoW-testnet (activated on Jan 30th, 2020)~~
- ~~2058191 on Kotti Classic PoA-testnet (approx Feb 12th, 2020)~~
- ~~10500839 on Ethereum Classic PoW-mainnet (approx Jun 10th, 2020)~~

For more information on the opcodes and their respective EIPs and implementations, please see the Specification
section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes shall be added to the Ethereum Classic
networks, all of which have been in use on the Ethereum Foundation networks since end of 2019.

### Specification

Technical specifications for each EIP can be found at those documents respectively:
- EIP-152: Add Blake2 compression function F precompile
- EIP-1108: Reduce altbn128 precompile gas costs
- EIP-1344: Add ChainID opcode
- EIP-2028: Calldata gas cost reduction
- EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

### Rationale

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for
developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Mordor,
Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing
contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of
them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM
increases its functionality and should be considered a feature upgrade rather than a modification. In particular, a delay
of Istanbul's EIP-1884 activation should be considered until backward-compatibility solutions are in place on Ethereum Classic.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Istanbul features currently:
- Parity Ethereum
- Multi-Geth
- Hyperledger Besu

### Final Note

Both, the Geth Classic client and the Morden testnet will no longer be supported by the community and not recieve the Aztlán_ ugrades.
- Users of the Geth Classic client are urged to migrate their services to Parity Ethereum, Multi-Geth, or Hyperledger Besu. It is no longer recommended to run Geth Classic in production.
- Users of the Morden Classic testnet are urged to migrate their applications to the Kotti Classic or Morder Classic testnets.

## Copyright

This work is licensed under Apache License, Version
2.0.

## Abstract

This ECIP introduces a minimally complicated implementation of EIP-1559 for Ethereum Classic.

EIP-1559 was introduced on Ethereum Mainnet in August 2021 during its London Hard Fork. Thanks in part to improved user experience and more efficient transaction pricing, EIP-1559 has achieved widespread adoption across many EVM chains. In turn, EVM-compatible wallets and smart contract systems are increasingly designed with the assumption that EIP-1559 is a baseline standard.

For users of Ethereum Classic to enjoy the benefits of 1559, and for the ETC protocol to maintain future-proof compatibility with the wider EVM ecosystem, the adoption of a 1559-compatible format is increasingly desirable. To this end, ECIP-1120 gives users the option to price transactions using an algorithmic Basefee Market, via the opt-in "Type 2" transaction.

In Ethereum's implementation of EIP-1559, the Basefee is burned, but this is not practical for Ethereum Classic. Instead, ECIP-1120 proposes that the Basefee is distributed in full to miners to maximize long-term security budget, which will become increasingly important during the tail-end of the emission curve in the coming decades.

This ECIP presents key recommendations, with assumed parameters summarized in the Key Parameters section.

## Motivation

The goal of this ECIP is to identify the least complex and most secure 1559-like implementation within real-world technical design constraints.

ECIP-1120 presents a math-only, protocol-neutral, protocol-native solution that distributes all fees to miners without any smart contracts or a governance system. It is fully self-contained with no dependencies on other ECIPs; once provisional parameters are finalized, this specification provides everything needed for implementation.

## Specification

ECIP-1120 consists of two key mechanisms - a Basefee Market and a Basefee Distribution - that together define a 1559-like protocol upgrade for Ethereum Classic.

### Basefee Market

The Basefee Market component is essentially a straightforward replication of relevant aspects of EIP-1559, with a Block Elasticity Multiplier optimized for ETC.

#### Type 2 Transactions

Type 2 transactions, using the envelope format defined in EIP-2718, allow users to specify a maximum fee and a priority fee (tip), with the protocol algorithmically determining the Basefee based on network demand. Block elasticity allows blocks to temporarily exceed the target gas limit during demand spikes, with the Basefee adjusting to bring utilization back to target. These mechanisms are detailed in the sections below.

As per EIP-1559, each Type 2 transaction satisfies the following validation rules:

#### BASEFEE Opcode

The 0x48 opcode returns the current block's Basefee, as specified in EIP-3198.

#### Basefee Calculation

The Basefee adjusts dynamically based on network demand. When blocks are fuller than the target, the Basefee increases. When blocks are emptier than the target, it decreases. This creates a self-correcting mechanism that targets 50% block utilization over time.

As per EIP-1559:

### Basefee Distribution

In Ethereum's implementation of EIP-1559, the Basefee is burned. Instead, ECIP-1120 proposes that Basefees are distributed to miners using a backward-looking mechanism, a form of "ℓ-smoothing" as described in Roughgarden's analysis (Section 8.3.1).

In ECIP-1120, total miner rewards consist of:
- Block Subsidy - based on the ECIP-1017 emission curve, and
- Priority Fees - optional tips, as a fallback pricing mechanism when blocks are full, and
- Distributed Fees - a portion of the Basefees collected from each of the previous BACKWARDFEESBLOCKCOUNT ancestor blocks, calculated as follows:

### Key Parameters

The following parameters govern the behavior of ECIP-1120. See Parameter Selection for rationale.

| Parameter | Value | Description |
|-----------|-------|-------------|
| Base gas target | 8,000,000 gas | Target gas usage per block (current ETC target) |
| Initial Basefee | 1 gwei | Basefee at fork activation block |
| Basefee max change denominator | 8 (±12.5%) | Controls max Basefee change per block |
| Elasticity multiplier | 4 | Ratio of max gas limit to gas target |
| Max gas limit | 32,000,000 | Maximum gas per block (base gas target × elasticity multiplier) |
| Backward fees block count | 64 | Number of ancestor blocks for fee distribution |
| Distribution curve | Uniform | Shape of fee distribution across lookback window |

*Assumed values cannot be finalized at this stage. Final values require client implementation and testing to determine optimal tradeoffs. See Research for details.

## Rationale

### Why Not Burn or Redirect?

Under ECIP-1017, ETC has a fixed emission schedule with block subsidies decreasing 20% every 5 million blocks. Burning fees interferes with this monetary policy, and as subsidies diminish during tail-end emissions, transaction fees become increasingly important for miner revenue and chain security.

Redirecting fees to a Treasury or DAO, in addition to reducing the security budget, introduces myriad governance complexities and smart contract dependencies.

Directing all transaction fees to miners, as is the case today:
- Keeps complexity and attack surface to a minimum
- Maintains protocol neutrality
- Sidesteps governance issues
- Leaves the social contract between miners and developers unchanged

Maximizing mining incentives prioritizes the security and long-term sustainability of the chain.

### Why Smoothing?

An immediate payment to the block's miner is vulnerable to manipulation via spam transactions and off-chain fee agreements. This ECIP instead distributes Basefees to miners using an algorithmic backward-looking smoothing mechanism.

Smoothing fees across blocks also helps avoid a "death spiral" when the block subsidy approaches zero. Without smoothing, empty blocks offer no reward, removing incentive to mine them. This causes irregular block times, discouraging transactions, further reducing miner revenue and resulting in a destructive feedback loop.

### Why Protocol-Native?

This ECIP keeps fee distribution logic at the protocol layer rather than delegating to smart contracts. Keeping this logic outside the EVM dramatically reduces complexity, making the mechanism simpler to implement, test, and audit across client implementations.

Crossing the protocol/application boundary introduces additional concerns:
- Attack surface - Smart contracts introduce reentrancy, overflow, and other vulnerability classes not present at the protocol layer.
- Governance capture - Governance systems are susceptible to capture, bribery, or manipulation by well-resourced actors.
- Code is Law - Embedding fee logic in contract state creates immutability expectations that may conflict with future necessary adjustments, potentially forcing contentious interventions that undermine ETC's principles.
- Future adaptability - Protocol-layer logic can be optimized or modified in future hard forks, whereas contract-based solutions are constrained by EVM limitations and may miss opportunities for deeper integration or performance improvements.
- Resource overhead - Smart contract execution consumes gas and adds computational load to every block, whereas protocol-native logic executes outside the EVM with no gas cost.

A protocol-native approach maintains a clean separation of concerns. The protocol handles consensus-critical fee mechanics, while the application layer remains focused on user-facing functionality.

### Why Stateless?

The backward-looking approach is deliberately stateless. The distributed fee amount is derived entirely from existing block header data, with no additional state variables required. This dramatically simplifies implementation, testing, and auditing.

A forward-looking accumulator would require stateful tracking that complicates re-org handling. When a reorg occurs, stateful data (such as an accumulator or reservoir balance) would require rolling back previous operations and tracking the history of changes to correctly restore state on the canonical chain. This adds implementation complexity, increases the attack surface, and imposes additional memory and disk costs during fork transitions.

Stateless calculation allows nodes to simply recompute the fee distribution from the new canonical chain's block headers, requiring no rollback logic, no state corruption risk, and no additional storage beyond what is already required for block headers.

### Block Elasticity Opportunity

In EIP-1559, the gas target is the equilibrium level where Basefee remains stable, while the gas limit is the maximum capacity per block. These are related by the formula gaslimit = gastarget × elasticitymultiplier. Blocks can vary between empty and fully utilized, with the Basefee algorithm incentivizing average utilization toward the target.

On Ethereum, EIP-1559 sets a block elasticity multiplier of 2x. With Ethereum's current block gas limit of 60m, this means a gas target of 30m. Since individual transactions can consume up to the full block gas limit, this enables large contract deployments or executions such as L2 state validation that consume significant gas.

This ECIP presents an opportunity to bring Ethereum Classic closer to feature parity with Ethereum. Ethereum Classic's current limit of 8 million is controlled by miners, but client defaults recommend this conservative value to minimize state bloat.

By increasing the block elasticity multiplier from 2x, a higher value such as 4x, 16x, or even 32x could be considered, enabling maximum transaction sizes equal to or greater than Ethereum, supporting large contract deployments and L2 settlement operations. Crucially, this can be achieved while still maintaining a much more conservative average block size and thus minimal state bloat over time, more in line with the Ethereum Classic ethos.

The goal is to identify a reasonable multiplier given real-world hardware capabilities and network conditions on the Ethereum Classic network, including how the Basefee adjustment rate interacts with higher elasticity values.

### Determining Distribution Parameters

The backward fees block count balances client performance (fewer calculations per block) against sufficient smoothing to achieve the desired incentive properties. This ECIP currently specifies a uniform distribution curve; alternative curves such as exponential decay may be explored in future work. Final values require implementation and testing across ETC clients to determine optimal tradeoffs.

## Backwards Compatibility

### Legacy Transactions

Type 0 (legacy) and Type 1 (EIP-2930 access list) transactions remain fully supported. These transactions are treated as having maxFeePerGas = maxPriorityFeePerGas = gasPrice, ensuring backwards compatibility with existing transaction workflows.

### Block Header Changes

This ECIP adds a BaseFeePerGas field to the block header, as specified in EIP-1559. This field is RLP-encoded as a 256-bit integer appended to the existing header structure. The block hash calculation includes this new field, making post-fork blocks incompatible with pre-fork clients.

### Wallet and Tooling Compatibility

Wallets and tooling that support EIP-1559 on other EVM chains work with minimal changes. Gas estimation APIs account for the Basefee, and transaction signing supports the Type 2 envelope format per EIP-2718.

### Client Requirements

A hard fork is required. ETC clients (Core-Geth, Besu) upgrade before the activation block. Non-upgraded nodes reject post-fork blocks and fork onto an incompatible chain.

## Security Considerations

### 51% Attack Resistance

Since all fees are returned to miners, total miner compensation remains essentially unchanged compared to the current fee market, with no reduction in security budget other than a reduction in mispriced transactions. This contrasts with fee-redirection mechanisms that permanently remove value from the security budget. As block subsidies decline under ECIP-1017, maintaining full fee distribution to miners becomes increasingly important for sustaining the cost of 51% attacks.

### Manipulation Resistance

The distribution mechanism is intended to satisfy key incentive compatibility properties as defined in Roughgarden's analysis: MMIC (myopic miner incentive compatibility, Section 5), UIC (user incentive compatibility, Section 4), and OCA-proofness (off-chain agreement proofness, Section 6). Formal verification of these properties under ECIP-1120's specific parameters is an area for future research; see Research.

### Resource Exhaustion Attacks

Increased block elasticity expands the potential for denial-of-service attacks where adversaries submit computationally expensive transactions to slow block processing or network propagation. Client benchmarking establishes safe parameter values for specific hardware configurations. Elasticity and gas limit values are chosen to ensure that even worst-case blocks (maximum gas, adversarial transaction patterns) can be processed within acceptable time bounds on recommended node hardware.

### MEV-related Attacks

Miner Extractable Value (MEV) refers to profit that miners can extract by reordering, inserting, or censoring transactions within blocks. High-value blocks create incentives for chain reorganizations to capture outsized rewards.

Fee smoothing via backward-looking distribution reduces block reward variance, decreasing the incentive to re-org for high-fee blocks. Since fees are distributed across multiple blocks, no single block presents an outsized MEV opportunity.

## Research

Certain parameter values cannot be reasonably finalized until the mechanism is implemented and tested across ETC clients. The companion research site at ecip1120.dev tracks this work, covering economic security modeling, elasticity multiplier benchmarking, distribution curve design, client performance testing, and reference test vectors. This ECIP remains the authoritative specification; any consensus-critical changes will be made here via PR.

## Implementation

ECIP-1120 is designed for deployment in a single hard fork. All components (Type 2 transactions, Basefee calculation, fee distribution, BASEFEE opcode) activate together at a designated block height, preventing partial implementations that could create unexpected behavior or security gaps.

## Conclusion

This ECIP proposes a minimal implementation of EIP-1559 for Ethereum Classic, adapting the Basefee market mechanism while distributing fees to miners rather than burning them. The backward-looking fee distribution preserves ETC's fixed monetary policy, maintains chain security as block subsidies decline, and resists manipulation through ℓ-smoothing. This proposal provides a path toward EIP-1559 compatibility while respecting Ethereum Classic's unique requirements.

## References
- EIP-1559: Fee market change for ETH 1.0 chain
- EIP-2718: Typed Transaction Envelope
- EIP-2930: Optional access lists
- EIP-3198: BASEFEE opcode
- ECIP-1017: Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule
- Roughgarden, T. Transaction Fee Mechanism Design for the Ethereum Blockchain

## License

Copyright and related rights waived via CC0.

### Abstract ###

The purpose of this ECIP is to calibrate the epoch length used in DAG calculations.

### Motivation ###

The original intent of the DAG was to provide ASIC resistance to the mining protocol in order to prevent centralization of mining distributions and thereby provide for an objectively fair distribution of tokens. As evident by ASICs being developed that are capable of matching current GPU miners while being more energy efficient, the DAG has succeeded in leveling the playing field between GPU incumbents and ASIC challengers, avoiding ASIC takeover and domination, and leading to a competitive and large mining ecosystem. However the original parameters are proving too aggressive, resulting in obsoleting support for GPUs still in wide use today by miners.

Calibrating these parameters to better reflect todays hardware markets and mining ecosystem will bring the DAG growth back in sync with commonly used GPUs. Allowing the DAG system to continue to serve it's purpose far into the future.

### Parameters ###

Ethash transitions to a modified Dagger Hashimoto algorithm, referred to hereby as Etchash, on block ETCHASHFORKBLOCK:
- For the Ethereum Classic main network: ETCHASHFORKBLOCK := 11700000 (Epoch 390)
- For the Mordor Classic test network: ETCHASHFORKBLOCK := 2520000 (Epoch 84)
- For the Kotti Classic test network, no upgrade is required.

### Specification ###

On ETCHASHFORKBLOCK, activate the following Etchash logic:

The oldEpochLength (30000) changes to newEpochLength (60000) at a given ETCHASHFORKBLOCK (hardfork required).

This will result in the epoch (blockNumber/[old/new]EpochLength) halving upon activation. As the DAG cache and dataset sizes are calculated from epoch, the growth in which they have experienced too will half upon activation. DAG caches and dataset will then continue to grow as intended, however at half of the pre-activation rate. To avoid re-use of seeds oldEpochLength will continue to be used within the seedHash function.

### Rationale ###
At current epoch (372) the DAG size is 3.91 GB. 4GB GPUs are getting obsoleted while they still make up a significant amount of ethash hashrate. Activating this change at epoch 376 (for example), would reduce the DAG size from 3.94GB to 2.47GB. With the reduced growth rate, 4GB GPUs will remain supported for an additional 3+ years.

### Implementation ###
Hard fork required for activation.
Mining software and pool implementations required.

For the smoothest possible transition activation should occur on a block in which an epoch transition to an even epoch number is occurring.
- Epoch 388/2 = 194 (good) = block 11640000
- Epoch 389/2 = 194.5 (bad) -
- Epoch 390/2 = 195 (good) = block 11700000

#### Clients ####
- [x] core-geth - #186 #209 #212
- [x] besu - #1421 #1462

#### Pools ####
- [x] open-ethereum-pool https://github.com/etclabscore/open-etc-pool
- [x] stand-alone etchash library https://github.com/etclabscore/go-etchash

#### Mining Software ####
- [ ] ethminer
- [x] proprietary miners, see https://github.com/eth-classic/etchash

### References ###
- ECIP-1099 Research/Test data
- ECIP 1043 - Fixed DAG limit restriction
- ECIP-? Limit DAG growth #6
- Ethash Sources
- DAG Size Calculator

## Copyright ##

This work is licensed under Apache License, Version 2.0.

### Abstract

A proposal to replace the current Ethereum Classic proof of work algorithm Etchash with Keccak-256.

### Copyright / Licensing

Copyright under Apache 2.0 license.

### Specification
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

Use Keccak256 with no DAG instead of ETChash as the proof-of-work mechanism on Ethereum Classic.

### Motivation
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.
- A response to the recent double-spend attacks against Ethereum Classic. Most of this hashpower was rented or came from other chains, specfically Ethereum (ETH). A seperate 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.

### Rationale
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

### 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 availalble on the market.

Keccak256 (aka SHA3) 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 SHA256 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 commited miner base, much the way Bitcoin did with its own SHA256 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 Specifcally 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.

### Backwards compatibility
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

### Reference implementation
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

Example of a Smart contract hashing being able to trustlessly Keccak 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:

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 Keccak256
2. The Function that checks the nonce-header in the block needs to know to accept Keccak256 hashes as valid for a block.

After doing further analysis it the best way forward to begin work is to implement this change in Multi-Geth instead of any other client. This is because Multi-geth is organized for multi-chain development, it seems to be more recently updated than classic-geth, and it is designed to be used with alternative consensus methods- which is necessary for implementing ECIP-1049.

The area where most of the changes will be in multi-geth/consensus

### 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. https://github.com/EthereumCommonwealth/Auditing/issues/102
6. https://etherscan.io/address/0xb6ed7644c69416d67b522e20bc294a9a9b405b31

### Related Discussions:
1. https://github.com/ethereumclassic/ECIPs/pull/8
2. https://github.com/ethereumclassic/ECIPs/issues/13
3. https://github.com/ethereumclassic/ECIPs/issues/342
4. https://github.com/ethereumclassic/ECIPs/issues/333
5. https://github.com/ethereumclassic/ECIPs/issues/362
6. https://github.com/ethereumclassic/ECIPs/issues/382
7. https://github.com/ethereum/EIPs/issues/2951
8. CDC 15 Call: https://vimeo.com/464336957
9. https://github.com/ethereumclassic/ECIPs/issues/394
10. https://ethereumclassic.org/blog/2022-02-23-core-devs-call-22-ecip-1049-call-results

# Change the ETC Proof of Work Algorithm to Sha-3-256 (vanilla Sha-3)

_Abstract. Make Sha-3-256 Standard the Proof of Work algorithm for Ethereum Classic. Ethereum’s development coincided with the development of the Sha-3 standard, but the Sha-3 standard was finalized shortly after Ethereum launched. So, Ethereum was left with a variant of Sha-3 that did not produce standard Sha-3 hashes. This variant of Sha-3 utilized in Ethereum was named Keccak-256 to avoid confusion. Keccak-256 is utilized in the EVM, but the Proof of Work algorithm is Ethash. Ethash is a combination of Keccak256 & Daggerhashimoto which contributes to the memory-intensive feature (Dag). The Dag was added due to the premise of ASIC resistance, but that premise is flase since Ethash ASICs exist. So, Ethash’s Dag is built on the false premise of ASIC resistance and not utilizing the official Sha-3 Standard algorithm.

Ethereum Classic's hash rate is also a minority of Ethereum's and the amount of rentable hash rate is available on the market to 51% attack the Ethereum Classic network. In summary, this proposal seeks to:
- Remove Daggerhashimoto (Dag)
- Bump Keccak-256 to Sha-3-256 Standard
- Become a majority PoW algorithm in the industry

Disclaimer. This is an alternative proposal to ECIP-1049 [1] since Keccak-256 and vanilla Sha-3 produce different hashing results. However, most of the arguments in this proposal are compatible with ECIP-1049 since Keccak-256 and vanilla Sha-3 differ in padding. ECIP-1049 and this proposal are both in support of switching the PoW to a Sha-3-based algorithm.

Motivation. The motivation of this proposal is to standardize the cryptographic hash function of the Ethereum Classic network with vanilla Sha-3 and become a majority chain in it's respective PoW.

Rationale.
- Cryptographic standardization: By bumping Keccak-256 to vanilla Sha-3, Ethereum Classic will have the official Sha-3 algorithm recognized by NIST. Sha-3 features:
- Enhanced security: Sha-3 is the latest member of the Secure Hash Algorithm family of standards and certified by the Federal Information Processing Standards (FIPS) [2].
- Reduced risk of non-compliance: Software agreements can have complex compliance criteria and compliance audits can be time consuming or simply a deal-breaker. Having a standardized cryptographic hash function would reduce the risk of non-compliance as vanilla Sha-3 is certified by trusted organizations and has been thoroughly vetted to obtain its place in the Sha family [3].
- Enhanced productivity: Sha-3 is a solidified cryptographic function with certification and documentation. This reduces research and maintenance costs for engineers especially since Sha-3 ASIC chip designs are available.
- Less PoW Competition: There are no major public blockchains whom use Sha-3 for PoW. Ethereum Classic's current market status to adopt Sha-3 would make it the majority chain for its respective PoW without having to compete in existing PoW ecosystems for miners.

Design.

As mentioned in ECIP-1049:
1. The Proof of work function needs to be replaced with Keccak256
2. The Function that checks the nonce-header in the block needs to know to accept Keccak256 hashes as valid for a block.

Diagram: https://camo.githubusercontent.com/97974a2041c7633669309cf41902e4ad6b78e4cc/68747470733a2f2f692e696d6775722e636f6d2f32686f62714f4c2e706e67

Instead:
1. Replace the PoW function in the EVM with vanilla Sha-3-256.
2. The function that checks the nonce-header in a block needs to accept vanilla Sha-3 as valid.

Development & Testing.

Since switching to Sha-3 is resetting the mining algorithm, we need "open-source" tools and resources to help facilitate the adoption of the new PoW.
- Client implementation: All major Ethereum Classic protocol providing clients such as Core-geth and Besu need a Sha-3 implementation.
- Mining-pool software: A mining pool tool will allow anyone to contribute a mining pool to the Etherem Classic network.
- Mining software: Existing AMD+NVIDIA GPU mining software for Ethash is available, but there is not solidified Sha-3 variant. We can collaborate with existing mining software providers or build new ones.
- Mining hardware: We need to know the performance difference between commodity GPUs and a Sha-3 ASIC. Sha-3 is ASIC friendly and cheaper to build ASICs for than Ethash. Some chip manufacturers may be interested in participating in the initiative since is may be economically rewarding.
- Sha-3 testnet launch: Launch of a Sha-3 Ethereum Classic testnet.
- Sha-3 network testing: Test all operations of the testnet from mining, transactions, and smart contracts.

Implementation.
- Recounciliation:
- Get commitment from miners and pools to contribute to the new PoW network.
- Have community recounciliation of testing results and make changes as needed.
- Set a Hard-fork date: Assuming the Sha-3 testnet is deemed suitable for mainnet adoption, plan a hard-fork with enough time to coodinate stakeholders.

References:
1. Alexander Tsankov. ECIP-1049 Change the ETC Proof of Work Algorithm to Keccak256. URL: https://ecips.ethereumclassic.org/ECIPs/ecip-1049
2. Federal Information Processing Standards (FIPS). PUB 202. 2015. URL: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
3. NIST. Approved Algorithms. URL: https://csrc.nist.gov/projects/hash-functions

License._

Apache 2.0

### Abstract

This document outlines a proposal for the implementation of a system to provide 51% attack resistance on the Ethereum Classic blockchain. It describes the high-level structure and general properties of such a system. IOHK has already researched and implemented the checkpointing protection on ETC, and has detailed specifications for each part of the system, as well as reference implementation, that can be found in this repository.

### Motivation

Distributed ledgers based on the Proof-of-Work (PoW) paradigm are typically most vulnerable when mining participation is low. During these periods an attacker can mount devastating attacks, such as double spending or censorship of transactions [^CHECK]. We have seen recently that this is particularly relevant to ETC, as witnessed by the two attacks that took place in August 2020.

Checkpointing is proposed as a mechanism to mitigate such 51% attacks. The core idea is to employ an external set of parties that securely run an assisting service which guarantees the ledger's properties and can be relied upon at times when the invested hashing power is low. Once hashing power reaches a level where an attack is no longer financially viable, the system can be discontinued.

The future viability of ETC in its current, unsecured state is now in question. Implementing a fully tested Checkpointing solution, running the Ouroboros-BFT (OBFT) consensus protocol, would provide high assurance, with low performance requirements. It would also boost confidence in the network and provide the much needed stability required to take ETC to a level where 51% attacks are no longer feasible.

### Specification

The checkpointing authority monitors the growth of the chain and periodically issues checkpoints, which are points at which validations occur. As soon as it observes the first valid chain, which extends the latest checkpoint by 𝑘 blocks (for some constant value 𝑘), the authority signs this chain’s last block and broadcasts this signature, thus producing a new checkpoint.

From the user perspective, chain selection is augmented by enforcing a rule where a chain is valid only if it extends the latest checkpoint. In particular, when selecting a chain, honest use applies as follows:
- first verifies that it contains the latest checkpoint; and
- then applies the longest-chain rule to all validly checkpointed candidates.

Even an adversary controlling a majority of the mining power cannot revert the block history secured by the latest checkpoint, as an honest user will (eventually) reject any chain that does not extend this checkpoint.

The checkpointing authority is distributed among a number 𝑛 of nodes. These nodes run an internal Byzantine fault tolerant (BFT) consensus protocol, Ouroboros BFT [^OBFT], to coordinate the issuing of checkpoints.

The checkpointing nodes use a multi-signature scheme to produce each checkpoint. A 𝑡-out-of-𝑛 multi-signature scheme allows a set of 𝑛 parties to collectively sign a message under the necessary condition that at least 𝑡 of the parties collaborate in order to sign this message. The checkpointing nodes issue their chosen checkpoints by creating respective multi-signature2s using their keys. Choosing `𝑡 > 𝑛 − 𝑡 implies that correct (agreed-upon) checkpoints will be continuously produced, while the forgery of checkpoints is impossible assuming that a minority of the checkpointing nodes is corrupted.

#### Checkpointing Service

The federation needs to agree upon the block to be checkpointed. The proposed solution consist of two components:
- a dedicated ETC node that will be used by the federation to monitor and retreive data.
- a checkpointing service server (the server) which allows federation nodes to reach an agreement.

The server is based on Ouroboros BFT [^OBFT]. Ourobotos BFT is a blockchain-based Byzantine Fault Tolerant protocol, i.e. it’s resilient to t windowmin;
- calculate npp(k) the subset of k latest NiPoPow graphs;
- calculate l(npp(k))the list of miners’ public keys that have contributed to mine the blocks contained by npp(k)removing duplicates (set);
- if length(l(npp(k))) < n go to 2.;
- else the list is determined
- when t - p expires go to 1.
- Pros
- Cons

##### Option 3: Auxiliary Security from an External Blockchain

This option relies on utilizing an external distributed ledger as a timestamping service. We believe that Bitcoin, being the most used and, arguably, most secure existing distributed ledger, can serve as an anchor of security for ETC, in the manner described below.

The timestamping protocol, which can be used to secure ETC, is parameterized with:
- kc: the checkpointing interval. Note that kc needs to be large enough, such that a timestamp has enough time to become stable on Bitcoin; in practice, it should correspond to, at the very least, 60 minutes.
- g: the ETC block number, which marks the beginning of the timestamped period.

Mining in ETC under timestamping works as follows. When a miner tries to produce a new block, with block number j:
- If j = g + ikc for some integer i, i.e. every kc blocks, they construct a special checkpointed block as follows:
- If j ≠ g + ikc for any integer i, then the miner creates a standard ETC block as usual.

When choosing between two ETC chains, C1 and C2, intuitively, an ETC node prioritizes timestamps over PoW. Specifically, between two competing blocks, it always chooses the one with the oldest timestamp, i.e. the one that was created first. If neither block and they both stem from the same timestamped block, then PoW is enforced. Specifically, a node does as follows:
- It finds the common ancestor block BC of the two chains
- In each chain, it finds the first block Bt1, Bt2 after BC which has been timestamped on Bitcoin
- If timestamp(Bt1) < timestamp(Bt2), i.e. if Bt1 was timestamped before Bt2, then the miner picks C1; otherwise they pick C2
- If BC is the latest timestamped block on both chains, then the standard maxvalid rule applies

Note 1: In practice, an ETC miner can choose on which chain to mine before a timestamp becomes stable in the Bitcoin ledger. Specifically, they may assume that the Bitcoin miners follow a first-come-first-in-the-block rule, such that the first timestamping transaction that the ETC miner observes on the Bitcoin network will eventually be the correct one.

Note 2: The above proposal applies on any alternative distributed ledger that enables publishing arbitrary data, such as Litecoin or Bitcoin Cash (on the PoW side) or Cardano (on the PoS side).

High Level Requirements
- ETC miners need to run a full Bitcoin node to retrieve and verify timestamps
- ETC miners need to own some Bitcoins to create timestamping transactions; on September 2019, this cost was $3.6 per block, see [^CHECK]
- A soft fork will be required to add the special header field (see mining step (b)), which is needed to ensure liveness
- Pros
- Cons

### Implementation

The following section refers to the Option 1 with fixed commite members

#### Data Structures

A checkpoint is another block in the chain. To distinguish it from regular blocks we need an extra field in the header called checkpoint. To simplify implementation all other header fields remain the same. What follow is recipe to build checkpoint block:

where the signature follows the same ECDSA scheme as transaction signatures and consists of:

Notes:
- there is no block reward for a checkpoint block
- timestamp should be predetermined so that all federation nodes construct exactly the same header

Validation of checkpoint upon import should check that all header values match the recipe specified above. It should also validate that the checkpoint block does not contain any signatures.

#### Consensus changes

In order to facilitate checkpointing the following consensus changes need to be made:
1. Each node in the network should be configured with a list of ECDSA public keys of the Checkpointing Federation
2. Upon importing a checkpoint block a node should verify the signatures conveyed in the checkpoint field against the parentHash of the block. The recovered keys must match the keys in 1. and each signature must come from a unique signer (note that checking signature non-equality is not enough)
3. Once a checkpoint has been imported it becomes stable in the chain. It can never be rolled back.

#### JSON-RPC Additions

An ETC node that is part of the Checkpointing Federation must implement these RPC methods to communicate with an OBFT node:
- checkpointinggetLatestBlock

Returns the hash and number for the latest block that matches the given checkpointing interval

Parameters:
- QUANTITY - integer checkpointing interval

Example:
- checkpointingpushCheckpoint

Used to push checkpoint information from the OBFT node to the associated ETC node

Parameters:
- DATA - hash of the checkpointed block, 32 bytes
- Array of DATA - a list ECDSA signatures encoded in 65-byte uncompressed format

Example:

Note that these methods are not required for a regular ETC network node.

[^OBFT]: Aggelos Kiayias, Alexander Russell, Ouroboros-BFT: A Simple Byzantine Fault Tolerant Consensus Protocol https://eprint.iacr.org/2018/1049.pdf

[^CHECK]: Dimitris Karakostas, Aggelos Kiayias: Securing Proof-of-Work Ledgers via Checkpointing. IACR Cryptol. ePrint Arch. 2020: 173 (2020). https://eprint.iacr.org/2020/173

[^NIPOPOW]: Aggelos Kiayias, Andrew Miller, and Dionysis Zindros: Non-Interactive Proofs of Proof-of-Work https://eprint.iacr.org/2017/963.pdf

## Abstract

Clique is a proof-of-authority consensus protocol. It shadows the design of Ethereum mainnet, so it can be added to any client with minimal effort.

## Motivation

Ethereum's first official testnet was Morden. It ran from July 2015 to about November 2016, when due to the accumulated junk and some testnet consensus issues between Geth and Parity, it was finally laid to rest in favor of a testnet reboot.

Ropsten was thus born, clearing out all the junk and starting with a clean slate. This ran well until the end of February 2017, when malicious actors decided to abuse the low PoW and gradually inflate the block gas limits to 9 billion (from the normal 4.7 million), at which point sending in gigantic transactions crippling the entire network. Even before that, attackers attempted multiple extremely long reorgs, causing network splits between different clients, and even different versions.

The root cause of these attacks is that a PoW network is only as secure as the computing capacity placed behind it. Restarting a new testnet from zero wouldn't solve anything, since the attacker can mount the same attack over and over again. The Parity team decided to go with an emergency solution of rolling back a significant number of blocks, and enacting a soft-fork rule that disallows gas limits above a certain threshold.

While this solution may work in the short term:
- It's not elegant: Ethereum supposed to have dynamic block limits
- It's not portable: other clients need to implement new fork logic themselves
- It's not compatible with sync modes: fast and light clients are both out of luck
- It's just prolonging the attacks: junk can still be steadily pushed in ad infinitum

Parity's solution although not perfect, is nonetheless workable. I'd like to propose a longer term alternative solution, which is more involved, yet should be simple enough to allow rolling out in a reasonable amount of time.

### Standardized proof-of-authority

As reasoned above, proof-of-work cannot work securely in a network with no value. Ethereum has its long term goal of proof-of-stake based on Casper, but that is heavy research so we cannot rely on that any time soon to fix today's problems. One solution however is easy enough to implement, yet effective enough to fix the testnet properly, namely a proof-of-authority scheme.

The main design goals of the PoA protocol described here is that it should be very simple to implement and embed into any existing Ethereum client, while at the same time allow using existing sync technologies (fast, light, warp) without needing client developers to add custom logic to critical software.

## Design constraints

There are two approaches to syncing a blockchain in general:
- The classical approach is to take the genesis block and crunch through all the transactions one by one. This is tried and proven, but in Ethereum complexity networks quickly turns out to be very costly computationally.
- The other is to only download the chain of block headers and verify their validity, after which point an arbitrary recent state may be downloaded from the network and checked against recent headers.

A PoA scheme is based on the idea that blocks may only be minted by trusted signers. As such, every block (or header) that a client sees can be matched against the list of trusted signers. The challenge here is how to maintain a list of authorized signers that can change in time? The obvious answer (store it in an Ethereum contract) is also the wrong answer: fast, light and warp sync don't have access to the state during syncing.

The protocol of maintaining the list of authorized signers must be fully contained in the block headers.

The next obvious idea would be to change the structure of the block headers so it drops the notions of PoW, and introduces new fields to cater for voting mechanisms. This is also the wrong answer: changing such a core data structure in multiple implementations would be a nightmare development, maintenance and security wise.

The protocol of maintaining the list of authorized signers must fit fully into the current data models.

So, according to the above, we can't use the EVM for voting, rather have to resort to headers. And we can't change header fields, rather have to resort to the currently available ones. Not much wiggle room.

### Repurposing header fields for signing and voting

The most obvious field that currently is used solely as fun metadata is the 32 byte extra-data section in block headers. Miners usually place their client and version in there, but some fill it with alternative "messages". The protocol would extend this field ~~to~~ with 65 bytes with the purpose of a secp256k1 miner signature. This would allow anyone obtaining a block to verify it against a list of authorized signers. It also makes the miner section in block headers obsolete (since the address can be derived from the signature).

Note, changing the length of a header field is a non invasive operation as all code (such as RLP encoding, hashing) is agnostic to that, so clients wouldn't need custom logic.

The above is enough to validate a chain, but how can we update a dynamic list of signers. The answer is that we can repurpose the newly obsoleted miner field and the PoA obsoleted nonce field to create a voting protocol:
- During regular blocks, both of these fields would be set to zero.
- If a signer wishes to enact a change to the list of authorized signers, it will:
- Set the miner to the signer it wishes to vote about
- Set the nonce to 0 or 0xff...f to vote in favor of adding or kicking out

Any clients syncing the chain can "tally" up the votes during block processing, and maintain a dynamically changing list of authorized signers by popular vote.

To avoid having an infinite window to tally up votes in, and also to allow periodically flushing stale proposals, we can reuse the concept of an epoch from ethash, where every epoch transition flushes all pending votes. Furthermore, these epoch transitions can also act as stateless checkpoints containing the list of current authorized signers within the header extra-data. This permits clients to sync up based only on a checkpoint hash without having to replay all the voting that was done on the chain up to that point. It also allows the genesis header to fully define the chain, containing the list of initial signers.

### Attack vector: Malicious signer

It may happen that a malicious user gets added to the list of signers, or that a signer key/machine is compromised. In such a scenario the protocol needs to be able to defend itself against reorganizations and spamming. The proposed solution is that given a list of N authorized signers, any signer may only mint 1 block out of every K. This ensures that damage is limited, and the remainder of the miners can vote out the malicious user.

### Attack vector: Censoring signer

Another interesting attack vector is if a signer (or group of signers) attempts to censor out blocks that vote on removing them from the authorization list. To work around this, we restrict the allowed minting frequency of signers to 1 out of N/2. This ensures that malicious signers need to control at least 51% of signing accounts, at which case it's game over anyway.

### Attack vector: Spamming signer

A final small attack vector is that of malicious signers injecting new vote proposals inside every block they mint. Since nodes need to tally up all votes to create the actual list of authorized signers, they need to track all votes through time. Without placing a limit on the vote window, this could grow slowly, yet unbounded. The solution is to place a ~~moving~~ window of W blocks after which votes are considered stale. ~~A sane window might be 1-2 epochs.~~ We'll call this an epoch.

### Attack vector: Concurrent blocks

If the number of authorized signers are N, and we allow each signer to mint 1 block out of K, then at any point in time N-K+1 miners are allowed to mint. To avoid these racing for blocks, every signer would add a small random "offset" to the time it releases a new block. This ensures that small forks are rare, but occasionally still happen (as on the main net). If a signer is caught abusing it's authority and causing chaos, it can be voted out.

## Specification

We define the following constants:
- EPOCHLENGTH: Number of blocks after which to checkpoint and reset the pending votes.
- Suggested 30000 for the testnet to remain analogous to the mainnet ethash epoch.
- BLOCKPERIOD: Minimum difference between two consecutive block's timestamps.
- Suggested 15s for the testnet to remain analogous to the mainnet ethash target.
- EXTRAVANITY: Fixed number of extra-data prefix bytes reserved for signer vanity.
- Suggested 32 bytes to retain the current extra-data allowance and/or use.
- EXTRASEAL: Fixed number of extra-data suffix bytes reserved for signer seal.
- 65 bytes fixed as signatures are based on the standard secp256k1 curve.
- NONCEAUTH: Magic nonce number 0xffffffffffffffff to vote on adding a new signer.
- NONCEDROP: Magic nonce number 0x0000000000000000 to vote on removing a signer.
- UNCLEHASH: Always Keccak256(RLP([])) as uncles are meaningless outside of PoW.
- DIFFNOTURN: Block score (difficulty) for blocks containing out-of-turn signatures.
- Suggested 1 since it just needs to be an arbitrary baseline constant.
- DIFFINTURN: Block score (difficulty) for blocks containing in-turn signatures.
- Suggested 2 to show a slight preference over out-of-turn signatures.

We also define the following per-block constants:
- BLOCKNUMBER: Block height in the chain, where the height of the genesis is block 0.
- SIGNERCOUNT: Number of authorized signers valid at a particular instance in the chain.
- SIGNERINDEX: Index of the block signer in the sorted list of current authorized signers.
- SIGNERLIMIT: Number of consecutive blocks out of which a signer may only sign one.
- Must be floor(SIGNERCOUNT / 2) + 1 to enforce majority consensus on a chain.

We repurpose the ethash header fields as follows:
- beneficiary: Address to propose modifying the list of authorized signers with.
- Should be filled with zeroes normally, modified only while voting.
- Arbitrary values are permitted nonetheless (even meaningless ones such as voting out non signers) to avoid extra complexity in implementations around voting mechanics.
- Must be filled with zeroes on checkpoint (i.e. epoch transition) blocks.
- nonce: Signer proposal regarding the account defined by the beneficiary field.
- Should be NONCEDROP to propose deauthorizing beneficiary as a existing signer.
- Should be NONCEAUTH to propose authorizing beneficiary as a new signer.
- Must be filled with zeroes on checkpoint (i.e. epoch transition) blocks.
- Must not take up any other value apart from the two above (for now).
- extraData: Combined field for signer vanity, checkpointing and signer signatures.
- First EXTRAVANITY bytes (fixed) may contain arbitrary signer vanity data.
- Last EXTRASEAL bytes (fixed) is the signer's signature sealing the header.
- Checkpoint blocks must contain a list of signers (N20 bytes) in between, omitted otherwise.
- The list of signers in checkpoint block extra-data sections must be sorted in ascending order.
- mixHash: Reserved for fork protection logic, similar to the extra-data during the DAO.
- Must be filled with zeroes during normal operation.
- ommersHash: Must be UNCLEHASH as uncles are meaningless outside of PoW.
- timestamp: Must be at least the parent timestamp + BLOCKPERIOD.
- difficulty: Contains the standalone score of the block to derive the quality of a chain.
- Must be DIFFNOTURN if BLOCKNUMBER % SIGNERCOUNT != SIGNERINDEX
- Must be DIFFINTURN if BLOCKNUMBER % SIGNERCOUNT == SIGNERINDEX

### Authorizing a block

To authorize a block for the network, the signer needs to sign the block's hash containing everything except the signature itself. The means that the hash contains every field of the header (nonce and mixDigest included), and also the extraData with the exception of the 65 byte signature suffix. The fields are hashed in the order of their definition in the yellow paper.

This hash is signed using the standard secp256k1 curve, and the resulting 65 byte signature (R, S, V, where V is 0 or 1) is embedded into the extraData as the trailing 65 byte suffix.

To ensure malicious signers (loss of signing key) cannot wreck havoc in the network, each singer is allowed to sign maximum one out of SIGNERLIMIT consecutive blocks. The order is not fixed, but in-turn signing weighs more (DIFFINTURN) than out of turn one (DIFFNOTURN).

#### Authorization strategies

As long as signers conform to the above specs, they can authorize and distribute blocks as they see fit. The following suggested strategy will however reduce network traffic and small forks, so it's a suggested feature:
- If a signer is allowed to sign a block (is on the authorized list and didn't sign recently).
- Calculate the optimal signing time of the next block (parent + BLOCKPERIOD).
- If the signer is in-turn, wait for the exact time to arrive, sign and broadcast immediately.
- If the signer is out-of-turn, delay signing by rand(SIGNERCOUNT 500ms).

This small strategy will ensure that the in-turn signer (who's block weighs more) has a slight advantage to sign and propagate versus the out-of-turn signers. Also the scheme allows a bit of scale with the increase of the number of signers.

### Voting on signers

Every epoch transition (genesis block included) acts as a stateless checkpoint, from which capable clients should be able to sync without requiring any previous state. This means epoch headers must not contain votes, all non settled votes are discarded, and tallying starts from scratch.

For all non-epoch transition blocks:
- Signers may cast one vote per own block to propose a change to the authorization list.
- Only the latest proposal per target beneficiary is kept from a single signer.
- Votes are tallied live as the chain progresses (concurrent proposals allowed).
- Proposals reaching majority consensus SIGNERLIMIT come into effect immediately.
- Invalid proposals are not to be penalized for client implementation simplicity.

A proposal coming into effect entails discarding all pending votes for that proposal (both for and against) and starting with a clean slate.

#### Cascading votes

A complex corner case may arise during signer deauthorization. When a previously authorized signer is dropped, the number of signers required to approve a proposal might decrease by one. This might cause one or more pending proposals to reach majority consensus, the execution of which might further cascade into new proposals passing.

Handling this scenario is non obvious when multiple conflicting proposals pass simultaneously (e.g. add a new signer vs. drop an existing one), where the evaluation order might drastically change the outcome of the final authorization list. Since signers may invert their own votes in every block they mint, it's not so obvious which proposal would be "first".

To avoid the pitfalls cascading executions would entail, the Clique proposal explicitly forbids cascading effects. In other words: Only the beneficiary of the current header/vote may be added to/dropped from the authorization list. If that causes other proposals to reach consensus, those will be executed when their respective beneficiaries are "touched" again (given that majority consensus still holds at that point).

#### Voting strategies

Since the blockchain can have small reorgs, a naive voting mechanism of "cast-and-forget" may not be optimal, since a block containing a singleton vote may not end up on the final chain.

A simplistic but working strategy is to allow users to configure "proposals" on the signers (e.g. "add 0x...", "drop 0x..."). The signing code can then pick a random proposal for every block it signs and inject it. This ensures that multiple concurrent proposals as well as reorgs get eventually noted on the chain.

This list may be expired after a certain number of blocks / epochs, but it's important to realize that "seeing" a proposal pass doesn't mean it won't get reorged, so it should not be immediately dropped when the proposal passes.

## Test Cases

## Implementation

A reference implementation is part of go-ethereum and has been functioning as the consensus engine behind the Rinkeby testnet since April, 2017.

## Copyright
Copyright and related rights waived via CC0.

## Simple Summary

This document proposes a new proof-of-authority consensus engine that could be used by Ethereum testing and development networks in the future.

## Abstract

Cliquey is the second iteration of the Clique proof-of-authority consensus protocol, previously discussed as "Clique v2". It comes with some usability and stability optimizations gained from creating the Görli and Kotti Classic cross-client proof-of-authority networks that were implemented in Geth, Parity Ethereum, Pantheon, Nethermind, and various other clients.

## Motivation

The Kotti Classic and Görli testnets running different implementations of the Clique engine got stuck multiple times due to minor issues discovered. These issues were partially addressed on the mono-client Rinkeby network by optimizing the Geth code.

However, optimizations across multiple clients should be adequately specified and discussed. This working document is a result of a couple of months testing and running cross-client Clique networks, especially with the feedback gathered by several Pantheon, Nethermind, Parity Ethereum, and Geth engineers on different channels.

The overall goal is to simplify the setup and configuration of proof-of-authority networks, ensure testnets avoid getting stuck and mimicking mainnet conditions.

For a general motivation on proof-of-authority testnets, please refer to the exhaustive introduction in EIP-225 which this proposal is based on.

## Specification

This section specifies the Cliquey proof-of-authority engine. To quickly understand the differences from Clique, please refer to the Rationale further below.

### Constants

We define the following constants:
- EPOCHLENGTH: The number of blocks after which to checkpoint and reset the pending votes. It is suggested to remain analogous to the mainnet ethash proof-of-work epoch (30000).
- BLOCKPERIOD: The minimum difference between two consecutive block's timestamps. It is suggested to remain analogous to the mainnet ethash proof-of-work block time target (15 seconds).
- EXTRAVANITY: The fixed number of extra-data prefix bytes reserved for signer vanity. It is suggested to retain the current extra-data allowance and use (32 bytes).
- EXTRASEAL: The fixed number of extra-data suffix bytes reserved for signer seal: 65 bytes fixed as signatures are based on the standard secp256k1 curve.
- NONCEAUTH: Magic nonce number 0xffffffffffffffff to vote on adding a new signer.
- NONCEDROP: Magic nonce number 0x0000000000000000 to vote on removing a signer.
- UNCLEHASH: Always Keccak256(RLP([])) as uncles are meaningless outside of proof-of-work.
- DIFFNOTURN: Block score (difficulty) for blocks containing out-of-turn signatures. It should be set to 1 since it just needs to be an arbitrary baseline constant.
- DIFFINTURN: Block score (difficulty) for blocks containing in-turn signatures. It should be 7 to show preference over out-of-turn signatures.
- MINWAIT: The minimum time to wait for an out-of-turn block to be published. It is suggested to set it to BLOCKPERIOD / 2.

We also define the following per-block constants:
- BLOCKNUMBER: The block height in the chain, where the height of the genesis is block 0.
- SIGNERCOUNT: The number of authorized signers valid at a particular instance in the chain.
- SIGNERINDEX: The index of the block signer in the sorted list of currently authorized signers.
- SIGNERLIMIT: The number of signers required to govern the list of authorities. It must be floor(SIGNERCOUNT / 2) + 1 to enforce majority consensus on a proof-of-authority chain.

We repurpose the ethash header fields as follows:
- beneficiary: The address to propose modifying the list of authorized signers with.
- Should be filled with zeroes normally, modified only while voting.
- Arbitrary values are permitted nonetheless (even meaningless ones such as voting out non-signers) to avoid extra complexity in implementations around voting mechanics.
- It must be filled with zeroes on checkpoint (i.e., epoch transition) blocks.
- Transaction execution must use the actual block signer (see extraData) for the COINBASE opcode.
- nonce: The signer proposal regarding the account defined by the beneficiary field.
- It should be NONCEDROP to propose deauthorizing beneficiary as an existing signer.
- It should be NONCEAUTH to propose authorizing beneficiary as a new signer.
- It must be filled with zeroes on checkpoint (i.e., on epoch transition) blocks.
- It must not take up any other value apart from the two above.
- extraData: Combined field for signer vanity, checkpointing and signer signatures.
- The first EXTRAVANITY fixed bytes may contain arbitrary signer vanity data.
- The last EXTRASEAL fixed bytes are the signer's signature sealing the header.
- Checkpoint blocks must contain a list of signers (SIGNERCOUNT20 bytes) in between, omitted otherwise.
- The list of signers in checkpoint block extra-data sections must be sorted in ascending order.
- mixHash: Reserved for fork protection logic, similar to the extra-data during the DAO.
- It must be filled with zeroes during regular operation.
- ommersHash: It must be UNCLEHASH as uncles are meaningless outside of proof-of-work.
- timestamp: It must be greater than the parent timestamp + BLOCKPERIOD.
- difficulty: It contains the standalone score of the block to derive the quality of a chain.
- It must be DIFFNOTURN if BLOCKNUMBER % SIGNERCOUNT != SIGNERINDEX
- It must be DIFFINTURN if BLOCKNUMBER % SIGNERCOUNT == SIGNERINDEX

### Validator List

The initial validator list can be specified in the configuration at genesis, i.e., by appending it to the Clique config in Geth:

By using this list, for convenience, the extraData field of the genesis block only has to contain the 32 bytes of EXTRAVANITY. The client automatically converts and appends the list of signers to the block 0 extra-data as specified in EIP-225 at checkpoint blocks (appending SIGNERCOUNT20 bytes).

### Sealing

For a detailed specification of the block authorization logic, please refer to EIP-225 by honoring the constants defined above. However, the following changes should be highlighted:
- Each singer is allowed to sign any number of consecutive blocks. The order is not fixed, but in-turn signing weighs more (DIFFINTURN) than out-of-turn one (DIFFNOTURN). In case an out-of-turn block is received, an in-turn signer should continue to publish their block to ensure the chain always prefers in-turn blocks in any case. This strategy prevents in-turn validators from being hindered from publishing their block and potential network halting.
- If a signer is allowed to sign a block, i.e., is on the authorized list:
- Calculate the Gaussian random signing time of the next block: parenttimestamp + BLOCKPERIOD + r, where r is a uniform random value in rand(-BLOCKPERIOD/4, BLOCKPERIOD/4).
- If the signer is in-turn, wait for the exact time to arrive, sign and broadcast immediately.
- If the signer is out-of-turn, delay signing by MINWAIT + rand(0, SIGNERCOUNT * 500ms).

This strategy will always ensure that an in-turn signer has a substantial advantage to sign and propagate versus the out-of-turn signers.

### Voting

The voting logic is unchanged and can be adapted straight from EIP-225.

## Rationale

The following changes were introduced over Clique EIP-225 and should be discussed briefly.
- Cliquey introduces a MINWAIT period for out-of-turn block to be published which is not present for Clique. This addresses the issue of out-of-turn blocks often getting pushed into the network too fast causing a lot of short reorganizations and in some rare cases causing the network to come to a halt. By holding back out-of-turn blocks, Cliquey allows in-turn validators to seal blocks even under non-optimal network conditions, such as high network latency or validators with unsynchronized clocks.
- To further strengthen the role of in-turn blocks, an authority should continue to publish in-turn blocks even if an out-of-turn block was already received on the network. This prevents in-turn validators being hindered from publishing their block and potential network problems, such as reorganizations or the network getting stuck.
- Additionally, the DIFFINTURN was increased from 2 to 7 to avoid situations where two different chain heads have the same total difficulty. This prevents the network from getting stuck by making in-turn blocks significantly more heavy than out-of-turn blocks.
- The SIGNERLIMIT was removed from block sealing logic and is only required for voting. This allows the network to continue sealing blocks even if all but one of the validators are offline. The voting governance is not affected and still requires signer majority.
- The block period should be less strict and slightly randomized to mimic mainnet conditions. Therefore, it is slightly randomized in the uniform range of [-BLOCKPERIOD/4, BLOCKPERIOD/4]. With this, the average block time will still hover around BLOCKPERIOD.

Finally, without changing any consensus logic, we propose the ability to specify an initial list of validators at genesis configuration without tampering with the extraData.

## Test Cases

## Implementation

A proof-of-concept implementation is being worked on at #ETHCapeTown.

## Copyright
Copyright and related rights waived via CC0.

### 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 % 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).

| Block interval | Block Reward | Mining, % | Cold Staking, % | Monthly return (assuming that 1/2 of total ETC supply is locked in staking) |
| ---: | ---: | ---: | ---: | ---: |
| 1 - 10,000,000 | 5 ETC | 100% | 0% | - |
| 10,000,000 - 15,000,000 | 4 ETC | 60% | 40% | 0.36% |
| 15,000,000 - 20,000,000 | 3.2 ETC | 55% | 45% | 0.28% |
| 20,000,000 - 25,000,000 | 2.56 ETC | 50% | 50% | 0.23% |
| 25,000,000 - ... | 2.05 ETC | 50% | 50% | 0.17% |

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.

## Abstract

A process for communicating high priority updates and events to 3rd parties

## Motivation

One of the biggest issues for coordinated decentralized network upgrades (ie hard fork) is disseminating this information to 3rd parties. As it stands, multiple entities can be contacting 3rd party organizations as “official” representatives, recommending different clients and actions, or even publishing conflicting information that can lead to centralization, network splitting, and other systemic issues caused by this lack of coordination.

There can also be new processes that come out as a result of this, ie a “safe list” of 3rd party organizations. It is not the purpose of this ECIP to outline these.

## Specification

This process is comprised of 3 parts

1) Representative Selection
2) Message Construction
3) Channels

### Representative Selection

Each Client (geth/multigeth/parity/mantis) should have 1 representative selected to help in the outreach process. In addition, there should be 2 representatives voted by the Client representatives that are unaffiliated with any of the Clients.

This selection happens during Final Call of Hard Fork Meta ECIP or when a "Black Swan" event occurs.

Examples of "Black Swan" events are:
- 51% attack
- SHA256 breaking

For example, at the Final Call of Atlantis, the following representatives are selected:
1. Geth – Christian
2. Multigeth – Yaz
3. Parity – Wei
4. Mantis – Kevin
5. Community 1 – Donald
6. Community 2 – Roy

### Message Construction

The author for the message will be assigned to one of the unaffiliated representatives. There will also be a send date agreed upon. The recommended send date for a Hard Fork is 6 weeks, and immediately for a "Black Swan" event. The draft will be submitted to the representatives no later than 1 week before the send date.

Example Message: Initial Communications Setup

Hi [Contact Name]

I wanted to reach out and setup a technical contact at [Org] for Ethereum Classic. We are gearing up for our Atlantis Hardfork and want to ensure a smooth upgrade with all of our [OrgType] partners. 

I'll be sending you the official announcement details within the next couple of weeks, but I wanted to make sure this is your best contact detail and see if there is anyone else on your team that needs to be involved.

Looking forward to our continued work together and a successful hard fork!

### Channels

A channel is defined as a contact name and contact medium, with a very high likelihood of response within 48 hours.

2 spreadsheets are required: Contact List and Update Status

Contact List: the official communications channels for all 3rd parties. This must remain semi-private to protect 3rd parties from spam. The entries are updated by the last contact to have a successful response from the Organization.

The suggested spreadsheet format

Org | OrgType | Contact Name | Contact Medium | Last Contact | Last Contact By

OrgTypes:
- Exchange
- Miner
- Node
- Wallet
- Publication

Example entry
- F2Pool | Miner | Thomas | Wechat - @thomasf2pool | 7/30/2019 | Community 1 – Donald
- Coinbase | Exchange | Bill | Email – bill@coinbase.com | 7/25/2019 | Mantis – Kevin
- Coineal | Exchange | None | None | 7/20/2019 | ETCCoop - Yaz

Update Status: a temporary spreadsheet used to coordinate communications for a specific update/event

The suggested spreadsheet format

Org | Rep 1 | Rep 2 | Status

Status Types
- Complete: acknowledged receipt of the communication
- InProgress1: 1st 2 weeks of attempts, handled by Rep 1
- InProgress2: 2nd 2 weeks of attempts, handled by Rep 2
- Failed: no response after 4 weeks of attempts

Example entry
- F2Pool | Community 1 – Donald | Geth – Christian | Complete
- Coinbase | Mantis – Kevin | Community 2 – Roy | InProgress1

#### Channel Use

After message construction, a “Update Status” spreadsheet is created. Each Representative fills in their name under Rep1 for every “Org” they are the “Last Contact By”. Rep 2 is assigned by Rep1 or done on a volunteer basis, whichever occurs first.

Outreach begins using the last established channel and Status becomes InProgress1. During this phase, outreach can extend to different mediums if there is no response within the 1st week. At the end of the 2nd week, if there is no successful response, status moves to InProgress2 and Rep2 begins outreach process, following the same protocol. After 4 weeks of attempts with no response, the status is set to Failed and the “Contact List” entry is updated to “No Contact” and “Last Contact” is set to last attempt date and “Contact By” is set to Rep2.

Every outreach will include another representative

Example
- Email: cc’ing another Rep
- WeChat: group chat
- Ticket: cc’ing and including another Rep’s contact details in the submission

Successful responses are marked as “Success” in the “Update Status” sheet and the “Contact List” is updated.

#### Channel Maintenance

To prevent out of date information in the contact list, the contacts will be refreshed with a generic outreach every month. This outreach will be handled by the last Contact By on the contact list. Adding new contacts would organically occur and there is no need to remove old ones.

### Implementation

The first iteration of this process is the most difficult, as the Contact List is being formed from scratch.

Representatives are selected once this ECIP is accepted

Once a message has been constructed, the steps would emulate the normal process. Any existing contact list can act as a starting point, with the Representatives filling in information to the best of their abilities.

## Abstract

Turn off the artificial finality mechanism ECBP-1100's MESS (Modified Exponential Scoring) in Core-Geth for Ethereum Classic.

## Motivation

MESS was designed from the start as a temporary, peripheral patch on the incumbent GHOST-based chain arbitration algorithm.

It was intended to mitigate the risk imparted to the chain by an adjacent chain -- the Ethereum mainnet -- which, while using its original PoW algorithm, dwarfed ETC's hashrate and thus established the vulnerable position MESS hoped to safeguard. ETH moved from PoW to PoS in September 2022. Its exit from the PoW economy has left ETC as the largest apparent sink of compatible hashrate (limited by DAG and the hash type demand). With this clear reduction in apparent risk to the network, the need for MESS is diminished.

The costs of persisting any kind of subjective chain arbitration on the network are not zero. Network risk to sophisticated bifurcation attacks; an expected low-probability exposure to catastrophic failure. Code overhead during upstream codebase merges; developer chore cost.

## Specification

MESS will be deactivated by default at block 19,250,000. This is concurrent with ECIP-1109's Spiral Hardfork.

An override flag for this decision will be provided to configure ongoing operation --override.ecbp1100-deactivate= .

Users will be encouraged to upgrade to Core-Geth v1.12.17, or to deactivate MESS manually, which can be done with all versions of core-geth implementing MESS using the flag value: --ecbp1100=99999999999 or equivalent.

### Mordor (ETC PoW Testnet)

MESS will be deactivated at block 10,400,000.

## Rationale

While limited data circumscribes our understanding of hashrate supply, an apparent migration of an original roughly 1000 TH/s economy to currently about 20% of that, it seems reasonable to conclude that the costs of MESS now outweigh the risks it was designed to mitigate, since ETC's current hashrate accounts for around 85% of the apparent hashrate supply.

## Implementation

As far as I understand, the Core-Geth client is the only client to have implemented ECBP-1100, making it the only client that needs to implement deactivation.

## Testing

## References

### Abstract
This ECIP describes the details of delaying Difficulty Bomb growth for one year. It’s suggested to change Difficulty Bomb formula to stop growing for period of time from January 2017 to December 2017, which is around blocks 3,000,000 and 5,000,000 accordingly.

### Motivation
For the next phase of Ethereum Classic it’s planned to make a set of updates that could possible break backward compatibility and make serious changes to Ethereum Classic economic model. It includes changes to Monetary Policy, PoW/PoS or Hybrid, Replay Attack, DAG growths and Difficulty Bomb itself. All of these topics are important and must be solved as soon as possible.

Such changes to the protocol can cause another fork, and it’s very dangerous to introduce just part of protocol changes at this moment. It’s very likely that after the Difficulty Bomb will be diffused it will be near impossible to make any other changes to the protocol. That is one of the main reasons why Difficulty Bomb was introduced initially.

To reduce risk of a potential fork during protocol upgrades and to keep development resources focused on working on the next phase of the Ethereum Classic, it seems reasonable to implement Difficulty Bomb diffusion at the very last step in the series of protocol upgrades.

Most of this upgrades to the protocol requires significant time for finding optimal model, implementation and testing. It’s too reckless to make this changes without proper validation. With optimistic estimations it requires at least 6 months, which is not giving us enough time before Difficulty Explosion moment. Also consider the fact that this is an estimation for the ideal situation.

One of the most feasible solutions at this moment will be delaying difficulty growth to the moment when all other changes will be ready to use.

Delaying the Difficulty Bomb is a trivial change to the protocol. It keeps all the logic on place, just adds a pause in X blocks to stop difficulty growing for a some period of time. If we choose 2,000,000 blocks, it will a pause it for about a year, which will give us time to implement and test all protocol upgrades for the next version.

### Specification
Current formula for a minimal difficulty is

The most important part related to Difficulty Bomb is:

It’s a lower bound for minimal difficulty, which grows exponentially with next step every 100,000 blocks. -2 is added to start growth only after the block 200,000

With this formula minimal difficulty is:
- Block 1 == 2(-2) == 0
- Block 100,000 == 2(-1) == 0
- Block 200,000 == 20 == 1
- Block 300,000 == 21 == 2
- Block 1,920,000 == 217 == 131,072
- Block 2,000,000 == 218 == 262,144
- Block 2,500,000 == 223 == 8,388,608
- Block 3,000,000 == 228 == 268,435,456
- Block 4,000,000 == 238 == 274,877,906,944 or 274 GH
- Block 5,000,000 == 248 == 281 TH
- Block 5,200,000 == 250 == 1126 TH
- Block 6,000,000 == 258 == 288230 TH

Current difficulty used for mining is 8 TH. For a comparison, difficulty in Forked ETH Blockchain is 71 TH.

To pause difficulty growth (block.number / 100000) - 2 must be fixed to a concrete value for the range 3,000,000 to 5,000,000, then continue growing.

Instead of value 2 it’s proposed to use n with a dynamic formula as following:

Constants:

Final formula:

With this changes min difficulty value will become:
- Block 2,500,000 == 223 == 8,388,608
- Block 3,000,000 == 228 == 268,435,456
- Block 4,000,000 == 228 == 268,435,456
- Block 5,000,000 == 228 == 268,435,456
- Block 5,200,000 == 230 == 1 GH
- Block 6,000,000 == 238 == 274 GH

### Links
- Difficulty growth model: https://docs.google.com/spreadsheets/d/1ZXNrSCNV0HGWU7zOTUyIIRUGv5M44P6wiAZclpY4Y2Q/edit

### NOTE

The ECIP was replaced by ECIP-1090 - ECIP process
and was never activated.

### Abstract

Both soc1c and meowbits have
made it crystal clear in multiple posts across Github and the ETC Discord server
that they do not want their real names to be used in ECIP-1000 anymore, but instead
will be using "Talha Cross" and "Mr. Meows D. Bits" respectively as their pseudonyms.

Their contact details remain the same and they are readily contactable.

### Motivation

Donald expressed this very well
in a recent Github comment:

"... it is absolutely acceptable to work pseudonymously. It is a long tradition of
decades in the cypherpunk philosophy (the source and likely creators or Bitcoin) and
Bitcoin, the first implementation of a PoW blockchain, was, in fact, created by a
pseudonymous individual or team.

As it is imperative in the crypto industries (both cryptography and blockchain) to let
people work in the level of privacy they prefer, it is irrelevant for the ECIP process
what names contributors choose to use, therefore it is not appropriate, "important",
nor advisable to mark participants by their levels of privacy."

## Copyright

This work is licensed under the Apache License, Version 2.0. The author, Bob Summerwill, attests to his sole authorship of this work, and that he is able to contribute this work to the ECIP process under the Apache 2.0 licence.

He further attests that he neither holds nor is aware of any patents, trademarks, copyright issues or other IP hinderances associated with this work.

# Abstract

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 mechanism 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.

# Copyright

This ECIP is licensed Apache-2, originally by Luke Dashjr under BSD 2-clause license.

# ECIP Workflow

## Introduction

The ECIP process begins with a new idea for Ethereum Classic. Each potential ECIP must have a champion -- someone who writes the ECIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The ECIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is ECIP-able.

Small enhancements or patches to a particular piece of software often don't require standardization between multiple projects; these don't need an ECIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.

Additionally, many ideas have been brought forward for changing Ethereum Classic that have been rejected for various reasons.

## Steps

1: The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression.

After investigating past work, the best way to proceed is by posting about the new idea to the Ethereum Classic Discord #ecips Channel.

Vetting an idea publicly before going as far as writing a ECIP is meant to save both the potential author and the wider community time.

Asking the Ethereum Classic community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick).

It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum Classic is used.

2: Once the champion has asked the Ethereum Classic community as to whether an idea has any chance of acceptance, a draft ECIP should be submitted to the ECIPs git repository as a pull request. This gives the author a chance to flesh out the draft ECIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. This draft must be written in ECIP style as described below, and named with an alias such as "ecip-johndoe-infinitecoins" until an editor has assigned it an ECIP number (authors MUST NOT self-assign ECIP numbers).

ECIP authors are responsible for collecting community feedback on both the initial idea and the ECIP before submitting it for review. However, wherever possible, long open-ended discussions on public groups or mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the ECIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. ECIP authors should use their discretion here.

It is highly recommended that a single ECIP contain a single key proposal or new idea. The more focused the ECIP, the more successful it tends to be. If in doubt, split your ECIP into several well-focused ones. Please check out the ECIPs in this repository and search for similar ones that have already been created.

3: When the ECIP draft is complete, an ECIP editor will assign the ECIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the ECIPs git repository.

The ECIP editor will not unreasonably reject an ECIP.

Reasons for rejecting ECIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Ethereum Classic philosophy.

For a ECIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

4: During the life cycle of the ECIP, the author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.

## Transferring ECIP Ownership

It occasionally becomes necessary to transfer ownership of ECIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred ECIP, but that's really up to the original author.

A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the ECIP process, or has fallen off the face of the net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ECIP. We try to build consensus around an ECIP, but if that's not possible, you can always submit a competing ECIP.

If you are interested in assuming ownership of a ECIP, send a message asking to take over, addressed to both the original author and the ECIP editor. If the original author doesn't respond to email in a timely manner, the ECIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).

## ECIP Editors

Current ECIP editors:
- @chris-mercer - Christopher Mercer
- @IstoraMandiri - Istora Mandiri
- @Diega - Diego López León
- @realcodywburns - Cody Burns

Former ECIP editors:
- @atoulme - Antoine Toulme
- @BelfordZ - Zachary Belford
- @faraggi - Felipe Faraggi
- @gitr0n1n - r0n1n
- @soc1c - Talha Cross
- @sorpaas - Wei Tang
- @stevanlohja - Stevan Lohja
- @meowbits - Mr. Meows D. Bits
- @YazzyYaz - Yaz Khoury

## ECIP Editor Responsibilities & Workflow

### Introduction

ECIP editors are intended to fulfill administrative and editorial responsibilities. ECIP editors monitor ECIP changes, and update ECIP headers as appropriate.

### Steps

1: Each new ECIP should first be submitted as a "pull request" to the ECIPs git repository. Then, an editor does the following:
- Read the ECIP to check if it is ready: sound and complete. The ideas must make technical sense, even if it doesn't seem likely to be accepted.
- The title should accurately describe the content.
- Motivation and backward compatibility (when applicable) must be addressed.
- The defined Layer header must be correctly assigned for the given specification.
- Licensing terms must be acceptable for ECIPs.

2: If the ECIP isn't ready, the editor will send it back to the author for revision with specific instructions.

3: Once the ECIP is ready, the ECIP editor will:
- Assign a ECIP number in the pull request.
- Merge the pull request when it is ready.
- List the ECIP in [[README.mediawiki]]

# ECIP Format and Structure

## Specification

ECIPs should be written in mediawiki or markdown format.

Each ECIP should have the following parts:
- Preamble -- Headers containing metadata about the ECIP see below.
- Abstract -- A short (~200 word) description of the technical issue being addressed.
- Copyright -- The ECIP must be explicitly licensed under acceptable copyright terms see below
- Specification -- The technical specification should describe the syntax and semantics of any new feature. It should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum Classic platforms.
- Motivation -- The motivation is critical for ECIPs that want to change the Ethereum Classic protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the ECIP solves.
- Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. It should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
- Backwards compatibility -- All ECIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ECIP must explain how the author proposes to deal with these incompatibilities.
- Reference implementation -- The reference implementation must be completed before any ECIP is given "Final" status, but it need not be completed before the ECIP is "Accepted". It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Ethereum Classic protocol.

### ECIP Header Preamble

Each ECIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "" are optional and are described below. All other headers are required.
- ECIP: (ECIP number, or "?" before being assigned)
- Layer: (Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications)
- Title: (ECIP title; maximum 44 characters)
- Author: (authors real names and email addrs)
- Discussions-To: (email address)
- Comments-Summary: (summary tone)
- Comments-URI: (links to wiki page for comments)
- Status: (Draft | Last Call | Accepted | Final | Deferred | Replaced | Rejected | Withdrawn)
- Type: (Standards Track | Informational | Process)
- Created: (date created on, in ISO 8601 (yyyy-mm-dd) format)
- License: (abbreviation for approved license(s))
- License-Code: (abbreviation for code under different approved license(s))
- Requires: (ECIP number(s))
- Replaces: (ECIP number)
- Superseded-By: (ECIP number)

The Layer header (only for Standards Track ECIPs) documents which layer of Ethereum Classic the ECIP applies to.

The Author header lists the names and email addresses/GitHub handles of all the authors/owners of the ECIP.
The format of the Author header value must be:

 Random J. User
 Random J. User (@random.j.user)

If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.

While an ECIP is in private discussions (usually during the initial Draft phase), aDiscussions-To header will indicate the mailing list or URL where the ECIP is being discussed. No Discussions-To header is necessary if the ECIP is being discussed privately with the author.

The Type header specifies the type of ECIP: Standards Track, Informational, or Process.

The Created header records the date that the ECIP was assigned a number.

ECIPs may have a Requires header, indicating the ECIP numbers that this ECIP depends on.

ECIPs may also have a Superseded-By header indicating that a ECIP has been rendered obsolete by a later document; the value is the number of the ECIP that replaces the current document. The newer ECIP must have a Replaces header containing the number of the ECIP that it rendered obsolete.

### Auxiliary Files

ECIPs may include auxiliary files such as diagrams. If if requires images, the image files should be included in a subdirectory of the assets folder for that ECIP as follow: assets/ecip-X. When linking to an image in the ECIP, use the related links such as ./assets/ecip-X/image.png.

## ECIP Types

There are three types of ECIP:
- A Standard Track ECIP describes any change that affects most or all Ethereum Classic implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum Classic. Furthermore, Standard Track ECIPs can be broken down into the following categories:
- Core - improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to core developer discussions.
- Networking - improvements to networking protocol specifications.
- Interface - improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names and contract ABIs.
- ECBP (Ethereum Classic Best Practice) - application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats.
- A Meta ECIP describes a process surrounding Ethereum Classic or proposes a change to a process (or an event like the next hard fork). Process ECIPs are like Standard Track ECIPs, but apply to areas other than the Ethereum Classic protocol itself. They may propose an implementation, but not to Ethereum Classic's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process (e.g. this ECIP-1000 process document), and changes to the tools or environment used in Ethereum Classic development. If a Meta ECIP is for a hard fork, changes are to be updated with PRs to existing Meta ECIPs. Any meta-ECIP is also considered a Process ECIP.
- An Informational ECIP describes an Ethereum Classic design issue, or provides general guidelines or information to the Ethereum Classic community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum Classic community consensus or a recommendation, so users and implementors are free to ignore Informational ECIPs or follow their advice.

It is highly recommended that a single ECIP contain a single key proposal or new idea. The more focused the ECIP, the more successful it tends to be. A change to one client doesn't require an ECIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.

An ECIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement.

## ECIP Status Field

### Specification

The typical paths of the status of ECIPs are as follows:

Champions of an ECIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.

The ECIP editor may also change the status to Deferred when no progress is being made on the ECIP.

An ECIP may only change status from Draft (or Rejected) to Last Call, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to Final status.

ECIPs should be changed from Draft or Last Call status, to Rejected, upon request by any person, if they have not made progress in three years. Such a ECIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Last Call if it meets the criteria required as described in the previous paragraph.

An Accepted ECIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each ECIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development calls, Discord channel, other groups or the mailing list.

When a Final ECIP is no longer relevant, its status may be changed to Replaced. This change must also be objectively verifiable and/or discussed.

Some Informational ECIPs, which are considered process ECIPs, may also be moved to a status of Active instead of Final if they are never meant to be completed, e.g. this ECIP-1000.

Draft ECIPs which may be in a very early stage may be entered as WIP ECIPs, which means they are a work in progress.

A process ECIP may change status from Draft to Final when it achieves rough consensus on the discussion process. Such a proposal is said to have rough consensus if it has been open to discussion on the development calls, Discord channel, other groups or the mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.

### Progression to Final status

Peer services ECIPs should be observed to be adopted by at least 1% of public listening nodes for one month.

API/RPC and application layer ECIPs must be implemented by at least two independent and compatible software applications.

Software authors are encouraged to publish summaries of what ECIPs their software supports to aid in verification of status changes. Good examples of this, at the time of writing this ECIP, can be observed in Bitcoin Core's doc/BIPs.md file as well as Bitcoin Wallet for Android's wallet/README.specs file.

These criteria are considered objective ways to observe the de facto adoption of the ECIP, and are not to be used as reasons to oppose or reject an ECIP. Should an ECIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.

## Rationale

Why is this necessary at all?
- Many ECIPs with significant real-world use have been left as Draft or Last Call status longer than appropriate. By giving objective criteria to judge the progression of ECIPs, this proposal aims to help keep the Status accurate and up-to-date.

What is the ideal percentage of listening nodes needed to adopt peer services proposals?
- This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.

Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer ECIPs, before they become Final?
- If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
- Even if there are only two projects rather than more, some standard coordination between them exists.

What if a ECIP is proposed that only makes sense for a single specific project?
- The ECIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a ECIP in the first place.

## ECIP comments

### Specification

Each ECIP should, in its preamble, link to a public wiki page with a summary tone of the comments on that page.

Reviewers of the ECIP who consider themselves qualified, should post their own comments on this wiki page.

The comments page should generally only be used to post final comments for a completed ECIP.

If an ECIP is not yet completed, reviewers should instead post on the applicable development Discord group or mailing list thread to allow the ECIP author(s) to address any concerns or problems pointed out by the review.

Some ECIPs receive exposure outside the development community prior to completion, and other ECIPs might not be completed at all. To avoid a situation where critical ECIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).

Pages must be named after the full ECIP number (eg, "ECIP 0001") and placed in the "Comments" namespace.

For example, the link for ECIP 1 will be:

 https://github.com/ethereumclassic/ECIPs/wiki/Comments:ECIP-0001 .

Comments posted to this wiki should use the following format:

ECIPs may also choose to list a second forum for ECIP comments, in addition to the ECIPs wiki.
In this case, the second forum's URI should be listed below the primary wiki's URI.

After some time, the ECIP itself may be updated with a summary tone of the comments.
Summary tones may be chosen from the following, but this ECIP does not intend to cover all possible nuances and other summaries may be used as needed:
- No comments yet.
- Unanimously Recommended for implementation
- Unanimously Discourage for implementation
- Mostly Recommended for implementation, with some Discouragement
- Mostly Discouraged for implementation, with some Recommendation

For example, the preamble to ECIP 1 might be updated to include the line:

These fields must follow the Discussions-To header defined in ECIP 1 (if that header is not present, it should follow the position where it would be present; generally this is immediately above the Status header).

To avoid doubt: comments and status are unrelated metrics to judge an ECIP, and neither should be directly influencing the other.

## Rationale

What is the purpose of ECIP comments?
- Various ECIPs have been adopted (the criteria required for Final status) despite being considered generally inadvisable. Some presently regard ECIPs as a "good idea" simply by virtue of them being assigned an ECIP number. Due to the low barrier of entry for submission of new ECIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.

Will ECIP comments be censored or limited to particular participants/"experts"?
- Participants should freely refrain from commenting outside of their area of knowledge or expertise. However, comments should not be censored, and participation should be open to the public.

## ECIP Licensing

### Specification

New ECIPs may be accepted with the following licenses. Each new ECIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below.

For example, a preamble might include the following License header:

In this case, the ECIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of either license. In other words, the license list is an "OR choice", not an "AND also" requirement.

It is also possible to license source code differently from the ECIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.

For example, a preamble specifying the optional License-Code header might look like:

In this case, the code in the ECIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer.
If the code were to be available under only version 2 exactly, the "+" symbol should be removed from the license abbreviation.
For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent).

In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the ECIP.

ECIPs are not required to be exclusively licensed under approved terms, and may also be licensed under unacceptable licenses in addition to* at least one acceptable license.
In this case, only the acceptable license(s) should be listed in the License and License-Code headers.

### Recommended licenses
- Apache-2.0: Apache License, version 2.0
- BSD-2-Clause: OSI-approved BSD 2-clause license
- BSD-3-Clause: OSI-approved BSD 3-clause license
- CC0-1.0: Creative Commons CC0 1.0 Universal
- GNU-All-Permissive: GNU All-Permissive License

In addition, it is recommended that literal code included in the ECIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Ethereum Classic Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ECIP text.

### Not recommended, but acceptable licenses
- BSL-1.0: Boost Software License, version 1.0
- CC-BY-4.0: Creative Commons Attribution 4.0 International
- CC-BY-SA-4.0: Creative Commons Attribution-ShareAlike 4.0 International
- MIT: Expat/MIT/X11 license
- AGPL-3.0+: GNU Affero General Public License (AGPL), version 3 or newer
- FDL-1.3: GNU Free Documentation License, version 1.3
- GPL-2.0+: GNU General Public License (GPL), version 2 or newer
- LGPL-2.1+: GNU Lesser General Public License (LGPL), version 2.1 or newer

## Rationale

Why are there software licenses included?
- Some ECIPs, especially consensus layer, may include literal code in the ECIP itself which may not be available under the exact license terms of the ECIP.
- Despite this, not all software licenses would be acceptable for content included in ECIPs.

# See Also
- RFC 7282: On Consensus and Humming in the IETF

# Abstract

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 mechanism for proposing new features, for collecting ecosystem 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 ECIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

This ECIP process has the purpose of making proposals and maintaining the Ethereum Classic protocol, it is not a governance system nor a constitution.

# Copyright

This ECIP is licensed Apache-2, it is based on ECIP-1000, licensed Apache-2 by Wei Tang, originally by Luke Dashjr under BSD 2-clause license.

# Precedents

This ECIP process has the precedents of the Bitcoin BIP and the Ethereum EIP processes.

# ECIP Workflow

## Introduction

The ECIP process begins with a new idea for Ethereum Classic. Each potential ECIP must have a champion -- someone who writes the ECIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The ECIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is ECIP-able.

Small enhancements or patches to a particular piece of software often don't require standardization between multiple projects; these don't need an ECIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.

Additionally, many ideas have been brought forward for changing Ethereum Classic that have been rejected for various reasons.

## Steps

1) The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression.

After investigating past work, the best way to proceed is by posting about the new idea to the Ethereum Classic Discord #ecips Channel.

Vetting an idea publicly before going as far as writing a ECIP is meant to save both the potential author and the wider community time.

Asking the Ethereum Classic community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick).

It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum Classic is used.

2) Once the champion has asked the Ethereum Classic community as to whether an idea has any chance of acceptance, a draft ECIP should be submitted to the ECIPs git repository as a pull request. This gives the author a chance to flesh out the draft ECIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. This draft must be written in ECIP style as described below, and named with an alias such as "ecip-johndoe-infinitecoins" until an editor has assigned it an ECIP number (authors MUST NOT self-assign ECIP numbers).

ECIP authors are responsible for collecting community feedback on both the initial idea and the ECIP before submitting it for review. However, wherever possible, long open-ended discussions on public groups or mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the ECIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. ECIP authors should use their discretion here.

It is highly recommended that a single ECIP contain a single key proposal or new idea. The more focused the ECIP, the more successful it tends to be. If in doubt, split your ECIP into several well-focused ones.

3) When the ECIP draft is complete, an ECIP editor will assign the ECIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the ECIPs git repository.

The ECIP editor will not unreasonably reject an ECIP.

Reasons for rejecting ECIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Ethereum Classic philosophy.

For a ECIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

4) During the life cycle of the ECIP, the author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.

## Transferring ECIP Ownership

It occasionally becomes necessary to transfer ownership of ECIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred ECIP, but that's really up to the original author.

A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the ECIP process, or has fallen off the face of the net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ECIP. We try to build consensus around an ECIP, but if that's not possible, you can always submit a competing ECIP.

If you are interested in assuming ownership of a ECIP, send a message asking to take over, addressed to both the original author and the ECIP editor. If the original author doesn't respond to email in a timely manner, the ECIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).

## ECIP Editors

The current ECIP editors are:
- Mr. Meows D. Bits (@meowsbits)
- Cody Burns (@realcodywburns)
- Yaz Khoury (@YazzyYaz)
- Zachary Belford (@BelfordZ)

## ECIP Editor Responsibilities & Workflow

### Introduction

ECIP editors are intended to fulfill administrative and editorial responsibilities. ECIP editors monitor ECIP changes, and update ECIP headers as appropriate.

### Steps

1) Each new ECIP should first be submitted as a "pull request" to the ECIPs git repository. Then, an editor does the following:
- Read the ECIP to check if it is ready: sound and complete. The ideas must make technical sense, even if it doesn't seem likely to be accepted.
- The title should accurately describe the content.
- Motivation and backward compatibility (when applicable) must be addressed.
- The defined Layer header must be correctly assigned for the given specification.
- Licensing terms must be acceptable for ECIPs.

2) If the ECIP isn't ready, the editor will send it back to the author for revision with specific instructions.

3) Once the ECIP is ready, the ECIP editor will:
- Assign a ECIP number in the pull request.
- Merge the pull request when it is ready.
- List the ECIP in [[README.mediawiki]]

# ECIP Format and Structure

## Specification

ECIPs should be written in mediawiki or markdown format.

Each ECIP should have the following parts:
- Preamble -- Headers containing metadata about the ECIP see below.
- Abstract -- A short (~200 word) description of the technical issue being addressed.
- Copyright -- The ECIP must be explicitly licensed under acceptable copyright terms see below
- Specification -- The technical specification should describe the syntax and semantics of any new feature. It should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum Classic platforms.
- Motivation -- The motivation is critical for ECIPs that want to change the Ethereum Classic protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the ECIP solves.
- Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. It should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
- Backwards compatibility -- All ECIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ECIP must explain how the author proposes to deal with these incompatibilities.
- Reference implementation -- The reference implementation must be completed before any ECIP is given "Final" status, but it need not be completed before the ECIP is "Accepted". It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Ethereum Classic protocol.

### ECIP Header Preamble

Each ECIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "" are optional and are described below. All other headers are required.
- ECIP: (ECIP number, or "?" before being assigned)
- Layer: (Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications)
- Title: (ECIP title; maximum 44 characters)
- Author: (authors real names and email addrs)
- Discussions-To: (email address)
- Comments-Summary: (summary tone)
- Comments-URI: (links to wiki page for comments)
- Status: (Draft | Last Call | Accepted | Final | Deferred | Replaced | Rejected | Withdrawn)
- Type: (Standards Track | Informational | Process)
- Created: (date created on, in ISO 8601 (yyyy-mm-dd) format)
- License: (abbreviation for approved license(s))
- License-Code: (abbreviation for code under different approved license(s))
- Requires: (ECIP number(s))
- Replaces: (ECIP number)
- Superseded-By: (ECIP number)

The Layer header (only for Standards Track ECIPs) documents which layer of Ethereum Classic the ECIP applies to.

The Author header lists the names and email addresses of all the authors/owners of the ECIP.
The format of the Author header value must be:

 Random J. User

If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.

While an ECIP is in private discussions (usually during the initial Draft phase), aDiscussions-To header will indicate the mailing list or URL where the ECIP is being discussed. No Discussions-To header is necessary if the ECIP is being discussed privately with the author.

The Type header specifies the type of ECIP: Standards Track, Informational, or Process.

The Created header records the date that the ECIP was assigned a number.

ECIPs may have a Requires header, indicating the ECIP numbers that this ECIP depends on.

ECIPs may also have a Superseded-By header indicating that a ECIP has been rendered obsolete by a later document; the value is the number of the ECIP that replaces the current document. The newer ECIP must have a Replaces header containing the number of the ECIP that it rendered obsolete.

### Auxiliary Files

ECIPs may include auxiliary files such as diagrams. If if requires images, the image files should be included in a subdirectory of the assets folder for that ECIP as follow: assets/ecip-X. When linking to an image in the ECIP, use the related links such as ./assets/ecip-X/image.png.

## ECIP Types

There are three types of ECIP:
- A Standard Track ECIP describes any change that affects most or all Ethereum Classic implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum Classic. Furthermore, Standard Track ECIPs can be broken down into the following categories:
- Core - improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to core developer discussions.
- Networking - improvements to networking protocol specifications.
- Interface - improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names and contract ABIs.
- ECBP (Ethereum Classic Best Practice) - application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats.
- A Meta ECIP describes a process surrounding Ethereum Classic or proposes a change to (or an event in) a process. Process ECIPs are like Standard Track ECIPs, but apply to areas other than the Ethereum Classic protocol itself. They may propose an implementation, but not to Ethereum Classic's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process (e.g. this ECIP-1090 process document), and changes to the tools or environment used in Ethereum Classic development. Any meta-ECIP is also considered a Process ECIP.
- An Informational ECIP describes an Ethereum Classic design issue, or provides general guidelines or information to the Ethereum Classic community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum Classic community consensus or a recommendation, so users and implementors are free to ignore Informational ECIPs or follow their advice.

It is highly recommended that a single ECIP contain a single key proposal or new idea. The more focused the ECIP, the more successful it tends to be. A change to one client doesn't require an ECIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.

An ECIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement.

## ECIP Status Field

### Specification

The typical status lifecycles of successful ECIP types, from pull requests to merged and fully processed or implemented, are as follows:

For Standard Track ECIPs:

For Meta or Informational ECIPs:

However, core developers and editors can decide to move ECIPs back to previous statuses after the fact, or to Rejected or Withdrawn status at their discretion provided there is reasonable cause, e.g. a major, but correctable, flaw was found in the ECIP, or a major but not correctable flaw was found in the ECIP.

Champions of an ECIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.

The ECIP editor may also change the status to Deferred when no progress is being made on the ECIP.

An ECIP may only change status from Draft (or Rejected) to Last Call, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to Final status.

ECIPs should be changed from Draft or Last Call status, to Rejected, upon request by any person, if they have not made progress in three years. Such a ECIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Last Call if it meets the criteria required as described in the previous paragraph.

An Accepted ECIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each ECIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development calls, Discord channel, other groups or the mailing list.

When a Final ECIP is no longer relevant, its status may be changed to Replaced. This change must also be objectively verifiable and/or discussed.

Some Informational ECIPs, which are considered process ECIPs, may also be moved to a status of Active instead of Final if they are never meant to be completed, e.g. this ECIP-1000.

Draft ECIPs which may be in a very early stage may be entered as WIP pull requests, which means they are a work in progress. However, WIP ECIP pull requests may not be merged into the ECIP repository unless authors feel confident enough about their proposals and moved them to Draft status.

A process ECIP may change status from Draft to Final when it achieves rough consensus on the discussion process. Such a proposal is said to have rough consensus if it has been open to discussion on the development calls, Discord channel, other groups or the mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.

### Progression to Final status

Peer services ECIPs should be observed to be adopted by at least 1% of public listening nodes for one month.

API/RPC and application layer ECIPs must be implemented by at least two independent and compatible software applications.

Software authors are encouraged to publish summaries of what ECIPs their software supports to aid in verification of status changes. Good examples of this, at the time of writing this ECIP, can be observed in Bitcoin Core's doc/BIPs.md file as well as Bitcoin Wallet for Android's wallet/README.specs file.

These criteria are considered objective ways to observe the de facto adoption of the ECIP, and are not to be used as reasons to oppose or reject an ECIP. Should an ECIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.

## Rationale

Why is this necessary at all?
- Many ECIPs with significant real-world use have been left as Draft or Last Call status longer than appropriate. By giving objective criteria to judge the progression of ECIPs, this proposal aims to help keep the Status accurate and up-to-date.

What is the ideal percentage of listening nodes needed to adopt peer services proposals?
- This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.

Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer ECIPs, before they become Final?
- If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
- Even if there are only two projects rather than more, some standard coordination between them exists.

What if a ECIP is proposed that only makes sense for a single specific project?
- The ECIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a ECIP in the first place.

## ECIP comments

### Specification

Each ECIP should, in its preamble, link to a public wiki page with a summary tone of the comments on that page.

Reviewers of the ECIP who consider themselves qualified, should post their own comments on this wiki page.

The comments page should generally only be used to post final comments for a completed ECIP.

If an ECIP is not yet completed, reviewers should instead post on the applicable development Discord group or mailing list thread to allow the ECIP author(s) to address any concerns or problems pointed out by the review.

Some ECIPs receive exposure outside the development community prior to completion, and other ECIPs might not be completed at all. To avoid a situation where critical ECIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).

Pages must be named after the full ECIP number (eg, "ECIP 1090") and placed in the "Comments" namespace.

For example, the link for ECIP 1 will be:

 https://github.com/ethereumclassic/ECIPs/wiki/Comments:ECIP-1090 .

Comments posted to this wiki should use the following format:

ECIPs may also choose to list a second forum for ECIP comments, in addition to the ECIPs wiki.
In this case, the second forum's URI should be listed below the primary wiki's URI.

After some time, the ECIP itself may be updated with a summary tone of the comments.
Summary tones may be chosen from the following, but this ECIP does not intend to cover all possible nuances and other summaries may be used as needed:
- No comments yet.
- Unanimously Recommended for implementation
- Unanimously Discourage for implementation
- Mostly Recommended for implementation, with some Discouragement
- Mostly Discouraged for implementation, with some Recommendation

For example, the preamble to ECIP 1 might be updated to include the line:

These fields must follow the Discussions-To header defined in ECIP 1 (if that header is not present, it should follow the position where it would be present; generally this is immediately above the Status header).

To avoid doubt: comments and status are unrelated metrics to judge an ECIP, and neither should be directly influencing the other.

## Rationale

What is the purpose of ECIP comments?
- Various ECIPs have been adopted (the criteria required for Final` status) despite being considered generally inadvisable. Some presently regard ECIPs as a "good idea" simply by virtue of them being assigned an ECIP number. Due to the low barrier of entry for submission of new ECIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.

Will ECIP comments be censored or limited to particular participants/"experts"?
- Participants should freely refrain from commenting outside of their area of knowledge or expertise. However, comments should not be censored, and participation should be open to the public.

## ECIP Licensing

### Specification

New ECIPs may be accepted with the following licenses. Each new ECIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below.

For example, a preamble might include the following License header:

In this case, the ECIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of either license. In other words, the license list is an "OR choice", not an "AND also" requirement.

It is also possible to license source code differently from the ECIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.

For example, a preamble specifying the optional License-Code header might look like:

In this case, the code in the ECIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer.
If the code were to be available under only version 2 exactly, the "+" symbol should be removed from the license abbreviation.
For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent).

In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, the details of the licensing terms must be provided in the Copyright section of the ECIP.

ECIPs are not required to be exclusively licensed under approved terms, and may also be licensed under unacceptable licenses in addition to* at least one acceptable license.
In this case, only the acceptable license(s) should be listed in the License and License-Code headers.

### Recommended licenses
- Apache-2.0: Apache License, version 2.0
- BSD-2-Clause: OSI-approved BSD 2-clause license
- BSD-3-Clause: OSI-approved BSD 3-clause license
- CC0-1.0: Creative Commons CC0 1.0 Universal
- GNU-All-Permissive: GNU All-Permissive License

In addition, it is recommended that literal code included in the ECIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Ethereum Classic Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ECIP text.

### Not recommended, but acceptable licenses
- BSL-1.0: Boost Software License, version 1.0
- CC-BY-4.0: Creative Commons Attribution 4.0 International
- CC-BY-SA-4.0: Creative Commons Attribution-ShareAlike 4.0 International
- MIT: Expat/MIT/X11 license
- AGPL-3.0+: GNU Affero General Public License (AGPL), version 3 or newer
- FDL-1.3: GNU Free Documentation License, version 1.3
- GPL-2.0+: GNU General Public License (GPL), version 2 or newer
- LGPL-2.1+: GNU Lesser General Public License (LGPL), version 2.1 or newer

## Rationale

Why are there software licenses included?
- Some ECIPs, especially consensus layer, may include literal code in the ECIP itself which may not be available under the exact license terms of the ECIP.
- Despite this, not all software licenses would be acceptable for content included in ECIPs.

# ECIP Process Code of Conduct

## ECIP Participants Will Adhere to the Following
1. Anyone can participate in the ECIP process as a competent developer, miner, validator, node operator, user, or any other prescribed participant or stakeholder.
2. Within the ECIP documents and discussion pages, participants will conduct themselves professionally, will not abuse their privileges, if any, to obstruct or derail the process, will focus on ECIP issues, making sure their arguments are well founded, minimizing trolling, insulting or derogatory comments, and personal or political attacks.
3. Participant privacy will be respected. Publishing other participant’s private information, such as a physical or email addresses, or real names, without their explicit permission is not allowed within the ECIP process nor in other public forums.
4. Ethereum Classic organization owners on Github or other platforms in use, ECIP repo admins, and ECIP editors have the right and responsibility to remove ECIP participants of any kind, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this ECIP-1090 and Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

## Rationale

The ECIP process, like any open source software development process or repository on Github or other platforms, has suffered the vulnerability of being taken over, obstructed, or tampered with by internal and external participants. Although in a permissionless open source system as ETC the ideal is to minimize rules and to be as open as possible, it is also important to protect participant privacy, have a professional proposal and discussion dynamic, and minimize obstructions and harassment. These goals help guarantee openness and maintain a high technical and knowledgeable set of participants in the process.

# See Also
- RFC 7282: On Consensus and Humming in the IETF

### Abstract

Don't touch Kotti; allow ECIP1061, ECIP1078, and ECIP1086 (EIP2200, EIP2200Disable) to continue as specified and implemented there.

Set Mordor ECIP1078 activation to 778507 (equivalent to ECIP1061), and rollback to 750000.

### Motivation

ECIP1061 specifies a hard fork "Aztlan" for ETC networks. (google it)

ECIP1078 specifies a hard fork "Phoenix" for ETC Networks (discussions here: https://github.com/ethereumclassic/ECIPs/issues/262).

ECIP1061 enables EIP2200.

ECIP1078 disables EIP2200

EIP2200 was incorrectly implemented in ethereum/go-ethereum, etclabscore/multi-geth, multi-geth/multi-geth, and paritytech/parityethereum clients, which together compose the lion's share of ETC network providership.
EIP2200 has since been (simply) corrected (in all impacted providers AFAIK).

ECIP1061 and ECIP1078 have equal activation block numbers on mainnet (10500839).
But ECIP1061 has already been activated on testnets, while ECIP1078, with a later testnet activation, is not yet enabled on the testnets.

This means that an incorrect (and mainnet irrelevant) implementation of EIP2200 is live on testnets.
This means that protocol providers publishing releases which include ECIP1078 for testnets are faced with a dilemma:
- Don't correct EIP2200 before the testnets ECIP1078 fork.
- Do correct EIP2200 before the fork, but follow specification (ECIP1086) to "allow" the incorrect EIP2200 implementation.
- Do correct EIP2200 before the fork, but rollback the effected testnets to "reset" prior to the impact of the incorrect EIP2200 implementation.

There seem to be two major, sometimes contradictory, philosophies about ETC testnets:

A. Testnets are a public service; a place for ETC-based dapp developers to try out their stuff in public.

B. Testnets are a public test; a place to demonstrate network feature acceptance before equivalent changes risk actual value on ETC mainnet.

### Specification

Accept and include ECIP1086 on Kotti testnet. This leaves ECIP1061, ECIP1078, and the current proposal for handling the EIP2200 in/correction as-is and unchanged.

Change Mordor testnet ECIP1078 activation number to 778507. This will place ECIP1061 and ECIP1078 activation at equal blocks, and they will activate simulaneously, just like they are scheduled to on mainnet.
Reset Mordor testnet back to block 775000 (3507 blocks prior to its ECIP1061 -- and, as proposed, ECIP1078 -- activation).

### Rationale

Kotti is a PoA network, so it doesn't simulate (ie test) ETC mainnet in the first place (at least not well) since it uses different consensus rules.
If it is a public simulation and test of ETC mainnet, it isn't a good one. So we can follow the logic of A: Testnets-as-service.

Mordor is a PoW network, making it a better simulator of ETC mainnet.
We can follow the logic of B: Testnets-as-test, and not only resolve the issue of EIP2200 correction, but improve the network's simulation of mainnet activation for ECIP1061 and ECIP1078.

### Implementation

N/A

### Copyright/Licensing

This work is licensed under Apache License, Version
2.0.

## Simple Summary

Describes a practice enabling chain discretion based on endorsements by verifiable identities.

## Abstract

Provide a way for node operators to prefer an arbitrary chain segment, and to use that preference to thwart bad guys.

## Motivation

A low hash rate has caused Ethereum Classic's consensus algorithms to yield inconvenient and undesirable finality rates.

This proposal describes a method for collective chain discretion which is currently achievable, avoiding any required modifications to existing consensus protocol.

## Specification

Transactions are included in chain state which signal an identity-verifiable endorsement.

Such transactions can be observed and acted upon in case of chain identification and discretion challenges.

### Endorser Transactions

Transactions are made by an endorsing entity including information in the data field referencing the block hash (or some other unique characteristic) of some endorsed ancestor block.

The construction of this value could be of the form 0xff .

### Endorsement Observation

A node registers some list of trustee entities from whom they wish to acknowledge endorsements.
These entities are encoded as transaction author identities (sender address, from).

Transactions with a data field value matching the general pattern described above are filtered from the set of on-chain transactions.
This set of filtered transactions are filtered again for positive matches against the local list of trustee authors.

Chain segments with positive matches for trustee endorsements are preferred in case of chain discretion challenges.

## Rationale

The identity of an endorser transaction authorship is verifiable because transaction validity depends on valid signing.

## Backwards Compatibility

There are no known backward compatibility issues.

## Security Considerations

### Costs of Implementation

For miners acting as endorsers, the cost of including an endorsement transaction is equal to the opportunity cost of a replacing the transaction authored by anyone else.
If block space competition is incomplete (an unfilled block), the transaction is free (aside from the nominal cost of CPU processing to generate the transaction).

In the general case, the cost of creating an endorsing transaction is equal to cost of that transaction in gas fees.

The cost of observation of such transactions is expected to be programmatically nominal.

### Trustee Sociology and Incentives

It is expected that "followers" subscribing to endorsements should limit their set of trustees to a minimum, subscribing only to the most trustworthy and staked entities; risk of betrayal by any one of an observer's trustees should be met with commensurate risk management.

It should be expected that trustee lists would be kept private for any given observing node.

In practice, a handful of sufficiently large miners should be expected to comprise the universal set of distinct trustees.

### Discretion Challenges

Discretion challenges can be generally understood as any case where a node's view of blockchain state warrants their suspicion.
The programmatic or analogue execution of such deliberation is subjective, and not discussed in this document.

### Is this Proof-of-Authority?

No. Proof of Authority networks use identity authorization as a condition of block production. The endorsement transactions pattern offers a way for node operators to have a choice of trustee when their node is faced with tough decisions.

The cases in which these decisions would occur have been such that a pure proof-of-work consensus is at odds with social benefit. This approach intends to provide a tool whereby node operators can express and observe an aspect of the social and economic context, at the behest of the node operator.

### How is this different than other "Checkpoint" solutions?

This solution does not offer any canonical checkpoint, nor any means of establishing one. Most checkpointing solutions do this.

This solution does not rely on any single oracle or oracles, whereas most checkpointing solutions look to core developers, adjacent networks, or hardcoded values for sources of truth. Instead, this solution offers an existing way for node operators to express and observe chain preference. The ultimate impact of the feature on the network remains strictly in the hands of the operators.

## Copyright/Licensing

Copyright and related rights waived via
CC0.

### Abstract:

The Current ECIP process is chaos. ECIPs are created in random number order without adequate means of tracking changes or monitoring status. During the forming phase of ETC this was somewhat acceptable. Moving forward the process needs to be made clearer to facilitate clearer communication to all participants

### Implementation

All ETC Improvement Proposal should be submitted as pull requests with the format ECIP-n with n being the number after the previous ECIP. This allows for change tracking and historical monitoring.

Every ECIP Should be tagged with a milestone for its current status
Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded

Every ECIP Should be tagged with a label for its type and layer:
Standards Track | Informational | Process
Consensus | Networking | API/RPC | Applications

Every ECIP should follow https://github.com/ethereumproject/ECIPs/blob/master/ECIP-0000.md.sample as closely as practical.

### Abstract
With all financial systems and software, the possibility of fraud and theft are constant threats. This ECIP addresses on chain, independently verifiable, timestamping of project release binaries which can be used for any project and is presented for consideration on all ETC released software.

### Motivation
Loss of trust in decentralized and open projects can be a major obstacle to be overcome for widespread adoption. The ETC wallet creation method protocol allows for a simple verifiable method of demonstrating proof of existence and authority for any public project.

#### Trustless File Verification Problem
All ETC binaries are created and distributed with a SHA-256 hash for cryptographic verification of a file's integrity. The hash distributed with the file is a verification that the file has not been altered from its release state. A motivated malicious actor has the ability to fork/clone an entire repository and create new hash signatures based on the malicious code for distribution. Multiple distribution channels for compiled software are used for the sharing of open source software projects currently and lack a distributed method of signature verification across all channels opens a possible attack vector.

### Specification

#### Wallet Creation from a File Hash
For distributed proof of existence, any files SHA-256 hash is used as an ETC private key to create a public address. This address can be distributed with the binary instead of the hash, but it is not necessary as the address is reproducible. Any user will be able to recreate the public address by creating the hash of the file.

#### On-Chain Proof of Existence

The development team responsible for the creation of a project should send a trivial amount of ETC to the newly created public address from a publicly known account related to the owners. This will serve to both time-stamp the project on the chain and serve as authoritative verification of the account. For the ETC core projects, this can be the public donation address.

#### Independent Verification
Independent verification is possible of any project from any source using this method. As long as a user is capable of creating the sha256 hash of a file, the public key can be verified for transactions. This process also prevents cross chain verification as only one chains wallet will be funded providing a fork-checking functionality. The first user to independently verify a project is capable of claiming the trivial ETC sent for timestamping.

UNDER NO CIRCUMSTANCE SHOULD A PROJECT HASH WALLET BE USED FOR ANY PURPOSE OTHER THAN PROOF OF EXISTENCE!!!!

###Implementations
This process does not require modification to any ETC projects. Block explorer projects, acting as impartial third parties, should be encouraged to implement client side drag and drop SHA-256 file hashing for ease of verification to lay-users who are unfamiliar with hashing.

A decentralized whois contract could be constructed for true decentralized verification, but is not an obstacle to implementation.

### Simple Summary

This ECIP defines the Ethereum Classic Funding Proposal (ECFP) process — the exclusive, standardized, and permissionless mechanism for requesting and executing funding from the Olympia Treasury (ECIP-1112).

ECFPs are application-layer funding proposals that:
- are submitted by any participant without prior permission,
- are reviewed and voted on through Olympia DAO governance (ECIP-1113), and
- are executed only via the DAO’s authorized Governor → Timelock → Executor pipeline, which calls the Treasury with opaque {target, value, calldata} payloads.

This process governs the allocation of BASEFEE revenue redirected under ECIP-1111 and ensures that protocol-level funds are used in a transparent, accountable, and governance-neutral manner.

### Abstract

This ECIP formalizes the Ethereum Classic Funding Proposal (ECFP) process — the standardized, permissionless, and exclusive mechanism for submitting, reviewing, and executing funding requests from the Olympia Treasury (ECIP-1112).

The Treasury is populated by BASEFEE revenue redirected at the consensus layer under ECIP-1111 and is controlled solely by Olympia DAO (ECIP-1113). ECIP-1114 defines:
- the canonical ECFP data model (identifier, recipient, amount, metadata),
- the proposal lifecycle (submission → governance vote → timelocked execution → completion),
- the hash-bound execution model that ties every disbursement to immutable off-chain metadata, and
- the interface boundary between application-layer proposal registries and the governance execution pipeline.

All funding actions are encoded as opaque {target, value, calldata} payloads to the governance system. The Treasury (ECIP-1112) and governance architecture (ECIP-1113) treat ECFP identifiers and hashes as opaque values and do not interpret proposal metadata.

This ECIP introduces no consensus-layer logic and does not modify Treasury or governance behavior. It operates entirely at the application layer and can evolve alongside Olympia DAO via standard governance procedures.

### Motivation

For most of its history, Ethereum Classic has depended on centralized foundations, corporate sponsors, and private donors to fund protocol development and public infrastructure. These arrangements were often opaque, fragile, and vulnerable to gatekeeping, creating long periods of underfunding for:
- client maintenance and consensus upgrades,
- public RPC and node infrastructure,
- security audits and incident response, and
- documentation, education, and ecosystem growth.

With the activation of:
- ECIP-1111 – Olympia EVM and Protocol Upgrades, which redirects BASEFEE into a protocol-level revenue stream,
- ECIP-1112 – Olympia Treasury Contract, which provides an immutable, governance-isolated vault for that revenue, and
- ECIP-1113 – Olympia DAO Governance Framework, which defines the sole on-chain executor path for Treasury withdrawals,

Ethereum Classic gains a decentralized, non-inflationary, protocol-native funding source. What remains is a standardized, auditable process for submitting, reviewing, voting on, and executing funding proposals so that every Treasury allocation is transparent, reproducible, and resistant to capture.

The Ethereum Classic Funding Proposal (ECFP) process addresses this need by:
- defining a clear proposal lifecycle from submission to execution,
- standardizing the data model for funding requests (identifiers, recipients, amounts, metadata),
- binding disbursements to immutable, content-addressed metadata via hash-bound execution, and
- ensuring that all spending decisions flow through the Governor → Timelock → Executor pipeline defined in ECIP-1113.

ECIP-1114 thus replaces ad hoc, off-chain funding arrangements with a transparent, rules-based funding process that is native to Ethereum Classic and aligned with its principles of immutability, decentralization, and neutrality.

### Specification

The Ethereum Classic Funding Proposal (ECFP) process defines the exclusive, standardized, and permissionless on-chain lifecycle for submitting, reviewing, voting on, and executing protocol-level funding proposals. It is the sole mechanism through which the Ethereum Classic community may authorize disbursements from the protocol-level Olympia Treasury defined in ECIP-1112.

ECFPs govern the allocation of BASEFEE revenue redirected at the consensus layer under ECIP-1111.
All funding decisions and all Treasury calls are enforced exclusively by the governance architecture specified in ECIP-1113.

The ECFP process is:
- Transparent — All proposal submissions, votes, approvals, queues, and disbursements are immutably recorded on-chain.
- Reproducible — All participants follow the same lifecycle, parameters, and execution path.
- Hash-bound — Every disbursement is cryptographically bound to immutable proposal metadata through the tuple
 (ecfpId, recipient, amount, metadataCID, chainid),
 ensuring integrity, replay protection, and alignment between off-chain metadata and on-chain execution.

Only successful governance actions that meet quorum, threshold, voting period, and timelock requirements MAY authorize a Treasury disbursement.
Execution occurs through the DAO’s authorized Executor, which forwards an opaque {targets, values, calldatas} payload to the Olympia Treasury. The Treasury validates disbursements via the hash-bound model defined in ECIP-1112, using the exact parameters included in the approved ECFP.

#### ECFP Lifecycle

The ECFP lifecycle defines how a funding proposal moves from initial submission to final execution.
This lifecycle is application-layer only; all governance logic, voting, timelock behavior, and Treasury execution are enforced solely by the Governor → Timelock → Executor architecture defined in ECIP-1113 and the Treasury contract defined in ECIP-1112.

##### 1. Proposal Submission
- Any Ethereum Classic address MAY submit an ECFP.
- Submission is permissionless. Optional Sybil-resistance modules (e.g., BrightID, Gitcoin Passport, Proof of Humanity) MAY be added by DAO vote.
- Each proposal MUST include the following on-chain fields:
- ecfpId – unique proposal identifier
- recipient – address to receive funds
- amount – requested funding amount (wei)
- metadataCID – content-addressed hash (e.g., IPFS, Arweave) binding off-chain metadata
- Off-chain metadata referenced by metadataCID SHOULD include:
- Title / human-readable identifier
- Author(s) and contact information
- Purpose, scope, intended impact
- Disbursement structure (milestones, vesting, lump sum)
- Deliverables and KPIs
- The tuple (ecfpId, recipient, amount, metadataCID, chainid) MUST be used to derive the hash-bound identifier required for execution as defined in ECIP-1112.

##### 2. Proposal Statuses

All ECFPs MUST follow these standardized states:
- Draft — Submitted; open for discussion; not yet eligible for voting.
- Active — Undergoing governance voting.
- Approved — Passed quorum and threshold; queued in the Timelock for execution.
- Rejected — Failed quorum or approval threshold.
- Executed — One or more associated Treasury disbursements were successfully executed.
- Expired — Did not activate or queue within a DAO-defined validity window.

Implementations MAY define additional non-binding UX states (e.g., Cancelled, Superseded), but the above MUST be reconstructible from on-chain events and storage.

##### 3. Voting and Quorum
- All ECFPs SHALL follow the governance logic in ECIP-1113.
- At launch, Olympia DAO operates without a governance token, using a one-address-one-vote model.
 Mitigation strategies for Sybil risk (e.g., attestations, delegated voting, reputation systems) MAY be adopted via future governance.
- The DAO MAY upgrade to alternative voting systems (stake-weighted, delegated stake, quadratic, hybrid) through standard governance without modifying this ECIP.
- A minimum quorum MUST be met.
- A configurable approval threshold (e.g., ≥60% "yes") MUST be met.
- Voting delay and voting period parameters SHALL be DAO-configurable.
- All voting tallies and results MUST be recorded on-chain and be publicly auditable.

##### 4. Execution and Disbursement
- Only proposals that become Approved and are successfully queued in the Timelock MAY proceed to execution.
- Execution is performed exclusively by the DAO’s authorized Executor, which forwards an opaque {targets, values, calldatas} payload to the Treasury as defined in ECIP-1113.
- One of the targets MUST be the Olympia Treasury.
 The corresponding calldata MUST encode the Treasury’s withdrawal function and include:
- The hash-bound identifier derived from
- Matching recipient and amount values
- Treasury disbursement MUST follow the validation rules defined in ECIP-1112.
- Execution MUST emit a ProposalExecuted (or equivalent) event containing:
- ecfpId
- hash-bound identifier
- recipient
- amount
- timestamp
Non-normative note:
No helper function such as executeECFP() is defined in ECIP-1114.
Execution occurs only through Governor → Timelock → Executor as defined in ECIP-1113.

##### 5. Amendments and Withdrawals
- Proposals MAY be modified or withdrawn while in Draft.
- Once in Active, proposal fields (recipient, amount, metadataCID) are immutable.
 Any change requires submitting a new ECFP with a new ecfpId.
- Rejected or expired proposals MAY be resubmitted as new proposals, generating a new hash-bound identifier.

##### 6. Transparency and Indexing
- All state transitions MUST be represented on-chain via storage or events.
- ECFP registries and governance contracts SHOULD emit standardized events:
- ProposalSubmitted
- ProposalActivated
- ProposalQueued
- ProposalExecuted
- Public explorers MAY index proposal metadata, lifecycle transitions, and disbursement history for transparency and auditability.

#### Spam, Sybil, and Governance Capture Mitigations

To preserve openness, integrity, and resilience against manipulation, the following mitigations MAY be adopted by the Olympia DAO through on-chain governance as defined in ECIP-1113.
All measures in this section are optional, modular, and MUST preserve the permissionless nature of the ECFP process.

These mitigations SHALL NOT:
- restrict access through privileged actors or centralized authorities,
- introduce off-chain gatekeepers,
- override the standard ECFP lifecycle, or
- alter the Treasury’s execution rules defined in ECIP-1112.

##### Participation Thresholds

DAO-approved mitigations MAY require lightweight, permissionless submission conditions, such as:
- Refundable ETC deposits (e.g., returned if quorum is met)
- Minimal ETC or governance token holding
- Optional Sybil-resistance attestations, including:
- BrightID
- Gitcoin Passport
- Proof of Humanity
- Any future decentralized identity system approved by governance

These integrations MUST remain:
- permissionless — anyone may still participate by meeting objectively defined criteria
- modular — no hard-coded dependencies
- opt-in — sub-DAOs or workflows MAY elect to use them, but they cannot be mandatory at the consensus layer

##### Submission Cooldowns
- Governance MAY adopt rate limits or cooldown periods between submissions from the same address to reduce spam or flooding.
- These cooldowns MUST be enforced via DAO configuration, not via special access rights.

##### Draft Review Periods
- Every ECFP MUST remain in Draft for a minimum review period to allow time for community feedback and informal discussion before activation.
- The minimum review window MAY be configured through governance.

##### Structured Format Requirements
- All ECFPs MUST conform to the standardized template adopted by the DAO (title, description, metadata, parameters, KPIs, etc.).
- Every ECFP MUST embed a verifiable content hash (e.g., IPFS CID, Arweave digest) of its off-chain metadata.
- The metadataCID MUST match the value used in the hash-bound disbursement tuple (ecfpId, recipient, amount, metadataCID, chainid) required for Treasury execution under ECIP-1112.
- No ECFP MAY proceed to Active unless the metadata hash is well-formed and valid.

These requirements ensure that the metadata used during voting is identical to the metadata bound to the Treasury disbursement, preventing manipulation or divergence between the approved proposal and its execution payload.

#### Voting Model Upgradeability

At launch, the Olympia DAO operates without a governance token, using the one-address-one-vote model defined in ECIP-1113.
This ensures maximum openness and broad community participation during the initial phase of the Olympia framework.

Sybil-resistance modules and submission protections defined in ECIP-1113 are independent of the voting model itself; this section concerns only the mechanism by which voting power is aggregated and counted.

The DAO MAY, through a standard on-chain governance proposal, upgrade to alternative voting systems, including but not limited to:
- stake-weighted or delegated stake models
- governance tokens with transparent, non-allocative issuance
- quadratic voting
- identity-verified or attestation-based models
- hybrid combinations of the above

Any upgrade to the voting model:
- MUST be proposed and approved through the ECFP governance process
- MUST meet the quorum, approval threshold, and timelock requirements established by the DAO
- MUST respect the no premine, no privileged allocation, no retroactive advantage principles defined in ECIP-1113
- MUST NOT introduce centralized gatekeepers, trusted third parties, or off-chain discretionary authority

Changes to the voting model SHALL NOT modify, weaken, or bypass the execution requirements of the Olympia Treasury defined in ECIP-1112.
All disbursements remain subject to:
- the hash-bound execution model (ecfpId, recipient, amount, metadataCID, chainid), and
- authorization exclusively through the Governor → Timelock → Executor pipeline.

Voting model flexibility enables long-term governance evolution while preserving the immutability, neutrality, and isolation of the Treasury.

#### Child-DAO ECFPs for Infrastructure Spending

To streamline recurring or infrastructure-critical funding (e.g., client maintenance, public RPC services, security audits), the Olympia DAO MAY define Child-DAO ECFP categories through standard governance as described in ECIP-1113.

Child-DAOs are application-layer helper contracts with scoped responsibilities.
They DO NOT possess independent spending authority and DO NOT interface with the Treasury directly.

Typical infrastructure domains include:
- Client DAO — Maintains protocol clients, reviews CVEs, performs releases, and ensures consensus alignment.
- Infra DAO — Manages RPC endpoints, explorers, indexers, load balancers, and DevOps operations.
- Security DAO — Coordinates audits, formal verification, fuzzing, incident response, and bounty programs.

##### Child-DAO Responsibilities

Each Child-DAO:
- Is deployed as a modular contract under authority granted by the main DAO.
- MAY coordinate domain-specific workstreams, contributors, and milestones.
- Submits ECFPs to the main DAO on a scheduled or recurring basis (e.g., monthly, quarterly).
- Operates only within the scope defined by main DAO proposals (e.g., budget ceilings, reporting requirements).
- Publishes periodic progress and expenditure reports linked to the metadata of the associated ECFPs.
- MAY be renewed, modified, or sunset via new main DAO proposals.

Child-DAOs exist to organize work, NOT to control funds.

##### Benefits of the Child-DAO Model
- Predictable, depoliticized funding for mandatory ecosystem operations
- Reduced governance overhead for non-controversial maintenance tasks
- Clear accountability through standardized event logging, periodic reports, and recurring ECFPs
- Minimal surface area by isolating domain responsibilities

##### Governance Requirements

To preserve Treasury immutability and governance isolation:
- All disbursements from the Olympia Treasury MUST be authorized by the main DAO using the standard ECFP lifecycle defined in this ECIP.
- All Treasury calls MUST execute through the main DAO’s authorized Executor, using the hash-bound disbursement tuple
 (ecfpId, recipient, amount, metadataCID, chainid)
 required by ECIP-1112.
- Child-DAO proposals MUST follow the same lifecycle and constraints as all other ECFPs:
- Draft → Active → Approved → Queued → Executed
- subject to quorum, threshold, and timelock rules
- Child-DAOs SHALL NOT:
- hold keys, multisigs, or privileged authority
- execute Treasury withdrawals
- bypass the Governor → Timelock → Executor pipeline
- create independent budgets outside ECFP governance
- impose off-chain or discretionary approval processes

Child-DAOs MAY streamline coordination, but only the main DAO governs funds.
Their sole purpose is to bundle repetitive or domain-specific work into clearly structured ECFPs that the community can evaluate, approve, or reject.

#### Governance Scope

The Ethereum Classic Funding Proposal (ECFP) process is the exclusive, on-chain mechanism for authorizing all disbursements from the Olympia Treasury, as defined in ECIP-1112.
This includes, but is not limited to:
- core protocol development
- emergency or contingency funding
- recurring maintenance or operational budgets
- multi-phase or milestone-based grant programs

The Olympia DAO, defined in ECIP-1113, SHALL be the only governance-authorized contract permitted to initiate Treasury withdrawals.
All Treasury movements MUST:
- be authorized exclusively through successful DAO proposals following the ECFP lifecycle,
- be executed through the Governor → Timelock → Executor pipeline,
- use the hash-bound disbursement tuple
 (ecfpId, recipient, amount, metadataCID, chainid)
 required for validation under ECIP-1112, and
- be immutably enforced by the Treasury contract’s internal logic.

Treasury access is immutable, governance-isolated, and non-bypassable.
No off-chain multisig, committee, foundation, service provider, or discretionary process MAY override, initiate, or modify Treasury disbursements.

The DAO MAY define proposal subtypes (e.g., operational budgets, recurring maintenance proposals, treasury management ECFPs) with domain-specific eligibility criteria or workflows, provided they adhere to:
- quorum
- approval thresholds
- voting delays and voting periods
- timelock requirements

All disbursements MUST remain subject to the standard ECFP lifecycle and the Treasury’s hash-bound validation model.
No Treasury funds MAY be allocated, redirected, or disbursed outside the ECFP process.

Additional governance safeguards MAY include:
- supermajority thresholds for sensitive funding categories
- co-signing or multi-step execution for large disbursements
- staggered execution timelines for additional oversight

These safeguards MUST be implemented via on-chain governance and SHALL NOT introduce privileged actors or discretionary authority.

#### Legal Interface: Ethereum Classic DAO LLC

To support fiat disbursements and necessary administrative compliance, the Ethereum Classic community MAY operate an external legal interface: the Ethereum Classic DAO LLC, a Wyoming-registered entity established under the Wyoming DAO LLC Act.

The Ethereum Classic DAO LLC exists purely as an off-chain administrative executor, and SHALL remain strictly subordinate to on-chain governance.
It holds no authority, implicit or explicit, over the Olympia Treasury or the ECFP process.

##### Scope and Responsibilities

The Ethereum Classic DAO LLC SHALL operate solely as a legal execution proxy for approved on-chain ECFPs.
It SHALL:
- execute only those actions explicitly authorized by a successful DAO proposal,
- follow the exact parameters specified in the approved proposal’s metadata, and
- perform no evaluative, filtering, or discretionary decision-making.

Permissible administrative tasks include:
- fiat currency conversion
- contractor onboarding and compliance (e.g., KYC, W-9/W-8BEN collection)
- tax reporting and regulatory filings
- delivery of contractual documents tied to approved ECFPs

All such actions MUST correspond directly to an approved ECFP and MAY NOT add, modify, or interpret requirements beyond those set by on-chain governance.

##### Traceability and Hash-Bound Consistency

All fiat-related disbursements MUST:
- correspond to a hash-bound proposal
 (ecfpId, recipient, amount, metadataCID, chainid)
 as required by ECIP-1112,
- be fully traceable to the same metadata used for on-chain execution, and
- be included in publicly accessible financial reports.

These requirements ensure that off-chain administrative actions precisely mirror their on-chain counterparts, preventing drift, reinterpretation, or discretionary alteration.

##### Transparency and Reporting

The LLC SHALL publish periodic public reports summarizing:
- donation receipts
- contractor onboarding logs (to the extent legally permissible)
- administrative cost summaries
- fiat conversion records and dates
- corresponding ECFP identifiers for every off-chain disbursement

These reports MUST align with the underlying hash-bound metadata to maintain auditability.

##### Prohibited Actions

The Ethereum Classic DAO LLC MUST NOT:
- hold or control Treasury private keys
- initiate, authorize, or route Treasury disbursements
- veto, reinterpret, or modify approved ECFPs
- circumvent the Governor → Timelock → Executor pipeline
- combine protocol-level Treasury funds with donor or operational funds
- introduce off-chain custody, signers, or multisig authority over on-chain funds
- exercise governance influence or serve as a gatekeeper

The LLC’s role is purely administrative, never authoritative.

##### Governance and Oversight
- DAO participants MAY, through standard governance, reassign LLC administrative roles or rotate signers via term-limited elections.
- The LLC’s scope and mandate SHALL remain narrow, revocable, and strictly limited to administrative facilitation.
- No LLC action MAY supersede, delay, or contradict an approved ECFP or its hash-bound execution parameters.

The LLC exists only to extend on-chain decisions into the off-chain legal and fiat world, without altering the immutability, neutrality, or decentralization of the Olympia Treasury.

#### Donation Handling and Segregation

The Ethereum Classic DAO LLC MAY receive off-chain donations in fiat or cryptocurrency.
Such donations are optional, external to the protocol, and MUST remain strictly segregated from the protocol-level Olympia Treasury defined in ECIP-1112.

All donations:
- MUST be accounted for separately from protocol-level Treasury funds, both in off-chain accounting and in any on-chain representations.
- SHOULD be routed through on-chain mechanisms when feasible, using the hash-bound execution tuple
 (ecfpId, recipient, amount, metadataCID, chainid)
 for transparency and auditability.
- MUST be spent only via DAO-approved ECFPs if routed through governance.
- MUST be included in public financial reports, regardless of whether the disbursement was routed through governance.

Use of donation funds outside the ECFP process MUST be:
- Optional — donors may choose whether to route donations through on-chain governance.
- Transparent — all off-chain disbursements MUST be publicly reported.
- Governance-neutral — donor funds MUST NOT influence or override on-chain governance decisions.
- Strictly separated — protocol-level Treasury funds and external donations MUST NOT be co-mingled.

Donated funds MUST NOT:
- override or preempt approved ECFPs,
- create preferential or accelerated execution paths,
- introduce discretionary spending authority,
- compromise governance neutrality, or
- alter or weaken Treasury access controls.

All donation handling SHALL be publicly verifiable and governed by a narrow, limited administrative mandate, consistent with ECIP-1113.

Informative Note:
The DAO MAY define a “Donation ECFP” format for donors wishing to align contributions with specific initiatives.
Donation ECFPs MUST follow the same lifecycle, quorum, threshold, and timelock rules as all other Treasury disbursements.

##### Strategic Donors and Institutional Funders

The ECFP framework — combined with the administrative interface provided by the Ethereum Classic DAO LLC — enables transparent participation by institutional or centralized donors, including:
- centralized exchanges
- mining pools and ASIC manufacturers
- investment trusts and ETF managers
- infrastructure and service providers (RPC, explorers, hosting)
- Web3 venture firms and protocol builders

These entities may support the Ethereum Classic ecosystem without compromising decentralization or governance neutrality.

Key properties that enable institutional participation:
- Legal execution:
 The DAO LLC provides a compliant mechanism to perform off-chain administrative tasks required for fiat-related portions of approved ECFPs.
- Transparent governance:
 All disbursements — whether protocol-level or donor-funded — require on-chain DAO approval and are immutably recorded.
- Auditable funding:
 When routed through the Treasury, donor-funded disbursements use the hash-bound execution tuple
 (ecfpId, recipient, amount, metadataCID, chainid)
 ensuring traceability to the original proposal metadata.
- Optional alignment:
 Donors MAY submit or support Donation ECFPs to earmark contributions for specific workstreams.
 These proposals MUST follow the standard ECFP lifecycle with no preferential treatment.
- No privileged access:
 Institutional donors receive no special rights regarding Treasury access, voting power, or governance influence.

##### Protocol-Level Donors and Fee Forwarding (Composable DeFi Stack)

Olympia also supports opt-in protocol-level donations from EVM-native applications deployed on Ethereum Classic.
Smart contracts such as DEXs, lending markets, liquid staking systems, stablecoins, or yield platforms MAY voluntarily forward a percentage of fees, rewards, or revenue to the Olympia Treasury (ECIP-1112).

This creates a self-reinforcing public-goods funding loop:
Increased protocol usage → higher fee forwarding → greater Treasury capacity → improved infrastructure → more users and applications

This mechanism mirrors established EVM patterns (e.g., Lido, Balancer, Aura, RocketPool) while preserving Ethereum Classic’s neutrality and opt-in ethos.

### Benefits
- Composable, voluntary participation by DeFi protocols
- Transparent on-chain donation flows
- Sustainable infrastructure funding
- Ecosystem-wide positive feedback loop

### Governance and Execution Requirements
- Once forwarded to the Treasury, such funds MUST be disbursed only via ECFPs approved through the main DAO.
- All disbursements MUST use the hash-bound execution tuple
 (ecfpId, recipient, amount, metadataCID, chainid)
 defined in ECIP-1112.
- These ECFPs MUST follow the same:
- quorum
- approval threshold
- voting period
- timelock
- execution pathway (Governor → Timelock → Executor)
 as all other Treasury allocations.
- Donation sources SHOULD be disclosed by the donating protocol and included in DAO financial reports.
- A standardized Donation ECFP format MAY be used to align donated funds with specific deliverables or KPIs.

This opt-in structure allows decentralized and centralized protocols alike to support the ecosystem without introducing privileged access, governance influence, or Treasury bypasses.

### Rationale

The Ethereum Classic Funding Proposal (ECFP) framework completes a four-part architecture that enables sustainable, decentralized protocol funding for Ethereum Classic:
1. ECIP-1111 — Redirects BASEFEE into a protocol-native revenue stream.
2. ECIP-1112 — Deploys an immutable, governance-isolated Treasury to custody that revenue.
3. ECIP-1113 — Establishes Olympia DAO as the sole authorized executor of Treasury disbursements.
4. ECIP-1114 — Defines the standardized, permissionless process for proposing, reviewing, voting on, and executing those disbursements.

#### Why This Is Necessary

Prior to Olympia, Ethereum Classic funding relied on centralized foundations, corporate sponsors, or informal donor arrangements. These sources were often opaque, inconsistent, or vulnerable to gatekeeping, and could not guarantee stable support for critical public infrastructure such as clients, RPC endpoints, explorers, audits, and developer tooling.

The ECFP process provides a durable replacement by:
- Codifying a transparent, rules-based allocation mechanism for all Treasury funds.
- Using ECIP-1112’s hash-bound execution model
 (ecfpId, recipient, amount, metadataCID, chainid)
 to ensure accountability, integrity, and replay protection.
- Requiring that all spending decisions flow through Olympia DAO as defined in ECIP-1113, subject to quorum, approval thresholds, and timelock safeguards.
- Offering a predictable, reproducible framework for proposers and voters, reducing ambiguity and governance fatigue.
- Preserving upgrade flexibility so governance parameters can evolve without modifying the core funding mechanism.

By separating concerns across four ECIPs — revenue (1111), custody (1112), governance execution (1113), and proposal lifecycle (1114) — the architecture remains modular, auditable, and resilient.

This ensures that Ethereum Classic’s protocol-level funding is:
- Decentralized — no single entity controls fund access.
- Immutable — Treasury disbursement rules cannot be bypassed or altered off-chain.
- Transparent — all proposals, votes, and disbursements are verifiable on-chain.
- Sustainable — funding grows proportionally with network usage, without inflation.

#### Minimal, Scalable, and Governance-Neutral

The ECFP framework defines a minimal but robust set of rules that scale naturally with ecosystem growth:
- Proposals MAY represent one-time grants, multi-milestone programs, or recurring maintenance budgets.
- The system does not require constant activity or continuous funding.
- Proposal formats and workflows can evolve via governance without modifying the underlying Treasury or execution logic.

This avoids reliance on discretionary or foundation-driven grantmaking and replaces it with transparent, permissionless, rule-based Treasury governance.

The ECFP process integrates directly with the Olympia Treasury (ECIP-1112) and Olympia DAO (ECIP-1113), ensuring that all disbursements are authorized on-chain and executed through the immutable governance pipeline.

#### Governance-Aligned Funding Infrastructure

The ECFP process formalizes a community-controlled mechanism for allocating protocol-level funds. Compared to prior funding models, it provides:
- Transparency — Every lifecycle event (submission, voting, execution) is recorded on-chain.
- Inclusiveness — Any contributor MAY submit a proposal without prior affiliation, reputation, or political capital.
- Predictability — Standardized proposal structure and lifecycle reduce ambiguity for both proposers and reviewers.
- Upgradeability — The ECFP process is governance-agnostic: it supports modular upgrades to the DAO, voting logic, or templates without altering the ECFP standard itself.

#### Key Design Objectives
- Clarity and Accountability
 Structured templates, explicit execution parameters, and required deliverables ensure that intent and outcomes remain well-defined and enforceable.
- Transparency and Auditability
 All metadata, voting records, and disbursement events MUST be stored or emitted on-chain to ensure full public verifiability.
- Openness and Meritocracy
 Participation in both proposal creation and voting is permissionless and not gated by token balances, off-chain influence, or privileged membership.
- Governance Modularity
 The ECFP lifecycle is defined independently of any specific voting mechanism or governance token. Future upgrades can adjust governance parameters without altering the funding process or Treasury logic.
- Alignment with Ethereum Classic Principles
 The ECFP process reflects ETC’s core values: immutability, decentralization, credible neutrality, and resistance to centralized capture. It replaces opaque, foundation-based funding with transparent, on-chain, rules-based allocation.

### Related Work

The ECFP process aligns Ethereum Classic with established, DAO-governed funding models used across the broader EVM ecosystem.
These systems demonstrate the viability of transparent, on-chain treasury governance, standardized proposal lifecycles, and immutable execution logic.

Examples include:
- Arbitrum (AIP Framework) — Token-holder governance approves treasury disbursements via structured improvement proposals and a standardized review process.
- Optimism (RetroPGF) — A bicameral governance system allocates funds based on demonstrated public goods impact, using transparent evaluation and execution rules.
- Celo Community Fund — A portion of transaction fees routes directly to a community-governed treasury, funding grants through milestone-based oversight.
- Ronin DAO — Redirects EIP-1559 BASEFEE into a DAO-controlled treasury for infrastructure and ecosystem support, paralleling the revenue model defined in ECIP-1111.
- Mantle Governance — Manages a modular, DAO-controlled treasury sourced from sequencer revenue, with delegated authority for domain-specific funding.
- Polygon Funding Councils — Operate delegated, domain-specific treasuries funded by sequencer fees, with structured workflows for proposals and ecosystem grants.

Across these examples, several common design principles emerge:
- Transparent, on-chain governance controls all treasury disbursements.
- Immutable execution paths ensure funds move only through DAO-approved actions.
- Standardized proposal formats and workflows reduce ambiguity and centralization risk.
- Revenue captured at the protocol or sequencer layer provides sustainable funding for public goods.

Olympia applies these proven governance patterns to Ethereum Classic’s Proof-of-Work environment by combining:
- Sustainable, consensus-layer revenue from ECIP-1111
- Immutable, governance-isolated custody via ECIP-1112
- Sole-executor, permissionless governance defined in ECIP-1113
- Standardized, hash-bound proposal execution through ECIP-1114

### Implementation

#### 1. Proposal Submission
- Proposal submission is permissionless. Any Ethereum Classic address MAY submit an ECFP via the Olympia DAO interface, subject to governance parameters defined in ECIP-1113 (e.g., delays, thresholds, quorum).
- Optional Sybil-resistance modules (e.g., BrightID, Gitcoin Passport, Proof of Humanity) MAY be adopted by DAO vote.
- A dedicated ECFP submission repository SHALL be maintained at:
 https://github.com/ethereumclassic/ECFPs
- Each ECFP MUST include:
- Sequential ECFP number
- Title and rationale
- Requested funding amount (denominated in ETC / wei)
- Recipient address
- Milestone schedule or disbursement structure
- Off-chain metadata pointer (IPFS CID, Arweave URL, etc.)
- Metadata MUST be:
- Content-addressed
- Immutable and verifiable
- Referenced on-chain via its CID or equivalent digest
- ECFPs SHOULD follow the official Markdown template:
 https://github.com/ethereumclassic/ECFPs/blob/main/ecfp-template.md
- ECFPs MAY include supplemental materials:
- GitHub repositories
- Technical specifications
- Mockups / diagrams
- Community endorsements

To ensure consistent hash derivation across on-chain contracts, scripts, wallets, indexers, and governance dashboards, implementations SHOULD use the canonical encoding for the ECFP payout identifier.
The library below illustrates the exact tuple and encoding order used to derive payoutId from (ecfpId, recipient, amount, metadataCID, chainid) as required by ECIP-1112. Off-chain clients MUST replicate this logic exactly.

#### 2. On-Chain Registry and Governance

The Olympia DAO smart contracts SHALL maintain an ECFP registry storing:
- Submission timestamp
- Proposer address
- Derived hash-bound identifier
- Voting results
- Final lifecycle state (Draft, Active, Approved, Rejected, Executed, Expired)

Governance contracts MUST:
- Enforce voting delays, voting periods, thresholds, and quorum
- Capture voting power using snapshot blocks to prevent manipulation after activation
- Emit standardized events (e.g., ProposalSubmitted, ProposalActivated, ProposalExecuted) for indexing
- Forward all execution payloads through the Governor → Timelock → Executor pipeline as required by ECIP-1113

#### 3. Execution and Disbursement
- After approval and timelock maturity, the DAO’s sole authorized Executor SHALL trigger a Treasury disbursement.
- Execution occurs by forwarding an opaque {targets, values, calldatas} payload to the Treasury, as defined in ECIP-1113.
- All disbursements MUST use the hash-bound execution model defined in ECIP-1112:
 (ecfpId, recipient, amount, metadataCID, chainid)
- Execution MUST bind:
- recipient
- amount
- metadataCID
 exactly as provided in the proposal submission.
- The Treasury and Executor SHOULD emit standardized ProposalExecuted events containing:
- ECFP ID
- Hash-bound identifier
- Recipient
- Amount
- Timestamp
- Disbursement patterns MAY include:
- One-time transfers
- Milestone-based disbursements
- Recurring operational budgets via multiple ECFPs
- Escrow-based or stream-based payout contracts

The example below illustrates the final step of the Olympia execution pipeline, where the Executor forwards a governance-approved disbursement to the Treasury (ECIP-1112).
The Executor does not derive payoutId, does not validate metadata, and does not issue any funds itself.
These responsibilities are enforced respectively by ECIP-1114 (proposal registry), ECIP-1113 (governance), and ECIP-1112 (Treasury).
This example clarifies only the expected call surface during execution.

#### 4. Transparency Dashboard

A public-facing dashboard SHALL provide:
- Active, approved, rejected, and executed proposal lists
- DAO voting outcomes and participation metrics
- Treasury balances and disbursement history

The dashboard MUST:
- Be open-source
- Mirror on-chain state verifiably
- Use standardized DAO and Treasury events for indexing

#### 5. Community Review and Deliberation
- Proposals SHOULD undergo informal discussion prior to activation.
- Recommended venues include:
- GitHub discussion threads
- Ethereum Classic Discord
- The ECIP discussion forum
- Community moderators MAY assist with formatting or technical feedback.
- Moderators SHALL NOT possess authority to approve, veto, or gate proposals.

#### Testing and Mainnet Rollout
- All governance and Treasury contracts SHALL be deployed and tested first on the Mordor Testnet.
- Mainnet activation SHALL require:
- Successful simulation of the full ECFP lifecycle
- Successful simulation of hash-bound execution
- Community review
- Independent third-party audits

### Backwards Compatibility

The Ethereum Classic Funding Proposal (ECFP) process is implemented entirely at the application layer through smart contracts.
It introduces no changes to consensus rules, fork choice, block structure, transaction formats, opcode behavior, or EVM semantics.
As a result, ECIP-1114 is fully backward-compatible with all existing wallets, tooling, and deployed contracts.

#### Compatibility Notes
- No Consensus-Layer Modifications
 ECIP-1114 does not alter block validation, gas accounting, transaction encoding, or any consensus-critical rules.
 Nodes that upgrade to support the Olympia governance suite remain in full consensus with the network.
- Voluntary Participation
 Participation in ECFP governance is optional.
 Nodes, miners, and users are not required to submit proposals or vote in order to remain in consensus.
- Application-Layer Isolation
 ECFP logic is confined to governance contracts and does not interfere with unrelated smart contracts or dApps.
 All pre-existing contracts continue to function without modification.
- Client Compatibility
- Clients implementing ECIP-1111, ECIP-1112, ECIP-1113, and ECIP-1114 will remain in consensus and be capable of participating fully in Olympia governance.
- Clients that do not implement ECIP-1111 will diverge from the canonical chain at the activation block, as BASEFEE redirection is a consensus-layer change.
- Clients implementing ECIP-1111 and ECIP-1112, but not ECIP-1113/1114, remain in consensus but cannot submit, vote on, or execute governance actions; they simply validate them as ordinary transactions.
- Treasury Execution Requirements
 To construct and broadcast valid Treasury disbursement transactions, a client MUST support:

 Clients lacking these components may still observe governance transactions but cannot originate or process them meaningfully.
- State and Data Integrity
 All proposal metadata, voting records, and execution events are stored in governance-layer contract storage.
 No historical blockchain state is altered, and no migration or pruning of existing state is required.

By isolating governance logic from protocol consensus, the ECFP framework integrates cleanly with the Ethereum Classic stack while preserving base-layer stability, determinism, and long-term security.

### Security Considerations

Although ECIP-1114 introduces no changes to Ethereum Classic’s consensus or EVM semantics, it defines a critical application-layer mechanism for allocating protocol-level funds.
The security of the ECFP lifecycle depends on the correctness, immutability, and isolation of the Treasury (ECIP-1112) and governance framework (ECIP-1113).

The following categories summarize the required security properties and safeguards.

#### 1. Metadata and Proposal Integrity

The hash-bound execution identifier derived from
(ecfpId, recipient, amount, metadataCID, chainid)
serves as the binding link between the on-chain proposal and its off-chain metadata.
This ensures disbursements cannot be altered, replayed, or redirected without invalidating the hash.

All ECFPs MUST:
- Embed a verifiable content hash (IPFS CID, Arweave digest, etc.).
- Store metadata immutably in a content-addressed system.
- Use globally unique ecfpId values.
- Include chainid (and optionally domain separators) for replay protection across forks or testnets.

Additional Integrity Requirements:
- Content-Addressed Metadata
 Prevents retroactive edits or hidden changes.
- Immutable References
 Voters MUST be able to confirm that metadata has not changed after submission.
- Replay Protection
 The chain ID MUST be part of the encoded hash to prevent cross-network execution.

#### 2. Treasury and DAO Contract Safeguards
- Execution Logic Isolation
 The Treasury SHALL NOT parse proposal metadata.
 It validates only the hash-bound tuple and releases funds exclusively in response to calls from the authorized DAO Executor.
- Strict Call Permissions
 The Treasury MUST reject all calls from EOAs or unauthorized contracts.
- Deterministic Execution Path
 All disbursements MUST follow the immutable execution rules defined in ECIP-1112, with no arbitrary logic or branching.
- Immutable Lifecycle States
 Once an ECFP enters Active, its parameters MUST NOT change.
- Event Logging
 DAO and Treasury contracts SHOULD emit standardized events to support independent indexing and audit tools.

#### 3. Governance Process Risks
- Governance Capture
 Mitigated through quorum thresholds, timelock delays, optional delegated or reputation-based mechanisms, and transparent upgrade paths.
- Replay Defense
 Governance payloads MUST include domain separation and unique proposal identifiers.
- Safe Governance Upgrades
 Any upgrade to the DAO MUST:
- Be proposed and approved on-chain
- Undergo third-party audits
- Be subject to timelock enforcement
- NOT alter Treasury immutability

#### 4. Execution and Client Consistency Risks
- Client Validation
 Clients MUST verify that execution payloads match approved governance decisions.
 This prevents inconsistent local state or misinterpretation of Treasury calls.
- Reentrancy and Logic Review
 The Treasury and governance contracts MUST undergo extensive security review, including:
- static analysis
- fuzzing
- formal verification (where possible)
- third-party audits
- Proposal Manipulation Prevention
 Achieved through:
- immutable metadata hashing
- minimum draft review periods
- off-chain discussion and community oversight
- Funding Accountability
 Milestone-based or vesting-based disbursements SHOULD be used for large or long-term proposals.

#### 5. Spam Resistance and Participation Gating
- Sybil Attack Mitigation
 The DAO MAY adopt optional, permissionless sybil-resistance modules such as:
- refundable deposits
- submission cooldowns
- decentralized identity attestations
- Preservation of Permissionlessness
 Any gating mechanism MUST remain:
- modular
- governance-controlled
- non-discretionary
- free of centralized approval or gatekeeper authority

### Security Considerations Summary

ECIP-1114 establishes a transparent, hashed, and governance-controlled framework for protocol-level funding.
Security properties derive from:
- immutable metadata and content-addressed references
- hash-bound execution with replay protection
- strict Treasury call permissions (ECIP-1112)
- mandatory governance flow through Governor → Timelock → Executor (ECIP-1113)
- standardized event logging and auditable state transitions
- formal review, testnet deployment, and independent audits

All components MUST be deployed to the Mordor Testnet for full lifecycle simulation and reviewed publicly prior to mainnet activation.

### Related ECIPs in the Olympia Upgrade

ECIP-1114 is one component of a coordinated four-ECIP architecture that introduces sustainable, decentralized, and transparent protocol-level funding to Ethereum Classic. Each ECIP addresses a distinct layer of the system and is designed to operate independently while forming a cohesive whole.
- ECIP-1111 — Olympia EVM and Protocol Upgrades
 Introduces EIP-1559 and EIP-3198 to Ethereum Classic and redirects BASEFEE to the Treasury instead of burning it, creating a protocol-native revenue stream.
- ECIP-1112 — Olympia Treasury Contract
 Specifies the immutable, governance-isolated Treasury contract that receives BASEFEE revenue and enforces hash-bound, deterministic disbursement rules.
- ECIP-1113 — Olympia DAO Governance Framework
 Defines the decentralized governance architecture and the sole authorized execution path (Governor → Timelock → Executor) for Treasury withdrawals.
- ECIP-1114 — Ethereum Classic Funding Proposal Process
 Establishes the standardized, permissionless ECFP format for requesting Treasury funds, including metadata requirements, lifecycle states, and hash-bound execution parameters.

### Interdependency Summary
- ECIP-1111 — Creates the protocol-level funding source (BASEFEE redirection).
- ECIP-1112 — Provides immutable custody and enforcement of hash-bound disbursement rules.
- ECIP-1113 — Establishes the governance executor that authorizes disbursements.
- ECIP-1114 — Defines the proposal lifecycle and metadata standards required for all disbursements.

These ECIPs are designed for modular activation:
- ECIP-1111 + ECIP-1112 may be activated first to begin accumulating Treasury revenue.
- ECIP-1113 + ECIP-1114 may be deployed subsequently to enable full on-chain governance, voting, and controlled Treasury execution.

Together, ECIP-1111 through ECIP-1114 form a complete, modular, and upgradeable funding framework for Ethereum Classic.

### Copyright

Copyright and related rights waived via
CC0

### Appendix: EVM Precedents for Funding Proposal Processes

The Ethereum Classic Funding Proposal (ECFP) framework in ECIP-1114 draws on established patterns from other EVM-governed treasuries. These examples demonstrate that transparent, standardized, and on-chain managed funding processes can scale to large communities and significant treasury sizes while maintaining decentralization and auditability.

#### Funding Process Precedents

| Network | Funding Process Name | Key Process Steps | Relevance to ECFP Design |
|----------------|-------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Arbitrum | Arbitrum Improvement Proposal (AIP) | Forum draft → Community review → Temperature check → On-chain binding vote → Treasury execution | Multi-stage lifecycle mirrors ECFP’s Draft → Active → Approved → Executed flow. Ensures robust review before binding execution. |
| Optimism | Retroactive Public Goods Funding (RPGF) | Application → Evaluation → Impact measurement → Retroactive payout | Validates support for milestone or impact-based disbursements; informs optional multi-phase ECFPs. |
| Gitcoin DAO| Grants Rounds & Quadratic Funding | Project application → Matching pool setup → Quadratic voting → Payout distribution | Highlights value of sybil-resistance tools and broad participation; aligns with optional ECFP anti-spam and identity-attestation modules. |
| MakerDAO | Maker Improvement Proposals (MIPs) | Proposal submission → Domain facilitator review → Governance polling → On-chain executive vote → Budget allocation | Standardized templates and structured reviews map to ECFP’s formalized metadata and optional draft review periods. |
| Aave DAO | Aave Governance Proposals (AGPs) | Forum discussion → Snapshot signaling → On-chain vote → Smart contract execution | Demonstrates utility of off-chain signaling prior to binding action; relevant to ECFP’s permissive Draft stage. |
| Celo | Community Fund Governance | Proposal creation → Stake requirement to submit → On-chain vote → Treasury release | Shows how stake-based or threshold-based submission gating can reduce spam; aligns with optional ECFP participation thresholds. |
| Mantle | Mantle Improvement Proposals (MIPs) | MIP drafting → Community discussion → DAO vote → Treasury execution | Parallels ECFP’s direct governance-to-treasury path and modular proposal categories. |
| Polygon | Polygon Funding Proposal (PFP) Framework | GitHub draft → Community discussion → Editor review → Soft consensus → Accepted proposals routed to treasury workflows | Highlights transparent, version-controlled proposal histories; relates to ECFP’s standardized formatting and repository-driven archival. |

#### Observations
- Structured Lifecycles
 Most ecosystems employ multistage proposal processes with review, signaling, and execution phases.
 ECFP reflects this with its Draft → Active → Approved → Executed states.
- Community Review Before Voting
 Nearly all systems incorporate pre-vote discussion.
 ECFP includes an optional draft period to encourage early feedback and reduce governance errors.
- On-Chain Finality
 Every listed system culminates in a binding on-chain action—similar to ECFP’s requirement that Treasury withdrawals must pass through the hash-bound execution model
 (ecfpId, recipient, amount, metadataCID, chainid).
- Sybil Resistance & Submission Protection
 Many ecosystems employ stake deposits, identity attestations, or rate limits to reduce spam.
 ECFP includes these mechanisms as optional, governance-controlled modules.
- Milestone & Impact-Based Funding
 Several treasuries allocate funds in tranches or based on completed deliverables.
 ECFP natively supports milestone-based or multi-phase funding structures.

By adapting these proven patterns to Ethereum Classic’s design principles—immutability, decentralization, credible neutrality—ECIP-1114 delivers a funding process that is both compatible with established EVM governance practices and purpose-built for ETC’s long-term sustainability.

# Abstract
Imagine how we can use ETC having oracle features which can assist Dapps and ERC-223 tokens to accomplish their goals.

Although decentralized oracles rely on a source of information, it does not have to be from a centralized source.

If an oracle is able to rely on multiple sources and is able to verify which information is the correct one, wouldn't it still work in a manner that is decentralized as possibly can?

An example would be academia sources for a research paper, we have multiple sources that cannot be used for reliable information such as journals and memoirs.

However, with a decentralized oracle, it can then verify the reliability of an information and check if the sources have a track history of reliability such as from an academic institute.

Information that is considered unreliable such as a journal or memoir can be verified to be reliable if the journalist has a history of accuracy and reliability.

If the person who wrote the memoir is the primary source and has the evidence through other reliable sources that he is there, then the oracle can consider his memoir as a reliable source of information.

Afterwards, then feed it to the smart contract to come with a reliable answer of what actually happened.

## Motivation
To make better smart contracts even smarter than they are, the decentralized oracle can feed reliable information to the smart contract.

A integrated decentralized oracle is useful for the Ethereum Classic network because relying on a third party for oracles means they can modify the code to suit the output.

Integrated decentralized oracles create a tool that can better assist in problem solving beyond just academia, but has real life use cases that can be used for derivatives markets, gambling, accounting, and finance.

An Ethereum Classic Decentralized oracle can be used not only for ETC projects, but can be used for other smart projects.
Ethereum Classic's precedent as the first to integrate oracles and smart contracts means other smart contract platforms would look for an oracle solution that specifically address their issues.

## Specification

### Decentralized Oracle Dapp

By becoming a Dapp, the decentralized Oracle can work independent of the network.
This can be off-chain and help assist the smart contract.

### Oracle Function as Part of ETC Network
Ethereum Classic can run the oracle within the limitations of its network and the smart contract.
The oracle becomes just a tool of a smart contract to decide the information to input to the smart contract.

### The Oracle as a Separate Layer or Separate Network

The oracle can act as a network, similar to the Lightening Network for Bitcoin, but instead the oracle network would act to make smart contracts more efficient and cheaper.

By using the decentralized oracle, less waste of transactions on the Ethereum Classic network would occur.
Because information is sorted from the decentralized oracle, the smart contract can function more efficiently.

# Rationale
To further provide reliable information to the smart contract and to solve real world problems.
This would create a greater decentralized network that provides reliable answers.

# Implementation
All these examples of how we can use a decentralized oracle can be run with ETC gwei.
Whether it will be a Dapp or as a part of the ETC or as a separate network/layer, they will use ETC gwei to power the decentralized oracle.

This document records feature upgrades that have been applied in
Ethereum Classic network mainnet.

| Version and Code Name | Block No. | Released | Incl EIPs | Specs | Blog |
|----------------------------------------------|-----------|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------|
| Spiral Shanghai | 19250000 | 2024-02-04 | EIP-3651
 EIP-3855
 EIP-3860
 EIP-6049 | ECIP-1109 | |
| Mystique London | 1452500 | 2022-02-12 | EIP-3529
 EIP-3541 | ECIP-1104 | | |
| Magneto Berlin | 13189133 | 2021-07-23 | EIP-2565
 EIP-2929
 EIP-2718
 EIP-2930 | ECIP-1103 | | |
| Thanos | 11700000 | 2020-11-28 | ECIP-1099 | | | |
| Phoenix Istanbul | 10500839 | 2020-06-01 | EIP-152
 EIP-1108
 EIP-1344
 EIP-1884
 EIP-2028
 EIP-2200 | ECIP-1088 | | |
| Agharta Constantinople+Petersburg | 9583000 | 2020-01-11 | EIP-145
 EIP-1014
 EIP-1052 | ECIP-1056 | | |
| Atlantis Byzantium | 8772000 | 2019-09-12 | EIP-100
 EIP-140
 EIP-196
 EIP-197
 EIP-198
 EIP-211
 EIP-214
 EIP-658 | ECIP-1054 | |
| Defuse Difficulty Bomb | 5900000 | 2018-05-29 | ECIP-1041 | | |
| Gotham | 5000000 | 2017-12-11 | ECIP-1017
 ECIP-1039 | | |
| Die Hard Spurious Dragon | 3000000 | 2017-01-13 | ECIP-1010
 EIP-155
 EIP-160 | | |
| Gas Reprice Tangerine Whistle | 2500000 | 2016-10-24 | EIP-150 | ECIP-1015 | |
| ~~DAO Fork~~ | 1920000 | 2016-07-20 | | HFM-779 | Blog |
| DAO Wars | aborted | aborted | | | Blog |
| Homestead | 1150000 | 2016-03-14 | EIP-2
 EIP-7
 EIP-8 | HFM-606 | Blog |
| Frontier Thawing | 200000 | 2015-09-07 | | | Blog |
| Frontier | 1 | 2015-07-30 | | | Blog |

### Abstract

Currently user accounts are represented in a manner that allows for any third party who know a user’s public account number to review all transactions and interactions associated with that account creating a linkable transaction history. While these addresses are good for transactions requiring psudeo-identity( contracts, tokens, etc), it is not ideal for standard user accounts. The purpose of a stealth addressing scheme is to create one-time addresses which are publicly unlinkable to the owner or any other one-time addresses and allow for only the recipient to link transactions and derive the secret key associated with the address. In short, with a privacy enhanced ethereum classic (ETC-PE) capable node a user can publish one address and receive publicly unlinkable payments as well as make traditional ethereum transactions. This type of cryptographic scheme is described in detail in the cryptonote whitepaper.

### Definitions

Private Key(yellowpaper: pr) is a standard elliptic curve private key: a ∈ [1, secp256k1n − 1].

Public Key (yellowpaper: pu) is a standard elliptic curve public key: a point pu = prG;

one-time keypair is a pair of private and public keys;

private user key is a pair (a, b) of two different private ec-keys;

public user key is a pair (A, B) of two public ec-keys derived from (a, b);

Public Spend Key is a standard elliptic curve public key: A = aG used to spend transactions

Public View Key is a standard elliptic curve public key: B = bG used to view transactions

Random private key random nonce where r ∈ [1, secp256k1n − 1];

Random public key is a standard elliptic curve public key: a point R = rG;

tracking key is a pair (a, B) of private and public ec-key (where B = bG and a 6= b);

standard address is a representation of a public user key given into human friendly string with error correction;

truncated address is a representation of the second half (point B) of a public user key given into human friendly string with error correction.

Standard Ethereum address(yellow paper: A(pr)) rightmost 160-bits of the Keccak hash of the corresponding ECDSA public key A(pr) = B96..255(KEC(ECDSAPUBKEY(pr)))

Contract Address rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the nonce. a ≡ B96..255(KEC(RLP((s, σ[s]n − 1)))

Transaction Extra DataAn unlimited size byte array specifying the input data of the message call, formally Td

### Stealth Address

Cryptonote whitepaper Figure 4

#### The Alice and Bob

 Alice wants to send a payment to Bob.

Alice= Private spend key (Prz)and Private View Key (Pry)

Alice= Public Address (Z,Y)

Bob = Public Address (A,B)

Bob = Private spend key (Pra)and Private View Key (Prb)

Alice and Bob know each others Public Address

#### Send Process

 Alice chooses a random private key r and calculates R = rG. r is no longer needed after this point, however it may be retained to prove Alice sent the transaction to a 3rd party. A new r should be used with every transaction. R is added to the transactions extradata prefixed with: halt code 0x00 and a version byte 01 to prevent accidental evm functioning and to allow for rapid lookup.

 Td=0x0001(R)

Alice then generates a stealth address P

P = KEC(rA)G+B

Where:

P is the final stealth address;

KEC is the hashing algorithm;

r is Alice’s random private key;

A is Bobs Public View key

G is the standard base point;

B is Bobs Public spend key

#### Receiving Process

Bob's ETC-PE node checks every transaction with his private key (a,b) and computes

P’ = KEC(aR)G+B

Where:

P’ is an address;

KEC is the hashing algorithm;

a is Bobs Private View Key

R is a transactions extra Data begingin with 0x0001

G is the standard base point;

B is Bobs Public spend key

If Alice’s transaction for with Bob as the recipient was among them:

aR = arG = rA and P’ = P

Bob can recover the corresponding one-time private key:

x = KEC(aR) + b, so as P = xG

Bob can spend this output at any time by signing a transaction with x.

### Rationale

Having both legacy, contract, and stealth account schema allows for additional privacy features to be incorporated into the ethereum classic ecosystem. The stealth account schema by themselves provide the benefit of a unique account per transaction, it is computationally non-trivial for a third party to determine Bobs true holdings.

Additional notes from Cryptonote white paper:

• When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: (a, B). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key p without Bob’s full private key (a, b). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.).

• In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose r or use any kind of zero-knowledge protocol to prove she knows r (for example by signing the transaction with r).

• If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key B, and the remaining part required by the protocol is derived from it as follows: a = Hs(B) and A = Hs(B)G. In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key b.

### Backwards Compatibility

This ECIP is applicable at the node/client level and has no effect on consensus. It is fully backwards compatible. Any node not upgrade to ETC-PE addressing will view the transactions as normal transactions with extra data. ETC-PE nodes should retain legacy addressing as well for interacting with contracts.

### Copyright

Copyright and related rights waived via CC0.

### Ref

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER EIP-150 REVISION, Dr. Gavin Wood, http://yellowpaper.io/
CryptoNote v 2.0, Nicolas van Saberhagen ,https://cryptonote.org/whitepaper.pdf

## 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.

## Abstract

ECIP-1121 documents the Ethereum execution-layer protocol specifications that Ethereum Classic execution clients implement in order to remain execution-client parallel with Ethereum, excluding fee-market governance and blob-based data availability mechanics.

This ECIP serves as the execution-layer bookend for the Olympia ECIP option set (ECIP-1111, ECIP-1112, ECIP-1113, ECIP-1114, ECIP-1115, ECIP-1116, ECIP-1117, ECIP-1118, ECIP-1119 and ECIP-1120), consolidating execution semantics that are independent of consensus, treasury policy, or data-availability design choices.

This ECIP documents and scopes execution-layer specifications for coordination purposes.
This document proposes the following blocks at which to implement these changes in the Ethereum Classic networks:

TBD on Mordor testnet
TBD on Ethereum Classic mainnet

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

## Motivation

Ethereum Classic has historically adopted a conservative, explicitly documented approach to protocol upgrades, as demonstrated in the Spiral and Mystique hard forks. Execution-layer compatibility with Ethereum improves tooling interoperability, client robustness, and auditability, while preserving Ethereum Classic’s Proof-of-Work consensus and economic neutrality.

Since Spiral and Mystique, and continuing through Ethereum’s Fusaka execution-layer upgrades, a set of execution client specifications has emerged that:
- Do not depend on Proof-of-Stake
- Do not mandate blob data availability
- Do not alter Ethereum Classic’s monetary or treasury policy

These execution semantics are already implemented or are directly implementable in Ethereum Classic execution clients. ECIP-1121 consolidates them into a single reference document.

## Scope

This ECIP:
- Applies to execution-layer behavior only
- Excludes fee market governance defined in the Olympia ECIP set
- Explicitly defers blob data availability mechanics
- Does not modify consensus rules
- Does not define activation blocks (TBD)

## Relationship to Prior ECIPs

ECIP-1121 is complementary to the following ECIPs:

| ECIP | Description | Included / Excluded |
|-----|-------------|------|
| ECIP-1111 | Olympia meta-specification | Included |
| ECIP-1112 | Treasury contract option | TBD |
| ECIP-1113 | Treasury governance option | TBD |
| ECIP-1114 | Funding flow option | TBD |
| ECIP-1115 | Treasury operational constraints | TBD |
| ECIP-1116 | Fee-handling alternative (draft) | TBD |
| ECIP-1117 | Fee-handling alternative (draft) | TBD |
| ECIP-1118 | Fee-handling alternative (draft) | TBD |
| ECIP-1119 | International Sanctions Compliance | TBD |
| ECIP-1120 | Base fee smoothing option | TBD |

ECIP-1121 does not supersede any of the above ECIPs and does not define economic or governance behavior.

## Prior Fork Validation

The EIPs listed in this ECIP:
- Were not activated in Spiral or Mystique
- Were not explicitly excluded in prior ECIPs
- Are execution-layer only
- Are compatible with Proof-of-Work block production

### ETH Forks Covered:
- Fulu-Osaka ("Fusaka")
- Prague-Electra ("Pectra")
- Cancun-Deneb ("Dencun")

## Execution Client Specifications

### Gas Accounting and State Access

| EIP | Short Description |
|----|------|
| EIP-7702 - Set EOA account code | Add a new tx type that permanently sets the code for an EOA |
| EIP-7623 - Increase calldata cost | Increase calldata cost to reduce maximum block size |
| EIP-7825 Transaction Gas Limit Cap | Introduce a protocol-level cap on the maximum gas used by a transaction to 16,777,216 (2^24) |
| EIP-7883 MODEXP gas cost increase | Increases cost of ModExp precompile |
| EIP-7935 - Set default gas limit to 60 million | Recommend a new gas limit value for Fusaka and update execution layer client default configs |

### EVM Safety and Forward Compatibility

| EIP | Short Description |
|----|------|
| EIP-7934 RLP Execution Block Size Limit | Introduce a protocol-level cap on the maximum RLP-encoded block size to 10 MiB, including a 2 MiB margin for beacon block size.|
| EIP-6780 - SELFDESTRUCT only in same transaction | SELFDESTRUCT will recover all funds to the target but not delete the account, except when called in the same transaction as creation |
| EIP-7642: eth/69 - history expiry and simpler receipts | Adds history serving window and removes bloom filter in receipt|
| EIP-7910 - ethconfig JSON-RPC Method | A JSON-RPC method that describes the configuration of the current and next fork |

### Cryptographic and Precompile Enhancements

| EIP | Short Description |
|----|------|
| EIP-2537 - Precompile for BLS12-381 curve operations | Adds operation on BLS12-381 curve as a precompile in a set necessary to efficiently perform operations such as BLS signature verification. |
| EIP-7951 Precompile for secp256r1 Curve Support | Add precompiled contract for secp256r1 ECDSA signature verification with proper security checks |

### Execution Context Optimizations

| EIP | Short Description |
|----|------|
| EIP-5656 - MCOPY - Memory copying instruction | An efficient EVM instruction for copying memory areas |
| EIP-2935 - Save historical block hashes in state | Store and serve last 8191 block hashes as storage slots of a system contract to allow for stateless execution |
| EIP-1153 - Transient storage opcodes | Add opcodes for manipulating state that behaves almost identically to storage but is discarded after every transaction |

## Deferred Specifications

The following execution-adjacent EIPs are explicitly deferred because Ethereum Classic does not implement blob-based data availability:

| EIP | Reason for Deferral |
|----|--------------------|
| Any blob-dependent EIP | ETC does not implement blobs |
| EIP-4788 - Beacon block root in the EVM | ETC does not implement blobs |
| EIP-4844 - Shard blob transactions (Proto-Danksharding) | ETC does not implement blobs |
| EIP-7516 - BLOBBASEFEE opcode | ETC does not implement blobs |
| EIP-4844 - Shard blob transactions | ETC does not implement blobs |
| EIP-7691 - Blob throughput increase | ETC does not implement blobs |
| EIP-7840 - Add blob schedule to EL config files | ETC does not implement blobs |
| EIP-7892 Blob Parameter Only Hardforks | ETC does not implement blobs |
| EIP-7918 Blob base fee bounded by execution cost | ETC does not implement blobs |

Deferral does not imply rejection.

## Explicit Exclusions

The following specifications are intentionally excluded and governed elsewhere:
- Fee market governance (ECIP-1111, ECIP-1112, ECIP-1113, ECIP-1114, ECIP-1115, ECIP-1120)
- EIP-1559
- EIP-3198

The following specifications are related to one or more of the following and are not applicable to ETC
- Proof-of-Stake consensus mechanisms
- Beacon Chain dependencies
- Engine API proposer-validator separation
- MEV-Boost and proposer-builder separation

| EIP | Reason for Omission |
|----|--------------------|
| EIP-4788 - Beacon block root in the EVM | ETC does not implement POS |
| EIP-7044 - Perpetually valid signed voluntary exits | ETC does not implement POS |
| EIP-7045 - Increase max attestation inclusion slot | ETC does not implement POS |
| EIP-7514 - Add max epoch churn limit | ETC does not implement POS |
| EIP-7251 - Increase the MAXEFFECTIVE_BALANCE | ETC does not implement POS |
| EIP-7002 - Execution layer triggerable exits | ETC does not implement POS |
| EIP-7685 - General purpose execution layer requests | ETC does not implement POS |
| EIP-6110 - Supply validator deposits on chain | ETC does not implement POS |
| EIP-7549 - Move committee index outside Attestation | ETC does not implement POS |
| EIP-7917 Deterministic proposer lookahead | ETC does not implement POS |

## Rationale

Separating execution-layer semantics from economic and governance policy:
- Preserves Ethereum Classic’s Proof-of-Work integrity
- Improves client and tooling interoperability
- Reduces governance coupling
- Mirrors the successful structure of Spiral and Mystique ECIPs

## References
- Ethereum Improvement Proposals: https://eips.ethereum.org
- Ethereum Roadmap – Fusaka: https://ethereum.org/roadmap/fusaka/
- Ethereum Classic ECIPs: https://ecips.ethereumclassic.org
- Core-Geth: https://github.com/etclabscore/core-geth

## Copyright

Copyright and related rights waived via
CC0.

### Abstract

This ECIP describes a fallback plan if an extension of ECIP-1010 does not activate. If that is the case, then completely diffuse the difficulty bomb at block 5452163.

### Motivation

There is currently a small probability that an extension of ECIP-1010 might not be able to be activated. The probability is really slight, but it is still possible. Please see the discussion of that issue for reasonings from different parties. This ECIP provides a fallback plan, to give assurance for those who might be impantient or worried of the difficulty bomb, so as to avoid a possible community split or an unexcepted hard fork.

Block 5452163 is chosen as the fork block number. This is a totally arbitrary and meaningless number. In this way, we avoid collisions of the fork block number with other protocol upgrade hard forks.

### Specification

If an extension of ECIP-1010 is rejected, at block 5452163, change the difficulty calculation formula to:

That is, remove the int(2**explosion) part from the formula in ECIP-1010.

# ECIP-1043 – Fixed DAG limit restriction

## Abstract
The purpose of this ECIP is to set a limit on the maximum size of the DAG and no longer increase it on an epoch schedule.

## Motivation
The original intent of the DAG was to provide ASIC resistance to the mining protocol in order to prevent centralization of mining distributions and thereby provide for an objectively fair distribution of tokens. As evident by ASICs being developed that are capable of matching current GPU miners while being more energy efficient, the DAG has succeeded in leveling the playing field between GPU incumbents and ASIC challengers, avoiding ASIC takeover and domination, and leading to a competitive and large mining ecosystem. However, further increases of the DAG size, while technically possible, may have negative impact on long term security and may act as an anti-competitive bug preventing further investment in mining development.

While prior concerns around 2 GB and 3 GB boundaries have not materialized ECIP-? Limit DAG growth #6, there is renewed concern around the 4 GB boundary, which will be reached in late 2020. Forcing GPUs into obsolescence does not provide an increase in security. To the contrary, smaller DAG sizes allow more GPUs the ability to mine while providing a lowered initial entry cost to hobbyist miners.

A 5 year vision of the mining landscape would see a transition from general purpose GPU mining to a broader market of application specific hardware being built by current and supported by a diverse group of manufactures similar to the current GPU market.

## Specification
if(blkNumber > 10,000,000) { DAG growth = 0; cache growth = 0 }

Note that in order to not alter the characteristics of the Ethash Proof-of-Work entirely, the epoch is still incremented every 30,000 blocks, and the contents of the DAG and cache change with every epoch.
The only modification is to stop the increase of DAG size and cache size.

## Specification Alternatives
- A: do not activate ECIP but continue to collect data and prepare code
- B: (current spec) stop growth at block 10,000,000 (DAG is about 3.6GB then)
- C: reverse growth at block 10,000,000, stop decline at block x
- D: set to 2.9 GB at block x
- E: set to 1.5 GB at block x

## Recommended Implementation

Two variables directly control the dag size growth cacheSize and datasetSize
- cacheSize is the size of the ethash verification cache that belongs to a certain block number. The cache size grows linearly, however, we always take the highest prime below the linearly growing threshold in order to reduce the risk of accidental regularities leading to cyclic behavior
- DatasetSize is the size of the ethash mining dataset that belongs to a certain block number. The dataset size grows linearly, however, we always take the highest prime below the linearly growing threshold in order to reduce the risk of accidental regularities leading to cyclic behavior.

These values are calculated as blockNumber / epochLength. To set the dag growth to a number smaller than what would occur through the normal calculation. A Magic Dag Epoch block is of 64 replaces blockNumber / epochLength as the epoch number after the fork block and when the dag is calculated in the future this epoch is always used. Dag generation is uneffected and will compute at epoch 64 pepeturally. Epoch 64 was selected because it included block 1,920,000 where the mining community rallied to help ETC form and survive.

## Risks Consideration
- This ECIP is not forward compatible and introduces backwards incompatibilities in the DAG file generation, block verification, and block mining. Therefore, it should be included in a scheduled hardfork at a certain block number.
- This is a long term PRO applicaton specific hardware proposal. If sufficient interest is not generated by manufactures in the mining field, there is risk of domination by one or more manufactures. (market risk)
- This ECIP moves the goalposts of a game that has already started. It may set a precedent of social intervention and reduce objectivity of the physical layer. Owners of 6 GB and more memory GPUs may not see the profitability jump they may have expected around November 2020. Owners of 4 GB GPUs or Bitmain E3 may see unexpected additional profitability. If DAG is decreased below 3 GB or below 2 GB, owners of older GPUs may unexpectedly have a chance to participate again.
- This ECIP impairs the immutability of the hashing algorithm, potentially leading to a reassessment of the current 1.0 value in Yazanator's immutability map (to 0.9 maybe?) and Szabo score.
- The units of Ethash before and after activation may be deemed not fully comparable and thus impair a fair chance for follow-the-longest-chain to play out.
- This ECIP may not attract sufficiently broad support from client software, mining stacks (Claymore), pools, Bitmain (E3 software upgrade).
- It may be unclear how to gather sentiment around a change that affects investments into the physical layer currently valued at 21 mio USD, or how to assess and handle contentious or friendly forks emerging from this ECIP.
- This ECIP may require coordination with ETH given that ETH is considering both a change to ProgPoW and a change to PoS in the near future. It may be hard to assess sentiment whether it's better for ETC to lead with stability or to lead with progression.

## Quantifying ETC Mining Investment
Network values for ETC (2019-10-19):
- mining profitability 0.0123 USD/MH/Day
- calculated network hashrate 9.5TH/s

Ignoring sunk cost, we calculate how much it would cost to provide today's network hashrate at today's profitability, if investors want to recoup the cost of machines within 180 days.
- 0.0123 USD/MH/day = 12,300 USD/TH/day
- 12,300 USD 180 days = 2,214,000 USD/TH
- 2,214,000 USD/TH 9.5 TH = 21,033,000 USD

We can value today's ETC mining investment at about 21 mio USD.

## Quantifying DAG Size
- 1 epoch = 30,000 blocks (about 5 days)
- DAG increase: 8MB / epoch, about 579 MB / year

|Date|DAG Size|Note|
|----|--------|----|
|2016-09-28|1.6 GB|Predecessor of ECIP 1043 started|
|2017-08-31|2 GB||
|2018-04-16|2.4 GB|ECIP 1043 started|
|2019-04-01|3 GB||
|2019-10-20|3.3 GB|Now|
|2020-10-30|4 GB|Might affect 20%-40% of network hashrate|
|2023-12-31|6 GB||
|2027-03-01|8 GB||
|2031-11-30|11 GB||
|2040|16 GB||
|2065|32 GB||

## References
- ECIP-? Limit DAG growth #6
- Ethash Sources
- DAG Size Calculator
- Bob Summerwill's Explicit Social Contract in support of PoW mining
- Donald McIntyre's Why Proof of Stake is Less Secure Than Proof of Work
- Yazanator's Quantifying Immutability
- Linzhi's ECIP 1043 Revisited
- Linzhi's What Is Memory-Hard?
- Bob Rao's ProgPoW Hardware Audit

## Implementation
The following clients implemented ECIP
- [] Geth-ETC
- [] Parity
- [] Mantis

## Copyright
Copyright and related rights waived via CC0.

## Simple Summary

The addition of a Merkle-Mountain-Range (MMR) root to blockheaders

## Abstract

A block chain could be interpreted as a linked-list using hashpointers from each block to its previous block. A Merkle-Mountain-Range is a type of tree that, will allow every block to point back to all its previous blocks. This can be accomplished using only a single hashPointer in each block - the current MMR root. Adding this will allow proving the cummulative work of an entire chain in Olog(n) time, instead of the current O(n) time. In the case of ethereum, with small block-times, and over 7 million blocks and counting, this will open a ton of doors in the area light-clients, and data verification.

## Motivation

The recent FlyClient paper and presentation at Scaling Bitcoin Represented a major breakthrough the ability to succinctly, and non-interactivly prove the cumulative work of a blockchain.

The current data structures in Ethereum (merkle-patricia-trees) were made with the sole purpose of allowing succinct verification of all the data. I have personally been working for some time on the missing tools to extract, send, and validate these proofs. This work is mostly done, but there is a problem:

Without a succinct way to verify work, there is nothing to verify these merkle proofs against.

A merkle proof can only verify against a hash that I already trust. The validation chain goes something like this for some contract data x:
- x is proven to have existed in a particular storageRootx
- storageRootx is proven to have existed in a particular accountx
- acount is proven to have existed in a particular stateTreex
- stateTreex is proven to have existed in a particular blockx

And merkle proofs end there: blockx unfortunately cannot be trusted.

There are 2 main strategies for verifying a block:
- Validate every transaction sinse genesis
- This takes a week on desktop and
- Requires the user to have the full dataset anyway, removing the need for merkle proofs in the first place.
- Is infeasible on mobile.
- Validating the work (of the entire chain)
- Relies on majority honest miner assumption
- currently requires all block headers
- currently requires validating every blockHeader's PoW

The problem is that it ends there. And we still have nothing, if the person (or machine) validating cannot validate the block. The cost to produce such proofs is free; To validate blocks we cant use the same strategy. Blocks validate against a chain, which in turn validates through its proof of work. Currently the only way to do this requires 4gb of chain data. Thats way too much. We need something that can work within a few seconds.

FlyClient is that something, and adding an MMRroot to each blockheader is the protocol change that will allow FlyClient to work.

On a high level, it allows the verifier to sample a subset of blocks in a tree, rather than a full amount thought a linked list, improving the time-complexity from O(n) to O(log(n)). The sample subset can be made large enough such it is cryptographically infeasible to ever produce a false proof.

With this EIP, PoW can be proven in

There is a consensus-breaking rule change proposed here, and then a bit of software around the change will be needed in order to take advantage of the new features. I think it would be best to keep this EIP as just detailing the rule-change, I will summeraize the other tools and link them

### Consensus Rule Change

If block.number >= ISTANBULFORKNUM then when constructing the block, set a 16th value blockHashesRoot in the header to the MMRRoot from the previous block.

This Root is defined by the combining all previous hashes into a Merkle Mountain Range (Peter Todd) using it's block number as leaf index.

Implementation of this tree is up to the clients but its fairly simple and requires only an additional ~500mb (on disk) to a full/archive node.

The MMR structure uses a proccess of "bagging the peaks" in order to create a single root hash. However, this may be sub-optimal for our use case. I would like to ammend this to instead define each root as the hash of the concatonation of the mountain peaks. This will make building and verifying proofs much simpler without significantly changing the size of the proofs.

The structure can be implimented as an array. Only a log(n) number of read/writes are done for any operation. A put operation needs to be done durring each block validation by the client. About 600 gets need to be performed when one of these proofs is requested (however the client can cache the latest proof). There is exactly 1 valid FlyProof for the current tip (latest mined block).

The FlyCLient paper can be followed almost exactly. Find it herefor specs.

Missing from the paper is a specific way to attain the samples from the blockhash (used as random seed). For this process, I propose we use slice-sampling. This should be a very efficient algorithm as long as our probability density function is invertible. We may require a hash during each iteration (~600). This process is only required for building and verifying proofs, it is not required for instance, of miners.

 seconds
- Creating a succinct Proof blockHashesRoot: seconds
- Size of a Proof mb
-->

## Rationale

## Backwards Compatibility

## Test Cases

## Implementation

The most obvious need is for a non-full-node to be able to request this Proof from a full-node. This should be done by adding an RPC method. The method will take no arguments and it should return an object with:
- The lastest blockHeader
- A list of the randomly selected ~600 blockheaders for the proof
- we need to create the standard deterministic way to pick the the blocks (using blockhash as seed) over the probability denisty function. I propose that we do something like this
- The 64 byte dataset (each) for verifying an ethHash (~2.4 MB)
- A list of proofNodes from the MMR (+"bag proof" nodes)

## Copyright
Copyright and related rights waived via CC0.

### Abstract

EIP-2124 (forkid) and EIP-2364 (eth/64) propose discovery protocol modifications which depend on lists of fork values. In case these changes are adopted and implemented on Ethereum Classic networks, this ECIP defines canonical lists of forks numbers for inclusion in the generation and validation steps of these "ForkID" schemes.
- https://eips.ethereum.org/EIPS/eip-2124
- https://eips.ethereum.org/EIPS/eip-2364

This specification describes a set of forks which exclude TheDAO fork event block(s) from forkid calculations, as well as excluding all forthcoming blockNumber % 5000000 == 0 blocks that, according to the algorithmdescribed in ECIP-1017 and enabled on ETC Mainnet and some testnets, will see reduced block reward values.

### Motivation

Specify parameters for forkid generation and validation, so that in the case nodes on Ethereum Classic networks implement eth/64, they can do so in a consistent way.

As documented in EIP-2364, implementation for eth/64 does not demand consensus nor require any fork for node or network implementation.

Notwithstanding, it would be good for Ethereum Classic networks and clients to be able to implement the protocol change, if they want, according to a standard specification. Failure for clients to agree on forkid implementation could result in difficulty discovering each other.

### Specification

#### Generally

Don't include TheDAO fork blocks (eg. 1920000 on Mainnet, 1885000 on Morden) as a forkid parameter as specified in EIP-2124.

Don't include any blocks subsequent and incidental to consensus-facing calculations according to accepted and implemented algorithms, eg. ECIP-1017.

#### Applied

The following data points are valid at time of writing (see ECIP's created-at metadata).

##### Ethereum Classic Mainnet (ETC)
- Genesis Hash: 0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3
- Forks: 1150000,2500000,3000000,5000000,5900000,8772000,9573000,10500839

| Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
| --- | --- | --- | --- |
| head=0 | FORKHASH=fc64ec04 | FORKNEXT=1150000 | c984fc64ec0483118c30 |
| head=1149999 | FORKHASH=fc64ec04 | FORKNEXT=1150000 | c984fc64ec0483118c30 |
| _head=1150000 | FORKHASH=97c2c34c | FORKNEXT=2500000 | c98497c2c34c832625a0 |
| head=1150001 | FORKHASH=97c2c34c | FORKNEXT=2500000 | c98497c2c34c832625a0 |
| head=2499999 | FORKHASH=97c2c34c | FORKNEXT=2500000 | c98497c2c34c832625a0 |
| head=2500000 | FORKHASH=db06803f | FORKNEXT=3000000 | c984db06803f832dc6c0 |
| head=2500001 | FORKHASH=db06803f | FORKNEXT=3000000 | c984db06803f832dc6c0 |
| head=2999999 | FORKHASH=db06803f | FORKNEXT=3000000 | c984db06803f832dc6c0 |
| head=3000000 | FORKHASH=aff4bed4 | FORKNEXT=5000000 | c984aff4bed4834c4b40 |
| head=3000001 | FORKHASH=aff4bed4 | FORKNEXT=5000000 | c984aff4bed4834c4b40 |
| head=4999999 | FORKHASH=aff4bed4 | FORKNEXT=5000000 | c984aff4bed4834c4b40 |
| head=5000000 | FORKHASH=f79a63c0 | FORKNEXT=5900000 | c984f79a63c0835a06e0 |
| head=5000001 | FORKHASH=f79a63c0 | FORKNEXT=5900000 | c984f79a63c0835a06e0 |
| head=5899999 | FORKHASH=f79a63c0 | FORKNEXT=5900000 | c984f79a63c0835a06e0 |
| head=5900000 | FORKHASH=744899d6 | FORKNEXT=8772000 | c984744899d68385d9a0 |
| head=5900001 | FORKHASH=744899d6 | FORKNEXT=8772000 | c984744899d68385d9a0 |
| head=8771999 | FORKHASH=744899d6 | FORKNEXT=8772000 | c984744899d68385d9a0 |
| head=8772000 | FORKHASH=518b59c6 | FORKNEXT=9573000 | c984518b59c683921288 |
| head=8772001 | FORKHASH=518b59c6 | FORKNEXT=9573000 | c984518b59c683921288 |
| head=9572999 | FORKHASH=518b59c6 | FORKNEXT=9573000 | c984518b59c683921288 |
| head=9573000 | FORKHASH=7ba22882 | FORKNEXT=10500839 | c9847ba2288283a03ae7 |
| head=9573001 | FORKHASH=7ba22882 | FORKNEXT=10500839 | c9847ba2288283a03ae7 |
| head=10500838 | FORKHASH=7ba22882 | FORKNEXT=10500839 | c9847ba2288283a03ae7 |
| head=10500839 | FORKHASH=9007bfcc | FORKNEXT=0 | c6849007bfcc80 |
| head=10500840 | FORKHASH=9007bfcc | FORKNEXT=0 | c6849007bfcc80 |

##### Kotti
- Genesis Hash: 0x14c2283285a88fe5fce9bf5c573ab03d6616695d717b12a127188bcacfc743c4
- Forks: 716617,1705549,2000000,2200013,5000000

| Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
| --- | --- | --- | --- |
| head=0 | FORKHASH=0550152e | FORKNEXT=716617 | c9840550152e830aef49 |
| head=716616 | FORKHASH=0550152e | FORKNEXT=716617 | c9840550152e830aef49 |
| head=716617 | FORKHASH=a3270822 | FORKNEXT=1705549 | c984a3270822831a064d |
| head=716618 | FORKHASH=a3270822 | FORKNEXT=1705549 | c984a3270822831a064d |
| head=1705548 | FORKHASH=a3270822 | FORKNEXT=1705549 | c984a3270822831a064d |
| head=1705549 | FORKHASH=8f3698e0 | FORKNEXT=2000000 | c9848f3698e0831e8480 |
| head=1705550 | FORKHASH=8f3698e0 | FORKNEXT=2000000 | c9848f3698e0831e8480 |
| head=1999999 | FORKHASH=8f3698e0 | FORKNEXT=2000000 | c9848f3698e0831e8480 |
| head=2000000 | FORKHASH=7faf51b5 | FORKNEXT=2200013 | c9847faf51b5832191cd |
| head=2000001 | FORKHASH=7faf51b5 | FORKNEXT=2200013 | c9847faf51b5832191cd |
| head=2200012 | FORKHASH=7faf51b5 | FORKNEXT=2200013 | c9847faf51b5832191cd |
| head=2200013 | FORKHASH=595e180d | FORKNEXT=5000000 | c984595e180d834c4b40 |
| head=2200014 | FORKHASH=595e180d | FORKNEXT=5000000 | c984595e180d834c4b40 |
| head=4999999 | FORKHASH=595e180d | FORKNEXT=5000000 | c984595e180d834c4b40 |
| head=5000000 | FORKHASH=b5407fd6 | FORKNEXT=0 | c684b5407fd680 |
| head=5000001 | FORKHASH=b5407fd6 | FORKNEXT=0 | c684b5407fd680 |

##### Mordor
- Genesis Hash: 0xa68ebde7932eccb177d38d55dcc6461a019dd795a681e59b5a3e4f3a7259a3f1
- Forks: 301243,999983

| Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
| --- | --- | --- | --- |
| head=0 | FORKHASH=175782aa | FORKNEXT=301243 | c984175782aa830498bb |
| head=301242 | FORKHASH=175782aa | FORKNEXT=301243 | c984175782aa830498bb |
| head=301243 | FORKHASH=604f6ee1 | FORKNEXT=999983 | c984604f6ee1830f422f |
| head=301244 | FORKHASH=604f6ee1 | FORKNEXT=999983 | c984604f6ee1830f422f |
| head=999982 | FORKHASH=604f6ee1 | FORKNEXT=999983 | c984604f6ee1830f422f |
| head=999983 | FORKHASH=f42f5539 | FORKNEXT=0 | c684f42f553980 |
| head=999984 | FORKHASH=f42f5539 | FORKNEXT=0 | c684f42f553980 |

##### Morden
- Genesis Hash: 0x0cd786a2425d16f152c658316c423e6ce1181e15c3295826d7c9904cba9ce303
- Forks: 494000,1783000,1915000,2000000,2300000,4729274,5000381

| Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
| --- | --- | --- | --- |
| head=0 | FORKHASH=417adbe7 | FORKNEXT=494000 | c984417adbe7830789b0 |
| head=493999 | FORKHASH=417adbe7 | FORKNEXT=494000 | c984417adbe7830789b0 |
| head=494000 | FORKHASH=aeb67dfb | FORKNEXT=1783000 | c984aeb67dfb831b34d8 |
| head=494001 | FORKHASH=aeb67dfb | FORKNEXT=1783000 | c984aeb67dfb831b34d8 |
| head=1782999 | FORKHASH=aeb67dfb | FORKNEXT=1783000 | c984aeb67dfb831b34d8 |
| head=1783000 | FORKHASH=6a495281 | FORKNEXT=1915000 | c9846a495281831d3878 |
| head=1783001 | FORKHASH=6a495281 | FORKNEXT=1915000 | c9846a495281831d3878 |
| head=1914999 | FORKHASH=6a495281 | FORKNEXT=1915000 | c9846a495281831d3878 |
| head=1915000 | FORKHASH=e893e32d | FORKNEXT=2000000 | c984e893e32d831e8480 |
| head=1915001 | FORKHASH=e893e32d | FORKNEXT=2000000 | c984e893e32d831e8480 |
| head=1999999 | FORKHASH=e893e32d | FORKNEXT=2000000 | c984e893e32d831e8480 |
| head=2000000 | FORKHASH=12a0ac82 | FORKNEXT=2300000 | c98412a0ac8283231860 |
| head=2000001 | FORKHASH=12a0ac82 | FORKNEXT=2300000 | c98412a0ac8283231860 |
| head=2299999 | FORKHASH=12a0ac82 | FORKNEXT=2300000 | c98412a0ac8283231860 |
| head=2300000 | FORKHASH=02a93060 | FORKNEXT=4729274 | c98402a93060834829ba |
| head=2300001 | FORKHASH=02a93060 | FORKNEXT=4729274 | c98402a93060834829ba |
| head=4729273 | FORKHASH=02a93060 | FORKNEXT=4729274 | c98402a93060834829ba |
| head=4729274 | FORKHASH=4802d0c7 | FORKNEXT=5000381 | c9844802d0c7834c4cbd |
| head=4729275 | FORKHASH=4802d0c7 | FORKNEXT=5000381 | c9844802d0c7834c4cbd |
| head=5000380 | FORKHASH=4802d0c7 | FORKNEXT=5000381 | c9844802d0c7834c4cbd |
| head=5000381 | FORKHASH=0b559b1d | FORKNEXT=0 | c6840b559b1d80 |
| head=5000382 | FORKHASH=0b559b1d | FORK_NEXT=0 | c6840b559b1d80 |

### Rationale

The Ethereum Classic consensus protocol did not fork at block 1920000.

The Ethereum Classic disinflationary monetary policy is not considered a series of forks, it is the natural "stepping" behavior of a deterministic algorithm.

### Implementation

Respective reference implementations for forkid generation are documented in EIP-2124 and EIP-2364.

### Abstract

EIP-2124 (forkid) and EIP-2364 (eth/64) propose discovery protocol modifications which depend on lists of fork values. In case these changes are adopted and implemented on Ethereum Classic networks, this ECIP defines canonical lists of forks numbers for inclusion in the generation and validation steps of these "ForkID" schemes.
- https://eips.ethereum.org/EIPS/eip-2124
- https://eips.ethereum.org/EIPS/eip-2364

This specification describes a set of forks which exclude TheDAO fork event block(s) from forkid calculations, as well as excluding all forthcoming blockNumber % 5000000 == 0 blocks that, according to the algorithmdescribed in ECIP-1017 and enabled on ETC Mainnet and some testnets, will see reduced block reward values.

### Motivation

Specify parameters for forkid generation and validation, so that in the case nodes on Ethereum Classic networks implement eth/64, they can do so in a consistent way.

As documented in EIP-2364, implementation for eth/64 does not demand consensus nor require any fork for node or network implementation.

Notwithstanding, it would be good for Ethereum Classic networks and clients to be able to implement the protocol change, if they want, according to a standard specification. Failure for clients to agree on forkid implementation could result in difficulty discovering each other.

### Specification

#### Generally

Don't include TheDAO fork blocks (eg. 1920000 on Mainnet, 1885000 on Morden) as a forkid parameter as specified in EIP-2124.

Don't include any blocks subsequent and incidental to consensus-facing calculations according to accepted and implemented algorithms, eg. ECIP-1017.

#### Applied

The following data points are valid at time of last edit.

##### Ethereum Classic Mainnet (ETC)
- Genesis Hash: 0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3
- - Forks: 1150000,2500000,3000000,5000000,5900000,8772000,9573000,10500839
- - | Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
- | --- | --- | --- | --- |
- | head=0 | FORKHASH=fc64ec04 | FORKNEXT=1150000 | c984fc64ec0483118c30 |
- | head=1149999 | FORKHASH=fc64ec04 | FORKNEXT=1150000 | c984fc64ec0483118c30 |
- | _head=1150000 | FORKHASH=97c2c34c | FORKNEXT=2500000 | c98497c2c34c832625a0 |
- | head=1150001 | FORKHASH=97c2c34c | FORKNEXT=2500000 | c98497c2c34c832625a0 |
- | head=2499999 | FORKHASH=97c2c34c | FORKNEXT=2500000 | c98497c2c34c832625a0 |
- | head=2500000 | FORKHASH=db06803f | FORKNEXT=3000000 | c984db06803f832dc6c0 |
- | head=2500001 | FORKHASH=db06803f | FORKNEXT=3000000 | c984db06803f832dc6c0 |
- | head=2999999 | FORKHASH=db06803f | FORKNEXT=3000000 | c984db06803f832dc6c0 |
- | head=3000000 | FORKHASH=aff4bed4 | FORKNEXT=5000000 | c984aff4bed4834c4b40 |
- | head=3000001 | FORKHASH=aff4bed4 | FORKNEXT=5000000 | c984aff4bed4834c4b40 |
- | head=4999999 | FORKHASH=aff4bed4 | FORKNEXT=5000000 | c984aff4bed4834c4b40 |
- | head=5000000 | FORKHASH=f79a63c0 | FORKNEXT=5900000 | c984f79a63c0835a06e0 |
- | head=5000001 | FORKHASH=f79a63c0 | FORKNEXT=5900000 | c984f79a63c0835a06e0 |
- | head=5899999 | FORKHASH=f79a63c0 | FORKNEXT=5900000 | c984f79a63c0835a06e0 |
- | head=5900000 | FORKHASH=744899d6 | FORKNEXT=8772000 | c984744899d68385d9a0 |
- | head=5900001 | FORKHASH=744899d6 | FORKNEXT=8772000 | c984744899d68385d9a0 |
- | head=8771999 | FORKHASH=744899d6 | FORKNEXT=8772000 | c984744899d68385d9a0 |
- | head=8772000 | FORKHASH=518b59c6 | FORKNEXT=9573000 | c984518b59c683921288 |
- | head=8772001 | FORKHASH=518b59c6 | FORKNEXT=9573000 | c984518b59c683921288 |
- | head=9572999 | FORKHASH=518b59c6 | FORKNEXT=9573000 | c984518b59c683921288 |
- | head=9573000 | FORKHASH=7ba22882 | FORKNEXT=10500839 | c9847ba2288283a03ae7 |
- | head=9573001 | FORKHASH=7ba22882 | FORKNEXT=10500839 | c9847ba2288283a03ae7 |
- | head=10500838 | FORKHASH=7ba22882 | FORKNEXT=10500839 | c9847ba2288283a03ae7 |
- | head=10500839 | FORKHASH=9007bfcc | FORKNEXT=0 | c6849007bfcc80 |
- | head=10500840 | FORKHASH=9007bfcc | FORKNEXT=0 | c6849007bfcc80 |
- - - ##### Kotti
- - - Genesis Hash: 0x14c2283285a88fe5fce9bf5c573ab03d6616695d717b12a127188bcacfc743c4
- - Forks: 716617,1705549,2200013
- - | Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
- | --- | --- | --- | --- |
- | head=0 | FORKHASH=0550152e | FORKNEXT=716617 | c9840550152e830aef49 |
- | head=716616 | FORKHASH=0550152e | FORKNEXT=716617 | c9840550152e830aef49 |
- | head=716617 | FORKHASH=a3270822 | FORKNEXT=1705549 | c984a3270822831a064d |
- | head=716618 | FORKHASH=a3270822 | FORKNEXT=1705549 | c984a3270822831a064d |
- | head=1705548 | FORKHASH=a3270822 | FORKNEXT=1705549 | c984a3270822831a064d |
- | head=1705549 | FORKHASH=8f3698e0 | FORKNEXT=2200013 | c9848f3698e0832191cd |
- | head=1705550 | FORKHASH=8f3698e0 | FORKNEXT=2200013 | c9848f3698e0832191cd |
- | head=2200012 | FORKHASH=8f3698e0 | FORKNEXT=2200013 | c9848f3698e0832191cd |
- | head=2200013 | FORKHASH=6f402821 | FORKNEXT=0 | c6846f40282180 |
- | head=2200014 | FORKHASH=6f402821 | FORKNEXT=0 | c6846f40282180 |
- - - ##### Mordor
- - - Genesis Hash: 0xa68ebde7932eccb177d38d55dcc6461a019dd795a681e59b5a3e4f3a7259a3f1
- - Forks: 301243,999983
- - | Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
- | --- | --- | --- | --- |
- | head=0 | FORKHASH=175782aa | FORKNEXT=301243 | c984175782aa830498bb |
- | head=301242 | FORKHASH=175782aa | FORKNEXT=301243 | c984175782aa830498bb |
- | head=301243 | FORKHASH=604f6ee1 | FORKNEXT=999983 | c984604f6ee1830f422f |
- | head=301244 | FORKHASH=604f6ee1 | FORKNEXT=999983 | c984604f6ee1830f422f |
- | head=999982 | FORKHASH=604f6ee1 | FORKNEXT=999983 | c984604f6ee1830f422f |
- | head=999983 | FORKHASH=f42f5539 | FORKNEXT=0 | c684f42f553980 |
- | head=999984 | FORKHASH=f42f5539 | FORKNEXT=0 | c684f42f553980 |
- - - ##### Morden
- - - Genesis Hash: 0x0cd786a2425d16f152c658316c423e6ce1181e15c3295826d7c9904cba9ce303
- - Forks: 494000,1783000,1915000,2000000,2300000,4729274,5000381
- - | Head Block Number | FORKHASH | FORKNEXT | RLP Encoded (Hex) |
- | --- | --- | --- | --- |
- | head=0 | FORKHASH=417adbe7 | FORKNEXT=494000 | c984417adbe7830789b0 |
- | head=493999 | FORKHASH=417adbe7 | FORKNEXT=494000 | c984417adbe7830789b0 |
- | head=494000 | FORKHASH=aeb67dfb | FORKNEXT=1783000 | c984aeb67dfb831b34d8 |
- | head=494001 | FORKHASH=aeb67dfb | FORKNEXT=1783000 | c984aeb67dfb831b34d8 |
- | head=1782999 | FORKHASH=aeb67dfb | FORKNEXT=1783000 | c984aeb67dfb831b34d8 |
- | head=1783000 | FORKHASH=6a495281 | FORKNEXT=1915000 | c9846a495281831d3878 |
- | head=1783001 | FORKHASH=6a495281 | FORKNEXT=1915000 | c9846a495281831d3878 |
- | head=1914999 | FORKHASH=6a495281 | FORKNEXT=1915000 | c9846a495281831d3878 |
- | head=1915000 | FORKHASH=e893e32d | FORKNEXT=2000000 | c984e893e32d831e8480 |
- | head=1915001 | FORKHASH=e893e32d | FORKNEXT=2000000 | c984e893e32d831e8480 |
- | head=1999999 | FORKHASH=e893e32d | FORKNEXT=2000000 | c984e893e32d831e8480 |
- | head=2000000 | FORKHASH=12a0ac82 | FORKNEXT=2300000 | c98412a0ac8283231860 |
- | head=2000001 | FORKHASH=12a0ac82 | FORKNEXT=2300000 | c98412a0ac8283231860 |
- | head=2299999 | FORKHASH=12a0ac82 | FORKNEXT=2300000 | c98412a0ac8283231860 |
- | head=2300000 | FORKHASH=02a93060 | FORKNEXT=4729274 | c98402a93060834829ba |
- | head=2300001 | FORKHASH=02a93060 | FORKNEXT=4729274 | c98402a93060834829ba |
- | head=4729273 | FORKHASH=02a93060 | FORKNEXT=4729274 | c98402a93060834829ba |
- | head=4729274 | FORKHASH=4802d0c7 | FORKNEXT=5000381 | c9844802d0c7834c4cbd |
- | head=4729275 | FORKHASH=4802d0c7 | FORKNEXT=5000381 | c9844802d0c7834c4cbd |
- | head=5000380 | FORKHASH=4802d0c7 | FORKNEXT=5000381 | c9844802d0c7834c4cbd |
- | head=5000381 | FORKHASH=0b559b1d | FORKNEXT=0 | c6840b559b1d80 |
- | head=5000382 | FORKHASH=0b559b1d | FORKNEXT=0 | c6840b559b1d80 |
- ### Rationale

The Ethereum Classic consensus protocol did not fork at block 1920000.

The Ethereum Classic disinflationary monetary policy is not considered a series of forks, it is the natural "stepping" behavior of a deterministic algorithm.

### Implementation

Respective reference implementations for forkid generation are documented in EIP-2124 and EIP-2364.

At the time of last edit, client implementation tests may be found at:
- Core-Geth: https://github.com/etclabscore/core-geth/blob/master/core/forkid/forkidtest.go#L132, https://github.com/etclabscore/core-geth/blob/master/core/forkid/forkidtest.go#L322
- Multi-Geth: https://github.com/etclabscore/core-geth/blob/master/core/forkid/forkidtest.go#L132
- OpenEthereum: https://github.com/openethereum/openethereum/blob/master/ethcore/sync/src/chain/fork_filter.rs#L145

### Change Log
- 2020-06-03
- Modify Kotti eligible fork specs, removing blocks 2M and 5M. Prior specifications were generated using a faulty chain configuration, which wrongly included these blocks. Rel https://github.com/goerli/testnet/pull/71.

# ECIP 1044 - Formalize IPFS hash into ECNS(Ethereum Classic Name Service) resolver

## Simple Summary
To specify the mapping protocol between resources stored on IPFS and ECNS(Ethereum Classic Name Service).

## Abstract
The following standard details the implementation of how to combine the IPFS cryptographic hash unique fingerprint with ecns public resolver. This standard provides a functionality to get and set IPFS online resources to ecns resolver.

We think that this implementation is not only aim to let more developers and communities to provide more use cases, but also leverage the human-readable features to gain more user adoption accessing decentralized resources. We considered the IPFS ecns resolver mapping standard a cornerstone for building future Web3.0 service.

## Motivation
To build fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages :
- Address large amounts of data, and has unique cryptographic hash for every record.
- Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, with safer way and lower the millions of cost for the bandwidth.
- IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network.

Those features makes perfect match for integrating into ecns, and these make users can easily access content through ecns, and show up in the normal browser.

## Specification
The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum Classic uses hex in API to encode the binary data. So that need a way to process the condition requires not only we need to transfer from IPFS to Ethereum Classic, but also need to convert it back.

To solve these requirements, we can use binary buffer bridging that gap.
When mapping the IPFS base58 string to ecns resolver, first we convert the Base58 to binary buffer, turn the buffer to hex encrypted format, and save to the contract. Once we want to get the IPFS resources address represented by the specific ecns, we can first find the mapping information stored as hex format before, extract the hex format to binary buffer, and finally turn that to IPFS Base58 address string.

## Rationale
To implement the specification, need two methods from ecns public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the setMultihash method below :

Whenever users need to visit the ecns content, we call the multihash method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use.

## Test Cases

To implement the way to transfer from base58 to hex format and the reverse one, using the ‘multihashes’ library to deal with the problem.
The library link : https://www.npmjs.com/package/multihashes
To implement the method transfer from IPFS(Base58) to hex format :

To implement the method transfer from hex format to IPFS(Base58) :

## Implementation
The use case can be implemented as browser extension. Users can easily download the extension, and easily get decentralized resources by just typing the ECNS just like we normally type the DNS to browser the website. Solve the current pain for normal people can not easily visit the total decentralized website.

The workable implementation repository : https://github.com/PortalNetwork/portal-network-browser-extension

## Copyright
Copyright and related rights waived via CC0.

# ECIP-1042 - GASPAY opcode

# Abstract
Add an operation to consume gas and add amount paid for that gas to token balance.

# Motivation
A useful Smart Contract (i.e. valuable) should expect small reward for its execution. A micropayment could be very
small a sub-cent payment but sending an additional value to a contract will make it more complicated and cost of such
transfer or contract execution could exceed requested reward.

It’s proposed here to introduce a new EVM Operation that will allow a developer to consume a portion of transaction fee
(amount paid for a gas) and transfer it to current Smart Contract.

Using a gas payment provided with transaction provides flexibility and independence from market price of Ether. Gas Price
is dynamic value and supposed to represent fair market price of contract execution, therefore making micropayment value
proportional to const of transaction and more stable in long term.

# Specification
Provide a new operation GASPAY a where a is amount of gas to consume, and 0x0 <= a <= 0x0fffff. The payment for
that gas goes to contract address. As a return it puts consumed value (Wei) into the stack.

The cost of the operation itself is equal to 1/4 of requested amount of Gas plus 5000 (a/4 + 5000). The payment for
that gas is going to miner address, and supposed to compensate potential miner loss from including in a block
transaction that doesn’t give all gas fee as a reward to a miner.

With the current average price of 23000 MWei per Gas, a smart contract can earn up to $1 per operation, by
requesting payment for 1,048,575 of Gas.

# Risks consideration

## Miners don’t receive payment for all gas in a block
Currently miners expect that all payment for the gas goes to coinbase. After introducing this operation part of this
payment could go to smart contracts participated in block transactions. This plays a role only when we have blocks fully
packed with transaction, up to the block gas limit, which is a dynamic value and can be controlled by miners.

Because cost of the execution of that operation is a constant and roughly is about 5000 of Gas, then requested cost of
execution as a/4 + 5000 will be as much as profitable as including other transactions with same gas limit. With that
cost it’s expected that a miner could earn 10%-20% of a requested amount, in addition to cost of actual work spent on
execution of that transaction. If gas prices per opcodes are fair, then a miner could be in favour of adding a
transaction with GASPAY opcode as it provides slightly more profit to a miner too.

## Software must distinguish payment went to contract and to miner
Most of the current 3rd party software expect that whole payment for a gas will go to a miner of the block. It includes
dev tools, block explorers and nodes (protocol implementations).

After introducing this new opcode, all this software must be updated according to a new way of gas payment calculation.

## Smart Contract language compilers
Solidity and other smart contract language compilers will need to be updated to support additional opcode

## Simple Summary

Introduce account versioning for smart contracts so upgrading the VM
or introducing new VMs can be easier.

## Abstract

This defines a method of hard forking while maintaining the exact
functionality of existing account by allowing multiple versions of the
virtual machines to execute in the same block. This is also useful to
define future account state structures when we introduce the on-chain
WebAssembly virtual machine.

## Motivation

By allowing account versioning, we can execute different virtual
machine for contracts created at different times. This allows breaking
features to be implemented while making sure existing contracts work
as expected.

Note that this specification might not apply to all hard forks. We
have emergency hard forks in the past due to network attacks. Whether
they should maintain existing account compatibility should be
evaluated in individual basis. If the attack can only be executed once
against some particular contracts, then the scheme defined here might
still be applicable. Otherwise, having a plain emergency hard fork
might still be a good idea.

## Specification

### Account State

Re-define account state stored in the world state trie to have 5
items: nonce, balance, storageRoot, codeHash, and
version. The newly added field version is a 256-bit scalar. We
use the definition of "scalar" from Yellow Paper. Note that this is
the same type as nonce and balance, and it is equivalent to a RLP
variable-sized byte array with no leading zero, of maximum length 32.

When version is zero, the account is RLP-encoded with the first 4
items. When version is not zero, the account is RLP-encoded with 5
items.

Account versions can also optionally define additional account state
RLP fields, whose meaning are specified through its version
field. In those cases, the parsing strategy is defined in "Additional
Fields in Account State RLP" section.

### Contract Execution

When fetching an account code from state, we always fetch the
associated version field together. We refer to this as the code's
version below. The code of the account is always executed in the
code's version.

In particular, this means that for DELEGATECALL and CALLCODE, the
version of the execution call frame is the same as
delegating/receiving contract's version.

### Contract Deployment

In Ethereum, a contract has a deployment method, either by a contract
creation transaction, or by another contract. If we regard this
deployment method a contract's parent, then we find them forming a
family of contracts, with the root being a contract creation
transaction.

We let a family of contracts to always have the same version. That
is, CREATE and CREATE2 will always deploy contract that has the
same version as the code's version.

In other words, CREATE and CREATE2 will execute the init code
using the current code's version, and deploy the contract of the
current code's version. This holds even if the to-be-deployed code
is empty.

### Validation

A new phrase, validation is added to contract deployment (by
CREATE / CREATE2 opcodes, or by contract creation
transaction). When version is 0, the phrase does nothing and
always succeeds. Future VM versions can define additional validation
that has to be passed.

If the validation phrase fails, deployment does not proceed and return
out-of-gas.

### Contract Creation Transaction

Define LATESTVERSION in a hard fork to be the latest supported VM
version. A contract creation transaction is always executed in
LATESTVERSION (which means the code's version is
LATESTVERSION), and deploys contracts of LATESTVERSION. Before a
contract creation transaction is executed, run validation on the
contract creation code. If it does not pass, return out-of-gas.

### Precompiled Contract and Externally-owned Address

Precompiled contracts and externally-owned addresses do not have
version. If a message-call transaction or CALL / CALLCODE /
STATICCALL / DELEGATECALL touches a new externally-owned address
or a non-existing precompiled contract address, it is always created
with version field being 0.

### Additional Fields in Account State RLP

In the future we may need to associate more information into an
account, and we already have some EIP/ECIPs that define new additional
fields in the account state RLP. In this section, we define the
parsing strategy when additional fields are added.
- Check the RLP list length, if it is 4, then set account version to
 0, and do not parse any additional fields.
- If the RLP list length more than 4, set the account version to the
 scalar at position 4 (counting from 0).
- Check version specification for the number of additional fields
- Parse RLP position 5 to 4 + N as the meaning specified in

## Extensions

In relation to the above "Specification" section, we have defined the
base account versioning layer. The base account versioning layer is
already useful by itself and can handle most EVM improvements. Below
we define two specifications that can be deployed separately, which
improves functionality of base layer account versioning.

Note that this section is provided only for documentation
purpose. When "enabling ECIP-1040", those extensions should not be
enabled unless the extension EIP is also included.
- ECIP-1068: Account Versioning Extension for Contract Creation
 Transaction
- ECIP-1069: Account Versioning Extension for CREATE and
 CREATE2

## Usage Template

This section defines how other ECIPs might use this account versioning
ECIP. Note that currently we only define the usage template for base
layer.

Account versioning is usually applied directly to a hard fork meta
ECIP. ECIPs in the hard fork are grouped by the virtual machine type,
for example, EVM and eWASM. For each of them, we define:
- Version: a non-zero scalar less than 2^256 that uniquely
 identifies this version. Note that it does not need to be
 sequential.
- Parent version: the base that all new features derived
 from. With parent version of 0 we define the base to be legacy
 VM. Note that once a version other than 0 is defined, the legacy
 VM's feature set must be frozen. When defining an entirely new VM
 (such as eWASM), parent version does not apply.
- Features: all additional features that are enabled upon this
 version.

If a meta ECIP includes ECIPs that provide additional account state RLP
fields, we also define:
- Account fields: all account fields up to the end of this meta
 EIP, excluding the basic 5 fields (nonce, balance,
 storageRoot, codeHash and version). If EIPs included that are
 specific to modifying account fields do not modify VM execution
 logic, it is recommended that we specify an additional version whose
 execution logic is the same as previous version, but only the
 account fields are changed.

## Rationale

This introduces account versioning via a new RLP item in account
state. The design above gets account versioning by making the contract
family always have the same version. In this way, versions are only
needed to be provided by contract creation transaction, and there is
no restrictions on formats of code for any version. If we want to
support multiple newest VMs (for example, EVM and WebAssembly running
together), then this will requires extensions such as ECIP-1068 and
ECIP-1069.

Alternatively, account versioning can also be done through:
- 26-VER and
 40-UNUSED: This makes an
 account's versioning soly dependent on its code header prefix. If
 with only EIP-1707, it is not possible to certify any code is valid,
 because current VM allows treating code as data. This can be fixed
 by EIP-1712, but the drawback is that it's potentially backward
 incompatible.
- EIP-1891: Instead of writing version field into account RLP
 state, we write it in a separate contract. This can accomplish the
 same thing as this EIP and potentially reduces code complexity, but
 the drawback is that every code execution will require an additional
 trie traversal, which impacts performance.

## Backwards Compatibility

Account versioning is fully backwards compatible, and it does not
change how current contracts are executed.

## Discussions

### Performance

Currently nearly all full node implementations uses config parameters
to decide which virtual machine version to use. Switching virtual
machine version is simply an operation that changes a pointer using a
different set of config parameters. As a result, this scheme has
nearly zero impact to performance.

### WebAssembly

This scheme can also be helpful when we deploy on-chain WebAssembly
virtual machine. In that case, WASM contracts and EVM contracts can
co-exist and the execution boundary and interaction model are clearly
defined as above.

## Test Cases and Implementations

To be added.

## Copyright

This work is licensed under Apache License, Version
2.0.

## Abstract

The following ECIP tries to bring the best practices about how Bitcoin
deals with consensus hard fork
(BIP-9
and
BIP-135)
into Ethereum Classic. Rather than hard-code a block number as we
currently do, each block mined emits support of the new consensus
hard-fork. Only when a large enough portion of the network support it,
the hard-fork is "locked-in" and will be activated.

## Motivation

Lack of an appropriate voting method can results in network
forking. The DAO hard fork was such an example. Currently the way
Ethereum used to gather opinions was through
CarbonVote. It indeed has the advantage that
it brings the opinions of Ethereum holders rather than
miners. However, it is not enforceable and we all know the disastrous
result it brought during the DAO hard fork period. We don't want that
to happen again.

Miner community, stake holders and proof of work. It is common
knowledge that Ethereum Classic will probably stay in proof of work,
rather than, like Ethereum, switch to a proof of stake
algorithm. Combining this ECIP together with ECIP-1023, we combines
opinions from both the miner community and ETC coin holders to reach
consensus about whether a hard fork should occur.

Best practices from
Bitcoin. BIP-9,
which uses version bits mined in each blocks to vote for consensus
soft fork has be successfully conducted for several. Its upgraded
version, BIP-135, aims to deal with both soft forks and hard forks
alike.

Potentially faster adoption of new consensus hard fork. When
dealing with emergency consensus hard fork for preventing network
attacks, the developer would not need to artificially insert a "hard
fork block number" (which must leave enough time for everyone else to
upgrade their clients, and then wait for that block). The ETC coin
holders and miners collectively decide when the hard fork happens,
which potentially could be faster than hard coded block numbers.

Ethereum Classic will become a stable protocol soon. When we
finished dealing with the monetary policy and finally the difficulty
bomb, ETC's protocol would become a rather stable one. This means most
of the new consensus hard fork would be new features of the network,
rather than fixing existing bugs. In that case, voting would be
important to keep the whole network healthy.

## Terms and conventions

The version bits used by this proposal for signaling deployment of
forks are referred to as 'signaling bits' or shortened to 'bits' where
unambiguous.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

## Specification

### Signaling bits

Ethereum's extraData field are 32-bytes, i.e. a 256-bit value. The
field itself should be a RLP list that follows:

For this ECIP, version should equal to 1, and signalingBits and
clientIdentity fulfill the rest of the extraData field as long as it
does not exceed the maximum size allowed. This allows us to have way
more concurrent signalings and better backward compatibility than
Bitcoin.

signalingBits are right-aligned, i.e. 0b1 has its bit at index 0
set, 0b10 has its bit at index 1 set, 0b100 has its bit at index 2
set.

### Deployment states

With each block and fork, we associate a deployment state. The
possible states are:
- DEFINED is the first state that each fork starts out as. The
 genesis block for any chain SHALL by definition be in this state for
 each deployment.
- STARTED for blocks past the starttime.
- LOCKEDIN after STARTED, if at least threshold out of windowsize
 blocks have the associated bit set in signalingBits in extraData
 block header, measured at next height that is evenly divisible by
 the windowsize.
- ACTIVE for all blocks after the grace period conditions have
 been met.
- FAILED if past the timeout time and LOCKEDIN was not reached.

In accordance with BIP9, a block's state SHALL never depend on its own
extraData; only on that of its ancestors.

### Fork deployment parameters

Each fork deployment is specified by the following per-chain
parameters:
- The name specifies a very brief description of the fork,
 reasonable for use as an identifier. For deployments described in a
 single BIP, it is recommended to use the name "bipN" where N is the
 appropriate BIP number.
- The bit determines which bit in the extraData field of the block
 is to be used to signal the fork deployment.
- The start specifies a block number at which the bit gains its
 meaning.
- The timeout specifies a time at which the deployment is
 considered failed. If the current block number >= (start + timeout)
 and the fork has not yet locked in (including this block's bit
 state), the deployment is considered failed on all descendants of
 the block.
- The windowsize specifies the number of past blocks (including
 the block under consideration) to be taken into account for locking
 in a fork.
- The threshold specifies a number of blocks, in the range of
 1..windowsize, which must signal for a fork in order to lock it
 in. The support is measured when the chain height is evenly
 divisible by the windowsize. If the windowsize is set to 2016 (as in
 BIP9) this coincides with the 2016-block re-targeting intervals.
- The minlockedblocks specifies a minimum number of blocks which a
 fork must remain in locked-in state before it can become
 active. Both minlockedblocks and minlockedtime (see below) must be
 satisfied before a fork can become active. If the current block
 number >= (minlockedblocks + the block number that locked in the
 fork), then the fork becomes activated.

### Tallying

If a block's extraData specifies a version other than 1, all its
signaling bits MUST be treated as if they are '0'.

A signaling bit value of '1' SHALL indicate support of a fork and
SHALL count towards its tally on a chain.

A signaling bit value of '0' SHALL indicate absence of support of a
fork and SHALL NOT count towards its tally on a chain.

The signaling bits SHALL be tallied whenever the head of the active
chain changes (including after reorganizations).

### State transitions

The following diagram illustrates the generalized state machine:

The genesis block of any chain SHALL have the state DEFINED for each
deployment.

A given deployment SHALL remain in the DEFINED state until it either
passes the start (and becomes STARTED) or the timeout time (and
becomes FAILED).

Once a deployment has STARTED, the signal for that deployment SHALL be
tallied over the the past windowsize blocks whenever a new block is
received on that chain.

A transition from the STARTED state to the LOCKEDIN state SHALL only
occur when all of these are true:
- The height of the received block is an integer multiple of the
 window size
- The current block number is below (start + timeout)
- At least threshold out of windowsize blocks have signaled support

A similar height synchronization precondition SHALL exist for the
transition from LOCKEDIN to ACTIVE. These synchronization conditions
are expressed by the "mod(height, windowsize) = 0" clauses in the
diagram.

A transition from LOCKEDIN to ACTIVE state SHALL only occur if the
height synchronization criterion is met and the below configurable
'grace period' conditions are fulfilled:
- Current height MUST be at least minlockedblocks above LOCKEDIN
 height

NOTE: If minlockedblocks is set to 0, then the fork will proceed
directly to ACTIVE state once the chain height reaches a multiple of
the windowsize.

The ACTIVE and FAILED states are terminal; a deployment stays in these
states once they are reached.

Deployment states are maintained along block chain branches. They need
re-computation when a reorganization happens.

### New consensus rules

New consensus rules deployed by a fork SHALL be enforced for each
block that has ACTIVE state.

### Optional operator notifications

An implementation SHOULD notify the operator when a deployment
transitions to STARTED, LOCKEDIN, ACTIVE or FAILED states.

It is RECOMMENDED that an implementation provide finer-grained
notifications to the operator which allow him/her to track the
measured support level for defined deployments.

An implementation SHOULD warn the operator if the configured (emitted)
nVersion has been overridden to contain bits set to '1' in
contravention of the above non-signaling recommendations for DEFINED
forks.

It is RECOMMENDED that an implementation warn the operator if no
signal has been received for a given deployment during a full
windowsize period after the deployment has STARTED. This could
indicate that something may be wrong with the operator's configuration
that is causing them not to receive the signal correctly.

For undefined signals, it is RECOMMENDED that implementation track
these and alert their operators with supportive upgrade notifications,
e.g.
- "warning: signaling started on unknown feature on version bit X"
- "warning: signaling on unknown feature reached X% (over last N
 blocks)"
- "info: signaling ceased on unknown feature (over last M blocks)"

Since parameters of these deployments are unknown, it is RECOMMENDED
that implementations allow the user to configure the emission of such
notifications (e.g. suitable N and M parameters in the messages above,
e.g. a best-guess window of 100 blocks).

## Rationale

The timeout into FAILED state allows eventual reuse of bits if a fork
was not successfully activated.

A fallow period at the conclusion of a fork attempt allows some
detection of buggy clients, and allows time for warnings and software
upgrades for successful forks. The duration of a fallow period is not
specified by this proposal, although a conventional fallow period of 3
months is RECOMMENDED.

## Guidelines

### Parameter selection guidelines

The following guidelines are suggested for selecting the parameters
for a fork:
- name SHOULD be selected such that no two forks, concurrent or
 otherwise, ever use the same name.
- bit SHOULD be selected such that no two concurrent forks use the
 same bit. Implementors should make an effort to consult resources
 such as [2] to establish whether the bit they wish to use can
 reasonably be assumed to be unclaimed by a concurrent fork, and to
 announce their use ('claim') of a bit for a fork purpose on various
 project mailing lists, to reduce chance of collisions.
- start SHOULD be set to some block number in the future,
 approximately one month after a software release date which includes
 the fork signaling. This allows for some release delays, while
 preventing triggers as a result of parties running pre-release
 software.
- timeout is RECOMMENDED to be a block number that is
 approximately 1 year after start.
- windowsize SHOULD be set large enough to allow reception of an
 adequately precise signal.
- threshold SHOULD be set as high as possible to ensure a smooth
 activation based on the estimated support and the nature of the
 proposed changes. It is strongly RECOMMENDED that threshold >=
 windowsize / 2 (rounded up) to ensure that a proposal is only
 activated by majority support.
- minlockedblocks is RECOMMENDED to be set >= windowsize, to
 ensure that a full window passes in LOCKEDIN state. Lower values
 will be ineffective as the transition from LOCKEDIN to ACTIVE is
 guarded by a synchronization based on the window size.

NOTE: If minlockedblocks is set to 0, then the fork will proceed to
ACTIVE state when the chain height reaches a multiple of the
windowsize.

A later deployment using the same bit is possible as long as the
starttime is after the previous fork's timeout or activation, but it
is discouraged until necessary, and even then recommended to have a
pause in between to detect buggy software.

### Signaling guidelines

An implementation SHOULD signal '0' on a bit if one of the following
holds true:
- The deployment parameters are not DEFINED (not configured or
 explicitly undefined)
- The deployment is DEFINED and has not yet reached the STARTED state
- The deployment has succeeded (it has become ACTIVE)
- The deployment has FAILED

An implementation SHOULD enable the operator to choose (override)
whether to signal '0' or '1' on a bit, once its deployment has at
least reached the STARTED state.

A supporting miner SHOULD signal '1' on a bit for which the deployment
is LOCKEDIN state so that uptake is visible. However, this has no
effect on consensus rules. Once LOCKED_IN, a deployment proceeds to
ACTIVE solely based on the configured grace period parameters (see
'Fork deployment parameters' above).

A miner SHOULD signal '0' on a bit if they wish to suspend signaling
of support for a fork that is DEFINED in their software.

It is NOT RECOMMENDED to signal '1' for bits where the meaning is
undefined (i.e. bits which are unclaimed by proposals).

## References

This ECIP is a realization of
27-MINERVOTE.

## License

This work is licensed under Apache License, Version
2.0.

## Abstract

A proposal to place a hard cap on the gaslimit for the ETC mainnet as an in-protocol
consensus rule. From the block that this ECIP was activated, gaslimit would follow a
curve defined in this proposal rather than being subject to miner voting.

## Rationale

There is nothing more important to the ETC network than security and decentralization.
Both of those desired characteristics have already been heavily compromised in ETC
because of the malincentives which ETC inherited from ETH in the form of the miner
gaslimit voting mechanism.

The gaslimit has been raised for the ETH mainnet first to 8M and then to 10M gas,
despite it being obvious that the client implementations cannot adequately cope with
the state trie growth that such a high gaslimit has created. ETH has been
"overclocked" and smoke is coming out of the engine. This long crisis was one of the
primary motivations for the ETH 1.x initiative which started around DEVCON4 in Prague
in October 2018. The crisis on ETH is still ongoing and still unresolved and is
affecting ETC too as well now.

The miner gaslimit voting is one-sided. There are no checks-and-balances. There is no voice
for the end-users who care about the long-term health of the network. There is only
a single "control knob" and the miners have control of that "control knob". They are
incentivized to vote the limit up to infinity, because fees rise if they do so.
Like over use of credit cards, the bill comes much later as a consequence of growth of the state
trie which makes it harder and harder to run a full node. For Ethash miners with
GPUs or FPGAs there is little consequence for them "killing the host". They can just
exit and go and mine some other coin if ETH or ETC become completely centralized and
unusable because of state bloat.

This malincentive has played out for ETH such that the ETH state tie is now so large
that full-sync-from-genesis is completely impractical and the disk usage is off the
charts for full nodes, let alone for archival nodes. Fully validating syncs for
ETH nodes are now a multi-month process.

Here is a recent example from Jeff Garzik on 15th January 2020 (it took him nearly 2 months):

https://twitter.com/jgarzik/status/1217488290900848640

Sync'd!
- Ethereum --syncmode=full node:
- Laptop w/ 8G ram, external 1TB USB 3.1 SSD
- Started: November 26, 2019
- Finished: January 13, 2020
- Storage used: 668G
- Docker container restarts, for hard fork geth upgrades: 2

ETH is completely reliant on Infura now and it is well known
(how serious a problem)[https://www.coindesk.com/the-race-is-on-to-replace-ethereums-most-centralized-layer]
that dependency on a single centralized and proprietary service provider is.

(Anthony Lusardi)[https://twitter.com/pyskell] proposed an appeal to the ETC miners to
voluntarily vote the gaslimit down to 1M in March - (ECIP-1047)[https://ecips.ethereumclassic.org/ECIPs/ecip-1047]
but that appeal has never happened, though might soon. A voluntary solution would
be a step in the right direction in terms of the effects, but it does not solve the
root issue which is the malincentive of the miner vote.

A protocol change to set a hard-cap would resolve the unsustainability issue for
ETC and bring the protocol into alignment with ETC philosophy, rejecting this bad
inheritance from ETH and back in line with Bitcoin's sustainable approach.
Unlike BTC however, we would define a long-term growth curve to reflect the
constantly improving hardware - even with the same protocol and same client
implementations.

## Specification

At block number ACTIVATIONBLOCK on ETC mainnet, switch the gas-limit calculation
to be one of the following two options:
1. gaslimit = INITIALGASLIMIT + (blocknumber - ACTIVATIONBLOCK) GASLIMITCURVERATE
2. gaslimit = INITIALGASLIMIT + (blocknumber - ACTIVATIONBLOCK) 2 ^ GASLIMITCURVERATE

Let ACTIVATIONBLOCK = TBD
Let INITIALGASLIMIT = 2,000,000 (subject to change)
Let GASLIMITCURVERATE = TBD

## Backwards compatibility

There is certainly a concern that some smart contracts which used to work will cease
to work (until some future point where the raising gaslimit makes them viable again)
and we need to quantify this risk.

There is a concern that it will not be possible to migrate ETH smart contracts to ETC
because of the lower gaslimit. Straw polls on Twitter seem to indicated that 1M or 2M
is adequate for most smart contracts out there for their heaviest transactions with the
sole exception of transactions for contract deployment, which can hit 4M or more. In
that case we have no answer yet other than spliting contracts up into multiple libraries.

It looks like some kind of "Webpack for Solidity" would be workable, where we could add
opcodes to deploy chunks of bytecode across several transactions, with new opcodes for
STARTDEPLOY, DEPLOYCHUNK and ENDDEPLOY or similar which could be used transparency
internal to the development framework (Truffle, Embark, Brownie, etc) and
compiler (SOLC, SOLL, Vyper, etc) to generate different bytecode depending on the
gaslimit of the target chain. This is just an idea for the time being and needs its
own new ECIP too.

Aragon is probably the perfect guinea pig for addressing these concerns because they have
large smart contracts and have just recently been the victim of backwards-compatibility
breaks in ETH as part of the Istanbul HF. If we can provide a great story for ETH to ETC
migration with well engineered changes spanning frameworks, compiler and runtime then
that will be a delightful win-win for all parties. As Jorge said, while breaking smart
contracts up is the right thing to do, it should not be REQUIRED. To require changes
to existing script is a break in the implicit social contract:

https://www.coindesk.com/ethereums-istanbul-upgrade-will-break-680-smart-contracts-on-aragon

### Implementation

There is no implementation of this proposal yet because we are missing the specific details
of the future gaslimit curve. That could either be linear growth or Moore's Law style
exponential growth.

The ETC Cooperative will fund implementations of this ECIP for Hyperledger Besu,
Parity-Ethereum and MultiGeth, including testnets and audits as required.

## Copyright

This work is licensed under the Apache License, Version 2.0. The author, Bob Summerwill, attests to his sole authorship of this work, and that he is able to contribute this work to the ECIP process under the Apache 2.0 licence.

He further attests that he neither holds nor is aware of any patents, trademarks, copyright issues or other IP hinderances associated with this work.

### Abstract

A proposal to replace Ethereum Classic proof of work algorithm with CPU-friendly RandomX should GPU-friendly Ethash be rejected from the network.

### Motivation

I am concerned with the centralized pro-ASIC movement in ECIP-1049 (and ECIP-1095) from a centralized body in ETC (ETC Coop, Commonwealth.gg, and EPIC Blockchain). I believe the self named SHA3 Coalition is not fully addressing the many concerns of miners/developers/end users regarding miner centralization, inflation capture, supply chain bottle necks, network security, interoperability with other EVMs, and a deviation from the core principles of Ethereum Classic network.

To date there are 27 meaningful unanswered comments written from high profile ETC network developers, large mining pools, small independent miners and independent end users. The champions of ECIP-1049 and ECIP-1095 proposals are not engaging these comments in their ECIP discussion threads. Due to the uncertainty of these unaddressed questions, a material opposition to ECIP-1049 has formed in the Ethereum Classic community.

It is my opinion that ECIP-1049, will not achieve the Rough Consensus requirement to push SHA3 ASIC on the network and Ethash GPU will likely prevail in that conversation. As an auxiliary path, this ECIP is being proposed to offer an alternative route to consumer product, decentralized mining via a CPU route.

Related ECIPs to the discussion:
- Do nothing. Stay on Ethash.
- ECIP-1043 Ethash GPU. https://github.com/ethereumclassic/ECIPs/issues/11
- ECIP-1049 SHA3 ASIC. https://github.com/ethereumclassic/ECIPs/issues/13 , https://github.com/ethereumclassic/ECIPs/issues/8
- ECIP-1095 SHA3 ASIC. https://github.com/ethereumclassic/ECIPs/issues/342
- ECIP-1099 Ethash GPU. https://github.com/ethereumclassic/ECIPs/issues/368

#### Withdrawn Status Update and Explanation

This topic has evolved rapidly since the date I originally submitted this proposal. As the author of ECIP-1093, I believe this ECIP is unnecessary at this point in time and request that it be moved to Withdrawn status. This ECIP became obsolete due to the materialization of a vocal opposition to changing the Ethereum Classic mining algorithm. Dexaran of Ethereum Commonwealth has committed development resources to the GPU-friendly Ethash chain should the ETC mining community chose to continue to mine Ethash ( https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-687297252 ). That means that any proposal to change the mining algorithm will likely end up in contention, which is against the goals of the ECIP process.

A non-exhaustive list of comments from a notable opposition to changing the Ethereum Classic mining algorithm from Ethash:

Sourced from ECIP-1095 Thread
- https://github.com/ethereumclassic/ECIPs/issues/342#issuecomment-685208360
- https://github.com/ethereumclassic/ECIPs/issues/342#issuecomment-685500623
- https://github.com/ethereumclassic/ECIPs/issues/342#issuecomment-685840814
- https://github.com/ethereumclassic/ECIPs/issues/342#issuecomment-686983866
- https://github.com/ethereumclassic/ECIPs/issues/342#issuecomment-687640021
- https://github.com/ethereumclassic/ECIPs/issues/342#issuecomment-687864802

Sourced from ECIP-1049 Threads
- https://github.com/ethereumclassic/ECIPs/pull/8#issuecomment-453714749
- https://github.com/ethereumclassic/ECIPs/pull/8#issuecomment-453086727
- https://github.com/ethereumclassic/ECIPs/pull/8#issuecomment-452459302
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-479955986
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-551256069
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-551309467
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-552100904
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-684070006
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-685309563
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-686250338
- https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-687297252

# Specification

The proposed solution refers to RandomX. This spec was sourced from the Monero Community. Thank you to all the wonderful researchers contributing to the goal of ASIC resistant algorithms.

# RandomX
RandomX is a proof-of-work (PoW) algorithm that is optimized for general-purpose CPUs. RandomX uses random code execution (hence the name) together with several memory-hard techniques to minimize the efficiency advantage of specialized hardware.

## Overview

RandomX utilizes a virtual machine that executes programs in a special instruction set that consists of integer math, floating point math and branches. These programs can be translated into the CPU's native machine code on the fly (example: program.asm). At the end, the outputs of the executed programs are consolidated into a 256-bit result using a cryptographic hashing function (Blake2b).

RandomX can operate in two main modes with different memory requirements:
- Fast mode - requires 2080 MiB of shared memory.
- Light mode - requires only 256 MiB of shared memory, but runs significantly slower

Both modes are interchangeable as they give the same results. The fast mode is suitable for "mining", while the light mode is expected to be used only for proof verification.

## Documentation

Full specification is available in specs.md.

Design description and analysis is available in design.md.

## Audits

Between May and August 2019, RandomX was audited by 4 independent security research teams:
- Trail of Bits (28 000 USD)
- X41 D-SEC (42 000 EUR)
- Kudelski Security (18 250 CHF)
- QuarksLab (52 800 USD)

The first audit was generously funded by Arweave, one of the early adopters of RandomX. The remaining three audits were funded by donations from the Monero community. All four audits were coordinated by OSTIF.

Final reports from all four audits are available in the audits directory. None of the audits found any critical vulnerabilities, but several changes in the algorithm and the code were made as a direct result of the audits. More details can be found in the final report by OSTIF.

## Build

RandomX is written in C++11 and builds a static library with a C API provided by header file randomx.h. Minimal API usage example is provided in api-example1.c. The reference code includes a randomx-benchmark and randomx-tests executables for testing.

### Linux

Build dependencies: cmake (minimum 2.8.7) and gcc (minimum version 4.8, but version 7+ is recommended).

To build optimized binaries for your machine, run:

To build portable binaries, omit the ARCH option when executing cmake.

### Windows

On Windows, it is possible to build using MinGW (same procedure as on Linux) or using Visual Studio (solution file is provided).

### Precompiled binaries

Precompiled randomx-benchmark binaries are available on the Releases page.

## Proof of work

RandomX was primarily designed as a PoW algorithm for Monero. The recommended usage is following:
- The key K is selected to be the hash of a block in the blockchain - this block is called the 'key block'. For optimal mining and verification performance, the key should change every 2048 blocks (~2.8 days) and there should be a delay of 64 blocks (~2 hours) between the key block and the change of the key K. This can be achieved by changing the key when blockHeight % 2048 == 64 and selecting key block such that keyBlockHeight % 2048 == 0.
- The input H is the standard hashing blob with a selected nonce value.

RandomX was successfully activated on the Monero network on the 30th November 2019.

If you wish to use RandomX as a PoW algorithm for your cryptocurrency, please follow the configuration guidelines.

Note: To achieve ASIC resistance, the key K must change and must not be miner-selectable. We recommend to use blockchain data as the key in a similar way to the Monero example above. If blockchain data cannot be used for some reason, use a predefined sequence of keys.

### CPU performance
The table below lists the performance of selected CPUs using the optimal number of threads (T) and large pages (if possible), in hashes per second (H/s). "CNv4" refers to the CryptoNight variant 4 (CN/R) hashrate measured using XMRig v2.14.1. "Fast mode" and "Light mode" are the two modes of RandomX.

|CPU|RAM|OS|AES|CNv4|Fast mode|Light mode|
|---|---|--|---|-----|------|--------------|
Intel Core i9-9900K|32G DDR4-3200|Windows 10|hw|660 (8T)|5770 (8T)|1160 (16T)|
AMD Ryzen 7 1700|16G DDR4-2666|Ubuntu 16.04|hw|520 (8T)|4100 (8T)|620 (16T)|
Intel Core i7-8550U|16G DDR4-2400|Windows 10|hw|200 (4T)|1700 (4T)|350 (8T)|
Intel Core i3-3220|4G DDR3-1333|Ubuntu 16.04|soft|42 (4T)|510 (4T)|150 (4T)|
Raspberry Pi 3|1G LPDDR2|Ubuntu 16.04|soft|3.5 (4T)|-|20 (4T)|

Note that RandomX currently includes a JIT compiler for x86-64 and ARM64. Other architectures have to use the portable interpreter, which is much slower.

### GPU performance

SChernykh is developing GPU mining code for RandomX. Benchmarks are included in the following repositories:
- CUDA miner - NVIDIA GPUs.
- OpenCL miner - only for AMD Vega and AMD Polaris GPUs (uses GCN machine code).

The code from the above repositories is included in the open source miner XMRig.

Note that GPUs are at a disadvantage when running RandomX since the algorithm was designed to be efficient on CPUs.

# FAQ

### Which CPU is best for mining RandomX?

Most Intel and AMD CPUs made since 2011 should be fairly efficient at RandomX. More specifically, efficient mining requires:
- 64-bit architecture
- IEEE 754 compliant floating point unit
- Hardware AES support (AES-NI extension for x86, Cryptography extensions for ARMv8)
- 16 KiB of L1 cache, 256 KiB of L2 cache and 2 MiB of L3 cache per mining thread
- Support for large memory pages
- At least 2.5 GiB of free RAM per NUMA node
- Multiple memory channels may be required:

### Does RandomX facilitate botnets/malware mining or web mining?

Due to the way the algorithm works, mining malware is much easier to detect. RandomX Sniffer is a proof of concept tool that can detect illicit mining activity on Windows.

Efficient mining requires more than 2 GiB of memory, which also disqualifies many low-end machines such as IoT devices, which are often parts of large botnets.

Web mining is infeasible due to the large memory requirement and the lack of directed rounding support for floating point operations in both Javascript and WebAssembly.

### Since RandomX uses floating point math, does it give reproducible results on different platforms?

RandomX uses only operations that are guaranteed to give correctly rounded results by the IEEE 754 standard: addition, subtraction, multiplication, division and square root. Special care is taken to avoid corner cases such as NaN values or denormals.

The reference implementation has been validated on the following platforms:
- x86 (32-bit, little-endian)
- x86-64 (64-bit, little-endian)
- ARMv7+VFPv3 (32-bit, little-endian)
- ARMv8 (64-bit, little-endian)
- PPC64 (64-bit, big-endian)

### Can FPGAs mine RandomX?

RandomX generates multiple unique programs for every hash, so FPGAs cannot dynamically reconfigure their circuitry because typical FPGA takes tens of seconds to load a bitstream. It is also not possible to generate bitstreams for RandomX programs in advance due to the sheer number of combinations (there are 2 512 unique programs).

Sufficiently large FPGAs can mine RandomX in a soft microprocessor configuration by emulating a CPU. Under these circumstances, an FPGA will be much less efficient than a CPU or a specialized chip (ASIC).

## Acknowledgements
- tevador - author
- SChernykh - contributed significantly to the design of RandomX
- hyc - original idea of using random code execution for PoW
- Other contributors

RandomX uses some source code from the following 3rd party repositories:
- Argon2d, Blake2b hashing functions: https://github.com/P-H-C/phc-winner-argon2

The author of RandomX declares no competing financial interest.

## Donations

If you'd like to use RandomX, please consider donating to help cover the development cost of the algorithm.

Author's XMR address:

Total donations received: ~3.86 XMR (as of 30th August 2019). Thanks to all contributors.

### Simple Summary

This protocol upgrade provides a backward compatibility foundation to
enable future protocol upgrades to be applied with significantly lower
chance of breaking existing contracts.

### Abstract

This document proposes the following blocks at which to implement the
changes specified in "Specification" section.
- Undecided on Ethereum Classic PoW-mainnet.

### Specification

At hard fork block, enable EIP-1702:
- Define the previous EVM version as version 0.
- Define a new version 1, with the following EVM modifications
 applied on it.
- 39-UNGAS: Remove all
- 40-UNUSED: Disable

### Discussion

#### Feature Upgrades

Once the hard fork is enabled, future feature upgrades can be applied
directly on version 1, without the need to define additional new
versions. This simplifies client maintainence, which was one of the
main resistence to apply EIP-1702 in Istanbul.

Any gas cost changes can be applied without worry about backward
compatibility issues, because gas cost is now an unobservable behavior
in EVM. Any addition of opcodes can be applied without worry about
backward compatibility issues, because deployment of unused opcode is
disabled. This nearly covers all EVM upgrade paths we need to care
about.

#### Ecosystem

It is possible to deploy a helper contract to allow version 0
contracts continue to be created. This allows unmodified Solidity code
to be deployed, just like what we have now.

However, for version 1, because we made several changes related to
gas cost, which impacts the semantics of certain opcodes such as
CALL and CREATE, Solidity compiler must be modified to support
version 1.

Existing common practices might need to change as well. Some practices
relies on the observable behavior of gas cost. Relying on gas cost is
usually considered to be a bad practice because gas cost can and will
change.

On the other hand, version 1 enables some new practices that wasn't
possible before. For example, a contract can now refuse to be invoked
by any other contracts.

#### Emergency Hard Fork

Our current gas cost scheme might contain DoS attack vectors. If those
attack vectors must be fixed by changing existing gas cost schemes,
then it must change gas costs specified in version 0. In those
emergency hard fork scenarios, we will inevitably break backward
compatibility.

## License

This work is licensed under Apache License, Version
2.0.

- In reference to: EIP-150
- Concerning: Long-term gas cost changes for IO-heavy operations to
 mitigate transaction spam attacks

## With the understanding that:
1. This is a fork intended for protocol improvement.
2. This is mutually beneficial to all etherem clients in order to mitigate current attacks.
3. Ethcore and Ethereum Foundation intend to implement the changes in
 unison on or around block 2,463,000
4. An unknown number of ETC nodes are using --oppose-dao clients and
 will be switched to the EIP gas price model at block 2,463,000

## Issues to address:
1. The need to avoid silverware drawer of ethereums:
- EF Official
- EF Official- no eip 150 fork
- EF TheDao Classic (accepted 1920k but ignored GasReprice, not upgraded nodes basically)
- ETC Early GasReprice, block 2,463,000 (uses upgraded EF version of geth with --oppose-dao flag)
- ETC Late GasReprice, block 2500000 (uses etc version 2.0.0 client)
- Ethereum Classic Classic (doomed) no forks ever from homestead
2. Urgency - this needs to be ready for testing as soon as humanly possible.
3. MAKE THE PLAN KNOWN. on all channels. smoke signals as need be.

## Proposed actions:
1. MAKE KNOWN TO EVERYONE WHAT THE DECISION IS AND PUBLISH REQUIRED CHANGES IN ACCEPTED ECIP.
2. Incorporate EIP-150 as ECIP-1015, to follow our process
3. Attempt to reach agreement with EF devs to either support etc flag forking on 2,500,000, or disable –oppose-dao-fork switch completely (absent that, an active campaign to get people to upgrade to classic geth)
4. Get parity buy-in to make a new release supporting our HF (which would require a PR be submited for json config change)
5. Implement ECIP-1015 on top of our 2.0.0 geth code base, test it
6. Release new classic geth version, promote its usage heavily among ETC users, as well as with pools, exchanges, and wallets that support ETC
7. Hard fork on block 2,500,000 ~2016-10-25

## License

This work is licensed under Apache License, Version
2.0.

### Simple Summary

Enable the outstanding Ethereum Foundation Berlin network protocol upgrades on
the Ethereum Classic network in a hard-fork code-named Magneto to enable
maximum compatibility across these networks.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the
Ethereum Foundation (ETH) network via the Berlin hardforks. The proposed
changes for Ethereum Classic's Berlin upgrade include:
- Reprices the gas cost of the ModExp (0x00..05) precompile.
- Increases gas cost for SLOAD, CALL, BALANCE, EXT, and
 SELFEDESTRUCT when used for the first time in a transaction.
- Defines a new transaction type that is an envelope for future transaction
 types.
- Adds a transaction type which contains an access list, a list of addresses
 and storage keys that the transaction plans to access.

This document proposes the following blocks at which to implement these changes
in the Classic networks:
- 3985893 on Mordor Classic PoW-testnet (June 2nd, 2021)
- 4368634 on Kotti Classic PoA-testnet (June 9th, 2021)
- 13189133 on Ethereum Classic PoW-mainnet (July 21st, 2021)

For more information on the opcodes and their respective EIPs and
implementations, please see the Specification section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes
shall be added to the Ethereum Classic networks, all of which have been in use
on the Ethereum Foundation networks since early 2021.

### Specification

Technical specifications for each EIP can be found at those documents
respectively:
- EIP-2565: ModExp Gas Cost
- EIP-2929: Gas cost increases for
 state access opcodes
- EIP-2718: Typed Transaction
 Envelope
- EIP-2930: Optional access lists

### Rationale

_Interoperability: Establishing and maintaining interoperable behavior
between Ethereum clients is essential for developers and end-user adoption,
yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and
Mordor, Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the
potential to change the behavior of existing contracts; in the case where
previously an arbitrary invalid bytecode would have been deployed to the
network, none of them would be able to modify the state of the Ethereum Classic
networks retrospectively. Adding opcodes to the EVM increases its functionality
and should be considered a feature upgrade rather than a modification.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces
changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Berlin
features currently and will be able to support the Magneto_ upgrade:
- Core-Geth (maintained by ETC Core)
- Hyperledger Besu (maintained by ConsenSys)

The Mantis client (maintained by IOHK) plans to eventually support the upgrade, but will not so do by the time of the hardfork.

## Copyright

Copyright and related rights waived via
CC0.

## Abstract

Define a function arbitrating chain acceptance using relative total difficulty and common ancestor time to raise finality confidence.

Update (January 2024): Replaced with ECBP-1110.

## Motivation

A low hashrate has caused Ethereum Classic's consensus algorithms to yield inconvenient and undesirable finality rates.

This proposal offers a way to increase the finality rate without tampering with existing "hard" chain consensus functions or characteristics, and to do so with minimal negative side effects.

## Specification

### General

This proposal is built on a proposed core principle to Ethereum Classic neatly summed as:
Small reorgs are normal and healthy; large reorgs are suspicious. Given a reorg of unusual length, nodes should value their local (first-available) segment with preference over the later proposed segment, despite that it may have greater difficulty. Source

What follows is an algorithm and implementation details toward a way to realize this opinion programmatically as convention for network clients.

### Specific

#### Conceptual translation
- > Small reorgs are normal and healthy; large reorgs are suspicious.

Conceptions of "small" and "large" are described functionally by the "suspicious" curve; a reorg becomes "big" when it becomes suspicious, and vice versa. This is parameterized by time and total difficulty. Generally, anything less than about 10 minutes won't be suspicious, and thus is considered "small."
- > nodes should value their local (first-available) segment with preference over the later proposed segment

Valuation is conventionalized as the difference between treating a block as a canonical head versus treating it like a side chain. In both cases the block data is stored and may be propagated. Miners normally only mine on top of blocks they consider to be canonical.

#### Algorithm details

This specification for subjective arbitration of chain segments based on availability cardinality, segment duration, and difficulty is provided which may be implemented by nodes to deter and avoid suspicious reorganizations.

This specification falls outside of existing consensus protocol. With that, the need for congruent implementation(s) across protocol providers (aka clients) on the network is important to avoid observable or actionable variances in implementation that might present a risk to network coherence (whether by malicious intention or accident).

This specification should be applied in the client wherever total difficulty is used to evaluate a block's candidacy for the head of the chain database. In etclabscore/core-geth this occurs in the BlockChain.writeBlockWithState and its caller BlockChain.insertChain methods.

This specification should be applied only given the condition of a positive outcome for the existing subjective arbitration cases described below.

In the case of a negative result from the arbitration, blocks should be deferred from receiving status as canonical, but still be stored as a sidechain. This, as opposed to outright rejection for failing blocks, permits segments which have not but may eventually achieve sufficient difficulty to maintain practical eligibility for canonical status.

#### Existing Subjective Arbitrations

This specification assumes _existing extra-protocol behavior as:
- preference of self-mined blocks for proposed blocks having equal total difficulty and number
- then, a 50% randomized acceptance rate for proposed blocks having equal total difficulty and number, per Eyal and Sirer

These evaluations are implemented at the etclabscore/core-geth and ethereum/go-ethereum clients as:
https://github.com/etclabscore/core-geth/blob/eb8bbb02a5b1516ab181a49117c970270532aa03/core/blockchain.go#L1525, https://github.com/ethereum/go-ethereum/blob/129cf075e963df10f42da81d817a4c12f7d4bf16/core/blockchain.go#L1518
https://github.com/etclabscore/core-geth/blob/129cf075e963df10f42da81d817a4c12f7d4bf16/eth/backend.go#L379-431, https://github.com/ethereum/go-ethereum/blob/129cf075e963df10f42da81d817a4c12f7d4bf16/eth/backend.go#L359-L411

#### Proposed Additional Subjective Arbitration

As a successor to established chain reorganization arbitration, the following logic should be added.
- A polynomial function ecbp1100PolynomialV is defined which implements a cubic curve as the "antigravity" of a proposed chain segment.
- A condition function ecbp11100 applies this value as a required total difficulty ratio for proposed chain segments over their local alternative.

Polynomial ecbp1100PolynomialV
Source: https://github.com/ethereumclassic/ECIPs/issues/374#issuecomment-694156719

Condition ecbp1100

### Code

This is implemented in the etclabscore/core-geth Go(lang) client as follows.

## Rationale

This is a modified (M) version of Buterin's Exponential Subjective Scoring (ESS) by
- using a capped polynomial function instead of an unbounded exponential function
- using the difference of local head time(stamp) from common ancestor time(stamp), rather than the previously described block lengths or times of block reception used by Buterin.

See References for what I've found on the topic.

#### The Case and Place of Subjectivity

This specification maintains the (modified) GHOST protocol as an invariant; existing consensus rules are not modified nor sidestepped. Modified only is the schedule (ie "pace", "timeline") at which clients choose to implement these established procedures. The heaviest (most difficult) chain will -- still -- always, eventually, win. Proposed only is to make clients somewhat stubborn in their opinion and processing of chains; it makes them sluggish and resistant to big changes. It gives them a (temporary) opinion.

Opinions are allowed under GHOST and the rest of Ethereum's Yellow Paper (and Satoshi's email chains). Nowhere is it specified that blocks must be imported or included immediately, nor that a miner must mine on the heaviest chain available to them, nor that submitted transactions must be processed, nor that blocks must be propagated regularly.

The normal functioning of the chain is explained (as in rationalized) by some game theory and economics, but it is not subject to it. Miners are not forced (as in caused by the protocol) to mine on the heaviest chain available to them; they normally do so because they bet that that will turn out to be profitable for them. But sometimes mining on the heaviest chain may not be profitable for them; like if the heaviest chain was apparently made by a criminal, and perpetuating that association may lower the exchange rate of their reward. Miners can mine on whatever chain they want, can include whatever transactions they want, and can process, propagate, postpone, or ignore blocks however they want; all without offending Satoshi or his idolators.

In consideration here is a proposal of CONVENTION for network participants that is designed to keep the network as unified as possible while describing an opinion (implemented as algorithm) that prevents big ugly late-coming chain segments from being immediately and automatically accepted.

This is functionally no different than a thought experiment where the human miners are watching their nodes day-in and day-out, every minute, arbitrating with their own personal opinions about whether or not to allow geth to mine on top of block 10550798. Again, they are allowed to do this. They can do this. Sometimes they do do this. This proposal is a specification of a way that they can make this same order of decisions, but with the help of some math, a computer, and heuristics that will allow them to do it in coordination without requiring the use of the world's most boring conference call.

In fact, one of the first evolutions of this proposal was made by @BelfordZ:
When geth wants to reorganize its existing chain for a too-long or too-old chain segment, have it just send an email to its operator saying: Geth has found a suspicious chain segment and requires a human's wisdom and advice... and then turn off.

Except for a few fancy bells and whistles (ie maybe not shutting down... :)), and a proposed CONVENTION for determining suspicion, these proposals are more alike than different.

Network participants are allowed to be stubborn curmudgeons with opinions. ECIP1100 wants to help them do that gracefully.

#### Benefits
- Mini-forks and normal reorganizations are not effected, since their difficulty variances fall within the curve in this domain (200 seconds, give or take).
- There is no Edge-of-Eternity attack vector (no vulnerable focal points for an attacker to target).
- Partitions resolve quickly and consistently.
- Intentional partitions are extremely difficult to establish and maintain.
- The polynomial function yields a "ceiling" that would be extravagantly high for an attacker to achieve relative to the main network, but within reasonable operating bounds for the victim of an eclipse attack to eventually recover and rejoin the network. Unbounded exponential growth for the antigravity function serves no purpose beyond some point.

The graphs below show a 200 block chain accepting, sidechaining ~~or rejecting~~ reorganizations of varying relative difficulty and length.

#### Costs
- Nodes subject to eclipse attacks (mostly considered as nodes coming online after a long time or starting out) are vulnerable to destitution, even once released. This is addressed by the function's ceiling causing the attacker to need to establish (and maintain) a total difficulty 1/31x of the competing honest chain, and can be addressed further by the operator including a checkpoint value.
- It may be anticipated that the network uncle and waste rates will rise slightly, as blocks that would otherwise be randomly included will be rejected. ETC currently has a 3.5% uncle rate compared to ETH's 5.5%.
- A network vulnerability resulting in bifurcation exists given the condition that competing segments become available with near-equal total difficulty within the window of the antigravity curve allowance. This state of balance must be maintained until the antigravities force the network partitions to reject each other's segments. If a state of near-perfect balance in total difficulty between the partitions can be maintained, this bifurcated state shall be indefinite. However, achieving and maintaining a balanced competition between segments can be seen to be extraordinarily challenging, expensive, and ultimately unlikely. Confounding variables for an attacker in this scenario are normal network hashrate variability, network propagation times and protocol, disproportionate mining entity hashpower share, unpredictable block times, and existing subjective arbitration steps.

#### Discussion of Constant Parameters

The polynomial function uses constant parameters xcap = 2pi/8000 and amplitude = 15, the values of which are reasoned as follows.

The x cap value of 2pi/8000 causes the peak of the curve (and ultimate ceiling) to occur at 25132 seconds (approximately 7 hours). This falls in between the rates of the previously considered exponential functions. The "ramp up" domain (nearest x=0) sees a flattened curve, yielding a more generous lenience for competing short segments. The curve eventually intersects the original exponential function at about 900 seconds (15 minutes) at about y=1.09.

The amplitude value of 15 causes the peak to occur at (215)+1 = 31. This value means that the maximum "antigravity" an attack will face is a 31, where the proposed chain would need a total difficulty 31 times that of the chain it would replace.

These values were chosen for ETC with the following assumptions and reasoning.
- Assume global Ethash hashrate availability is 200TH.
- Assume greatest single Ethash mining entity is 33% of the global, yielding about 66TH. This is considered as the largest possible antagonist for the ETC chain.
- Assume ETC has 3TH total contributed hashrate.
- Following this, we deduce that the largest Ethash mining entity has 22 times of ETC's current mining power. An "attack" by this entity on ETC would result in a (66/(66+3))100 = 95% attack.
- Given a 22x anticipated "reasonable" worst-case scenario, the amplitude of 15 yielding a total 31 ceiling, around 50% above the anticipated worst-case scenario, is intended to be sufficiently future-proof and resilient to unforeseen scenarios.

#### Alternatives Considered

An bounded exponential function would work in much the same way, although it would not have a continuous ceiling transition and would, in a far-edge case, present an exploitable focal point of vulnerability at that transition.

## Implementation

This feature does not require a hard fork, but the network stands to benefit and avoid risk with majority coordinated acivation.

Core-Geth
- Feature is tentatively proposed to activate in Core-Geth on Ethereum Classic network at and above block 11380000 (ETA 09 October 2020).
- Feature is proposed to activate in Core-Geth on Ethereum Classic's Mordor test network at and above block 2380000 (ETA 29 September 2020).
- Core-Geth feature implementation includes a few additional safety mechanisms:
- MESS is disabled for any sync mode besides full sync.
- MESS is only enabled once a peer has completed initial chain synchronisation, not while they are fast syncing or even full syncing during the download and process phase. This reduces the chances of a node coming online being lured into an eclipse scenario.
- MESS is only enabled if a peer has greater than or equal to the MinimumSyncPeers peers. In Core-Geth this value is by default 5.
- MESS is disabled if, once synced, a node's head block is not changed within a time limit (ie becomes stale). In Core-Geth this value is by default 30 * 13 seconds.

The associated Core-Geth implementation is available here.

### Testing

Cross client tests are included as assets as "first" and "second" RLP-encoded chain segments. A genesis configuration is provided describing the necessary chain and genesis configuration.

The file names describe the test, as well as providing expectations for the outcome of the second chain import via the suffix secondWins-true vs. secondWins-false.

## References
- https://bitcointalk.org/index.php?topic=865169.msg16349234#msg16349234
- https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/

Bespoke previously considered exponential functions:

A further alternative is demonstrated with a cosin_ function as follows, which, being squared, has an even flatter "ramp up" section. However, since difficulty adjustment is discrete and the
primary case of consideration in this context is one of equivalent difficulty, efforts toward an ultra-low
antigravity product seem well-intentioned but practically ineffectual.

Likewise, the exponents in the currently specified polynomial may be adjusted to modify the shape of the curve (increasing them will flatten it).

This ECIP defines methods that can be adopted to merge two
Ethereum-like blockchains together.

Note that this ECIP is purely an exploration of technical
possibilities, and it does not mean the author endorse merging
Ethereum and Ethereum Classic, or any other two blockchains together.

## Simple Summary

We define methods to merge multiple blockchains together, in a fully
backward compatible way.

## Abstract

This defines how Ethereum merging can happen, with backward
compatibility in mind. This is done by utilizing account versioning
together with transaction replay protection. We also define three
additional opcodes to allow merged chains to work across two sides of
state.

## Motivation

There are many reasons why we may want to merge multiple Ethereum
(eth1.x) blockchains together. For example, there may have been chain
splits of a blockchain, where later the community issues are resolved,
and we want to avoid a permanent split due to a temporary issue. It
may also be two completely distinct blockchains that want to merge in
order to share proof of work, or to improve inter-chain communication.

## Specification

The merge process happens at fork block, where we have a merger
chain and a mergee chain. At fork height, a miner should mine both
a merger chain's block, and a mergee chain's block. For those two
blocks:
- Both of them should have no transactions.
- Merger chain's fork height block and mergee chain's fork height
 block should have its state root processed as normal.
- Merger chain's fork height block should set its extra data field to
 mergee chain's fork height block's state root. The same for mergee
 chain's fork height block.
- After mergee chain's fork height block, its proof of work should be
 abandoned. That is, updated miners should not continue to mine
 mergee chain any more.

### State Root

For the block after merger chain's fork height block, the state root
meaning is changed to be hash of concatenating merger chain's original
state root, and mergee chain's original state root.

### Block Rewards

Use merger chain's original block rewards. And mine coinbase always to
the merger chain's side of the state.

### Transactions and Account Versioning

After merge, transactions with both chain ids are considered valid on
the merger chain. We define two account versions, one with merger
chain's original EVM config, and one with mergee chain's original EVM
config. Accessing accounts originally from either chain should use
ECIP-1040's account versioning rules. We define how accounts are
referred on the merged blockchain below:
- For end user interface, prefix 0x01 for accounts on the merger
 chain, and prefix 0x02 for accounts on the mergee chain.
- The transaction format is unchanged with addresses using original
 format. We distinguish whether a transaction operates on merger chain
 or mergee chain by its chain id. None replay protected transactions
 must be disabled prior to merging.
- All original opcodes CALL, CREATE are unchanged, where it only
 accesses accounts on the same originating chain.

### Cross the Merger and Mergee Chain Boundary

Define factor P // Q, which determines how coins are exchanged on
merger chain and mergee chain. Define three new opcodes MCALL,
MCREATE and MCREATE2. They function the same as CREATE, CALL
and CREATE2 with the same gas cost, except that it calls accounts on
the other side of the state. Values V to be exchanged are computed as
V P // Q from merger side of state to mergee side of state, and
V Q // P from mergee side of state to merger side of state.

## Rationale

This ECIP accomplishes the chain merge by concatenating two blockchain's
state root. In clients, this can be represented as a simple depth one
binary merkle tree where root's left is the merger state, and root's
right is the mergee state. We use account versioning and transaction
replay protection to make it backward compatible for full nodes,
without changing any internal address representation or transaction
representation. We then define additional opcodes to make two sides
communicatable.

## Backwards Compatibility

This ECIP is fully backward compatible for EVM and account states. It
is not backward compatible for light client state proof verification,
because an additional binary merkle tree is added.

## Test Cases

To be added.

## Implementation

To be added.

## Reference

This specification is a realization of
37-MERGE.

## Copyright

This work is licensed under Apache License, Version
2.0.

### Abstract
This meta document is agnostic to any mining algorithm. Its sole purpose is specifying a process how to openly determine and select a mining algorithm for Ethereum Classic.

### Motivation
The decision to change the Ethereum Classic mining algorithm - or to keep it as is - is not an easy one to make. It should be done by broad consensus with all stakeholders involved - miners, investors, application and core developers, and anyone else who feels they have a stake in ETC. This meta document proposes a process of how to facilitate the potential change of the mining algorithm and parameters.

### Available Options
Currently, the following options are debatable.
- ECBP-1076-A: "Ethash Status Quo." The mining algorithm will be untouched as it is since genesis, as Ethash function with a statically increasing DAG.
- ECBP-1076-B: "Ethash Limited DAG." The mining algorithm will be untouched as it is since genesis, as Ethash function. However, the DAG size will be limited as specified in ECIP-1043.
- ECBP-1076-C: "Keccak256 (SHA3)." The mining algorithm will be changed to Keccak256 as specified in ECIP-1049.
- ECBP-1076-D: "ProgPoW." The mining algorithm will be changed to ProgPow as specified in ECIP-1070.

Eventually, the community has to decide on one.

### Process
The following process facilitates all stakeholders in various stages.
1. "Tech Stage." Core and application developers meet in regular calls to evaluate the feasibility of the Ethash status quo, the limited DAG size proposal (ECIP-1043), the Keccak256 proposal (ECIP-1049), and the ProgPoW proposal (ECIP-1070).
2. "Miner Stage." Solo miners, mining farms, and mining pools can signal support by adjusting their mining node to signal in favor of one of the proposals that was promoted to "Last Call" state in the previous stage. Details on the signaling can be found in the subsequent section.
3. "Decision Stage." The proposal that passed the technical stage to "Last Call" state and received 70% approval by the miner community, shall be considered as "Accepted," all other competing proposals shall be considered as "Rejected." The EIP Editors are responsible to facilitate this status update to the proposals according to this process definition.

### Miner Signaling
The miner stage is specified as follows.

The miner prepend the miner's extra data with 5 bytes of signaling data which shall be recorded in the Ethereum Classic block headers. The 5 bytes contain the following:
1. Two start bytes that indicate a signal in terms of ECBP-1076, namely 76 (0x37 0x36)
2. One option byte that favors one of the proposals:
3. Two numeric bytes that vote on the default gas limit as specified in ECIP-1047.

In addition to the numeric vote on the gas limit with the extra data field, mining nodes are encouraged to utilize block gas target limit voting with the suitable configuration flags for their mining nodes.

No signaling favors the status quo (ECBP-1076-A) and effectively rejects ECIPs 1041, 1043, 1047, 1049, and 1070.

### Mining Node Configuration Examples
The following configuration examples do not favor one option over another and only serve the purpose of demonstration.

A Parity Ethereum node configured to vote for Keccak256 (ECBP-1076-C) not caring about the block gas limit:

A Multi-Geth node configured to vote for Ethash with DAG size limit (ECBP-1076-B) and a 1 million block gas limit (ECIP-1047):

A Besu node configured to vote for ProgPoW (ECBP-1076-D) and an increase of the block gas limit:

### Implementation
All clients implement custom extra data and block gas limit target voting. No custom implementation is required.

### Copyright/Licensing
Copyright and related rights waived via CC0.

## Rationale

This allows for efficient RSA verification inside of the EVM, as well as other forms of number theory-based cryptography. Note that adding precompiles for addition and subtraction is not required, as the in-EVM algorithm is efficient enough, and multiplication can be done through this precompile via a b = ((a + b)2 - (a - b)2) / 4.

The bit-based exponent calculation is done specifically to fairly charge for the often-used exponents of 2 (for multiplication) and 3 and 65537 (for RSA verification).

## Specification

### Parameters
- GQUADDIVISOR: 100

### Algorithm

At address 0x00......05, add a precompile that expects input in the following format:

Where every length is a 32-byte left-padded integer representing the number of bytes to be taken up by the next value. Call data is assumed to be infinitely right-padded with zero bytes, and excess data is ignored. Consumes floor(max(lengthofMODULUS, lengthofBASE) 2 max(ADJUSTEDEXPONENTLENGTH, 1) / GQUADDIVISOR) gas, and if there is enough gas, returns an output (BASE*EXPONENT) % MODULUS as a byte array with the same length as the modulus.

ADJUSTEDEXPONENTLENGTH is defined as follows.
- If lengthofEXPONENT 0, 2 -> 1, 3 -> 1, 255 -> 7, 256 -> 8).
- If lengthofEXPONENT > 32, then return 8 (lengthofEXPONENT - 32) plus the index of the highest bit in the first 32 bytes of EXPONENT (eg. if EXPONENT = \x00\x00\x01\x00.....\x00, with one hundred bytes, then the result is 8 (100 - 32) + 253 = 797). If all of the first 32 bytes of EXPONENT are zero, return exactly 8 (lengthofEXPONENT - 32).

For example, the input data:

Represents the exponent 3(2256 - 232 - 978) % (2256 - 232 - 977). By Fermat's little theorem, this equals 1, so the result is:

Returned as 32 bytes because the modulus length was 32 bytes. The ADJUSTEDEXPONENTLENGTH would be 255, and the gas cost would be 322 255 / 100 = 2611 gas (note that this is ~five thirds of the cost of using the EXP opcode to compute a 32-byte exponent). A 4096-bit RSA exponentiation would cost 5122 4095 / 100 = 10734796 gas in the worst case, though RSA verification in practice usually uses an exponent of 3 or 65537, which would reduce the gas consumption to 2621 or 41943, respectively.

This input data:

Would be parsed as a base of 0, exponent of 2256 - 232 - 978 and modulus of 2256 - 232 - 978, and so would return 0. Notice how if the lengthofBASE is 0, then it does not interpret any data as the base, instead immediately interpreting the next 32 bytes as lengthofEXPONENT.

This input data:

Would parse a base length of 0, a modulus length of 32, and an exponent length of 2256 - 1, where the base is empty, the modulus is 2256 - 2 and the exponent is (2*256 - 3) 256(2256 - 33) (yes, that's a really big number). It would then immediately fail, as it's not possible to provide enough gas to make that computation.

This input data:

Would parse as a base of 3, an exponent of 65535, and a modulus of 2255, and it would ignore the remaining 0x07 byte.

This input data:

Would also parse as a base of 3, an exponent of 65535 and a modulus of 2255, as it attempts to grab 32 bytes for the modulus starting from 0x80, but then there is no further data so it right pads it with 31 zeroes.

### Abstract

This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time.

### Motivation

At its core, the purpose of adjusting the current monetary policy of the ETC network, to a policy which places an upper bound on the number of tokens issued and decreases the rate at which ETC is introduced into the system over time, is to "bootstrap" the network’s security. By increasing the security of the network, a proper monetary policy indirectly nurtures the network, providing a secure platform for which smart contract development will be more likely to occur.

If we accept that speculation, a demand function, is the main economic driver of any new system, that the Ethereum Classic Network is a new system, and that speculation will drive the value of the Ethereum Classic token until the utility value of the Ethereum Classic token exceeds its speculative value, it is reasonable to assume that rewarding speculation will help to secure and nurture the network:

Large scale, high risk, and/or high profile applications will be less likely to be developed on a blockchain with weak security ie. a low hashrate. Increasing demand for the Ethereum Classic token will, all else being equal, increase the price of the Ethereum Classic token. An increase in the price of the token incentivizes mining operations to direct their efforts on the Ethereum Classic Network or to begin operations on the Ethereum Classic Network. The additional mining power that is directed towards the network, because of this incentive, further secures the network. An increase in the security of the network assists in building trust between the network and both current and potential users and developers of the network. This increase of trust in the network provides an incentive for large scale, high risk, and/or high profile applications to be developed on the network. Thus, rewarding speculation helps to secure and nurture the Ethereum Classic network.

Especially important to early stage cryptocurrencies, assuming all other variables are equal, a network with a decreasing rate of production and an upper bound on the number of tokens that will be issued will provide more incentive for high risk speculation to occur than one without a known rate of production or an upper bound.

Above all, it is important to recognize that a monetary policy does not directly create value for the network. A stable platform with useful applications and a vibrant community are the variables that drive value. The purpose of a properly structured monetary policy is to create an incentive for people to take a risk on a system that has not yet reached its full potential, providing an additional reason for those who may not otherwise be interested, who cannot or have not developed anything on the platform (yet), or who remain skeptical, to involve themselves in an otherwise nascent platform.

### Specification

#### Current Ethereum Classic Monetary Policy

Source

The current mining rewards on the Ethereum Classic Network are as follows:
- A "static" block reward for the winning block of 5 ETC
- An extra reward to the winning miner for including uncles as part of the block, in the form of an extra 1/32 (0.15625ETC) per uncle included, up to a maximum of two (2) uncles.
- A reward of up to 7/8 (4.375ETC) of the winning block reward for a miner who has mined an uncled block and has that uncle included in the winning block by the winning miner, up to a maximum of two (2) uncles included in a winning block.
- This reward structure is set to continue in perpetuity.

#### Proposed Ethereum Classic Monetary Policy

Source

An "Era" is defined as the number of blocks containing a given production rate.

The proposed mining rewards on the Ethereum Classic Network are as follows:
- Era 1 (blocks 1 - 5,000,000)
- Era 2 (blocks 5,000,001 - 10,000,000)
- Era 3+

### Rationale

Why this 5M20 model:
- Minimizes making the first adjustment too "exceptional." Other than equalizing all uncle rewards at block 5M, the changes/reductions to supply over time are equal.
- The model is easy to understand. Every 5M blocks, total reward is reduced by 20%.
- Uncle inclusion rates through block 5M will likely remain at around the 5%. Because of this, once block 5M is reached, in the worst case scenario (supply wise, which assumes two uncles included every block in perpetuity) the total supply will not exceed 210.7M ETC. Should the network remain as efficient in its ability to propagate found blocks as it has in Era 1 (5.4% uncle rate), the total supply will not be less than 198.5M ETC. This provides for an incentive to miners and client developers to maintain high standards and maintenance of their hardware and software they introduce into the network.
- The 5M model provides a balance between providing an acceptable depreciating distribution rate for rewarding high risk investment into the system and maintaining an active supply production over time. Maintaining this future supply rate keeps the potential price of the ethereum token suppressed enough to ensure transaction prices can remain lower than if the supply were to reduce to zero at an earlier date. This serves as a "blow off valve" for price increases in the case that a dynamic gas model cannot be implemented for the foreseeable future.
- Having the monetary policy begin at 5M provides a balance between delaying the implementation to provide enough time for code development and testing, and accelerating the implementation to provide an incentive to potential early adopters and high risk investors. Based on community discussion, beginning before block 4M is too soon for development, testing, and implementation of the policy, and later than block 6M is too long to interest many potential early adopters/investors.
- Not changing the monetary policy of ETC provides no benefit to risk taking early on in the life of the system, speculation wise. It will be difficult for the network to bootstrap its security. While bitcoin has what is considered to be the generally accepted ideal monetary policy, with its 50% reduction every four years, this model is not likely to yield optimal investment for ETC. If ETC were to adopt the bitcoin halving model, it is arguable that too much of the supply would be produced too soon: 50% of the estimated total ETC supply would be mined 75% sooner than traditional bitcoin because of the pre-mine of 72M ETC that was initially created in the genesis block. While the 5M model does not completely eliminate the effects of the premine, since 50% of total estimated production occurs sooner than would the bitcoin model, it makes up for this, to an extent, with its lengthening of the time until 90%, 99% and 100% of bitcoin are mined. The tail end of ETC production is longer and wider than bitcoin.
- In the current ETC reward schedule, the total reward for uncles is higher than the reward received by the miner who also includes uncles. In this state, a miner is significantly diluting the value of his reward by including these uncled blocks. By equalizing the rewards to uncle block miners with the rewards to miners who include an uncle block, the reward structure is more fairly distributed. In addition, equalizing the uncle rewards reduces the incentive for miners to set up an ETC "uncle farm," and instead drives them to better secure the network by competing for the latest "real block."
- Because the rate at which uncled blocks can vary with extreme, reducing the reward for uncle blocks assists considerably with being able to forecast the true upper bound of the total ETC that will ultimately exist in the system.
- The model is the best attempt at balancing the needs to incentivize high risk investment into the system in order to bootstrap security and create a potential user base, be easy to understand, include a reduction to the rate of production of ETC over time, include an upper bound on supply, provide for a long term production of the ETC token, and allow enough time for development, adoption, and awareness.

# Abstract

This ECIP proposes a precise specification for eventual rounding issues around
ECIP-1017 Monetary Policy calculation, particularly around
- block winner reward calculation
- block winner reward for including uncles
- block uncle miner reward for having uncles included in the winning block

The content of the proposal deals exclusively with reward calculation beginning with Era 2.

# Motivation
[@rtkacyk] In its current form, [ambiguity in the specification] may lead to different interpretations and implementations that may result in a network split in further eras. See these issues for details:
- https://github.com/ethereumproject/go-ethereum/issues/352
- https://github.com/paritytech/parity/issues/6523

# Solution

### Definitions
- In this document, the mathematic and code symbol / should be understood as a "floor divide," and any fractions using / (eg. 1/32) should not be interpreted as floating points.

### _Block winner reward calculation.

Block winner reward calculation for a given era should be rounded down only once.
This can be accomplished using exponentiation. In the following specifications around
uncles, use of this strategy will be assumed as well.

eg.

Reasoning: a block reward in this case is always singular, and era number is an essentially arbitrary constant (for any given bock). If the block reward for a given era n is rounded n times, the iterative rounding will eventually cause the final reward to atrophy. I see no reason for magnitude of era to "degrade" the singular block reward.

This, as opposed to the example below (which should NOT be used):
See Block winner comparison table for
expected rewards. Note that the discrepency would begin in era 22, where a single
rounding will yield 46116860184273879, and iterative rounding will yield 46116860184273878.

### Uncle rewards
- Rewards for both the winning block miner for including and uncles and the miner of the included uncle(s) should round down the winning block reward prior to division by 32 in the calculation of the uncle(s) "bonus" reward.
- The reward for uncles inclusion should reflect rounding per uncle, as opposed to rounding per "magnitude of uncles," which to say that an uncles inclusion reward is calculated using 1/32's (rounded down) of the block winner reward.

#### Block winner reward for including uncle(s).
- Uncle(s) inclusion reward should be calculated and rounded down prior to addition
 with the block winner reward.

eg.

And then either:

Or:

Reasoning: rounding down happens per uncle, since the reward in this case may be for one or two uncles. Otherwise, far in the future when rounding becomes an issue, a winning block with 2 uncles would get a proportionally higher per-uncle reward than a block with just one uncle. Since I don't see any reason to incentivize including 2 uncles over 1, I think calculation should be done per uncle.

This, as opposed to the example below (which should NOT be used):
See Block winner uncles inclusion reward comparison table for expected rewards. Note, for example, that era 22 yields a correct maximum block winner reward 48999163945790995 of 48999163945790996.

#### Block uncle miner reward for having an uncle(s) included in the winning block.
- Uses uncle(s) inclusion reward calculation as described in Uncle rewards.

Reasoning: Like Block winner reward for including uncles, without_ rounding
per uncle reward calculation, an uncle miner rewarded for 2 included blocks would
receive a proportionally higher per-uncle reward than for having only 1 uncle included.
There is no reason for such asymmetry.
See Uncle miner inclusion reward comparison table for expected rewards. Note, for example, that era 22 yields a correct maximum uncles miner reward of 2882303761517116, while an incorrect calculation yields 2882303761517117.

# Reward tables

## Expected overview

| Era | Block Winner Reward | 1 Uncle Reward | 2 Uncles Reward | Block Winner w/ 1 Uncle Reward | Block Winner w/ 2 Uncles Reward |
| --- | --- | --- | --- | --- | --- |
| 2 | 4000000000000000000 | 125000000000000000 | 250000000000000000 | 4125000000000000000 | 4250000000000000000 |
| 3 | 3200000000000000000 | 100000000000000000 | 200000000000000000 | 3300000000000000000 | 3400000000000000000 |
| 4 | 2560000000000000000 | 80000000000000000 | 160000000000000000 | 2640000000000000000 | 2720000000000000000 |
| 5 | 2048000000000000000 | 64000000000000000 | 128000000000000000 | 2112000000000000000 | 2176000000000000000 |
| 6 | 1638400000000000000 | 51200000000000000 | 102400000000000000 | 1689600000000000000 | 1740800000000000000 |
| 7 | 1310720000000000000 | 40960000000000000 | 81920000000000000 | 1351680000000000000 | 1392640000000000000 |
| 8 | 1048576000000000000 | 32768000000000000 | 65536000000000000 | 1081344000000000000 | 1114112000000000000 |
| 9 | 838860800000000000 | 26214400000000000 | 52428800000000000 | 865075200000000000 | 891289600000000000 |
| 10 | 671088640000000000 | 20971520000000000 | 41943040000000000 | 692060160000000000 | 713031680000000000 |
| 11 | 536870912000000000 | 16777216000000000 | 33554432000000000 | 553648128000000000 | 570425344000000000 |
| 12 | 429496729600000000 | 13421772800000000 | 26843545600000000 | 442918502400000000 | 456340275200000000 |
| 13 | 343597383680000000 | 10737418240000000 | 21474836480000000 | 354334801920000000 | 365072220160000000 |
| 14 | 274877906944000000 | 8589934592000000 | 17179869184000000 | 283467841536000000 | 292057776128000000 |
| 15 | 219902325555200000 | 6871947673600000 | 13743895347200000 | 226774273228800000 | 233646220902400000 |
| 16 | 175921860444160000 | 5497558138880000 | 10995116277760000 | 181419418583040000 | 186916976721920000 |
| 17 | 140737488355328000 | 4398046511104000 | 8796093022208000 | 145135534866432000 | 149533581377536000 |
| 18 | 112589990684262400 | 3518437208883200 | 7036874417766400 | 116108427893145600 | 119626865102028800 |
| 19 | 90071992547409920 | 2814749767106560 | 5629499534213120 | 92886742314516480 | 95701492081623040 |
| 20 | 72057594037927936 | 2251799813685248 | 4503599627370496 | 74309393851613184 | 76561193665298432 |
| 21 | 57646075230342348 | 1801439850948198 | 3602879701896396 | 59447515081290546 | 61248954932238744 |
| 22 | 46116860184273879 | 1441151880758558 | 2882303761517116 | 47558012065032437 | 48999163945790995 |
| 23 | 36893488147419103 | 1152921504606846 | 2305843009213692 | 38046409652025949 | 39199331156632795 |
| 24 | 29514790517935282 | 922337203685477 | 1844674407370954 | 30437127721620759 | 31359464925306236 |
| 25 | 23611832414348226 | 737869762948382 | 1475739525896764 | 24349702177296608 | 25087571940244990 |
| 26 | 18889465931478580 | 590295810358705 | 1180591620717410 | 19479761741837285 | 20070057552195990 |
| 27 | 15111572745182864 | 472236648286964 | 944473296573928 | 15583809393469828 | 16056046041756792 |
| 28 | 12089258196146291 | 377789318629571 | 755578637259142 | 12467047514775862 | 12844836833405433 |
| 29 | 9671406556917033 | 302231454903657 | 604462909807314 | 9973638011820690 | 10275869466724347 |
| 30 | 7737125245533626 | 241785163922925 | 483570327845850 | 7978910409456551 | 8220695573379476 |
| 31 | 6189700196426901 | 193428131138340 | 386856262276680 | 6383128327565241 | 6576556458703581 |
| 32 | 4951760157141521 | 154742504910672 | 309485009821344 | 5106502662052193 | 5261245166962865 |
| 33 | 3961408125713216 | 123794003928538 | 247588007857076 | 4085202129641754 | 4208996133570292 |
| 34 | 3169126500570573 | 99035203142830 | 198070406285660 | 3268161703713403 | 3367196906856233 |
| 35 | 2535301200456458 | 79228162514264 | 158456325028528 | 2614529362970722 | 2693757525484986 |
| 36 | 2028240960365167 | 63382530011411 | 126765060022822 | 2091623490376578 | 2155006020387989 |
| 37 | 1622592768292133 | 50706024009129 | 101412048018258 | 1673298792301262 | 1724004816310391 |
| 38 | 1298074214633706 | 40564819207303 | 81129638414606 | 1338639033841009 | 1379203853048312 |
| 39 | 1038459371706965 | 32451855365842 | 64903710731684 | 1070911227072807 | 1103363082438649 |
| 40 | 830767497365572 | 25961484292674 | 51922968585348 | 856728981658246 | 882690465950920 |
| 41 | 664613997892457 | 20769187434139 | 41538374868278 | 685383185326596 | 706152372760735 |
| 42 | 531691198313966 | 16615349947311 | 33230699894622 | 548306548261277 | 564921898208588 |
| 43 | 425352958651173 | 13292279957849 | 26584559915698 | 438645238609022 | 451937518566871 |
| 44 | 340282366920938 | 10633823966279 | 21267647932558 | 350916190887217 | 361550014853496 |
| 45 | 272225893536750 | 8507059173023 | 17014118346046 | 280732952709773 | 289240011882796 |
| 46 | 217780714829400 | 6805647338418 | 13611294676836 | 224586362167818 | 231392009506236 |
| 47 | 174224571863520 | 5444517870735 | 10889035741470 | 179669089734255 | 185113607604990 |
| 48 | 139379657490816 | 4355614296588 | 8711228593176 | 143735271787404 | 148090886083992 |
| 49 | 111503725992653 | 3484491437270 | 6968982874540 | 114988217429923 | 118472708867193 |
| 50 | 89202980794122 | 2787593149816 | 5575186299632 | 91990573943938 | 94778167093754 |

## Block winner reward comparison

| Era | CORRECT (exponentiation) | INCORRECT (eg. looping) |
| --- | --- | --- |
| 2 | 4000000000000000000 | 4000000000000000000 |
| 3 | 3200000000000000000 | 3200000000000000000 |
| 4 | 2560000000000000000 | 2560000000000000000 |
| 5 | 2048000000000000000 | 2048000000000000000 |
| 6 | 1638400000000000000 | 1638400000000000000 |
| 7 | 1310720000000000000 | 1310720000000000000 |
| 8 | 1048576000000000000 | 1048576000000000000 |
| 9 | 838860800000000000 | 838860800000000000 |
| 10 | 671088640000000000 | 671088640000000000 |
| 11 | 536870912000000000 | 536870912000000000 |
| 12 | 429496729600000000 | 429496729600000000 |
| 13 | 343597383680000000 | 343597383680000000 |
| 14 | 274877906944000000 | 274877906944000000 |
| 15 | 219902325555200000 | 219902325555200000 |
| 16 | 175921860444160000 | 175921860444160000 |
| 17 | 140737488355328000 | 140737488355328000 |
| 18 | 112589990684262400 | 112589990684262400 |
| 19 | 90071992547409920 | 90071992547409920 |
| 20 | 72057594037927936 | 72057594037927936 |
| 21 | 57646075230342348 | 57646075230342348 |
| 22 | 46116860184273879 | 46116860184273878 |
| 23 | 36893488147419103 | 36893488147419102 |
| 24 | 29514790517935282 | 29514790517935281 |
| 25 | 23611832414348226 | 23611832414348224 |
| 26 | 18889465931478580 | 18889465931478579 |
| 27 | 15111572745182864 | 15111572745182863 |
| 28 | 12089258196146291 | 12089258196146290 |
| 29 | 9671406556917033 | 9671406556917032 |
| 30 | 7737125245533626 | 7737125245533625 |
| 31 | 6189700196426901 | 6189700196426900 |
| 32 | 4951760157141521 | 4951760157141520 |
| 33 | 3961408125713216 | 3961408125713216 |
| 34 | 3169126500570573 | 3169126500570572 |
| 35 | 2535301200456458 | 2535301200456457 |
| 36 | 2028240960365167 | 2028240960365165 |
| 37 | 1622592768292133 | 1622592768292132 |
| 38 | 1298074214633706 | 1298074214633705 |
| 39 | 1038459371706965 | 1038459371706964 |
| 40 | 830767497365572 | 830767497365571 |
| 41 | 664613997892457 | 664613997892456 |
| 42 | 531691198313966 | 531691198313964 |
| 43 | 425352958651173 | 425352958651171 |
| 44 | 340282366920938 | 340282366920936 |
| 45 | 272225893536750 | 272225893536748 |
| 46 | 217780714829400 | 217780714829398 |
| 47 | 174224571863520 | 174224571863518 |
| 48 | 139379657490816 | 139379657490814 |
| 49 | 111503725992653 | 111503725992651 |
| 50 | 89202980794122 | 89202980794120 |

## Block winner uncles inclusion reward comparison
This table and the next deal exclusively with the reward for 2 uncles, since that's the only case
where rounding discrepencies will happen. These numbers assume use of the CORRECT block
winner reward calculation.

| Era | CORRECT Block Winner Reward w/ 2 Uncles | INCORRECT Block Winner Reward w/ 2 Uncles |
| --- | --- | --- |
| 2 | 4250000000000000000 | 4250000000000000000 |
| 3 | 3400000000000000000 | 3400000000000000000 |
| 4 | 2720000000000000000 | 2720000000000000000 |
| 5 | 2176000000000000000 | 2176000000000000000 |
| 6 | 1740800000000000000 | 1740800000000000000 |
| 7 | 1392640000000000000 | 1392640000000000000 |
| 8 | 1114112000000000000 | 1114112000000000000 |
| 9 | 891289600000000000 | 891289600000000000 |
| 10 | 713031680000000000 | 713031680000000000 |
| 11 | 570425344000000000 | 570425344000000000 |
| 12 | 456340275200000000 | 456340275200000000 |
| 13 | 365072220160000000 | 365072220160000000 |
| 14 | 292057776128000000 | 292057776128000000 |
| 15 | 233646220902400000 | 233646220902400000 |
| 16 | 186916976721920000 | 186916976721920000 |
| 17 | 149533581377536000 | 149533581377536000 |
| 18 | 119626865102028800 | 119626865102028800 |
| 19 | 95701492081623040 | 95701492081623040 |
| 20 | 76561193665298432 | 76561193665298432 |
| 21 | 61248954932238744 | 61248954932238744 |
| 22 | 48999163945790995 | 48999163945790996 |
| 23 | 39199331156632795 | 39199331156632796 |
| 24 | 31359464925306236 | 31359464925306237 |
| 25 | 25087571940244990 | 25087571940244990 |
| 26 | 20070057552195990 | 20070057552195991 |
| 27 | 16056046041756792 | 16056046041756793 |
| 28 | 12844836833405433 | 12844836833405434 |
| 29 | 10275869466724347 | 10275869466724347 |
| 30 | 8220695573379476 | 8220695573379477 |
| 31 | 6576556458703581 | 6576556458703582 |
| 32 | 5261245166962865 | 5261245166962866 |
| 33 | 4208996133570292 | 4208996133570292 |
| 34 | 3367196906856233 | 3367196906856233 |
| 35 | 2693757525484986 | 2693757525484986 |
| 36 | 2155006020387989 | 2155006020387989 |
| 37 | 1724004816310391 | 1724004816310391 |
| 38 | 1379203853048312 | 1379203853048312 |
| 39 | 1103363082438649 | 1103363082438650 |
| 40 | 882690465950920 | 882690465950920 |
| 41 | 706152372760735 | 706152372760735 |
| 42 | 564921898208588 | 564921898208588 |
| 43 | 451937518566871 | 451937518566871 |
| 44 | 361550014853496 | 361550014853496 |
| 45 | 289240011882796 | 289240011882796 |
| 46 | 231392009506236 | 231392009506237 |
| 47 | 185113607604990 | 185113607604990 |
| 48 | 148090886083992 | 148090886083992 |
| 49 | 118472708867193 | 118472708867193 |
| 50 | 94778167093754 | 94778167093754 |
| 51 | 75822533675003 | 75822533675003 |
| 52 | 60658026940002 | 60658026940002 |
| 53 | 48526421552000 | 48526421552001 |
| 54 | 38821137241600 | 38821137241601 |
| 55 | 31056909793280 | 31056909793281 |
| 56 | 24845527834624 | 24845527834624 |
| 57 | 19876422267699 | 19876422267699 |
| 58 | 15901137814158 | 15901137814159 |
| 59 | 12720910251326 | 12720910251327 |
| 60 | 10176728201061 | 10176728201061 |
| 61 | 8141382560849 | 8141382560849 |
| 62 | 6513106048679 | 6513106048679 |
| 63 | 5210484838942 | 5210484838943 |
| 64 | 4168387871154 | 4168387871154 |
| 65 | 3334710296923 | 3334710296923 |
| 66 | 2667768237538 | 2667768237538 |
| 67 | 2134214590029 | 2134214590030 |
| 68 | 1707371672024 | 1707371672024 |
| 69 | 1365897337619 | 1365897337619 |
| 70 | 1092717870095 | 1092717870095 |
| 71 | 874174296076 | 874174296076 |
| 72 | 699339436860 | 699339436861 |
| 73 | 559471549488 | 559471549488 |
| 74 | 447577239590 | 447577239591 |
| 75 | 358061791671 | 358061791672 |
| 76 | 286449433337 | 286449433337 |
| 77 | 229159546669 | 229159546670 |
| 78 | 183327637335 | 183327637335 |
| 79 | 146662109867 | 146662109868 |
| 80 | 117329687894 | 117329687894 |
| 81 | 93863750314 | 93863750315 |
| 82 | 75091000251 | 75091000252 |
| 83 | 60072800200 | 60072800201 |
| 84 | 48058240160 | 48058240161 |
| 85 | 38446592128 | 38446592128 |
| 86 | 30757273703 | 30757273703 |
| 87 | 24605818961 | 24605818962 |
| 88 | 19684655169 | 19684655169 |
| 89 | 15747724134 | 15747724135 |
| 90 | 12598179307 | 12598179308 |
| 91 | 10078543446 | 10078543446 |
| 92 | 8062834756 | 8062834757 |
| 93 | 6450267806 | 6450267806 |
| 94 | 5160214244 | 5160214244 |
| 95 | 4128171394 | 4128171395 |
| 96 | 3302537115 | 3302537116 |
| 97 | 2642029692 | 2642029693 |
| 98 | 2113623753 | 2113623754 |
| 99 | 1690899002 | 1690899003 |
| 100 | 1352719201 | 1352719202 |
| 101 | 1082175362 | 1082175362 |
| 102 | 865740288 | 865740289 |
| 103 | 692592230 | 692592231 |
| 104 | 554073783 | 554073784 |
| 105 | 443259027 | 443259027 |
| 106 | 354607222 | 354607222 |
| 107 | 283685777 | 283685777 |
| 108 | 226948621 | 226948621 |
| 109 | 181558896 | 181558897 |
| 110 | 145247118 | 145247118 |
| 111 | 116197694 | 116197694 |
| 112 | 92958154 | 92958154 |
| 113 | 74366523 | 74366524 |
| 114 | 59493218 | 59493219 |
| 115 | 47594574 | 47594574 |
| 116 | 38075659 | 38075659 |
| 117 | 30460526 | 30460527 |
| 118 | 24368422 | 24368422 |
| 119 | 19494736 | 19494737 |
| 120 | 15595789 | 15595790 |
| 121 | 12476630 | 12476631 |
| 122 | 9981304 | 9981305 |
| 123 | 7985044 | 7985044 |
| 124 | 6388035 | 6388035 |
| 125 | 5110427 | 5110428 |
| 126 | 4088342 | 4088342 |
| 127 | 3270673 | 3270673 |
| 128 | 2616539 | 2616539 |
| 129 | 2093230 | 2093231 |
| 130 | 1674584 | 1674585 |
| 131 | 1339668 | 1339668 |
| 132 | 1071733 | 1071734 |
| 133 | 857387 | 857387 |
| 134 | 685908 | 685909 |
| 135 | 548727 | 548727 |
| 136 | 438981 | 438981 |
| 137 | 351183 | 351184 |
| 138 | 280948 | 280948 |
| 139 | 224757 | 224758 |
| 140 | 179806 | 179806 |
| 141 | 143844 | 143845 |
| 142 | 115075 | 115076 |
| 143 | 92059 | 92060 |
| 144 | 73648 | 73648 |
| 145 | 58917 | 58918 |
| 146 | 47134 | 47134 |
| 147 | 37708 | 37708 |
| 148 | 30166 | 30166 |
| 149 | 24131 | 24132 |
| 150 | 19304 | 19305 |
| 151 | 15444 | 15444 |
| 152 | 12355 | 12355 |
| 153 | 9883 | 9884 |
| 154 | 7906 | 7907 |
| 155 | 6326 | 6326 |
| 156 | 5059 | 5060 |
| 157 | 4048 | 4048 |
| 158 | 3238 | 3238 |
| 159 | 2590 | 2590 |
| 160 | 2071 | 2072 |
| 161 | 1656 | 1657 |
| 162 | 1326 | 1326 |
| 163 | 1060 | 1060 |
| 164 | 847 | 848 |
| 165 | 677 | 678 |
| 166 | 541 | 542 |
| 167 | 433 | 434 |
| 168 | 347 | 347 |
| 169 | 277 | 277 |
| 170 | 221 | 222 |
| 171 | 177 | 177 |
| 172 | 142 | 142 |
| 173 | 113 | 113 |
| 174 | 89 | 90 |
| 175 | 72 | 72 |
| 176 | 56 | 57 |
| 177 | 45 | 45 |
| 178 | 37 | 37 |
| 179 | 28 | 29 |
| 180 | 22 | 23 |
| 181 | 17 | 18 |
| 182 | 14 | 14 |
| 183 | 11 | 11 |
| 184 | 9 | 9 |
| 185 | 7 | 7 |
| 186 | 5 | 5 |
| 187 | 4 | 4 |
| 188 | 3 | 3 |
| 189 | 3 | 3 |
| 190 | 2 | 2 |
| 191 | 1 | 1 |
| 192 | 1 | 1 |
| 193 | 1 | 1 |
| 194 | 0 | 0 |
| 195 | 0 | 0 |
| 196 | 0 | 0 |
| 197 | 0 | 0 |
| 198 | 0 | 0 |
| 199 | 0 | 0 |
| 200 | 0 | 0 |

## Uncle miner inclusion reward comparison
Like above, this table deals exclusively with the reward for a miner of 2 uncles
having those 2 uncles included in the winning block. Inclusion of 2 uncles is
the only case where alternate rounding strategies can produce a discrepency,
given constant block winner reward rounding.

| Era | CORRECT Uncle Miner w/ 2 Uncles Reward | INCORRECT Uncle Miner w/ 2 Uncles Reward |
| --- | --- | --- |
| 2 | 250000000000000000 | 250000000000000000 |
| 3 | 200000000000000000 | 200000000000000000 |
| 4 | 160000000000000000 | 160000000000000000 |
| 5 | 128000000000000000 | 128000000000000000 |
| 6 | 102400000000000000 | 102400000000000000 |
| 7 | 81920000000000000 | 81920000000000000 |
| 8 | 65536000000000000 | 65536000000000000 |
| 9 | 52428800000000000 | 52428800000000000 |
| 10 | 41943040000000000 | 41943040000000000 |
| 11 | 33554432000000000 | 33554432000000000 |
| 12 | 26843545600000000 | 26843545600000000 |
| 13 | 21474836480000000 | 21474836480000000 |
| 14 | 17179869184000000 | 17179869184000000 |
| 15 | 13743895347200000 | 13743895347200000 |
| 16 | 10995116277760000 | 10995116277760000 |
| 17 | 8796093022208000 | 8796093022208000 |
| 18 | 7036874417766400 | 7036874417766400 |
| 19 | 5629499534213120 | 5629499534213120 |
| 20 | 4503599627370496 | 4503599627370496 |
| 21 | 3602879701896396 | 3602879701896396 |
| 22 | 2882303761517116 | 2882303761517117 |
| 23 | 2305843009213692 | 2305843009213693 |
| 24 | 1844674407370954 | 1844674407370955 |
| 25 | 1475739525896764 | 1475739525896764 |
| 26 | 1180591620717410 | 1180591620717411 |
| 27 | 944473296573928 | 944473296573929 |
| 28 | 755578637259142 | 755578637259143 |
| 29 | 604462909807314 | 604462909807314 |
| 30 | 483570327845850 | 483570327845851 |
| 31 | 386856262276680 | 386856262276681 |
| 32 | 309485009821344 | 309485009821345 |
| 33 | 247588007857076 | 247588007857076 |
| 34 | 198070406285660 | 198070406285660 |
| 35 | 158456325028528 | 158456325028528 |
| 36 | 126765060022822 | 126765060022822 |
| 37 | 101412048018258 | 101412048018258 |
| 38 | 81129638414606 | 81129638414606 |
| 39 | 64903710731684 | 64903710731685 |
| 40 | 51922968585348 | 51922968585348 |
| 41 | 41538374868278 | 41538374868278 |
| 42 | 33230699894622 | 33230699894622 |
| 43 | 26584559915698 | 26584559915698 |
| 44 | 21267647932558 | 21267647932558 |
| 45 | 17014118346046 | 17014118346046 |
| 46 | 13611294676836 | 13611294676837 |
| 47 | 10889035741470 | 10889035741470 |
| 48 | 8711228593176 | 8711228593176 |
| 49 | 6968982874540 | 6968982874540 |
| 50 | 5575186299632 | 5575186299632 |
| 51 | 4460149039706 | 4460149039706 |
| 52 | 3568119231764 | 3568119231764 |
| 53 | 2854495385410 | 2854495385411 |
| 54 | 2283596308328 | 2283596308329 |
| 55 | 1826877046662 | 1826877046663 |
| 56 | 1461501637330 | 1461501637330 |
| 57 | 1169201309864 | 1169201309864 |
| 58 | 935361047890 | 935361047891 |
| 59 | 748288838312 | 748288838313 |
| 60 | 598631070650 | 598631070650 |
| 61 | 478904856520 | 478904856520 |
| 62 | 383123885216 | 383123885216 |
| 63 | 306499108172 | 306499108173 |
| 64 | 245199286538 | 245199286538 |
| 65 | 196159429230 | 196159429230 |
| 66 | 156927543384 | 156927543384 |
| 67 | 125542034706 | 125542034707 |
| 68 | 100433627766 | 100433627766 |
| 69 | 80346902212 | 80346902212 |
| 70 | 64277521770 | 64277521770 |
| 71 | 51422017416 | 51422017416 |
| 72 | 41137613932 | 41137613933 |
| 73 | 32910091146 | 32910091146 |
| 74 | 26328072916 | 26328072917 |
| 75 | 21062458332 | 21062458333 |
| 76 | 16849966666 | 16849966666 |
| 77 | 13479973332 | 13479973333 |
| 78 | 10783978666 | 10783978666 |
| 79 | 8627182932 | 8627182933 |
| 80 | 6901746346 | 6901746346 |
| 81 | 5521397076 | 5521397077 |
| 82 | 4417117660 | 4417117661 |
| 83 | 3533694128 | 3533694129 |
| 84 | 2826955302 | 2826955303 |
| 85 | 2261564242 | 2261564242 |
| 86 | 1809251394 | 1809251394 |
| 87 | 1447401114 | 1447401115 |
| 88 | 1157920892 | 1157920892 |
| 89 | 926336712 | 926336713 |
| 90 | 741069370 | 741069371 |
| 91 | 592855496 | 592855496 |
| 92 | 474284396 | 474284397 |
| 93 | 379427518 | 379427518 |
| 94 | 303542014 | 303542014 |
| 95 | 242833610 | 242833611 |
| 96 | 194266888 | 194266889 |
| 97 | 155413510 | 155413511 |
| 98 | 124330808 | 124330809 |
| 99 | 99464646 | 99464647 |
| 100 | 79571716 | 79571717 |
| 101 | 63657374 | 63657374 |
| 102 | 50925898 | 50925899 |
| 103 | 40740718 | 40740719 |
| 104 | 32592574 | 32592575 |
| 105 | 26074060 | 26074060 |
| 106 | 20859248 | 20859248 |
| 107 | 16687398 | 16687398 |
| 108 | 13349918 | 13349918 |
| 109 | 10679934 | 10679935 |
| 110 | 8543948 | 8543948 |
| 111 | 6835158 | 6835158 |
| 112 | 5468126 | 5468126 |
| 113 | 4374500 | 4374501 |
| 114 | 3499600 | 3499601 |
| 115 | 2799680 | 2799680 |
| 116 | 2239744 | 2239744 |
| 117 | 1791794 | 1791795 |
| 118 | 1433436 | 1433436 |
| 119 | 1146748 | 1146749 |
| 120 | 917398 | 917399 |
| 121 | 733918 | 733919 |
| 122 | 587134 | 587135 |
| 123 | 469708 | 469708 |
| 124 | 375766 | 375766 |
| 125 | 300612 | 300613 |
| 126 | 240490 | 240490 |
| 127 | 192392 | 192392 |
| 128 | 153914 | 153914 |
| 129 | 123130 | 123131 |
| 130 | 98504 | 98505 |
| 131 | 78804 | 78804 |
| 132 | 63042 | 63043 |
| 133 | 50434 | 50434 |
| 134 | 40346 | 40347 |
| 135 | 32278 | 32278 |
| 136 | 25822 | 25822 |
| 137 | 20656 | 20657 |
| 138 | 16526 | 16526 |
| 139 | 13220 | 13221 |
| 140 | 10576 | 10576 |
| 141 | 8460 | 8461 |
| 142 | 6768 | 6769 |
| 143 | 5414 | 5415 |
| 144 | 4332 | 4332 |
| 145 | 3464 | 3465 |
| 146 | 2772 | 2772 |
| 147 | 2218 | 2218 |
| 148 | 1774 | 1774 |
| 149 | 1418 | 1419 |
| 150 | 1134 | 1135 |
| 151 | 908 | 908 |
| 152 | 726 | 726 |
| 153 | 580 | 581 |
| 154 | 464 | 465 |
| 155 | 372 | 372 |
| 156 | 296 | 297 |
| 157 | 238 | 238 |
| 158 | 190 | 190 |
| 159 | 152 | 152 |
| 160 | 120 | 121 |
| 161 | 96 | 97 |
| 162 | 78 | 78 |
| 163 | 62 | 62 |
| 164 | 48 | 49 |
| 165 | 38 | 39 |
| 166 | 30 | 31 |
| 167 | 24 | 25 |
| 168 | 20 | 20 |
| 169 | 16 | 16 |
| 170 | 12 | 13 |
| 171 | 10 | 10 |
| 172 | 8 | 8 |
| 173 | 6 | 6 |
| 174 | 4 | 5 |
| 175 | 4 | 4 |
| 176 | 2 | 3 |
| 177 | 2 | 2 |
| 178 | 2 | 2 |
| 179 | 0 | 1 |
| 180 | 0 | 1 |
| 181 | 0 | 1 |
| 182 | 0 | 0 |
| 183 | 0 | 0 |
| 184 | 0 | 0 |
| 185 | 0 | 0 |
| 186 | 0 | 0 |
| 187 | 0 | 0 |
| 188 | 0 | 0 |
| 189 | 0 | 0 |
| 190 | 0 | 0 |
| 191 | 0 | 0 |
| 192 | 0 | 0 |
| 193 | 0 | 0 |
| 194 | 0 | 0 |
| 195 | 0 | 0 |
| 196 | 0 | 0 |
| 197 | 0 | 0 |
| 198 | 0 | 0 |
| 199 | 0 | 0 |
| 200 | 0 | 0 |

### Simple Summary

Enable the outstanding Ethereum Foundation London network protocol upgrades on
the Ethereum Classic network in a hard-fork code-named Mystique to enable
maximum compatibility across these networks.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the
Ethereum Foundation (ETH) network via the London hardforks. The proposed
changes for Ethereum Classic's London upgrade include:

EIP | Eth PR | omit or include
-- | -- | --
3529 (Alternative refund reduction) | #22733 | Include
3541 (Reject new contracts starting with the 0xEF byte) | #22809 | Include
1559 (Fee market change) | #22837 #22896 | Omit
3198 (BASEFEE opcode) | #22837 | Omit
3228 (💣 delay) | #22840 and #22870 | Omit

The fee market change and bomb delay are omitted at this time as they are not applicable for Ethereum Classic. The fee market change puts the network at longterm risk since as ETC currently has a capped supply and fixed emmision epocs. The bomb was disarmed in ETC code base in a previous hardfork.

#### EIP Summaries and expected action
##### Included
- EIP 3529 "Alternative refund reduction" Remove gas refunds for SELFDESTRUCT, and reduce gas refunds for SSTORE to a lower level where the refunds are still substantial, but they are no longer high enough for current “exploits” of the refund mechanism to be viable.
- gas price should be adjusted on respective opcodes to reflect the new EVM standard
- EIP 3541 "Reject new contracts starting with the 0xEF byte": Disallow new code starting with the 0xEF byte to be deployed. Code already existing in the account trie starting with 0xEF byte is not affected semantically by this change.
- No future contracts shall be deployed on chain with 0xEF prefix. Clients should respond with an error message citing ECIP 1104 as justification of rejection.

##### Omitted
- EIP 1559 "Fee market change": A transaction pricing mechanism that includes fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with transient congestion.
- Undesirable to implement at this time as it would conflict with the current monetary policy set in ECIP-1017
- EIP 3198 "BASEFEE opcode": Adds an opcode that gives the EVM access to the block’s base fee.
- It depends on EIP-1559. Behavior specifications for use in context without EIP-1559 are undefined.
- EIP 3228 "💣 delay": Delays the difficulty bomb to show effect the first week of December 2021.
- Not applicable to ETC due to difficulty bomb being defused

This document proposes the following blocks at which to implement these changes
in the Classic networks:
- 5520000 on Mordor Classic PoW-testnet (Jan 13th 2022)
- 5578000 on Kotti Classic PoA-testnet (Jan 23th 2022)
- 14525000 on Ethereum Classic PoW-mainnet (Feb 13th 2022)

For more information on the opcodes and their respective EIPs and
implementations, please see the Specification section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes
shall be added to the Ethereum Classic networks, all of which have been in use
on the Ethereum Foundation networks since early 2021.

Specific to EIP 3529: Refunds are currently only applied after transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. Hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable.
#### Gas tokens will become valueless.

### Specification

Technical specifications for each EIP can be found at those documents
respectively:
- EIP-3198: BASEFEE opcode
- EIP-3529: Alternative refund reduction
- EIP-3541: Reject new contracts starting with the 0xEF byte
- EIP-1559: Fee market change
- EIP-3228: 💣 delay

### Rationale

_Interoperability: Establishing and maintaining interoperable behavior
between Ethereum clients is essential for developers and end-user adoption,
yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and
Mordor, Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the
potential to change the behavior of existing contracts; in the case where
previously an arbitrary invalid bytecode would have been deployed to the
network, none of them would be able to modify the state of the Ethereum Classic
networks retrospectively. Adding opcodes to the EVM increases its functionality
and should be considered a feature upgrade rather than a modification.

Standards Compliance: In order to guarantee that every EOF-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. New code starting with the 0xEF byte will not be deployable, and contract creation will result in a failure. However, given bytecode is executed starting at its first byte, code deployed with 0xEF as the first byte is not executable anyway.

While this means no currently executable contract is affected, it does rejects deployment of new data contracts starting with the 0xEF byte.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces
changes that are not backward compatible.

The following clients with Ethereum Classic support implement the London
features currently and will be able to support the Mystique_ upgrade:
- Core-Geth (maintained by ETC Core)
- Hyperledger Besu (maintained by ConsenSys)

## Copyright

Copyright and related rights waived via
CC0.

### Simple Summary

This ECIP defines the on-chain governance framework for Olympia DAO, the contract suite that authorizes and schedules the execution of approved actions affecting the Olympia Treasury (ECIP-1112).
Olympia DAO provides a modular governor, voting mechanism, and timelock executor. The DAO’s authorized execution path is the only route through which Treasury actions can be released.

Governance-layer upgrades — including voting-model selection, module replacement, and parameter adjustments — follow the Olympia Improvement Proposal (OIP) process defined in this ECIP.
Treasury disbursements are handled independently through the funding-proposal workflow specified in ECIP-1114.

Olympia launches without a governance token. Any future tokenization proposal must proceed through the OIP process and rely on the DAO’s standard approval and execution path.

### Abstract

This ECIP specifies the architecture of Olympia DAO, the on-chain governance system that acts as the sole authorized executor for actions affecting the immutable Olympia Treasury (ECIP-1112). The DAO is composed of a modular Governor, a voting mechanism, and a timelock executor, together forming the exclusive path permitted to invoke the Treasury’s withdrawal interface.

Olympia DAO does not define the funding proposal lifecycle. Treasury disbursements originate from the standardized process in ECIP-1114, while governance-layer upgrades — such as voting-model changes, parameter adjustments, or module replacement — are processed through the Olympia Improvement Proposal (OIP) mechanism.

This ECIP establishes the governance-execution architecture and access-control model used to authorize Treasury actions. The system follows a modular Governor pattern functionally comparable to the audited OpenZeppelin Governor and Timelock design, while remaining fully isolated from consensus-layer logic (ECIP-1111), Treasury implementation details (ECIP-1112), and proposal-content requirements (ECIP-1114).

### Motivation

ECIP-1112 defines an immutable Treasury with a restricted withdrawal interface.
To authorize any release of funds, an on-chain governance executor is required to verify approval, enforce execution delays, and perform the final call to the Treasury in a transparent and tamper-resistant manner.

A modular Governor architecture satisfies these requirements by providing:
- a verifiable, on-chain voting mechanism,
- a timelock that enforces delayed execution and public review, and
- a single, authorized execution contract permitted to call the Treasury’s withdrawal function.

Using a Governor pattern functionally comparable to the audited OpenZeppelin Governor and Timelock design minimizes attack surface, ensures predictable behavior, and allows governance parameters to evolve without modifying the Treasury or consensus rules.

To maintain clear modular boundaries within the Olympia framework:
- Treasury behavior is defined in ECIP-1112,
- the funding-proposal lifecycle and metadata rules are defined in ECIP-1114, and
- governance-layer upgrades — including voting-model changes, parameter updates, module replacement, or the creation of Child-DAO governance pipelines — proceed through the Olympia Improvement Proposal (OIP) process defined in this ECIP.

This separation enables Olympia DAO to evolve safely over time while preserving strict, auditable isolation between consensus logic, Treasury storage, proposal processing, and governance execution.

### Specification

#### 1. Governance Architecture

Olympia DAO SHALL be implemented as a modular, on-chain governance system deployed on Ethereum Classic.
Its sole protocol-level responsibility is to authorize withdrawals from the immutable Olympia Treasury (ECIP-1112) through a designated governance executor contract.

The governance system MUST include:
- Governor Module — proposal lifecycle and vote tallying
- Voting Module — computation of voting power
- Timelock Module — mandatory execution delay
- Executor Module — the only contract permitted to call Treasury withdrawal functions
- Upgrade Module (OIP) — governance-layer evolution
- Optional Modules — formally audited extensions (e.g., Child-DAOs, execution guards)

All modules MUST follow deterministic, auditable, non-privileged execution semantics.

#### 1.1 Governor Module

The Governor module SHALL implement governance behavior functionally equivalent to the audited OpenZeppelin Governor model, including:
- proposal lifecycle validation,
- immutable snapshot-block voting,
- one-vote-per-identity tallying,
- enforcement of quorum and approval thresholds,
- non-zero voting delay and voting period,
- queueing approved proposals into the timelock, and
- dispatching execution exclusively to the executor.

The Governor MAY be implemented in any language and MAY be customized, but MUST uphold all behavioral invariants of the OpenZeppelin Governor and SHALL NOT:
- bypass the timelock,
- permit execution without queueing, or
- allow a proposal to execute more than once.

Voting delay and voting period MUST be strictly greater than zero and MAY only be modified through the OIP process.

#### 1.2 Voting Module

The Voting Module SHALL define how voting power is computed and exposed to the Governor.

At launch, Olympia DAO SHALL implement a Sybil-resistant, ETC-domain-restricted, one-address-one-vote model where:
- each voter is represented by a unique eligible address,
- uniqueness and eligibility are provided by modular Sybil-resistance mechanisms (e.g., identity proofs or uniqueness attestations), and
- eligibility MUST require ETC-domain participation, preventing cross-ecosystem governance capture.

Sybil-resistance and domain-restriction layers SHALL be external modules.
The Governor MUST treat these layers as pure interfaces, embedding no identity logic internally.

The Voting Module MAY be replaced only via OIP.
Any future token-based or stake-weighted model introduced via OIP MUST NOT include:
- a premine,
- privileged allocation, or
- retroactive assignment outside OIP-approved parameters.

Any new voting-weight model MUST:
- integrate without modifying Treasury logic,
- preserve the Governor → Timelock → Executor → Treasury execution path,
- maintain ETC-domain restriction, and
- remain compliant with all invariants in this ECIP.

To prevent governance capture, the Sybil-resistance and domain-restriction modules SHALL enforce:
- minimum eligibility/identity-aging periods,
- ETC-specific contextual binding,
- non-transferable voting rights,
- participation-based activity requirements,
- decentralized attestation pipelines, and
- sustained ETC-ecosystem involvement.

No entity — including Child-DAOs, attestation providers, or external committees — MAY have unilateral authority over voter eligibility or OIP outcomes.

Child-DAO delegation MUST follow the same Sybil-resistance and ETC-domain rules and SHALL NOT introduce alternate eligibility pathways.

#### 1.3 Timelock Module

The Timelock Module SHALL:
- enforce a mandatory execution delay,
- expose queue/execute functions consistent with OpenZeppelin’s TimelockController,
- ensure queued actions CAN ONLY be executed after the delay,
- prevent immediate execution, and
- prevent re-execution of actions.

The timelock delay MUST be strictly greater than zero and MAY only be changed via OIP.

Only the Governor MAY queue operations.
Only the Timelock MAY authorize the executor to act.

If batching is supported, all batched actions MUST execute atomically or revert entirely, and all queued operations MUST be visible on-chain prior to execution.

#### 1.4 Executor Module

The Executor Module SHALL:
- be the sole authorized caller of Treasury withdrawal functions,
- receive operations from the Timelock,
- execute the final Treasury call, and
- revert any call not originating from the Timelock.

The Executor MAY NOT:
- initiate execution,
- bypass the Timelock,
- validate proposal content or metadata,
- execute arbitrary calls beyond scheduled operations,
- modify Governor state, or
- schedule new governance actions.

No EOA, multisig, contract, or Child-DAO MAY bypass the executor.

#### 2. Governance Upgrade Process (OIP)

All governance-layer evolution SHALL occur through the Olympia Improvement Proposal (OIP) process.
The OIP process SHALL be the exclusive pathway for modifying:
- voting models,
- governor parameters,
- timelock parameters,
- module implementations,
- executor upgrades,
- Child-DAO governance pipelines,
- governance extensions, or
- emergency-module behavior.

The OIP process MUST:
- operate as standard on-chain Governor proposals,
- follow the same voting → queueing → timelock → executor semantics as all governance actions, and
- NEVER bypass the executor for Treasury actions.

OIPs MUST preserve all invariants defined in this ECIP, and OIPs MUST NOT:
- modify ECIP-1112 Treasury immutability,
- modify ECIP-1111 consensus rules,
- set quorum/thresholds/delays to zero, or
- disable voting.

Any non-compliant OIP SHALL be invalid.

#### 3. Access Control & Treasury Interaction

The following SHALL be enforced:
- The Treasury SHALL designate exactly one authorized caller — the executor.
- Only actions processed by the Governor → Timelock → Executor pipeline MAY call Treasury withdrawal functions.
- Unauthorized calls MUST revert.
- Governance MUST NOT modify Treasury code, authorization rules, or immutability guarantees.

The executor address MAY ONLY be modified using procedures defined in ECIP-1112, not by governance defined in this ECIP.

Governance MUST treat Treasury functions as opaque and MUST NOT implement ECIP-1114 metadata logic.

#### 4. Proposal Semantics (Architecture Only)

ECIP-1113 defines only the governance-execution architecture, not proposal content.

Thus:
- Governance MUST expose interfaces for approving actions originating from ECIP-1114,
- MUST NOT interpret proposal metadata or funding logic, and
- SHALL operate strictly on action identifiers and execution payloads.

Funding lifecycle rules or proposal-content validation are out of scope for ECIP-1113.

#### 5. Optional Governance Modules

##### 5.1 Emergency Pause Module (Optional)

An Emergency Pause Module MAY be deployed via OIP.
Its scope SHALL be limited to:
- pausing queued (but not executed) actions,
- blocking timelock execution during emergencies, and
- initiating recovery-oriented OIPs.

It SHALL NOT:
- approve funding,
- execute withdrawals,
- modify Treasury logic, or
- override governance outcomes.

Pauses MUST be time-limited and revocable by OIP.
The module MUST NOT permanently disable governance or Treasury execution.

##### 5.2 Execution Guard Module (Optional)

An Execution Guard MAY:
- enforce deterministic runtime checks (e.g., batch limits, argument validation),
- reject malformed or invalid payloads.

It SHALL NOT:
- interpret metadata,
- inspect ECFP contents,
- depend on off-chain data,
- rely on multisig/committee decisions, or
- introduce discretionary veto power.

All checks MUST be deterministic, rule-based, and publicly specified.

#### 6. Child-DAO Governance Pipelines

Child-DAOs are governance modules, not funding mechanisms.
They MUST be registered and modified solely through OIP.

##### 6.1 Definition

A Child-DAO is a subordinate Governor-compatible module created to manage domain-specific governance tasks.

Child-DAOs:
- MAY propose actions to the main Governor,
- MAY aggregate domain-specific voting,
- MUST NOT call the Treasury, and
- MUST route all actions through the main Governor → Timelock → Executor pipeline.

##### 6.2 Creation & Modification

Child-DAOs:
- MUST be created, modified, or dissolved exclusively through OIP,
- MUST have strictly scoped authority,
- SHALL NOT bypass the main Governor, and
- MUST NOT control OIP outcomes.

##### 6.3 Architectural Requirements

Child-DAOs MUST:
- implement minimal Governor-equivalent logic,
- delegate Treasury authorization to the main DAO,
- emit transparent audit logs, and
- avoid circular delegation paths.

Child-DAO participation, membership, or domain rules are NOT defined here and MAY be governed by OIP or operational policy.

#### 7. Transparency Requirements

All governance modules MUST:
- emit standardized events for proposal creation, queueing, execution, and upgrades,
- preserve full on-chain auditability, and
- enable indexers to reconstruct governance state solely from event logs.

Treasury-specific events remain defined in ECIP-1112 and ECIP-1114.

#### 8. Prohibited Features

Governance contracts SHALL NOT:
- use proxy upgrades,
- use delegatecall for dynamic logic,
- include owner-only functions,
- include privileged multisigs or committees,
- allow off-chain entities to unilaterally approve or veto actions,
- read ECFP metadata,
- encode funding schedules or milestones, or
- modify Treasury state outside the executor’s authorized call.

Any implementation containing these features is non-compliant with ECIP-1113.

### Rationale

#### Modular, Security-Oriented Governance Architecture

The Olympia governance system is structured to preserve strict separation between governance execution, consensus behavior, and Treasury logic.
ECIP-1113 defines only the governance-execution architecture; ECIP-1112 defines the immutable Treasury, and ECIP-1114 defines the proposal lifecycle and metadata semantics.
This separation ensures that governance cannot modify Treasury rules or consensus behavior, and that Treasury spending cannot occur without governance-authorized execution.

A modular architecture—composed of Governor, Voting Module, Timelock, and Executor—reduces attack surface and aligns with extensively audited governance frameworks.
Requiring behavior functionally equivalent to the OpenZeppelin Governor and Timelock model provides predictable, verifiable lifecycle semantics that have been validated across high-value EVM systems.

#### Deterministic Execution and Invariant Preservation

A mandatory Governor → Timelock → Executor pipeline enforces deterministic execution.
This prevents:
- immediate or surprise execution,
- bypassing governance approval,
- modification of Treasury logic,
- unilateral action by multisigs or EOAs, and
- re-execution or conflicting execution of proposals.

These invariants ensure that proposal outcomes cannot be altered after voting concludes and that all execution paths remain transparent and auditable.

#### Sybil Resistance and Domain Restriction

One-address-one-vote governance is vulnerable to Sybil attacks, identity markets, infiltration, and cross-ecosystem governance raids.
ECIP-1113 therefore requires a modular Voting Module that incorporates:
- externally implemented Sybil resistance,
- ETC-domain participation requirements,
- identity-aging and uniqueness enforcement,
- non-transferable voting rights,
- periodic participation requirements,
- contextual ETC-specific attestation, and
- decentralized attestation sources.

These requirements ensure governance reflects sustained, legitimate ETC participation rather than external coalitions or identity-leasing markets.

#### Upgradeability Through the OIP Process

Governance parameters and module implementations may need to evolve as new identity systems, voting models, or security techniques emerge.
To prevent unsafe or discretionary upgrades, ECIP-1113 restricts all governance-layer evolution to the Olympia Improvement Proposal (OIP) process.

This guarantees that upgrades:
- follow the same voting, queueing, and timelock semantics as all governance actions,
- cannot modify consensus rules or Treasury immutability,
- cannot remove mandatory modules, and
- cannot introduce prohibited features such as proxies, owner-keys, or discretionary veto authority.

OIP-restricted upgradeability enables controlled evolution while preserving all security invariants defined in this ECIP.

#### Protection Against Governance Capture and Privilege Escalation

The architecture mitigates multiple governance attack classes, including:
- External Raid Attacks — prevented by domain-restricted identity layers.
- Slow-Roll Infiltration — mitigated by identity-aging and activity requirements.
- Identity-Leasing Markets — mitigated by non-transferable voting rights.
- Cross-DAO Credential Reuse — prevented via ETC-specific attestation.
- Child-DAO Capture — prevented by routing all authority through the main Governor.
- Timelock Zeroing — prevented by requiring non-zero delays.
- Executor Abuse — prevented through strict, narrow withdrawal permissions.
- Emergency-Module Abuse — limited via narrow scope and time-bound operation.
- Off-Chain Veto Committees — explicitly prohibited.

This ensures governance cannot be captured by external actors, privilege escalation, or informal off-chain power centers.

#### Justification for OpenZeppelin-Equivalent Architecture

OpenZeppelin’s Governor and Timelock patterns are among the most widely used and audited governance frameworks in the EVM ecosystem.
Requiring functional equivalence ensures:
- predictable lifecycle semantics,
- consistent edge-case handling,
- minimized implementation risk,
- strong audit coverage, and
- compatibility with existing tooling and analysis pipelines.

This requirement preserves implementation flexibility while leveraging mature, validated governance semantics.

#### Role of Child-DAO Governance Pipelines

Child-DAOs enable domain-specific governance—such as client development or infrastructure coordination—without increasing main DAO proposal load or introducing centralizing actors.
They provide modular delegation while remaining subordinate to the main Governor.
Child-DAOs:
- cannot initiate or execute Treasury withdrawals, and
- cannot influence OIP outcomes beyond standard governance processes.

This supports scalable governance while preserving decentralization and accountability.

#### Alignment With Ethereum Classic Governance Principles

The architecture reflects Ethereum Classic’s foundational governance principles:
- Immutability — Treasury code is immutable; governance cannot alter consensus.
- Determinism — execution flows follow a single, non-bypassable pipeline.
- Neutrality — no privileged actors or discretionary committees.
- Security — no admin keys, no proxy upgrades, no owner-only functions.
- Auditability — all governance actions are transparent, time-locked, and indexable.
- Resilience — identity systems and modules are replaceable via OIP under strict invariants.

Together, these properties yield a governance system that is evolvable yet resistant to capture, modular yet secure, and permissionless yet protected against common DAO-level attacks.

### Related Work

Olympia DAO’s governance architecture draws from proven patterns in high-value EVM governance systems while applying constraints required by Ethereum Classic’s immutable Treasury (ECIP-1112) and modular OIP-based governance upgrade path.
The design incorporates established approaches to on-chain voting, timelock-controlled execution, and modular governance composition used across major Layer-1 and Layer-2 networks.

#### Governance Architecture Precedents

Several governance frameworks inform the modular Governor → Timelock → Executor pattern defined in this ECIP:
- Compound Governor Bravo
 Defines a structured proposal lifecycle with immutable snapshots and parameterized governance.
 Its invariant-driven architecture informs Olympia’s requirements for deterministic thresholds, immutable snapshots, and mandatory proposal flow sequencing.
- OpenZeppelin Governor
 A widely audited, modular governance suite with a dedicated Timelock Controller and pluggable voting mechanisms.
 Olympia DAO requires functional equivalence to its behavioral invariants to ensure predictable, verifiable execution flows.
- Aragon OSx
 Demonstrates a plugin-based governance architecture with scoped permission modules and delegated authority.
 Olympia adopts this modularity for optional extensions (Child-DAOs, guards) while enforcing stricter anti-capture constraints and mandatory executor isolation.
- Aave Governance
 Utilizes layered timelocks, vote delegation, and strict separation between governance contracts and protocol logic.
 This separation inspires Olympia’s prohibition on discretionary executors and external veto mechanisms.
- MakerDAO (MIPs Framework)
 Provides a formal improvement process with domain-specific modules and timelocked execution.
 The Olympia Improvement Proposal (OIP) process follows similar principles: controlled upgradeability with deterministic, time-delayed execution.
- ENS DAO Governance
 Employs a minimal, predictable, and transparent governance contract surface area.
 This aligns with Olympia’s emphasis on deterministic proposal lifecycles and standardized event logs.
- Gitcoin Passport / Sybil-Resistance Frameworks
 Demonstrate modular identity-layer voting systems grounded in external attestations.
 Olympia adapts these concepts to support ETC-domain-restricted, Sybil-resistant voting with additional anti-capture safeguards.

#### Executor & Timelock Precedents

Deterministic, timelock-controlled execution is a well-established foundation of secure DAO governance:
- Uniswap Governor + Timelock
 Enforces strict separation between governance logic and execution.
 Olympia adopts this separation and strengthens it by requiring executor exclusivity for Treasury withdrawals.
- Yearn, Synthetix, and Lido Timelock Models
 Highlight the importance of non-zero delays, pre-execution transparency, and replay protection.
 Olympia incorporates mandatory delay invariants and transparent, atomic batch semantics.

These precedents collectively demonstrate the necessity of executor isolation, mandatory delay windows, and deterministic, replay-protected execution—core requirements of this ECIP.

#### Identity & Domain-Restricted Governance Precedents

Multiple governance ecosystems employ identity-layer or domain-restricted voting to mitigate capture:
- Gitcoin Passport — multi-attestation Sybil resistance
- Optimism Citizenship — domain-restricted participation
- BrightID / Proof-of-Personhood — unique identity verification
- POAP-based voting — contextual participation requirements

Olympia extends these concepts by combining external attestations with:
- ETC-domain contextual participation,
- identity-aging requirements,
- non-transferable voting rights, and
- periodic participation thresholds.

This combination is tailored to mitigate both rapid-coordination attacks and slow-roll infiltration—risks relevant to a Proof-of-Work L1 with a protocol-level Treasury.

#### Application to Ethereum Classic

Olympia DAO adapts the above governance models to the constraints inherent to Ethereum Classic:
- Executor Isolation
 Only a designated executor may call the Treasury.
 Olympia strengthens this model by prohibiting proxy upgrades, arbitrary executor calls, or owner-privileged override paths.
- Immutable Treasury Interaction
 Unlike many upgradeable treasuries, the Olympia Treasury cannot be replaced or modified.
 This necessitates a strictly enforced Governor → Timelock → Executor pipeline.
- Modular Upgradeability Through OIP
 Governance must remain evolvable, but only through deterministic, on-chain improvement processes.
 This parallels MakerDAO’s MIPs and Aragon’s plugin architecture, with stricter anti-capture constraints.
- Domain-Restricted, Sybil-Resistant Voting
 ETC requires defenses against cross-ecosystem governance raids.
 Olympia incorporates identity modules and contextual participation rules inspired by Gitcoin and Optimism, with additional layers suitable for an L1 Treasury.

These adaptations yield a governance architecture aligned with Ethereum Classic's principles of immutability, neutrality, determinism, and verifiable on-chain guarantees, while resisting common DAO-level governance attacks.

### Implementation

Olympia DAO SHALL be implemented as a modular suite of audited smart contracts deployed on Ethereum Classic.
In accordance with this ECIP, the governance system:
- manages proposal lifecycle, voting, and scheduling,
- enforces a mandatory Governor → Timelock → Executor execution pipeline, and
- authorizes calls to the immutable Olympia Treasury (ECIP-1112) via a single, restricted Executor contract.

All interaction with proposal content, metadata, and funding semantics (including the ECFP process defined in ECIP-1114) SHALL occur outside the governance contracts. The governance system operates only on action identifiers and execution payloads defined at the interface boundary.

#### 1. Governor Contract

The Governor contract SHALL be implemented using a governance framework functionally equivalent to the audited OpenZeppelin Governor pattern. It MUST:
- manage the complete proposal lifecycle (creation, state transitions, queueing, execution),
- record immutable snapshot state for voting power at the proposal’s snapshot block,
- enforce quorum, approval thresholds, voting delay, and voting period as on-chain parameters,
- dispatch approved actions exclusively to the Timelock Module, and
- source all voting power from a dedicated Voting Module (see §2), not from token balances or off-chain authorities.

The Governor MUST NOT include Treasury logic, funding rules, ECFP rules, metadata parsing, or BASEFEE mechanics.
These belong to ECIP-1112 (Treasury) and ECIP-1114 (Funding Proposal System).

Implementations SHOULD reuse well-reviewed governance libraries (e.g., OpenZeppelin Governor) but MAY diverge from specific inheritance structures as long as required invariants are preserved.

The following is an illustrative, non-normative example.

Governance parameters MUST be stored in contract state and MUST only be modifiable through OIP-approved governance actions.
In the intended example, this is enforced via the onlyGovernance modifier, ensuring all parameter changes—including migration to a new Voting Module—pass through the Governor → Timelock → Executor pipeline.

#### 2. Voting Module and Identity Integration

The Voting Module SHALL be implemented as a distinct contract (or set of contracts) that provides all voting power data to the Governor.
The Governor MUST NOT derive voting power from token balances, multisig attestations, or off-chain authority.
All voting power MUST be obtained through calls to the Voting Module.

At initial deployment, the Voting Module MUST implement:
- Sybil resistance via a one-address-one-vote model,
- ETC-domain restriction, ensuring that eligibility is derived solely from state observable on Ethereum Classic L1 and not from external chains, bridges, L2 systems, or unverifiable off-chain data,
- snapshot determinism, where voting power is computed solely from state available at the proposal’s snapshot block, and
- identity or activity requirements (e.g., minimum account age, recent activity window, or attestation-based eligibility).

Eligibility MUST be proposal-agnostic; the Voting Module MUST NOT introduce proposal-specific or content-dependent filtering conditions.

Voting power MUST NOT be transferable, delegatable, or assignable to any other address.

All examples in this section are illustrative and MUST NOT be interpreted as normative reference implementations.

The Voting Module MAY consume attestations from one or more decentralized identity systems, provided that:
- no identity provider may veto or approve proposals,
- no single identity oracle, multisig, or off-chain group may control eligibility,
- attestations MUST be verifiable on-chain without trusting external signatures, and
- replacing, upgrading, or removing an identity provider MUST occur only through the OIP process.

The Voting Module MUST expose a minimal interface for the Governor, at minimum providing proposal-agnostic votingPower and isEligible view functions.

The following is an illustrative, non-normative example.

##### Example: One-Address-One-Vote Eligibility Module

An illustrative module MAY enforce:
- one-address-one-vote,
- minimum account age,
- recent activity requirements,
- full snapshot determinism, and
- no delegation, no ownership, and no privileged identity authority.

The following is an illustrative, non-normative example.

##### Upgradability and Identity Migration

Changes to any of the following:
- account age rules,
- activity requirements,
- attestation providers,
- decentralized identity mechanisms, or
- vote weighting models

MUST occur solely through the Olympia Improvement Proposal (OIP) process.

Identity systems MAY evolve over time, but no identity provider or attestation mechanism may introduce veto power, proposal filtering, or privileged approval authority.

The Governor MUST NOT contain hardcoded identity logic and MUST NOT depend on any particular identity provider.

The Voting Module MUST remain replaceable via an OIP-governed update (e.g., an updateVotingModule() function in the Governor as defined in §1), ensuring full modularity and future extensibility.

#### 3. Timelock Contract

The Timelock Module SHALL be implemented using a pattern functionally equivalent to OpenZeppelin’s TimelockController. It MUST:
- accept scheduled operations from the Governor,
- enforce a strictly positive, configurable delay before execution,
- expose queue and execute functions callable only by the Governor (for queuing) and the Executor (for execution), and
- ensure that completed, cancelled, or expired operations cannot be re-executed.

No governance action MAY bypass the Timelock. The Timelock MUST NOT expose any owner, admin, guardian, or emergency-bypass roles that can alter queued operations or execute transactions outside the standard Governor → Timelock → Executor pipeline.

If batched operations are supported, the implementation MUST:
- execute all operations atomically or revert in full, and
- publish the complete batch contents on-chain prior to execution.

The following is an illustrative, non-normative example.

In production deployments, Timelock parameters (including the delay) MUST be modifiable only via the full Governor → Timelock → Executor pipeline; no instantaneous or retroactive changes to execution latency are possible. The simplified example above uses an immutable delay for brevity and does not show the OIP-controlled update path.

#### 4. Executor Contract

The Executor contract SHALL be implemented as a minimal, deterministic execution module that:
- can only execute operations that have been previously scheduled and unlocked by the Timelock,
- can only call the Treasury’s restricted withdrawal functions and other explicitly allowed, OIP-approved targets, and
- MUST revert any execution attempt that is not authorized by the Timelock.

The Executor MUST:
- trust a single Timelock address as its sole authority for execution authorization,
- perform calls exactly as specified by the Timelock (target, value, calldata) without modification, and
- emit events for all successful executions to enable full on-chain auditability.

The Executor MUST NOT:
- schedule governance actions,
- alter proposal state,
- interpret proposal metadata,
- perform arbitrary calls outside the set of operations provided by the Timelock,
- use delegatecall to execute arbitrary logic, or
- expose any owner, admin, or emergency-bypass role.

If batching is supported via future OIP-approved Timelock extensions, the Executor MUST execute all batched operations atomically and MUST NOT introduce any batching functionality on its own.

The Executor SHALL be a pure forwarding module: it MUST NOT contain business logic, Treasury accounting logic, or funding rules of any kind. The Executor MUST NOT perform state-changing logic before or after the external call that could introduce reentrancy risk.

The following is an illustrative, non-normative example of a module whose parameters are only updateable via an on-chain call from the governance Executor (the endpoint of the Governor → Timelock → Executor pipeline).

The Executor address SHALL be hardcoded into the Treasury (ECIP-1112) according to ECIP-1112’s deployment rules and MUST NOT be changeable by any governance action in ECIP-1113. No OIP, upgrade, or external contract MAY modify the Executor reference inside the Treasury once deployed. The Treasury MUST reject any call to its withdrawal functions that does not originate from this Executor.

#### 5. OIP Implementation (Governance Upgrades)

The Olympia Improvement Proposal (OIP) process SHALL be implemented as a subset of Governor-managed proposals whose execution payloads modify governance parameters or module references, rather than initiating Treasury disbursements.
OIPs are strictly limited to governance-layer configuration changes and MUST NOT perform any action that alters consensus behavior, Treasury mechanics, or funds.

All OIP proposals MUST be processed exclusively through the standard lifecycle:

Governor → Timelock → Executor → (Authorized Module)

No contract, module, or off-chain actor MAY bypass this sequence.

Implementation guidelines:
- OIP proposals SHOULD be tagged or categorized within the Governor for on-chain indexing and UX clarity.
- OIP proposals MUST follow the same voting delay, voting period, quorum, and Timelock delay rules as all other governance proposals.
- Execution payloads for OIPs MUST update only:
- governance parameters (quorum, thresholds, voting delay, voting period, Timelock delay),
- references to Voting Modules or identity systems,
- references to Timelock or Executor modules (if migrated via OIP), or
- optional module configuration (Child-DAOs, Execution Guard, Emergency Pause).

The implementation MUST enforce that OIP proposals CANNOT:
- modify or override consensus-layer rules (ECIP-1111),
- modify or redeploy the Treasury contract (ECIP-1112),
- modify the funding proposal lifecycle or metadata rules defined in ECIP-1114,
- upgrade or replace contracts via delegatecall, proxy patterns, or external upgrade infrastructure, or
- introduce any feature prohibited in this ECIP’s Security or Prohibited Features sections.

All OIP parameter updates MUST be persisted on-chain and MUST only become effective after execution through the Timelock and Executor.
No governance state MAY be mutated within the Governor prior to Timelock-mediated execution.

The following is an illustrative, non-normative example.

#### 6. Integration With ECIP-1114 (Execution Payloads Only)

While ECIP-1114 defines the Ethereum Classic Funding Proposal (ECFP) process, ECIP-1113’s governance contracts interact with ECIP-1114 only at the execution payload boundary.
The Olympia Governor, Timelock, and Executor SHALL treat all ECIP-1114 data (identifiers, hashes, metadata references) as opaque values and SHALL NOT implement or re-implement any ECFP logic.

The implementation MUST:
- accept execution payloads that reference proposal identifiers and hashes defined in ECIP-1114,
- treat those identifiers and hashes as opaque values (e.g., bytes32 proposalId, bytes32 metadataHash), and
- enforce that execution of any ECIP-1114-related funding action is contingent on:
- successful approval by the Governor under the rules of this ECIP,
- successful elapsing of the Timelock delay, and
- successful invocation by the Executor of the Treasury’s restricted interface, as defined in ECIP-1112.

All of the following concerns MUST be handled outside of ECIP-1113, as specified in ECIP-1114:
- proposal metadata structure and content,
- ECFP categorization, milestones, and funding schedules,
- off-chain or cross-chain references (IPFS, URLs, documents),
- any interpretation of proposal content, purpose, or risk.

ECIP-1113-compliant implementations MUST NOT:
- parse, validate, or transform ECIP-1114 metadata,
- enforce ECFP rules such as spending caps, categories, or milestones,
- introduce proposal-content-based veto logic or metadata-based approval checks.

From the perspective of the governance system, an ECIP-1114-driven funding action is represented only by:
- a target address (typically the Treasury),
- a value (if applicable),
- calldata (including opaque identifiers such as proposalId, metadataHash, or schedule IDs).

These values SHALL pass through the Governor → Timelock → Executor pipeline verbatim and MUST NOT be altered by ECIP-1113 logic.

The following is an illustrative, non-normative example.

#### 7. Optional Modules: Emergency Pause & Execution Guard

Optional safety modules MAY be deployed alongside the core Governor → Timelock → Executor pipeline.
When present, these modules MUST integrate without altering the fundamental governance flow or introducing any privileged actors.
All optional modules MUST be governed entirely through OIPs and MUST remain removable or replaceable via OIP-controlled updates.

##### 7.1 Emergency Pause Module

The Emergency Pause Module MAY be deployed to provide a temporary, reversible halt on governance execution.
Its behavior MUST comply with the following invariants:
- It MUST be capable of blocking one or both of:
- execution within the Timelock,
- execution attempts forwarded by the Executor.
- It MUST NOT modify queued operations or alter proposal state.
- It MUST NOT bypass the Governor — activation and deactivation MUST occur exclusively through OIP.
- The paused state MUST be stored on-chain, deterministic, and publicly auditable.
- Pause state MUST automatically unblock once revoked by an OIP-governed action.

The module MUST NOT interpret proposal metadata, funding semantics, milestones, or any proposal content.

This is an illustrative, non-normative example.

##### 7.2 Execution Guard Module

The Execution Guard Module, when deployed, acts as a deterministic validation layer that checks execution requests before the Executor performs them.
It MUST:
- validate calldata structure, size, or format,
- reject operations that violate explicit, on-chain rules (e.g., invalid targets, forbidden selectors, excessive batch size),
- operate only on raw calldata and execution parameters,
- emit deterministic reverts for invalid operations,
- NEVER inspect metadata, ECFP contents, proposal descriptions, or other off-chain inputs.

The Guard MUST NOT:
- approve or veto proposals,
- possess any external control keys,
- modify proposal or governance state.

The Guard may only accept or reject execution payloads based on a deterministic rule set defined on-chain and modifiable solely through OIP.

This is an illustrative, non-normative example.

##### 7.3 Integration Requirements

When optional modules are deployed:
- They MUST NOT alter the mandatory execution sequence:
 Governor → Timelock → Guard(s) → Executor → Treasury
- They MUST be modular contracts referenced by the Timelock or Executor (not embedded logic).
- All updates or replacements MUST occur through OIP-authorized governance actions.
- Guard rejections MUST produce deterministic failures without mutating queued Timelock operations.
- Their absence MUST NOT affect correctness of the core governance pipeline—these modules provide optional risk-reduction, not required functionality.

#### 8. Child-DAO Governance Pipelines

Child-DAO modules MAY be deployed to manage domain-specific governance (e.g., Core Client Maintenance, Infrastructure Coordination, Public Goods, etc.) while preserving the strict separation of authority defined in this ECIP.
A Child-DAO operates as a subordinate governance layer whose outputs MUST always be routed through the main Olympia Governor.

A Child-DAO SHALL:
- manage its own internal voting or signaling process,
- maintain its own proposal lifecycle and domain-specific rules,
- optionally aggregate votes or input from its participant set, and
- produce derived actions or recommendations that are forwarded to the main Governor for binding execution.

A Child-DAO MUST NOT:
- execute actions directly against the Treasury (ECIP-1112),
- bypass the main Governor’s quorum, voting, or timelock rules,
- introduce external or privileged veto actors,
- or possess any direct write-access to protocol-level parameters.

All actionable output from a Child-DAO MUST be submitted to the main Governor as a standard proposal payload. The main Governor SHALL then:
1. apply its own voting delay, voting period, quorum, and OIP rules,
2. queue any approved actions into the Timelock, and
3. execute them via the Executor if not vetoed or paused.

This ensures that all binding authority remains with the main Governor, while Child-DAOs serve as modular contributors or domain-specific governance pipelines.

Child-DAO configuration—including membership criteria, internal voting rules, and optional delegation mechanics—MAY be defined or updated via OIP. However:
- no Child-DAO MAY violate the Sybil-resistance and ETC-domain restrictions defined for the main Voting Module, and
- no Child-DAO MAY impose proposal-specific veto power or privileged access to the Treasury.

The following illustrative example demonstrates how a Child-DAO MAY package a domain-specific action and submit it to the main Governor using a standard propose() call.
The Child-DAO does not execute actions directly and does not interact with the Treasury; it simply forwards an action for main-governor consideration under the normal voting and timelock rules.

The following illustrative, non-normative example shows how a Child-DAO MAY package a single-target domain-specific action and submit it to the main Governor using a standard propose() call. The Child-DAO does not execute actions directly and does not interpret Treasury details; it only forwards its recommendation into the main Governor for consideration under the normal voting and timelock rules.

#### 9. Audit & Testnet Rollout

Before mainnet activation, all Olympia DAO components SHALL undergo comprehensive security review and multi-client testnet validation.
The full governance suite MUST be deployed and exercised on the Mordor Testnet prior to any mainnet hard fork.

##### 9.1 Security Audits

At minimum, one independent third-party security audit SHALL be performed, covering:
- the Governor contract suite,
- the Voting Module and all identity/eligibility logic,
- the Timelock and Executor modules,
- any optional modules (Emergency Pause, Execution Guard), and
- any deployed Child-DAO contracts.

Audits MUST verify adherence to the invariants defined in this ECIP, including:
- prohibition of upgradeable proxy patterns,
- absence of owner/admin/guardian roles,
- immutability of the governance pipeline,
- determinism of snapshot and eligibility logic, and
- correct enforcement of Timelock delays and Executor authorization.

All findings SHOULD be resolved or mitigated before mainnet activation.

##### 9.2 Mordor Testnet Deployment

A full-system deployment SHALL be performed on the Mordor Testnet, validating:
- proposal creation, queueing, execution, and lifecycle transitions,
- snapshot-based voting power and eligibility correctness,
- Timelock delay enforcement and replay protection,
- Executor isolation and correct Treasury-call behavior,
- proper handling of OIP-driven parameter and module upgrades, and
- cross-client consensus consistency across all governance-related operations.

Testnet trials MUST exercise all mandatory governance flows and SHOULD include:
- benign governance scenarios (parameter updates, module replacements),
- adversarial and edge-case behaviors (invalid operations, replay attempts),
- activation and revocation of Emergency Pause,
- rejection and acceptance paths for Execution Guard rules, and
- real-world identity/attestation interactions under varied conditions.

Successful testnet validation SHALL be considered a requirement for readiness prior to scheduling any mainnet activation block.

#### 10. Modular Deployment and Activation

Consistent with the modular design of ECIPs 1111–1114, deployment and activation of Olympia SHALL proceed in discrete, independently verifiable phases.
Each phase MUST preserve the invariants of this ECIP and MUST NOT grant premature authority to any undeployed or unaudited module.

##### 10.1 Staged Deployment
- The Treasury (ECIP-1112) MAY be deployed and begin accumulating BASEFEE-redirected funds prior to activation of ECIP-1113.
- The Olympia Governor, Voting Module, Timelock, Executor, and any optional modules MAY be deployed to testnet or mainnet in advance, provided they do not yet control the Treasury.
- Child-DAO modules MAY also be deployed early, provided that they route all binding actions to the main Governor and do not interact with the Treasury directly.

Early deployment MUST NOT grant control of the Treasury until the community, client implementers, and auditors have verified correctness.

##### 10.2 Preconditions for Mainnet Activation

Mainnet activation of ECIP-1113 SHOULD occur only after:
- independent third-party audits have been completed and reviewed,
- Mordor testing demonstrates correct behavior under benign, adversarial, and edge-case conditions, and
- the Ethereum Classic community has had sufficient opportunity to review and discuss the governance architecture defined in this ECIP.

##### 10.3 Handover of Treasury Control

Handover of execution authority to Olympia DAO SHALL occur by setting the Executor address inside the Treasury (ECIP-1112) according to the deployment rules defined in that proposal.

Once this address is set:
- all authorized Treasury withdrawals MUST pass exclusively through the
 Governor → Timelock → Executor
 pipeline defined in this ECIP, and
- no subsequent governance action MAY modify the Treasury’s reference to the Executor.

After handover, the Treasury becomes fully governed by the on-chain, OIP-controlled Olympia DAO framework, and all protocol-level funding actions MUST conform to the access-control and execution pipeline defined in ECIP-1113.

### Backwards Compatibility

ECIP-1113 introduces no changes to Ethereum Classic’s consensus rules, block structure, transaction formats, opcodes, or EVM semantics.
Olympia DAO governance operates entirely at the application layer through smart contracts and does not modify consensus-layer behavior.

#### Protocol Impact
- Nodes that implement ECIP-1111 (BASEFEE activation) and ECIP-1112 (Olympia Treasury) but not ECIP-1113 will remain in consensus with the canonical chain. However:
- they will be unable to construct or execute governance transactions, and
- they will still validate blocks containing governance-related transactions, since such transactions conform to existing consensus rules.
- Nodes that fail to implement ECIP-1111 (EIP-1559-style BASEFEE + redirection) will fork from the canonical chain at the ECIP-1111 activation block.

#### Application-Layer Isolation
- All Olympia DAO logic — proposal creation, voting, timelock scheduling, parameter updates, and execution — is isolated from consensus logic.
- Existing smart contracts and dApps remain fully compatible and unaffected unless they opt in to interact with Olympia DAO governance or Treasury events.
- Participation in governance is entirely optional; non-participating nodes and applications remain fully valid.

#### Treasury Execution Requirements

To authorize or construct Treasury disbursements, clients MUST support:
- the immutable Olympia Treasury contract (ECIP-1112),
- the Olympia DAO Executor (ECIP-1113), and
- the ECIP-1114 execution path, including hash-bound proposal verification.

Clients that do not implement ECIP-1113 or ECIP-1114:
- cannot create, sign, or participate in governance transactions,
- but will continue to validate Treasury executions so long as they comply with consensus rules.

#### State and Data Integrity
- Proposal state, voting records, timelock queues, and execution events are stored entirely within smart contract state.
- No historical consensus-layer state is altered.
- Governance-layer state is deterministic and does not affect block validity or canonical chain selection.

By keeping all governance logic strictly isolated from consensus mechanics, ECIP-1113 preserves Ethereum Classic’s protocol stability and immutability while enabling a secure, opt-in, on-chain governance and funding system.

### Governance Parameter Invariants

Olympia DAO governance parameters SHALL be implemented as on-chain, OIP-controlled variables that define the safety envelope for all governance operations.
These parameters MUST be stored in contract state, enforced deterministically, and modifiable only through the Governor → Timelock → Executor pipeline.

#### Quorum and Approval Thresholds
- A minimum quorum MUST be required for any proposal to be valid.
- An approval threshold MUST be required for any proposal to pass.
- Both quorum and approval thresholds MUST be modifiable only through OIP-authorized parameter updates.
- No external authority MAY alter these values.

#### Voting Delay and Voting Period
- A voting delay MUST be enforced between proposal creation and voting start.
- A minimum voting period MUST be enforced to allow global participation.
- Both parameters MUST be encoded on-chain and modifiable only through OIP-controlled governance actions.

#### Proposal Submission Requirements
- The DAO MAY define additional submission requirements (e.g., eligibility checks, identity-based verification) provided they remain:
- permissionless,
- modular, and
- enforced by the Voting Module or associated identity systems.
- These requirements MUST NOT introduce privileged actors, trusted committees, or off-chain authority.

#### Timelock Enforcement
- All approved proposals MUST pass through a Timelock before execution.
- Timelock delay MUST be strictly greater than zero and modifiable only through OIP.
- Timelock delays MUST NOT be bypassable by any module, external actor, multisig, or emergency mechanism.

#### On-Chain Auditability
- All governance-parameter changes MUST be recorded on-chain.
- Events MUST be emitted for updates to quorum, thresholds, delays, and voting periods.
- Parameter changes MUST only take effect after successful execution through the Timelock.

These invariants ensure that Olympia DAO governance remains auditable, transparent, and resistant to rushed or captured decision-making, while preserving permissionless participation and deterministic on-chain behavior.

### Security Considerations

Olympia DAO governance is designed to minimize attack surfaces while preserving permissionless participation and transparent on-chain execution.
This section outlines the core security properties and mitigations required for the Governor → Timelock → Executor pipeline defined in this ECIP.

#### 1. Contract Immutability and Access Control
- Governance contracts (Governor, Timelock, Executor) MUST NOT include admin keys, owner roles, guardian roles, or upgradeable proxy patterns.
- Governance parameters (quorum, thresholds, delays, periods) MUST be modifiable only through OIP-controlled proposals executed via the full governance pipeline.
- The Olympia Treasury (ECIP-1112) SHALL remain immutable and MUST accept calls only from the approved Executor; all other callers MUST revert.
- No external contract, off-chain actor, multisig, or Child-DAO MAY bypass the Timelock or alter queued operations.

#### 2. Execution Integrity and Determinism
- All execution payloads MUST be treated as opaque byte arrays and executed exactly as encoded.
- The Governor, Timelock, and Executor MUST NOT transform, reinterpret, sanitize, or conditionally modify payloads.
- Operations MUST be executed atomically; partial execution MUST revert.
- Timelock operationId hashing MUST ensure replay protection, uniqueness, and non-reexecution of completed or canceled entries.

#### 3. Replay Protection
- Proposals and execution payloads MUST be domain-separated using block.chainid or equivalent chain-bound identifiers.
- Replay-protection logic MUST be implemented consistently across the Governor, Timelock, and Executor.
- Executed operations MUST be marked in contract state to prevent same-chain re-execution.

#### 4. Governance Process Risks
- Low participation risk — mitigated via quorum requirements, configurable voting periods, and mandatory voting delays.
- Governance capture — minimized through one-address-one-vote, optional Sybil-resistant identity systems, and ETC-domain restrictions.
- Rushed execution — prevented via strictly positive Timelock delays and optional Emergency Pause modules.
- Module misconfiguration — mitigated by requiring all module references (Voting Module, Timelock, Executor, Guard, Pause) to be updated exclusively via OIP.

#### 5. Client and Network Safety
- Governance execution MUST NOT modify consensus rules, transaction validation logic, or block format.
- Clients verifying Treasury disbursements MUST validate:
- the target address (Treasury),
- the caller (Executor),
- and that the calldata matches the expected withdrawal function signature.
- All governance operations MUST be deterministic across clients to avoid consensus divergence.
- Full cross-client testing on Mordor Testnet SHALL confirm identical execution paths on all supported ETC clients prior to activation.

#### 6. Event Logging and Auditability
- All governance actions — including proposal creation, voting, parameter changes, queueing, and execution — MUST emit standardized events.
- Events MUST allow complete off-chain reconstruction of proposal state transitions.
- The Timelock MUST emit events for all queued operations, and the Executor MUST emit events for all executed operations.
- Off-chain indexers SHOULD track these events to provide verifiable governance audit trails.

By enforcing immutable access control boundaries, deterministic execution, replay protection, and comprehensive logging, Olympia DAO ensures secure, transparent, and tamper-resistant governance over Ethereum Classic’s protocol-level execution pipeline.

### Related ECIPs in the Olympia Upgrade

ECIP-1113 is one of four coordinated ECIPs that together introduce a modular, decentralized, and transparent protocol-funding framework for Ethereum Classic.
Each component focuses on a distinct layer of the system.
- ECIP-1111 — Olympia EVM and Protocol Upgrades
 Activates EIP-1559 and EIP-3198 on Ethereum Classic and redirects the BASEFEE to the Olympia Treasury (ECIP-1112) instead of burning it.
- ECIP-1112 — Olympia Treasury Contract
 Defines the immutable, governance-isolated smart contract that receives all redirected BASEFEE revenue and holds it until released through authorized on-chain governance.
- ECIP-1113 — Olympia DAO Governance Framework
 Specifies the decentralized governance architecture that acts as the single authorized execution path for Treasury disbursements, including proposal submission, voting, timelock scheduling, and execution.
- ECIP-1114 — Ethereum Classic Funding Proposal Process
 Establishes the standardized, hash-bound funding proposal format (ECFP) for requesting Treasury funds, enabling transparent and verifiable allocation of protocol-level resources.

#### Interdependency Summary
- ECIP-1111 introduces protocol-level revenue via BASEFEE redirection.
- ECIP-1112 deploys the immutable Treasury vault that stores this revenue.
- ECIP-1113 defines the governance layer that can authorize withdrawals from the Treasury.
- ECIP-1114 defines the proposal format and metadata rules that ECIP-1113 consumes as opaque execution payloads.

These ECIPs are designed for modular activation:
- ECIP-1111 and ECIP-1112 may be deployed first, allowing the Treasury to accumulate funds.
- ECIP-1113 and ECIP-1114 may be activated later, enabling transparent, on-chain governance and disbursement of accumulated funds.

### Copyright

Copyright and related rights waived via
CC0

### Appendix: Governance Architecture Precedents

This appendix provides informal background on governance patterns that inspire the modular Governor → Timelock → Executor architecture defined in ECIP-1113.
These precedents are non-normative and do not impose implementation requirements.

#### Established EVM Governance Patterns

Olympia DAO draws conceptual influence from widely deployed and audited on-chain governance frameworks, including:
- OpenZeppelin Governor
 Modular governance architecture with pluggable voting strategies and a dedicated Timelock Controller.
 Demonstrates deterministic lifecycle semantics and strong audit coverage.
- Compound Governor Bravo
 Snapshot-based voting, deterministic proposal states, timelock enforcement, and configurable quorum/threshold parameters.
 Serves as a proven reference for transparent, parameterized governance logic.
- Aragon OSx
 Plugin-based governance modules and scoped authority paths.
 Demonstrates modular governance composition, which aligns with Olympia’s optional modules (e.g., Guards, Child-DAOs).
- ENS / Gitcoin / Aave Governance Systems
 Illustrate predictable proposal lifecycles, on-chain execution, and identity-or voting-module-based authorization consistent with a modular governor design.

These systems collectively validate the architectural principles required for Olympia DAO:
- deterministic proposal lifecycles,
- transparent on-chain execution,
- mandatory timelock delays,
- modular voting and execution components, and
- strict avoidance of privileged roles or upgradeable-proxy patterns.

#### Scope Note

This appendix is informational only.
Treasury custody precedents and cross-ecosystem treasury designs are documented in ECIP-1112 and are intentionally excluded here to preserve strict modular boundaries between:
- ECIP-1112 — Treasury storage and immutability
- ECIP-1113 — governance and execution architecture
- ECIP-1114 — funding proposal metadata and payload structure

The Olympia DAO design adheres to governance patterns proven across the EVM ecosystem while maintaining Ethereum Classic’s requirements for immutability, neutrality, and deterministic on-chain execution.

### Simple Summary

This proposal introduces EIP-1559 and EIP-3198 to Ethereum Classic via a hard fork named Olympia. These upgrades enhance EVM compatibility and modernize gas pricing mechanics. Unlike Ethereum Mainnet, where the BASEFEE is burned, Ethereum Classic redirects it to the Olympia Treasury (ECIP-1112) — an immutable, governance-isolated on-chain funding contract.

This establishes a transparent, non-inflationary protocol-level funding source while preserving Proof-of-Work consensus and Ethereum Classic’s principles of immutability, neutrality, and decentralization.

Until governance defined in ECIP-1113 and ECIP-1114 is activated, the Treasury accumulates funds passively with no disbursements, ensuring secure and trustless value storage.

### Abstract

This ECIP proposes the activation of select Ethereum protocol upgrades on Ethereum Classic under the hard fork name Olympia. Specifically, it introduces:
- EIP-1559: Implements a dynamic basefee adjustment mechanism to improve fee predictability and market efficiency.
- EIP-3198: Adds the BASEFEE opcode for full EVM opcode compatibility.

These changes improve interoperability with Ethereum and other EVM-based networks while preserving Ethereum Classic’s Proof-of-Work consensus and principles of immutability.

All BASEFEE revenue is redirected to the Olympia Treasury (ECIP-1112), a deterministic, immutable contract defined at the protocol level. Governance and funding flows for this Treasury are specified separately in ECIP-1113 (Olympia DAO Governance Framework) and ECIP-1114 (Ethereum Classic Funding Proposal Process).

This upgrade explicitly excludes changes related to Ethereum’s Proof-of-Stake transition, including validator operations and beacon-chain-based randomness, which are not applicable to Ethereum Classic. Implementation requires coordinated deployment across client software and node operators, with block heights to be finalized for both Mordor Testnet and Mainnet activation.

### EIP Summaries and Expected Action

#### Included in the Olympia Upgrade
- EIP-1559 – Fee Market Change
 Introduces a new transaction type with a dynamically adjusting basefee based on block gas usage and an optional miner tip (priorityFee).
 On Ethereum Classic, unlike Ethereum Mainnet, the basefee is not burned. It is redirected at the consensus layer to the deterministic Olympia Treasury address defined in ECIP-1112. Miner tips (priorityFee) remain payable directly to block producers.
- EIP-3198 – BASEFEE Opcode
 Adds opcode 0x48 (BASEFEE), returning the current block’s basefee.
 This enables fee-aware contract logic, improved gas estimation, and standard EVM opcode compatibility.

This ECIP proposes activation of both EIPs at the following block heights (to be finalized after successful testnet deployment):
- Mordor Testnet: TBD
- Ethereum Classic Mainnet: TBD
 (See Activation section for final coordination and release details.)

For technical implementation details, see the Specification section below.

### Motivation

The Olympia upgrade enhances Ethereum Classic’s protocol by integrating widely adopted Ethereum Virtual Machine (EVM) features — specifically EIP-1559 and EIP-3198. These changes bring Ethereum Classic into closer alignment with the modern EVM ecosystem, improving interoperability, developer experience, and long-term maintainability.

EIP-1559 and EIP-3198 provide several benefits:
1. Improved EVM Compatibility
 Adoption of EIP-1559 and the BASEFEE opcode enables Ethereum Classic to support transaction formats and gas-pricing conventions now standard across most EVM networks. This reduces friction for developers and tooling providers and improves cross-chain portability.
2. Modernized Fee Market
 EIP-1559 introduces a dynamic basefee mechanism that provides more predictable gas pricing and a clearer distinction between network congestion pricing and miner incentives. This results in more consistent application and user behavior across EVM chains.
3. Expanded Tooling and Infrastructure Support
 Parity with widely supported EVM standards improves compatibility with wallets, infrastructure services, and development frameworks that increasingly assume EIP-1559 semantics.
4. Sustainable Protocol-Level Funding
 Redirecting the BASEFEE to the Olympia Treasury (ECIP-1112) creates a transparent, non-inflationary source of protocol revenue. This supports long-term client maintenance, infrastructure reliability, and ecosystem security as block rewards decline under ECIP-1017.

While EIP-1559 originated on Ethereum, its inclusion here remains consistent with Ethereum Classic’s principles of immutability and censorship resistance. It modifies no historical state, introduces only additive transaction formats, and does not require trust in off-chain actors.

### Specification

The Olympia upgrade activates the following Ethereum protocol improvements on Ethereum Classic. All specifications are implemented exactly as defined in the canonical Ethereum Improvement Proposals (EIPs), except where noted for consensus-layer BASEFEE redirection.

#### Protocol Changes Adopted from Ethereum's London Hard Fork
- EIP-1559 – Fee Market Change
 Introduces a new transaction format with a dynamically adjusting basefee based on block gas usage and an optional miner tip (priorityFee).
 On Ethereum Classic, the basefee is not burned. Instead, it is redirected at the consensus layer to the deterministic Olympia Treasury address defined in ECIP-1112. Miner tips (priorityFee) continue to be paid directly to block producers.
- EIP-3198 – BASEFEE Opcode
 Adds opcode 0x48 (BASEFEE), allowing smart contracts to access the current block’s basefee.
 This enables fee-aware smart contract logic, improved gas estimation, and consistent EVM behavior across supported tooling.

##### Example: Consensus-Layer BASEFEE Redirection

##### Pseudocode Notes
- This example is illustrative only; actual implementations appear within each client’s consensus and state-transition logic.
- state represents the client’s execution ledger for applying balance changes during block processing.
- This behavior is consensus-critical and MUST be implemented identically across any participating Ethereum Classic clients.

🔒 Consensus-critical logic: BASEFEE redirection is enforced during block finalization and cannot be bypassed or altered without a hard fork. The Treasury transfer occurs before miner rewards are applied.

No additional EVM changes, consensus rules, or opcodes are introduced in this upgrade.

#### Implementation Notes
- Clients MUST implement EIP-1559 and EIP-3198 exactly as specified, with the modification that the basefee amount is redirected to the Treasury address defined in ECIP-1112 rather than burned.
- Test vectors MUST be updated to reflect Treasury accumulation instead of basefee destruction.
- Activation SHALL occur at predefined block heights on Mordor Testnet and Ethereum Classic Mainnet (see Activation section).

Clients and infrastructure providers MUST validate implementation using cross-client consensus tests, including basefee calculation, transaction-type handling, and correct Treasury accumulation.

#### Monetary Policy Consideration

Redirecting the BASEFEE to the Olympia Treasury replaces Ethereum Mainnet’s burn mechanism with protocol-level treasury accumulation, without altering ETC’s total supply or issuance schedule. Monetary policy defined in ECIP-1017 remains unchanged. This change preserves Ethereum Classic’s fixed monetary policy while enabling sustainable, transparent funding for ecosystem maintenance and public infrastructure.

### Rationale

#### Simplicity by Design

The Olympia upgrade introduces no additional consensus-layer complexity beyond the well-established specifications of EIP-1559 and EIP-3198, both of which have been extensively tested and adopted across the EVM ecosystem.

Olympia’s architecture is modular by intent:
- ECIP-1112 (Treasury), ECIP-1113 (Governance Framework), and ECIP-1114 (Funding Proposal Process) are distinct, independently testable components built atop standard smart contract primitives.
- Each layer can be activated or upgraded independently, allowing protocol functionality, governance, and funding mechanisms to evolve without coupling changes across the stack.
- No new token is introduced or distributed as part of this upgrade.

This separation mirrors ECIP-1112’s minimalist vault architecture and ECIP-1113’s modular governance structure, ensuring each layer can be maintained or improved without modifying the others.

#### Interoperability

Maintaining EVM interoperability ensures compatibility with:
- Cross-chain infrastructure (wallets, bridges, RPC providers)
- dApp frameworks (e.g., Hardhat, Foundry, Scaffold-ETH)
- Developer tooling and compilers that increasingly assume EIP-1559-style transactions

By adopting canonical Ethereum upgrades, Ethereum Classic maintains alignment with widely supported EVM conventions, improving tooling compatibility and reducing friction for developers and infrastructure providers.
EIP-1559 and EIP-3198 adoption also fulfills the dependency required for the Olympia Treasury’s BASEFEE revenue capture mechanism (ECIP-1112).

#### Immutability

EIP-1559 and EIP-3198 are strictly additive upgrades:
- No changes are made to existing opcodes, transaction types, or state semantics.
- Historical contracts behave identically post-fork.
- No retroactive modification of the ETC ledger occurs.

This preserves Ethereum Classic’s core principle of immutability while enabling forward-compatible improvements.

#### Standards Compliance

Canonical EIPs such as 1559 and 3198 are now expected defaults across most major L1 networks and rollups:
- Many tools, libraries, and RPC providers assume EIP-1559 support.
- Without these upgrades, Ethereum Classic risks incompatibility with upstream EVM tooling and reduced developer accessibility.

Adopting these standards ensures that ETC remains aligned with the broader EVM ecosystem, improving long-term maintainability for both dApp and client developers.

### Modular Activation

ECIP-1111 introduces consensus-layer BASEFEE redirection to an on-chain Treasury but does not require immediate activation of downstream governance components — including ECIP-1113 (Olympia DAO Governance Framework) or ECIP-1114 (Ethereum Classic Funding Proposal Process).

Instead, BASEFEE is redirected to a passive, immutable, governance-isolated Treasury contract defined in ECIP-1112. This Treasury:
- Accumulates protocol revenue without disbursing funds
- Remains immutable and transparent through on-chain auditability
- Restricts all withdrawals until governance contracts are activated under separate ECIPs

This modular approach allows ECIP-1111 to remain a single, isolated consensus change, consistent with ECIP-1000. It enables the network to adopt EIP-1559 and EIP-3198 immediately, without introducing:
- Dependencies on governance readiness
- Coordination requirements beyond client activation
- Any operational or administrative prerequisites

Activation of governance control over the Treasury is intentionally specified outside of ECIP-1111. It is defined in:
- ECIP-1113, which establishes the on-chain governance framework
- ECIP-1114, which defines the standardized funding proposal process

This separation ensures that consensus changes, Treasury deployment, and governance activation can proceed independently and safely, each undergoing appropriate testing and review.

### Implementation & Reference Client

#### Testnet Coordination & Implementation Status

At the time of writing, prototype implementations of EIP-1559, EIP-3198, and consensus-layer BASEFEE redirection are under active development within the Ethereum Classic client ecosystem.

Specific client names, branches, or release artifacts MAY be documented in this section once reference implementations are publicly announced and tagged by their respective maintainers.

Prior to any Mainnet activation, the Olympia upgrade SHALL be tested on the Mordor Testnet. Testnet coordination SHOULD cover at minimum:
- Activation parameters (block height or activation epoch)
- basefee calculation and adjustment behavior under varying gas usage
- Correct accounting of Treasury balances (ECIP-1112)
- Handling of Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transactions
- Cross-client state-transition equivalence and replay protection

Final activation block numbers for both Mordor and Mainnet SHALL be agreed by client implementers, node operators, and other stakeholders, and SHALL be published in an update to this section and in the relevant client release notes.

#### Client Requirements

All ETC client implementations MUST:
- Implement EIP-1559 basefee targeting logic
- Support Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transactions
- Implement the BASEFEE opcode exactly as defined in EIP-3198
- Redirect the BASEFEE amount to the deterministic Olympia Treasury address (ECIP-1112)
- Enforce replay protection and fork ID behavior around the activation block
- Apply state-transition rules identically to other participating clients to maintain consensus

### Testing and Coordination

Validation MUST occur on the Mordor Testnet before any Mainnet activation.

Test coverage SHOULD include:
- Transaction lifecycle for Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transactions
- Accurate fee accounting (BASEFEE redirection vs miner tips)
- Correct Treasury accumulation at the consensus layer
- BASEFEE opcode behavior under empty, partially full, and full gas blocks
- Cross-client consensus testing, including block execution equivalence
- Fork ID, chain configuration, and replay protection validation
- Optional integration testing with ECIP-1112, and—once deployed—ECIP-1113 and ECIP-1114

Activation block heights for Mordor and Mainnet SHALL be finalized through open coordination among client implementers, node operators, miners, exchanges, and infrastructure providers.

#### Scope of This ECIP

This ECIP strictly introduces:
- Activation of EIP-1559
- Activation of EIP-3198
- Consensus-layer BASEFEE redirection to the Olympia Treasury (ECIP-1112)

All governance, funding, and contract-layer functionality is defined separately in:
- ECIP-1112 — Treasury Contract
- ECIP-1113 — Governance Framework
- ECIP-1114 — Funding Proposal Process

These ECIPs are independent of ECIP-1111 and MAY be deployed and activated on separate timelines under the modular rollout model.

### EIP Compatibility Scope

The Olympia upgrade is intentionally limited in scope. It activates only two Ethereum protocol improvements:
- EIP-1559 — Introduces the dynamic basefee mechanism and replaces Ethereum Mainnet’s burn behavior with consensus-layer BASEFEE redirection to the immutable Olympia Treasury (ECIP-1112).
- EIP-3198 — Adds the BASEFEE opcode (0x48), enabling contract-level visibility of the current block’s basefee.

These EIPs improve fee-market behavior and EVM interoperability without modifying existing contract semantics or introducing any consensus-layer changes beyond the redirection of BASEFEE.

No additional EIPs are activated by this proposal. All other Ethereum Foundation EIPs — spanning from Tangerine Whistle (2016) through Prague–Electra (2025) — were reviewed only for compatibility context and are listed in the Appendix: EVM Compatibility Roadmap and Upgrade Candidates section of this ECIP. Their inclusion in the appendix does not imply adoption; any future EVM upgrades would require separate ECIPs.

### Related Work

#### Precedents for Protocol-Level Fee Redirection

While Ethereum Mainnet burns the basefee as part of EIP-1559, several production EVM networks have adopted alternative designs that redirect protocol-level fee revenue to on-chain treasuries or governance-controlled funding systems. These precedents fall into two broad categories:

##### Networks that Redirect EIP-1559 BASEFEE
- Ronin Network — Redirects the EIP-1559 basefee to a DAO-governed treasury that funds infrastructure, validators, and ecosystem programs.

##### Networks that Redirect Other Forms of Protocol or Sequencer Revenue
- Celo — Redirects gas fees to a governance-managed Gas Fee Handler that allocates funds to community and climate initiatives.
- Mantle — Routes sequencer revenue to a DAO treasury for grants, tooling, and infrastructure.
- Polygon CDK — Allows sovereign rollups to implement EIP-1559-compatible fee hooks for governance-controlled treasuries.
- OP Stack (used by Base, Optimism) — Supports sequencer revenue splitting for public-goods funding.
- Arbitrum — Directs sequencer revenue into a DAO-managed treasury, with allocations governed through the AIP process.
- Optimism — Allocates sequencer revenue to Retroactive Public Goods Funding (RPGF).
- zkSync Era & Scroll — Include revenue hooks that can forward sequencer income to protocol-aligned treasuries.
- Avalanche Subnets — Some subnet configurations route transaction fees to validator-governed treasuries.
- Gitcoin DAO — While not fee-based, it provides a notable example of transparent, governance-directed public goods funding.

These examples demonstrate that redirecting protocol-level fee or revenue flows to transparent, governance-controlled treasuries is an established design pattern across modern EVM systems. Such mechanisms support sustainable funding for core protocol work, infrastructure, and public goods.

In adopting consensus-layer BASEFEE redirection, Ethereum Classic implements a non-inflationary, protocol-native funding mechanism that maintains ETC’s fixed monetary policy while enabling transparent and auditable treasury accumulation.

### Future Work (Non-Consensus Extensions)

The scope of ECIP-1111 is intentionally limited to the activation of EIP-1559, EIP-3198, and consensus-layer BASEFEE redirection to the Olympia Treasury (ECIP-1112).

Additional miner-alignment or revenue-smoothing mechanisms MAY be proposed in a separate, additive ECIP. A future proposal — tentatively referred to as ECIP-1115 — may explore optional approaches to modifying how Treasury-bound BASEFEE is handled at the application or governance layer.

Any such proposal:
- SHALL be introduced as an independent ECIP
- SHALL be strictly additive and SHALL NOT modify the consensus rules introduced in ECIP-1111
- SHALL undergo full review under the ECIP-1000 process
- SHALL require independent testnet validation prior to activation
- WOULD remain optional and modular within the broader Olympia framework

No additional miner-alignment or smoothing mechanics are included in ECIP-1111 to preserve its role as a minimal, isolated consensus change.

### Backwards Compatibility

The Olympia upgrade introduces:
- A new transaction type: Type-2 (EIP-1559)
- A new EVM opcode: BASEFEE (EIP-3198)
- Consensus-layer redirection of the BASEFEE amount to the immutable Olympia Treasury (ECIP-1112)

All existing functionality remains unchanged:
- Type-0 transactions continue to be valid and fully supported
- Type-1 (Access List) transactions introduced by ECIP-1103 remain valid and unchanged
- Previously deployed contracts operate without modification
- Historical blocks and state are preserved without retroactive changes

The upgrade is fully additive — the new transaction format and opcode are optional to use. Legacy (Type-0) and Access List (Type-1) transactions continue to function without modification.

#### Client Upgrade Requirements
- Clients that do not implement the Olympia upgrade will diverge from the canonical Ethereum Classic chain at the designated fork block.
- To remain in consensus, node operators MUST upgrade to a client version that supports:
- EIP-1559 (basefee mechanism and Type-2 transactions)
- EIP-3198 (BASEFEE opcode)
- Consensus-layer BASEFEE redirection to the deterministic Treasury address defined in ECIP-1112

#### Compatibility Characteristics
- Legacy Contract Support — Existing smart contracts and dApps function without modification.
- Treasury Isolation — The Treasury contract logic (ECIP-1112) is independent of application-layer behavior.
- Transaction-Type Flexibility — Users, miners, and developers may continue using Type-0 and Type-1 transactions if desired; Type-2 support is additive.

As with ECIP-1112, any non-upgraded clients will fork permanently from the canonical chain at activation. All blocks, transactions, and state transitions on the minority fork will be invalid on the main chain.

### Security Considerations

The Olympia upgrade introduces no new consensus-critical vulnerabilities beyond those already inherent in EIP-1559 and EIP-3198. Both features are widely deployed across the EVM ecosystem and have undergone extensive testing, review, and validation. Security considerations for ECIP-1111 focus primarily on ensuring correct and consistent implementation of consensus-layer BASEFEE redirection.

#### 1. EIP-1559 and EIP-3198 Safety
- Production Maturity — EIP-1559 and the BASEFEE opcode have been active on Ethereum Mainnet since 2021 and are implemented across numerous EVM-based networks (e.g., BSC, Polygon, Arbitrum, OP Stack chains).
- Independent Validation — These features have undergone formal analysis, multi-client testing, and long-term operational usage in production environments.

#### 2. BASEFEE Redirection Logic
- Single Consensus Deviation — The only functional divergence from Ethereum Mainnet’s EIP-1559 behavior is that ETC redirects the BASEFEE amount to the Olympia Treasury (ECIP-1112) rather than burning it.
- Consensus Enforcement — This redirection is enforced directly within the block finalization logic. All participating clients MUST apply identical state-transition rules to avoid consensus divergence.
- Treasury Immutability — The Treasury contract defined in ECIP-1112 contains no upgrade mechanisms, administrative keys, or privileged withdrawal paths. It is a deterministic, immutable vault.

#### 3. Client Implementation Requirements
- State-Transition Accuracy — Clients MUST correctly compute and redirect the BASEFEE amount to the Treasury. Incorrect calculation or transfer risks:
- Rounding inconsistencies
- Ledger imbalance
- Block execution mismatches
- Test Vector Updates — Test vectors that assume basefee burning MUST be adapted to validate Treasury accumulation behavior.
- Cross-Client Alignment — All clients MUST produce identical results for basefee calculation, transaction processing, and Treasury accumulation.

#### 4. Treasury Isolation
- Execution Separation — ECIP-1111 specifies only consensus-layer revenue redirection. No withdrawal or governance logic is included in this ECIP.
- Independent Governance — Treasury spending and governance mechanisms are defined separately in ECIP-1112, ECIP-1113, and ECIP-1114. Their activation or operation does not alter the consensus rules introduced in ECIP-1111.

#### 5. Testnet and Audit Strategy
- Mordor Testnet Deployment — All ECIP-1111 functionality MUST be validated on Mordor prior to Mainnet activation. Testing SHOULD include:
- Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transaction handling
- Accurate BASEFEE accounting
- Treasury accumulation verification
- BASEFEE opcode correctness
- Audit Coordination — Although ECIP-1111 affects consensus-layer logic only, its interaction with ECIP-1112 SHOULD be reviewed to ensure correct integration of Treasury accumulation mechanisms.

#### Security Considerations Summary

The Olympia upgrade activates established EVM improvements and introduces a single consensus-layer modification to redirect the BASEFEE amount to an immutable Treasury contract. The upgrade is fully additive, preserves all existing EVM semantics, and makes no changes to historical state or previously deployed contracts. With correct implementation, cross-client alignment, and thorough testnet validation, the consensus changes defined in ECIP-1111 can be adopted safely and predictably across the Ethereum Classic network.

### Related ECIPs in the Olympia Upgrade

ECIP-1111 is one of four coordinated proposals that together define the Olympia upgrade path.
Only ECIP-1111 introduces a consensus-layer change. ECIP-1112, ECIP-1113, and ECIP-1114 operate entirely at the contract or application layer and do not require a network hard fork.
Although ECIP-1113 and ECIP-1114 are not required for activation of ECIP-1111, they are required for any future Treasury disbursements. Until those governance components are deployed, the Treasury defined in ECIP-1112 remains an immutable, non-spending vault.
- ECIP-1111 — Olympia EVM and Protocol Upgrades
 Activates EIP-1559 and EIP-3198 on Ethereum Classic and redirects the BASEFEE amount to the Treasury instead of burning it.
- ECIP-1112 — Olympia Treasury Contract
 Defines the deterministic, immutable Treasury contract that receives all redirected BASEFEE revenue and holds it in a governance-isolated vault.
 Without ECIP-1113 and ECIP-1114, the Treasury can accumulate but cannot release funds.
- ECIP-1113 — Olympia DAO Governance Framework
 Specifies the governance architecture that, once deployed, becomes the required governance layer for authorizing Treasury disbursements.
 ECIP-1113 is optional relative to ECIP-1111 activation, but mandatory for enabling any spending.
- ECIP-1114 — Ethereum Classic Funding Proposal Process
 Defines the standardized, permissionless proposal format (ECFP) and the hash-bound execution model that ECIP-1113 uses to authorize Treasury disbursements.

#### Interdependency Summary
- ECIP-1111 introduces consensus-layer BASEFEE redirection to the Treasury.
- ECIP-1112 deploys the immutable Treasury contract to receive and hold funds.
- ECIP-1113 provides the governance framework that is required for any Treasury withdrawals.
- ECIP-1114 defines the standardized proposal process that ECIP-1113 enforces for all disbursements.

All four ECIPs are designed for modular and independent activation:
- ECIP-1111 and ECIP-1112 MAY be activated first to begin revenue accumulation.
- ECIP-1113 and ECIP-1114 MAY be activated later, enabling controlled Treasury governance and disbursement without requiring any changes to ECIP-1111.

### Copyright

Copyright and related rights waived via
CC0.

### Appendix: EVM Precedents for BASEFEE Redirection and EIP-1559 Adoption

ECIP-1111 activates EIP-1559 and EIP-3198 on Ethereum Classic, with the modification that the basefee amount is redirected to the Treasury contract defined in ECIP-1112 rather than burned. While Ethereum Mainnet treats the basefee as a deflationary burn, several EVM networks use alternative designs that redirect protocol-level fee revenue or sequencer revenue toward governance-controlled treasuries. These precedents demonstrate the diversity of fee-handling models within the broader EVM ecosystem.

#### Precedents for Protocol-Level Revenue Redirection

| Network | Fee / Revenue Mechanism | Governance Model | Notes |
|-----------------|-------------------------------------------|-------------------------------------|-----------------------------------------------------------------------|
| Ronin | EIP-1559 basefee redirected to treasury | Ronin DAO (Snapshot + Multisig) | Direct example of basefee redirection rather than burning |
| Celo | Gas fees routed to Gas Fee Handler | Celo Governance | Non-1559 mechanism for funding community and climate initiatives |
| Mantle | Sequencer revenue to DAO treasury | Mantle Governance | L2-style revenue sharing; not EIP-1559 basefee |
| Polygon CDK | Optional fee hooks | Rollup-local DAO governance | Sovereign rollups may implement basefee-like hooks |
| OP Stack | Sequencer revenue sharing | L2-local DAO governance | Revenue allocation for public goods; not EIP-1559 basefee |
| Arbitrum | Sequencer revenue to DAO treasury | Arbitrum DAO | Uses AIP process; not EIP-1559 basefee |
| Optimism | Sequencer revenue to RPGF | Bicameral DAO | Retroactive public goods funding |

#### Lessons Applied in ECIP-1111
- Protocol-Layer Enforcement — ECIP-1111 redirects the basefee amount at the consensus layer, ensuring the behavior is deterministic and identical across all participating clients.
- Consistency with Existing EIPs — ECIP-1111 retains all other EIP-1559 semantics, including dynamic basefee adjustment, transaction pricing, and tip handling.
- Deterministic Treasury Address — ECIP-1112 defines a fixed, consensus-recognized Treasury address to ensure consistent behavior across clients.
- Modular Governance Separation — ECIP-1111 implements revenue redirection only. Governance mechanisms for Treasury withdrawals are defined separately in ECIP-1113 and ECIP-1114 and are not part of this ECIP.

ECIP-1111 adapts the established EIP-1559 fee market to route value to an immutable, protocol-defined Treasury contract rather than burning it, enabling transparent and auditable accumulation of consensus-layer revenue while preserving Ethereum Classic’s Proof-of-Work and immutability guarantees.

### Appendix: EVM Compatibility Roadmap and Upgrade Candidates

#### Future Considerations: Toward Full EVM Compatibility

The Olympia Upgrade is intentionally limited in scope to EIP-1559 and EIP-3198. However, additional Ethereum protocol improvements have been reviewed as potential candidates for future consideration. The table below categorizes EIPs based on their technical compatibility with Ethereum Classic’s Proof-of-Work model and their relevance to developer tooling and interoperability.
Note: The EIPs listed below are not included in ECIP-1111. Adoption of any additional EIPs would require a separate ECIP, independent community review under ECIP-1000, and successful Mordor Testnet validation before Mainnet activation.

#### ✅ Candidates for Future Evaluation

These EIPs appear technically compatible with ETC’s Proof-of-Work design and may improve developer experience or EVM alignment without introducing breaking changes:

| EIP | Title | Notes |
|--------|-----------------------------------------|-------------------------------------------------------------------------------------------------|
| 1283 | SSTORE Gas Metering Changes | Improves storage efficiency; widely supported by tooling; considered low-risk and high-utility.|
| 5656 | MCOPY Memory Instruction | Performance optimization; beneficial for modern EVM workloads including zk-related tooling. |
| 6780 | SELFDESTRUCT Semantics Change | Aligns with Shanghai semantics; removes non-deterministic contract deletion; requires review. |
| 1153 | Transient Storage Opcodes | Adds ephemeral storage support used in modern dApp patterns; no impact on PoW consensus. |
| 2935 | Save Historical Block Hashes in State | Provides access to past block hashes for certain oracle-like use cases; optional enhancement. |
| 7623 | Increase Calldata Cost | Adjusts calldata gas costs; relevant for reducing calldata-intensive patterns; PoW-tunable. |

#### ⚠️ Optional or Lower Priority

These EIPs have limited impact or depend on ecosystem factors not currently present on ETC:

| EIP | Title | Notes |
|--------|-------------------------------|------------------------------------------------------------------------------------|
| 170 | Contract Code Size Limit | Mitigates contract bloat; ETC has not seen high-volume DoS patterns. |
| 3228 | Difficulty Bomb Delay | Specific to Ethereum’s PoS transition; not applicable to ETC’s PoW model. |
| 7691 | Blob Throughput Increase | Depends on EIP-4844 blob support, which ETC does not currently implement. |
| 7702 | Set EOA Account Code | Supports account abstraction; not currently a priority for ETC. |

#### ❌ Incompatible or Out of Scope (PoS-Specific or High-Risk)

These EIPs require consensus structures incompatible with ETC’s Proof-of-Work model or introduce architectural assumptions ETC does not share:

| EIP(s) | Reason for Exclusion |
|-----------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|
| 3675, 4895, 4788, 4399, 6110, 7251, 7549, 7002, 7685, 7840 | Depend on Ethereum’s Proof-of-Stake, beacon chain, or validator lifecycle; incompatible with ETC’s PoW consensus. |
| 4844, 7516 | Require blob transaction support and related consensus infrastructure; high complexity and low relevance for ETC today. |
| 2537 | Introduces BLS12-381 precompiles primarily used for PoS validator duties; expands cryptographic surface area unnecessarily. |

Community members are encouraged to submit ECIPs for any desired EVM upgrade using the standard process, prioritizing compatibility, security, and Ethereum Classic’s Proof-of-Work integrity.

### Simple Summary

This ECIP introduces an optional governance-layer mechanism that applies a deterministic L-curve to a governance-selected portion of Treasury-held BASEFEE revenue across a future window, only if smoothing is explicitly activated through an OIP. The mechanism reshapes the timing of BASEFEE-derived incentives to provide a more predictable miner revenue profile if governance elects to use smoothing for miner payouts; this ECIP does not mandate such use, and smoothing remains entirely optional. All parameters are fully configurable through the Olympia Improvement Proposal (OIP) process.

### Abstract

This ECIP specifies a governance-layer framework for applying an L-curve smoothing function to Treasury-held BASEFEE revenue. After each block’s basefee amount is deposited into the Olympia Treasury under ECIP-1111 and ECIP-1112, a configurable portion may be smoothed across a governance-defined future window. The mechanism operates strictly after consensus-layer deposit into the Treasury and produces a predictable revenue schedule without altering consensus-layer EIP-1559 behavior or block-processing rules.

Smoothed payouts are authorized solely through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and expressed as standard Treasury withdrawals under ECIP-1114. All operational parameters—window length, weighting function, allocation fraction, and miner distribution policy—are set or modified exclusively through the Olympia Improvement Proposal (OIP) process.

### Motivation

As Ethereum Classic’s fixed-emission schedule (ECIP-1017) continues to reduce block subsidies over time, priority fees (tips—defined in Type-2 transactions as maxPriorityFeePerGas and implicit in gasPrice for Type-0 and Type-1) remain the primary consensus-level fee mechanism for miners. These variable priority fees directly reward block producers and continue to anchor Proof-of-Work incentives regardless of how the BASEFEE is handled.

Under ECIP-1111 and ECIP-1112, 100% of the BASEFEE is redirected to the Olympia Treasury. Any decision to allocate a portion of that Treasury-held BASEFEE to miners is optional, fully governed through OIPs, and intended only to complement—not replace—the consensus-level priority-fee incentive mechanism.

If the Olympia DAO elects to direct a percentage of Treasury-held BASEFEE toward long-term network security, governance MAY choose to route those allocations through governance-approved payouts, without creating any entitlement, expectation, or obligation toward miners or any other recipient class. These allocations will inherently fluctuate with network activity. A smoothing mechanism can reshape the timing of such allocations, reducing short-term volatility and providing a more predictable payout profile only if governance elects to activate it, all without altering consensus-layer incentives such as miner tips. This ECIP does not modify, reinterpret, or supplement the monetary policy defined under ECIP-1017; ECIP-1115 smoothing applies only to Treasury-held BASEFEE after deposit into the immutable Treasury defined in ECIP-1112, and affects solely the timing of governance-approved payouts, with no effect on issuance, BASEFEE computation, priority-fee mechanics, or any consensus-layer economic behavior.

Critically, the smoothing framework allows Ethereum Classic to experiment with security-budget policies incrementally and empirically. Rather than setting hard monetary rules (as was done with ECIP-1017) without fee-market data, smoothing keeps BASEFEE-based miner incentives flexible, adjustable, and governance-driven. This design preserves consensus simplicity, avoids premature monetary commitments, and lets the network adapt as Type-2 fee markets mature post-Olympia.

Placing smoothing at the governance layer ensures the mechanism is fully optional, tunable over time, and upgradable without hard forks, while the underlying priority-fee mining incentives remain unchanged at the consensus layer.

### Specification

#### 1. Scope

This ECIP defines a governance-layer mechanism that applies a deterministic L-curve to a configurable portion of Treasury-held BASEFEE revenue after it has been deposited under the consensus rules of ECIP-1111 and ECIP-1112. It introduces no changes to consensus behavior, EIP-1559 basefee computation, miner priority fees (tips), block rewards, difficulty adjustment, block validity, or state-transition rules.

Smoothing logic operates strictly at the application and governance layer. Any payout generated by smoothing MUST be authorized through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and expressed as a standard Treasury withdrawal under ECIP-1114. This ECIP does not modify Treasury access control, hash-bound proposal semantics, or the execution pathway.

ECIP-1115 specifies only the smoothing framework. All operational parameters—including the smoothing window, weighting function, allocation fraction, payout cadence, and miner distribution method—MUST be introduced, modified, or removed exclusively through the Olympia Improvement Proposal (OIP) process.

The mechanism is optional. The Olympia DAO MAY activate, adjust, suspend, or disable smoothing without requiring a hard fork.

#### 2. Smoothing Model

The smoothing mechanism applies a deterministic weighting function (“L-curve”) to a configurable portion of Treasury-held BASEFEE revenue over a governance-defined future window. The model determines only the timing of BASEFEE-derived payouts; total allocated amounts remain unchanged.

Let Bk denote the BASEFEE revenue credited to the Treasury for block k under ECIP-1111 and ECIP-1112. Governance MAY specify a fraction f of each Bk to be included in smoothing, where 0 ≤ f ≤ 1. The smoothed portion is:

Rk = f · Bk

A governance-defined smoothing window of length N assigns a payout schedule across indices j = 1…N using a deterministic, on-chain computable weighting function L(j). The following invariants apply:
- Normalization:
 Σ₍ⱼ₌₁→ᴺ₎ L(j) = 1
- Determinism:
 L(j) MUST be fully deterministic, on-chain computable, and depend solely on governance-approved parameters. L(j) MUST NOT rely on off-chain data sources, randomness, or any non-deterministic process.
- Non-negativity:
 L(j) ≥ 0 for all j.
- Configurability:
 N, f, and the functional form of L(j) MUST be adjustable solely through the OIP process.

The smoothed allocation attributed to offset index j for block k is:

A(k + j) = Rk · L(j)

This framework does not mandate a specific curve family. L(j) MAY be linear, piecewise linear, exponential, polynomial, or parameterized, provided it satisfies the above invariants and is fully on-chain computable.

The smoothing model defines only the timing and magnitude of intended allocations. Execution of payouts is governed separately and MUST follow ECIP-1113 and ECIP-1114 using standard Treasury withdrawal semantics.

#### 3. Allocation Rule

For each block k, the smoothing mechanism produces a sequence of intended allocations A(k + j) for j = 1…N, as defined in Section 2. These allocations represent scheduled values that MAY be used as inputs to standard Treasury withdrawal semantics after approval via the governance pipeline defined in ECIP-1113 and ECIP-1114.

Smoothing defines only the schedule of intended payouts; it does not create rights, claims, reservations, implied obligations, or automatic execution. All payouts MUST be explicitly authorized by governance through the OIP process or through a governance-approved smoothing module that prepares Treasury withdrawal calls conforming to ECIP-1114.

Multiple smoothing schedules MAY overlap. For a given target index t, the cumulative intended allocation—explicitly not a liability, reserve, obligation, earmark, or claim upon Treasury funds—is the sum of all applicable contributions:

Atotal(t) = Σ over all k such that (k + j = t) of A(k + j)

All such sums MUST be:
- Deterministic: computable solely from governance-defined parameters and the historical sequence of Treasury-held BASEFEE credits.
- Non-negative: no negative adjustments or offsetting entries are permitted.
- Monotonic in scope: smoothing MUST NOT withdraw or reserve Treasury funds automatically; only governance-approved actions MAY cause value to exit the Treasury.

This ECIP does not define buffering, queuing, or state-tracking requirements. Any smoothing module that aggregates intended allocations MUST treat the smoothing rule as a deterministic transformation over historical Bk values and MUST NOT modify Treasury behavior or access control. Execution of actual payouts remains exclusively governed by the Governor → Timelock → Executor pipeline defined in ECIP-1113 and ECIP-1114.

Smoothing MUST NOT imply buffering, queuing, or earmarking funds inside any contract. Only explicit governance-approved Treasury withdrawals create real movements of value.

#### 4. Miner Distribution Mechanism

Smoothed allocations define only the hypothetical timing and magnitude of governance-controlled payouts and create no rights, claims, or reservations against Treasury-held funds. To convert any of these allocations into actual Treasury withdrawals, governance MAY designate a Miner Reward Module responsible for mapping approved smoothing outputs to specific recipient addresses. Such a module is optional, governance-defined, and MAY be used for any class of recipients—not only miners—and does not, by itself, create any entitlement, expectation, or preferential claim to Treasury-held BASEFEE for miners or any other group.

The Miner Reward Module operates strictly at the application layer and MUST:
- receive intended allocation amounts from a governance-approved smoothing module,
- compute miner or mining-pool payout shares according to parameters defined through the OIP process,
- prepare Treasury withdrawal calls that conform to ECIP-1114, and
- rely exclusively on the Governor → Timelock → Executor pipeline defined in ECIP-1113 for authorization and execution.

The Miner Reward Module MUST NOT:
- modify consensus-layer behavior,
- determine miner eligibility using off-chain or discretionary authority,
- read or modify Treasury state outside authorized execution,
- enforce automatic payouts or reserve Treasury funds,
- bypass the governance execution pipeline, or
- introduce privileged roles, admin keys, or discretionary veto authority.

Recipient identification MUST NOT rely on hashpower or mining-rate data sourced from off-chain systems, unverifiable APIs, or any non-deterministic computation.

Governance MAY choose any miner identification or weighting method, including but not limited to:
- mining pool payout addresses specified through governance,
- miner self-declared payout addresses registered through open, permissionless processes,
- hashpower-attestation mechanisms defined via OIP, or
- any on-chain computable distribution rule that satisfies ECIP-1113 invariants.

All such methods MUST be deterministic, transparent, and fully configurable through OIP. No miner or pool obtains an automatic right to funds from smoothing; payouts require explicit governance approval and execution through ECIP-1113 and ECIP-1114.

No recipient class—including miners, pools, infrastructure providers, or other groups—receives any priority, privilege, or implied preference under this ECIP. All payouts must be explicitly authorized via governance.

This ECIP does not mandate a specific Miner Reward Module design. Multiple versions MAY exist over time, and governance MAY update or replace them via the OIP process without requiring a network fork.

#### 5. Governance Integration

All parameters and operational components of the smoothing mechanism MUST be governed exclusively through the Olympia Improvement Proposal (OIP) process defined in ECIP-1113. This includes, but is not limited to:
- the smoothing window N,
- the allocation fraction f,
- the weighting function L(j) and its governing parameters,
- activation or deactivation of smoothing,
- upgrade or replacement of the Smoothing Module, and
- upgrade or replacement of the Miner Reward Module.

Any module that participates in smoothing MUST operate entirely at the application layer and MUST rely on the Governor → Timelock → Executor execution pipeline for authorization of Treasury withdrawals. Smoothing modules and Miner Reward Modules MUST NOT contain any mechanism for automatic withdrawal, reservation, or direct access to Treasury funds.

No smoothing-related module MAY modify, intercept, or bypass the standard Governor → Timelock → Executor execution path under any circumstances.

Governance MAY adopt, revise, or disable smoothing through standard OIP proposals. Any update to smoothing parameters MUST be:
- deterministic and on-chain verifiable,
- published as part of the OIP payload, and
- effective only after successful execution through the Timelock and Executor.

Governance MAY replace or upgrade smoothing-related modules provided that all implementations:
- preserve the invariants defined in this ECIP,
- do not modify Treasury code or its access control,
- do not alter consensus-layer behavior defined in ECIP-1111,
- do not alter the hash-bound execution semantics defined in ECIP-1114, and
- remain fully transparent, permissionless, and auditable on-chain.

This ECIP does not mandate a specific governance cadence or parameter schedule. All decisions regarding smoothing configuration, module selection, update frequency, and activation state are left to OIP-controlled governance and do not require a network fork.

#### 6. Treasury Behavior

This ECIP does not modify the Olympia Treasury defined in ECIP-1112. The Treasury continues to receive 100% of the basefee amount for each block under the consensus-layer rules of ECIP-1111, and smoothing operates only after these deposits have been made.

The Treasury does not compute smoothing schedules, maintain smoothing state, or reserve funds for smoothing. All Treasury withdrawals—whether related to smoothing or any other purpose—MUST be authorized exclusively through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and encoded as standard Treasury calls under ECIP-1114.

Smoothing modules and Miner Reward Modules MUST NOT introduce any changes to the Treasury’s access control, immutability, or withdrawal semantics. All interactions with the Treasury are limited to governance-approved execution payloads that use the existing withdrawal interface defined in ECIP-1112.

Smoothing MUST NOT add state variables, flags, or configuration references to the Treasury, nor may it require Treasury modification, redeployment, or upgrade.

This ECIP defines no new Treasury functions and introduces no additional responsibilities for Treasury code or consensus-layer behavior.

#### 7. Optionality

The smoothing mechanism defined in this ECIP is fully optional. Governance MAY activate, adjust, suspend, or disable smoothing through the Olympia Improvement Proposal (OIP) process without requiring a network fork or any modification to consensus-layer behavior, and disabling smoothing SHALL NOT affect any historical allocations or create retroactive obligations. The default state of the system is that smoothing is inactive unless explicitly activated by an OIP.

Enabling or disabling smoothing does not affect Treasury deposits under ECIP-1111 and ECIP-1112, nor does it change the execution pipeline defined in ECIP-1113 and ECIP-1114. If smoothing is inactive, Treasury-held BASEFEE revenue remains available for standard governance-directed use through existing ECFP processes.

### Rationale

ECIP-1115 introduces an optional mechanism for reshaping the timing of BASEFEE-derived Treasury payouts without altering Ethereum Classic’s consensus rules or the EIP-1559 transaction fee mechanism. The smoothing model is motivated by economic analyses that study the effects of distributing fee revenue across multiple future blocks—most notably the ℓ-smoothed “pay the base fee forward” mechanism described by Roughgarden (§8.3). In that model, the base-fee revenue from block k is distributed evenly across the next ℓ blocks, reducing revenue variance while preserving incentive alignment.

ECIP-1115 adapts this economic insight to the Olympia framework by applying smoothing only after the basefee amount has been deposited into the immutable Treasury under ECIP-1111 and ECIP-1112. This preserves the transaction-fee semantics of EIP-1559 while allowing the network to experiment with alternative temporal distributions of Treasury-held BASEFEE revenue. By generalizing Roughgarden’s uniform ℓ-window rule into an arbitrary, governance-defined weighting function L(j), ECIP-1115 enables the community to evaluate linear, exponential, piecewise, or other curve families as empirical data becomes available.

Placing smoothing at the governance layer rather than at consensus offers several benefits:
- Consensus-layer simplicity:
 The underlying transaction-fee mechanism remains unchanged across all clients, avoiding additional consensus complexity or opportunities for divergence.
- Treasury immutability:
 The Treasury remains a minimal, immutable vault that does not maintain smoothing state or engage in revenue scheduling logic.
- Governance flexibility:
 All smoothing parameters—window length, weighting function, allocation fraction, payout cadence, and miner distribution methods—can be adjusted or replaced through the OIP process without requiring new hard forks.
- Determinism and auditability:
 Smoothing schedules are derived entirely from deterministic, on-chain computable functions using historical BASEFEE credits. This ensures predictable behavior and allows independent verification of intended allocations.
- No automatic entitlements:
 Smoothing defines a schedule of intended allocations only. All actual payouts require a successful governance action and are executed through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and the funding-proposal structure of ECIP-1114.

The Rk → A(k+j) construction is deliberately chosen because it captures the essence of ℓ-smoothed economic design while remaining fully compatible with Olympia’s Treasury-based governance model. ECIP-1115 offers a governance-controlled tool for reducing short-term volatility in miner incentive flows as fixed issuance declines, while keeping all changes strictly outside the Ethereum Classic consensus layer and preserving the architectural principles of Olympia. The ℓ-smoothed model is referenced only as economic context and does not prescribe any specific window length, weighting function, or numerical configuration. All parameters remain entirely governance-defined.

### Backwards Compatibility

ECIP-1115 introduces no changes to Ethereum Classic’s consensus rules, transaction processing, basefee computation, block validity, or state-transition semantics. All consensus-layer behavior defined in ECIP-1111 and ECIP-1112 remains unchanged, including the requirement that 100% of the basefee amount is credited to the Treasury during block finalization.

Because smoothing operates exclusively at the governance and application layer, all existing and future clients remain fully consensus-compatible without any changes.

Smoothing does not modify the Treasury contract defined in ECIP-1112 or the governance execution pipeline defined in ECIP-1113. All withdrawals related to smoothing continue to use the hash-bound, permissionless execution model defined in ECIP-1114. No migrations, state recalculations, or protocol upgrades are required for activation or deactivation of smoothing modules.

As a result, ECIP-1115 is fully backward compatible with all existing Ethereum Classic clients and has no impact on peer-to-peer networking, block production, or chain selection. Activation or deactivation of smoothing cannot cause a consensus fork under any circumstances, as smoothing operates exclusively at the governance layer.

### Security Considerations

ECIP-1115 introduces no new consensus-layer behavior and therefore does not alter consensus-level security assumptions. All security considerations are confined to the governance and application layers where smoothing is defined and executed.

Smoothing MUST NOT introduce privileged recipients, preferred entities, or governance-exempt payout flows. All recipients must be subject to identical governance-verification rules.

Smoothing MUST NOT generate any claimable rights, future expectations, implicit liabilities, or accounting obligations against the Treasury.

#### Governance and Execution Integrity

All payouts associated with smoothing MUST be authorized through the Governor → Timelock → Executor pipeline defined in ECIP-1113. Smoothing modules and Miner Reward Modules MUST NOT contain automatic withdrawal logic, reserve Treasury funds, or bypass governance controls. Any deviation from deterministic, governance-approved execution could undermine the immutability guarantees of ECIP-1112.

#### Treasury Isolation

The Olympia Treasury remains an immutable vault that does not compute, store, or track smoothing allocations. Smoothing MUST NOT introduce new Treasury state, mutate existing state, or alter the Treasury’s withdrawal semantics. All payout requests MUST conform to the existing hash-bound execution model defined in ECIP-1114.

#### Deterministic Computation

Smoothing schedules MUST be derived from deterministic, on-chain computable functions defined through governance. Modules MUST NOT rely on off-chain data sources, external oracles, or discretionary operator input. Non-deterministic or off-chain dependencies could produce inconsistent allocations and undermine the auditability of smoothing behavior.

#### Recipient Identification and Fairness

Any method used to identify miners or mining pools—such as self-declared payout addresses, governance-defined recipients, or hashpower-based attestations—MUST be transparent, deterministic, and fully configurable through OIP. No module MAY introduce privileged recipients, opaque weighting systems, or off-chain veto authority.

#### Overlapping Schedules and Aggregation

Multiple smoothing windows may overlap. Implementations MUST ensure that cumulative allocations are computed deterministically and do not exceed governance-approved limits. Aggregation logic MUST NOT imply future claims on Treasury funds; only governance-approved executions may transfer value.

#### Optionality and Activation Risks

Because smoothing is optional, governance MAY activate or deactivate it at any time. Parameter changes or module replacements SHOULD be evaluated carefully to avoid unexpected shifts in payout schedules. Rapid or uncoordinated parameter changes may affect miner expectations but pose no consensus-level risk.

#### No Miner Entitlements

Smoothing defines intended allocations only. No miner obtains an enforceable right to Treasury funds based on smoothing schedules alone. All payouts require explicit approval through ECIP-1113 and MUST be encoded as standard Treasury calls under ECIP-1114.

### Implementation Notes

This ECIP defines the framework and invariants for smoothing Treasury-held BASEFEE revenue. It does not mandate a particular contract structure or implementation strategy. The following notes provide guidance for implementers while preserving the modularity and immutability guarantees of ECIP-1112–1114.

Failure or misconfiguration of a Smoothing Module or Miner Reward Module MUST NOT impair or delay standard Treasury operations or governance-authorized withdrawals.

No default smoothing parameters or module configurations are defined by this ECIP; governance MUST explicitly activate smoothing before it has any effect.

#### Smoothing Module Structure

A Smoothing Module MAY be implemented as a standalone smart contract or as a set of coordinating contracts responsible for:
- receiving governance-approved parameters (N, f, L(j), and related configuration),
- computing intended allocations according to the smoothing model,
- producing deterministic outputs that can be referenced in governance-approved Treasury withdrawal calls.

The Smoothing Module MUST NOT hold funds, modify Treasury balances, or introduce automatic withdrawal logic.

#### Governance Integration

All parameter updates—such as changes to window length, weighting function, allocation fraction, or payout cadence—MUST be applied through the Olympia Improvement Proposal (OIP) process. Implementers SHOULD design modules with clear on-chain parameter interfaces so governance can update configuration safely and transparently.

#### Deterministic Allocation Outputs

Smoothing outputs SHOULD be expressed as deterministic, on-chain computable values. Implementations MAY store intermediate results or compute allocations on demand, provided that:
- output values are reproducible from historical Treasury-held BASEFEE amounts B_k and governance-approved parameters; and
- no off-chain data sources, randomness, or discretionary operator input is required.

#### Miner Reward Module

A Miner Reward Module MAY be implemented to map intended smoothing allocations to recipient addresses. Such modules SHOULD:
- support on-chain computation of payout shares,
- accept configuration via OIP,
- expose deterministic logic only,
- prepare Treasury withdrawal calls conforming to ECIP-1114.

The module MUST NOT reserve Treasury funds, maintain privileged withdrawal authority, or depend on opaque off-chain attestation sources.

#### Interaction With the Treasury

The ECIP-1112 Treasury remains unchanged. Implementations MUST treat the Treasury as an immutable vault that only executes authorized withdrawal calls arriving via the Executor.

Any implementation MUST ensure:
- no direct calls to the Treasury outside the governance pipeline,
- no alteration of Treasury state or semantics, and
- no expectation that the Treasury stores smoothing state.

#### Off-Chain Tools

Indexers, dashboards, or analytics tools MAY compute and display projected smoothing schedules. Such tooling is non-normative and MUST NOT be required for correct on-chain operation.

#### Parameter Defaults

This ECIP defines no default parameters. Implementers SHOULD assume all parameter values are unset until supplied via OIP, and SHOULD ensure contract initialization requires explicit, governance-approved activation.

### Related ECIPs in the Olympia Upgrade

ECIP-1115 builds on the modular Olympia framework defined across ECIPs 1111–1114. Each component provides a distinct layer of the architecture:
- ECIP-1111 — Olympia EVM and Protocol Upgrades
 Activates EIP-1559 and redirects the basefee amount to the Olympia Treasury. Smoothing operates on Treasury-held BASEFEE as defined in ECIP-1112, independent of transaction type or origin.
- ECIP-1112 — Olympia Treasury Contract
 Defines the immutable Treasury that receives all consensus-layer basefee deposits. Smoothing operates strictly on Treasury-held BASEFEE after deposit and does not alter Treasury code or access control.
- ECIP-1113 — Olympia DAO Governance Framework
 Establishes the Governor → Timelock → Executor pipeline, which is the exclusive path for authorizing all Treasury withdrawals, including any optional smoothing-related payouts.
- ECIP-1114 — Ethereum Classic Funding Proposal Process (ECFP)
 Specifies the hash-bound execution format required for all Treasury releases. Any smoothing-derived payout MUST be encoded as a standard ECIP-1114 execution payload.

ECIP-1115 adds an optional governance-layer mechanism for applying L-curve smoothing to Treasury-held BASEFEE. It does not modify ECIP-1111 through ECIP-1114 and can be activated, adjusted, or disabled independently through the OIP process.

### References and Related Work

#### Academic Foundation
- Roughgarden, Tim.
 Transaction Fee Mechanism Design for the Ethereum Blockchain (2021).
 Section §8.3 introduces the ℓ-smoothed “pay the base fee forward” mechanism, distributing per-block revenue across a future window to reduce variance while preserving incentive alignment.
 ECIP-1115 adapts this concept into a governance-controlled L-curve applied solely to Treasury-held BASEFEE after consensus-layer deposit.

#### Governance-Layer Timing & Scheduling Precedents

ECIP-1115 aligns with established EVM governance patterns in which timed execution, scheduled payouts, or parameterized release windows are implemented at the governance layer through timelocks or controlled modules:
- Compound Governor Bravo — canonical timed-execution model using a Governor → Timelock → Executor pipeline.
- MakerDAO (MCD + MIPs) — scheduled executive actions and parameter updates via time-delayed governance spells.
- Aave Governance v2/v3 — modular, timelocked execution for treasury actions and parameter changes.
- ENS DAO — utilizes standard governance-and-timelock flows for delayed execution of approved actions.

These systems demonstrate that temporal control of payouts and actions is a governance-layer function, not a consensus modification—mirroring ECIP-1115’s placement of smoothing above protocol semantics.

#### DAO Treasury Timing & Recurring Distribution Patterns

A range of DAO treasuries implement recurring, epoch-based, or streaming payouts through governance-approved mechanisms. These patterns provide practical precedents for ECIP-1115’s role as a time-smoothing, governance-controlled payout scheduler:
- Arbitrum DAO — multi-stage incentive programs and periodic distributions approved through governance.
- Optimism RetroPGF — recurring, epoch-based funding rounds disbursing treasury allocations in structured intervals.
- Celo Community Fund — configurable, season-based governance allocations over a defined timeframe.
- Mantle Treasury programs — modular, recurring distributions from treasury controlled by DAO vote.

These systems show that temporal structuring of treasury payouts is common and governance-driven.

#### On-Chain Streaming & Programmatic Disbursement Tools

Modern DAOs increasingly use streaming or vesting mechanisms to smooth treasury outflows over time in a governance-controlled manner:
- Superfluid — real-time streaming of grants, incentives, or salaries under DAO governance, used to distribute treasury funds over predictable intervals.
- Hedgey — on-chain vesting and multi-period distribution tooling widely adopted for structured incentive programs and scheduled treasury disbursements.

These tools demonstrate that smoothing or time-distribution of payouts is now a common governance-layer pattern used to manage treasury volatility and cadence—precisely the role ECIP-1115 fills for Treasury-held BASEFEE.

#### Alignment With Olympia and EVM Best Practices

ECIP-1115 follows these governance-layer precedents by:
- applying a parameterizable timing function (L-curve) exclusively through the Governor → Timelock → Executor pipeline,
- treating smoothing outputs as governance-controlled scheduling inputs—not automatic or entitlement-based payouts,
- operating solely on Treasury-held funds without altering consensus or modifying ECIP-1112 behavior, and
- enabling flexible, adjustable payout policy without any changes to protocol economics.

These properties ensure that smoothing operates entirely at the governance layer, preserves the immutability of the ECIP-1112 Treasury, and introduces no consensus-layer changes.

### Copyright

Copyright and related rights waived via
CC0.

### Simple Summary

Redirect all BASEFEE amounts introduced by ECIP-1111 to a deterministic, immutable smart contract — the Olympia Treasury — instead of burning them. The Treasury functions as a governance-isolated vault that can receive protocol-level revenue but cannot be modified or accessed except through a single, authorized execution entry point defined in a separate governance ECIP.

### Abstract

This ECIP defines the deployment of the Olympia Treasury, a deterministic and immutable smart contract that receives all BASEFEE amounts redirected under ECIP-1111. The Treasury is deployed at a fixed address, derived deterministically, and is hardcoded as the canonical recipient of protocol-level revenue. It functions exclusively as a governance-isolated vault: it may receive funds, but it cannot be upgraded, modified, or accessed directly.

The Treasury exposes a minimal, restricted interface that accepts revenue transfers and permits withdrawals only from a single, authorized execution entry point defined in separate governance ECIPs. No governance logic, proposal processing, or allocation rules are implemented within this contract. Its sole purpose is to provide a transparent, auditable, and immutable custody layer for protocol-level funds.

This ECIP does not introduce consensus behavior beyond that defined in ECIP-1111, and it does not define how funds are allocated or governed. Those mechanisms are specified independently in downstream ECIPs.

### Motivation

Ethereum Classic requires a transparent and protocol-native method to retain the BASEFEE amounts introduced under ECIP-1111. Because Ethereum Mainnet burns the BASEFEE, a deterministic mechanism is needed on Ethereum Classic to receive and hold this value at the protocol level without altering monetary policy or relying on discretionary off-chain actors.

A contract-based Treasury provides this functionality by:
- Offering an immutable, governance-isolated location for protocol revenue.
- Ensuring that accumulated funds are custodied transparently and audited on-chain.
- Providing a deterministic address that all upgraded clients can reference consistently.
- Enforcing strict separation between fund custody (this ECIP) and any governance or allocation logic (defined in separate ECIPs).

By deploying a minimal, immutable vault contract, Ethereum Classic gains a durable mechanism for securely accumulating protocol-level revenue while preserving consensus neutrality and avoiding any implicit trust in privileged intermediaries. This enables the network to adopt BASEFEE redirection under ECIP-1111 without introducing governance or execution semantics into the consensus layer.

### Specification

#### Treasury Address

The Olympia Treasury contract SHALL be deployed at a fixed, deterministic address.
This address SHALL be derived using a reproducible method (e.g., CREATE2) and SHALL be publicly documented prior to testnet activation.

Upon activation of ECIP-1111, all BASEFEE amounts defined in that ECIP SHALL be transferred to this address at the consensus layer.

Client implementations MUST treat this address as the canonical recipient of protocol-level BASEFEE revenue.

#### Deterministic Deployment

The Treasury contract’s address derivation MUST be identical across all client implementations.
The derivation method SHALL:
- Use a fixed deployer address
- Use a fixed, published salt
- Use the keccak256 hash of the final Treasury contract bytecode

An implementation MAY use CREATE or CREATE2, but the resulting address MUST be predetermined and published in advance of deployment.

A reference derivation method is provided below:

This code is illustrative only; client implementations SHALL rely on the published final address.

#### Consensus-Layer Funding Source

Upon activation of ECIP-1111:
- The full basefee-derived amount from each EIP-1559 transaction MUST be credited to the Treasury address at the consensus layer.
- This transfer SHALL occur during block finalization. Clients that omit, alter, or redirect this behavior SHALL fork from the canonical chain.

ECIP-1112 defines:
- the immutable Treasury contract,
- the consensus-layer requirement that 100% of the basefee-derived amount be deposited into it, and
- the single authorized withdrawal entry point.

All allocation, smoothing, or redistribution of Treasury-held BASEFEE — including mechanisms
defined in ECIP-1114 and ECIP-1115 — occurs strictly after deposit and must use the
governance-controlled execution pathway defined in ECIP-1113. ECIP-1112 itself implements
no allocation logic or distribution rules.

No additional revenue sources are defined in this ECIP.

#### Contract Requirements

The Olympia Treasury contract MUST satisfy the following constraints.

##### Immutability

The contract:
- MUST NOT contain upgrade mechanisms, proxy patterns, delegatecall, or selfdestruct.
- MUST be deployed exactly once.
- MUST NOT allow modification of authorization or upgrade-related state variables.

##### Minimal Responsibilities

The Treasury contract MUST:
- Accept incoming ETC transfers, including consensus-directed BASEFEE redirection.
- Expose its balance publicly through standard EVM semantics.
- Provide a single restricted withdrawal entry point callable only by the authorized governance executor defined in separate ECIPs.

The Treasury contract MUST NOT:
- Perform governance, voting, proposal validation, or metadata verification.
- Perform accounting logic beyond optional duplicate-execution prevention.
- Modify consensus-layer fee rules or participate in fee calculation.
- Emit governance-level events or track proposal metadata.

#### Access Control

The Treasury contract MUST:
- Restrict withdrawals to a single, authorized caller address.
- Reject all direct withdrawal attempts from EOAs.
- Reject calls from contracts other than the authorized governance executor.

This ECIP does not define the governance executor contract or its lifecycle; those are specified in ECIP-1113.

#### Minimal Reference Interface

A minimal Treasury interface MAY be expressed as:

The release() function:
- MUST transfer the specified amount to recipient only if msg.sender is the authorized executor.
- MAY internally track identifiers to prevent duplicate execution.
- MUST NOT implement proposal validation, metadata hashing, or governance logic.

No additional externally callable methods SHALL be exposed.

#### Event Emission

The Treasury contract MUST emit events sufficient for basic auditability.
At minimum:
- FundsReleased(address indexed recipient, uint256 amount)
- Received(address indexed from, uint256 amount)

These events MUST NOT include governance metadata or proposal identifiers, which are defined in ECIP-1113 and ECIP-1114.

#### Out-of-Scope Elements

The Treasury contract MUST NOT implement:
- Proposal hashing or metadata binding
- ECFP lifecycle logic
- Governance decision-making
- Timelock, voting, queueing, or scheduling
- Role delegation or admin key models
- Off-chain integrations
- Legal entity handling
- Fee smoothing, escrow logic, or L-curve mechanics

These functions are defined exclusively in downstream ECIPs.

### Rationale

#### Minimal, Immutable Architecture

The Olympia Treasury is intentionally designed as a minimal, immutable contract whose sole role is to receive and hold protocol-level BASEFEE revenue redirected under ECIP-1111. By excluding governance logic, proposal handling, or metadata processing, the Treasury remains simple, auditable, and resistant to operational or upgrade-related risks.

A minimal vault architecture provides:
- Safety at activation — No logic beyond accepting and releasing funds reduces the chance of deployment-time vulnerabilities.
- Long-term stability — With no upgrade paths or privileged roles, the Treasury remains reliable throughout the lifecycle of the protocol.
- Deterministic and verifiable behavior — All clients interact with the same immutable contract at a fixed address.

This approach limits the attack surface and ensures that the Treasury can safely begin accumulating funds before any governance mechanism is deployed.

#### Separation of Concerns

Strict separation between custody (ECIP-1112) and governance (ECIP-1113/1114) is a core design principle.
This separation ensures:
- The Treasury does not depend on the lifecycle, parameters, or implementation details of future governance systems.
- Governance upgrades or replacements can occur without modifying the Treasury contract.
- Consensus-layer behavior remains fully isolated from application-layer governance logic.

The Treasury exposes only one restricted withdrawal entry point, callable by an external executor defined in separate ECIPs. This creates a clear boundary between value custody and decision-making.

#### Deterministic Deployment and Client Consistency

A fixed, deterministic Treasury address is necessary for:
- Consensus-layer correctness — Clients must transfer BASEFEE revenue to an identical address to maintain consensus.
- Cross-client interoperability — Deterministic address derivation prevents divergence between implementations.
- Auditability — Participants can reliably verify inflows and contract behavior across all clients.

Using deterministic deployment via CREATE2 further guarantees that the published address can be reproduced independently.

#### Transparent, Protocol-Level Fund Custody

Redirecting the BASEFEE to a contract rather than burning it requires an on-chain location that is:
- Publicly visible
- Immutable
- Programmatically accessible
- Free of discretionary control

The Treasury contract satisfies these requirements by acting solely as a transparent ledger entry that accumulates protocol-level value without applying any discretionary logic to it.

#### Rationale Summary

The Treasury’s design emphasizes immutability, minimalism, and strict separation from governance.
This ensures that protocol-level revenue redirected under ECIP-1111 is held securely and transparently, while leaving all governance, allocation, and proposal processes to independently defined ECIPs.
By maintaining this separation, Ethereum Classic gains a durable and verifiable foundation for protocol-level fund custody without introducing dependencies, privileged roles, or upgradeable components into the vault itself.

### Related Work

Several EVM-based networks use contract-based mechanisms to receive protocol-level fees or revenue at deterministic, on-chain addresses. These patterns demonstrate the viability of directing endogenous network value into immutable or minimally permissioned contracts for transparent custody.

Examples include:
- Ronin Network
 Implements EIP-1559-style BASEFEE redirection into a contract-based treasury rather than burning the fee.
- Celo (Layer 1)
 Routes gas fees to a fixed contract (Gas Fee Handler) that acts as an on-chain sink for protocol-level value.
- Mantle (Layer 2)
 Directs sequencer revenue into a deterministic on-chain vault contract.
- Polygon (Layer 2)
 Uses contract-based treasuries for receiving protocol-level revenue defined by network rules.
- Arbitrum
 Sends sequencer revenue to a deterministic contract address for transparent custody.
- Optimism
 Uses on-chain sinks for sequencer revenue prior to any governance or allocation logic.

Although these systems differ in governance structure and distribution logic—topics defined separately in ECIP-1113 and ECIP-1114—they share a common architectural pattern relevant to ECIP-1112:
protocol-level revenue is routed to a deterministic, immutable contract that serves as a transparent custody layer.

This approach has proven reliable across multiple EVM ecosystems and informs the design choice to implement the Olympia Treasury as a minimal, immutable vault contract with a fixed, reproducible address.

### Implementation

The Olympia Treasury is implemented as a deterministic, immutable smart contract deployed at a fixed address.
Consensus-layer redirection of the BASEFEE amount is defined in ECIP-1111; this ECIP (1112) specifies only the contract that receives those funds.

#### Client Responsibilities

All Ethereum Classic client implementations MUST:
- Hardcode the Treasury address
 Clients MUST treat the published Treasury address as the canonical destination for protocol-level BASEFEE revenue following activation of ECIP-1111.
- Apply consensus-layer redirection
 During block finalization, clients MUST credit the full BASEFEE amount to the Treasury address in accordance with ECIP-1111.
 Clients MUST NOT expose alternative behaviors (e.g., burning).
- Maintain full EIP-1559 semantics
 Clients MUST preserve all EIP-1559 rules for calculating the basefee and miner priority fees, with the only modification being the redirection of the BASEFEE component to the Treasury address.

Failure to implement this behavior precisely SHALL result in a consensus fork.

#### Deployment Artifacts

Prior to activation on testnet and mainnet, the following SHALL be published:
- The Treasury contract’s bytecode
- The selected deployment method (CREATE or CREATE2)
- The fixed, deterministic address
- The derivation parameters (e.g., deployer address and salt), if using CREATE2

Deterministic publication of these artifacts ensures cross-client reproducibility and enables consistent verification by implementers and auditors.

#### Test Coverage and Validation

Testing MUST validate the following behaviors:
1. Correct Consensus Redirection
 Each client MUST correctly compute the BASEFEE amount and transfer it to the Treasury address in every post-activation block.
2. Cross-Client Consistency
 All upgraded clients MUST produce identical state transitions and balances for the Treasury address under shared test vectors.
3. Event Emission
 The Treasury contract MUST emit its defined events (FundsReleased, Received) during relevant operations and MUST NOT emit governance-related metadata.
4. Access Control Behavior
 The Treasury contract MUST accept incoming transfers from consensus-layer redirection and MUST reject unauthorized withdrawal attempts.
5. Reproducible Deployment
 The published deployment parameters MUST reproduce the exact Treasury address across all client implementations.

These tests ensure that the Olympia Treasury behaves as a minimal, deterministic vault compatible with ECIP-1111’s consensus-layer rules and suitable for integration with the governance executor defined in ECIP-1113.

#### Implementation Summary

This ECIP defines the immutable contract that receives protocol-level BASEFEE revenue.
Client software is responsible only for:
- redirecting BASEFEE to this contract, and
- ensuring consistent state-transition behavior across implementations.

All governance logic, proposal processing, and withdrawal authorization are defined outside this ECIP.

### Modular Treasury Deployment

The Olympia Treasury is implemented as a standalone, immutable smart contract.
It MAY be deployed and activated independently of any downstream governance components defined in separate ECIPs.
This separation enables a phased rollout consistent with the modular activation strategy introduced in ECIP-1111.

#### Pre-Governance Activation

Upon activation of ECIP-1111, the Treasury SHALL begin passively accumulating BASEFEE revenue.
No governance contracts or auxiliary infrastructure are required for the Treasury to function as a secure, protocol-level vault during this phase.

#### Security During the Accumulation Phase

At deployment, the Treasury’s authorized executor address SHALL be configured to a value that cannot satisfy the contract’s access control checks.
Until a valid executor is established under a separate governance ECIP, the Treasury’s withdrawal entry point MUST NOT be callable by any account or contract.
Any attempted withdrawal from unauthorized addresses MUST revert.

This configuration ensures that all accumulated funds remain securely locked, regardless of the timing or readiness of governance systems.

#### Deployment Advantages
- Forward Compatibility — The Treasury can operate unchanged across future governance upgrades because it contains no governance logic of its own.
- Security Isolation — The Treasury’s immutability and minimalism reduce the attack surface during the period before governance deployment.
- Phased Rollout Support — ECIP-1111 and ECIP-1112 can be activated as soon as they are ready, while governance mechanisms defined in other ECIPs can be deployed, audited, and reviewed independently.

This modular deployment model ensures that protocol revenue capture can begin immediately once ECIP-1111 is active, without requiring simultaneous activation of governance or proposal systems.

### Backwards Compatibility

ECIP-1112 introduces no changes to transaction formats, opcode behavior, or EVM semantics.
It defines only the immutable Treasury contract that receives the BASEFEE amounts redirected by ECIP-1111.
All consensus-layer changes related to BASEFEE handling are specified exclusively in ECIP-1111.

#### Node Behavior
- Upgraded Clients
 Clients that implement ECIP-1111 and recognize the Treasury address defined in this ECIP will:
- Process Type-0 (Legacy), Type-1 (Access List), and Type-2 (EIP-1559) transactions correctly.
- Redirect the computed BASEFEE amount to the Treasury address during block finalization.
- Non-Upgraded Clients
 Clients that do not implement ECIP-1111 and ECIP-1112 will:
- Fail to process Type-2 transactions correctly.
- Continue burning or mishandling the BASEFEE.
- Remain unaware of the Treasury contract address.

 Such clients will diverge at the activation block, forming a permanent consensus fork.

#### Contract and Tooling Compatibility
- Legacy Transactions
 Type-0 transactions remain valid and unaffected.
- Access List Transactions (Type-1)
 Type-1 transactions introduced by ECIP-1103 remain valid and unaffected, as ECIP-1112 adds no new semantics for transaction execution.
- Existing Contracts
 Smart contracts that do not reference the BASEFEE or the Treasury address continue to function unchanged.
- Tooling and dApps
 Applications that do not rely on EIP-1559 semantics remain fully functional.
 Tooling that supports Type-2 transactions (EIP-1559) MAY require updates to reflect that Ethereum Classic redirects the BASEFEE to the Treasury address rather than burning it, as defined in ECIP-1111.
 No changes are required for transaction submission or execution semantics.
- Treasury Contract Independence
 The Treasury contract can securely accumulate funds even if downstream governance contracts defined in other ECIPs are not yet deployed.

This ECIP preserves backward compatibility for all existing transaction types and smart contracts.
Only clients that fail to upgrade to support ECIP-1111 and recognize the Treasury address defined here will fork from the canonical chain at activation.

### Security Considerations

The Olympia Treasury is designed as an immutable, governance-isolated vault whose only responsibilities are to receive protocol-level BASEFEE revenue and permit withdrawals from a single authorized executor defined in a separate ECIP. The following security considerations apply.

#### 1. Contract Immutability
- The Treasury contract MUST be deployed exactly once and MUST NOT contain any upgrade mechanisms.
- No delegatecall, selfdestruct, proxy patterns, or privileged administrative keys SHALL be present.
- Immutability ensures that neither the contract’s authorization logic nor its withdrawal behavior can be modified after deployment.

#### 2. Access Control
- Withdrawals MUST only succeed when initiated by the authorized executor address defined in a separate governance ECIP.
- Until such an executor is deployed and configured, the withdrawal entry point MUST NOT be callable by any account or contract.
- All unauthorized withdrawal attempts MUST revert.

This ensures that protocol-level funds remain securely locked during the accumulation phase and cannot be accessed prematurely.

#### 3. Consensus Enforcement
- Clients MUST correctly redirect all BASEFEE amounts to the Treasury address during block finalization as defined in ECIP-1111.
- Any deviation from this rule SHALL cause a permanent consensus fork.
- The Treasury contract itself performs no consensus logic; it relies on client implementations to uphold the protocol rules strictly.

#### 4. Minimal Attack Surface
- The Treasury MUST NOT implement governance logic, proposal validation, metadata hashing, or voting semantics.
- Its design SHALL remain minimal and predictable, reducing potential vulnerabilities arising from complex logic.
- The contract SHOULD track only what is necessary to prevent duplicate withdrawals, if applicable.

#### 5. Deployment and Initialization Safety
- At deployment, the executor address MUST be set to a value that cannot satisfy the Treasury’s authorization checks until the designated governance executor is deployed under a separate ECIP.
- This ensures that all funds remain locked and inaccessible during the pre-governance accumulation period.

#### 6. Audit and Testing Requirements
- The Treasury contract SHALL undergo third-party security audits prior to mainnet deployment.
- Formal verification and static-analysis tools SHOULD be used to validate invariants such as:
- Correct access control
- Absence of upgrade paths
- Safe handling of Ether transfers
- Testnet deployments MUST confirm:
- Accurate BASEFEE accumulation
- Correct rejection of unauthorized withdrawal attempts
- Cross-client consistency under ECIP-1111 redirection

#### Security Considerations Summary

The Olympia Treasury provides a secure and immutable custody layer for protocol-level revenue. Its minimal design, strict access control, and reliance on consensus-layer enforcement ensure that funds are safely accumulated and remain inaccessible until governance becomes active under separate ECIPs.

### Related ECIPs in the Olympia Upgrade

ECIP-1112 is one of four coordinated proposals that together define the Olympia framework for protocol-level funding on Ethereum Classic.
- ECIP-1111 — Olympia EVM and Protocol Upgrades
 Activates EIP-1559 and EIP-3198 on Ethereum Classic and redirects the BASEFEE amount to the Treasury address defined in this ECIP.
- ECIP-1112 — Olympia Treasury Contract
 Defines the deterministic, immutable smart contract that receives and holds all redirected BASEFEE revenue in a governance-isolated vault.
- ECIP-1113 — Olympia DAO Governance Framework
 Specifies the governance architecture, including the authorized executor contract that is permitted to initiate Treasury withdrawals.
- ECIP-1114 — Ethereum Classic Funding Proposal Process
 Defines the standardized proposal format and lifecycle used by the governance system to authorize Treasury disbursements.

#### Interdependency Summary
- ECIP-1111 provides the protocol-level BASEFEE revenue source.
- ECIP-1112 defines the immutable contract that stores this revenue.
- ECIP-1113 establishes the governance executor permitted to withdraw funds.
- ECIP-1114 defines the proposal structure and lifecycle used by governance to authorize withdrawals.

These ECIPs are designed for modular activation:
- ECIP-1111 and ECIP-1112 MAY be activated first to begin revenue accumulation.
- ECIP-1113 and ECIP-1114 MAY be deployed later to enable controlled, on-chain authorization of Treasury withdrawals.

### Copyright

Copyright and related rights waived via
CC0

### Appendix: EVM Precedents for Treasury Design

Several EVM-based networks use deterministic, contract-based mechanisms for receiving protocol-level fees or revenue. These designs demonstrate established patterns for routing endogenous network value into transparent, on-chain custody locations that operate independently of execution or governance logic.

#### Treasury Design Precedents

| Network | Mechanism | Notes |
|-------------------|------------------------------------------------------|-----------------------------------------------------------------------|
| Ronin | Redirects EIP-1559 BASEFEE to a fixed contract | Demonstrates contract-based receipt of protocol-level fees |
| Celo | Gas fees sent to a contract-based fee handler | Illustrates transparent custody of on-chain revenue |
| Mantle | Sequencer revenue accumulated at a known contract | Shows deterministic contract endpoints for protocol-level inflows |
| Polygon CDK | Optional fee hooks directing value to contracts | Supports contract-level receipt of network fees in modular rollups |
| OP Stack | Sequencer revenue forwarded to fixed contract sinks | Example of predictable programmatic fee routing |
| Arbitrum | Sequencer fees accumulated at a contract address | Illustrates transparent on-chain fund accumulation |
| Optimism | Revenue routed to designated on-chain custody | Reinforces patterns for deterministic fee sinks |
| Avalanche Subnets | Transaction fees routed to subnet contracts | Demonstrates per-subnet contract-level custody |
| Gitcoin DAO | Uses contract-based treasuries for on-chain funds | Relevant for transparent custody rather than governance mechanics |

#### Design Principles Relevant to ECIP-1112
- Immutable Contract Custody
 Several networks use contracts with no upgrade mechanisms to provide predictable, tamper-resistant storage of protocol-level value.
- Deterministic Addresses
 Many systems deploy fee-receiving contracts at fixed or precomputed addresses to ensure consistent cross-client behavior.
- Automatic Revenue Routing
 Protocol-defined flows (e.g., BASEFEE, gas fees, sequencer revenue) are commonly forwarded directly into a contract without discretionary control.
- Transparent On-Chain Accounting
 Contract-based treasuries allow all inflows to be observed and audited directly on-chain.

ECIP-1112 adopts these proven design patterns by defining an immutable, deterministic Treasury contract that receives protocol-level BASEFEE revenue redirected under ECIP-1111, while leaving governance and allocation mechanics to separate ECIPs.

### Simple Summary

Enable the outstanding Ethereum Foundation Istanbul network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Phoenix to enable maximum compatibility across these networks.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Istanbul hardforks. The proposed changes for Ethereum Classic's Phoenix upgrade include:
- Add Blake2 compression function F precompile
- Reduce altbn128 precompile gas costs
- Add ChainID opcode
- Repricing for trie-size-dependent opcodes
- Calldata gas cost reduction
- Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

This document proposes the following blocks at which to implement these changes in the Classic networks:
- 999983 on Mordor Classic PoW-testnet (April, 2020)
- 2200013 on Kotti Classic PoA-testnet (April, 2020)
- 10500839 on Ethereum Classic PoW-mainnet (June, 2020)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since end of 2019.

### Specification

Technical specifications for each EIP can be found at those documents respectively:
- EIP-152: Add Blake2 compression function F precompile
- EIP-1108: Reduce altbn128 precompile gas costs
- EIP-1344: Add ChainID opcode
- EIP-1884: Repricing for trie-size-dependent opcodes
- EIP-2028: Calldata gas cost reduction
- EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

### Rationale

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Mordor,
Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Istanbul features currently and will be able to support the Phoenix upgrade:
- Core-Geth (maintained by ETC Core)
- Hyperledger Besu (maintained by PegaSys and ChainSafe)

The following clients with Ethereum Classic support also implement Phoenix but let the users choose whether to adapt the upgrade or not.
- Multi-Geth (maintained by the community)
- OpenEthereum (previously Parity Ethereum, maintained by Gnosis)

### Final Note

Both, the Geth Classic client and the Morden testnet will no longer be supported by the community and not recieve the Phoenix_ ugrades.
- Users of the Geth Classic client are urged to migrate their services to Core-Geth or Hyperledger Besu. It is no longer recommended to run Geth Classic in production.
- Users of the Morden Classic testnet are urged to migrate their applications to the Kotti Classic or Mordor Classic testnets.

## Copyright

Copyright and related rights waived via CC0.

### Simple Summary

This ECIP describes a hard-fork which would occur at the same mainnet block as
ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) to "fix" two issues with ECIP-1061 where the written specification
did not match the original intent.

### Abstract

The network participants who took part in the
ETC Core Developers call on 27th November 2019
were under the impression at the time that the scope we agreed ("Instanbul without the
backward-compatibility breaking parts of EIP-1884") - ECIP-1061 / ECIP-1072 - would move the ETC
protocol to a place where it was 100% compatible with the ETH mainnet.

Wei Tang's implementation of ECIP-1061 shortly afterwards revealed
two flaws in the specification, together with recommendations on how to address those shortcomings.

This ECIP codifies those recommendations.

Both hard-forks would be activated at the same block and the combination of both sets of changes
would result in protocol changes which met the original intent.

### Specification

This document proposes the following blocks at which to implement these changes in the Classic networks:
- ~~976231 on Mordor Classic PoW-testnet (approx March 4th, 2020)~~
- ~~2208203 on Kotti Classic PoA-testnet (approx March 11st, 2020)~~
- ~~10500839 on Ethereum Classic PoW-mainnet (approx June 10th, 2020)~~

At HARDFORKBLOCK, apply the following changes:
- Disable EIP-2200
- Enable EIP-1283 with EIP-1706 instead.
- Enable ECIP-1080

### Rationale

ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) as defined is "broken" and it would be inadvisable to activate on the ETC mainnet in
its current state.

See EIP 1884: Repricing for trie-size-dependent opcodes for
the original rationale for the gas-repricings for ETH.

These changes are sensible, but they broke 680 deployed Aragon smart contracts along with various other deployed
smart contacts by applying the repricings retroactively and unconditionally.

The new SELFBALANCE opcode does not break backwards compatibility. For compatibility with ETH it is both
necessary and desirable.

Short of imminent and catatrophic danger to the ETC network, making retroactive changes which break
backwards compatibility is counter to ETC values and philosophy.

Gas-repricings to balance EVM gas prices with real world resource usage is entirely rational and is
happening on the ETC protocol too, but will be done in a backwards-compatible ways wherever possible.
Unconditional retroactive ("emergency") repricings would only happen when the network has been halted
or has been rendered unusable.

An example of such a situation occurred following the Shanghai attacks on ETH and ETC networks:

ECIP 1015: Long-term gas cost changes for IO-heavy operations to mitigate transaction spam attacks, which has ETC's equivalent to ETH Tangerine Whistle,
with both chains implementing EIP 150: Gas cost changes for IO-heavy operations.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Istanbul_ features currently:
- Parity Ethereum
- Multi-Geth
- Hyperledger Besu

The author is unaware if any of these clients have implemented EIP-1706, but it is a very simple change, analogous to EIP-2200, which all the
codebases have already implemented.

Similarly ECIP-1080 has not been implemented in any of these codebases, but is just a "remix" of code which they have already implemented.

## Copyright

This proposal is licensed under the Apache License, Version 2.0,
based on specifications developed by Wei Tang within the Core Paper project (https://corepaper.org/).

Core Paper Copyright 2019-2020 Wei Tang.

Bob Summerwill, the author of this proposal attests that his is the sole author of this specific document
based on Wei Tang's work and that he is able to contribute this work to the ECIP process under the
Apache 2.0 licence. He further attests that he neither holds nor is aware of any patents, trademarks,
copyright issues or other IP hinderances associated with this work.

### NOTE

This ECIP was rendered unworkable when
ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition)
was activated to the Mordor testnet. It was no longer possible for the original Aztlán
hardfork to be Withdrawn and replaced with this ECIP.

The most likely path forward at the time of writing is for
ECIP 1078: Phoenix EVM and Protocol Upgrades ("Aztlán redo")
to be moved to Last Call and to have block numbers assigned and to proceed with activation on
Mordor and Kotti testnets slightly later than the Aztlán activation but activating on the same
block for ETC mainnet.

There will be a Core Devs Call: ECIP-1078 Phoenix Upgrade
on Wednesday, February 05, 2019, 4pm UTC, 60 minutes max to make the final decision on this.

### Simple Summary

This ECIP describes a hard-fork which would replace
ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) to "fix" two issues with ECIP-1061 where the written specification
did not match the original intent.

Enable the outstanding Ethereum Foundation Istanbul network protocol upgrades on the Ethereum
Classic network without any gas-cost assumptions in a hard-fork code-named Phoenix to enable
maximum compatibility across these networks.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the
Istanbul hardforks. The proposed changes for Ethereum Classic's Phoenix upgrade include:
- Add Blake2 compression function F precompile
- Reduce altbn128 precompile gas costs
- Add ChainID opcode
- Calldata gas cost reduction
- Net gas metering for SSTORE without dirty maps
- Addition of SELFBALANCE opcode

The network participants who took part in the
ETC Core Developers call on 27th November 2019
were under the impression at the time that the scope we agreed ("Instanbul without the
backward-compatibility breaking parts of EIP-1884") - ECIP-1061 / ECIP-1072 - would move the ETC
protocol to a place where it was 100% compatible with the ETH mainnet.

Wei Tang's implementation of ECIP-1061 shortly afterwards revealed
two flaws in the specification, together with recommendations on how to address those shortcomings.

This ECIP codifies those recommendations in the form
of a replacement hard-fork which would happen instead of
ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) on a timeline still TDB.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes shall be added to the Ethereum Classic
networks, all of which have been in use on the Ethereum Foundation networks since end of 2019.

### Specification

This document proposes the following blocks at which to implement these changes in the Classic networks:
- TBD on Mordor Classic PoW-testnet
- TBD Kotti Classic PoA-testnet
- TBD on Ethereum Classic PoW-mainnet

At HARDFORKBLOCK, apply the following changes.
- Enable EIP-152
- Enable EIP-1108
- Enable EIP-1344
- Enable EIP-2028
- Enable EIP-1283 with EIP-1706.
- Enable ECIP-1080

### Rationale

ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) as defined is "broken" and it would be inadvisable to activate on the ETC mainnet in
its current state.

See EIP 1884: Repricing for trie-size-dependent opcodes for
the original rationale for the gas-repricings for ETH.

These changes are sensible, but they broke 680 deployed Aragon smart contracts along with various other deployed
smart contacts by applying the repricings retroactively and unconditionally.

The new SELFBALANCE opcode does not break backwards compatibility. For compatibility with ETH it is both
necessary and desirable.

Short of imminent and catatrophic danger to the ETC network, making retroactive changes which break
backwards compatibility is counter to ETC values and philosophy.

Gas-repricings to balance EVM gas prices with real world resource usage is entirely rational and is
happening on the ETC protocol too, but will be done in a backwards-compatible ways wherever possible.
Unconditional retroactive ("emergency") repricings would only happen when the network has been halted
or has been rendered unusable.

An example of such a situation occurred following the Shanghai attacks on ETH and ETC networks:

ECIP 1015: Long-term gas cost changes for IO-heavy operations to mitigate transaction spam attacks, which has ETC's equivalent to ETH Tangerine Whistle,
with both chains implementing EIP 150: Gas cost changes for IO-heavy operations.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Istanbul_ features currently:
- Parity Ethereum
- Multi-Geth
- Hyperledger Besu

The author is unaware if any of these clients have implemented EIP-1706, but it is a very simple change, analogous to EIP-2200, which all the
codebases have already implemented.

Similarly ECIP-1080 has not been implemented in any of these codebases, but is just a "remix" of code which they have already implemented.

## Copyright

This proposal is licensed under the Apache License, Version 2.0,
based on specifications developed by Wei Tang within the Core Paper project (https://corepaper.org/).

Core Paper Copyright 2019-2020 Wei Tang.

Bob Summerwill, the author of this proposal attests that his is the sole author of this specific document
based on Wei Tang's work and that he is able to contribute this work to the ECIP process under the
Apache 2.0 licence. He further attests that he neither holds nor is aware of any patents, trademarks,
copyright issues or other IP hinderances associated with this work.

### Simple Summary

Enable the outstanding Ethereum Foundation Istanbul network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Phoenix to enable maximum compatibility across these networks.

This is the classic option equaling to an Istanbul option without gas repricing.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Istanbul hardforks. The proposed changes for Ethereum Classic's Phoenix upgrade include:
- Add Blake2 compression function F precompile
- Reduce altbn128 precompile gas costs
- Net gas metering for SSTORE without dirty maps
- Add ChainID opcode
- Disable SSTORE with gasleft lower than call stipend
- Calldata gas cost reduction
- Add SELFBALANCE opcode

This document proposes the following blocks at which to implement these changes in the Classic networks:
- 999983 on Mordor Classic PoW-testnet (April, 2020)
- 2200013 on Kotti Classic PoA-testnet (April, 2020)
- 10500839 on Ethereum Classic PoW-mainnet (June 10th, 2020)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since end of 2019.

### Specification

Technical specifications for each EIP can be found at those documents respectively:
- EIP-152: Add Blake2 compression function F precompile
- EIP-1108: Reduce altbn128 precompile gas costs
- EIP-1283: Net gas metering for SSTORE without dirty maps
- EIP-1344: Add ChainID opcode
- EIP-1706: Disable SSTORE with gasleft lower than call stipend
- EIP-2028: Calldata gas cost reduction
- ECIP-1080: Add SELFBALANCE opcode

### Rationale

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Mordor,
Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Istanbul features currently and would be able to support the Phoenix upgrade:
- Hyperledger Besu
- Core-Geth
- Multi-Geth
- Parity Ethereum

### Final Note

Both, the Geth Classic client and the Morden testnet will no longer be supported by the community and not recieve the Phoenix_ ugrades.
- Users of the Geth Classic client are urged to migrate their services to Parity Ethereum, Multi-Geth, or Hyperledger Besu. It is no longer recommended to run Geth Classic in production.
- Users of the Morden Classic testnet are urged to migrate their applications to the Kotti Classic or Morder Classic testnets.

## Copyright

Copyright and related rights waived via CC0.

# ECIP 1046 - Precompiled contract for Merkle Inclusion Proofs

## Abstract

Verification of Merkle Inclusion Proofs is obviously possible in EVM bytecode.
However, the gas cost for such an operation is very high.

We propose adding this functionality to Ethereum Classic as a precompiled
contract in order to combat this cost.

## Motivation

Interoperability is a very important goal for Ethereum Classic. We believe that
having a way to efficiently tell whether a transaction is included in a
Bitcoin/Bitcoin Cash block by utilizing only the block's Merkle Tree Root and a
short proof is a great first step in that direction.

Moreover, new efficient constructions which enable cross-chain asset transfers
like NIPoPoWs heavily rely on Merkle Inclusion Proofs.

## Specification

If block.number >= MERKLEFORKBLKNUM, add a precompiled contract for Merkle
Inclusion Proofs (MERKLEVERIFY).

The proposal adds a new precompiled function MERKLEVERIFY with the following input and output.

MERKLEVERIFY takes as input at least 72 bytes:
1. root hash: the 256-bit merkle tree root hash
2. leaf: the 256-bit leaf we want to prove is included in the merkle tree
3. leaf index: the 64-bit index of the leaf
4. siblings: an array of 256-bit values, arranged from the leaves to the root

MERKLEVERIFY returns as output 4 bytes:
- 0x00000000 if the proof is valid
- any non-zero value indicates an invalid proof

### Address

The address of MERKLEVERIFY is 0x9.

### Gas costs

Gas cost for MERKLEVERIFY is ????.

## Implementation

The hash function used is SHA256(SHA256(_)), to be compatible with Bitcoin/Bitcoin Cash.

The merkle tree construction assumed is described in detail in the Bitcoin
Developer Reference.

Here follows an example implementation of the verification in Solidity:

## References
- NIPoPoWs
- Original Solidity implementation
- Bitcoin Developer Reference

## Motivation

Precompiled contracts for elliptic curve and pairing operations are required in order to perform zkSNARK verification within the block gas limit.

## Abstract

zkSNARK verification will allow anonymous transaction to be executed on the Ethereum Classic network. See this for how a simple mixer contract can be implemented using zkSNARK verification. This ECIP implements three primitive operations in order to perform zkSNARK verification. This allows changes of zkSNARK algorithms without requiring another hard fork.

The general benefit of zkSNARKs for Ethereum and Ethereum Classic is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property).

This combines EIP-212 and EIP-213.

## Specification for Addition and Scalar Multiplication on the Elliptic Curve altbn128

Add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "altbn128".

Address of ADD: 0x6
Address for MUL: 0x7

The curve is defined by:

### Encoding

Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements (x, y), where the point at infinity is encoded as (0, 0).

Tuples of objects are encoded as their concatenation.

For both precompiled contracts, if the input is shorter than expected, it is assumed to be virtually padded with zeros at the end (i.e. compatible with the semantics of the CALLDATALOAD opcode). If the input is longer than expected, surplus bytes at the end are ignored.

The length of the returned data is always as specified (i.e. it is not "unpadded").

### Exact semantics

Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates) is equal or larger than the field modulus p, the contract fails. The scalar can be any number between 0 and 2*256-1.

#### ADD
Input: two curve points (x, y).
Output: curve point x + y, where + is point addition on the elliptic curve altbn128 specified above.
Fails on invalid input and consumes all gas provided.

#### MUL
Input: curve point and scalar (x, s).
Output: curve point s x, where is the scalar multiplication on the elliptic curve altbn128 specified above.
Fails on invalid input and consumes all gas.

### Gas costs

To be determined.

### Specification for Optimal Ate Pairing Check on the Elliptic Curve altbn128

Add a precompiled contracts for a bilinear function on groups on the elliptic curve "altbn128". We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below.

Address: 0x8

For a cyclic group G (written additively) of prime order q let logP: G -> Fq be the discrete logarithm on this group with respect to a generator P, i.e. logP(x) is the integer n such that n P = x.

The precompiled contract is defined as follows, where the two groups G1 and G2 and their generators P1 and P2 are defined below (they have the same order q):

Note that k is determined from the length of the input. k == 0 is valid and results in returning one.

In order to check that an input is an element of G1, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For G2, in addition to that, the order of the element has to be checked to be equal to the group order q = 21888242871839275222246405745257275088548364400416034343698204186575808495617.

### Definition of the groups

The groups G1 and G2 are cyclic groups of prime order q = 21888242871839275222246405745257275088548364400416034343698204186575808495617 on the elliptic curve altbn128 defined by the curve equation
Y^2 = X^3 + 3.

The group G1 is a cyclic group on the above curve over the field Fp with p = 21888242871839275222246405745257275088696311157297823662689037894645226208583 with generator P1 = (1, 2).

The group G2 is a cyclic group on the same elliptic curve over a different field Fp^2 = Fp[i] / (i^2 + 1) (p is the same as above) with generator

### Encoding

Elements of Fp are encoded as 32 byte big-endian numbers. An encoding value of p or larger is invalid.

Elements a i + b of Fp^2 are encoded as two elements of Fp, (a, b).

Elliptic curve points are encoded as a Jacobian pair (X, Y) where the point at infinity is encoded as (0, 0).

Note that the number k is derived from the input length.

The length of the returned data is always exactly 32 bytes and encoded as a 32 byte big-endian number.

### Gas costs

Benchmarks run on cpp-ethereum

suggest the following gas formula:

60000 k + 40000

if we target 20000 gas per millisecond.

Awaiting benchmarks from other implementations.

## Rationale

The specific curve altbn128 was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts.

The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification: The gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve.

A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).

## Backwards Compatibility

As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256.

## Implementation

### Optional Ate Pairing Check

The precompiled contract can be implemented using elliptic curve pairing functions, more specifically, an optimal ate pairing on the altbn128 curve, which can be implemented efficiently. In order to see that, first note that a pairing function e: G1 x G2 -> GT fulfills the following properties (G1 and G2 are written additively, GT is written multiplicatively):

(1) e(m P1, n P2) = e(P1, P2)^(m n)
(2) e is non-degenerate

Now observe that

if and only if

Furthermore, the left hand side of this equation is equal to

And thus, the precompiled contract can be implemented by verifying that
e(a1, b1) ... * e(ak, bk) = e(P1, P2)

## Simple Summary

NOTE: This ECIP is in direct reference to EIP-1057 written by IfDefElse (ifdefelse@protonmail.com) for Ethereum EIPs. It has been licensed as an ECIP submission under Apache 2.0.

A new Proof-of-Work algorithm to replace Ethash that utilizes almost all parts of commodity GPUs.

## Abstract

ProgPoW is a proof-of-work algorithm designed to close the efficiency gap available to specialized ASICs. It utilizes almost all parts of commodity hardware (GPUs), and comes pre-tuned for the most common hardware utilized in the Ethereum network.

## Motivation

Ever since the first bitcoin mining ASIC was released, many new Proof of Work algorithms have been created with the intention of being “ASIC-resistant”. The goal of “ASIC-resistance” is to resist the centralization of PoW mining power such that these coins couldn’t be so easily manipulated by a few players.

This document presents an overview of the algorithm and examines what it means to be “ASIC-resistant.” Next, we compare existing PoW designs by analyzing how each algorithm executes in hardware. Finally, we present the detailed implementation by walking through the code.

### ProgPoW Overview
The design goal of ProgPoW is to have the algorithm’s requirements match what is available on commodity GPUs: If the algorithm were to be implemented on a custom ASIC there should be little opportunity for efficiency gains compared to a commodity GPU.

The main elements of the algorithm are:
- Changes keccakf1600 (with 64-bit words) to keccakf800 (with 32-bit words) to reduce impact on total power
- Increases mix state.
- Adds a random sequence of math in the main loop.
- Adds reads from a small, low-latency cache that supports random addresses.
- Increases the DRAM read from 128 bytes to 256 bytes.

The random sequence changes every PROGPOWPERIOD (about 2 to 12 minutes depending on the configured value). When mining source code is generated for the random sequence and compiled on the host CPU. The GPU will execute the compiled code where what math to perform and what mix state to use are already resolved.

While a custom ASIC to implement this algorithm is still possible, the efficiency gains available are minimal. The majority of a commodity GPU is required to support the above elements. The only optimizations available are:
- Remove the graphics pipeline (displays, geometry engines, texturing, etc)
- Remove floating point math
- A few ISA tweaks, like instructions that exactly match the merge() function

These would result in minimal, roughly 1.1-1.2x, efficiency gains. This is much less than the 2x for Ethash or 50x for Cryptonight.

### Rationale for PoW on Commodity Hardware
With the growth of large mining pools, the control of hashing power has been delegated to the top few pools to provide a steadier economic return for small miners. While some have made the argument that large centralized pools defeats the purpose of “ASIC resistance,” it’s important to note that ASIC based coins are even more centralized for several reasons.
1. No natural distribution: There isn’t an economic purpose for ultra-specialized hardware outside of mining and thus no reason for most people to have it.
2. No reserve group: Thus, there’s no reserve pool of hardware or reserve pool of interested parties to jump in when coin price is volatile and attractive for manipulation.
3. High barrier to entry: Initial miners are those rich enough to invest capital and ecological resources on the unknown experiment a new coin may be. Thus, initial coin distribution through mining will be very limited causing centralized economic bias.
4. Delegated centralization vs implementation centralization: While pool centralization is delegated, hardware monoculture is not: only the limiter buyers of this hardware can participate so there isn’t even the possibility of divesting control on short notice.
5. No obvious decentralization of control even with decentralized mining: Once large custom ASIC makers get into the game, designing back-doored hardware is trivial. ASIC makers have no incentive to be transparent or fair in market participation.

While the goal of “ASIC resistance” is valuable, the entire concept of “ASIC resistance” is a bit of a fallacy. CPUs and GPUs are themselves ASICs. Any algorithm that can run on a commodity ASIC (a CPU or GPU) by definition can have a customized ASIC created for it with slightly less functionality. Some algorithms are intentionally made to be “ASIC friendly” - where an ASIC implementation is drastically more efficient than the same algorithm running on general purpose hardware. The protection that this offers when the coin is unknown also makes it an attractive target for a dedicate mining ASIC company as soon as it becomes useful.

Therefore, ASIC resistance is: the efficiency difference of specialized hardware versus hardware that has a wider adoption and applicability. A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms. Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated. If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack.

### Review of Existing PoW Algorithms

#### SHA256
- Potential ASIC efficiency gain ~ 1000X

The SHA algorithm is a sequence of simple math operations - additions, logical ops, and rotates.

To process a single op on a CPU or GPU requires fetching and decoding an instruction, reading data from a register file, executing the instruction, and then writing the result back to a register file. This takes significant time and power.

A single op implemented in an ASIC takes a handful of transistors and wires. This means every individual op takes negligible power, area, or time. A hashing core is built by laying out the sequence of required ops.

The hashing core can execute the required sequence of ops in much less time, and using less power or area, than doing the same sequence on a CPU or GPU. A bitcoin ASIC consists of a number of identical hashing cores and some minimal off-chip communication.

#### Scrypt and NeoScrypt
- Potential ASIC efficiency gain ~ 1000X

Scrypt and NeoScrypt are similar to SHA in the arithmetic and bitwise operations used. Unfortunately, popular coins such as Litecoin only use a scratchpad size between 32kb and 128kb for their PoW mining algorithm. This scratch pad is small enough to trivially fit on an ASIC next to the math core. The implementation of the math core would be very similar to SHA, with similar efficiency gains.

#### X11 and X16R
- Potential ASIC efficiency gain ~ 1000X

X11 (and similar X##) require an ASIC that has 11 unique hashing cores pipelined in a fixed sequence. Each individual hashing core would have similar efficiency to an individual SHA core, so the overall design will have the same efficiency gains.

X16R requires the multiple hashing cores to interact through a simple sequencing state machine. Each individual core will have similar efficiency gains and the sequencing logic will take minimal power, area, or time.

The Baikal BK-X is an existing ASIC with multiple hashing cores and a programmable sequencer. It has been upgraded to enable new algorithms that sequence the hashes in different orders.

#### Equihash
- Potential ASIC efficiency gain ~ 100X

The ~150mb of state is large but possible on an ASIC. The binning, sorting, and comparing of bit strings could be implemented on an ASIC at extremely high speed.

#### Cuckoo Cycle
- Potential ASIC efficiency gain ~ 100X

The amount of state required on-chip is not clear as there are Time/Memory Tradeoff attacks. A specialized graph traversal core would have similar efficiency gains to a SHA compute core.

#### CryptoNight
- Potential ASIC efficiency gain ~ 50X

Compared to Scrypt, CryptoNight does much less compute and requires a full 2mb of scratch pad (there is no known Time/Memory Tradeoff attack). The large scratch pad will dominate the ASIC implementation and limit the number of hashing cores, limiting the absolute performance of the ASIC. An ASIC will consist almost entirely of just on-die SRAM.

#### Ethash
- Potential ASIC efficiency gain ~ 2X

Ethash requires external memory due to the large size of the DAG. However that is all that it requires - there is minimal compute that is done on the result loaded from memory. As a result a custom ASIC could remove most of the complexity, and power, of a GPU and be just a memory interface connected to a small compute engine.

## Specification

The DAG is generated exactly as in Ethash. All the parameters (ephoch length, DAG size, etc) are unchanged. See the original Ethash spec for details on generating the DAG.

ProgPoW can be tuned using the following parameters. The proposed settings have been tuned for a range of existing, commodity GPUs:
- PROGPOWPERIOD: Number of blocks before changing the random program
- PROGPOWLANES: The number of parallel lanes that coordinate to calculate a single hash instance
- PROGPOWREGS: The register file usage size
- PROGPOWDAGLOADS: Number of uint32 loads from the DAG per lane
- PROGPOWCACHEBYTES: The size of the cache
- PROGPOWCNTDAG: The number of DAG accesses, defined as the outer loop of the algorithm (64 is the same as ethash)
- PROGPOWCNTCACHE: The number of cache accesses per loop
- PROGPOWCNTMATH: The number of math operations per loop

The value of these parameters has been tweaked between version 0.9.2 (live on the gangnum testnet) and 0.9.3 (proposed for Ethereum adoption). See this medium post for details.

| Parameter | 0.9.2 | 0.9.3 |
|-----------------------|-----------|-----------|
| PROGPOWPERIOD | 50 | 10 |
| PROGPOWLANES | 16 | 16 |
| PROGPOWREGS | 32 | 32 |
| PROGPOWDAGLOADS | 4 | 4 |
| PROGPOWCACHEBYTES | 16x1024 | 16x1024 |
| PROGPOWCNTDAG | 64 | 64 |
| PROGPOWCNTCACHE | 12 | 11 |
| PROGPOWCNTMATH | 20 | 18 |

The random program changes every PROGPOWPERIOD blocks to ensure the hardware executing the algorithm is fully programmable. If the program only changed every DAG epoch (roughly 5 days) certain miners could have time to develop hand-optimized versions of the random sequence, giving them an undue advantage.

Sample code is written in C++, this should be kept in mind when evaluating the code in the specification.

All numerics are computed using unsigned 32 bit integers. Any overflows are trimmed off before proceeding to the next computation. Languages that use numerics not fixed to bit lengths (such as Python and JavaScript) or that only use signed integers (such as Java) will need to keep their languages' quirks in mind. The extensive use of 32 bit data values aligns with modern GPUs internal data architectures.

ProgPoW uses a 32-bit variant of FNV1a for merging data. The existing Ethash uses a similar variant of FNV1 for merging, but FNV1a provides better distribution properties.

Test vectors can be found in the test vectors file.

ProgPow uses KISS99) for random number generation. This is the simplest (fewest instruction) random generator that passes the TestU01 statistical test suite. A more complex random number generator like Mersenne Twister can be efficiently implemented on a specialized ASIC, providing an opportunity for efficiency gains.

Test vectors can be found in the test vectors file.

The fillmix function populates an array of int32 values used by each lane in the hash calculations.

Test vectors can be found in the test vectors file.

Like Ethash Keccak is used to seed the sequence per-nonce and to produce the final result. The keccak-f800 variant is used as the 32-bit word size matches the native word size of modern GPUs. The implementation is a variant of SHAKE with width=800, bitrate=576, capacity=224, output=256, and no padding. The result of keccak is treated as a 256-bit big-endian number - that is result byte 0 is the MSB of the value.

As with Ethash the input and output of the keccak function are fixed and relatively small. This means only a single "absorb" and "squeeze" phase are required. For a pseudo-code imenentation of the keccakf800round function see the Roundb function in the "Pseudo-code description of the permutations" section of the official Keccak specs.

Test vectors can be found in the test vectors file.

The inner loop uses FNV and KISS99 to generate a random sequence from the progseed. This random sequence determines which mix state is accessed and what random math is performed.

Since the progseed changes only once per PROGPOWPERIOD it is expected that while mining progPowLoop will be evaluated on the CPU to generate source code for that period's sequence. The source code will be compiled on the CPU before running on the GPU.

Test vectors can be found in the test vectors file.

The math operations that merges values into the mix data are ones chosen to maintain entropy.

Test vectors can be found in the test vectors file.

The math operations chosen for the random math are ones that are easy to implement in CUDA and OpenCL, the two main programming languages for commodity GPUs. The mulhi, min, clz, and popcount functions match the corresponding OpenCL functions. ROTL32 matches the OpenCL rotate function. ROTR32 is rotate right, which is equivalent to rotate(i, 32-v).

Test vectors can be found in the test vectors file.

The flow of the inner loop is:
- Lane (loop % LANES) is chosen as the leader for that loop iteration
- The leader's mix[0] value modulo the number of 256-byte DAG entries is is used to select where to read from the full DAG
- Each lane reads DAGLOADS sequential words, using (lane ^ loop) % LANES as the starting offset within the entry.
- The random sequence of math and cache accesses is performed
- The DAG data read at the start of the loop is merged at the end of the loop

progseed and loop come from the outer loop, corresponding to the current program seed (which is blocknumber/PROGPOWPERIOD) and the loop iteration number. mix is the state array, initially filled by fillmix. dag is the bytes of the Ethash DAG grouped into 32 bit unsigned ints in litte-endian format. On little-endian architectures this is just a normal int32 pointer to the existing DAG.

DAGBYTES is set to the number of bytes in the current DAG, which is generated identically to the existing Ethash algorithm.

Test vectors can be found in the test vectors file.

The flow of the overall algorithm is:
- A keccak hash of the header + nonce to create a seed
- Use the seed to generate initial mix data
- Loop multiple times, each time hashing random loads and random math into the mix data
- Hash all the mix data into a single 256-bit value
- A final keccak hash is computed
- When mining this final value is compared against a hash32t target

## Rationale

ProgPoW utilizes almost all parts of a commodity GPU, excluding:
- The graphics pipeline (displays, geometry engines, texturing, etc);
- Floating point math.

Making use of either of these would have significant portability issues between commodity hardware vendors, and across programming languages.

Since the GPU is almost fully utilized, there’s little opportunity for specialized ASICs to gain efficiency. Removing both the graphics pipeline and floating point math could provide up to 1.2x gains in efficiency, compared to the 2x gains possible in Ethash, and 50x gains possible for CryptoNight.

## Backwards Compatibility

This algorithm is not backwards compatible with the existing Ethash, and will require a fork for adoption. Furthermore, the network hashrate will halve since twice as much memory is loaded per hash.

## Test Cases

### progpow 0.9.2
The algorithm run on block 30,000 produces the following digest and result:

Additional test vectors can be found in the test vectors file.
### progpow 0.9.3
Machine-readable test vectors

## Implementation

The reference ProgPoW mining implementation located at ProgPOW is a derivative of ethminer so retains the GPL license.
## License and Copyright

The ProgPoW algorithm and this specification are a new work. Copyright and related rights are waived via CC0.

The reference ProgPoW mining implementation located at ProgPOW is a derivative of ethminer so retains the GPL license.

### Abstract

This document outlines a proposal for the implementation of a proto-treasury system in Ethereum Classic. It describes the high-level structure of the proto-Ethereum Classic Treasury System (p-ECTS), and its general properties. Detailed specifications for each part of the system, as well as reference implementation, can be found in the GitHub repository.

### Motivation

The primary motives of the p-ECTS is to establish a stable and reliable funding mechanism for independent teams, each of whom are capable of both maintaining core clients and evolving the development of the Ethereum Classic platform, as well as initiating the funding of a Gitcoin grants pool for wider community development.

The current approach of relying on voluntarism and benefactors to support the ETC eco-system has failed. A clear signal needs to be sent to the wider community that ETC means to move forward with confidence with a clear vision to deliver a stable stream of funding that encourages developer engagement.

To realise this ambitious vision, innovation must be encouraged and the ETC network must be consistently maintained and continuously improved. Blockchain protocols are highly complex distributed systems that are proven to be expensive to research, develop, and implement while operating within an increasingly competitive developer market. ETC needs to position itself as a desirable platform for innovation where developers want to invest their time making improvements and building new applications.

ETC can gain significant competitive advantage in the medium and long-term outlook by delivering a stable, decentralized and community-driven funding system for protocol development that is backed by a clear technical roadmap. To achieve this goal, stable and reliable funding is required, under the transparent and verifiable control of the Ethereum Classic community, through the ECIP process. With full transparency, proposals can be thoroughly questioned and rigorously examined by fellow community members, with community members themselves making collective funding decisions.

ETC needs a vision to inspire developers - particularly those currently outside the ETC ecosystem, to build on the platform, ahead of the many other well-funded competitor platforms in the space. This treasury system is designed to do this quickly and efficiently and having a high value ETC will also mitigate against potential 51% attacks.

We recognize this proposal outlines a significant change to the future governance of ETC. For this reason, we are proposing an element of built in obsolescence so the community has the opportunity to directly assess the value of the treasury system and in time, actively vote for its continuation and further development or indeed to allow it to be reversed.

This proposal is not designed to deliver an end-state system, but a stepping stone solution on the path to the launch of a fully decentralized treasury system.

### Specification

#### Solution Overview and Rationale

This proposal opts for the most simple solution for the p-ECTS to encourage collaboration and transparency for this first-step treasury system.

This specification represents the p-ECTS only, and a best-in-class treasury and governance model, such as outlined in [[1]](https://eprint.iacr.org/2018/435.pdf
), can be proposed by the community via the ECIP mechanism in the future.

We would also put forward that this treasury system would go through a formal verification process to ensure that it behaves as per the final specification.

#### Parameters

| Name | Description | Proposed value |
|---|---|---|
|FORKBLKNUM|Block on which the Hard Fork will take place.|TBD|
|Initial client members addresses|Collections of all MemberType.Client.|TBD|
|gitcoinAddress|Gitcoin grant address.|TBD|
|treasuryBlockReward|Amount of ETC received by the treasury.|20% portion of the block reward|
|gitcoinRewardPerc|Percentage of reward that the MemberType.Gitcoin will receive.|10%|
|proposalMinDeposit| Minimum amount of ETC required to submit a proposal.|100 ETC|
|proposalDebatePeriod| Amount of time the proposal can be voted on.|30 days|
|proposalPreSupportPeriod| Amount of time before the proposal voting deadline, on which the presupportflag can be evaluated.|2 days|
|proposalMinQuorum| Minimum amount of ETC required to have participated in voting for a proposal (either yes/no) to be considered applicable. | 1/3 of total ETC supply ()|
|proposalMajorityPerc| Percentage of majority (yes over no votes) required for any proposal to be passed.|60%|
|lockedWaitingTime| Time since funds are locked until they can be used for proposal voting.|1 day|
|shutdownGracePeriod| Period of time after a shutdown proposal has been approved, where proposals can no longer be submitted, but funds can be recovered.|7 days|

() Obtaining the exact total supply from a smart contract is not easy, and we'll probably need to make some estimations, like taking the average of a lower and upper bound.

#### Data Dictionary
- Member: Entity that will receive funding, identified by an address.
- MemberType:
- Client
- Gitcoin
- N: number of active MemberType.Client to receive funding on a given time.

#### Protocol changes: Treasury Fund

Currently, when a block is successfully mined on the Ethereum Classic blockchain, the miner receives 3.2 ETC as a block reward. For now, all rewards and fees are taken by the miners who have produced the blocks; it is possible to take a portion of the reward to fund the treasury. This change proposes that the block reward is adjusted so that:
- 80% of the block reward goes to the miners
- 20% goes to the p-ECTS smart contract address or the burn address (0x0)

(note: transaction fees will not be included in the treasury fund)

The miner will be able to choose whether they want to send the 20% to the defined address, or burn the funds completely.

In the special case where the treasury contracts have been shut off, the miner will reclaim the 20% and receive the full block reward.

The funds allocation for the treasury contract, or the burn address, will be allocated in the same way as the coinbase funds. That is, with direct intervention on the balance of those accounts.

#### Funds distribution

Treasury funds will be held in escrow in the p-ECTS smart contract. Capability to withdraw from the p-ECTS will be limited to the contract members, initially three MemberType.Client for the core ETC development teams and a single MemberType.Gitcoin Gitcoin grant.

Funds will be distributed as follows:

Note that if the division by N might has some leftover dust, it will be "collected" by future distributions._

So, for example for the initial proposed state, on which we have three client members, the distribution will be:
- Gitcoin grant: 10%
- Client Member 1: 30%
- Client Member 2: 30%
- Client Member 3: 30%

Note that as the funds are allocated directly on the treasury contract address, a transaction will be needed to actually distribute ( distributeFunds()) them and make them available for withdrawal to each of the members, then each one will need an extra call to do so ( withdrawFunds()).
As distributeFunds considers the state of the contract at that moment, it’s important that any method that alters this state, first executes it.

#### Governance of p-ECTS

##### Proposal and voting mechanics

Governance participation is open to all ETC holders who can vote on any proposed changes to the p-ECTS.

Votes will be counted as total locked ETC that has participated (voted yes/no) on each proposal.

Anyone can submit a new proposal to update the p-ECTS, but they need to include a minimum amount of funds (proposalMinDeposit), those funds will be locked until the proposal ends (not active) and will be counted as yes votes.

A similar lockdown mechanism applies for the voting, the voter will need to lock their funds for lockedWaitingTime until they're eligible and they can cast any vote with them. If the same user wants to register more funds with the same address, all their previous funds will be locked for the new lockedWaitingTime period as well.

Participants will be able to unlock these funds and take them back, as long as they are not currently being used as votes on another proposal in progress.

Participants can use the same eligible stake for voting simultaneously on any proposals under consideration.

Participants can change their vote at any time during the proposal period, but all their funds will be taken into account and they will all need to be unlocked. For example, if I vote yes with 10ETC, then lock an extra 5ETC, wait the lockedWaitingTime and now re-vote as no, this will count as a 15ETC no vote.

Participants, with the exception of the proposal submitter, can also deregister votes, and the same locking funds restrictions apply. For example, if I vote yes with 10ETC, then lock an extra 5ETC, wait the lockedWaitingTime and now deregister my votes, naturally, only my 10ETC yes vote will be revoked. The funds however, will remain blocked for withdrawal until the proposal finished.

A proposal lifecycle for updates to p-ECTS consists of the following phases, delimited with certain events:
- Proposal creation event: The proposal gets created, its author's stake is registered as a yes vote and it immediately enters the voting phase.
- Voting phase: Since creation, and up to proposalCreationTime + proposalDebatePeriod; the proposal can register new votes, change votes or unvote.
- Proposal pre-support event: proposalPreSupportPeriod before the proposal's voting deadline, the preSupport flag can be evaluated. If a majority has voted yes and there is enough quorum, this flag will be activated, which is a pre-condition for the proposal to pass. (See: Ambush attacks prevention Section)
- Proposal voting deadline event: After proposalCreationTime + proposalDebatePeriod, the proposal no longer accepts votes, meaning that the proposal outcome is settled at this moment.
- Proposal execution phase: After the deadline event, if the proposal gets approved, it's publicly available to be executed, making the change effective immediately.

##### Proposal approval criteria
- The Treasury cannot be in shutdown state.
- It needs to be active (have not been executed before) and have completed the proposalDebatePeriod.
- It needs to have the pre-support flag on.
- It needs to have reached minimum quorum. Meaning that the sum of all yes and no votes has to be equal, or bigger than proposalMinQuorum at closing time.
- It needs to have majority consensus, meaning that amount of yes votes, over no votes, needs to be equal or bigger than proposalMajorityPerc.

##### Members add & remove

Through the proposal mechanism, the community has the power to remove a member from the p-ECTS. It can be both a MemberType.Client or MemberType.Gitcoin.

The community also has the power to add members to the p-ECTS. Only MemberType.Client can be added. There is no limit to the number of clients.

##### Members address update

Through the proposal mechanism, the community has the power to update a member address from the p-ECTS. It can be both a MemberType.Client or MemberType.Gitcoin.
The fundamental difference with remove/add is that in this case, the accumulated funds for this member remain available for them to withdraw, using this updated address.
This is particularly useful if a member loses their private keys or their keys become compromised.
It applies for all MemberTypes.

Please also review the Notes section on this topic.

##### Treasury shutdown

Through the proposal mechanism, the community has the power to shut down the p-ECTS, and from that point forward the full block reward will revert to the miners.

The shutdown is carried out in two steps. First, the proposal execution sets the shutdownScheduledAt time and the shutdownGracePeriod starts. During this time, no new proposal can be submitted, nor votes cast. Also, all the funds are unblocked and available to be withdrawn.
Secondly, after shutdownGracePeriod, the actual shutdown method is enabled and the contract can be effectively self destructed. The operation is irreversible, and whatever funds are left in it, become "burned".

#### Interface

#### Notes and considerations

##### Client account maintenance

In the event that a client funding account has been lost or compromised, we had incorporated a proposal type (ProposalType.UpdateClientAddress) to make the change, but going through the proposal process to make such a update might be overkill and there is no need to involve the whole community in something that is solely the client's responsibility.

We suggest an alternative mechanism to cover this, in which each client would have two different sets of keys; one spending key that would allow them to manage their funds and acts as a hot wallet and a second one that can act as a revocation key/certificate. This second key doesn't necessarily have to be an ETC account but could follow another standard (such as PGP for example).
This would facilitate the client in making a more frequent rotation of their spending keys in a secure way.

##### Ambush attacks prevention

Ambush attack: "Surprise" that a huge approval is given to a proposal at the last minute. A proposal that seems to be going towards a "No" outcome, suddenly receives a big amount of yes votes and the result is flipped at the last minute.

Prevention: Successful proposals require early pre-support, which already raises warnings that this approval might go through, so anyone that wants to counteract, can intervene during this period.

##### No version/upgradeability rationale

Adhering to the ECIP's rationale on keeping the solution simple and with the immutability principles of ETC, we chose to model the governance protocol as a fixed set of pre-defined operations.
Other models, that allow proxy-like structures on which the logic can be upgraded ( like OpenZeppelinProxies) are much more versatile, but they add more complexity and it's evolution is impossible to predict.

##### Treasury fixed reward

In the p-ECTS, the 20% reward that goes into the treasury is fixed, meaning that changing this allocated reward percentage would require a new hard fork.

We evaluated allowing the treasury governance to have the possibility of updating this reward allocation. For example, allowing the treasury smart contract to give back some portion to the miner or allowing the miners to dynamically "read" from the contract state the percentage they need to send.

However, this feature presents a technical challenge that we think exceeds its benefits, and we propose that such an important network parameter needs to be changed via a hard fork.

We have decided not to include this functionality. As this ECIP is open for input from the ETC Community, this decision can be discussed further to guage if there is broad support for this approach.

##### Even distribution for clients

Even if the initial distribution (10% & 3x30%) can be settled in the beginning, it can be argued that it's too rigid whilst adding/removing new members. Again, keeping things simple was the cornerstone of this proposal but we might want to consider the ability to include new distribution schemas, either as a new proposal type and/or on the adding/removing operation itself.
On the other hand, agreeing on what percentages go to each member could be a difficult decision and could lead to unnecessary unrest in the community. The even distribution, although being a rather blunt instrument, seems easier to accept.

##### Shutdown selfdestruction rationale

As the consensus layer needs to know when the treasury has been shut-off (so that miners can take their 20% back), we think it's convenient to utilize the self-destruct feature [3]. It's an effective mechanism to "state" that a contract is not longer valid, and it's easy to validate this condition at the consensus layer.

##### No Members left

The contract would allow for a situation in which all members get removed, and if some miners keep sending the treasury reward instead of burning it, the contract will accumulate all the funds - if someone executes the distribute method under these circumstances, the funds won't be affected.

When a new client member is added, he will be able to reclaim all the funds.
We think this is the correct behavior understanding that the treasury funds are above any client or executor, but we don't expect either an empty, or single member, situation should happen.
The gitcoin member is fundamentally different, as they're an external partner, so removing them will result in re-assigning their current and future funds to the treasury's reserves.

##### No Proposal pruning

To keep things simple, we exclude any pruning possibility, especially on the proposal structure where gas efficiency could be improved.

### Assumptions

The following assumptions apply to this proposal:
- Each p-ECTS member should ensure transparency by producing weekly and monthly development reports and meeting regularly to coordinate development efforts.
- All smart contracts will go through one or more professional security audits before deployment.
- After deployment, independent parties will need to verify that the deployed contract corresponds exactly to the audited version. All ETC clients will include this in their actual hard fork proposal.
- Supply changes will require a hard fork.
- Gitcoin grant [2] has ETC integrations and allows an active account to periodically receive funds.
- The treasury system should have an open, user-friendly UI to support community participation and engagement.

### Reference Implementation

A basic prototype implementation is included to illustrate the mechanics of the treasury smart contract.
It is not production code and it's only intention at this point is to be a playground for experimentation and a driver for discussion.

You can find it here: ETC Treasury System

### References

[1] https://iohk.io/en/research/library/papers/a-treasury-system-for-cryptocurrenciesenabling-better-collaborative-intelligence/

[2] https://gitcoin.co/grants/

[3] https://solidity.readthedocs.io/en/v0.6.12/introduction-to-smart-contracts.html#deactivate-and-self-destruct

## Abstract

All Ethereum-based chains face a major issue where blockchain bloat has the potential to drastically increase sync times and make it difficult to impossible for users to fully validate their copy of the ETC blockchain.

To mitigate this issue, this ECIP is a request that miners target a gas limit of 1 million which is an 8x reduction from the current limit of ~7.95 million; and well above the average gas size of blocks on the ETC blockchain.

## Motivation

Over the past year the ETH blockchain has grown substantially in verification time from less than 1 day in June 2017 to 4+ days in October 2018 and growing; even with considerably powered hardware and recent client optimizations. With maximum gas usage it's reasonable to expect that sync times over the next few years will grow to the point where a normal users and even some businesses cannot fully validate the chain, leading to node centralization and the need for trusted intermediaries.

We have the benefit of hindsight and lower utilization but will face exactly the same problems if we do not take steps to address blockchain bloat.

## Specification

Miners can start reducing their gas limit to 1,000,000 by adding the below parameters to their clients. This change will happen over time with each block reducing by a maximum of 1/1024th of the gas of the previous block. More details on gasLimitBoundDivisor are here.

### Geth
--targetgaslimit 1000000

### Parity
--gas-floor-target 1000000 --gas-cap 0

### Mantis
TBD

### Code Changes
A more robust method to decreasing gas target is to specify a default within each ETC client. Potential changes are detailed below:
- Parity-Ethereum, Mantis, and Multi-Geth will require a small refactor such that the default is specified in a config file, rather than hard coded as is presently the case.
- Geth-ETC, being a single-network client, can simply update the value specified here

### Abstract

As brought up in the Atlantis HF dev call, EIP-170 was added as part of the ECIP-1054 atlantis upgrade. There are alternate proposals for solving the disproportionate gas cost and possible DoS vector that are detailed in the ethereum/eips issues section, as well as a number of arguments as to why it hampers smart contract development significantly. This ECIP is to serve as a mirror of such thread, and hopefully get some discourse around reconsidering this change. I've added @maxsam4 as an author as much of this is copy pasted from the afforementioned issue.

### Motivation

Complex dApps require complex smart contracts. I have seen a lot of dApp developers struggle with this and a lot of alternative solutions are being used like using delegate calls. Delegate calls reduce code readability while developing and while verifying source code on tools like etherscan. They also introduce another attack surface and added complexity.

### Specification

As suggested by @jbaylina in this comment:

### Rationale

The only reason why contract size was limited was to prevent people from exploiting the fixed costs. We can overcome this by making the costs variable. The suggestion by @jbaylina is more representative of real-world cost of the computation. Fetching is expensive and cache is cheap, and so the cost should be reflected as such.

### Implementation

TBD. Preliminary discussion of alternatives is required.

### References

https://eips.ethereum.org/EIPS/eip-170
https://github.com/ethereumclassic/ECIPs/blob/0a4afcab7f9b97993a255079ceba848db2495b45/_specs/ecip-1054.md
https://github.com/ethereum/EIPs/issues/1662
https://github.com/ethereum/EIPs/issues/170

# ECIP 1041 - Remove Difficulty Bomb

## Abstract
This ECIP proposes removing Difficulty Bomb from Ethereum Classic Mainnet at block 5,900,000

## Motivation
As Ethereum Classic Mainnet is not planed to migrate to PoS in near future there is no reason to have it and the Difficulty Bomb should be removed to avoid collapse of the network.

## Specification
Difficulty Bomb is an artificial increase of mining difficulty of Ethereum blockchain which was introduced to Ethereum protocol as a motivation for developers to migrate to Proof of Stake consensus algorithm. It was introduced in Ethereum Homestead by EIP-2.

With that additional element, Minimum Mining Difficulty grows exponentially every 100,000 blocks by factor of 2. It was paused by ECIP-1010 from block 3,000,000 to block 5,000,000. With continued growth at the block 6,500,000, which is scheduled for September 2018, the mining of ETC chain will become unprofitable. There is a small chance that miners will quit mining ETC because of mining difficulty growth before that block.

Removing that part of the formula is a trivial change, but because it’s a part of consensus rules it produces a Hardfork. To make it successfull it requires modifications to all of existing ETC peer implementations and providing time to upgrade for miners, exchanges and other critical parts of ETC ecosystem.

It seems reasonable to allocate up to 6 weeks to update and release all critical software and up to 6 weeks to upgrade for miners and exchanges. Which gives up to 3 months for enabling this proposal. With that requirements the earliest safe block to enable new hardfork would be 5,700,000 which is expected at April 2018

Growing Difficulty Bomb above 20% of standard difficulty is dangerous, also for additional security we should consider scenario when half of the current miners left the network. With current difficulty at about 7,000 Gh/s it shouldn’t grow above 700 Gh. Under that requirements the latest safe block to enable new hardfork would be 6,100,000 with 550Gh of extra difficulty, which fits our requirements. Block 6,100,000 is expected at June 2018.

Hardfork boundaries:
- Earliest block is 5,700,000 at April 2018
- Latest block is 6,100,000 at June 2018

It’s proposed here to use block 5,900,000 which is in the middle between these boundaries.

Block 5,900,000 expected at May 2018 and will require 137Gh of additional difficulty. It’s an optimal block under current circumstances.

## Implementation

For most of peer implementations it’s a trivial modification and can be done through configuration without changing actual code.

## References
- ECIP-1010 Delay Difficulty Bomb Explosion - https://ecips.ethereumclassic.org/ECIPs/eip-1010
- EIP-2 Homestead Hard-fork Changes - https://eips.ethereum.org/EIPS/eip-2

# Abstract

It’s proposed here to support Sidechains to Ethereum Classic blockchain as a first class citizens, effectively
sharding transactions between separate chains based on cheaper consensus algorithms (PoS, PoA, etc) and
using Main Ethereum Classic chain to transfer state between these chains and use as a security checkpoint
(Checkpoint Contract Consensus).

Checkpoint Contract is based on Smart Contract way to track Sidechain state, it has special methods to store
Height/Difficulty/State of Sidechain in a separate parent chain. Consensus algorithm for a Side Chain could consider
this information stored in parent chain when synchronizing side chain.

NOTE This document propose a general idea, where some parts can be implemented in different ways, and will be
proposed with separate ECIPs

# Definitions
- Parent Chain - a blockchain to make checkpoints to
- Sidechain - a dependent blockchain that uses Parent Chain Checkpoints as part of Consensus
- Checkpoint - a status of Sidechain committed to Parent Chain
- Private Chain - a custom blockchain w/o public nodes
- Mainnet - main Ethereum Classic blockchain
- PoS - Proof Of Stake
- PoA - Proof Of Authority

# Motivation

One of the ways to provide Scalability is to split execution into several (semi-) independent parts and allow Peer
to process only that parts of whole chains that Peer is using. This approach is usually called Sharding.

Proof Of Work consensus algorithm is proven to be good for chain security, but other consensus algorithms, such as
Proof Of Stake or Proof of Authority are better for performance and much cheaper in execution, and therefore are
good solution for Scalability.

By combining them into a Hybrid Multichain, where chains is split into Sidechains with better performing consensus
algorithm, we can reach greater scalability. A business can have a fast and cheap chain for internal processing,
but having a security from public Proof Of Work ledger.

Idea of Sidechain for scalability is not new, and different versions of same idea were discussed many times over
past years ([1], [2]). Most of these discussions were about applying Sidechains to Bitcoin,
which has a are limited execution model and it requires enhancements to start using it. Ethereum turing-complete
VM is much more flexible and allows to use this approach for scalability even without running a Hard Fork.

# Specification

## Overview

A Peer configures Geth to follow a separate chain (Sidechain) and specifying a more secure chain (Parent Chain)
to make checkpoints through a special smart contract. For simplicity it could be two separate instances of Geth,
communicating through RPC API. For better usability it would be optimal to add ability to follow several chains from
same Geth instance.

## Key points:
- There should be a special Smart Contract deployed to Parent Chain to manage checkpoints
- Checkpoints are transactions in Parent Chain
- Sidechain can read from Parent Chain and verify that it follows longest or most difficult Sidechain
- Mainnet is going to work as usual. Not a fork.

It maybe helpful to introduce additional Opcodes to improve cross-transaction functionality. That will require a
protocol upgrade, but that’s optional and will be discussed in separate ECIPs

## Types of chains

There can be selected major 3 types of Sidechains:
- Private chain - uses mainnet only for consensus
- Trusted public chain - operated by a trusted party
- Public chain - general use blockchain operated in untrusted environment

### Private Chain (C1)

Private Chain is a fully private chain executed in isolated environment which is using Parent Chain only as a security
mechanism.

This can be a solution for many cases of a private corporate blockchains. This types of chain doesn’t share state with
parent chain, and therefore doesn’t need cross transactions, or can perform them in individual way when needed.

Conception of making checkpoints on public secure blockchain is a popular idea in private chains and standalone
services, also called as Anchoring.

See ECIP-1028

### Trusted Public Chain (C2)

Trusted Public Chain is a chain managed by a public service or Dapp, and such service provides full management of
that chain and performs cross operations for their users. Sidechain can use PoA or PoS for internal consensus, and a
separate Oracle/Validator like service to send/confirm user actions performed across the chains. For most of the cases
this chain could have a simple shared state, such as buying/selling internal tokens through a parent coin.

Smart contracts for controlling shared state, and Transaction Replay like logic can give users additional security for
their cross-chain operations.

Example: a smart contract based Token Exchange with Deposit/Withdraw through a special Smart Contract in Parent chain

### Public Chain (C3)

Public Chain is a general use blockchain, operated by multiple parties and in an untrusted environment. It can use a
fast PoS consensus algorithm for fast and cheap transactions, or individual configuration of EVM.

## Checkpoint authorization

Making a checkpoint will require verification mechanism to avoid corrupted state and to protect from malicious actors.

For simple cases, when Sidechain is solely managed by one business (C1/C2 types), it’s enough to authorize an address
(or set of addresses) which can make such checkpoints.

For more sophisticated chains (C2/C3 types) verification a Sidechain can use methods similar to Proof Of Stake, or
even implement full verification in a smart contract. Later is possible if a checkpoint can provide security by
validating only a chain headers and part of shared state.

## Cross Transactions

Cross-transactions for public Sidechain (C3) is most complicated part. In additional to untrusted environment it
can have multiple shared states managed by different types of services. It seems to be infeasible to implement a
general algorithm which will work for all cases.

There could be few possible solutions to that problem:
- Tx Replay through a Smart Contract, when Transaction Owner is separated from Transaction Executor. One example is
 Replay Attack Issue for ETH/ETC, when once signed transaction can be reused by a third party on a separate chain.
 This can also be implemented through a smart contract, where an input operation in one chain can be easily replayed
 by another network participant (which could also get a small fee for this) effectively making cross transactions
 between chains. By using Smart Contract implementation it’s possible to achieve required effect different by chain.
- Ideas from Polkadot [4] and Tendermint/Cosmos [5] can be applied here. Both this approaches are targeting more broad set
 of blockchains, so can be significantly simplified for this particular task.

To improve capabilities of EVM to handle support for cross transactions, it seems to be helpful to add new Opcodes to
do following:
- Get a hash of a whole mapping state of an address - that will allow to validate shared state on a checkpoint
- Signature validation for arbitrary data passed to a contract - that will allow to make same calls from another
 user (“replay tx”)

As there are few possible ways to implement such cross-chain transaction mechanism, it will be introduced in a series
of a separate ECIPs.

# Key Features

Proposed structure allows to use different EVM configuration per chain. It can be used for testing purposes, when a
part of the network is used a test playground for new features of EVM. A business can apply custom optimization and
additional features (OPCODES and Predefined Contracts) for their needs on their Sidechain. It could move most of
politics aside, as sides can choose own subset of Sidechains for their needs.

Besides EVM it allows to use different type of VM for particular Sidechain, such as eWASM, WASM, JVM, etc

More to that, it’s possible to implement Sidechain with a totally new execution structure, which can be optimized just
for one particular task, such as Token Transfer. Token Transfer Sidechain doesn’t need most of EVM features, therefore
it can be implemented in ways similar to Bitcoin UTXO, Lighting/Raiden network, or can be used together with
Zk-SNARKs, etc.

A particular Sidechain is free to use own subset of Sidechain, and practically allows to use Three of Chains, based
on task or conditions. That could be a long living chain or ephemeral chain, global chain or geo-bounded chain
suitable for local network of IoT devices.

# Alternatives to proposed approach
- Address Space Sharding [6] - where a peer keeps only part of address space required for processing. This solution can
 be used together with proposed scheme and it gives additional joint for scalability.
- Raiden Network [7] - basically it’s a Sidechain in terms of this proposal, and can be considered as one of the possible
 implementations of a Sidechain

# Implementation

## Checkpoint Contract Interface

Minimal interface usable for a private managed chain

It’s possible that for some cases it will be required to keep other data within the checkpoint, at this case it’s
possible to extend parameters list with this new details. But for better compatibility and for standardization, it’s
suggested to introduce custom methods to manage other details associated with the checkpoint

## Extended interface

## Geth Enhancements

Geth should have support for multiple consensus mechanisms, and a configuration for multiple chains. Part of this
is already implemented, and we can have multiple custom/private chains with Geth starting at version 3.4.0. Similar
features are already implemented in Parity.

It will also require improvements in user interface, new commands, configuration options and documentation. None of
this is a breaking change

# References
1. Enabling Blockchain Innovations with Pegged Sidechains (Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille) - https://blockstream.com/sidechains.pdf
2. Scaling Bitcoin with Sidechains - https://bitcointalk.org/index.php?topic=1083345.0
3. Sidechains, Drivechains, and RSK 2-Way peg Design - http://www.rsk.co/blog/sidechains-drivechains-and-rsk-2-way-peg-design
4. Polkadot, a heterogeneous extensible multi-chain - http://polkadot.io/
5. Cosmos: A Network of Distributed Ledgers (Jae Kwon, Ethan Buchman) - https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#sidechains
6. Ethereum ETH Sharding FAQ - https://github.com/ethereum/wiki/wiki/Sharding-FAQ
7. Raiden Network - http://raiden.network/

### Simple Summary

This is a standalone ECIP for the addition of the SELFBALANCE opcode. This opcode
was added to the ETH protocol as part of the broader EIP 1884: Repricing for trie-size-dependent opcodes which was activated in the Instanbul hardfork. The 1884 EIP was rejected during the
ETC Core Developers call on 27th November 2019 because
it broke backwards compatbility, but in this case the baby was accidentally thrown out with the bathwater.

### Abstract

This ECIP is a standalone SELFBALANCE specification, which would be implemented
as part of the "Phoenix" hardfork which would either "fix" Aztlán
or would replace Aztlán.

The network participants who took part in the
ETC Core Developers call on 27th November 2019
were under the impression at the time that the scope we agreed ("Instanbul without the
backward-compatibility breaking parts of EIP-1884") - ECIP-1061 / ECIP-1072 - would move the ETC
protocol to a place where it was 100% compatible with the ETH mainnet.

### Specification

Thanks to Wei Tang for
identifying the mis-specification and
for providing his recommendation on how to rectify it.
- A new opcode, SELFBALANCE is introduced at 0x47.
- SELFBALANCE pops 0 arguments off the stack,
- SELFBALANCE pushes the balance of the current address to the stack,
- SELFBALANCE is priced as GasFastStep, at 5 gas.

### Rationale

See EIP 1884: Repricing for trie-size-dependent opcodes for
the original rationale for the gas-repricings for ETH.

These changes are sensible, but they broke 680 deployed Aragon smart contracts along with various other deployed
smart contacts by applying the repricings retroactively and unconditionally.

This new opcode does not break backwards compatibility. For compatibility with ETH it is both
necessary and desirable.

### Implementation

The following clients with Ethereum Classic support already implement the SELFBALANCE opcode, but
not in this standalone form yet. The work to support standalone would be minimal.
- Parity Ethereum
- Multi-Geth
- Hyperledger Besu

## Copyright

This proposal is licensed under the Apache License, Version 2.0,
based on specifications developed by Wei Tang within the Core Paper project (https://corepaper.org/).

Core Paper Copyright 2019-2020 Wei Tang.

Bob Summerwill, the author of this proposal attests that his is the sole author of this specific document
based on Wei Tang's work and that he is able to contribute this work to the ECIP process under the
Apache 2.0 licence. He further attests that he neither holds nor is aware of any patents, trademarks,
copyright issues or other IP hinderances associated with this work.

This ECIP is based off BIP 0021 can be referenced at https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki

# Abstract
This ECIP proposes a URI scheme for interacting with ethereum contract and accounts in a uniform standard format.

# Motivation
The purpose of this URI scheme is to enable users to easily make payments and interact with smart contracts by simply clicking links on webpages or scanning QR Codes. This allows for nfc, qr codes, or other similar non-interactive devices to store and transmit a standard message to a user, as well as interactive applications such as websites and dApps to present simple data to a user for action

# Specification

## General rules for handling (important!)

ETC clients MUST NOT act on URIs without getting the user's authorization.
They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.
ETC clients SHOULD include the message field describing the actions of the code.

## Operating system integration
Graphical ethereum clients SHOULD register themselves as the handler for the "ethereum:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

## General Format

Ethereum URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of an Ethereum address, and the query component provides additional payment options.

Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.

## ABNF grammar
- ethereumurn = "ethereum:" ethereumaddress & ethereumchainid [ "?" ethereumparams ]
- ethereumaddress = hexdig
- ethereumchainid = "id=" digit
- ethereumparams = ethereumparam [ "&" ethereumparams ]
- ethereumparam = [ amountparam / gasparam / gaslimitparm / nonceparam / codeparam / labelparam / messageparam / otherparam / reqparam]
- amountparam = "amount=" digit [ "." digit ]
- gasparam = "gas=" digit
- gaslimitparm = "glmt=" digit
- nonceparam = "n=" digit
- codeparam = "code=" hexdig
- labelparam = "label=" qchar
- messageparam = "message=" qchar
- otherparam = qchar qchar [ "=" qchar ]
- reqparam = "req-" qchar qchar [ "=" qchar ]

Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this ECIP takes as separators.

The scheme component ("ethereum:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys.

## Query Keys
- address: ethereum account or contract address in hexidecimal
- id: eip 155 compliant chainid, used for sanity check
- amount = amount of ether to transfer, denominated in ETC
- gas = gas price
- gaslmt = amount of gas transaction is not to exceed
- nonce = account nonce
- code = byte code data for transaction
- label: Label for that address (e.g. name of receiver)
- message: message that describes the transaction to the user ([[#Examples|see examples below]])
- (others): optional, for future extensions

## EIP 155 Transaction

The intent of the uri is to pass all information nessecarry for forming a raw transaction to another device or service for signing.

A raw transaction should map the uri functions as follows for RLP encoding:

 var rawTX = {

The parameters labelparam, messageparam, otherparam, and reqparam are not used in transaction signing and can be optionally displayed to the user to pass additional information about the transaction.

### Transfer amount/size

If an amount is provided, it MUST be specified in decimal ETC.
All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.
I.e. amount=50.00 or amount=50 is treated as 50 ETC, and amount=50,000.00 is invalid.

ETC clients MAY display the amount in any format that is not intended to deceive the user.
They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
For example, so long as the majority of users work in ETC units, values should always be displayed in ETC by default, even if wei would otherwise be a more logical interpretation of the amount.

## ENS addresses

The Ethereum Name Service is a protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes.

ENS names must conform to the following syntax:

 ::= | "."
 ::= any valid string label per UTS46

For the specification of the URI, resolves into the following ethereumchainid:

{| class="wikitable" style="text-align: left;"
|-
! scope="col" width="width:20em;" | TLD
! scope="col" width="width:20em;" | Chain_ID
! scope="col" width="width:20em;" | Chain
|-
|.eth
|1
|Ethereum mainnet
|-
|.exp
|2
|Expanse mainnet
|-
|.rsk
|30
|Rootstock mainnet
|-
|.etc
|61
|Ethereum Classic mainnet
|-
|}

## Bytecode Transactions

Events and functions in evm contracts are / can be preformatted to know functions in the underlying contract. The first four bytes of the call data for a function call specifies the function to be called. It is the first (left, high-order in big-endian) four bytes of the Keccak (SHA-3) hash of the signature of the function. This information along, with the appropriate hex encoded data to pass, form the bytecode.

### Example

Contract C is at 0xdeadbeef... and has the following psudo function:

 function getETC(){

Contract C requires no inputs and only requires enough gas to preform its functions. The byte code for this function can be derived using web3 as:

 web3.sha3("getETC()");

which yeilds:

 0x023b88685d10d29e0bf0563e4ab1b9d8fc8333c166705be5538c4b079cdd9af0

The information that will be passed in the byte code field would then be:

 code=0x023b8868

The entire URi could be:

 ethereum:0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef&id=61?code=0x023b8868

Bytecode specifications can be found in their respective documentation.

# Rationale

## Payment identifiers, not person identifiers
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment or function call.

## Accessibility (URI scheme name)
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to ETC.

## Contract Code

It is not the intent of this ECIP to define every possible contract code that could be implimented.
Higher level functionality would be provided by the site creating the URI qr code and, for lack of a better term,
black box it to the application scanning the code. As generating qr-codes is trivial on an application compared to
the hazard of unlocking a private key, an application should be able to produce a URI that is functionally similar
to a standard transaction without the account specific details.

Best practices in function codes shold be adhered to and this ECIP should remain forward compatable.
It is recommended that dApps should make effort to include in the message what is being accomplished in the code.

## Forward compatibility
Variables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored.

## Backward compatibility
As this ECIP is written, several clients already implement a ethereum: URI scheme similar to this one, however usually without the additional "req-" prefix requirement. Thus, it is recommended that additional variables prefixed with req- not be used in a mission-critical way until a grace period of 6 months from the finalization of this ECIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade.

# Appendix

## Simpler syntax

This section is non-normative and does not cover all possible syntax.
Please see the BNF grammar above for the normative syntax.

[foo] means optional, <bar> are placeholders

 ethereum: &id= [?amount= ][&gas= ][&glmt= ][&n= ][&code= ][&label= ][&message= ]

## Examples

Just the address:
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61

Address with name:
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61?label=DontPanic

Request 20.30 ETC to "DontPanic":
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61?amount=20.3&label=DontPanic

Request 42.30 ETC to "DontPanic" with gas:
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61?amount=20.3&gas=21000&label=DontPanic

Request 50 ETC with message:
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61?amount=50&label=DontPanic&message=Purchase%20token%20for%20project%20xyz%20ICO

Request a function call in a contract:
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61?amount=50&code=0x2066726f6d204a656666204761727a696b20666f7220746f6b656e206d696e74

Some future version that has variables which are (currently) not understood and required and thus invalid:
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61?req-somethingyoudontunderstand=50&req-somethingelseyoudontget=999

Some future version that has variables which are (currently) not understood but not required and thus valid:
 ethereum:0xCe5ED529977b08f87CBc207ebC216859820461eE&id=61?somethingyoudontunderstand=50&somethingelseyoudontget=999

Characters must be URI encoded properly.

# Reference Implementations

## Libraries

## References

BIP 21: Bitcoin URI Scheme
https://github.com/bitcoin/bips/blob/master/bip-0021.mediawik

ERC: Standard URI scheme with metadata, value and byte code
https://github.com/ethereum/EIPs/issues/67

RFC 3986
https://www.ietf.org/rfc/rfc3986.txt

EIP 155: Simple replay attack protection
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md

EIP 137: Ethereum Domain Name Service - Specification
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md

Solidity in depth
http://solidity.readthedocs.io/en/develop/abi-spec.html#examples

Ethereum Yellow Paper
http://yellowpaper.io/

## Abstract

This proposal introduces two opcodes to support subroutines: JUMPSUB and RETSUB.

## Motivation

The EVM does not provide subroutines as a primitive. Instead, calls must be synthesized by fetching and pushing the current program counter on the data stack and jumping to the subroutine address; returns must be synthesized by getting the return address to the top of stack and jumping back to it.

## Specification

##### JUMPSUB
Jumps to the address on top of the stack, which must be the offset of a JUMPDEST.

##### RETSUB
Returns to the instruction after the most recently executed JUMPSUB instruction.

A program may JUMPSUB at most 1023 times without an intervening RETSUB.

## Rationale

This is the smallest possible change that provides native subroutines without breaking backwards compatibility.

## Backwards Compatibility

These changes do not affect the semantics of existing EVM code.

## Test Cases

This code should terminate after 5 steps with an empty stack.

## Implementations

No clients have implemented this proposal as of yet.

The new operators proposed here are implemented by the following pseudocode, which adds cases for JUMPSUB and RETSUB to a simple loop-and-switch interpreter.

Execution of EVM bytecode begins with one value on the return stack—the size of the bytecode. The virtual byte of 0 at this offset is the EVM STOP opcode, so executing a RETSUB with no prior JUMPSUB executes a STOP. A STOP or RETURN ends the execution of the subroutine and the program.

We suggest the cost of JUMPSUB should be low, and RETSUB should be verylow.
 Measurement will tell. We suggest the following opcodes:

## Security Considerations

Program flow analysis frameworks will need to be updated to allow for a new type of branch -JUMPSUB - and new type of branching, since a RETSUB will cause a jump to a destination which is not a JUMPDEST.

## Copyright

This proposal is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license based on specifications developed by Greg Colvin
within the Ethereum improvement process as EIP 2315: Simple Subroutines for the EVM.

Bob Summerwill, the author of this proposal attests that his is the sole author of this specific document
based on Greg Colvin's work and that he is able to contribute this work to the ECIP process under the
CC-BY-SA-4.0 licence. He further attests that he neither holds nor is aware of any patents, trademarks,
copyright issues or other IP hinderances associated with this work.

### Simple Summary

Issues with the Aztlán protocol upgrades were identified and sufficiently patched with the Phoenix protocol upgrades. However, the subsequent activation of these upgrades on the Kotti and Mordor testnets revealed inconsistencies between client implementations. This document proposes a patch for the aforementioned testnets.

### Abstract

The EIP-2200 defines structured definitions of net-gas metering for the SSTORE opcode. This EIP was activated in a bundle called EIP-1679 "Istanbul" on the Ethereum Foundation network and ECIP-1061 "Aztlán" on the Ethereum Classic network.

Notably, the difference here is that Istanbul contained EIP-1884 which repriced various opcodes for trie-size dependent operations, whereas Aztlán did not.

Both EIP-1884 and EIP-2200 propose the SLOADGAS to be increased from 200 to 800 but not all clients correctly implemented this change for both EIPs leaving networks configured with a pick-and-mix EIP configuration such as Aztlán with an incompatible configuration as compared to clients who correctly implemented the specifications.

### Motivation

This specification seeks to validate the incomplete configuration in favor of retaining the Kotti and Mordor testnets in consensus. This ECIP shall not be considered on mainnet. It's sole purpose is to allow avoiding a rollback on the testnets and having a proper documentation on the cause for the gas mismatch and providing instructions for client developers how to circumvent this.

### Specification

At BLOCKNUMBER maintain a consistent SLOADGAS cost of 200.

This applies only under the condition:
- that ECIP-1061 Aztlán was activated without ECIP-1078 Phoenix,
- OR that EIP-2200 was activated without EIP-1884.

A subsequent protocol upgrade disabling EIP-2200 (such as ECIP-1078 Phoenix) makes this gas pricing configuration obsolete if it's activated at the same BLOCKNUMBER.

This document proposes the following BLOCKNUMBER at which to implement these changes in the Classic test networks:
- ~~778507 on Mordor Classic PoW-testnet (Jan 30th, 2020)~~
- ~~2058191 on Kotti Classic PoA-testnet (Feb 12th, 2020)~~

### Rationale

The inconsistency was discovered in a consensus issue on the Mordor Classic testnet between Hyperledger Besu, ETC Core Multi-Geth, and Parity Technologies Parity Ethereum.

It turned out that Besu correctly implemented EIP-2200 whereas Parity and Geth chose a sloppy implementation under the assumption of having this gas change already included with EIP-1884.

The following code changes to the clients are relevant for this ECIP:
- Foundation Geth: ethereum/go-ethereum#20646
- Parity Ethereum: paritytech/parity-ethereum#11474
- Multi-Geth: etclabscore/multi-geth#144

Note, that accepting and merging these pull requests would either require to roll back the Kotti and Mordor testnets or to accept this ECIP-1086 to patch the SLOAD gas to 200. As author of this proposal I will champion for a patch in favor of a rollback.

### Implementation

Adoption of the content of this ECIP requires a configuration for all clients to allow for configuring SLOAD_GAS as per ECIP-1086. The implementation cost is considered low.

An implementation is available for:
- Hyperledger Besu: hyperledger/besu#382
- Parity Ethereum: N/A
- Multi-Geth: etclabscore/multi-geth#151

## Copyright

Copyright and related rights waived via CC0.

## 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.

### Simple Summary
Enable the outstanding Ethereum Foundation Shanghai network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Spiral to enable maximum compatibility across these networks.

### Abstract
Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Shanghai network upgrade. The proposed changes for Ethereum Classic's Spiral upgrade include:

EIP | Description | Status
-- | -- | --
3651 | Warm COINBASE | Include
3855 | PUSH0 instruction | Include
3860 | Limit and meter initcode | Include
6049 | Deprecate SELFDESTRUCT | Include
4399 | Supplant DIFFICULTY opcode with PREVRANDAO | Omit
4895 | Beacon chain push withdrawals as operations | Omit

Beacon chain withdrawals are omitted at this time as they are not applicable for Ethereum Classic.

#### EIP Summaries and expected action
##### Included
- EIP 3651 "Warm COINBASE": Lowers the price of accessing the coinbase account following the access list framework introduced in EIP-2929.
- EIP 3855 "PUSH0 instruction": Introduces the PUSH0 (0x5f) instruction, which pushes the constant value 0 onto the stack.
- EIP-3860 "Limit and meter initcode": Limits the maximum size of initcode to 49152 bytes and apply extra gas cost of 2 for every 32-byte chunk of initcode

##### Omitted
- EIP 4399 "Supplant DIFFICULTY opcode with PREVRANDAO": Historically, the DIFFICULTY (0X44) instruction was used as a source of pseudo randomness. With the switch to Proof of Stake, Ethereum removed the work difficulty so, as a replacement, they now expose a RANDAO value taken from the beacon chain. Since v0.8.18, Solidity deprecates block.difficulty and replaces it with block.prevrandao but this syntactic change still compiles to the same EVM opcode, i.e. 0x44, which in the Ethereum Classic network will continue to evaluate as the aforementioned block difficulty value.
- EIP 4895 "Beacon chain push withdrawals as operations": In Proof of Stake networks, enable validator withdrawals from the beacon chain to the EVM. Ethereum Classic network only grants rewards through Proof of Work mining on the canonical chain, there are no validators, so this doesn't apply.

This document proposes the following blocks at which to implement these changes in the Ethereum Classic networks:
- 9957000 on Mordor testnet
- 19250000 on Ethereum Classic mainnet

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2022.

### Specification

Technical specifications for each EIP can be found at those documents respectively:
- EIP-4399: Supplant DIFFICULTY opcode with PREVRANDAO
- EIP-3651: Warm COINBASE
- EIP-3855: PUSH0 instruction
- EIP-3860: Limit and meter initcode
- EIP-6049: Deprecate SELFDESTRUCT
- EIP-4895: Beacon chain push withdrawals as operations

### Rationale

_Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Sepholia and Mordor).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

While this means no currently executable contract is affected, it states deployment of new data contracts starting with the 0xEF byte.

### Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Mystique features currently and will be able to support the Spiral_ upgrade:
- Core-Geth (maintained by ETC Cooperative)
- Hyperledger Besu (maintained by ConsenSys)

## Copyright

Copyright and related rights waived via
CC0.

## Note
I will often use the term "Signer" to mean the same thing as "Wallet", because these programs can sign more than just transactions.

## Abstract
UX involved with handling ethereum signing is especially cumbersome. This is mostly due to the fact that dapps and wallets are used in many different environments (i.e. desktop, mobile, CLI, plugin, mobile-browsers desktop-browsers, and hardware). Attempts to improve this UX shortcoming have generally involved rigid user work-flows, or specific application combinations. I assert the problem is best solved at the operating system level using a widely standardized protocol like the one proposed below.

The following describes
1. A way for dapp developers to handle any action requiring a signature (i.e. signing a tx or logging in). The spec defines how the wallet is chosen and invoked by the user's Operating System
2. A way for wallet applications to handle incoming requests for signature.

## Motivation
Users should be able to use any wallet of their choosing when interacting with a dapp. Having users download a specific wallet per-environment reduces security, inhibits adoption, and is terrible UX: The user has to "top-up", and not forget about each application-specific wallet. This sucks for the user because they have money all over the place and a laundry list of wallet program installations across devices.

The current architecture leads to staments like "Our dapp currently works on the chrome browser with metamask enabled. We plan to add support MyEtherWallet soon."

As the number of wallets and dapps grow, the combinations become n^2. This will inhibit small wallets from entering the market, but require users to download all major wallets.

## Current Scenario
#### Desktop Browser Dapps
So far, the best solution has been to download wallet plugins like Metamask, that inject javascript (by being granted very scary permissions) onto every single page the user navigates to. The user often cannot use a hardware wallet unless the dapp devloper specifically integrates support for it - a huge security limitation.

#### Mobile Browser Dapps
If the user attempts to load the dapp on mobile, they are expected to use a specially made "web3 enabled" mobile browser (i.e. Brave, Toshi), to view the app so the dapp has available it's in-browser wallet for invocation. This is suboptimal architecture, and a waste of engineering resources. Browsers are extraordinarily complex programs, and building a decent one is an overwhelmingly monumental challenge (unless say, you're the inventor of Javascript). UX is much better when they can use their preffered browser. Besides - we should not be building web-browsers to solve the problem of wallets.

#### Native Dapps (the worst UX of all)
Currently, if a mobile app developer wants to integrate an ethereum feature in their app, they genreally build a wallet into the app itself (from scratch). The user ends up with loose change in siloed apps, and these wallets will have widely varying (and therefore pathetic) security standards.

## Desired Dapp Experience
Before defining the proposed spec, I'd like to outline the ideal user experience, and work backwards to achieve it. After all, thats how this spec came about.
1. If a dapp is browser-based, the user can browse to it using ANY available browser on mobile OR desktop.
2. If the dapp is a native mobile or native desktop app, they simply download then open the application.
3. When the dapp requires a signature it should
- Automatically open the user's preferred mobile wallet when on mobile, or
- Automatically open the user's preferred desktop/hardware wallet when on desktop.
4. The wallet should then display details of the signing request.
5. The user can then tap or click "sign" and be sent back to the dapp.

## Rationale
This problem finally must be addressed at the Operating System level, because it is the only way to flexibly hand off control flow to another app.

### Deep Links
Deep linking is a method available from any application or webpage that provides the user's operating system with instructions to open a specific application (and can carry an arbitrary data string with it). They work in basically all environments: Android, iOS, MacOS, Windows, and Linux (possibly others).

Most of us have seen deep linking used when clicking on a Zoom or Spotify link. It usually invokes focus to a specific application. In our case, we don't want to open a specific (branded) application (i.e. Jaxx, Toshi, or Gnosis-Safe). Rather we tell the operating system to open the user's "default signer" (wallet).

### Implimentations
#### IOS and OSX
Implementation of signer apps varies by OS. On IOS it can be done with NSUrl Protocol, which is like a link, but instead of a opening a specific app, you specify a name space (e.g. "invoke-signer") to which any app can register itself as a handler.

All apps on the device registered as a handler will call a boolean function deciding whether or not the app should handle the incoming request (perhaps true if (and only if) the user has chosen this signer as default). The first app to return true from this function will be launched with access to data from the URL (the rpc data and/or more).

## Draft Specification
The name space should indicate fundamentally that its doing the signing. So ethereum-signer was my first though. However, nearly any cryptocurrency can benefit from this. For that reason simply signer would be better. Lastly this spec is about more than just a referring to the signer app - it is about specifically invoking that app. Therefore I think invoke-signer is the most relevent namespace to use.

From there, the path could communicate the specific cryptocurrency, i.e. ethereum-classic (together invoke-signer://ethereum-classic...). The path can be used by the singer in its boolean function to determine whether it's capable of handling this particular signing request. Then we need a way to tell the signer exactly what to do:

From there we need to communicate exactly what the signer should do. Rather then re-inventing the wheel, we can just uriencode the existing JSON RPC calls. For instance all signers would want to support the existing RPC methods ethsign and ethsignTypedData.

In standard query format this would be:

Over time signers should become the secure and predictable place to view blockchain information, espesially data about to be signed. We can not really trust data being viewed on brower-based explorers or new dapp websites. More advanced RPC methods will be added over time to accomidate this. For instance, methods that pass contractCode and compilerVerion, will be able to verify the code and ABI in the signer app. But none of that needs to be defined right now, because the format accepts arbitrary future methods!

## Conclusion
#### New User Experience
Most users will have a favorite mobile signer and enjoy a consistent experience with every dapp. Some may still use a plugin like metamask when on desktop, and power users will use a hardware signer for ultra-high security as needed.

#### Developer Experience
It becomes much easier to add a single "ethereum feature" into any software application. The app dev does not need to worry about any of the details of building a wallet/signer. They just create a string to be signed, and invoke the user's signer with it. The user expectation is only that they have a_ signer, as opposed to some specific signer.

### Withdrawal Notice:

This approach currently has a flaw that the name of the caller application is not sent to the invoked wallet, so handing control back to the caller app is very difficult. This can be worked around in an app-to-app setting (by passing it as part of the payload), but not in a browser-to-app setting (without complicated "browser sniffing" techniques).

### Abstract

This standard outlines a common set of Status Codes in the same
vein as HTTP statuses. This provides a shared set of signals to allow smart contracts
to react to situations autonomously, expose localized error messages to users, and so on.

The current state of the art is to either revert and require human intervention,
or return a Boolean pass/fail status. Status codes are similar-but-orthogonal
to reverting with a reason, but aimed at automation and translation.

As is the case with HTTP, having a standard set of known codes has many benefits for developers:
- They remove friction from needing to develop your own schemes for every contract,
- makes inter-contract automation easier, and
- makes it easier to broadly understand which of the finite states your request produced.

Importantly, it makes it much easier to distinguish between expected errors states, and truly exceptional conditions that require halting execution.

# Motivation

## Autonomy

Smart contracts are largely intended to be autonomous. While each contract may
define a specific interface, having a common set of semantic codes can help
developers write code that can react appropriately to various situations.

## Semantic Density

HTTP status codes are widely used for this purpose. BEAM languages use atoms
and tagged tuples to signify much the same information. Both provide a lot of
information both to the programmer (debugging for instance), and to the program
that needs to decide what to do next.

FISSION Codes convey a much richer set of information than Booleans,
and are able to be reacted to autonomously unlike arbitrary strings.

## User Feedback

Since status codes are finite and known in advance, we can provide global,
human-readable sets of status messages. These may also be translated into any language,
differing levels of technical detail, added as revert messages, natspecs, and so on.

We also see a desire for this in transactions,
and there's no reason that FISSION Codes couldn't be used by the EVM itself.

## More than Pass/Fail

While clearly related, status codes are complementary to "revert with reason".
FISSION Codes are not limited to rolling back the transaction, and may represent known error states
without halting execution. They may also represent off-chain conditions,
supply a string to revert, signal time delays, and more.

# Specification

## Format

Codes are returned as the first value of potentially multiple return values.

In the rare case that there are multiple codes required to express an idea,
they should be organized in ascending order.

# Code Table

| X. Low Nibble | 0. Generic | 10. Permission | 20. Find/Match/&c | 30. Negotiation / Offers | 40. Availability | 50. | 60. | 70. | 80. | 90. | A0. | B0. | C0. | D0. | E0. Cryptography | F0. Off Chain |
|-----------------------------------|-------------------------|-------------------------------|-------------------------|----------------------------------|----------------------------------|-----|-----|-----|-----|-----|-----|-----|-----|-----|-------------------------------------|---------------------------------------------------|
| 0. Failure | 0x00 Failure | 0x10 Disallowed | 0x20 Not Found | 0x30 Other Party Disagreed | 0x40 Unavailable or Expired | | | | | | | | | | 0xE0 Decrypt Failure | 0xF0 Off Chain Failure |
| 1. Success | 0x01 Success | 0x11 Allowed | 0x21 Found | 0x31 Other Party Agreed | 0x41 Available | | | | | | | | | | 0xE1 Decrypt Success | 0xF1 Off Chain Success |
| 2. Accepted / Started | 0x02 Accepted / Started | 0x12 Requested Permission | 0x22 Match Request Sent | 0x32 Sent Offer | | | | | | | | | | | 0xE2 Signed | 0xF2 Off Chain Process Started |
| 3. Awaiting Others | 0x03 Awaiting | 0x13 Awaiting Permission | 0x23 Awaiting Match | 0x33 Awaiting Their Ratification | 0x43 Not Yet Available | | | | | | | | | | 0xE3 Other Party Signature Required | 0xF3 Awaiting Off Chain Completion |
| 4. Action Required / Awaiting You | 0x04 Action Required | 0x14 Awaiting Your Permission | | 0x34 Awaiting Your Ratification | 0x44 Awaiting Your Availability* | | | | | | | | | | 0xE4 Your Signature Required | 0xF4 Off Chain Action Required |
| 5. | | | | | | | | | | | | | | | | |
| 6. | | | | | | | | | | | | | | | | |
| 7. | | | | | | | | | | | | | | | | |
| 8. | | | | | | | | | | | | | | | | |
| 9. | | | | | | | | | | | | | | | | |
| A. | | | | | | | | | | | | | | | | |
| B. | | | | | | | | | | | | | | | | |
| C. | | | | | | | | | | | | | | | | |
| D. | | | | | | | | | | | | | | | | |
| E. | | | | | | | | | | | | | | | | |
| F. Meta/Info | 0x0F Metadata Only | | | | | | | | | | | | | | | 0xFF Data Source is Off Chain (ie: no guarantees) |
- Unused regions are available for further extension or custom codes
- You may need to scroll the tables horizontally (they're pretty wide)

Codes break nicely into a 16x16 matrix, represented as a 2-digit hex number.
The high nibble represents the code's kind or "category", and the low nibble contains
the state or "reason". We present them below as separate tables per range for
explanatory and layout reasons.

Unspecified codes are not free for arbitrary use, but rather open for further specification.

## Generic

General codes. These double as bare "reasons", since 0x01 == 1.

| Code | Description |
|-----------------|:------------------------|
| 0x00 | Failure |
| 0x01 | Success |
| 0x02 | Accepted / Started |
| 0x03 | Awaiting / Before |
| 0x04 | Action Required |
| 0x05 | Expired |
| 0x06 | |
| 0x07 | |
| 0x08 | |
| 0x09 | |
| 0x0A | |
| 0x0B | |
| 0x0C | |
| 0x0D | |
| 0x0E | |
| 0x0F | Meta or Info Only |

## Permission

Related to permisson, authorization, approval, and so on.

| Code | Description |
|-----------------|:-------------------------|
| 0x10 | Disallowed |
| 0x11 | Allowed |
| 0x12 | Requested Permission |
| 0x13 | Awaiting Permission |
| 0x14 | Awaiting Your Permission |
| 0x15 | No Longer Allowed |
| 0x16 | |
| 0x17 | |
| 0x18 | |
| 0x19 | |
| 0x1A | |
| 0x1B | |
| 0x1C | |
| 0x1D | |
| 0x1E | |
| 0x1F | Permission Meta or Info |

## Find, Match, &c

This range is broadly intended for finding and matching.
Data lookups and order matching are two common use cases.

| Code | Description |
|-----------------|:-------------------------|
| 0x20 | Not Found |
| 0x21 | Found |
| 0x22 | Match Request Sent |
| 0x23 | Awaiting Match |
| 0x24 | Match Request Received |
| 0x25 | Out of Range |
| 0x26 | |
| 0x27 | |
| 0x28 | |
| 0x29 | |
| 0x2A | |
| 0x2B | |
| 0x2C | |
| 0x2D | |
| 0x2E | |
| 0x2F | Matching Meta or Info |

## Negotiation, Terms, and Offers

Negotiation, and very broadly the flow of such transactions.
Note that "other party" may be more than one actor (not necessarily the sender).

| Code | Description |
|-----------------|:----------------------------|
| 0x30 | Other Party Disagreed |
| 0x31 | Other Party Agreed |
| 0x32 | Sent Offer |
| 0x33 | Awaiting Their Ratification |
| 0x34 | Awaiting Your Ratification |
| 0x35 | Offer Expired |
| 0x36 | |
| 0x37 | |
| 0x38 | |
| 0x39 | |
| 0x3A | |
| 0x3B | |
| 0x3C | |
| 0x3D | |
| 0x3E | |
| 0x3F | Negotiation Meta or Info |

## Availability

Service or action availability.

| Code | Description |
|-----------------|:----------------------------|
| 0x40 | Unavailable |
| 0x41 | Available |
| 0x42 | You May Begin |
| 0x43 | Not Yet Available |
| 0x44 | Awaiting Your Availability |
| 0x45 | No Longer Available |
| 0x46 | |
| 0x47 | |
| 0x48 | |
| 0x49 | |
| 0x4A | |
| 0x4B | |
| 0x4C | |
| 0x4D | |
| 0x4E | |
| 0x4F | Availability Meta or Info |

### 0x5 TBD

Currently unspecified

### 0x6 TBD

Currently unspecified

### 0x7 TBD

Currently unspecified

### 0x8 TBD

Currently unspecified

### 0x9 TBD

Currently unspecified

## Application-Specific Codes

Contracts may have special states that they need to signal.
This proposal only outlines the broadest meanings, but implementers may have very
specific meanings for each, as long as they are coherent with the broader definition.

| Code | Description |
|-----------------|:--------------------------------|
| 0xA0 | App-Specific Failure |
| 0xA1 | App-Specific Success |
| 0xA2 | App-Specific Acceptance / Start |
| 0xA3 | App-Specific Awaiting / Before |
| 0xA4 | App-Specific Action Required |
| 0xA5 | App-Specific Expiry |
| 0xA6 | |
| 0xA7 | |
| 0xA8 | |
| 0xA9 | |
| 0xAA | |
| 0xAB | |
| 0xAC | |
| 0xAD | |
| 0xAE | |
| 0xAF | App-Specific Meta or Info |

### 0xB TBD

Currently unspecified

### 0xC TBD

Currently unspecified

### 0xD TBD

Currently unspecified

## Cryptography and Authentication

Actions around signatures, cryptography, signing, and application-level authentication.

The meta code 0xEF is often used to signal a payload descibing the algorithm
or process used.

| Code | Description |
|-----------------|:----------------------------|
| 0xE0 | Decrypt Failure |
| 0xE1 | Decrypt Success |
| 0xE2 | Signed |
| 0xE3 | Their Signature Required |
| 0xE4 | Your Signature Required |
| 0xE5 | Auth Expired |
| 0xE6 | |
| 0xE7 | |
| 0xE8 | |
| 0xE9 | |
| 0xEA | |
| 0xEB | |
| 0xEC | |
| 0xED | |
| 0xEE | |
| 0xEF | Crypto Info or Meta |

## 0xF0 Off-Chain

For off-chain actions. Much like th 0x0: Generic range, 0xF is very general,
and does little to modify the reason.

Among other things, the meta code 0xFF may be used to describe what the off-chain process is.

| Code | Description |
|-----------------|:------------------------------|
| 0xF0 | Off-Chain Failure |
| 0xF1 | Off-Chain Success |
| 0xF2 | Off-Chain Process Stared |
| 0xF3 | Awaiting Off-Chain Completion |
| 0xF4 | Off-Chain Action Required |
| 0xF5 | Off-Chain Service Unavailable |
| 0xF6 | |
| 0xF7 | |
| 0xF8 | |
| 0xF9 | |
| 0xFA | |
| 0xFB | |
| 0xFC | |
| 0xFD | |
| 0xFE | |
| 0xFF | Off-Chain Info or Meta |

### Example Function Change

### Example Sequence Diagrams

# Rationale

## Encoding

Status Codes are encoded as a byte. Hex values break nicely into high and low nibbles:
category and reason. For instance, hex"01" stands for general success
and hex"00" for general failure.

byte is quite lightweight, and can be easily packed with multiple codes into
a bytes32 (or similar) if desired. It is also easily interoperable with uint8,
cast from enums, and so on.

## Alternatives

Alternate schemes include bytes32 and uint8. While these work reasonably
well, they have drawbacks.

uint8 feels even more similar to HTTP status codes, and enums don't require
as much casting. However does not break as evenly as a square table
(256 doesn't look as nice in base 10).

Packing multiple codes into a single bytes32 is nice in theory, but poses additional
challenges. Unused space may be interpeted as 0x00 Failure, you can only efficiently
pack four codes at once, and there is a challenge in ensuring that code combinations
are sensible. Forcing four codes into a packed representation encourages multiple
status codes to be returned, which is often more information than strictly nessesary.
This can lead to paradoxical results (ex 0x00 and 0x01 together),
or greater resorces allocated to interpreting 256 4 (4.3 billion) permutations.

## Multiple Returns

While there may be cases where packing a byte array of FISSION Codes may make sense, the simplest,
most forwards-compatible method of transmission is as the first value of a multiple return.

Familiarity is also a motivating factor. A consistent position and encoding together
follow the principle of least surprise. It is both viewable as a "header" in the HTTP analogy,
or like the "tag" in BEAM tagged tupples.

## Human Readable

Developers should not be required to memorize 256 codes. However, they break nicely into a table.
Cognitive load is lowered by organizing the table into categories and reasons.
0x10 and 0x11 belong to the same category, and 0x04 shares a reason with 0x24

While this repository includes helper enums, we have found working directly in
the hex values to be quite natural. ESC 0x10 is just as comfortable as HTTP 401, for example.

## Extensiblilty

The 0xA category is reserved for application-specific statuses.
In the case that 256 codes become insufficient, bytes1 may be embedded in larger byte arrays.

## EVM Codes

The EVM also returns a status code in transactions; specifically 0x00 and 0x01.
This proposal both matches the meanings of those two codes, and could later be used
at the EVM level.

## Empty Space

Much like how HTTP status codes have large unused ranges, there are totally empty
sections in this proposal. The intent is to not impose a complete set of codes up front,
and to allow users to suggest uses for these spaces as time progresses.

## Nibble Order

Nibble order makes no difference to the machine, and is purely mnemonic.
This design was originally in opposite order, but changed it for a few convenience factors.
Since it's a different scheme from HTTP, it may feel strange initially,
but becomes very natural after a couple hours of use.

## Short Forms

Generic is 0x0_, general codes are consistent with their integer representations

## Contract Categories

Many applications will always be part of the same category.
For instance, validation will generally be in the 0x10 range.

## Helpers

This above also means that working with app-specific enums is slightly easier:

# Implementation

Reference cases and helper libraries (Solidity and JS) can be found at:
- Source Code
- Package on npm

### Abstract

Add an RPC method to submit a new block, instead of having to use submitWork.

### Motivation

I would like to be able to submitWork, but have the address used be one other than the etherbase of the node the work is being submitted by.

### Specification

### Rationale

This removes the dependency for miners to have a geth node with accounts that need to be unlocked. Miners would be able to better isolate their private keys from the world, yeilding better security potential.

### Implementation

I think it's pretty straight forward. Looking at the above specification, we would be adding an ethsubmitBlock RPC method. It's similar to ethsubmitWork, except with fewer steps before broadcasting the block.

### NOTE

The ECIP was replaced by ECIP-1054 - Atlantis and
ECIP-1056 - Agharta. This ECIP was never activated.

### Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Byzantium hardfork. The proposed changes include:
- Byzantium EVM opcodes and precompiled contracts, namely opcodes REVERT (EIP 206/140), RETURNDATASIZE (EIP 211), RETURNDATACOPY (EIP 211), and STATICCALL (EIP 214/116); and precompiled contracts for modular exponentiation, elliptic curve addition, scalar multiplication, and pairing (EIPs 198, 212/197, 213/196)
- Expected Constantinople EVM opcodes, namely bitwise shifting operators SHL, SHR, and SAR (EIP 215); CREATE2 (EIP 1014); and EXTCODEHASH (EIP 1052).
- TODO: Research and discuss gas metering changes for SSTORE, proposed in EIP 1283.
- Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658).

This document proposes block 7,100,000 as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork in January 2019.

For more information on the opcodes and their respective EIPs and implementations, please see the _History section of this document.

### Motivation

To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s).

### Specification

As per associated EIPs's specifications and implementations, and success determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency).

### Rationale

Interoperability: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (eg. ETH and ETC).

On Immutability: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding invalid opcode) would now be assigned a meaning, and thus could generate or return a value other than invalid. In essence, this means "making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract. In counterargument to this concern are two critical points:
1. account states remain changed
2. the "Homestead" hardfork established a precedent for this type of change, having introduced the DELEGATECALL opcode at block 1,150,000.

With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting protocol upgrades (eg soft- and hard-forks), it follows that the definition of Immutability is not extended to guarantee perfect consistency for future behavior of historical account states, but only to only to guarantee the immutability of the account states themselves.

### Implementation

Adoption of the content of this ECIP requires a hard fork, and herein that adoption is proposed to be scheduled for block 7,100,000, roughly estimated to arrive in January 2019.

The ethereumproject/go-ethereum client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the v5.5.0 release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol).

### History

##### Byzantium changes

These changes were introduced in the Ethereum Foundation go-ethereum client via the 1.7 "Megara" release.

These changes were catalogued via the EIP process in the following:
- EIP-658: Transaction receipts embedding status code instead of intermediate state root field - https://github.com/ethereum/EIPs/pull/658
- EIP-140: REVERT - https://github.com/ethereum/EIPs/pull/206/files
The REVERT instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.
- EIP-211: RETURNDATASIZE, RETURNDATACOPY - https://github.com/ethereum/EIPs/pull/211/files
A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.
- EIP-214: STATICCALL - https://github.com/ethereum/EIPs/pull/214/files
To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).
- EIP-198: Precompiled contract for modular exponentiation - https://github.com/ethereum/EIPs/pull/198
- EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212
- EIP-213: Precompiled contract for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213

##### Constantinople changes

These changes are expected to be implemented by the anticipated Constantinople hard fork, which may take place on the ETH network sometime near October 30, 2018, although to date no block number configuration has been accepted to the master branch of the ethereum/go-ethereum client.
- EIP-215:(replacing EIP-145) (https://github.com/ethereum/EIPs/pull/215): Introduce bitwise shifting
To provide native bitwise shifting with cost on par with other arithmetic operations.
- EIP-1014 (https://github.com/ethereum/EIPs/pull/1247): Use keccak256 name instead of sha3 (CREATE2)
Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memorystart, memorylength, salt. Behaves identically to CREATE, except using keccak256(msg.sender ++ salt ++ initcode)[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
- EIP-1052 (https://github.com/ethereum/EIPs/pull/1052): EXTCODEHASH opcode
Returns the keccak256 hash of a contract's code

# Abstract

Use a heuristic of chain state capitalization as a 2nd-dimension factor in consensus arbitration to improve normal finality rates and increase the cost of abnormal private chain production.

# Motivation

## State Finality Is Low and Slow

This proposal intends to increase the cost of producing a private, competitive chain segment, which is characteristic of double-spend attacks. It aims to improve finality expectations by increasing the cost of attack, while maintaining existing assumptions and incentives associated with the incumbent proof-of-work protocol.

# Specification

This specification is defined as a modification of the general,[^1] currently existing canon-arbitration algorithm, namely "Modified GHOST," currently in use on the Ethereum and Ethereum Classic networks.

[^1]: Difficulty bomb and/or delay features are ignored.

## TABS: Total Active Balance Synthesis

Total Active Balance Synthesis (TABS) is a positive scalar integer. Generally considered, it provides a measure of currency capitalization over time for some chain state.

It is defined to approach the median aggregate balance of all transaction-originating accounts for a blockchain of some length. It is denominated in Wei.

TABS is a "synthetic" value derived from a "raw" Total Active Balance (TAB) value of any block and, recursively, the TABS value of its parent block, much like block difficulty and gas limit.

### TAB: Total Active Balance

The TAB value of a block is the sum of the balances (at the parent block state) of all unique transaction senders in the current block.

Pseudo-code is provided as:

### TABS Adjustment Algorithm (Validation)

The TABS value is defined as follows.

A _minimum value K for TABS is defined as 128e18 Wei, equivalent to 128 Ether.

An adjustment denominator r is defined as 4096.

An adjustment numerator y is defined to be in the set [-1,0,1], where:
- y = -1 if TAB(B n ) n-1 )
- y = 0 if TAB(B n ) == TABS(B n-1 )
- y = 1 if TAB(B n ) > TABS(B n-1 )

From these definitions, the TABS algorithm for a block numbered n, written as TABS(B n ), is as follows:
- if TABS(B n-1 ) is undefined, then TABS(B n ) = K
- otherwise, TABS(B n ) = MAX(K, TABS(B n-1 ) + (y TABS(B n-1 ) // r))

Where // means floor division.

Pseudo-code is provided as:

This algorithm is expected to yield a value which approaches the blockchain's median TAB score.

## Consensus Score

The incumbent primary "consensus score" is total difficulty. This value is defined as the sum of block difficulties for all blocks in some segment, as:

This proposal modifies the consensus score attribution as:

In this context, this proposal changes the atomic block consensus score value from block difficulty to the multiplicative product of block difficulty and block TABS.

Like total difficulty, this value is still summed across a chain segment of any length to yield a total consensus score value.

With this syntax, both the current and proposed arbitration conditions are defined to prefer any chain state with the greatest "consensus score."

## Invariance of Adjacent Canon-Arbitration Conditions

Like the incumbent protocol's initial comparison condition on Total Difficulty, the comparison condition proposed to replace it (an abstracted "Consensus Score") can yield indecisive outcomes, or ties.

In the case of ties, subsequent protocol canon-arbitration conditions are preserved as invariants, namely (and in this order):
- lesser block height preferred (objective)
- selfish authorship preferred (subjective)
- random coin toss (subjective)

# Rationale

## Inversely Proportional Equilibrium Factors

PoW resilience against double-spend attacks depends on an assumption that no entity controls more than the "honest"/public network's hashrate over some time. So the respective difficulty values over time (eg. 44%/56%) are compared relative to an equilibrium value (50%/50%). Difficulty values over time in excess or deficiency of the equilbrium represent competitiveness; for good, or for evil.

The logic of this proposal depends on an additional assumption that no entity controls more than the network's TABS value in capital over some time. This is another equilibrium value.

These assumptions (ie. equilibrium values) factored together create a 2-dimensional equilibrium. An excess or shortfall in one variable inversely and proportionally slackens or raises the demand on the other in maintenance of the 2-dimensional equilibrium.

For example, while maintaining an equivalence in consensus scores, a relatively greater difficulty value lessens the demand on TABS.

## Conservative Adjustment Rate
An adjustment denominator r is defined as 4096.

An adjustment factor of 1/4096 is chosen relative to the incumbent minimum difficulty adjustment factor which is 1/2048, and represents an intentionally conservative impact on chain production race probabilities and incentives.

The potential rates of change for difficulty are greater (faster) in all cases than those of TABS.

For example, a block produced in the [1-8] second interval (2049/2048parent.difficulty) with a diminished TABS value (4095/4096parent.TABS) yields an equivalent overall consensus score (+1/4096) compared with a block produced in the next [9-17] second interval (2048/2048parent.difficulty) with an increased TABS value (4097/4096parent.TABS) yielding also a consensus score increase of a proportional +1/4096.

Further investigation and analysis is encouraged for alternative adjustment rates, eg. 128.

## PoW Race Incentives and Equilibrium

The viability of a PoW-based network depends vitally on the competitiveness and fairness of the PoW race. Linearity (actually sublinearity) here is the goal; 1 GPU : 1 vote/gamble/point/token/whatever.

Upon the availability of a potentially canonical block to some miner, they have two strategies: ORPHAN or ADOPT. Because we assume that greed is a reliable and optimal strategy, the miner should choose the more probably profitable option. To ORPHAN the proposed block means they continue work toward a competitive sibling block. To ADOPT means they begin work toward a child block.

If their balance is insufficient to beat the TABS of the announced block, clearly the incentives of the incumbent PoW race are preserved as invariant and the miner chooses to ADOPT. This covers about 50\% of the cases.

If their balance is sufficient to beat the TABS of the announced block, how do they model their probabilities for the ORPHAN or ADOPT strategies?

Since their expected TABS consensus score is differentially, at most, +1/4096 of the proposed block, they can still achieve probabilistic equilibrium with the incumbent race given only 4095/4096 of the otherwise necessary hashrate (representing the likelihood of their PoW solution discovery).

So, unless the miner has "50%" + epsilon 4095/4096 = 49.9878% + epsilon of the hashrate, the best strategy is still to ADOPT.

### A Deeper Dive into Block Distribution vs. Capital Distribution

As above, the viability of the game on which the network's state depends is hinged on the relationship of invested capital share to an expected and realized share in canonical block production.

Empirically we are lead to believe that the distribution of Ethereum and Ethereum Classic's mining interests are long tail-type curves. A few interests control the majority share, with the democratic majority sharing the leftovers.

What would the TABS capital share distribution be?

Lets assume that, like most things, it won't be distributed evenly, and that "the rich get richer" is at least a working guideline for now.

The next question in expectation becomes whether the rich in computational capital are also those rich in currency capital. One line of reason suggests yes. After all, computational capital earns revenue in currency capital. And you need a lot of (generic) currency to pay for a lot of rigs in the first place. But miners have their costs, too. And the market for currency capital is independent from mining rigs, highly speculative already, and, compared to the mining rig market, highly liquid.

Another variable we need to build context with is the share of miner-exclusive ("private") capital relative to network-available ("public") capital. If public capital dwarfs private currency capital, then the role of private capital diminishes against an assumed randomness inherent in the aggregated public balance.

Plots are provided below comparing views in this light for Ethereum and Ethereum Classic.

## Short-Term Finality Rate Increases

The rate of the network's production of orphan blocks (sometimes recorded as uncles) is expected to drop because the expected rate of objectively decidable (non-tie, "asymmetric") block competitions is expected to rise by around 50\%.[^4] The precise value of this expecation depends on the distribution of miner-available capital rates relative to the distribution of miner hashrates.

[^4]: This assumes that the aggregated balances represented in TABS are not constant. If a TABS value (and the transaction-originating balances that compose it) is held constant, then the finality characteristics of the production race imitate pure-PoW exactly.

Lessening the production rate of non-canonical blocks is, by definition, an increase in expected network state finality.

## Median-Seeking Adjustment Algorithm

The proposed algorithm "synthesizing" TABS is an implementation of a median-seeking algorithm.

From this, and by definition, we expect that eventually for some set of blocks, roughly half will have TAB values above, and half below the resulting TABS value. However, since the block authorship per miner is not equally distributed, the TABS score will be weighted more heavily toward more prolific miners. The scale of this weighting will depend on the ratio of the aggregate balance of public transactions relative to any balance represented exclusively by some miner.

Further investigation and analysis is encouraged for alternative adjustment algorithms, eg. moving averages, sequential weights.[^3]

[^3]: Another idea uses a count of sequential TABS drops (number of consecutive falling adjustments) to cause the TABS value to fall faster_ when it is only (or usually) falling.

## Block Space Opportunity Cost for Miners

Miners can include "local" transactions on their own behalf at no currency cost, but at the opportunity cost of the inclusion of a revenue-generating transaction.[^2]

[^2]: :dragon: This changes with EIP-1559 or other transaction burn-fee schemes.

Miner participation in the TABS competition is expected, since expected block revenues are driven, in part, by the competitiveness of the capital they represent on their own behalf.

Since a miner can and should (optimally) represent their self-interested capital as a single transaction in the blocks they mine, they are expected to at least sometimes cannibalize one balance-transfer transaction's worth of block space (the minimum, currently 21,000 / ~10,000,000 = 0.02%) in their own interest.

Miner-interest transactions can be inoperative. Miners don't have to actually send any balance to anyone. Just a signed transaction to themselves, for example, where they recoup the gas fee (as the credited coinbase) or charge themselves a zero gas price.

## Observable, Domain-Specific Competition Drives Security

Heuristics about PoW finality expectations depend on "off-chain" variables, like universally (on- and off-network) available applicable hashrate. For example, hashrate from another network, networks, or any other applicable technologic domain like computer gaming; the state of the art of the work itself; the applicable market(s) for electricity, etc.

Unlike fuzzy estimates about (potentially) globally available hashrate relative to the PoW network in question, all of the functional TABS protocol parameters are observable as on-chain values, namely balance distribution and overall currency supply.

## Soft (But Important) Dependence on Transaction/State Exclusivity

An adjacent proposal "AHA Typed Transactions" is listed as a dependency, which should be understood as an encouraged, prototypical mechanism for developing a way for transactions to be dependent on some chain state at the transactor's discretion, and in expectation that this chain state (presumed to be a public one) is different than any hypothetical private state.

The motivation for this is to encourage a difference of TAB values between public and private chain segments. Transactions which depend on a chain state exclusive to the public chain count differentially toward the aggregated public TABS value, which increases the cost of a double-spend attack.

However, this is not completely theoretically necessary.

Miners can include "local" transactions arbitrarily in blocks they mine (using existing and common APIs and clients). Transactions made in this way already meet the criteria for differentially exclusive transactions, albeit imperfectly, since their differential exclusivity ("locality") is limited to the pending block because the transactions, once published in the public chain state, become available to any competitor.

TLDR; theoretically, existing APIs for "local" transactions can sufficiently differentially benefit the public state, but can do so only to the differential magnitude of a single block, and, as such, are practically insufficient.

# Tests

## Simulation Programs

I have written a couple programs that I've used to simulate and observe chain production characteristics.
- go-miner-sim simulates PoW/TABS chain production in a multi-agent environment.
- go-block-step simulates an abstracted version of the block production race.

I would love review, feedback, and collaboration on these.

## Empirical Context

TAB and TABS value estimates can be derived retrospectively for Ethereum and Ethereum Classic chains.

At the time of writing, and with limited sample sizes, I estimate TABS values as follows.
- Ethereum's (ETH): ~500,000 ETH.
- Ethereum Classic's (ETC): ~5,000 ETC.

Further efforts toward current or retrospective analysis of real-life PoW chains, not limited to ETC, is welcome.

# Backwards Compatibility

A hard fork would be required.

# Known Vulnerabilities

## TABS Poisoning

An attacker could promote high-gas, low-balance transactions in the public pool, attempting to lessen the public TABS value for some time.

This strategy would be observable in real time by the public.

## Whales and Collusive Capital

An attacker could challenge the assumption that no entity controls more than the public TABS value for some time. The value of TABS relative to current supply and its account distribution informs this risk model.

This attack, like a pure-PoW double-spend attack, would be invisible until published.

### Simple Summary

Enable the outstanding Ethereum Foundation Istanbul network protocol
upgrades on the Ethereum Classic network in a hard-fork code-named
Tanchun to enable maximum compatibility across these networks.

In particular, enables account versioning EIP-1702 with
forward-compatible EVM changes.

### Abstract

Add support for a subset of protocol-impacting changes introduced in
the Ethereum Foundation (ETH) network via the Istanbul hardforks.

This document proposes the following blocks at which to implement
these changes in the Classic networks:
- TBD on Mordor Classic PoW-testnet (Feb 5th, 2020)
- TBD on Kotti Classic PoA-testnet (Feb 12th, 2020)
- TBD on Ethereum Classic PoW-mainnet (March 25th, 2020)

For more information on the opcodes and their respective EIPs and
implementations, please see the Specification section of this
document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various
opcodes shall be added to the Ethereum Classic networks, all of which
have been in use on the Ethereum Foundation networks since end of
2019. This hard fork first enables the Kunming hard fork
specification, and
then enables all Istanbul features on top of the forward-compatible
EVM.

### Specification

Enable
ECIP-1040. Freeze
features on version 0. Define a new account version 1, with the
following additional EIPs enabled:
- 39-UNGAS: Remove all
 observable behavior of gas cost in EVM and change out-of-gas
 exception to trap the whole transaction.
- 40-UNUSED: Disable deployment
 of unused opcodes.
- EIP-152: Add Blake2
 compression function F precompile
- EIP-1108: Reduce
 altbn128 precompile gas costs
- EIP-1344: Add ChainID
 opcode
- EIP-1884: Repricing for
 trie-size-dependent opcodes
- EIP-2028: Calldata gas
 cost reduction
- EIP-2200: Rebalance
 net-metered SSTORE gas cost with consideration of SLOAD gas cost
 change

### Implementation

Adoption of the content of this ECIP requires a hard fork as it
introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the
Istanbul features and ECIP-1040 / EIP-1702 currently:
- Parity Ethereum
- Multi-Geth

The following clients implement Istanbul_ features but does not yet
support ECIP-1040 / EIP-1702:
- Hyperledger Besu

No clients currently have implemented 39-UNGAS and 40-UNUSED yet.

## Copyright

This work is licensed under Apache License, Version
2.0.

### Abstract

Establishing Fork type ECIPs, and their standards and processes.

#### TL;DR

Make ECIPs with Type Fork a thing, where Fork ECIPs should follow this process:
- A "shell" Fork ECIP is opened, fitting the template provided named ecip-X-FORK.md (available in the repository root directory). This ECIP _does not initially include Activation Block Number or Features specifications.
- While in WIP or Draft status, one or more change sets are proposed against this document (eg. via Github Pull Requests) modifying BOTH Activation Block Number and Features specifications.
- ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive critique, etc...
- One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document, and status is moved to Last Call. By virtue of the process specification provided, a Fork ECIP achieving Last Call may not see Draft nor WIP status again (because doing so would require a merging a change set holding INCOMPLETE specification variables).

### Definition

Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or more Standards-Core track IP(s) at a specified activation block number.

#### Standards

Fork ECIPs should contain only placeholder information for ECIP-sets and block activation numbers while in WIP or Draft status.

Modification to any of Last Call, Accepted, or Final statuses should be accompanied by the introduction (merge) of a single change set containing COMPLETE and UNIQUE definitions of the placeholder values.

Change sets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither value in isolation; change sets modifying only ECIP-set values, or only block number values, are disallowed.

### Motivation

Fork ECIPs represent a single idea: The next hardfork the blockchain is expected to undergo. This is a pragmatic and common approach to managing blockchain protocol maintenance and upgrades.
Thus, it makes sense to use accessible and conceptually-unifying procedures for this challenge.
- Accessibility: Github provides an accessible user interface for viewing a Pull Request (proposed change set) against a single document.
- Legible and Communicable Reasoning: Requiring UNIQUE and COMPLETE change sets against against a Fork type ECIP demand presentation and consideration of proposed specifications as a whole.
- Sufficient specification: It is the job of Fork ECIPs to eventually provide precise and operable implementation specifications. Incomplete proposals (changesets) are inoperable; they are not ready for review, discussion, nor implementation. Any Fork ECIP lacking a COMPLETE feature set or block number is considered incomplete.
- Efficiency: Unique proposals save time and energy.

#### Historical motivations

Related to and derivative of:
- https://github.com/ethereumclassic/ECIPs/issues/217
- https://github.com/ethereumclassic/ECIPs/issues/215
- https://github.com/ethereumclassic/ECIPs/issues/175
- https://github.com/ethereumclassic/ECIPs/issues/131
- https://github.com/ethereumclassic/ECIPs/issues/177
- https://github.com/ethereumclassic/ECIPs/issues/135
- https://github.com/ethereumclassic/ECIPs/pull/218
- https://github.com/ethereumclassic/ECIPs/pull/212
- https://github.com/ethereumclassic/ECIPs/pull/207
- https://github.com/ethereumclassic/ECIPs/pull/214
- https://github.com/ethereumclassic/ECIPs/pull/199
- https://github.com/ethereumclassic/ECIPs/pull/196

### Specification

A Fork ECIP is defined as an ECIP specifying any (n >= 1) Standards-Core track IP or IP-set and a block activation number for this set. A Fork ECIP should be conceptually complete and unique (note that Next hardfork suffices for the existing preference for ECIP uniqueness, since it is intended that there only be one at a time -- hopefully!).

Complete is defined as being fully and totally definitive; not lacking anything.

Unique means not the same as another thing; in this case, not precisely duplicating any existing ECIP.

This proposal specifies that all Fork ECIPs in Draft state or earlier should contain NO information about ECIP-sets or block activation numbers (all TBD). Proposed specifications to fill these placeholders should be made in the form of distinct and separate propsed change sets (eg Github Pull Requests) to the Fork ECIP document. The changesets are required to be UNIQUE and COMPLETE.

There might be an ecip-X-FORK.md file that would look something like this:

### Rationale

The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of n >= 1 Standards-Core type IPs containing protocol-facing changes. The document says "These features will activate at this moment."
0. "Shell" format Fork ECIPs represent a clear, albeit abstract, idea: One or many blockchains' next hard fork (eg. chains Ethereum Classic, Morden, Kotti).
1. Demanding fully-formed Fork ECIP Changeset proposal forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes. A Fork ECIP Changeset may represent a plurality of features, and so in order to be an operable specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. The intention of this specification is make these logical steps as explicit and document and accessible as possible, in order that good decisions can be made with a process of open and constructive collaboration, enabled by named and concrete options.
2. Fork ECIP Changesets without block numbers lack operability. Activation numbers are specifications and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation.
3. Concrete things are easier to build language and reasoning around. Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group and_ individual decision making. "Competing" Fork ECIP Changeset alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes.

#### Alternatives considered

Use distinct UNIQUE and COMPLETE ECIPs to describe fork specification options.

However, allowing fully-formed alternative and "competing" ECIPs is logistically and practically difficult to use.
Currently, our most prominently used collaboration tool, Github, does not provide an accessible UI for comparing arbitrary documents or review separate arbitrary documents as a conceptual set.

### Implementation

A Fork ECIP should achieve Last Call as a change set has been successfully merged. Conversely, a Fork ECIP with non-empty specifications may not see Draft or WIP status; it may only otherwise be Final, Withdrawn, or Rejected.

This proposed procedure makes only marginal conceptual changes to existing practices, demanding only that what was taken as implication, subtext, or context before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Fork ECIP specification outcomes to assume fully qualified and standardized formats before becoming eligible for consideration.

### Copyright/Licensing

MIT.

EIP-223 on Ethereum project: https://github.com/ethereum/EIPs/issues/223

## Abstract

The following describes standard functions a token contract and contract working with specified token can implement to prevent accidentally sends of tokens to contracts and make token transactions behave like ether transactions.

## Motivation

Two problems of ERC20 that ERC23 will solve:
1. When you are sending tokens receiver will never know that transaction appears. Addresses don't care about it while contracts my need to handle transactions.
2. Tokens could be sent to another contract address where would not be accessible anymore.

Those will allow dapps and wallets to handle incoming token transactions and prevent accidentally sent tokens from being accepted by contracts.
For example decentralized exchange will no more need to force users to call approve at token contract then call deposit that is calling transferFrom taking allowed tokens. Token transaction will automatically be handled inside the exchange contract.

The most important here are, transferToContract and fallbackToken.

## Specification

Token
Contracts that work with tokens

## Methods

NOTE: An important point is that contract developers should handle fallbackToken like fallback for ether transactions if they wish their contracts to work with specified tokens.

## Token contract methods
isContract

function isContract(address addr) private returns (bool iscontract)
private function that assembles extcodesize(addr) and returns true if code size is greater than 0. It's needed to choose which function to use transferToAddress or transferToContract depending on is the reveiver a contract or not.

transferToContract

function transferToContract(address to, uint value) private returns (bool success)
private function that transfers tokens from msg.sender to to then trying to call fallbackToken(msg.sender, value) at to.

transferToAddress

function transferToAddress(address to, uint value) private returns (bool success)
private function similar to base ERC20 transfer

transfer

function transfer(address to, uint value) returns (bool success)
function that is always called when someone wants to transfer tokens. Calls transferToAddress or transferToContract depending on is the reveiver an address or a contract.

## Contract to work with tokens

supportedTokens

mapping (address => bool) supportedTokens;
Mapping of addresses of token contracts that are supported.

addToken

function addToken(address token)
Allows a token contract address to work with.

removeToken

function removeToken(address token)
Makes a given token contract address no more allowed to work with.

function fallbackToken(address from, uint value)
A function to handle token transfers that is called from token contract when token holder is sending tokens. from is a token holder and value is amount of incoming tokens. Works like fallback function for Ether transactions.

# Abstract

This document describes the implementation of the VeriBlock Proof-of-Proof (“PoP”) consensus protocol on the Ethereum Classic blockchain for the prevention of 51% attacks. PoP reinforces Ethereum Classic’s existing Proof-of-Work protocol by allowing it to inherit the full Proof-of-Work security of Bitcoin in an entirely Decentralized, Trustless, Transparent, and Permissionless manner.

PoP introduces a new form of mining (“PoP mining”) which rewards PoP miners for publishing headers from a security-inheriting blockchain to a security-providing blockchain, allowing the security-inheriting blockchain to reference these publications in the event that a 51% attack is attempted.

With PoP implemented, the VeriBlock Bitcoin Finality Indicator (“vBFI”) provides blocks (and thus, transactions) on the Ethereum Classic network with Bitcoin confirmations as well as regular confirmations. Ethereum Classic transactions with at least one Bitcoin confirmation would be mathematically impossible to double-spend or otherwise reverse without performing a reorganization of the Bitcoin blockchain itself.

Additionally, PoP provides a mechanism for transaction offloading which allows transactions to be processed on the Ethereum Classic blockchain even when a majority ETC hashrate adversary is exerting complete censorship over Ethereum Classic blocks.

# Motivation
Ethereum Classic has suffered several high-profile 51% attacks which resulted in the theft of millions of dollars of funds from exchanges. Furthermore, several styles of 51% attacks can exploit many types of vulnerabilities in applications/protocols built on top of a smart-contract platform.
There are two types of 51% attacks which pose risks to smart contract applications and protocols:
1. Surprise 51% attacks where an attacker controlling the majority of the hashrate builds a large chain in private and releases it to the network, causing a long-range reorganization of the blockchain (overwriting hours, days, or weeks of blockchain history)
2. Real-time censorship 51% attacks, where an attacker controlling the majority of the hashrate only builds on top of blocks that they agree with all of the contents of and controls the content of all blocks they mine, and releases blocks as soon as they mine them

51% attacks do not only allow for the theft of funds through double-spend attacks; more sophisticated attacks can leverage long-range blockchain reorganizations and/or censorship attacks to:
1. Time-out payment channels or force the redemption of old payment channel states (and more generally, selectively censor time-sensitive interactions with smart contracts resulting in the triggering of default/refund behavior or punishment of the "unresponsive" party who was censored)
resulting in the triggering of default/refund behavior or punishment of the “unresponsive” party who was censored)
2. Desynchronize 1:1 pegs of cross-chain assets and artificially inflate their supply
3. Retroactively insert bets and take positions on oracle-driven betting platforms and prediction markets
4. Roll back decentralized exchanges and other DeFi applications based on external market forces and take advantage of favorable pricing or trade opportunities
5. Manipulate contract governance by censoring votes (ex: “steal” funds from DAOs by allocating them to parties which aren’t actually approved by the majority of the DAO’s ownership, inject malicious “upgrades” to upgradeable protocols, etc.)
6. Perform any other exploits that rely on censoring interaction with a smart contract or retroactively interacting with a smart contract in a particular fashion with “future” information

These potential 51% attack exploits do not only threaten exchanges and merchants accepting ETC as a payment mechanism, **but also dissuade from the deployment of smart contract protocols and applications on Ethereum Classic because of the attack vectors long-range reorganizations and/or censorship attacks pose to their security and reliability.

All of the successful 51% attacks against Ethereum Classic thus far have fallen into the first category (surprise long-range reorganizations); these long-range reorganizations are what make double-spends against services like exchanges possible. However, the second type of attack can be used in other exploits and can still be exploited when only protections against long-range attacks are implemented (such as max reorg distance, which also opens an attack vector for permanent irreconcilable network splits).

This proposal includes a solution for both types of attacks: preventing surprise long-range reorganizations and preventing a majority hashrate operator from exerting complete censorship even while publishing blocks to the network as the blocks are found.

Additionally, this proposal exposes the presence(/absence) of Bitcoin finality for a particular block as an opcode, enabling smart contracts to execute certain actions only when certain blocks (or transactions) reach a certain level of Bitcoin finality.

# Specification
## Data Structures

 VTB

 ATV

 VBKPoPDatastore

## Overview
When integrated into Ethereum Classic, VeriBlock Proof-of-Proof will function by creating a new class of miner on the Ethereum Classic network (an Ethereum Classic Proof-of-Proof miner) who is rewarded for publishing endorsements of Ethereum Classic blocks in the VeriBlock blockchain.

The VeriBlock network itself is secured using the Proof-of-Proof protocol to the Bitcoin blockchain using a similar mechanism (Proof-of-Proof miners on the VeriBlock network publish endorsements of VeriBlock blocks to Bitcoin).

Proof-of-Proof miners on the Ethereum Classic blockchain spend VeriBlock coins (VBK) to publish Ethereum Classic block headers (and accompanying context data which introduces a braided block reference pattern to the Ethereum Classic blockchain) to the VeriBlock blockchain.

Similarly, on the VeriBlock blockchain, VeriBlock Proof-of-Proof miners spend Bitcoin (BTC) to publish VeriBlock block headers to the Bitcoin blockchain.

As a result, the VeriBlock blockchain inherits Bitcoin PoW security to protect against double-spend attacks, and the Ethereum Classic blockchain inherits Bitcoin + VeriBlock PoW security to protect against double-spend attacks.

The protection against long-range reorganizations that Proof-of-Proof functions because Proof-of-Proof-enabled blockchains modify their fork resolution protocol to consult publications of both alternative chains to determine the canonical chain. As a result, an attacker who wants to cause a surprise reorganization in a Proof-of-Proof-secured blockchain has to announce their attack “in-step” with the main chain by publishing fingerprints of their attacking chain in a timely manner. These publications can be seen by any Ethereum Classic network participant by looking at the VeriBlock and Bitcoin blockchains.

As a practical example, with the recent 51% attacks against Ethereum Classic, if Proof-of-Proof were implemented the attacker would have to publish fingerprints of their attacking chain to VeriBlock “in-step” with the main chain, so long before the attack occurred it would have been publicly known at what block height the attacker’s ETC fork started, and whether the attack were still a potential threat. In the absence of an active attack (or the abandonment of a previously active attack), blocks (and thus, transactions) on the Ethereum Classic network would have reached Bitcoin finality which provides a mathematical guarantee that the block (and its containing transactions) could not be reversed without performing a 51% attack on Bitcoin itself.

Normally when a security-inheriting chain has no competing publications in the security-providing chain, blocks on the network achieve spFinality (mathematical certainty that the block cannot be reverted/overwritten without also 51% attacking the security-providing blockchain) like so:

In the event that a competing security-inheriting blockchain is also published to the security-providing blockchain in a timely manner:

And when the attacking chain is eventually abandoned, the main security inheriting chain will begin getting spFinality because of the attacking chain abandonment:

The implementation of Proof-of-Proof on the Ethereum Classic blockchain requires small modifications to:
- Block reward generation and validation code (to add additional beneficiaries to receive Proof-of-Proof payouts)
- Ethereum Classic block structure (to add in Proof-of-Proof data about the Bitcoin and VeriBlock blockchains, and publications of Ethereum Classic block headers)
- Fork resolution protocol (to consult publications of Ethereum Classic on VeriBlock and Bitcoin blockchains)
- P2P messaging protocol (to add commands which communicate ATV, VTB, and VBK block data)
- EVM (updated Opcode to expose Bitcoin finality)

Much of the functionality for validating and processing VeriBlock-related data, keeping track of the VeriBlock and Bitcoin blockchain state, and performing fork resolution is already implemented as part of a pre-built altchain integration library which is a C++ library designed to be called from any language. The changes to Ethereum Classic to implement Proof-of-Proof leverage this existing library, minimizing the amount of functionality which must be implemented in the Ethereum Classic codebase itself.
VeriBlock Proof-of-Proof requires the determination of several parameters, which are selected based on the block time and block variability of the network, and size of rewards intended for payout to Proof-of-Proof miners.

The exact values of these parameters must be the result of public community discussion and consensus.

Additional details for what these parameters do and how they should be selected is available in the VeriBlock whitepaper.

Reasoning: Ethereum Classic’s ~15 second block time would make a keystone period occur once every ~10 minutes

Reasoning: With a keystoneInterval of 40, this allows for a publication of a keystone itself or the block immediately following to provide context for 20 minutes of ETC, and for a publication of any other block to provide context for 10 minutes of ETC.

Reasoning: This allows approximately four hours of Ethereum Classic blocks for endorsements to be returned to the chain

Reasoning: 1.25x the popRewardSettlementInterval

where pubTime is the relative timeliness of the publication and amnesty is 40 VeriBlock blocks, and where the function returns 0 when pubTime > keystoneFinalityDelay

Reasoning: The 20-VBK-block amnesty time is approximately 20 minutes or 80 ETC blocks long, meaning that an attacker would have to produce ETC blocks at a significantly faster rate than the main network to begin getting a PoP fork resolution advantage.

## Block Reward Generation and Validation Code
Normally, Ethereum Classic pays out a block reward to a block’s beneficiary according to an emissions schedule. Integrating Proof-of-Proof will add additional payouts to Proof-of-Proof miners who secure the Ethereum Classic network.

These payouts will be calculated based on proofs Ethereum Classic PoP miners return to the Ethereum Classic network that prove they published Ethereum Classic blocks to the VeriBlock blockchain.

The exact reward algorithm and magnitude of rewards need to be determined based on community discussions and consensus, however the reward algorithm should have the following properties:
1. Ethereum Classic PoP miners are incentivized to publish Ethereum Classic block endorsements as quickly as possible to the VeriBlock blockchain to optimize the speed at which the Ethereum Classic blockchain reaches Bitcoin finality for particular blocks
2. Rewards are sufficiently large such that a sufficient number of PoP miners are incentivized to participate in PoP mining in a variety of VeriBlock fee market scenarios
3. The reward calculation introduces predictable and cyclic “jitter” for robust handling of different VeriBlock fee market scenarios

The PoP rewards paid out in a particular block are calculated using the popPayoutRewardCurves to be determined by the Etherum Classic community consensus, and will be based on the total number and relative timelinesses of the publications of endorsements of the block for which rewards are being paid out (block x pays out PoP rewards for endorsements of block x – popRewardPaymentDelay), and the recent publication quantities and timelinesses of blocks prior to block x. The exact weighting of past scores (the PoP difficulty) will be determined as part of the determination of popPayoutRewardCurves.

The functionality for calculating rewards based on publication timeliness is implemented by the C++ altchain integration library, which will handle tracking all of the endorsements of each Ethereum Classic block, calculating their relative publication timelinesses, and calculating the PoP difficulty based on publications of blocks prior to the one targeted by a particular reward calculation.

The Ethereum Classic blockchain code responsible for generating prototype blocks for mining needs to call the altchain integration C++ library to acquire the correct PoP reward payouts, and include these PoP reward payouts in the block (see the “popPayouts” section added to the Ethereum Classic block format in the Block Structure Modification section) in the order that they are returned from the library in, discarding any that don’t have a valid Ethereum Classic address as a payout destination. Additionally, the code which gathers transactions to include in a block must be further modified to query the altchain integration C++ library’s built-in mempool of ATV, VTB, and VeriBlock header information to determine which ATVs, VTBs, and VeriBlock headers should be included in the block, and to add those data structures to the prototype block, updating the contentRoot accordingly.

The Ethereum Classic blockchain code responsible for validating new blocks received from the network needs to call the altchain integration C++ library to acquire the correct PoP reward payouts when processing a particular Ethereum Classic block, and ensure that the returned PoP reward payouts match those returned from the library, less any that don’t have a valid Ethereum Classic address as a payout destination. If the calculated payouts don’t match the ones included in the block, then the block must be rejected as invalid (similar to if the block contained an invalid transaction).

The Ethereum Classic blockchain code responsible for paying out the Proof-of-Work reward to the beneficiary miner needs to be updated to also perform the respective payouts to all addresses contained in the PoP payout for the block being processed.

Additionally, the Ethereum Classic blockchain code responsible for processing blocks needs to pass VTB, ATV, and VeriBlock header data stored in the updated Ethereum Classic block structure (see the Block Structure Modification section) to the integration library, and ensure that the return values of the calls to the integration library don’t indicate a failure. If a failure is encountered, the block must be treated invalid (similar to if the Ethereum Classic block contained an invalid transaction).

Furthermore, the code needs to be updated to check that the VBKPoPDatastoreSlice associated with each VBKBlock either:
1. Proves a mapping of altchainTxOffloadIdentifier to one or more potential offloaded Ethereum Classic transactions
2. Proves two mappings of unrecognized altchain Tx identifiers which are contiguous given their Merkle path indexes and which are smaller and larger (respectively) than altchainTxOffloadIdentifier, proving that the VBK block contains no potential offloaded Ethereum Classic transactions

Finally, the Ethereum Classic blockchain code responsible for processing block transactions needs to be updated to attempt to process all transactions associated with the altchainTxOffloadIdentifier directly after processing the regular transactions in the Ethereum Classic block. If any of the transactions are invalid (formatted incorrectly, not signed or signed incorrectly, spends ETC that an address does not have, contains an invalid opcode, etc.) then the transaction must be ignored (but the Ethereum Classic block being processed MUST NOT be marked invalid as would be the case if a normal transaction in the block was invalid).

## Block Structure Modification
Blocks on the Ethereum Classic blockchain must have three data sections added to it to store data returned from PoP miners (which allows the blockchain to properly reward PoP miners as well as reference PoP data during fork resolution to protect against 51% attacks), and an additional data section added to it to store PoP payouts paid out to PoP miners in the block. Additionally, the blocks will be modified to cryptographically authenticate these data sections, as well as to cryptographically authenticate a new data structure which contains references to previous Ethereum Classic blocks (creating a braided reference pattern) to provide publication continuity without requiring the publication of all Ethereum Classic blocks to VeriBlock.

The following additional fields will be added to Ethereum Classic blocks:

The vbkHeaders vector entries will be added in the order they appear in the vector to a Keccak-256-based Merkle tree, and the top-level hash of this tree will be termed the vbkHeadersRoot.

The vtbs vector entries will be added in the order they appear in the vector to a Keccak-256-based Merkle tree, and the top-level hash of this tree will be termed the vtbsRoot.

The atvs vector entries will be added in the order they appear in the vector to a Keccak-256-based Merkle tree, and the top-level hash of this tree will be termed the atvsRoot.

The popPayouts entries will be added in the order they appear in the vector to a Keccak-256-based Merkle tree, and the top-level hash of this tree will be termed the popRewardsRoot.

The vbkHeadersRoot, vtbsRoot, atvsRoot, and popRewardsRoot will be added in that order to a Keeccak-256-based Merkle tree, and the top-level hash of this tree will be termed the popDataRoot.

The popDataRoot and the Keccak-256 hash of the two uint256 values constituting the previousKeystones vector (serialized as a single uint512 value and with the serialization order of the previousKeystones elements based on their order in the vector) will be added to a Keccak-256-based Merkle tree, and the top-level hash of this tree will be termed the popTopRoot.

The transactionsRoot (calculation unchanged from standard Ethereum Classic) and the popTopRoot will be added in that order to a Keccak-256-based Merkle tree, and the top-level hash of this tree will be termed the contentRoot.

This contentRoot will replace the transactionsRoot in the block header of Ethereum Classic blocks:

Adding the popTopRoot to the right of the transactionsRoot allows maximal compatibility with existing software by making the indexes of transactions in the Ethereum Classic block’s transaction tree stay the same as before, and only requiring the addition of the popTopRoot in the Merkle path to authenticate transactions against the root in the header.

## Fork Resolution Modification
The Ethereum Classic blockchain code which determines whether a reorganization should occur upon receipt of a non-mainchain block needs to be updated to consult the altchain integration C++ library to determine whether the blockchain should be reorganized based on Proof-of-Proof data.

## P2P Message Protocol Modification
The Ethereum Classic blockchain code which handles sending and receiving P2P messages needs to be introduced to add new P2P commands:

ATV atv or
VBKHeader vbkHeader

Additionally, the anti-DoS portion of the P2P code should penalize (and eventually ban/disconnect from) peers who:
1. Send PoPOffers with hashes and then don’t respond with a valid PoPSend when a corresponding PoPGet is sent by the local node (or sends invalid data in response to the PoPGet, invalidity determined by a failure when attempting to add the received data structure to the altchain integration C++ library PoP data mempool)
2. Send PoPGets for hashes which the local node never sent a PoPOffer advertising
3. Sends PoPSends for VTBs, ATVs, or VBKHeaders which the local node never sent a PoPGet requesting

The code which handles receiving P2P commands must call the altchain integration C++ library and add the received VTB, ATV, or VBKHeaders to the altchain integration C++ library’s PoP data mempool (so that the data can be eventually incorporated into the Ethereum Classic blockchain by miners).

## EVM Modification

The EVM must have an additional opcode BITCOINFINALITY implemented, which exposes the Bitcoin finality of an Ethereum Classic block (identified by block number on the current active chain).

This opcode allows smart contracts to be aware of the finality of a block (and thus, the transactions in it and the state modifications that those transactions result in). Smart contracts could use this opcode to only execute certain functions once a certain threshold of Bitcoin finality is reached for a block which caused a previous state modification.

The opcode takes a single argument from the top of the stack (a block index, where the genesis block’s block index is 0), and pushes a single value indicating the Bitcoin finality of that Ethereum Classic block (if it exists) to the top of the stack**. If the block index is a block which does not exist, then the Bitcoin finality will be 0. The Bitcoin finality value will be 0 to indicate no Bitcoin finality, or a positive integer to indicate a number of Bitcoin blocks providing finality for the particular Ethereum Classic block.

The BITCOINFINALITY opcode functions internally by:
1. Determining whether a block at the provided index exists (if not, push 0 to the stack and exit)
2. Acquiring the hash of the block at the provided index (note that the 256-block limit of the existing BLOCKHASH opcode is to small for this query, so this query must be done without using functionality from the BLOCKHASH opcode)
3. Querying the altchain integration C++ library to determine the Bitcoin finality of the particular Ethereum Classic block hash, pushing the returned value onto the EVM stack
The numerical opcode which identifies BITCOINFINALITY will be chosen by community consensus such that it doesn’t collide with any other proposals for opcodes in Ethereum Classic or Ethereum.

The numerical opcode which identifies BITCOINFINALITY will be chosen by community consensus such that it doesn’t collide with any other proposals for opcodes in Ethereum Classic or Ethereum.

# Rationale
Integrating VeriBlock Proof-of-Proof into Ethereum Classic allows Ethereum Classic to prevent both types of 51% attacks (surprise long-range reorganizations and censorship attacks) by inheriting the Proof-of-Work security of Bitcoin. Blocks (and thus transactions) on Ethereum Classic would receive Bitcoin confirmations as well as standard Ethereum Classic confirmations, and as soon as transactions on Ethereum Classic achieve a nonzero number of Bitcoin confirmations, they can be accepted with the same (technically higher) security as transactions on Bitcoin.

Proof-of-Proof takes the guesswork out of transaction security, allowing ecosystem participants to accept transactions as finalized with the full security guarantees of Bitcoin’s Proof-of-Work.

Additionally, the anti-censorship capabilities that VeriBlock introduces through transaction offloading protect applications and protocols deployed on Ethereum Classic from many other sophisticated attacks from forcibly redeeming old payment channel states to desynchronizing 1:1 asset pairs to censoring voting mechanisms in decentralized governance systems.

Proof-of-Proof doesn’t replace Ethereum Classic’s existing Proof-of-Work algorithm but provides reinforcement of it based on Bitcoin, and doesn’t introduce any centralized system or modify the blockchain’s governance system (adoption of hard forks, etc. is still done by consensus amongst PoW miners).

Adjustments can be made to how Proof-of-Proof is integrated into Ethereum Classic based on tradeoffs between backwards compatibility with existing software, ease of implementation, data size, and tolerable levels of introduced complexity. As well, some parts of the VeriBlock integration can be skipped; the transaction offloading system that provides protection against 51% censorship attacks could be removed while still integrating Proof-of-Proof to provide security against surprise long-range reorganizations, and the integration of the BITCOINFINALITY opcode can be skipped to reduce the amount of data required to be stored directly on-chain (versus acquired by only nodes wanting to access Bitcoin finality statistics) if desired.

## Copyright

This work is licensed under Apache License, Version
2.0.

### Work in Progress

 Work in progress (WIP) -- An ECIP where the author has asked the Ethereum Classic community whether an idea has any chance of support, he/she will write a draft ECIP as a pull request. However, if the idea is still in a very early stage, and will have a lot of commits and changes by the author, editors or contributors, it may be better to enter it as a WIP. Make sure to add [WIP] in the title (example: [WIP] ECIP-X) of the early stage ECIP so other members can mute it if they are not interested in participating at this stage.

Read more about Ethereum Classic Improvement Proposals (ECIPs) at https://github.com/ethereumclassic/ECIPs and ECIP-1000.

### Abstract

Taking after Core Dev Call 18, ETC Cooperative wants to test forking Ethereum Classic Mainnet into a separate network to test Keccak256 mining and the transition process between ETChash and Keccak256 mining and vice versa.

### Copyright / Licensing

Copyright and related rights waived via CC0.

### Specification
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.
- ETC Cooperative wants to select a block of ETC mainnet and take all account information, sent to a separate network.
- The network must have a different chain_id.
- The network must allow to change the Proof of Work algorithm in use.
- It should be possible to change the Proof of Work algorithm back and forth between ETChash and Keccak256.
- TBD whether the change should be cyclical or on demand.

### Motivation
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

ETC Cooperative is testing a situation where we transition across Proof of Work algorithms and require something that looks as close as possible as the real thing.

### Rationale
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

ETC Cooperative wants to make sure we can easily change between Proof of Work algorithms. In particular, we want to make sure we can adjust difficulty faster during the adjustment period of the algorithm.

### Backwards compatibility
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

### Reference implementation
ECIP Editor Note: Please update section to ECIP-1000 standards.

Work in Progress.

### Simple Summary

Enable the outstanding Ethereum Foundation Istanbul network protocol
upgrades on the Ethereum Classic network in a hard-fork code-named
Xichun to enable maximum compatibility across these networks.

In particular, enables account versioning EIP-1702.

### Abstract

Add support for a subset of protocol-impacting changes introduced in
the Ethereum Foundation (ETH) network via the Istanbul hardforks.

This document proposes the following blocks at which to implement
these changes in the Classic networks:
- TBD on Mordor Classic PoW-testnet (Feb 5th, 2020)
- TBD on Kotti Classic PoA-testnet (Feb 12th, 2020)
- TBD on Ethereum Classic PoW-mainnet (March 25th, 2020)

For more information on the opcodes and their respective EIPs and
implementations, please see the Specification section of this
document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various
opcodes shall be added to the Ethereum Classic networks, all of which
have been in use on the Ethereum Foundation networks since end of
2019. This enables all Istanbul features, feature gated under ECIP-1702 /
EIP-1702.

### Specification

Enable
ECIP-1040. Freeze
features on version 0. Define a new account version 1, with the
following additional EIPs enabled:
- EIP-152: Add Blake2
 compression function F precompile
- EIP-1108: Reduce
 altbn128 precompile gas costs
- EIP-1344: Add ChainID
 opcode
- EIP-1884: Repricing for
 trie-size-dependent opcodes
- EIP-2028: Calldata gas
 cost reduction
- EIP-2200: Rebalance
 net-metered SSTORE gas cost with consideration of SLOAD gas cost
 change

### Implementation

Adoption of the content of this ECIP requires a hard fork as it
introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the
Istanbul features and ECIP-1040 / EIP-1702 currently:
- Parity Ethereum
- Multi-Geth

The following clients implement Istanbul_ features but does not yet
support ECIP-1040 / EIP-1702:
- Hyperledger Besu

## Copyright

This work is licensed under Apache License, Version
2.0.

### Simple Summary

Enable the outstanding Ethereum Foundation Istanbul network protocol
upgrades on the Ethereum Classic network in a hard-fork code-named
Yingchun to enable maximum compatibility across these networks.

In particular, delay EIP-1884 activation until backward compatibility
solutions are in place on Ethereum Classic.

### Abstract

Add support for a subset of protocol-impacting changes introduced in
the Ethereum Foundation (ETH) network via the Istanbul
hardforks.

This document proposes the following blocks at which to implement
these changes in the Classic networks:
- TBD on Mordor Classic PoW-testnet (Feb 5th, 2020)
- TBD on Kotti Classic PoA-testnet (Feb 12th, 2020)
- TBD on Ethereum Classic PoW-mainnet (March 25th, 2020)

For more information on the opcodes and their respective EIPs and
implementations, please see the Specification section of this
document.

### Motivation

To enhance the Ethereum Virtual Machine's (EVM) capabilities, various
opcodes shall be added to the Ethereum Classic networks, all of which
have been in use on the Ethereum Foundation networks since end of
2019. This enables all EIPs in Istanbul, but EIP-1884, due to backward
compatibility considerations.

### Specification

Enable the following EIPs at the hard fork block:
- EIP-152: Add Blake2
 compression function F precompile
- EIP-1108: Reduce
 altbn128 precompile gas costs
- EIP-1344: Add ChainID
 opcode
- EIP-2028: Calldata gas
 cost reduction
- EIP-2200: Rebalance
 net-metered SSTORE gas cost with consideration of SLOAD gas cost
 change

### Implementation

Adoption of the content of this ECIP requires a hard fork as it
introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the
Istanbul_ features currently:
- Parity Ethereum
- Multi-Geth
- Hyperledger Besu

## Copyright

This work is licensed under Apache License, Version
2.0.

Attribution: https://blog.ethereum.org/2015/07/30/ethereum-launches/

A few minutes ago, many of you generated and loaded the Ethereum Genesis block, marking the inception of Frontier, the first Live release of the Ethereum project.

The Dev team joins me in thanking each and everyone of you for your support during the past year and half. It’s incredible to see the progress that has taken place since that humble first commit on Christmas Eve 2013. The vision of a censorship-proof ‘world computer’ that anyone can program, paying exclusively for what they use and nothing more, is now a reality.

Many of you will want to get started immediately. Please check out our brand new website for instructions on how to install and run the clients. If you face issues, the first port of call should be our forums. For more detailed information as to what this release includes, please see my previous blog post.

To celebrate the release, we’ll leave you with this new intro video to our project. We hope you enjoy it, and we cannot wait to see what you will build on Ethereum!

Ethereum: the World Computer

Attribution: https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/

Here comes the first Frontier patch, and this is a big one!

Before you go further, if your keys date back from Go 1.0 rc or C++ 0.9.36, note that you should regenerate all of your keys NOW. Though some releases of the pre-alpha and alpha clients are secure, this depends on which codebase and which version. You should assume that all keys generated prior to these clients are insecure and compromised. This, note, does not affect the pre-sale wallets.

## Thawing

The thawing pull request has been merged for the Go client and the Master branch has been updated. If you’re still running branch release 1.0.0 please switch to Master.

As for the C++ users, they can also switch to master once merged, and binaries will be made available shortly. If you’d rather not update eth but still wish to help thaw the network, you can also just restart eth with an extra parameter of –gas-floor 3141592.

I thought that I’d also repost a quick explanation on how the gas limit targeting process operates, and why we cannot guarantee a time by which we’ll reach the 21K limit necessary to process one basic transaction per block.

Each miner runs a copy of geth or eth. In the Frontier Genesis release, both were set to target 5k and never deviate from that figure. Now, with this update, both clients will be updated to instead target 3M gas limit per block.

But they cannot switch to a 3M gas limit just like that, because the protocol forces them to climb slowly at a certain rate. That rate is equal to previous block limit / 1024. Now, assuming all miners update their clients, and none of them mess around with the settings, we’re going to reach 3M within 28h assuming a steady 15s block time including propagation. But here’s the thing - not all miners are going to update in time, some might forget and some might never update!

So, going forward, if a winning block is mined by a updated miner, the block limit will adjust upwards by the rate intended, but if it is mined by a ‘lazy’ miner who didn’t update, it will adjust back downwards (as the lazy miner is still targeting 5k).

For this reason, it will take a minimum of 6h to get to a 21K gas limit per block(1 trx per block), and a minimum of 28h to get to 3M. In practice, it will likely take considerably longer than that.

This is where the free market come into play. Technically, miners could even have colluded a few days ago to modify the client code and make the network behave rather differently than what we had in mind. We merely act as advisers to the community.

## Default, community chosen, Genesis block

The Genesis block we have seen adopted by the community has now been hardcoded in the clients, and you no longer need to specify the –genesis parameter to start eth or geth. That said, you can still specify a hand-crafted genesis block if you want to start a private chain with different genesis, for example.

## Bug fixes

On the Go client side, a series of bug fixes and improvement have been merged into 1.0.1, including readying ourselves for a Go 1.5 release.
- Fixed crash in chain manager #1568
- Log number fixes #1545
- Crypto fix for go 1.5 #1536
- Fix for ethcall and ethestimateGas #1534
- Console resend method fix #1461

On the C++ client, a full external audit has been carried out on its Key Store and cryptography. All actions recommended by our expert reviewers have been acted upon. Numerous optimizations and security improvements were added to the client:
- A unique C++ client feature is Secure Secrets: all heap memory used to store your secrets is securely overwritten immediately after it is finished
- The C++ client now relies upon boost::random_device, giving a cryptographically secure random-number generation
- Several crash and build fixes for AlethZero
- Enhancements to Alethzero, especially regarding account information
- The CLI tool ‘ethkey’ can now be used in concert with AlethZero to inspect and sign an otherwise unsigned transaction. This allows you to have a completely air-gapped cold-wallet-device

## Difficulty adjustment scheme

A lot of you have been wondering how we would implement a switch from PoW to PoS in time for Serenity. This will be handled by the newly introduced difficulty adjustment scheme, which elegantly guarantees a hard-fork point in the next 16 months.

It works as follow: starting from block 200,000 (very roughly 17 days from now), the difficulty will undergo an exponential increase which will only become noticeable in about a year. At that point (just around the release of the Serenity milestone), we’ll see a significant increase in difficulty which will start pushing the block resolution time upwards.

So, a year on, the network will continue to be useful for roughly 3-4 months, but eventually will reach an ‘Ice Age’ of sorts: the difficulty will simply be too high for anyone to find a block. This will allow us to introduce PoS, perhaps via Casper, if it proves itself.

Attribution: https://blog.ethereum.org/2016/02/29/homestead-release/

Development of Ethereum started in December 2013 when two developers and a college dropout researcher decided to put their heads together and develop this amazing piece of technology. We were later joined by many like-minded individuals. Our first Proof of Concept (PoC) came on February 1, 2014. By the time we started our crowdsale on July 23, we were up to PoC 5 with a protocol that was almost finished, and had achieved compatibility between multiple clients. The team was psyched when we got our first million and our second and our third and so on. It was crazy! Believing that we could deliver the Ethereum platform was one thing, but seeing others believe and want to participate it was incredibly inspiring.

Somewhat later in October of 2014, Gav and I were sitting on the train to the Zurich airport when we figured that an Ethereum conference would be absolutely awesome, and settled on doing it in November that same year. It was a bit hectic for those who organised it (thanks Aeron, Christian & Jason!), but we managed to pull it off as we were determined to host our first internal developers conference, DEVcon0.

When January 2015 came around, we all knew this would be the year we’d have to launch our beta version of Ethereum. Our PoC series was closed off with the PoC 9 hackathon on March 5th and on July 30, 2015 we successfully launched Frontier. Miners from all over the globe booted up their mining rigs, users fired up their nodes and the network came to life. It worked; no hiccups, no issues and from a developer’s perspective the release couldn’t have gone smoother. In the following months, our team and community demonstrated its potential and true awesomeness in dealing with issues on the network and together solving two consensus bugs.

We felt it was extremely important to clearly communicate to our users how we felt about the security of the network. Today, we’re incredibly proud to announce that we are finally ready to remove the scratched out word “safe” from our website as move into a new phase: Homestead. The Homestead block will be 1.150.000 for the main network which means the Homestead transition will be roughly around midday on Pi day and the Homestead block for the Morden network will be 494.000.

## What is Homestead?

Homestead is the second major version release of the Ethereum platform, which includes several protocol changes and a networking change that gives us the ability to do further network upgrades:
- EIP-2 Main homestead hardfork changes
- EIP-7 Hardfork EVM update: DELEGATECALL
- EIP-8 devp2p forward compatibility

## Client releases

The Go version of Ethereum (geth) for Homestead will be release ~1.3.4~ release 1.3.5 and includes the above mentioned changes to the protocol and network. Following the release of Homestead the Go team will also shortly come with the 1.4 release, which is our big feature release and includes months of work. The reason for keeping Homestead and our feature release separate is to keep the Homestead release changes to an absolute minimum, making debugging easier when required.

The C++ version of Ethereum (eth) for Homestead will be version 1.2.0. Apart from the protocol and network changes, it also tries to be as compatible to geth as possible. You can already use Mist and “geth attach” with an eth node running in the background. In the next weeks, we will align key management with geth. The new DELEGATECALL feature of the EVM will be usable in Solidity for library calls (this is not yet released). For further details, please see the release notes.

## What’s next

Over the next couple of weeks, the teams will come together to pave the road for future development on both the Ethereum protocol as well as a roadmap for the clients and sub-protocols such as Swarm and Whisper. Once we have a clear picture of the work ahead we’ll provide details in another blog post.

For more information about Ethereum, Homestead and how to operate one of the Ethereum clients, please head over to the Homestead Documentation project and let us together prepare for the next phase of Ethereum.

Blockchains are going to rule the world, providing a mechanism for scaling social and economic cooperation to an unprecedented level — a truly global scale. Such cooperation will involve not only human beings, groups and associations but also a growing multitude of increasingly independent artificial agents.

Every blockchain creates a social network around its applications, with network value growing exponentially with the number of participants in accordance with Reed’s Law. This value isn’t extracted by intermediaries or controllers, as with previous centralized models. Instead, it’s shared among participants, providing economic incentives for cooperation without coercion.

Not all blockchains are created equal. There are three key characteristics that make scalable blockchain-enabled cooperation possible: openness, neutrality and immutability.

Openness is necessary. It goes without saying that the rules of the game should be open for anyone to see and understand. Anyone should be able to participate in any layer of the system without asking for any permission whatsoever. Anyone should be able to use the network in accordance with its rules. Anyone should be able to create their own client implementing the open protocol. Anyone should be able to contribute to network security, and so on. No registration, identification or other preconditions should limit participation. All such limitations prevent the network from scaling and their enforcement creates centralization risks.

Neutrality is necessary. It’s important for anyone participating in blockchain-enabled cooperation to be on an equal footing with everyone else. It doesn’t matter if you wield huge economic power or only a tiny amount. It doesn’t matter whether you’re a saintly Mother Theresa or a vicious drug dealer. It doesn’t matter whether you’re a human or a refrigerator. It doesn’t matter what you believe in, what political theory you subscribe to, or whether you’re a moral or immoral person. A participant’s ethnicity, age, sex, profession, social standing, friends or affiliations, make or model, goals, purposes or intentions — none of this matters to the blockchain even a bit. The rules of the game are exactly the same for everyone, period. Without neutrality, the system is skewed towards one set of participants at the expense of others. In that case, it’s less likely to gain universal acceptance and maximize network value for everyone.

Immutability is necessary. The blockchain is a truth machine preserving one universally accepted version of history, one immutable sequence of events. What’s true once is always true, regardless of political or business interests, and no amount of lobbying can change that. If it’s simply not possible to change history, then no resources are wasted on the effort. If there are any loopholes at all, then sufficiently motivated and determined interest groups will exploit them at the expense of others, diminishing network value for everyone.

The rules governing the blockchain network are known in advance. They’re exactly the same for everyone and not subject to change other than with 100% consensus. Yes, it must be 100%. Because any change to the system’s rules that not all participants freely agree to creates a network split, diminishing network value for everyone.

It’s impossible to achieve these blockchain characteristics without the system being truly decentralized. If any aspect of the blockchain system becomes subject to centralized control, this introduces an attack vector enabling the violation of one or more of the key blockchain characteristics. It may be possible to limit participation (such as by enforcing AML/KYC rules), thus violating openness. It may be possible to enforce discriminatory policies (such as by filtering “illegal” transactions), thus violating neutrality. It may be possible to rewrite the history of events (such as by confiscating or “redistributing” funds), thus violating immutability. Introducing centralized chokepoints creates a precondition for the introduction of “blockchain intermediaries or controllers” who can siphon value out of the system at other participants’ expense.

So decentralization is the most important feature of blockchain systems, the one everything else depends on. With decentralization, blockchains will come to rule the world. Without it, they’ll be “contained” and railroaded into niche applications.

We decentralists are committed to keeping blockchains open, neutral and immutable. We’re committed to keeping blockchain systems decentralized. This informs all our actions and positions towards any developments in the crypto world and beyond. All attempts to violate any of the key blockchain characteristics should be fought. All changes to a blockchain’s rules that introduce new centralization risks or strengthen existing ones should be fought. Only developments that are clearly beneficial to decentralization or strengthen the three key blockchain characteristics should be supported and encouraged. The blockchain revolution won’t be centralized. Let’s make sure of it.

Onward.

Source: https://medium.com/@bit_novosti/a-crypto-decentralist-manifesto-6ba1fa0b9ede#.2m5ro5rr9

PDF Version:
- English
- Tiếng Việt
- русский
- Deutsche
- Italiano

## Ideology
We believe in decentralized, censorship-resistant, permissionless blockchains. We believe in the original vision of Ethereum as a world computer you can't shut down, running irreversible smart contracts. We believe in a strong separation of concerns, where system forks are only possible in order to correct actual platform bugs, not to bail out failed contracts and special interests. We believe in censorship-resistant platform that can be actually trusted - by anyone.

More: https://medium.com/@bit_novosti/a-crypto-decentralist-manifesto-6ba1fa0b9ede

## Motivation
Ethereum Foundation responded to DAO debacle in the worst way possible. Special interests controlling the Foundation are ramming through DAO bailout hardfork against principled opposition of a significant economic minority of Ethereum stakeholders. According to (diligently hidden, pro-fork) coin vote on Carbonvote, 19% of ETH holders oppose this hardfork. Also, about 22% of Ethereum miners voted against the previous 'DAO softfork' and would logically oppose hardfork as well. Such a significant minority of stakeholders should not be silenced or intimidated into submission - they should be given a clear choice.

If we want to continue to move forward and guarantee survival of the original Ethereum vision, we must fork Ethereum. This will lay the foundation to build secure decentralized applications that are actually censorship resistant.

More: https://github.com/ethereumclassic/freeworldcomputer-project

## Goals

The main goal of the project is to ensure survival of the original Ethereum blockchain. We will strive to provide alternative for people who strongly disagree with DAO bailout and the direction Ethereum Foundation is taking their project. Anyone opting to remain on the original chain should have such opportunity.

## Plan

### Development
We fork Ethereum and maintain upstream patches similar to the relation between Redhat and CentOS, until a community can form around the project and create a road map. Until this happens we can fork multiple existing clients to help prevent a monoculture of clients. We plan to follow https://github.com/ethereum development except for any features they introduce into existing clients that violate the key principles of openness, neutrality and immutability.

Code: https://github.com/ethereumclassic

### Community
- https://www.ethereumclassic.org
- https://www.reddit.com/r/EthereumClassic/

## What can I do?

Please help us spread the word about this project in Ethereum community!

### Volunteers
If you feel strongly about the cause, please get involved. With just days before the planned hardfork, we need your support to ensure original Ethereum survival. We need more developers, website designers, people who can write and advocate the need for Ethereum Classic. Please let us know what are your skills and how you would like to contribute. Redditors, please reply here. Github users, please open new issue.

### Users

In order to remain on the original Ethereum chain, just don't upgrade to hardfork client version pushed by Ethereum Foundation. We will maintain non-fork versions of all major Ethereum clients (as well as other key software), so going forwards all the improvements will be available to you.

Fun fact. If you keep ETH under your direct control (not in a 3rd party wallet or exchange account), you will have two sets of coins instead of one post-fork. You could then install a forked Ethereum client in addition to Ethereum Classic, copy your private keys there and use your coins on both chains! You won't be so lucky if your ETH are locked with 3rd party going into the fork - some exchanges already announced that they will only return one type of coin post-fork to its users.

### Miners

Miners supporting the original chain should just keep mining with current version of software for now, without upgrading to client version introducing the hardfork code. It will be always possible to download and build latest non-fork version from https://github.com/ethereumclassic.

The difficulty of the original chain will be quite high post-fork, but it will adjust to actual hashrate shortly (just 2048 blocks, a few hours). Since it is expected that most hashrate will move to hardfoked chain, post-adjustment it will be possible to obtain decent mining rewards in classic ethers even with solo mining.

Mining pool supporting the original chain is currently under development, please check here in a couple of days.

### Traders

Most important question for traders is 'will ETC have market price'? There are all reasons to believe that it will. Essentially, ETC is an Ethereum 'spinoff coin' with a wide user base of all current ETH users. Some of them will see the value of transacting on a censorship-resistant chain, some won't. This creates interesting arbitrage opportunities for smart traders. Additional reasoning why ETC is very unlikely to be 'worthless'.

One exchange agreed to carry ETC already. It's Bitsquare which is planning to add ETC trading right after the fork. Other trading venues will follow. We are in talks with several exchanges to add ETC to their platforms (or re-introduce trading for the exchanges that previously traded ethers).

#### Let's make sure original Ethereum vision doesn't just "go gentle into that good night"!

Attribution: https://blog.ethereum.org/2016/07/20/hard-fork-completed/

We would like to congratulate the Ethereum community on a successfully completed hard fork. Block 1920000 contained the execution of an irregular state change which transferred ~12 million ETH from the “Dark DAO” and “Whitehat DAO” contracts into the WithdrawDAO recovery contract. The fork itself took place smoothly, with roughly 85% of miners mining on the fork:

You can see ongoing fork progress here. EthStats shows Go, Java and Parity (Rust) nodes successfully synchronized to the fork chain.

The recovery contract is already returning DAO token holders’ ether; about 4.5 million ETH has been sent to DAO token holders, and about 463000 ETH is in the control of the curator; a contract to facilitate extrabalance payments is currently undergoing security review.

Users who are interested only in participating in the fork chain should upgrade their clients to a fork-compatible version if they have not already done so; the upgraded Go client (version 1.4.10) is available here. If any users continue to be interested in following the non-fork chain, they should still update, but run with the --oppose-dao-fork flag enabled, though they should beware of transaction replay attacks and take appropriate steps to guard against them; users with no interest in the non-fork chain do not need to worry about transaction replay attack concerns.

We thank our developers and the community for working together to make the transition as smooth as it has been, and look forward to working together to continue to make the Ethereum ecosystem and protocol a success.

Now that we moved through the most difficult part of the post-fork transition and ensured our chain survival, we may focus on other things. Like branding, for example. Some people have noticed that I've started to use ETC ticker for Ethereum Classic instead of ETH-C. Why? Here is the rationale.

ETH-C ticker served us well in the process of HF transition. When we tried to explain the difference between pre-forked and post-forked tokens to the community, we could say that legacy ETH 'splits' into two separate tokens, namely ETH-F and ETH-C. It was logically consistent and helped us to convey our idea.

After the transition happened, there is a problem with this narrative however: 'ETH-F' does not really exist. All the exchanges assigned 'ETH' ticker to the forked Ethereum, even if many people consider it incorrect, with the original Ethereum chain still very much alive. So, 'ETH-F' just isn't real. And so is 'ETH-C'.
- In crypto-trading world, a four-letter ticker conveys inferiority, like a second-class citizen. We don't want our ticker to be seen similar to some shitty 2nd rate altcoins.
- We don't want to be second rate. Ethereum Classic has all the necessary components and a clear potential to grow into a major smart contract execution platform that is used by many types of dapps that critically depend on censorship-resistance. Dapps that are neither comfortable nor welcome on the forked blockchain, "mutable by democratic consensus". And we want our ticker to reflect this ambition early on.
- Three-letter codes are entrenched standard in forex/currency world. Most of the forex infrastructure is tied to these restrictions.
- Ah, yes, standards. ISO 4217 Currency Codes only allows for 3-letter codes. Only major crypto-currencies that follow this convention will be acceptable to wider financial system down the road. All the rest would have to change their ticker mid-way.
- Even in crypto-trading, some of the tools, trackers and exchanges don't even support non-standard 4 letter codes. You can see BTC, LTC, ETH, but not DOGE, BTCD or USDT there.
- ETC (EThereum Classic) contrasts well to ETH ticker which is claimed by the forked chain, without looking second-rate to it. At the same time, this ticker has 'a look and feel' of important coins such as BTC, LTC... ETC?
- The ticker ETC is miraculously not yet claimed by other cryptos. Which is very fortunate.

This are the main points supporting a view that transition to ETC as a main ticker for Ethereum Classic is a very good idea. Of course, you are free to use ETH-C in a narrative that contrasts it with a forked ETH-F or any other way. But for the obvious reasons given above (and some less obvious), ETC makes so much more sense as a main/trading ticker for Ethereum Classic.

News update

Ethereum Classic is starting to make some serious waves. With a surprise announcement of ETC trading on Poloniex, it immediately became trader's favorite. ETC/BTC is now the most active pair on Poloniex, with daily trading volume exceeding 100K BTC. Chinese exchange Yunbi announced start of ETC trading tomorrow. Coinmarketcap added ETC to its coin lineup, where it currently fighting with Litecoin for #5 position, with a market cap exceeding $150 mln.

Please engage in ETC trading if you are interested in active market and want to increase your stake in Ethereum Classic. Some people were asking if ETC is planning to do a token sale similar to ETH presale. In a certain sense you could say that ETC presale is running right now.
- - -
Mining

Miners who support Classic are now able to make good money: turns out, Classic mining is the most profitable of all GPU coins. New pools added ETC mining support. ETC nethash increased significantly to about 500 GH. Current Classic pools:
- http://ethc.epool.io (support thread)
- https://etcpool.io/ (support thread)
- https://ethc.coin-miners.info
- http://pool.ethereumclassic.com (backup only!)

New pools, please list yourself on ETC Wiki.

More info on solo mining and more mining tips.

The pools listed above are run independently of Ethereum Classic project, so do your own due diligence. BTW, why don't you start running your own Classic pool? Here is some opensource code, if you are interested.
- - -
Community tools

You can use (beta) block explorers to follow the chain progress:
- http://classic.aakilfernandes.com/
- http://gastracker.io/

Slack channels always have lively discussions:
https://ethereumclassic.herokuapp.com/

Our newest addition: Ethereum Classic wiki. Please share your knowledge and help others get going with Classic.
- - -
Outreach

Please help us spread the word about Ethereum Classic around Ethereum community and beyond! Use this logo set or create something better still. Start websites. Write blog posts. Tweet. Let people know about Ethereum Classic and its value proposition.

Thanks for your support, and let's move our chain along! Stay classy, everyone! ;)

So, you understand the value proposition of open, neutral and immutable blockchains and share Ethereum Classic principles. You would like to join the community and help original Ethereum vision to succeed. What can you do? Here are some ideas:
- - -
Get a Classic wallet

Create new Ethereum Classic wallet in few easy steps.
Running a web-based Classic wallet is also possible: http://classicetherwallet.com/
- - -
Run a Classic node

We need better network bootstrapping. Run a dedicated Classic node. If your node maintains good uptime and network connectivity, please notify the developers so they can add them to bootstrap list.
Also, please consider adding your node to network status monitor (Netstat): http://etcstats.net/
- - -
Help with community tools

There is a community-driven effort to create ethereumclassic.com website. If you are interested to participate, please join the discussion.

Another initiative is to create Ethereum Classic Guide and improve overall quality of documentation. ETC should be accessible to anyone, and easy to start with!

Ethereum Classic wiki needs some love as well. Please share your knowledge and help others get going with Classic.
- - -
Contribute to development

If you have skills, please consider joining our dev team. We are working actively on geth/mist/etherwallet, but we need developers to begin migrating/restoring other clients and key supporting software.

Alternatively, you can help improve community tools. Block explorer improvement is our top priority right now. Beta support for exploring addresses and transactions appeared, but more is needed. Block explorers are essential, and before Classic there were no open source ones in Ethereum ecosystem.
- - -
Mine the original chain

Start mining to support network and earn classic ethers (ETC). Difficulty is relatively low, so even solo miners have a decent chance to find a classic block or two. Here is some info on solo mining, ETC mining guides and tips. Join in on the fun!

There are many Classic pools now, some of them listed on our website. New pools, please list yourself on ETC Wiki.

The pools are run independently of Ethereum Classic project, so do your own due diligence. BTW, why don't you start running your own Classic pool? Here is some opensource code, if you are interested.
- - -
Trade ETC for fun and profit

Trading classic ethers (ETC) is important as it gives our chain tokens value, attracting more miners.

ETC trading is now live on all the major crypto-exchanges. Bitfinex, Poloniex, Kraken offer trading pairs such as ETC/BTC, ETC/USD and ETC/ETH. Updated exchange list can be found on the front page of our website. Please trade ETC if you are interested in active market forming or want to increase your stake in the success of Ethereum Classic.
- - -
Spread the word

Please help us spread the word about Ethereum Classic around Ethereum community and beyond! You can use this logo set, or create something better still. Start websites. Write blog posts. Tweet. Let people know about Ethereum Classic and its value proposition.
- - -
Donate

ETC: 0xe9a7e26bf5c05fe3bae272d4c940bd7158611ce9

ETH: 0xda99c6385e7ec0a7b4031c393dac01b600341fc3

BTC: 1953UK8Y849SZqfDEnn3Zu4AM98hwWk3Kw
- - -
Feeling like something needs to be done, and no one is doing it? Take the initiative! Ask around our Slack channel if there is something urgent to be done.
- - -
Thanks for your support, and let's move our chain along! Stay classy, everyone! ;)

Attribution: https://blog.ethereum.org/2016/07/26/onwardfromthehardfork/

The foundation has committed to support the community consensus on the admittedly difficult hard fork decision. Seeing the results of various metrics, including carbonvote, dapp and ecosystem infrastructure adoption, this means that we will focus our resources and attention on the chain which is now called ETH (ie. the fork chain). That said, we recognize that the Ethereum code can be used to instantiate other blockchains with the same consensus rules, including testnets, consortium and private chains, clones and spinoffs, and have never been opposed to such instantiations.

All users who had ETH before block 1920000 now have both ETH (the fork chain) and ETC (the community effort to continue the no-fork chain). Users are generally advised that most Ethereum client defaults, including clients developed by the Foundation and by third parties (eg. Parity), will select the ETH chain; if you are offered a choice on a fork in the Mist interface, then selecting “Yes” on this choice will direct you to this chain.

Users who are interested in taking any actions with their ETC, including creating and participating in applications, converting to another asset, etc are advised to use the splitter contract at address 0xaBbb6bEbFA05aA13e908EaA492Bd7a8343760477 to move their ETC to a separate newly created account so as to avoid replay attacks; we also encourage the ETC community to consider adopting a secondary hard fork to change transaction formats to make further replay attacks impossible. Until and unless that happens, once ETH and ETC are “split” they should be managed via separate wallets.

To use the splitter contract from inside of the Ethereum Wallet, click on Contracts -> Watch Contract, copy the address and ABI from the above linked etherscan page, and click “OK”; then, click on the contract in the Contracts tab, select “Write to Contract”, and select the “Split” function. It will ask for two addresses; for the first, put the address where you want your ETH to go (feel free to put the same address you are sending from), for the second put the address where you want the ETC to go. Make sure to try this with a very small amount of ether first to verify that it works before increasing the amount. You may use the Ethereum Classic Explorer here to verify that ETC balances have been transferred. A more detailed community-provided guide can be found here.

There is a tremendous momentum going in Ethereum Classic community. People burst with ideas, they want to help building and improving our community. People want to contribute to its infrastructure, coding, branding, marketing. Volunteers want to spread the word, organize local events and user groups, address issues, start new exciting projects and so on.

It is great to see this momentum, but some people feel disoriented because "no one seems to be in charge". I definitely have no intention to play Vitalik, and I don't feel like another definite centralized authority such as "Ethereum Classic Foundation" is a very good idea.

This is a decentralized community. You feel like something needs to be done and no one is doing it? Don't ask for permissions, just:
- inform everyone about the issue you see
- offer a plan to get it addressed
- initiate discussion, solicit help and resources you need to make it happen
- modify your plan as needed based on initial discussion
- go ahead and just implement it!
- assess the results, get feedback, go for another iteration

In Ethereum Classic, everything is a community effort. If everyone is simply contributing to the issue s/he is most passionate about and feels most qualified to achieve progress, it could work wonders. Just do your best to address the issues you see and listen to community feedback.

The blockchain revolution won't be centralized. We can make it happen, and we don't really need "supreme leaders" for this.

"He that breaks a thing to find out what it is has left the path of wisdom."
Gandalf - J.R.R Tolkien

Ethereum foundation when hardforked its blockchain broke vital values that could ultimately compromise forked Ethereum credibility.

#Immutability and #Fungibility

As a consequence of that decision we (Ethereum Classic), as a community, organized a movement to protect what is important for the future of society.

This movement gained incredible traction due to the philosophic alignment of many people with our values proposition.

The community formed around these core values is so vibrating and captivating that investors were attracted as light to a nearby black hole resulting in one of the most prominent blockchains in market capitalization and daily trade volume.

History will tell why these values are so important for an organization.

Methodology for reaching improved governance of decentralized anarchist organizations

Figure 1 - Source Inside Bitcoins

## Introduction

One of the main problems to be addressed by a decentralized anarchist organization of individuals is the intelligent allocation of resources. As each individual is motivated to propose organizational improvements, for each opportunity the organization has, several proposals might be sent for evaluation of the decision taking board. It's probable that not all the proposals made are going to be funded because resources (matter, time, space, intelligent agents) are limited. So methods for selecting most fit proposals are often utilized. Here I present a method analogous to the genetic algorithm for selecting most fit proposals to be funded within an anarchist organization.

Figure 2 - Source Mile Track GPS

## Proposed Algorithm

A population of proposals to a problem is evolved toward better proposals. The evolution starts from a population of community generated proposals, and is an iterative process, with the population in each iteration called a generation of proposals. In each generation, the fitness of every proposal in the population is evaluated; The more fit proposals are selected from the current population, and each proposal details are modified to form a new generation. The new generation of candidate proposals is then used in the next iteration of the proposals algorithm. Commonly, the algorithm terminates when either a maximum number of generations has been produced, or a satisfactory fitness level has been reached for the population.

## Measuring Fitness Of Each Proposal

One way to effectively measure the fitness of proposals is by a simple democracy voting process. The problem with this method is that receiving bad votes can lead to the tiranny of the majority.

Figure 3 - Source FTCDN

If somehow a method for measuring the quality of the votes was available, the tiranny of the majority could be avoided.

## Measuring Quality of Votes

The quality of the votes can be estimated with the conscience level each voter has.

Figure 4 - Source My Tech Analyst

To better illustrate the conscience level parameter I'll give a classical example called tragedy of the commons.

## Tragedy of the Commons
The tragedy of the commons is an economic theory of a situation within a shared-resource system where individual users acting independently according to their own self-interest behave contrary to the common good of all users by depleting that resource through their collective action.

Figure 5 - Source Jborden

People with less conscience would vote based on their own interest resulting in the depleting of the common resource whereas people with more conscience would actually vote for the collective handling of the common resource for added overall productivity.

If each individual has one vote, and 80% of the individuals are not conscious, full democracy would probably lead to depleting that resource. Let's then imagine a system that will give 5 votes for each individual that passes the courses called Tragedy Of The Commons and Correct Handling Of The Common Resource.

## Star Wars Analogy

In Star Wars the consciousness level would be something like the Midichlorian count. The highest Midichlorian count is attributed in the series to Anakin Skywalker, above 20,000.

He became Darth Vader and started acting evilly, in the same way highly conscious individuals often do. This indicates that consciousness cannot be the only factor for and individual to receive voting power. Instead evilness has also to be considered.Recently BBC published a psychological test called "How dark is your personality" to measure evilness.

Figure 6 - Source Tumblr

Evilness can be modeled as a factor ranging from -1 to 1.
 To be fair with the community evolution:

Voting power of an individual = - Evilness * Consciousness Level.

Instead of a general consciousness level, people are often very conscious in one subject and unconscious in another. That means the consciousness level in the equation above, that gives an individual voting power, has to be about the subject being voted, i.e. the proposals population and the problem to be addressed.

Let's then imagine a system that will give 5 votes for each individual that passes the courses called Tragedy Of The Commons and Correct Handling Of The Common Resource.

These courses are in fact relevant competences to the subject being voted, so an increase of these competences is positively related with a better vote.

### Measuring evilness of an individual

Figure 6 - Source the author

The advent of the blockchain allowed the recording of information in a safe, decentralized and possibly immutable way. Taking into advantage this technology, the evil deeds of an individual can be recorded in a blockchain powered immutable ledger.

If that was done in the forked Ethereum, Darth Vader would have the possibility to attack his evilness ledger to make it not evil with the purpose of receiving voting power.

## Drawbacks

This system might look overly complicated for a project selection process. Although with the advent of the smart contracts and computerized selection processes, the burden part of the process can be computer aided. After a few rounds people should get used to it.

## Insights

This topic was motivated from my participation in the Ethereum Classic community and first posted at Github - issue 39. Thank you Avtar Sehra for your contribution.

Let it be known to the entire world that on July 20th, 2016, at block 1,920,000, we as a community of sovereign individuals stood united by a common vision to continue the original Ethereum blockchain that is truly free from censorship, fraud or third party interference. In realizing, that the blockchain represents absolute truth, we stand by it, supporting its immutability and its future. We do not make this declaration lightly, or without forethought to the consequences of our actions.

## Looking Back

It should be stated with great gratitude, that we acknowledge the creation of the Ethereum blockchain platform by the Ethereum Foundation and its founding developers. It certainly can be said without objection, that without their hard work and dedication that we as a community would not be, where we are today.

From its inception, the Ethereum blockchain was presented as a decentralized platform for “applications that run exactly as programmed without any chance of fraud, censorship, or third-party interference” [1]. It provided a place for the free association of ideas and applications from across the globe without fear of discrimination, while also providing pseudonymity. In this decentralized platform, many of us saw great promise.

## List of Grievances

It is however, with deep regret, that we as a community have had to spontaneously organize [2] to defend the Ethereum blockchain platform from its founding members and organization due to a long train of abuses, specifically by the leadership of the Ethereum Foundation.
These grievances are as follows:
- For rushing the creation of a “soft fork,” which was comprised of a minor change in the Ethereum blockchain code for the sole purpose of creating a blacklist and censoring transactions, that normally would have been allowed
- For neglecting the full implications of the “soft fork” by the Ethereum blockchain as a warning, that they were violating the principles and values coded therein [3]
- For creating an unrepresentative voting mechanism called the “carbon vote”, which they initially stated was “unofficial” [4] only to contradict these statements a day before determining to hard fork [5]
- For rushing the creation of a “hard fork,” which was comprised of an irregular state change in the Ethereum blockchain code that violated the properties of immutability, fungibility, and the sanctity of the ledger
- For willfully deciding to not include replay protection in the “hard fork”, an action which has unnecessarily cost exchanges and thousands of users the rightful ownership of their Ether tokens [6]

## Respecting the Values Essential for Blockchains

One might ask, what harm can be done from changing the code of the Ethereum blockchain and bailing out [7] “The DAO” token holders, which is not an unreasonable question. Many of us have an innate sense of right and wrong, so at first glance rescuing "The DAO" felt right. However, it violated two key aspects of what gives peer-to-peer cash [8] and smart contract-based systems value: fungibility and immutability.

Immutability means, the blockchain is inviolable. That only valid transactions agreed upon via a cryptographic protocol determined by mathematics are accepted by the network. Without this, the validity of all transactions could come into question, since if the blockchain is mutable, any transaction could be modified. Not only does this leave transactions open to fraud, but it might spell disaster for any distributed application (Dapps) running atop the platform.

Fungibility is the feature of money, where one unit equals another unit. For instance, a Euro equals another Euro just as a Bitcoin equals another Bitcoin. Unfortunately, an ETH no longer equals another ETH. The alleged attacker’s ETH was no longer as good as your ETH and was worthy of censorship, deemed necessary by a so-called majority.

Ultimately, these breaches in fungibility and immutability were made possible by the subjective morality judgements of those, who felt a burning desire to bring the alleged attacker to justice.

However, in doing so, they compromised a core pillar of Ethereum just to do what they felt was in the interests of the “greater good”. In a global community, where each individual has their own laws, customs, and beliefs, who is to say what is right and wrong?
Deeply alarmed, that these core tenets were disregarded by many of the Foundation’s developers, and a sizable portion of Ethereum participants, we, as a community, have organized and formed a code of principles to follow for the Ethereum Classic chain.

## The Ethereum Classic Code of Principles

We believe in a decentralized, censorship-resistant, permissionless blockchain. We believe in the original vision of Ethereum as a world computer that cannot be shut down, running irreversible smart contracts. We believe in a strong separation of concerns, where system forks of the codebase are only possible, when fixing protocol level vulnerabilities, bugs, or providing functionality upgrades. We believe in the original intent of building and maintaining a censorship-resistant, trustless and immutable development platform.

Herein are written the declared values by which participants within the Ethereum Classic community agree. We encourage that these principles not be changed via edict by any individual or faction claiming to wield power, authority or credibility to do so.

We, as a community agree that:
- the purpose of Ethereum Classic is to provide a decentralized platform, that runs decentralized applications, which execute exactly as programmed without any possibility of downtime, censorship, fraud or third party interference
- code is law; there shall be no changes to the Ethereum Classic code that violate the properties of immutability, fungibility, or sanctity of the ledger; transactions or ledger history cannot for any reason be reversed or modified
- forks and/or changes to the underlying protocol shall only be permitted for updating or upgrading the technology on which Ethereum Classic operates
- internal project development can be funded by anyone, whether via a trusted third party of their choice or directly, using the currency of their choice on a per project basis and following a transparent, open and decentralized crowdfunding protocol
- any individual or group of individuals may propose improvements, enhancements, or upgrades to existing or proposed Ethereum Classic assets
- any individual or group of individuals may use the Ethereum Classic decentralized platform to build decentralized applications, hold crowdsales, create autonomous organisations / corporations or for any other purpose they deem suitable

## Looking Forward

For the many reasons listed above, we have chosen to rename the original blockchain “Ethereum Classic” with the ticker symbol “ETC”, so that the community and all other participants can identify the original, unforked, and immutable blockchain platform.

Our most sincere gratitude goes to those developers within and outside the Foundation, who opposed interfering with the Ethereum blockchain ledger and enabled the Ethereum Classic chain to survive and live on.

We know, there are many of you and we welcome you at anytime to join our decentralized community.

We will continue the vision of decentralized governance for the Ethereum Classic blockchain and maintain our opposition to any centralized leadership takeover, especially by the Ethereum Foundation as well as the developers, who have repeatedly stated, that they would no longer develop the Ethereum Classic chain.

We likewise will openly resist the “tyranny of the majority,” and will not allow the values of the system to be compromised. As a united community, we will continue to organize for the defense and advancement, as required, for the continuation and assurance of this grand experiment. The Ethereum Classic platform, its code and technology, are now open to the world as Open Source software [9]. It is now freely available for all who wish to improve and build upon it: a truly free and trustless world computer that we together as a community have proven and will continue to prove is anti-fragile [10].

~ The Ethereum Classic Community

### References
1. https://ethereum.org/
2. https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelpethereum/
3. https://blog.ethereum.org/2016/06/28/security-alert-dos-vulnerability-in-the-soft-fork/
4. https://www.reddit.com/r/ethereum/comments/4s0rz6/avotethatnobodyknowsaboutisnotavote/d55nye3/
5. https://blog.ethereum.org/2016/07/15/-to-fork-or-not-to-fork/
6. https://pbs.twimg.com/media/CopwJVHXEAABEKd.jpg
7. https://dictionary.cambridge.org/us/dictionary/english/bailout
8. https://bitcoin.org/bitcoin.pdf
9. https://github.com/ethereumclassic
10. Anti-fragile: “Things, That Gain from Disorder” by Nassim Nicholas Taleb

PDF Version:

-English
-中文
-русский
-Tiếng Việt
-Deutsche
-Italiano

Hello, Classic Fans!

We've launched a new ethereumclassic.org website to replace the old one.

If you'd like to contribute to its content, fix errors, write a blog article, feel free to submit a PR on Github!

Figure 1. Ethereum Classic pulsing community. Source Ethereum Classic Slack #website-design channel

## Nature Inspired Dynamics

For every opportunity presented to Ethereum Classic community I think it should not disencourage going to several random different approaches as a mutant evolving community. If an individual can grab some fruits in one direction awesome. If it starts to starve in another, that direction might be cancelled like in a Lévy flight foraging hypothesis performed by a bee looking for pollen for example.

Figure 2. Hive and bees. Source Geyser of Awesome

Figure 3. An example of 1000 steps of a Lévy flight in two dimensions. The origin of the motion is at \[0,0\], the angular direction is uniformly distributed and the step size is distributed according to a Lévy (i.e. stable) distribution with α = 1 and β = 0 which is a Cauchy distribution. Source wikipedia.

 The analogy helps to understand a proposed dynamics for the community:
- Each hive has limited resources depending upon the ecossytem where that hive is located among other factors.
- The species (analogous to the community) can be considered as a population of hives.
- Each bee's purpose is to make its hive and species grow stronger. A bee is a high valued asset for the hive. As each hive is a valued asset for the species.
- A regular bee can develop leadership skills becoming a leading bee.
- A leading bee can form a new hive and should be encouraged to do so.

According to the resources requirement, the selection of the best looking path by a single bee has to somehow be performed. Going into one direction has a cost function related to the bee fatigue. If it doesn't find pollen after a long run, best to abort mission and return to the hive to rest and recover energy. When that happens the hive is encouraged to welcome that bee with proud, happiness and warming comfort.

## Ethereum Classic community development

Figure 4. ETC Declaration of Independence. Source EthNews

 The community behing Ethereum Classic is growing as time goes by in a healthy and pulsating way preserving its outstanding values with determination.

Good ideas that boost motivation and drive inspiration are key factors to reward the community with advances in the crypto space. The idea presented here (nature inspired community dynamics) is philosophical and brings people a good understanding of the sense of a true community. In the other hand, diverging development efforts is to be avoided.

Congrats to Dr. Avtar Sehra, Dr. Vic Arulchandran and other organizers on a very
successful ETC Kickoff in London, and many thanks to Eversheds LLP for sponsorship of the event!

Slides from kickoff presentation could be found here:
http://www.youtube.com/watch?v=YB_k9iIqBEQ

As the Ethereum Classic community grows, more meetups are planned around the globe:
http://www.meetup.com/EthereumClassic/

Coming up next: Ethereum Classic Switzerland Kickoff in Zurich, Tuesday, August 23rd:
http://www.meetup.com/EthereumClassic/events/233057244/

One of the largest crypto-currency exchanges in China, CHBTC, has announced a series of donations to the Ethereum Classic (ETC) project. The donations will provide support to current and future development efforts, as well as kickstart various community building proposals. Today’s announcement by CHBTC, follows through on discussions that took place early August.

Funds contributed by CHBTC to ETC core development will be applied to accelerate the introduction of solutions to the so-called “difficulty bomb”. These solutions are important to ensure long-term viability of PoW mining on Ethereum Classic blockchain.

Another initiative that received CHBTC funding is focused on ETC community building in China. It will support localisation of ETC materials and development of the official Chinese ETC website located at ethereumclassic.cn, as well as community websites and news portals. A portion of the donation will also fund organizing ETC meetups and other community events in different cities around the country.

The Ethereum Classic community would like to express deep gratitude to CHBTC for this important contribution to ETC’s development. It will serve to strengthen the Ethereum Classic technical community as well as ETC’s position in China and worldwide.

Founded in 2013, CHBTC is one of the mainstream digital currency exchanges in China, offering Bitcoin, Litecoin, Ethereum and Ethereum Classic trading and 3 times margins. Headquartered in Zhongshan, China, CHBTC serves a global customer base. It is number one exchange in China for ETH and ETC trading, and fourth BTC trading platform by volume.

Ethereum Classic is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference. Ethereum Classic is a continuation of the original Ethereum blockchain - the classic ‘unforked’ version; free from external interference and subjective tampering of transactions.

People keep repeating the phrase "Code is Law" without clear understanding of what it's supposed to mean. Some deliberately misinterpret it to mean that "ETC supports thieves and crooks" and similar nonsense. Let's get some things straight. Code is law on the blockchain. In the sense, all executions and transactions are final and immutable. So, from our (Ethereum Classic supporters) standpoint by pushing the DAO hard fork EF broke the "law" in the sense that they imposed an invalid transaction state on the blockchain.

This has nothing to do with contractual or criminal law, or other legal considerations. Stating that "code is law" is similar to acknowledging the laws of physics. The law of gravity says that when I push a piano out of a window, the piano will fall downwards. It does not mean that it's necessarily "legal" for me to push that piano out of that window. And if I do so and the falling piano kills some passer-by, it would be insane for me to argue before the judge that I shouldn't go to jail because I broke no laws of physics.

On Ethereum blockchain, a Turing complete code operates with a very real and tangible value. Because of this, there is always a potential for mistakes and unintended outcomes. There will always be transactions and code execution results that someone is not happy about. There will be conflicts and disagreements, there will be code vulnerabilities and exploits, there will be scams and thefts, there will be all kinds of ugly things.

Who should deal with all these conflicts? Let's imagine for a moment that we decided 'the blockchain community' will take it upon itself to deal with it all.

Who is going to make a call which on-chain code execution is “theft,” and which is not? Is this ponzi contract scammy enough to shut it down? Do we tolerate this dark market while it sells fake ids and marijuana, but draw the line once it starts to dabble in child porn and cocaine?

Should there be a democratic voting system (moot court) to decide on these cases, changing the blockchain state based on such decisions? Should there be a committee that decides what smart contract behavior is 'unacceptable' and what transactions are 'illegal' enough to justify a hard fork?

What may serve as a basis for such decisions? Where is the applicable body of law? Who is going to be the police, the judge and the jury? What is a due process? What is the appeal procedure? A lot of questions, and no good answers to these questions, when it comes to "blockchain justice".

But it's even worse if there is no system at all. If 'the blockchain community' just makes a special exception in regards to a 'special case', choosing to administer justice 'just this one time'. What is so special about this case, one may ask? Why does this theft get a special treatment, and the other thefts don't? Who do you need to know, whose buddy do you need to be to get such exceptional treatment? How are you going to defend such preferential treatment against legal cases citing a precedent and subpoenas demanding reversal of specific transactions?

It's this whole snake's nest that could be avoided by refusing to be dragged into conflict resolution and quest for justice as related to smart contract execution. And it only requires sticking to principles of blockchain neutrality and immutability.

So, code is law on the blockchain. All executions are final, all transactions are immutable. For everything else, there is a time-tested way to adjudicate legal disputes and carry out the administration of justice. It's called legal system.

## Inspiration

You might not see it. But it is there quite active and performing a vital role!

Ethereum Classic community, with a clean and inspired mind we will perform greatly in the many challenges we have ahead.

The video below perfectly captures a beautiful phenomenon, a consequence of the invisible field and protector of life on planet Earth called magnetic field. Mars once had a similar magnitude field for millions of years ago when life was probably much more abundant there. With its weakening the sunrays just ravaged the planet.

So every time you feel defeated by the devastation that we do ourselves to our planet, remember that there is an invisible field and protector of our lives here on Earth. A field able to reveal itself to mankind through a light show in rare places.

This phenomenon is called aurora borealis. Ethereum Classic moves toward the protection of our planet by respecting not only intrinsic society values but also the nature of our planet in a harmonious and happy way.

 AURORA BOREALE from Andrea Battistella on Vimeo .

I will explain replay attacks in general and how to protect yourself.  I will give specifics regarding the Ethereum and Ethereum Classic replay attacks.  

## Navajo Code Talkers

Replay attacks are general attacks that are not even limited to computers.  Here is an example involving foreign languages.  During World War 2, bilingual Navajo soldiers secured communications by transmitting messages in the Navajo language.  If no extra precautions were taken, imagine the chaos that could ensure by simply repeating previously intercepted radio messages to random units.  You would not know what you were transmitting, but, you could conceivably send unsuspecting American soldiers messages such as “MOVE 1 MILE WEST NOW” or even “ATTACK NOW”.  Notice this takes little effort.  It does not even require deciphering the foreign language!

## Remote Controlled House

Here is an example of a replay attack involving computers. Imagine you decide to make your house remotely controllable with text commands while you are on travel.  You decide to take extreme measures and only send commands over the Internet that have been SHA-256 hashed 100 times.  The following Python code will encrypt your commands thusly:

You can run the script yourself to see that for the command “WATER THE LAWN NOW”, the encrypted text to send will be:

For the command “INCREASE THE TEMPERATURE 5 DEGREES”, the encrypted text will be:

If someone listens in on the transmission, all they would see is unintelligible bits.  Imagine the mischief someone could cause by resending the above two encrypted commands to your house every ten minutes nonstop.  This is another example of an attack that is easily carried out.  The attack is even effective against (apparently) strong encryption!

## Protecting Against Replay Attacks

The problem with the aforementioned scenarios is that the same messages always have the same corresponding encoded text.  This method, with regards to encryption, is referred to as Electronic Codebook (ECB) mode.  What is needed is some variability in all messages.  For example, imagine if the date and time were added to messages with the understanding that messages were to be ignored after an agreed upon expiry.  That would prevent replay attacks. Another simple solution is to add a unique number to every message.  Unique message numbers are referred to as nonces.

## What About Ethereum & Ethereum Classic?

Ethereum (ETH) and Ethereum Classic (ETC) do have protection against replay attacks.  All transactions on both systems have nonces!  If you send me some ETH tokens from your ETH account,  I cannot replay that transaction (“double spend”) on the ETH system to get more; likewise for the ETC system.  However, both systems are sometimes vulnerable to replay attacks involving the resending of transactions between systems.  The reason for this is that the uniqueness of corresponding nonces between the two systems is not required.

#### The replay attack transaction
0x87f8a62d4f04776701e95672b85838c818ceff3102d72be9377ede77ed59f83b
(minus the digital signature) on ETH block 1,920,100:

| FIELD | VALUE |
| ------------- |-------------|
| Nonce |115255 |
| Sending Address | 0x4bb96091ee9d802ed039c4d1a5f6216f90f81b01 |
| Receiving Address | 0x5d438e155d0b38c568496c411a4bcc1dcf45632a |
| Ether Sending | 5.008931333047880161 |
| Data Sending | (None) |
| Max Gas Units Can Use| 90000 |
| Price Per Gas Unit In Ether | 0.000000021786783329 | |

#### The same replay attack transaction
0x87f8a62d4f04776701e95672b85838c818ceff3102d72be9377ede77ed59f83b
(minus the digital signature) on ETC block 1,920,021:

| FIELD | VALUE |
| ------------- |-------------|
| Nonce |115255 |
| Sending Address | 0x4bb96091ee9d802ed039c4d1a5f6216f90f81b01 |
| Receiving Address | 0x5d438e155d0b38c568496c411a4bcc1dcf45632a |
| Ether Sending | 5.008931333047880161 |
| Data Sending | (None) |
| Max Gas Units Can Use| 90000 |
| Price Per Gas Unit In Ether | 0.000000021786783329 |

What specific funds are at risk?  Funds associated with the same address on both blockchains are at risk.  Therefore, this pertains to all funds existing before the ETH hard fork that now exist on both systems.  Notice this vulnerability does not pertain to the DAO related funds with modified histories. This is because these funds do not exist at the same addresses on both blockchains.

## Solutions Part One

The easiest solution is to just send your funds to an exchange that promises to secure your funds for you.  If you want to protect your funds yourself, you need to add variability between the funds on both blockchains.  Since nonces are not providing that, another method is needed.  The easiest way to add variability is to move funds to different addresses on each blockchain.  Using two wallets, one for each system, send the funds from the same addresses to different addresses on each system.

## Solutions Part Two

Perceptive readers may wonder whether the transactions that send funds to different addresses on each blockchain are themselves vulnerable to replay attacks.  There is a possibility that your attempt to add variability in the addresses fails.  But, that would just mean that your funds end up on the same new addresses on both systems controlled by you!  You could simply keep trying until you succeed in sending your funds to different addresses on each blockchain.

## Solutions Part Three

Perceptive readers may also wonder whether an aggressive attacker could make it impossible to successfully move funds as required to protect them.  Assume all transactions are instantly copied to both systems.  The countermeasure for this situation relies on the fact that there is uncertainty in the time required to process (“mine”) new transactions on blockchains that use proof of work information.   You could broadcast the two transactions, meant for different blockchains, to one blockchain.  Why would this thwart every replay attack?  Remember that the ETH and ETC systems both have replay attack protection with regards to multiple transactions on the same blockchain.  One of the transactions should be accepted, and one rejected, on each blockchain.  No one can predict which of the two transactions will be accepted on either blockchain without also compromising mining nodes.  It may take multiple attempts, but, eventually funds will end up at different addresses on each system.

## Solutions Part Four

Perceptive readers may also wonder whether new funds, sent to old addresses that previously held funds on both systems, are also vulnerable to replay attacks.  In some cases the answer is yes.  The simplest advice regarding that concern is to just avoid doing that.  In other words, do not reuse vulnerable addresses.  Arrange it so that no funds are ever sent to those addresses again.  If someone nevertheless insists on reusing addresses that exist on both chains, more work is required to secure future funds sent to those addresses.

## Parting Thoughts

Everyone must be vigilant about protecting their cryptocurrency.  Fortunately, there are effective tools and techniques that provide adequate safeguards.  The dangers cannot be ignored.  As an old Navajo proverb says:

“Coyote is always out there waiting, and Coyote is always hungry.”

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank Nick Johnson and Timon Rapp for their help. I would also like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

I will explain Merkle trees and why they are so important for blockchain systems.

## Introduction

The sending of information today is horrendously slow compared to the processing of information. Therefore, when distributing information on a peer to peer network, it is desirable to minimize communications even if that implies adding computations. Hashes can help confirm the integrity of information with minimal communication. Hash trees, or Merkle trees, can also help identify invalid bits with minimal communication.

## El Paquete Semanal

To understand the importance of Merkle trees for blockchains, consider El Paquete Semanal ("the Weekly Package"), part of one of the strangest peer to peer networks in the world. Every week a terabyte of YouTube videos, pop music MP3s, Spanish news articles and more is distributed to Cubans for a few pesos. Distribution sometimes depends on such methods as passing hard drives around by hand. This is because connectivity in Cuba is so poor. 95% of homes have none, and, the remaining 5% are subject to strong censorship. Suppose you wanted to give everyone a perfect copy of El Paquete Semanal. Because of the slowness of the network, it is impractical to resend copies to correct errors. How would you quickly find and fix errors without resending many bits? That is where Merkle trees come in.

## Fast Search

To understand why Merkle trees can be used to find errors so efficiently, try this activity: Have a friend pick any city in any part of the world. Google Maps might be helpful. Start asking yes / no questions to determine the city. You might ask questions like, "Is the city above or below the equator?", and, "Is it to the east or west of Cairo?". You should notice that cutting the search space approximately in half every question leads to the answer amazingly fast. Merkle trees allow a similarly fast search.

## Merkle Trees

Here is a Merkle tree recipe to quickly find corrupted segments in El Paquete Semanal:

Split it into eight segments and hash those segments. In the figure above, those eight hashes are represented by the boxes labelled 8 through 15. Then, hash consecutive pairs of those hashes. These are represented by the boxes labelled 4 through 7. Hash consecutive pairs of this second set of hashes as well. These are represented by the boxes labelled 2 and 3. Finally, hash these last two hashes. This is represented by the box labelled 1. Refer to the hash corresponding to label 1 as hash 1, the hash corresponding to label 2 as hash 2, etc.

Check hash 1 to determine if there are any errors to fix or not. Suppose the segment associated with hash 13 is corrupt. Check hashes 2 and 3 to determine the erroneous segment is associated with hash 6 or 7. Then, check hashes 6 and 7 to determine the bad segment is associated with hash 12 or 13. Finally, check hashes 12 and 13 to determine the faulty segment is associated with hash 13. Smaller segments would require a similar process with more levels to the Merkle tree.

For many small segments (lots of levels), using a Merkle tree to check and fix a remote copy requires much less communication than sending all the hashes of all the segments. It minimizes communications at the expense of some extra hash calculations.

## Conclusion

Blockchain systems rely on many clever data structures and algorithms. Merkle trees are muy importante for making blockchain systems operate quickly and efficiently.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

I will discuss denial of service (DOS) attacks in general and give details regarding the
Ethereum and Ethereum Classic attacks.

## Estonian Cyberwar

Estonia is known as "the most wired country in Europe". Over 90% of banking transactions are done online, and, it was the first country to have worldwide electronic voting. In 2007 Estonia also experienced the first cyberwar. Over the course of three weeks, over a million computers from fifty countries attacked its information infrastructure. Hundreds of government, banking, university and news sites were crippled or shut down by DOS attacks. There had been cyber attacks before, but, never had an entire country been targeted and its national security so threatened.

## Denial Of Service Attacks

DOS attacks attempt to make computer resources unavailable. If attacks originate from several computers, they are often referred to as distributed denial of service (DDOS) attacks. These are commonly executed by sending large amounts of traffic to computing targets. DOS attacks may be unintentional. When Michael Jackson died, news sites slowed or crashed in response to the increased traffic. DOS attacks may even arguably sometimes be legitimate. In 2011 the group of hackers known as Anonymous executed DOS attacks against PayPal, MasterCard and Visa to protest their refusal to process WikiLeaks donations. They claimed this was rightful protest and no different in principle than Occupy Wall Street. DOS attacks may even be governmental. Edward Snowden revealed that the Government Communication Headquarters (GCHQ) in the United Kingdom has developed DOS attack tools. Lastly, DOS attack vulnerabilities, without great effort, may be undetectable. An address blacklist was proposed to deal with the Ethereum DAO attack. Shortly thereafter, an overlooked DOS attack vulnerability was discovered with this scheme and the proposal was dropped.

## Ethereum & Ethereum Classic Denial Of Service Attacks

The recent DOS attacks against the Ethereum system started in September around the time of the developer conference in Shanghai. Vulnerabilities were exploited. Vulnerabilities were later patched. Then, new vulnerabilities would repeat the cycle over and over again. The attacker, or attackers, spent thousands of dollars to keep this going for several weeks. Eventually the Ethereum Classic system was also attacked in a similar manner.

Anyone can send large numbers of transactions to several Ethereum and Ethereum Classic nodes. Therefore, anyone can degrade these systems for the other participants anytime. This is typically not done because it would be horrendously expensive to keep it up for very long. The current attacks were possible because some Ethereum and Ethereum Classic instructions were underpriced relative to the amount of resources they tied up. Examples include EXTCODESIZE, EXTCODECOPY, BALANCE, SLOAD, CALL, CALLDELEGATE, CALLCODE and SUICIDE. Some attack transactions cheaply invoked EXTCODESIZE tens of thousands of times! Price adjustments to remove these vulnerabilities have necessitated changes to the systems (hard forks).

## Antifragility

In the long term, these attacks might actually be beneficial. The Ethereum and Ethereum Classic networks are antifragile. Antifragility is the property of improving in response to stressors. Immune systems, bones, muscles, economies, theories and the mythological Hydra are antifragile. Every time a new attack is exposed, the developers eventually remove the vulnerability. Therefore, every attack makes the Ethereum and Ethereum Classic systems stronger!

## Feedback

Feel free to leave any comments or questions below. You can also contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Introduction

Hard forks are incompatible changes to systems. Hard forks have caused more grief than probably anything else in the history of blockchains. Additional hard forks are being discussed now by the Ethereum and Ethereum Classic communities to deal with issues caused by the recent denial of service attack spam. Fortunately, there is nothing problematic about the proposed hard forks. I will describe an analogous technology and details of the Ethereum and Ethereum Classic systems to show why all is well.

## Java Virtual Machine

People own various computing devices. People also run various versions and types of operating systems. The Java Virtual Machine (JVM) allows disparate systems to all run programs and get the exact same results. People have implemented the JVM in hardware, but, most just simulate it in software. Some use compilers with no optimizations. Some use "just in time" compilers. Some use "ahead of time" compilers. Few care about the differences in JVM realizations as long as program results are always identical. If a complex Java based weather simulation predicts the temperature in one week will be 78.91775159 °F, and all JVM instances also compute 78.91775159 °F, then everyone is happy.

## Ethereum & Ethereum Classic Virtual Machines

The Ethereum and Ethereum Classic systems are also "virtual" machines. They are imaginary machines that are simulated. There is no Ethereum or Ethereum Classic world computer located in a bunker somewhere. The JVM allows everyone to effectively run programs on identical clones of a computer. Astonishingly, Ethereum and Ethereum Classic allow everyone to effectively run programs on the same instance of a computer. In other words, it is as if everyone is using the same single machine! As with the JVM, few care how this is done as long as the results are the same. The recent denial of service attacks took advantage of the way the systems are currently simulated. The proposed hard forks will just improve the efficiency. All results will remain the same.

## More Details On The Proposed Hard Forks

#### Ethereum attack contract account 0x7c20218efc2e07c8fe2532ff860d4a5d8287cb31 as of 2016-10-26 15:00:00 UTC that created over 2.4 million empty accounts:

| FIELD | VALUE |
| ------------- |-------------|
| Ether Balance | 0 |
| Contract Code | 0x7f6004600c60003960046000f3600035ff00000000000000000000000... |
| Storage Dictionary | (None) |
| Counter (Nonce) | 34148 |

The state of the Ethereum and Ethereum Classic systems at all times depends on all the previous activity. Computations affect accounts. There are external accounts and contract accounts. All accounts have four components: an ether balance, contract code, storage dictonary (associative array), and, a counter (nonce). For external accounts, the counter tracks the submitted transactions. For contract accounts, the counter tracks the created contracts. There is no reason for network nodes to store anything for accounts that either do not exist or are empty. The attacks created millions of empty accounts that are using massive amounts of storage. The proposed hard forks will just stop wasting space for these accounts.¹ As this storage is not in the blockchain, no changes to the blockchain are involved.

 1. Technically the proposed hard forks will also likely lead to slight gas costs to recreate these accounts.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank Elaine Ou, Nick Johnson and Smokyish for their help. I would also like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

During the last week, both Ethereum and Ethereum Classic were hit by a series of attacks that took advantage of inadequately low gas cost for certain computational operations. The effect of this attack was effectively making both networks hardly usable: blockchain sync becoming extremely slow and halting unpredictably, valid transactions taking extremely long time to make it into a block, and full nodes (both parity and geth) crashing due to difficulties processing spam transactions bloat.

It turns out that the client code fixes can do only so much to protect the network from this type of attacks. In order to close the attack vector completely, a non-backwards-compatible change is needed that reprices some operations to better reflect their impact on the nodes and the network. Which can be done only through a hard fork.

From the very beginning of Ethereum Classic project, we made it clear that hard forks are only acceptable in order to correct protocol-level bugs, fix security vulnerabilities, and provide functionality upgrades, not to bail out failed contracts and special interests. The gas reprice hard fork provides an important security fix and does not violate any principles that the Ethereum Classic community rallied around.

The technical details of the hard fork are expressed in ECIP-1050 (EIP-150 for Ethereum), and the fork code is currently being implemented and tested by ETC dev team.

It is important to note that ETH team chose another timeframe for hard fork implementation, to be effective on ETH block 2463000. Unfortunately, geth 1.4.18 released by Ethereum Foundation developers does not properly take --oppose-dao flag into consideration when implementing hard fork changes on block 2463000. Therefore, it becomes impossible to use this geth release as Ethereum Classic client.

All ETC full node users and miners are advised to upgrade to either Classic version of geth or Parity full node (which implements ETC hard fork properly) as soon as possible.

Users of the light ETC wallets (such as Jaxx), web wallet or Chrome extension should not be affected. Your ETC located in the exchange accounts also should be safe through a hard fork transition. Mist or EthereumWallet users should use Parity or Classic geth as a backend, as explained here.

### UPDATE: ETC community successfully implemented GasReprice hard fork

Block 2,500,000 passed without any issues, and ETC GasReprice hard fork is now effective. There was no netsplit, and ETC nethash did not change in any significant way, as can be seen on ETCstats network monitor.

We appreciate continued support of ETC exchanges, wallets and mining pools who upgraded their infrastructure in a timely manner and contributed to a smooth transition through the hard fork event.

First Ethereum Classic hard fork is a significant milestone for ETC community. Congratulations to classic geth and parity developers on the successful implementation and testing of the hard fork code! Many community members distributed information about the fork, helped ETC users to upgrade or troubleshooted various infrastructure issues. Without your active involvement, such a smooth transition would not be possible. Thank you!

Follow Ethereum Classic Twitter and Reddit for more updates:
- https://twitter.com/eth_classic
- https://www.reddit.com/r/EthereumClassic

Since the beginning of the formation of the Ethereum Classic community, users, developers, miners, and traders have been pondering about a change in monetary policy for ETC. Though many users in ETC look forward to a future of decentralized applications and smart contracts running on the blockchain but are dissatisfied with the current supply schedule of 5 ETC awarded per block which is created on average every 14 seconds.

As of the time of this writing, the available supply of ETC stands at 85.4 Million coins in circulation and users can’t help but compare that to Bitcoin’s 15.96 Million. For every 1 BTC there are 5 ETC and Bitcoin is 7 years older! Ethereum started with a Pre-Mine of 72 Million and by 2055, if nothing is changed, there will be about 500 Million ETC.

## A Network Upgrade

The current supply schedule for ETC is a bug, not a feature. A tightening of supply similar to Bitcoin’s would constitute as a network upgrade. The upward pressure on price due to the increased scarcity would encourage more mining, savings, and investment into ETC dApps and smart contracts.

The want and need for change in the money supply even had 77% support in one poll conducted by the Ethereum Classic Twitter Account.

Granted, it was not a scientific poll, but it seems to be an indicator of where the general ETC community stands on wanting to change policy.

## The Tithing Event

Below are two proposals by user “Snaproll” for changing the block reward of ETC. They are similar in nature to the supply schedule of Bitcoin which has proven to be a successful model were created with the goal of a CAP close to 210 million ETC. So that for every 1 BTC, there are roughly 10 ETC.

### Option A: “Tithing” at 10% Block Reward
- 10% Decrease in block reward every 3 million blocks.
- 3 million blocks is roughly 1.4 Years
- Theoretical Max CAP at 222 million, CAP in reality closer to 210 million.
- 99% of ETC mined by 2071, CAP hit after 2164

### Option B: “Tithing” at 20% Block Reward.
- 20% Decrease in block reward every 6 million blocks.
- 6 million blocks is roughly 2.8 Years
- Theoretical Max CAP at 222 million, CAP in reality closer to 210 million.
- 99% of ETC mined by 2066, CAP hit after 2157

Out of the two proposals, I prefer “Option A.” The tithing at 10%, for the reason that a change in supply schedule is done on the same day as the “Freeze of the Difficulty Bomb” network upgrade at block 3 million. It sends a clear signal to the market that ETC has taken steps towards it’s long term future and place in the crypto-currency market.

Follow Ethereum Classic Twitter and Reddit for more updates on monetary policy:
- https://twitter.com/eth_classic
- https://www.reddit.com/r/EthereumClassic

## Links

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report.

With the recent protocol update complete, focus has now shifted towards monetary
policy and governance models. Here a few points that are important to address.
- The bomb delay is part of the last protocol update.
- The bomb is delayed until late 2017.
- There will be another update coming in January to fix replay attack issues.
- Monetary policy proposals seem to be leaning heavily in favor of a capped supply.
- Here is a proposal from one of our users on Slack.
- Great article by "Chuck" that breaks down the proposal.
- Please join us on Slack.
- Monetary policy discussion can be found on the #monetary_policy channel.
- For more information on community participation please see this call to action post for guidance.

## Interview with Charles Hoskinson here .

## Great interview on CryptoHolics episode 1 featuring Charles Hoskinson.

In the interview he discusses Ethereum Classic and blockchain in general.

## Article by ETC community member "Chuck": "Instead of The Halvening, A Tithing for ETC"

## Article released by community member Dr. Seberino: "Let's Admit Blockchains Are Weird: An Introduction To The Strangeness."

## Article from ethnews.com discussing the successful ETC hardfork.“Ethereum Classic successfully hard forked the morning of October 25th. They made an upgrade to their network to stop attacks exploiting a vulnerability in the system.”

## Interesting discussion on immutability taking place on reddit: "Immutability doesn't mean being against hard forks."

## Community Metrics:
- Twitter - 33,700 followers.
- Reddit /r/EthereumClassic - 2,835 subscribers.
- Slack - 1,409 users.
- Telegram - 781 users.
- WeChat - 479 users.
- Miners - 279.91 Total GH/s Source: Gastracker.io

## Top 5 miners by average hashrate from the previous 7 days:
- 91pool 69.45 GH/s
- NanoPool 58.99 GH/s
- EtherMine 32.07 GH/s
- MiningPoolHub 31.82 GH/s
- F@pool 25.49 GH/s

I will explain the basics, and weirdness, of blockchains.

## Databases

Database administration is difficult. Information may be lost due to computer or human errors and corruption. In 2014, half a billion Yahoo accounts were compromised. Just a few months ago, the Air Force lost 12 years of investigative records. Therefore, it continues to be problematic to trust companies and governments with information.

## Blockchains

Blockchains are decentralized, secure, reliable and convenient databases. Nobody trusts anybody and no one is in charge. Nevertheless, blockchains are still used to store valuable assets including life savings and land titles.

Blockchain asset information is stored in records referred to as transactions. Transactions are organized into blocks which are further organized into chains. Cryptographic tools such as hashing functions and digital signatures help provide security. For additional security, to add new blocks, people must compute results referred to as proof of work information. To encourage this, calculation of proof of work information leads to cryptocurrency rewards. People that compete to compute proof of work information, and receive cryptocurrency rewards, are referred to as miners.

## A Weird Analog

For an analog to blockchain systems, consider free market economies. In free markets, goods and services are not in general managed by anyone. Like blockchain systems, they are decentralized. Interestingly, free market economies work better than controlled economies. Adam Smith noticed, over 200 years ago, that individuals pursuing their own interests often benefit society more so than if they intentionally tried to benefit society. It is as if every man is, in the words of Adam Smith, "led by an invisible hand to promote an end which was no part of his intention. Nor is it always the worse for the society that it was no part of it. By pursuing his own interest he frequently promotes that of the society more effectually than when he really intends to promote it." Likewise, unmanaged blockchain systems work better than managed database systems for some applications.

## Competition Is Foundational

Free market economies work so well largely because of competition. Competition improves productivity, efficiency, quality and more. Likewise, competition is foundational to blockchain systems. Widespread competition in mining provides resilience and security. Free market economies are threatened when competition is dimished, such as when monopolies form. Blockchain systems are threatened when a miner controls a majority of the mining resources (51% attack).

## Conclusion

Blockchain systems are able to effectively manage information in a trustless manner. They do this partly by utilizing the power of competition. If blockchains seem unbelievable, consider that many are still skeptical of free markets for similar reasons. In the words of Mark Twain:

"Truth is stranger than fiction."

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! Here are some dev updates courtesy of Igor Artomonov aka Splix.
- EthCore has accepted our pull request for Bomb Delay (ECIP-1010). Therefore Parity is fully compatible with Geth for our January upgrade
- The team has been working hard on stabilizing all ETC related code.
- Dev @Elaine made good progress on fixing cpp-ethereum for ETC (removed DAO fork support and so on).
- Dev @Sianyu is working on JS components for ETC Dapps, a valuable basement for building our Wallet and other Dapps to replace current Mist UI.
- Dev @prophetdaniel has been working on Mist itself, trying to make a workable build process for ETC Mist.
- Also, @avempace joined our EtherJar project, which is Java ETC client prospective for use in Fintech development.
- Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetary_policy channel on Slack.
- Please join us on Slack.
- For more information on community participation, please see this call to action post for guidance.

## "Call To Action" : Help with ETC Wikipedia page.

Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see the full post on reddit.

## Article from Cointelegraph about BTCC potentially choosing ETC: "Major Chinese Exchange BTCC Selects Ethereum Classic Over ETH"

## COO from BTCC confirms ETC integration plans: "It's something we plan to do - no timeframe yet." -Samson Mow​

## Article by Rocky from Cryptohustle: “Ethereum Classic Fundamentals.”

## "Let's Talk ETC" podcast/youtube show released: Let's Talk ETC episode 1. It will be a weekly show taking place every Tuesday at 7:30pm EST. Please subscribe to our channel for updates and announcements.

## Community Metrics:
- Twitter - 33,500 followers.
- Reddit /r/EthereumClassic - 2,835 subscribers.
- Slack - 1,428 users.
- Telegram - 786 users.
- WeChat - 481 users.
- Miners - 407.37 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days:
- NanoPool 106.51 GH/s
- F2pool 67.86 GH/s
- 91pool 53.59 GH/s
- EtherMine 41.28 GH/s
- Coinotron 20.55 GH/s

## Links To Our Community

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! Big shout out and many thanks to all the developers, community members, user's and investors. We have a special update this week from Snaproll regarding his monetary policy proposal which was in last week's newsletter. There is also a great report just released by IOHK breaking down the Dash governance/treasury model. Thank you for taking the time to read and distribute this newsletter, looking forward to your thoughts.

ETC monetary policy update courtesy of Snaproll.
- "I started doing some drafting of the ECIP for monetary policy and realized that we needed to get this thing airtight in terms of numbers, so I started reworking the spreadsheet used for analysis to enable better results......"
- Please see his full post from reddit.
- Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetary_policy channel on Slack.
- Please join us on Slack.
- For more information on community participation, please see this call to action post for guidance.

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. This week's show (11-15-16) will feature a special guest from the Dash community, Bill Cassidy. We will be discussing the Dash governance model as well as other blockchain centric topics. The link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/watch?v=jlYW2MLNzL8

## Report released by IOHK breaking down Dash governance model.

IOHK has just released a report that breaks down some of the pros and cons encompassing the Dash governance/treasury system. It's a very enlightening report that definitely benefits both the Dash and ETC community. Special thanks to the Dash community for always being so open to communication and collaboration.
- https://iohk.io/research/library/#NSJ554WR

## Interesting proof of work/proof of stake hybrid paper released.
Interesting proof of work/proof of stake hybrid paper released by Virgina Commonwealth University. A link to the paper as well as the discussion on reddit is posted below.
- https://eprint.iacr.org/2016/716.pdf
- reddit.com

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics:
- Twitter - 33,500 followers.
- Reddit /r/EthereumClassic - 2,836 subscribers.
- Slack - 1,453 users.
- Telegram - 786 users.
- WeChat - 476 users.
- Miners - 541.98 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days:
- NanoPool 112.89 GH/s
- 91pool 91.33 GH/s
- MiningPoolHub 72.08 GH/s
- EtherMine 50.38 GH/s
- Coinotron 35.33 GH/s

I will discuss money and monetary policy as well as give details regarding cryptocurrencies.

## What Is Money?

No one can create all the products and services they desire. Therefore, people exchange products and services. Money is an object that facilitates this exchange. Examples of money include convenient products such as rice and salt. More abstract examples of money include promissory notes like gold notes:

Another abstract example is a tally stick. It can record economic transactions much like a blockchain:

The most abstract examples of money are not associated with any product or service, and, they have little or no intrinsic value. An example is a dollar bill. The only intrinsic value is the value of the paper and ink. Another such example is a cryptocurrency key. It is a set of random numbers with no intrinsic value!

Money facilitates storage. It is more convenient to store dollar bills than say horses or eggs. Money also facilitates distribution. It is more convenient to send Bitcoin than say houses. Money also facilitates pricing. It is convenient to relate the values of all products and services to some single type of money.

## What Is Monetary Policy?

A monetary policy is a plan to manage a money supply. Some advocate fixed money supplies. Some advocate adjustable money supplies. In response to the Great Recession, many governments greatly increased their money supplies:

Satoshi Nakamoto set up Bitcoin to have a fixed long term money supply. He was likely concerned about the possibility of corruption otherwise. He placed the following Easter egg in the first (genesis) Bitcoin block: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". This refers to the following newspaper cover:

## What Sets Cryptocurrency Prices?

Cryptocurrency prices in general are not static. Satoshi Nakamoto avoided a central bank and accepted potentially fluctuating Bitcoin prices:
Satoshi Nakamoto 2009-02-18 20:50:00 UTC:
"You could say coins are issued by the majority. They are issued in a limited, predetermined amount... there is nobody to act as central bank... In this sense, it's more typical of a precious metal. Instead of the supply changing to keep the value the same, the supply is predetermined and the value changes."

Arguments can be made that cryptocurrency prices vary as the mining difficulty, and, therefore the mining cost. Satoshi Nakamoto believed this was true for Bitcoin. More people will presumably mine if that is cheaper than purchasing Bitcoin. That will increase the mining difficulty thereby bringing the mining cost closer to the price. Conversely, less people will presumably mine if that is more expensive than purchasing Bitcoin. That will decrease the mining difficulty thereby also bringing the mining cost closer to the price:
Satoshi Nakamoto 2010-02-21 05:44:24 UTC:
"The price... tends to gravitate toward[s] the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price. In later years, when new coin generation is a small percentage of the existing supply, market price will dictate the cost of production more than the other way around."

In addition to mining difficulty, fluctuations in cryptocurrency demand can affect prices. Satoshi Nakamoto believed that Bitcoin economy growth could offset the inflationary effects of the (temporarily) growing money supply:
Satoshi Nakamoto 2008-11-08 16:38:26 UTC:
"The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase."

Furthermore, the rate of Bitcoin money supply growth is decreasing. The money supply will never exceed 21 million BTC. These attributes should help control inflation. Satoshi Nakamoto believed lost Bitcoin would also help manage inflation due to the decrease of money in circulation:
Satoshi Nakamoto 2009-12-13 16:51:25 UTC:
"[T]here will be natural deflation due to payment mistakes and lost data. Coin creation will eventually get slow enough that... we'll have net deflation."

Unlike Bitcoin, Ethereum and Ethereum Classic currently do not have fixed long term money supplies. There are ongoing discussions in both communities about potential changes to their monetary policies. Any modifications will also likely affect prices.

## Conclusion

Cryptocurrencies are innovative types of money with monetary policies that in general have strong protections against abuse. Cryptocurrency prices can vary due to many factors. As more people understand these technologies, hopefully they will gain the confidence to benefit from them. In the words of the inventor of blockchains:
Satoshi Nakamoto 2008-11-14 17:29:22 UTC:
"It's very attractive to the libertarian viewpoint if we can explain it properly."

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! Big shout out and many thanks to all the developers, community members, users and investors. The proposal originally submitted by Snaproll is now officially on Github as ECIP-1017. We also have an article from Dr. Seberino discussing the basics of currency and monetary policy. Thank you for taking the time to read and distribute this newsletter, looking forward to your thoughts.

ETC Monetary Policy Proposal by @Snaproll is now officially out as ECIP-1017.
- "This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model."
- Please see his full post from Github and reddit.
- Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on Slack in the #monetary_policy channel.
- Please join us on Slack.
- For more information on community participation, please see this call to action post for guidance.

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. This week's show (11-22-16) will feature a special guests from the ETC mining community. We will be discussing mining as well as other of blockchain centric topics. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Article about the basics of currency released by Dr. Seberino.

"The Bare Basics Of Money And Monetary Policy With a Few Words From Satoshi Nakomoto."
- https://ethereumclassic.github.io/blog/2016-11-15-money-and-monetary-policy/

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33,500 followers.
- Reddit /r/EthereumClassic - 2,838 subscribers.
- Slack - 1,467 users.
- Telegram - 786 users.
- WeChat - 476 users.
- Miners - 504.46 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- 91pool 106.88 GH/s
- NanoPool 81.39 GH/s
- MiningPoolHub 64.08 GH/s
- F2pool 63.61 GH/s
- EtherMine 53.84 GH/s

## Introduction

Smart contracts, as defined by Nick Szabo, are computer systems that manage assets. Assets include money, votes, passports and reputation. Examples of smart contracts include supermarket checkout systems and automated teller machines.

## Actions & Agents

Smart contracts can perform actions. Automobile insurance plans might adjust rates hourly based on the weather or location. Washing machines might order replacement parts when needed.

Because smart contracts often operate autonomously, it might sometimes be more appropriate to refer to them as agents (autonomous software components). On the other hand, the original term emphasizes that they can manage many legal and financial agreements. An example of a smart contract that managed a financial agreement would be a television that stopped working when the loan payments were in arrears.

## Blockchains

Blockchain systems, such as Ethereum and Ethereum Classic, are ideal platforms for smart contracts (agents) because of their security, reliability and censorship resistance.

## Improved Communication

A major benefit of smart contracts is the improved communication. Uncertainties in legal and financial agreements such as confusing legalese and unintended loopholes incur huge costs. In contrast, smart contracts are deterministic and formal verification methods can help avoid mistakes.

Smart contracts can have the flexibility of legal contracts¹. For example, they can be designed to allow modifications when there are certain unforeseen events.

## Conclusion

Smart contracts can effectively manage assets removing a lot of the confusion of previous methods. Furthermore, when implemented on blockchain systems, they can have unprecedented levels of security, reliability and censorship resistance.

 1. Some have misinterpreted the saying, "Code is law!", as implying smart contracts somehow supercede legal systems. The intended meaning is that blockchain based smart contracts should be immutable and unstoppable like laws of nature.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank Gavin Wood for his informative papers and talks that have greatly helped clarify many of these ideas. I would also like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! Big shout out and many thanks to all the developers, miners, community members, user's and investors. Last week started off little hectic due to some network issues (detailed below) that the ETC network experienced for a few hours. I kept the monetary policy update from the last newsletter since it is still such a hot topic throughout the community. We also have an upcoming ETC event in London, an interview featuring Chandler Guo and another article from Dr. Seberino discussing smart contracts. Thank you for taking the time to read and distribute this newsletter, looking forward to hearing your thoughts.

ETC Monetary Policy Proposal by @Snaproll is now officially out as ECIP-1017.
- "This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model."
- Please see his full post from Github and reddit.
- Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on Slack in the #monetary_policy channel.
- Please join us on Slack.
- For more information on community participation, please see this call to action post for guidance.

## ETC Network Update
Hi everyone, please read this announcement about the network issues that were experienced last week.

The ETC network experienced an abnormally high level of orphans for a few hours on 11-23-16. The situation is still being investigated. If you suspended deposits/withdrawals, we consider it safe to resume deposits/withdrawals.

If anyone (especially miners) notices some suspicious behavior of their Parity node, please save the Parity log WITHOUT restarting Parity (as it overwrites its log upon restart). After the log is saved please send the log to splix@ethereumclassic.org (use tags #bugreport and #parity) for investigation.

Please read the bullet points below for answers to the most common questions:
- ETC network experienced issues for a few hours with abnormally high orphan rate and other effects.
- Causes and remedies still being investigated, it's safe to proceed with Parity 1.4.4, we will be investigating.
- Ethcore is aware and investigating with us as well.
- All versions of Parity and Geth are working normally.
- ETC does NOT have a geth/parity forking issue. The problems ETH experienced last week are unrelated to the ETC chain.

## ETC event in London scheduled for December 13th!

Dr. Avtar Sehra has organized an ETC event in London which will take place on Tuesday, December 13th, 2016.

The Event will be hosted by one of the leading financial services law firms, Eversheds LLP, at their London St. Pauls Head Quarters. They are in the process of confirming speakers and panelists from the BTC and ETC community.

Focus of the event will be to provide an update on the activity in the ETC community so far and what the future holds in terms of projected roadmap:
- Update on what has happened so far in the ETC Ecosystem.
- Planned monetary policy hard fork and why it matters.
- Panel discussion on monetary policy, economics and the future of cryptocurrency.
- Please see Dr. Sehra's twitter post below for more info.
https://twitter.com/avtarsehra/status/803292714267738112

## Cryptocoinnews.com interviews Chandler Guo.
"Chinese investor Chandler Guo, who has invested in various bitcoin and Ethereum Classic startups including major bitcoin mining pool BW.com....." Check out the link below for the full interview.
- https://www.cryptocoinsnews.com/chinese-investor-chandler-guo-world-gdp-will-based-bitcoin/

## Article about smart contracts released by Dr. Seberino.
"The Skinny On Smart Contracts: An Introduction & Why You Should Care."
- https://ethereumclassic.github.io/blog/2016-11-23-smart-contracts/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. This week's show (11-29-16) will feature a special guests from the ETC mining community. We will be discussing mining as well as other of blockchain centric topics. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33,500 followers.
- Reddit /r/EthereumClassic - 2,858 subscribers.
- Slack - 1,491 users.
- Telegram - 784 users.
- WeChat - 477 users.
- Miners - 428.15 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- 91pool 101.21 GH/s
- NanoPool 83.31 GH/s
- F2pool 27.56 GH/s
- EtherMine 46.85 GH/s
- ManekoETC 27.55 GH/s

## Introduction

The Internet is amazing but it is not as good as it can be. It is several decades old and was designed for a different environment. It does not provide adequate protections and support for the ways people actually use it:
- Security - Security was not a major design goal of the Internet. Data is vulnerable to hardware failures, censorship and attackers. Even today tools like Secure Sockets Layer (SSL), Pretty Good Privacy (PGP) and Domain Name System Security Extensions (DNSSEC) are not widely used. Security is optional :

- Mobile Devices - The Internet was designed to allow static computers to effectively communicate. Movement requires new wireless connections to be constantly set up. Furthermore, mobile device marketshare is growing :

- Broadcasting - The Internet was designed to allow two computers to effectively communicate. That is great for tasks such as sending email. However, today the majority of Internet traffic is broadcasting. Examples include Netflix and YouTube videos:

## Glimpses Of A Better Internet

Virtual private networks (VPNs) and Tor provide better security. Cell phone networks provide better support for mobile devices. BitTorrent provides better support for broadcasting. These give an idea of what a future improved Internet can look like.

## The InterPlanetary File System

The InterPlanetary File System (IPFS) is one noteworthy attempt to replace the current Internet. Security is built in by default. BitTorrent like broadcasting gives it better performance. Duplication of data across several computers provides censorship resistance and protection against hardware failures. There is even ongoing work to add support for mobile devices.

The Internet Protocol (IP) addresses devices. A major change in IPFS, relative to the current Internet, is to focus on addressing data. Notice that as long as copies of data are accurate, sources are irrelevant. Furthermore, IPFS addresses are based on cryptographic hashes making information virtually impossible to tamper with.

## Blockchains

Blockchains are not designed to effectively store vast amounts of data. This is why blockchain systems can greatly benefit from systems such as IPFS. Imagine a video smart contract, on Ethereum or Ethereum Classic, for which it would be prohibitively expensive to store the required videos on the blockchain. It would make much more sense to store the videos on IPFS and just store the corresponding IPFS addresses on the blockchain.

## Conclusion

There are efforts underway to greatly improve the Internet. These efforts will make the Internet faster, more secure and more mobile friendly for all of us. Blockchains will be able to effectively utilize these new architectures to allow the creation of many innovative applications in the near future. Stay tuned as it should be a wild ride.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank Van Jacobson for his brilliant Named Data Networking related papers and talks that have greatly helped clarify many of these ideas. I would also like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Please join us!

ETC End of Year and Monetary Policy Event The Event is hosted by one of the leading financial services law firms, Eversheds LLP, at their London St. Pauls Head Quarters. Attendance is free, but you need to register for the event. More information at the Event web site.

## Key Event Focus Points
1. Update on what has happened so far in the ETC Ecosystem and future roadmap
2. Overview of the planned ETC monetary policy Hard Fork and why it matters
3. Panel Discussion on Monetary Policy, Economics and the Future of Cryptocurrencies

## Panel: "Monetary Policy in Cryptocurrencies"

Jon Matonis:

Founding Director of the Bitcoin Foundation and his career has included senior influential posts at VISA International, VeriSign, Sumitomo Bank, and Hushmail. An economist and e-Money researcher focused on expanding the circulation of nonpolitical digital currencies, Jon also serves as an independent board director to companies in the Bitcoin, the Blockchain, mobile payments, and gaming sectors. A prominent fintech columnist with Forbes Magazine, American Banker, and CoinDesk, he recently joined the editorial board for the cryptocurrency journal Ledger. His early work on digital cash systems and financial cryptography has been published by Dow Jones and the London School of Economics.

Alistair Milne:

Founded and sold several companies over the past 15 years, including one IPO. Most of Alistair’s work has been in technology and web businesses. Over the last five years he has focused his efforts on the world of cryptocurrencies as both an Angel investor as well as manager of one of the few actively traded cryptocurrency funds. He is also an evangelist, writing and speaking about the new wave of innovation emerging from the convergence of digital technologies, cryptography and finance.

Edan Yago:

Experienced entrepreneur and seasoned veteran of the digital currency world. He is currently CEO & Founder of Epiphyte, a Bitcoin/Fiat Currency remittance company; which is one of the leading companies helping banks integrate with distributed ledgers for next generation payment services. Yago has led digital currency initiatives at Zynga and is a founding member of DATA, the leading digital asset industry regulatory body. Yago is an angel investor and advisor to several Bitcoin companies and is a thought leader in the space.

Matt Herbert:

Director at the British Bankers Association, where he is heading up the BBA’s digital policy and blockchain programme. Matthew works closely with member banks and other financial sector organisations to engage on key policy reforms, in order to support the sustainable digital transformation of the banking industry. His core focus is on the development and advocacy of industry policy, legislative, and regulatory reforms required in the UK, pan-EU, and Globally, to enable digital innovation in banking and FinTech. He is also an advocate of the core premise of immutable blockchains that have a native digital store of value. His other areas of focus are cognitive computing, big data analytics, homomorphic encryption and security. He is a former lawyer, with deep experience in the capital markets.

## Event Agenda
- Opening by Eversheds (5 min)
- ETC Event Introduction and Overview of Developing a Sustainable Open Ecosystem: Dr. Avtar Sehra (15 min)
- ETC Twitter Sentiment: Carlos Graterol, Manager of @eth_classic (5 min)
- Technology Progress to Date and Next Steps: Igor Artamonov, CTO Classic Development Labs (15 min)
- Overview of ETC Monetary Policy Proposal: Matthew Mazur, Architect of ECIP1017 (15 min)
- Panel Discussion: Monetary Policy in Cryptocurrencies (60 min)

## Please join us!

Attendance is free, but you need to register for the event. More information at the Event web site.

## Links To Our Community

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! Big shout out and many thanks to all the developers, miners, community members, user's and investors. This week's newsletter features some hints about a new team that will be joining the ETC community called "The Grothendieck Team". We are still keeping the monetary policy update from previous newsletters since it’s still the focus of many discussions throughout the community. We also have info about the upcoming ETC event in London, another article from Dr. Seberino and an article about governance models by Luis Molina. Thank you for taking the time to read and distribute this newsletter, looking forward to hearing your thoughts.

## The Grothendieck Team
IOHK is nearly finished with its vetting and onboarding process for the development team known as the "Grothendieck Team". The team has been named after Alexander Grothendieck, a German-born French mathematician who became the leading figure in the creation of modern algebraic geometry. They have been committed to Ethereum Classic by IOHK in order to build a Scala client for ETC based on IOHK's Scorex framework. An official announcement featuring the teams, background, past/current work experience, and bio will be posted in various channels. Plans are in place to bring the team on "Let's Talk ETC!" to discuss the roadmap and development timeframe for ETC in 2017, after they have had the chance to review all relevant ETC documentation properly. Links to the IOHK website, Scorex github, Let's Talk ETC youtube channel and ETC blog are posted below.
- www.iohk.io
- https://github.com/ScorexFoundation/Scorex
- https://www.youtube.com/channel/UCojbniTgg4BxcSphz0MGMg
- https://ethereumclassic.github.io/blog/2016-07-27-getting-things-done/

Also, we would love to know more about how the community would like to interact with and get reports from the new ETC developers. Please reply to this newsletter with ideas and requests for what you might like to see moving forward. You can also post your thoughts in this brainstorming thread from reddit.
- https://www.reddit.com/r/EthereumClassic/comments/5gpf3n/communitybrainstormideasforcontinuous/

## ETC Monetary Policy by Snaproll
"ECIP-1017 proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/

Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/

For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelp_ethereum/

## ETC event in London scheduled for December 13th!

Dr. Avtar Sehra has organized an ETC event in London which will take place on Tuesday, December 13th, 2016.

The Event will be hosted by one of the leading financial services law firms, Eversheds LLP, at their London St. Pauls Head Quarters. They are in the process of confirming speakers and panelists from the BTC and ETC community.

Focus of the event will be to provide an update on the activity in the ETC community so far and what the future holds in terms of projected roadmap:
- Update on what has happened so far in the ETC Ecosystem.
- Planned monetary policy hard fork and why it matters.
- Panel discussion on monetary policy, economics and the future of cryptocurrency.
- Please see Dr. Sehra's twitter post below for more info.
- https://twitter.com/avtarsehra/status/803292714267738112

## Article about Inter Planetary File Systems (IPFS) by Dr. Seberino.
"Why InterPlanetary File System & Its Ilk Are A Big Deal For Blockchains & Beyond"
- https://ethereumclassic.github.io/blog/2016-12-01-ipfs/

## Article about a Fermat Distributed Governance Model by Luis Molina
"Fermat Distributed Governance Model."
- https://medium.com/@luisfernandomolina/fermat-distributed-governance-model-1d90538d1bbc#.qq0i5wgog

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. This week's show (12-06-16) will feature a special guest from the ETC investment community. We will be discussing investment centric topics as well as blockchain in general. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33,500 followers.
- Reddit /r/EthereumClassic - 2,867 subscribers.
- Slack - 1,510 users.
- Telegram - 785 users.
- WeChat - 475 users.
- Miners - 511.74 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- NanoPool 109.14 GH/s
- 91pool 105.71 GH/s
- F2pool 98.38 GH/s
- EtherMine 53.05 GH/s
- Coinotron 43.23 GH/s

## Benefits Over The World Wide Web

The World Wide Web is one of the most successful software systems in history. It is a mature and widely supported platform for nearly all applications. Therefore, it might not seem like Ethereum Classic could offer a compelling alternative. Actually, it offers many benefits not provided by the World Wide Web:
- Security - The World Wide Web does not have strong security by default. Secure Sockets Layer (SSL) and Domain Name System Security Extensions (DNSSEC) are optional. There are also no builtin safeguards to prevent tampering with server data. Iran has successfully carried out man in the middle attacks against Google. China has successfully carried out man in the middle attacks against Github. On the other hand, Ethereum Classic provides much security by default. There are no insecure communications with remote computers. Also, it is virtually impossible to modify programs and data on the blockchain. (It is still possible to create insecure Ethereum Classic applications.)

- Censorship Resistance - The World Wide Web does not have strong censorship resistance by default. Megaupload was a file storage website that was successfully taken down by the United States government. On the other hand, Ethereum Classic applications are copied to several computers. Censoring these applications would require attacking every computer on the network!

- Reliability - The World Wide Web does not have strong reliability guarantees by default. Web servers are vulnerable to hardware failures. Many web services have suffered downtime due to Amazon Web Services outages. On the other hand, because Ethereum Classic applications are copied to several computers, downtime can only happen when every computer on the network fails!

- Public - Although web pages are public, web server operations are not by default. Wells Fargo intentionally opened over one million improper accounts for customers. Many were charged fees for these accounts. If their actions were public, this could have been discovered sooner or even prevented. On the other hand, Ethereum Classic is always auditable by anyone anytime!

- Trustless - The World Wide Web requires trust in the administrators of websites to not do anything malicious. On the other hand, Ethereum Classic does not require trust in anyone!

## Conclusion

Ethereum Classic provides many advantages not possible, or not provided by default, with the World Wide Web. You may want to take it for a test drive to see for yourself.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

ETC-IOHK Team

## The Grothendieck Team
Hi everyone, it's my pleasure to officially announce the new team known as The Grothendieck Team! The team has been named after Alexander Grothendieck, a German-born French mathematician who became a leading figure in the creation of modern algebraic geometry. They have been committed to Ethereum Classic by IOHK in order to build a Scala client for ETC based on IOHK's Scorex framework. Plans are in place to bring the team on "Let's Talk ETC!" to discuss the roadmap and development timeframe for ETC in 2017 (after they have properly reviewed the ETC documentation). Links to the IOHK website, Scorex page, Let's Talk ETC! youtube channel and ETC blog are posted below.
- IOHK-Ethereum Classic
- IOHK-Scorex
- Let's Talk ETC! on youtube.com
- Ethereumclassic.github.io/blog

Also, we would love to know more about how the community would like to get updates from the new ETC developers. Please let us know what you might like to see moving forward, post your thoughts in the brainstorming thread below or contact us on Slack, Twitter or Facebook.
- www.reddit.com

## Alan McSherry : Dublin, Ireland
Ethereum Classic Developer
Team Grothendieck Manager

Alan McSherry graduated with a degree in Computer Engineering from Limerick University In Ireland and has spent well over a decade at the cutting edge of technology as a developer, CTO, consultant, entrepreneur and everything in between. A strong interest in the nature of money and the positive disruption technology can bring means he is currently having a ball writing blockchain code in scala!

## Alan Verbner : Buenos Aires, Argentina
Ethereum Classic Developer
Team Grothendieck/Atix

Alan Verbner is a computer engineer and graduated from the Engineering University of Buenos Aires (Argentina). He has been developing software for about 10 years with special interest in the cryptocurrency space. Four years ago he Co-Founded Atix Labs, a software lab that has been helping other companies make their ideas come true with great high quality products. They are located in the Buenos Aires Bitcoin Embassy.

## Nicolas Tallar : Buenos Aires, Argentina
Ethereum Classic Developer
Team Grothendieck/Atix

Nicolas Tallar has a background in Computer Science and he is about to get his degree from University Of Buenos Aires (Argentina). He is a passionate functional programmer with special interest in image processing and robot controlling algorithms.

## Jan Ziniewicz : Warsaw, Poland
Ethereum Classic Developer
Team Grothendieck

I’ve been working in IT industry since 2004. Apart from being a functional programmer I was also a project manager, system designer and administrator. In my free time I am a rock climber, cyclist, RPG player, and of course Clojure / Scala coder.

## Lukasz Gasior : Rumia, Poland
Ethereum Classic Developer
Team Grothendieck/ScalaC

I’m a passionate Scala developer and a big fan of Domain Driven Design. For the past 3 years I’ve been working on various sized commercial (and non-commercial) Scala projects. I’m a cryptocurrency and blockchain technology enthusiast. Privately I like to travel and taste craft beer.

## Adam Smolarek : Warsaw, Poland
Ethereum Classic Developer
Team Grothendieck/ScalaC

I’ve been working as software developer since 2010, both fornt and back-end, I was also team leader and arhitect. Hobby: digital drawing, rock climbing, skateboarding, IoT (did master thesis in realated topic), cryptography (ECC).

## Radek Tkaczyk : Warsaw, Poland
Ethereum Classic Developer
Team Grothendieck/ScalaC

I’ve been developing in Scala since 2012 for a number of commercial clients. Having started my adventure with programming at the age of 13 this was a natural choice of a career path. However I’ve always had a fondness for abstract and pure ideas which is why I’m especially keen on working in a field so heavily reliant on mathematics. Outside of work I actively enjoy various sports, especially cycling and fitness as well as those for the mind like chess and - my latest passion - cue sports.

## Links To Our Community

ETC Website

ETC Reddit

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! Big shout out and many thanks to all the developers, miners, community members, user's and investors. The monetary policy meetup in London was excellent, special thanks to our panelists, Splix, Snaproll, Avtar and Eversheds LLP who hosted the event. I'm happy to let everyone know that it was professionally recorded so footage of the event will be released soon. Also featured in this week's newsletter is the official introduction of the new IOHK dev team dubbed "The Grothendieck Team". We are still keeping the monetary policy update from previous newsletters since it's still the focus of many discussions throughout the community. Some new media that just came out recently is the new ETC newspaper updated daily "ETC.today", it's a pleasure to read and I really recommend checking it out. We also have an article from Aaron van Wirdum of Bitcoin Magazine, another article from Dr. Seberino and FTreporter.com. Thank you for taking the time to read and distribute this newsletter, looking forward to hearing your thoughts.

## ETC monetary policy meetup was excellent!
The event organized by Dr. Avtar Sehra London which took place on Tuesday, December 13th, 2016 was excellent. The Event was hosted by one of the leading financial services law firms, Eversheds LLP, at their London St. Pauls Head Quarters. The focus of the event was to provide an update on the activity in the ETC community so far and what the future holds in terms of projected roadmap. The topics covered during the presentation included:
- An update on what has happened so far in the ETC Ecosystem.
- A presentation by ETC dev "Splix".
- A presentation by "Snaproll", author of the monetary policy proposal ECIP-1017
- Planned monetary policy hard fork and why it matters.
- Panel discussion on monetary policy, economics and the future of cryptocurrency.

The event was professionally recorded so expect some great media of the event coming out soon.

## Introducing The Grothendieck Team
It’s my pleasure to officially announce the new team known as The Grothendieck Team! The team has been named after Alexander Grothendieck, a German-born French mathematician who became a leading figure in the creation of modern algebraic geometry. They have been committed to Ethereum Classic by IOHK in order to build a Scala client for ETC based on IOHK’s Scorex framework. Plans are in place to bring the team on “Let’s Talk ETC!” to discuss the roadmap and development timeframe for ETC in 2017 (after they have properly reviewed the ETC documentation). Links to the IOHK website, Scorex page, Let’s Talk ETC! youtube channel and ETC blog are posted below.
- IOHK-Ethereum Classic
- IOHK-Scorex
- Let’s Talk ETC! on youtube.com
- Introducing Team Grothendick

Also, we would love to know more about how the community would like to get updates from the new ETC developers. Please let us know what you might like to see moving forward, post your thoughts in the brainstorming thread below or contact us on Slack, Twitter or Facebook.
- Brainstorm thread on reddit.com

## ETC Monetary Policy

ETC Monetary Policy Proposal by @snaproll is now officially out as ECIP-1017
"This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its currentEthash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/
Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/
For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelpethereum/

## Check out ETC.today!
Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Article from Aaron van Wirdum of Bitcoin Magazine.
"Ethereum Classic Forges New Path; Revamped Monetary Policy Could Be Next."
- https://bitcoinmagazine.com/articles/ethereum-classic-forges-new-path-revamped-monetary-policy-could-be-next-1481656302

## Article about blockchain vs standard web by Dr. Seberino.
"Why Would I Choose To Run My Application On Ethereum Classic Instead Of The World Wide Web?"
- https://steemit.com/etc/@cseberino/why-would-i-choose-to-run-my-application-on-ethereum-classic-instead-of-the-world-wide-web

## Article from FT Reporter about running smart contracts.
"Ethereum Classic: designed to run smart contracts."
- http://ftreporter.com/ethereum-classic-designed-to-run-smart-contracts/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. Last week's show (12-06-16) featured a special guest from the ETC investment community. We discussed investment related topics as well as blockchain in general. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33.5K followers.
- Reddit /r/EthereumClassic - 2,887 subscribers.
- Slack - 1,556 users.
- Telegram - 785 users.
- WeChat - 475 users.
- Miners - 807.95 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 221.04 GH/s
- NanoPool 169.65 GH/s
- 91pool 91.85 GH/s
- F2pool 52.47 GH/s
- Coinotron 37.18 GH/s

## Introduction

You can easily get your own Ethereum Classic network node up and running with the phenomenal Parity implementation. The Parity project is managed by Gavin Wood, the author of the Ethereum specification (yellow paper), and his company Ethcore.

## Setup

The first step is to download and install the latest Parity package for your system after confirming its integrity by checking its hash. After Parity is installed, the only remaining step to set up a node is to run the following command:

The set up should take a several hours to download a copy the Ethereum Classic blockchain. It will use about seven gigabytes of storage. Parity is able to survive interuptions such as power outtages. Just restart Parity in the event of an interruption and all should be fine. It is amazing that with these few steps one can easily add an Ethereum Classic node to the network and join the revolution!

## Communication

Parity nodes have a local web interface one can access by default at http://127.0.0.1:8180. There are other powerful user friendly tools it will be beneficial to investigate such as the Web3 library. Parity nodes communicate using JavaScript Object Notation (JSON). For educational purposes, I will show examples of sending and receiving JSON commands using only the following simple Python script:

Save the code above in a file called node_cmd and make it executable. By running this program, and adding various command line parameters, one can get much information from a node. For example, one can see if a node is syncing with the following command:

One can see the software version of a Parity node with the following command:

The following command will display how many other nodes a node is connected to:

This command will display the number of the latest block on the blockchain:

These commands will display information about any block by its number or hash:

These commands will display information about any transaction by its hash or index in a block:

These commands will display information about any uncle by its index in a block:

This command will display the total number of transactions sent from any account by its address:

This command will display the Ethereum Classic virtual machine code of any contract by its address:

Here is a slightly edited actual session with an Ethereum Classic Parity node running on a Linux computer:

## Conclusion

Parity is an amazing solid Ethereum Classic network node implementation you can easily get operational. The aforementioned code examples should be enlightening. Feel free to extend my script and investigate further. Welcome to the future!

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Reddit

ETC Today

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! Big shout out and many thanks to all the developers, miners, community members, user's and investors. The monetary policy meetup in London last week was really special so I'm going to leave it in this week's newsletter in case anyone missed it. Special thanks again to our panelists, Splix, Snaproll, Avtar and Eversheds LLP who hosted the event. I'm happy to let everyone know that it was professionally recorded so footage of the event will be released soon. I leaving in the introduction of the new IOHK dev team dubbed "The Grothendieck Team" as well as the monetary policy update from previous newsletters since it's still the focus of many discussions throughout the community. Be sure to check out ETC newspaper updated daily "ETC.today", it's a pleasure to read and I really recommend it. We also have an instructional video series on mining that our friends over at Epool just started. Additionally, there is another article from Dr. Seberino about setting up an ETC node as well as an article from cryptocoinsnews.com. Thank you for taking the time to read and distribute this newsletter, looking forward to hearing your thoughts.

## ETC monetary policy meetup was excellent!
The event organized by Dr. Avtar Sehra London which took place last week on Tuesday, December 13th, 2016 was excellent. It was hosted by one of the leading financial services law firms, Eversheds LLP, at their London St. Pauls Head Quarters. The focus of the event was to provide an update on the activity in the ETC community so far and what the future holds in terms of projected roadmap. The topics covered during the presentation included:
- An update on what has happened so far in the ETC Ecosystem.
- A presentation by ETC dev "Splix".
- A presentation by "Snaproll", author of the monetary policy proposal ECIP-1017
- Planned monetary policy hard fork and why it matters.
- Panel discussion on monetary policy, economics and the future of cryptocurrency.

The event was professionally recorded so expect some great media of the event coming out soon.

## The Grothendieck Team
In case you missed it, last week we officially announce the new team known as The Grothendieck Team! The team has been named after Alexander Grothendieck, a German-born French mathematician who became a leading figure in the creation of modern algebraic geometry. They have been committed to Ethereum Classic by IOHK in order to build a Scala client for ETC based on IOHK’s Scorex framework. Plans are in place to bring the team on “Let’s Talk ETC!” to discuss the roadmap and development timeframe for ETC in 2017 (after they have properly reviewed the ETC documentation). Links to the IOHK website, Scorex page, Let’s Talk ETC! youtube channel and ETC blog are posted below.
- IOHK-Ethereum Classic
- IOHK-Scorex
- Let’s Talk ETC! on youtube.com
- Introducing Team Grothendick

Also, we would love to know more about how the community would like to get updates from the new ETC developers. Please let us know what you might like to see moving forward, post your thoughts in the brainstorming thread below or contact us on Slack, Twitter or Facebook.
- Brainstorm thread on reddit.com

## ETC Monetary Policy

ETC Monetary Policy Proposal by @snaproll is now officially out as ECIP-1017
"This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its currentEthash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/
Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/
For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelpethereum/

## Check out ETC.today!
Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Instructional video series on mining released by Epool.
"Epool - Ethereum Classic Mining."
- https://www.youtube.com/channel/UCbE_HTAVD08mMQ5jBBUgKGw

## Article from Dr. Seberino about setting up an Ethereum Classic node.
"Why Would I Choose To Run My Application On Ethereum Classic Instead Of The World Wide Web?"
- https://ethereumclassic.github.io/blog/2016-12-16-parity/

## Article from Cryptocoinsnews.com
"How Classic is Ethereum’s Austrian Kin.”
- https://www.cryptocoinsnews.com/ethereum-austrian-kin/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. This weeks show (12-20-16) features special guest Matt M aka "Snaproll" who is the creator of the monetary policy proposal featured in this newsletter. We will discuss monetary policy, ETC and blockchain in general. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33.1K followers.
- Reddit /r/EthereumClassic - 2,836 subscribers.
- Slack - 1,567 users.
- Telegram - 785 users.
- WeChat - 475 users.
- Miners - 1002.37 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 269.48 GH/s
- NanoPool 198.32 GH/s
- 91pool 156.62 GH/s
- Private Pool 58.98 GH/s
- F2pool 48.62 GH/s

## Basic Definition

Zero knowledge proofs are proofs that do not reveal any information except the statement being proved.

## Ben & Jerry

Ben wants to prove to Jerry that he knows the passcode associated with an automated teller machine (ATM) card. Therefore, he performs an ATM deposit and withdrawal without divulging the passcode entered. Ben has made a zero knowledge proof!

A zero knowledge proof must not leak information. Therefore, Ben must select an ATM in an enclosed area to prevent someone reading the passcode with a telescope. For the same reason, all security cameras must be covered or disabled. Temperature changes due to ATM key presses must be removed lest they create yet another way to determine the passcode. Ben also cannot only deposit or only withdraw money because that would reveal information about the balance. Preventing information leakage is not easy!

A zero knowledge proof method must not be able to prove false statements. This is referred to as the soundness property. If Ben does not know the passcode, he should not be able to fool Jerry by various tricks. He should not be able to fake a deposit by stashing money somewhere. He should also not be able to fake a withdrawal by using money hidden on his person or near the ATM. Therefore, the ATM and surrounding area must be searched before and after the deposit. For the same reason, Ben must disrobe and undergo a full body cavity search before and after the deposit!

Only with all the necessary steps preventing Ben from leaking information, and Jerry from being fooled, is the zero knowledge proof valid.

## Current Methods

Many current zero knowledge proof methods are interactive. They require the exchange of nonces, or some equivalent, to protect against replay attacks (replaying transmitted text).

Many current zero knowledge proof methods only establish a high probability of a statement being true. Technically they are not providing proofs but rather only strong evidence. However, this evidence often provides absurdly high probabilities of truthfulness.

## Some Applications

Zero knowledge proofs might improve authentication systems. Imagine how secure password based systems will be if they only require zero knowledge proofs of password possession. Adequate systems, for many applications, are already available with public key encryption!

Zero knowledge proofs might eliminate the need for many escrow services. Imagine people trying to get paid for performing lengthy computations. They do not want to disclose their results before being compensated, and, customers do not want to pay up before confirming the work done. Zero knowledge proofs might provide the necessary guarantees in a way that pleases everyone.

Zero knowledge proofs might lead to amazing blockchain applications that can also protect privacy. zk-SNARKs are zero knowledge proof methods that are currently being used on the Zcash blockchain!

## Parting Thoughts

Zero knowledge proofs might improve authentication systems, eliminate escrow services, add privacy to blockchain applications, and, do much more. Who would have guessed research in an abstract field of mathematics would have so many consequences!

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Reddit

ETC Today

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! This will be the last newsletter of the year and it's incredible thinking about how much the community has progressed since the beginning. I want to send out one last giant end of the year thank you to all the developers, miners, community members, user's and investors. It has definitely been a real roller coaster ride but the entire community has done such an excellent job working together, I couldn't be happier.

A lot was going on last week, so this newsletter is packed. Security is of the utmost importance, so the lead off story is in reference to some users having trouble finding peers with Geth after a fresh install, please see the link/instructions for more info. Also featured is the "DieHard" protocol upgrade coming in January 15 at block 3,000,000. Thank you to everyone that contributed to "DieHard", nothing would be possible without all the hard work ETC devs put in. The protocol upgrade includes:
- Difficulty Bomb delay (ECIP-1010)
- EXP reprice (EIP-160)
- Replay Protection (EIP-155)

The other stories in this newsletter are listed below:
- ETC on the lookout for Rust and JS devs.
- ETC exchange launches.
- Ethereum Classic now available at Échange de Montréal.
- Use ETC to buy any OpenBazaar item via ShapeShift integration.
- Two recent IOHK publications(1 - 2).
- BTCC mining pool adding to ETC hashrate.
- ETCWin ICO thank you meeting and celebration!
- Check out ETC.today!
- Instructional video series on mining released by Epool.
- Article from Dr. Seberino about zero knowledge proofs.
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom.

I'm really looking forward to an outstanding 2017. Hope everyone's holiday season went well and on behalf of the ETC community I'd like wish you all a Happy New Year!

## Trouble finding peers with Geth?
Several ETC geth users reported problems connecting to peers after a fresh install. If your full node has trouble finding peers, you may want to try adding static peer file manually. An up-to-date list of ETC peers maintained by Epool can be found here:
- http://www1.epool.io/enodes.txt

This list of nodes should be added to ".ethereum/static-nodes.json".

## Update ETC Geth 3.2.3 aka "DieHard".

Diehard protocol upgrade coming in January 15 at block 3,000,000 is ready for release. DieHard protocol upgrade includes:
- Difficulty Bomb delay (ECIP-1010)
- EXP reprice (EIP-160)
- Replay Protection (EIP-155)
- Github:https://github.com/ethereumproject/go-ethereum/releases/tag/v3.2.3

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## ETC Exchange Launches
If you would like more details please check out the following links:
- http://bizhongchou.com/deal-show/id-367.html
- https://www.etcwin.com/

English and other languages are underway for the website. If you have any questions please send them to etcwin@wident.cn.

## Ethereum Classic now available at Échange de Montréal.
"Several of you have asked when we will be offering any alternative cryptocurrency apart from Bitcoin. We have been keeping an eye on other emerging cryptocurrencies and EDM is happy to announce that we will be selling Ethereum Classic (ETC) starting today!....."
- https://medium.com/@ferdousbhai/buying-ethereum-classic-now-available-at-%C3%A9change-de-montr%C3%A9al-d12a67018d11#.5kzeq2bgc

## Use ETC to buy any OpenBazaar item via ShapeShift integration.
"Today ShapeShift.io, a Blockchain asset exchange platform, has partnered with online bitcoin-enabled marketplace OpenBazaar via their integration of the ShapeShift Shifty Button. This integration allows OpenBazaar shoppers to purchase items....."
- http://www.the-blockchain.com/2016/12/20/decentralized-marketplace-openbazaar-integrates-shapeshift-allowing-payment-with-any-digital-asset/

## Two recent IOHK publications.
Ouroboros: A provably secure proof-of-stake blockchain protocol.
- https://eprint.iacr.org/2016/889

Scripting smart contracts for distributed ledger technology.
- https://eprint.iacr.org/2016/1156

## BTCC mining pool adding to ETC hashrate.
"Plans getting realized. BTCC ETC mining pool already above 40GHz and increasing."
- https://twitter.com/benvh/status/810755489621491712

## ETCWin ICO thank you meeting and celebration!
Check out the tweet below from ETC China.
- https://twitter.com/ETCChina/status/810287857331879936

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Instructional video series on mining released by Epool.
Epool - Ethereum Classic Mining.
- https://www.youtube.com/channel/UCbEHTAVD08mMQ5jBBUgKGw

## Article from Dr. Seberino about zero knowledge proofs.

"Zero Knowledge Proofs For Dummies."
- https://steemit.com/etc/@cseberino/zero-knowledge-proofs-for-dummies

## Let's talk ETC! Tuesdays at 7:30pm EST.

Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. Last weeks show (12-20-16) features special guest Matt M aka "Snaproll" who is the creator of the monetary policy proposal featured in this newsletter. We will discuss monetary policy, ETC and blockchain in general. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## ETC Monetary Policy

ETC Monetary Policy Proposal by @snaproll is now officially out as ECIP-1017

"This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/

Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/

For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelp_ethereum/

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33.1K followers.
- Reddit /r/EthereumClassic - 2,905 subscribers.
- Slack - 1,606 users.
- Telegram - 791 users.
- WeChat - 465 users.
- Miners - 953.58 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 156.82 GH/s
- 91pool 132.67 GH/s
- NanoPool 129.20 GH/s
- Private Pool 117.96 GH/s
- MiningPoolHub 90.56 GH/s

## Links To Our Community

ETC Website

ETC Reddit

ETC Today

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! This is the first newsletter of 2017 and it’s looking like this year is going to be incredible. The blockchain bull is in full effect and as I’m writing this, the entire top 20 by market capitalization is in the green. Special thanks to all the developers, miners, user's, investors and other community members that made 2016 so special.

Featured in this week’s newsletter is the upcoming "DieHard" protocol upgrade which is going to occur at block 3,000,000 around ~Jan 15th. Thank you to everyone that contributed to "DieHard", nothing would be possible without all the hard work ETC devs put in. The protocol upgrade includes:
- Difficulty Bomb delay (ECIP-1010)
- EXP reprice (EIP-160)
- Replay Protection (EIP-155)

The other big story is the CEO of CoinBase (Brian Armstrong) is considering the addition of ETC. Check out the post below to vote.
- https://twitter.com/brianarmstrong/status/81607874996369408

Last week's newsletter was jam packed with great news all over the place so I'm going to leave it in for one more run. It was a fun/busy holiday season so I'll leave everything in just in case anyone out there didn't get a chance to check it out. The other stories in this newsletter are listed below:
- Trouble finding peers with Geth?
- ETC on the lookout for Rust and JS devs.
- ETC exchange launches.
- Ethereum Classic now available at Échange de Montréal.
- Use ETC to buy any OpenBazaar item via ShapeShift integration.
- Two recent IOHK publications(1 - 2).
- BTCC mining pool adding to ETC hashrate.
- ETCWin ICO thank you meeting and celebration!
- Check out ETC.today!
- Instructional video series on mining released by Epool.
- Article from Dr. Seberino about zero knowledge proofs.
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom.

I'm really looking forward to an outstanding 2017. Hope everyone's holiday season went well and on behalf of the ETC community I'd like wish you all a Happy New Year!

## ETC Geth 3.2.3 protocol upgrade aka "DieHard".
"A release ready for Diehard protocol upgrade coming in at block 3,000,000 around ~Jan 15th. The protocol upgrade includes:
- Difficulty Bomb delay (ECIP-1010)
- EXP reprice (EIP-160)
- Replay Protection (EIP-155)

## CEO of CoinBase BrianArmstrong considering adding ETC!

Quote from Brian Armstrong below.
- "Yes - I'm thinking now that may have been a mistake. I'm not opposed to adding ETC if there is interest."

He also posted a poll for communities to let CoinBase know what currency they would like to see. Let him know you would like CoinBase to add ETC!
- https://twitter.com/brianarmstrong/status/816078749963694080

## Trouble finding peers with Geth?
Several ETC geth users reported problems connecting to peers after a fresh install. If your full node has trouble finding peers, you may want to try adding static peer file manually. An up-to-date list of ETC peers maintained by Epool can be found here:
- http://www1.epool.io/enodes.txt

This list of nodes should be added to ".ethereum/static-nodes.json".

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## ETC Exchange Launches
If you would like more details please check out the following links:
- http://bizhongchou.com/deal-show/id-367.html
- https://www.etcwin.com/

English and other languages are underway for the website. If you have any questions please send them to etcwin@wident.cn.

## Ethereum Classic now available at Échange de Montréal.
"Several of you have asked when we will be offering any alternative cryptocurrency apart from Bitcoin. We have been keeping an eye on other emerging cryptocurrencies and EDM is happy to announce that we will be selling Ethereum Classic (ETC) starting today!....."
- https://medium.com/@ferdousbhai/buying-ethereum-classic-now-available-at-%C3%A9change-de-montr%C3%A9al-d12a67018d11#.5kzeq2bgc

## Use ETC to buy any OpenBazaar item via ShapeShift integration.
"Today ShapeShift.io, a Blockchain asset exchange platform, has partnered with online bitcoin-enabled marketplace OpenBazaar via their integration of the ShapeShift Shifty Button. This integration allows OpenBazaar shoppers to purchase items....."
- http://www.the-blockchain.com/2016/12/20/decentralized-marketplace-openbazaar-integrates-shapeshift-allowing-payment-with-any-digital-asset/

## Two recent IOHK publications.
Ouroboros: A provably secure proof-of-stake blockchain protocol.
- https://eprint.iacr.org/2016/889

Scripting smart contracts for distributed ledger technology.
- https://eprint.iacr.org/2016/1156

## BTCC mining pool adding to ETC hashrate.
"Plans getting realized. BTCC ETC mining pool already above 40GHz and increasing."
- https://twitter.com/benvh/status/810755489621491712

## ETCWin ICO thank you meeting and celebration!
Check out the tweet below from ETC China.
- https://twitter.com/ETCChina/status/810287857331879936

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Instructional video series on mining released by Epool.
Epool - Ethereum Classic Mining.
- https://www.youtube.com/channel/UCbEHTAVD08mMQ5jBBUgKGw

## Article from Dr. Seberino about zero knowledge proofs.

"Zero Knowledge Proofs For Dummies."
- https://steemit.com/etc/@cseberino/zero-knowledge-proofs-for-dummies

## 2 articles from CoinDesk.

"Ether Classic Surges to More Than 4-Month High ."
- http://www.coindesk.com/ether-classic-surges-4-month-high/

"Ethereum classic pushes forward​....."
- http://www.coindesk.com/suspense-lingers-bitcoins-price-eyes-1000/

## Let's talk ETC! Tuesdays at 7:30pm EST.

Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. Last weeks show (12-20-16) features special guest Matt M aka "Snaproll" who is the creator of the monetary policy proposal featured in this newsletter. We will discuss monetary policy, ETC and blockchain in general. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## ETC Monetary Policy

ETC Monetary Policy Proposal by @snaproll is now officially out as ECIP-1017

"This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/

Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/

For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelp_ethereum/

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33.1K followers.
- Reddit /r/EthereumClassic - 2,939 subscribers.
- Slack - 1,629 users.
- Telegram - 783 users.
- WeChat - 472 users.
- Miners - 885.04 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 181.66 GH/s
- NanoPool 180.24 GH/s
- 91pool 173.73 GH/s
- Private Pool 109.76 GH/s
- F2pool 80.06 GH/s

Alas, our technology has marched ahead of our spiritual and social evolution, making us, frankly, a dangerous people.
Steven M. Greer

## Inherent Sustainability

One of the core values of Ethereum Classic has always been sustainaility due to several reasons specially as a perpetuation strategy for not only ETC community but the human species itself.
We now have new opportunities ahead to broaden ETC presence in the blockchain space by collaborating to include wider measures of value and thus becoming instrumental in achieving the United Nation's Sustainable Development goals.

## World has changed

Recently the COP21 conference raised diplomatic bars and was regarded as a monumental triumph and a victory for the planet.
It sets the stage for progress in ending poverty, strengthening peace and ensuring a life of dignity and opportunity for all.
Ban Ki-moon in a tweet, immediately following its adoption.

195 countries are signators of the COP21 conference and they are naturally pushed to deliver sustainable results over the next decades because of their already signed commitment.
In other words there's increased interest and funding available to initiatives able to bring closer to reality the UN target for a more sustainable world at 2030.

### Fintech Development Lab
Tomorrow, operating through the UN Innovation Centre, the Blockchain Alliance for Good launches its Fintech development lab to deliver the United Nations Sustainable, Development Goals.
In a nutshell, the effort brings social innovation through the power of the blockchain to truly engage and empower communities to achieve structural and sustainable change.

This is a very exciting collaboration of leading global institutions to accelerate the achievement of the Sustainable Development Goals
Barbara Mellish, President of the Blockchain Alliance for Good

### ETC China Support

ETC China is one of the powers behind ETC community and has already signaled its support to the initiative.
Blockchain would have huge impact on civil society in positive ways.
United Nation's Sustainable Development Goals is the perfect case how technology can improve human being’s happiness.
Roy Zou, Chairman of Ethereum Classic Consortium (ECC) in Chinese community, Founder & CEO of BITKIO, Co-founder of Fundonomy

### Centre for Citizenship Enterprise and Governance Support

The CCEG is a Think Tank focussing on the movement of non-financial and social value. It has also signaled it is supportive of the idea.
We are honoured to harness the technology, influence and inspiration of ETC community and ETC China to support this programme. Together we will guarantee its success
Olinga Ta'eed, Director of the Centre for Citizenship Enterprise and Governance

## Call for Action
In these terms I invite you fellows to become part of this technological revolution the world is recently experiencing with the advent of the blockchain in the social innovation space!
Let's participate identifying opportunities in this regard and taking action whenever positive outcome is most likely expected.
- Participate of the ETC Sustainable Growth Slack channel
- Register your support or offer your services at bisgit.iov

Let's make sure our spiritual and social evolution will march together with technology!

## Links To Our Community

ETC Website

ETC Reddit

ETC Today

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! This is the second newsletter of 2017 and ETC is off to a fantastic start. On Friday January 13th at block 3,000,000 the ETC community moved forward into the future with the protocol upgrade/hardfork dubbed "DieHard". The "DieHard" upgrade included the following protocol improvements:
- Difficulty Bomb delay (ECIP-1010)
- EXP reprice (EIP-160)
- Replay Protection (EIP-155)

I can't thank the ETC development community enough for all the hard work and countless hours they put in to make sure ETC is the most stable, secure platform that it can possibly be. I'd also like to thank the miners, exchanges, investors, traders and other community members for committing themselves to some of the best teamwork I have ever seen. The ETC community consists of countless countries, languages, cultures and ideas but the communication and teamwork managed to transcend all of those obstacles. This teamwork has helped thrust the ETC project into a stronger position than I could have ever imagined 6 months ago. An article by Aaron Van Wirdum covering the successful update was featured in Bitcoin Magazine as well as nasdaq.com.

The other stories featured in this newsletter are listed below:
- New footage from ETC event in London.
- Article from community member Prophet Daniel.
- New mining video from Epool.
- ETF potential for ETC.
- New articles by Dr. Seberino.
- ETC blog by community member "Jerry".
- Article from TechCrunch.
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

## "Ethereum Classic Hard Forks; Diffuses Difficulty Bomb"
Article from Aaron Van Wirdum about the protocol upgrade/hardfork featured in Bitcoin Magazine as well as nasdaq.com.
- https://bitcoinmagazine.com/articles/ethereum-classic-hard-forks-diffuses-difficulty-bomb-1484350622/
- http://www.nasdaq.com/article/ethereum-classic-hard-forks-diffuses-difficulty-bomb-cm733563

## New footage from ETC monetary policy event in London.
Footage of the ETC monetary policy event in London, please comment on youtube to let us know your thoughts.
- https://www.youtube.com/watch?v=0oBuc6uICTc

## Sustainable Development Goals

Article about sustainable development goals and other topics from Prophet Daniel.
- https://ethereumclassic.github.io/blog/2017-01-06-sustainable-development-goals/?platform=hootsuite

## New Instructional Video

New instructional video from Epool has been released.
- https://www.youtube.com/watch?v=WmhpYrmTav8

## Comments by Barry Silbert and DCG about an ETF for ETC.

"The DCG CEO is so drawn to Ethereum Classic that he may be interested in building a publicly traded ETF for the alternative digital currency. Such a move......."
- https://bitcoinmagazine.com/articles/barry-silbert-shares-digital-currency-group-s-perspective-on-ethereum-announces-etherscan-investment-1483989140/

## New articles by Dr. Seberino.
"Hashes: An Introduction & Why They Are Foundational To The Internet & Blockchains​"
- https://steemit.com/etc/@cseberino/hashes-an-introduction-and-why-they-are-foundational-to-the-internet-and-blockchains

"Why Bloom Filters Are So Cool (+ Useful!) For Blockchains & Beyond: An Introduction​"
- https://steemit.com/etc/@cseberino/why-bloom-filters-are-so-cool-useful-for-blockchains-and-beyond-an-introduction

## Check out this ETC blog from community member "Jerry".
"Classic Ether, ETC Community Updates​"
- https://medium.com/@classicether

## Article from TechCrunch about a decentralized internet.
"The future is a decentralized internet​."
- https://techcrunch.com/2017/01/08/the-future-is-a-decentralized-internet/
- https://twitter.com/ETCChina/status/810287857331879936

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. The previous show (1-03-17) featured special guest "ProphetDaniel" who is a constant contributor from the ETC development community. We had the pleasure of discussing ETC development and blockchain in general. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## ETC Monetary Policy

ETC Monetary Policy Proposal by @snaproll is now officially out as ECIP-1017

"This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/

Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/

For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelpethereum/

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33bK followers.
- Reddit /r/EthereumClassic - 2,978 subscribers.
- Slack - 1,676 users.
- Telegram - 783 users.
- WeChat - 472 users.
- Miners - 876.08 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 187.64 GH/s
- NanoPool 154.21 GH/s
- F2Pool 68.14 GH/s
- MiningPoolHub 37.42 GH/s
- Epool 31.02 GH/s

## Ethereum Classic Harmony Launch

| - | - |
|---|---|
Our friends from Ether.camp are proud to announce the release of Ethereum Harmony also available for ETC chain. Great job, cheers!| |
||Wine Art - Fabian Perez - Sante|

 Ethereum Harmony - Full info of a smart contract from ether.camp on YouTube .

## More information

 https://hack.ether.camp/sale

More information and registration as fan or a developer: https://hack.ether.camp

Slack: http://www.ether.camp/

https://twitter.com/campether

 #hackethercamp

## Links To Our Community

ETC Website

ETC Reddit

ETC Today

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Hi everyone, thank you for checking out this week's ETC newsletter! One of the biggest stories featured is about Grayscale Investments potentially launching an ETC Investment Trust. Another big event is the upcoming ETCathon, set to take place February 24th to the 26th in Shanghai. Also in the news recently, The whitehat withdrawal contract has been extended for 2 months. There is a lot of other great news as well, like the recent AMA on 8btc and plans to have Alan McSherry from IOHK's Grothendieck team on "Let's Talk ETC". Special thanks to Avtar, Splix, Snaproll and Roy Zou and all the other ETC community members for the setting up and participating in the AMA.

The other stories featured in this newsletter are listed below:*
- Ethereum Classic Harmony
- Two new articles from Dr. Seberino.
- Interesting thread on reddit about PoW/Pos and ETC/ETH.
- The value of the token model, by Fred Ehrsam
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

## "Grayscale to Launch Ethereum Classic Trust..."
Article from Kevin Helms of Bitcoin.com breaking down the launch of Grayscale Investments new product for Ethereum Classic set to possibly launch in the first quarter of this year.
- https://news.bitcoin.com/grayscale-to-launch-ethereum-classic-trust-modeled-bitcoin-investment-trust/

## ETCathon in Shanghai, February 24th to the 26th.
ETCathon will take place at the China Financial Information Center in Shanghai. Sponsors include the BTC China exchange, CHBTC exchange and Digital Currency Group.
- https://medium.com/@classicether/shanghai-etcathon-slated-for-february-24-26-7c82b96c4032#.d8ghgoelu

## Whitehat withdrawal contract has been extended.
"We want to give the community extra time to withdraw their share, so the funds will remain in the Withdraw Contract for an extra 2 months from today...."
- https://blog.bity.com/2017/01/30/the-whitehat-withdrawal-contract-has-been-extended-for-2-months/

## Monetary policy AMA on 8btc.
Special thanks to Avtar, Splix, Snaproll and Roy Zou and all the other ETC community members for the setting up and participating in the AMA.
- http://8btc.com/thread-45703-1-1.html

## Ethereum Classic Harmony

"Our friends from Ether.camp are proud to announce the release of Ethereum Harmony also available for ETC chain...."
- https://ethereumclassic.github.io/blog/2017-01-24-ethereum-classic-harmony/

## Two new articles from Dr. Seberino.

The first article is about a smart contract language called serpent and the second article is about ETC's sha3 implementation.
- https://steemit.com/etc/@cseberino/serpent-introduction-to-the-best-ethereum-classic-smart-contract-language
- https://steemit.com/etc/@cseberino/why-ethereum-classic-uses-an-incorrect-sha3-implementation

## Interesting thread on reddit about PoW/Pos and ETC/ETH.
Interesting post from Herman Schoenfeld with many great points, counterpoints, and rebuttals.
- https://www.reddit.com/r/EthereumClassic/comments/5qebcu/whyethereumclassicmaysurpassethereum/

## The value of the token model, by Fred Ehrsam.
"Since my prior post on app coins (I think the more appropriate term is now tokens or blockchain tokens) we’ve seen more and more projects use this model...."
- https://medium.com/@FEhrsam/value-of-the-token-model-6c65f09bcba8#.t0zt6yuju

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. The previous show (1-03-17) featured special guest "ProphetDaniel" who is a constant contributor from the ETC development community. We had the pleasure of discussing ETC development and blockchain in general. A link to the channel/show will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## ETC Monetary Policy

ETC Monetary Policy Proposal by @snaproll is now officially out as ECIP-1017

"This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/

Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/

For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelp_ethereum/

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33K followers.
- Reddit /r/EthereumClassic - 3,022 subscribers.
- Slack - 1,739 users.
- Telegram - 783 users.
- WeChat - 472 users.
- Miners - 1039.85 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 203.56 GH/s
- NanoPool 161.84 GH/s
- F2Pool 87.39 GH/s
- Epool 37.42 GH/s
- Coinotron 24.05 GH/s

"The phrase 'one-way hash function' might sound arcane and geeky, but hash functions are the workhorses of modern cryptography."

— Bruce Schneier

## Hash Functions

Hash functions are functions with outputs all the same size. These outputs are referred to as hashes. For example, all Secure Hash Algorithm 1 (SHA1) hashes have 20 bytes. Hash functions can efficiently confirm the integrity of files. For example, to confirm two terrabyte sized files are identical, it is easier to compare two hashes than all the bits!

## One Way Functions

Cryptography requires hash functions that are one way functions. One way functions are functions that are hard to invert. For example, computers can quickly find products of large primes, but, they cannot quickly factor the results.

## Collision Resistance

Cryptography also requires hash functions that are collision resistant. Collision resistance is a property of hash functions whereby it is difficult to find objects with the same hash. MD5 is a hash function discovered to have weak collision resistance. One could in principle maliciously modify information such that MD5 hashes would not detect the change. For a sobering example, consider Alice replacing this letter of recommendation, to the administrator of Gaul, with this alternate letter. The MD5 hash of both Postscript files is 0xa25f7f0b29ee0b3968c860738533a4b9!

Collision resistant hash functions make password based authentication systems more secure since only password hashes are stored. Authentication is performed by comparing hashes. Even if all password hashes are made public, it is still not possible to easily determine the passwords! (A attacker can eventually determine the passwords. Therefore, many systems require passwords to be changed every few months.)

## Blockchains

Blockchain systems continually use hashes to confirm the integrity of much information. Hashes also provide short unique identifiers for accounts, keys, transactions, blocks and state.

## Conclusion

Hashes are vital for the Internet, blockchains and beyond. They are truly the workhorses of cryptography.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Proposal

Here are some proposed Ethereum Classic (ETC) conventions to improve communication and avoid expensive mistakes:
- Refer to the currency as "ETC". Avoid the term "ether" whenever possible.
- Use the International System (SI) or metric prefixes to denote divisions of currency as in kETC, nETC and aETC. Avoid the terms "wei", "szabo" and "finney" whenever possible.
- Prefer the green clean minimalist logo on the ETC website over other choices.

## Motivation

The term "ether" is error prone for beginners as it can be confused with the Ethereum (ETH) currency. This can lead to expensive mistakes on cryptocurrency exchanges. Furthermore, the ETH currency terms "wei", "szabo" and "finney" are also confusing for beginners. The inventors of blockchain technology deserve to be honored. However, there are better ways to do that than to complicate currency transactions. Also, using the same consistent logo will improve marketing efforts. Finally, these conventions are another way to positively distinguish ETC from ETH and improve investor confidence.

## Implementation

The proposed conventions are based on the current standard currency code, "ETC", and the de facto standard logo on the ETC website. It is only necessary to continue using them and avoid other choices whenever possible. The SI or metric prefixes are already well known throughout the entire world and will be immediately recognized without any effort needed:

The choice that will likely get used the most, in addition to ETC, is aETC since many objects in software denote funds using this smallest possible division of currency.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

Serpent is a smart contract language based on Python. Python is arguably the best language for beginning programmers, and, the most productive language for serious developers. Serpent is currently being used for complex enterprise projects. It was originally developed for Ethereum. I will describe how to get started with it on the Ethereum Classic (ETC) system.

## Installing

An easy way to install Serpent, on most platforms, is with the Pip package management system. To install Serpent, first install Python 2 and Pip if necessary. Then, run the following command:

To test Serpent programs, it will be useful to install an additional package with the following command:

## Programming

To create smart contracts, simply create files containing Serpent functions. Note that some Python features are modified or missing in Serpent. For example, integers are 32 bytes, and, strings of 32 bytes or less are treated as integers. See Python and Serpent documentation for further details. Here are two examples of functions:

### Compiling

To compile Serpent functions in a file to ETC virtual machine code (bytecode), run the following command:

The output will be the hexadecimal representation of the corresponding machine code. Here is the output for a file containing getconfirmation and addthousand:

### Testing

To test functions with respect to a mock blockchain, the following Python script can be used:

Save this code in a file called serpenttest and make it executable. Here is a slightly edited actual session, on a Linux computer, with the file twofunctions.se containing the getconfirmation and addthousand functions:

The call data is an encoding of all the information needed to execute a smart contract method on the ETC blockchain. Notice the output of getconfirmation is the 32 byte hexadecimal representation of the string "It works!". Notice the output of addthousand is the 32 byte hexadecimal representation of 1234 since 0xea equals 234.

## Deploying

Deploying smart contracts requires a funded ETC account. There are many ways to obtain some ETC currency. For example, it can be purchased on the Poloniex exchange and transferred to any account. Deployment will also require access to an ETC node. To set up a node, I recommend the Parity implementation.

ETC Parity nodes communicate using JavaScript Object Notation (JSON). To be able to send all the requests to a properly secured ETC Parity node, start the node with the following command:

I will do deployment related tasks using the following Python script:

Save the code above in a file called nodecmd and make it executable. See the Parity JSON RPC documentation for more information.

### Smart Contract Account Management With Parity

To create a new account managed by a node, run the following command supplying the desired password. The account address will be returned:

To list accounts managed by a node, run the following command:

Run the following command to get the balance of any account. You must supply the hexadecimal representation of an account address:

### Smart Contract Deployment With Parity

Run the following command to deploy a smart contract. You must supply the hexadecimal representation of the funding account address, the machine code, and, the funding account password. The corresponding transaction hash will be returned:

For the above command, there will be a sensible gas limit imposed as well as a gas price based on recent transactions.

### Smart Contract Execution With Parity

Run the following command to execute a smart contract on the ETC blockchain. You must supply the smart contract address and call data:

The call data can be obtained from the aforementioned serpenttest script.

### Smart Contract Example With Parity

Here is a slightly edited actual session on a Linux computer running an ETC Parity node:

## Conclusion

Serpent is an excellent way to get started developing ETC smart contracts. Now go make a dent in the universe) with it!

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank Tomasz Drwięga for his help. I would also like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## The Problem

Millions of people search the Internet, government databases, private databases and blockchains everyday for medical advice, financial updates, weather reports, maps and more. Likewise, millions of people want or need fast searches.

## A Solution

An effective method to speed up many searches is the use of indexes. Indexes, like those at back of textbooks, provide the locations of all search terms. A possible drawback is that they require large amounts of storage.

## Another Solution

An effective method to speed up many searches, with less storage requirements, is the use of Bloom filters. These are important in many areas such as mobile and embedded devices.

## Bloom Filters

Bloom filters are binary strings used to quickly determine set membership with nominal storage requirements. Browsers use them to detect malicious websites. Databases use them to avoid searching for nonexistent data.

Bloom filters require less memory than indexes, but, they sometimes give false positives. In other words, they might claim an object is a member of a set when it is not. It is noteworthy that Bloom filters never give false negatives. They never claim an object is not in a set when it actually is. Browser Bloom filters might incorrectly claim safe websites are malicious, but, they will never claim malicious websites are safe. Fortunately, extra checks can always be performed to eliminate any false positives.

## Construction

To build a Bloom filter for the set {X₁, X₂, X₃, ..., Xₙ}, with hash function H, calculate H(X₁) | H(X₂) | H(X₃) | ... | H(Xₙ). | is the bitwise OR operator. H is only valid if the number of set bits (ones) in all hashes is always less than or equal to some selected maximum.

Larger Bloom filters have less false positives. Bloom filters of several megabytes are not uncommon. As hash functions typically do not have large enough hashes, not to mention hashes with required number of set bits, adequate hashes are often constructed from multiple hash functions. A common recipe is to have a group of hash functions each set a single bit in the construction of a valid hash. For example, to set a bit in a hash with 2²³ bits, the first 23 bits of the Secure Hash Algorithm 1 (SHA1) hash can be used to select the position of a bit to set.

## Operation

To determine if an object X might be in a set with Bloom filter B, built with hash function H, determine if H(X) & B = H(X). & is the bitwise AND operator. Notice that the test only returns true if all the set bits in H(X) are also set in B. Basically, groups of set bits in B correspond to elements. X might be a member of the set if and only if its group of set bits corresponds to a group in B. The reason B can only determine if X might be in the set is because B contains the bits of several elements.

## Blockchains

Bloom filters allow lightweight (small memory requirements) Bitcoin wallets to quickly and privately obtain account information without downloading the entire blockchain. Bloom filters also allow lightweight Ethereum Classic clients to quickly and privately obtain account information without downloading the entire blockchain.

## Conclusion

Bloom filters are a powerful tool that allows additional innovation in blockchain applications and many other areas in the twenty first century.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## SHA3 Description

The Secure Hash Algorithm 3 (SHA3) functions are referred to as SHA3-224, SHA3-256 and SHA3-512. The hash sizes are the same as SHA2. Therefore, SHA3 can easily replace SHA2 should that become necessary. The SHA3 algorithms however are substantially different. These differences will hopefully make any weaknesses ever found in SHA2 not also apply to SHA3. There are no known vulnerabilities in either SHA2 or SHA3.

## SHA3 History

Several years ago improved attacks and increased computing power made MD5 and SHA1 insecure for some applications. People became concerned that improved attacks might also make SHA2 insecure for some applications. Therefore, the National Institute of Standards and Technology (NIST) began the process of finding an alternative in 2006. Keccak became the official SHA3 standard in 2015. Keccak functions have multiple adjustable parameters. Different choices imply different levels of security and performance.

## SHA3 Controversy

NIST attempted to make changes to the selected Keccak functions after the peer review process to increase performance. The new candidates were all legitimate Keccak functions and not necessarily a bad idea. Unfortunately for NIST, these changes were proposed shortly after the Edward Snowden revelations. Snowden was a National Security Agency (NSA) contractor who exposed top secret information about several questionable programs starting in 2013. Documents suggest the NSA may have colluded with NIST to intentionally weaken the DualECDRBG standard. Therefore, the reaction to the proposed SHA3 changes was ferocious. NIST eventually backpedaled and reverted to more secure albeit slower Keccak function choices.

## SHA3 & ETC

The Ethereum (ETH) system was developed in the midst of this drama. The Ethereum Foundation decided not to follow every twist and turn that occurred after the SHA3 peer review process. Therefore, ETH uses a hash function that today is referred to as Keccak-256 instead of SHA3-256. Because Ethereum Classic (ETC) inherited this design decision, it also uses Keccak-256. There is nothing wrong with that except that Keccak-256 is referred to in many places as SHA3. This has led to lots of confusion. There are multiple Ethereum Improvement Proposals (EIPs) to fix this. Solidity has already implemented some corrections. If you understand now, please support my Ethereum Classic Improvement Proposal (ECIP) to address this.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Question

Should we make ⟠ the Ethereum Classic currency symbol? That is Unicode code
(U+27E0). See here: http://graphemica.com/%E2%9F%A0 . It looks just like the
awesome green Ethereum Classic logo! What do you think?

## ECIP

See the Ethereum Classic Improvement Proposal (ECIP) #20 for this proposal
here.

## Links To Our Community

ETC Website

ETC Reddit

ETC Today

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

The biggest story from the past week is the treasury proposal released by IOHK. Also, I wanted to let everyone know that the ETCathon, set to take place February 24th, 25th and 26th in Shanghai, has been delayed to a later date (TBA). Another reminder to everyone in the community about the whitehat withdrawal contract being extended. Also in the news recently, full footage released from the London monetary policy discussion and an inside look at IOHK's Grothendieck Team meeting.

The other stories featured in this newsletter are listed below:*
- A little support/shoutout from John McAfee.
- Brief update from Charles Hoskinson.
- New youtube vid from BitcoinMeister.
- Interesting thread about advantages/disadvantages of PoS.
- New unicode proposal.
- Interesting article from Nick Szabo.
- Various blockchain articles from coinidol.com.
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newslette

## Treasury proposal released by IOHK.
Treasury proposal has just been released by IOHK. Please voice your thoughts, opinions, and commentary.
- https://twitter.com/CollinCrypto/status/832493711384788992

## ETCathon has been delayed.

The ETCathon set to take place later this week has been delayed to a later date (TBA).

## Whitehat withdrawal contract has been extended.
"We want to give the community extra time to withdraw their share, so the funds will remain in the Withdraw Contract for an extra 2 months from today...."
- https://blog.bity.com/2017/01/30/the-whitehat-withdrawal-contract-has-been-extended-for-2-months/

## London monetary policy discussion footage.
All of the footage from the London monetary policy discussion, which took place in December, has been completed and released for everyone to view.
- https://www.youtube.com/watch?v=5CojLHSobQ

## Update from Charles Hoskinson.
Brief update from Charles Hoskinson discussing future plans and thoughts about the ETC platform.
- https://www.youtube.com/watch?v=-IBwDvxMnBc&feature=youtu.be

## New youtube vid from BitcoinMeister.
BitcoinMeister has been releasing a lot of great content every day, take a minute to check out his channel. In the video below he talks ETC and blockchain in general.
- https://www.youtube.com/watch?v=S2cXYFoPCxg

## Interesting thread about advantages/disadvantages of PoS.

Check out the reddit thread below for some interesting commentary about PoS from various users in the blockchain community.
- https://www.reddit.com/r/ethereum/comments/5seih3/vitalikondecentralization/ddekkkx/

## New unicode proposal.
Dr. Seberino found some gold when he was digging around looking at some of the unicode symbols, let us know what you guys think.
- https://www.reddit.com/r/EthereumClassic/comments/5t3n1u/letsmakethenewetccurrencylogoitlooksjust/

## Interesting article from Nick Szabo.
Check out the article below for some interesting thoughts by Nick Szabo.
- http://unenumerated.blogspot.jp/2017/02/money-blockchains-and-social-scalability.html

## Various blockchain articles from coinidol.com.
Various blockchain articles from coinidol.com including an article about ETC.
- https://coinidol.com/koles-coin-news-digest-feb-2/

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. The previous show (2-08-17), featured special guest Alan McSherry, who is the project lead of IOHK's Grothendieck Team. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## ETC Monetary Policy

ETC Monetary Policy Proposal by @snaproll is now officially out as ECIP-1017

"This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. In addition, this ECIP describes the requirements associated with maintaining this emission schedule through a potential change of the network’s consensus algorithm, from its current Ethash based Proof of Work to a possible POS or POW/POS hybrid model." Please see the full post from github and reddit at the links below.
- https://github.com/ethereumproject/ECIPs/pull/20/files
- https://www.reddit.com/r/EthereumClassic/comments/5cm582/monetarypolicyupdate/

Monetary policy discussions are still in progress on many platforms. However, most of the conversation seems to be taking place on the #monetarypolicy channel on slack.
Please join us on Slack using the following link.
- https://ethereumclassic.herokuapp.com/

For more information on community participation please see this call to action post for guidance.
- https://www.reddit.com/r/EthereumClassic/comments/4u4o61/callforactionwhatcanidotohelpethereum/

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33K followers.
- Reddit /r/EthereumClassic - 3,037 subscribers.
- Slack - 1,794 users.
- Telegram - 817 users.
- WeChat - 480 users.
- Miners - 915.73 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 278.89 GH/s
- NanoPool 139.25 GH/s
- NanoPool 128.35 GH/s
- F2Pool 84.17 GH/s
- Coinotron 30.56 GH/s

I recently interviewed the person who started Ethereum Classic (ETC). His motives are admirable. His reason for wishing to remain anonymous is a reminder of why blockchain technologies are important. Here is a slightly edited version of the interview:

### How do you want people to refer to you?

I use [the] personal pseudonym "Arvicco". BitNovosti is... the name of my business: a leading crypto media group in Russia that includes websites, video production, publishing[,] etc.

### Please tell a little about yourself.

I’m from Russia and my professional background is in IT and online media. As I have seen [the] Internet develop from very early stages (Mosaic, anyone?) into the unstoppable force it is today, I’ve always been interested in [the] transformative potential of digital technologies as it relates to society and [the] economy. Exploring virtual economies and virtual currencies, I stumbled upon Bitcoin in 2011. As with many other people in [the] crypto-space, my life has never been the same from that moment on. I have been mining, trading, evangelizing and building projects in [the] crypto space ever since. It is my life goal to make sure that Blockchain technologies fully realize their transformative potential, changing our societies and [the] human condition for the better.

### Why do you want to remain anonymous?

There is very significant legal uncertainty surrounding cryptocurrencies in Russia. Crypto information resources are regularly outlawed and blocked by Russian courts. Businesses accepting BTC are subject to legal and extra-legal pressure. Only late last year, [the] Russian government put on hold a legislative initiative introducing [a] criminal penalty and jail terms for people dealing with cryptocurrencies. But, knowing how things move in Russia, such legislation could be re-introduced and enacted [with] very short notice. Due to such risks, many Russian citizens active in [the] crypto space prefer to maintain pseudonymity.

### You do realize that being anonymous reminds people of Satoshi Nakamoto?

Such comparison[s] may be flattering but [they are] not very meaningful. Satoshi single-handedly created [Bitcoin] blockchain technology, coded a working version of Bitcoin software and maintained [the] Bitcoin network until others took notice and got involved. My role was much more limited.. from the very beginning it was a team effort - I was more visible simply due to the fact that I had media skills and was responsible for communications.

### Please describe the very beginning of ETC.

It all started with me publishing A Crypto-Decentralist Manifesto that articulated [the] blockchain principles [that are the] sine qua non[s. That was followed] by a call to action to keep the original Ethereum chain[.] After that, a small group of (mostly Russian-speaking) enthusiasts started working on setting up all the necessary infrastructure: Github orgs, Reddit, Slack, mining pool, block explorer, ETC website and so on. In no time, volunteers from all around the world started showing up around [the] ETC subreddit and Slack offering their help and taking [the] initiative to complete necessary tasks. Once the DAO bailout fork was behind us[,] and it became clear Ethereum Classic [would survive], then external support started pouring in: exchanges, mining pools, high-profile endorsers like Barry Silbert and Charles Hoskinson, and so on.

### Why did you do it?

A bit of background first, I’m one of [the] early supporters of Ethereum. Probably, one of the earliest in Russia. [I financed] Ethereum development via [the] pre-sale, mined ethers early on, [and,] published multiple Ethereum articles in Russian language media. My expectation was that whatever happens Ethereum [would] stick to the principles of Blockchain[s:] neutrality, openness and immutability. So[,] it came as a shock to me when I realized that as a result of [the] DAO debacle [the] Ethereum Foundation [was] going to move Ethereum in [a] completely opposite direction. As [did] many other opponents of [the] DAO bailout fork[,] I felt that by doing so EF not only broke the initial Ethereum’s vision and social contract, but also betrayed foundational Blockchain principles. [The] Ethereum Classic project was born as a way keep the original Ethereum’s vision and social contract alive, even if EF abandoned it. A small group that started ETC felt it [was] important to offer a decentralized alternative, and it turned out that many people agreed – so, [the] ETC community as we know it today started to coalesce around the project.

### Why is ETC important?

[A decentralized] platform for “applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference” is one of key technology components that will allow [the] Blockchain revolution to fully realize its potential, change economic and social structures, [and,] radically [transform] human society into a more equitable [and] decentralized configuration. It’s hard to see what is more important than that.

### What are your feelings about Vitalik and the rest of the Ethereum (ETH) community?

Each person is free to determine what is most important for him/her and [to] choose their path accordingly. It goes for communities as well as for individuals. Personally, I think that by endorsing [the] DAO bailout [the] ETH community broke the very value proposition its success depended on. Frankly, it’s sad so many people in that community either don’t understand the foundational principles of [blockchains], don't agree with them[, or,] just don’t care.

### What do you hope to see in the next 5, 10 or 20 years for ETC?

ETC needs to become a reliable, trustless [and] public infrastructure for unstoppable consensus-dependent applications [-- the] infrastructure that underlies the economic and social structures of tomorrow. We are still at the very beginning of this path – will it take 5, 10 or 20 years? Who knows. But what I have no doubt about – in order to arrive there, we need to build this infrastructure on a firm foundation of principles.

### What do you think are the biggest problems that ETC must overcome?

Monetary policy and decentralized governance are the most pressing issues [the] ETC community [is] facing today. It is very important to find the right models that ensure long-term [success]. There is a lot of productive discussion around both topics in the community right now and I’m confident we’ll be able to arrive [at] positive conclusions.

### Is there anything that worries you regarding ETC?

It worries me a bit that some people in the community complain about slow progress, problems or issues without really trying to contribute to solutions. In Ethereum Classic, everything is a community effort. If everyone is simply contributing to the issue s/he is most passionate about[,] and feels most qualified to achieve progress, we can make many wonderful things happen. It’s just as simple as doing your best and listening to community feedback.

### Is there a reason you and Vitalik are from Russia? Is there something about that part of the world that makes for great blockchain technologists?

Russians are sometimes stereotyped as stubborn people often doing something unconventional, something others consider impossible [-- like] putting the first man into space, you know. Blockchain is currently this Frontier opening the ways to change everything, do impossible things. So, there must be something there resonating with Russian mentality, I guess.

### Anything else you want to add?

[The blockchain] revolution won't be centralized. We can make it happen, and we don't really need "supreme leaders" for this.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Introduction

The Domain Name System (DNS) maps domains to Internet Protocol (IP) addresses. Governments, corporations and other entities have attempted to censor this system for various reasons. Therefore, it is desirable to create a censorship resistant alternative. Furthermore, DNS like systems are useful for other purposes such as cryptocurrencies, inventory tracking and voting.

The Ethereum Classic (ETC) system automatically provides censorship resistance! It is only necessary to write a smart contract to store and retrieve information on the blockchain.

## Code

Here is Serpent code that implements a DNS type system on the ETC platform:

This smart contract has methods to create, modify and retrieve domain records. All methods supply status messages. Notice it is necessary to send a small payment to set up new domain records. This discourages cybersquatting and other attacks.

## Testing & Deployment

### Testing Script

For testing I will use the following serpenttest script:

### Deployment Script

For deployment, I will use the following nodecmd script with an ETC Parity node:

### Pretty Printing Script

For pretty printing lists, from hexadecimal encodings, I will use the following serpent_list script:

### Example

Here is a slightly edited actual session on a Linux computer running an ETC Parity node. The domain name system code is in a file called dns.se:

## Conclusion

A censorship resistant DNS replacement is just one of many potentially useful ETC applications. Hopefully this example will encourage you to come up with your own ideas.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Reddit

ETC Today

ETC Twitter

ETC Facebook

ETC Slack

## ETC Development Report

Biggest story from the past week is a statement released in reference to ETC monetary policy. Additionally, since the community united and moved forward, Grayscale has announced that the ETC Trust is a go. March is shaping up to be an insanely great month for ETC and blockchain in general. Also in the news is a new ETCdev Team website that is up and running as well as another weekly meeting from IOHK's Grothendieck team.

The other stories featured in this newsletter are listed below:*
- First draft of Treasury Proposal released by IOHK.
- Chinese exchange http://szzc.com lists ETC.
- How I learned to stop worrying and love ETC.
- How I learned to stop worrying and love ETC.
- Interview done by Dr. Seberino.
- Charles Hoskinson: Some Thoughts on ETC.
- Request for comment: ECIP 1019 & 1020 .
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newslette

## Treasury proposal released by IOHK.
Treasury proposal has just been released by IOHK. Please voice your thoughts, opinions, and commentary.
- https://twitter.com/CollinCrypto/status/832493711384788992

## ETC on new exchange.
Chinese exchange http://szzc.com lists ETC.
- https://twitter.com/ETCChina/status/833960086414323712

## Article from Philip Daian
How I learned to stop worrying and love ETC.
- https://pdaian.com/blog/stop-worrying-love-etc/

## Article about IOHK's Grothendieck team.

IOHK's project lead on hitting the ground running with the Grothendieck team.
- https://iohk.io/blog/mission-one%E2%80%93destination-st-petersburg-and-warsaw/

## Article from Dr. Seberino.
An Interview With The Anonymous Individual That Started Ethereum Classic
- https://steemit.com/etc/@cseberino/an-interview-with-the-anonymous-individual-that-started-ethereum-classic

## Charles Hoskinson: Some Thoughts on ETC
Blog post by Charles Hoskinson discussing ETC monetary policy, the treasury proposal and other topics.
- https://hoskinsoncharles.blogspot.com/2017/02/some-thoughts-on-etc.html

## New unicode proposal.
Dr. Seberino found some gold when he was digging around looking at some of the unicode symbols, let us know what you guys think.
- https://www.reddit.com/r/EthereumClassic/comments/5t3n1u/letsmakethenewetccurrencylogoitlooks_just/

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST we will be discussing what's going on in the ETC community and beyond. The previous show (2-08-17), featured special guest Alan McSherry, who is the project lead of IOHK's Grothendieck Team. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33K followers.
- Reddit /r/EthereumClassic - 3,070 subscribers.
- Slack - 1,864 users.
- Telegram - 824 users.
- WeChat - 480 users.
- Miners - 936.93 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 225.70 GH/s
- NanoPool 118.07 GH/s
- NinjaPool.jp 21.63 GH/s
- F2Pool 84.17 GH/s
- Coinotron 14.13 GH/s

## Links To Our Community

ETC Website

ETC Dev Team

ETC Grothendieck Team

ETC Today

ETC Slack

ETC Reddit

ETC Twitter

ETC Facebook

## ETC Development Report

ETCDev Team: Weekly Report
- (Geth) migrate from private Teamcity CI to public builds
- Windows builds and tests with Appveyor (turns out there’re some issues with windows)
- automatic uploads to Bintray
- (Geth) Migrate chain config
- (Geth) logging normalization
- (Geth) JIT VM dropped (we’re working on replacement VM)
- (Geth) improved metrics stat
- (Emerald Wallet) Initial code for backend, rust based

IOHK’s Grothendieck Team Report
- Recording of the Grothendieck Team meeting from March 7th, 2017.
- https://www.youtube.com/watch?v=JB_j1pVonvo

The other stories featured in this newsletter are listed below:
- Grayscale confirms future launch of ETC trust.
- Article from Coindesk.
- Article from BTCmanager.com
- Sprites: Payment Channels that Go Faster than Lightning?
- Article from Cryptom
- Our New Linear Time PVSS Scheme
- Some Thoughts Towards an Ontology for Smart Contracts
- Provably secure hybrid PoW/PoS Algo
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

Also, now that monetary policy discussion has come to a close I would like to announce some ideas for more organized discussion on the following topics
- Marketing Mondays: Marketing centric discussion and ideas.
- Funding talk Tuesdays: Funding centric debate and discussion.
- Dapper devs Wednesdays: Dapp and development centric discussion.
- Think about it Thursdays: How can we accomplish what was discussed during the week.
- Free for all Fridays: Brainstorm/community questions/discussion open to anything.

## Grayscale ETC Trust

Grayscale confirms the future launch of an ETC trust.
- https://twitter.com/GrayscaleInvest/status/837649119992766465

## Article from Coindesk
“Beyond immutability: Ethereum Classic…”
- (http://www.coindesk.com/beyond-immutability-ethereum-classic-maps-way-forward/)

## Article from BTCmanager.com
“Ethereum Classic integrates deflationary monetary policy.”
- https://btcmanager.com/ethereum-classic-integrates-deflationary-monetary-policy/

## Paper from cornell on Sprites
“Sprites: Payment Channels that Go Faster than Lightning.”
- https://arxiv.org/abs/1702.05812

## Article from Cryptom.

“A new era of blockchain immutability towards a new understanding.”
- http://cryptom.site/2017/03/06/a-new-era-of-blockchain-immutability-towards-a-new-understanding/

## Paper on PVSS schemes.
“Our New Linear Time PVSS Scheme.”
- https://eprint.iacr.org/2017/216.pdf

## Blog post from Charles Hoskinson on smart contracts.
“Some Thoughts Towards an Ontology for Smart Contracts.”
- https://hoskinsoncharles.blogspot.com/2017/03/some-thoughts-towards-ontology-for.html

## Paper released detailing a hybrid PoW/PoS algorithm.

TwinCoins: A Provably secure hybrid PoW/PoS Algo.
- https://iohk.io/research/papers/twinscoin-a-cryptocurrency-via-proof-of-work-and-proof-of-stake/

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST, we will be discussing what's going on in the ETC community and beyond. The next show will feature a researcher from the treasury proposal first draft that was released by IOHK recently. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 32.7K followers.
- Reddit /r/EthereumClassic - 3,101 subscribers.
- Slack - 1,893 users.
- WeChat - 490 users.
- Miners - 1054.26 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 270.83 GH/s
- NanoPool 137.48 GH/s
- F2Pool 98.68 GH/s
- NinjaPool.jp 23.79 GH/s
- MiningPoolHub 15.00 GH/s

I recently discussed the new Viper smart contract programming language with Ethereum's Vitalik Buterin. Viper is similar to Python and provides more features and protections than Serpent. One of many noteworthy examples is support for Decimal like objects which are helpful for financial applications. Furthermore, the Viper compiler is implemented in Python 3. The same people that will want to use Viper can more easily help develop and maintain it. Here is a slightly edited version of the interview:

## Why Viper rather than just improving Serpent?

Serpent is written in C++ and the codebase is hard to work on. Once we start talking about doing major rewrites of Serpent, then we might as well add a bunch of other features to make the language much safer, like bounds checking, strong typing, etc. Hence, the totally-backwards-incompatible "[S]erpent 2.0" upgrade named Viper.

## Should people start using Viper now instead of Serpent?

I definitely recommend starting to look at Viper over Serpent. It's not 100% feature-complete yet but I hope it will be in a few months.

## Any chance of automated porting of Serpent code like with the 2to3 script for Python 3 ports?

Automated porting will be hard; also, note that not all Serpent code should be ported to Viper, as some Serpent code is for low-level highly optimized code, and that is best done in Serpent.

## What are the major deficiencies of Serpent that Viper addresses?
- Lack of a strong type system
- General ease of writing unsafe and misleading code
- Lack of easy accessibility + extensibility of the compiler code

## When will it be ready for enterprise use?

Hopefully in a few months.

## When did this project start and how do like it so far?

Started working on it in Nov. So far I like it :) I am currently using it for writing Casper contracts.

## What is left to do?
- Add support for calling external contracts
- A stronger type system that can statically check variable bounds, increasing both efficiency and safety
- More tests; always want more tests (ideally with a checker verifying 100% code coverage)

## How can people contribute?

Submit pull requests to http://github.com/ethereum/viper :)

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Dev Team

ETC Grothendieck Team

ETC Today

ETC Slack

ETC Reddit

ETC Twitter

ETC Facebook

## ETC Development Report

ETCDev Team: Weekly Report
- (Geth) improve automatic builds process, everything is deployed to bintray now.
- (Geth) new versioning process, based on git describe --tags
- geth-classic-linux-v3.3.0-1-gdd95f05.zip
- v.3.3.0 - Geth version
- 1 - commits count after tag creation
- gdd95f05 - commit id dd95f05
- (Geth) improved debugging service
- (Geth) NEW RELEASE
- version 3.3.0 https://github.com/ethereumproject/go-ethereum/releases/tag/v3.3.0
- cleanup & refactoring version
- please download and test it, many things were changed since 3.2.x
- (Emerald Wallet) working implementation of RPC Connector

IOHK’s Grothendieck Team Report
- Recording of the Grothendieck Team meeting from March 14th, 2017.
- https://www.youtube.com/watch?v=6AA-OwsRUlw

The other stories featured in this newsletter are listed below:
- ETC Trust investment thesis released.
- Geth Classic - 3.3.0 released.
- New video from BitcoinMeister
- Are crypto ‘tokens’ securities?
- Proof refinement basics from IOHK research.
- Article from Dr. Seberino
- Let’s Talk ETC - Episode 10
- Two theories of bitcoin immutability.
- Bidirectional proof refinement.
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC Monetary Policy
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

Also, now that monetary policy discussion has come to a close I would like to announce some ideas for more organized discussion on the following topics
- Marketing Mondays: Marketing centric discussion and ideas.
- Treasury Tuesdays: Treasury centric debate and discussion.
- Dapper Devs Wednesdays: Dapp and development centric discussion.
- Think about it Thursdays: How can we accomplish what was discussed during the week.
- Free for all Fridays: Brainstorm/community questions/discussion open to anything.

## ETC Trust investment thesis.

The ETC investment trust from Grayscale released their thesis.
- https://grayscale.co/ethereum-classic-investment-thesis-march-2017/

## Geth Classic - 3.3.0 released.

A new version of Geth Classic, 3.3.0, has just been released.
- (https://twitter.com/splix/status/839927062882193408)

## BitcoinMeister video.

New video from BitcoinMeister featuring discussion about ETC and other blockchain topics.
- https://www.youtube.com/watch?v=j0qFVq16fYE

## Article from americanbanker.com.

“Are crypto ‘tokens’ securities?”
- (https://www.americanbanker.com/news/are-crypto-tokens-securities-by-another-name)

## Article from IOHK research.

“Proof refinement basics…..”
- https://iohk.io/blog/proof-refinement-basics/

## Article from Dr. Seberino.

“Vitalik Buterin discusses the new viper smart contract programming language.”
- https://steemit.com/etc/@cseberino/ethereum-s-vitalik-buterin-discusses-the-new-viper-smart-contract-programming-language

## Let’s Talk ETC - Episode 10.

Let's Talk ETC! (Ethereum Classic) #10 featuring Charles Hoskinson & Roman Oliynykov discussing the recently released draft of the treasury proposal.
- https://www.youtube.com/watch?v=zxZoSjnHN84

## Article discussing immutability.

“Two theories of bitcoin immutability.”
- (https://medium.com/@Mengerian/two-theories-of-bitcoin-f4da84468a7a#.wc3ssrxub)

## Article from IOHK research.

“Bidirectional proof refinement.”
- (https://iohk.io/blog/bidirectional-proof-refinement/)

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Tuesday at 7:30pm EST, we will be discussing what's going on in the ETC community and beyond. Last weeks show featured a researcher from the treasury proposal first draft that was released by IOHK recently. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 32.8K followers.
- Reddit /r/EthereumClassic - 3,132 subscribers.
- Slack - 1,958 users.
- WeChat - 495 users.
- Miners - 681.05 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 186.69 GH/s
- F2Pool 89.39 GH/s
- NanoPool 74.89 GH/s
- MiningPoolHub 19.00 GH/s
- NinjaPool.jp 18.48 GH/s

Eyan Ron in A New Era of Blockchain Immutability - Towards a New Understanding brilliantly describes two types of blockchain system immutability: historical and procedural. I will show how these distinctions can improve Ethereum Classic (ETC) immutability discussions.

## Historical Immutability

historical immutability : property of blockchain systems such that the content and positions of all blocks, older than some minimum age, do not change

Historical immutability is not the same as blockchain immutability. An immutable blockchain would not allow new blocks! Historical immutability only applies to sufficiently aged blocks (or equivalently, blocks of sufficient depth in the blockchain). It permits new blocks and avoids confusion regarding the latest blocks. Furthermore, historical immutability does not allow new blocks to be added anywhere except after the latest blocks.

## Procedural Immutability

procedural immutability : property of blockchain systems such that the protocol to determine valid blocks does not change

Blockchain systems define block validation protocols. These might specify mining rewards and valid proof of work information. Procedural immutability typically is not desirable! It would prohibit bug fixes and new features! Although blockchain systems typically cannot guarantee procedural immutability, they should specify the only situations in which it may be violated.

## ETC Immutability

It is now possible to more precisely define ETC immutability:

ETC guarantees historical immutability, and, to only violate procedural immutability in order to improve the system.

## Managing Improvements

Unfortunately, this does not eliminate all ambiguity. There might still be confusion and disagreements regarding what constitutes improvements! Is the Ethereum DAO attack hard fork an "improvement" because it potentially increased the available investment capital? Clearly all blockchain systems, including ETC, must develop protocols to evaluate proposed improvements and avoid future problems.

## Historical Discussions

Below are some noteworthy historical ETC immutability related snippets and possible responses:

### Gavin Wood - 2016-10-27 - I would suggest that EIP-150 was compliant from a "don't mess with the chain" immutability point of view.

Possible Response: EIP-50 did not violate historical immutability since it only altered gas prices. It was a violation of procedural immutability that improved the system.

### Nick Johnson - 2016-10-27 - "Immutability" is overused and under-specified. Strictly speaking, it should mean only that the blockchain - the set of past transactions - is not modified, which no Ethereum fork has ever done.

Possible Response: The DAO attack hard fork did not technically violate historical immutability. However, it was a violation of procedural immutability that many would argue did not improve the system.

### Vitalik Buterin - 2016-11-15 - ETC is mutable too; they mutated their transaction execution rules to fix the recent DoS issues,

Possible Response: Removing the denial of service vulerabilities violated procedural immutability. However, this improved the system and did not violate historical immutability.

### Emin Gün Sirer - 2017-01-14 - Feel free to edit your coin any way you like. But be advised that the word immutable doesn't apply.

Possible Response: Procedural immutability does not apply but historical immutability does.

## Conclusion

Eyan Ron has helped clarify the definition of ETC immutability. This is useful to improve discussions. Further work is required to specify a protocol to manage proposed ETC improvements.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Dev Team

ETC Grothendieck Team

ETC Today

ETC Slack

ETC Reddit

ETC Twitter

ETC Facebook

## ETC Development Report

ETCDev Team: Weekly Report
- (Geth) Improved blockchain downloader and peer discovery
- (Geth) Initial refactor to externalize Chain configuration
- (Emerald) New account generator
- (SputnikVM) EVM Test suite
- (Emerald) Support for Tokens
- (Emerald) Automatic builds, with strict rules to code quality
- (SputnikVM) Implementation for basic Operations

IOHK’s Grothendieck Team Report
- Recording of the Grothendieck Team meeting from March 21st, 2017.
- https://www.youtube.com/watch?v=CKzo4OgtpSc

ECIP Updates

Let us know your thoughts!
- A smart contract based system for ECIP management by C. Burns
- An Ethereum Classic naming service by Dexaran.
- Atomic transactions proposal by Splix.

The other stories featured in this newsletter are listed below:
- Bitkio is researching IoT solution using ETC.
- Poll from 8btc has ETC as #2
- DigixDAO ETC withdraw proposal
- Let’s Talk ETC #12, Proof of Proof
- Interesting twitter thread on ETC vs ETH
- Raiden network IoT demo.
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

Also, now that monetary policy discussion has come to a close I would like to announce some ideas for more organized discussion on the following topics
- Marketing Mondays: Marketing centric discussion and ideas.
- Funding Talk Tuesdays: Funding centric debate and discussion.
- Dapper Devs Wednesdays: Dapp and development centric discussion.
- Think About It Thursdays: How can we accomplish what was discussed during the week.
- Free For All Fridays: Brainstorm/community questions/discussion open to anything.

## ETC IoT Research

Bitkio is researching IoT solution using ETC.
- https://twitter.com/roylzou/status/844419945299619841

## Geth Classic - 3.3.0 released.

A new version of Geth Classic, 3.3.0, has just been released.
- (https://twitter.com/splix/status/839927062882193408)

## BitcoinMeister video.

New video from BitcoinMeister featuring discussion about ETC and other blockchain topics.
- https://www.youtube.com/watch?v=j0qFVq16fYE

## Article from americanbanker.com.

“Are crypto ‘tokens’ securities?”
- (https://www.americanbanker.com/news/are-crypto-tokens-securities-by-another-name)

## Article from IOHK research.

“Proof refinement basics…..”
- https://iohk.io/blog/proof-refinement-basics/

## Let’s Talk ETC - Episode 10.

Let's Talk ETC! (Ethereum Classic) #10 featuring Charles Hoskinson & Roman Oliynykov discussing the recently released draft of the treasury proposal.
- https://www.youtube.com/watch?v=zxZoSjnHN84

## ETC #2 in recent poll.

Poll from 8btc, a popular Chinese cryptocurrency website, has ETC as #2.
- (https://twitter.com/roylzou/status/844411672617979913)

## Let’s Talk ETC #12

Dr. Seberino discusses ‘Proof of Proof’ with Justin Fisher and Max Sanchez of the
Veriblock team.
- https://www.youtube.com/watch?v=cZLrmHJ1DqQ

## Interesting twitter thread on ETC vs ETH.

Follow the link and let us know what your thoughts are.
- https://twitter.com/eth_classic/status/845627514915573760

## Raiden network IoT demo.

Demo from the creators of the ‘Raiden Network’ showing a glimpse into the potential future of IoT solutions.
- https://www.youtube.com/watch?v=t6-rf68taTs

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Tuesdays at 7:30pm EST.
Every Friday at 2:00pm EST, we will be discussing what's going on in the ETC community and beyond. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33K followers.
- Reddit /r/EthereumClassic - 3,203 subscribers.
- Slack - 2,173 users.
- WeChat - 493 users.
- Miners - 690.5 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 222.48 GH/s
- NanoPool 93.87 GH/s
- F2Pool 71.99 GH/s
- NinjaPool.jp 20.81 GH/s
- coinotron 15.61 GH/s

The Ethereum Classic (ETC) blockchain makes possible an unstoppable, reliable, auditable, trustless and secure world computer. To understand this system, it is important to understand accounts and states.

## Accounts

An account is a data structure containing an address, balance, program, memory and a nonce. They are used by entities external to the ETC system to interact with it. These external entities may be humans, but, they can also be Internet devices. Accounts are also used to specify smart contracts. It simplifies the design of ETC to use accounts for both of these purposes.

### Addresses

Accounts have unique 20 byte identifiers referred to as addresses. External entities generate new account addresses from public encryption keys. Smart contracts generate new account addresses by other means since smart contract accounts do not have public encryption keys.

### Balances

Accounts can have funds. Account funds are specified by balances. Balances are typically denoted in units of aETC (10 -18 ETC) or weis.

### Programs

Smart contract accounts have world computer programs. These are also referred to as smart contract code. This element is unused by external entity accounts. Partially for security reasons, smart contract programs in accounts cannot be modified. All other account elements however can be modified.

### Memories

Smart contract accounts have memories. These are also referred to as storage. All smart contract memory values, and their identifiers, are 32 bytes.

### Nonces

Accounts have counters referred to as nonces. Partially to protect against replay attacks, external account nonces increment every time they add a new transaction to the blockchain. Partially to provide variability when calculating new addresses, smart contract account nonces increment every time they add a new smart contract to the blockchain.

## States

A complete description of the world computer can be given solely by the accounts! This complete description is referred to as the state of the world computer. Because the world computer is always running, the state is always changing.

## Conclusion

There are external entity accounts and smart contract accounts. They completely specify the state of the world computer at all times. If you understand all that then you have taken a significant step in mastering ETC!

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Dev Team

ETC Grothendieck Team

ETC Today

ETC Slack

ETC Reddit

ETC Twitter

## ETC Development Report

ETCDev Team: Weekly Report
- (SputnikVM) First experimental project was finished. Started with second implementation
- (Emerald) Private key extraction
- (Emerald) Support for tokens
- (Emerald) Transfer and approve tokens from same interface
- (Emerald) Fully working transactions, with status update
- (Emerald) Basic support for arbitrary contracts
- (Emerald) Keystore read/store implementation
- (Emerald) Paths configuration
- (SputnikVM) New testing infrastructure
- (SputnikVM) Implementation for most basic Operations

IOHK’s Grothendieck Team Report
- Recording of the Grothendieck Team meeting from April 11th, 2017.
- https://www.youtube.com/watch?v=Sgay4pAOkY

The other stories featured in this newsletter are listed below:
- 2 additional developers joining the ETCDEV Team!
- Stampery uses ETC chain not Ethereum, help us with corrections to articles.
- Bitcoin Unlimited mining pool ICO terminated.
- Article on the white hat DAO refund.
- Let’s Talk ETC #13, Daniele Levi Discusses Stampery.
- Create and immutable record of existence on stamp.io
- Chart showing the current state of the DAO refund contract.
- TradeBlock’s ECX Index for Ethereum Classic now publicly available.
- Decentralized naming service on ETC.
- Article from Dr. Seberino
- Living Room of Satoshi now lets you pay any Australian bill directly with ETC.
- Explanation of recently discovered ERC20 tokens "bug".
- Check out ETC.today!
- Let's talk ETC! Tuesdays at 7:30pm EST.
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

Also, now that monetary policy discussion has come to a close I would like to announce some ideas for more organized discussion on the following topics
- Marketing Mondays: Marketing centric discussion and ideas.
- Funding Talk Tuesdays: Funding centric debate and discussion.
- Dapper Devs Wednesdays: Dapp and development centric discussion.
- Think About It Thursdays: How can we accomplish what was discussed during the week.
- Free For All Fridays: Brainstorm/community questions/discussion open to anything.

## New Devs

2 additional developers are joining the ETCDEV Team.
- https://twitter.com/etcdev/status/852279442886057984

## Bitcoin Unlimited mining pool ICO terminated.

The Bitcoin Unlimited mining pool ICO launched by Chandler Guo has been terminated due to not reaching expected targets for funding.
- https://cointelegraph.com/news/in-blow-to-bitcoin-unlimited-chandler-guo-terminates-ico-for-new-mining-pool

## Article on the white hat DAO refunds..

“The White Hat Group could receive $4.4 million next week….”
- https://news.bitcoin.com/white-hacker-groupl-claim-4-4-million-controversial-dao-refund/

## Stamp.io and record immutability.

“Create and immutable record of existence on stamp.io…”
- https://stamp.io/stamp/j1f2bjfv

## DAO refund chart.

Chart showing the current state of the DAO refund contract.
- https://np.reddit.com/r/ethereum/comments/64rm7m/chartbalanceofthedaoetcrefundcontract/

## Public ETC index released.

TradeBlock’s ECX Index for Ethereum Classic now publicly available.
- https://tradeblock.com/blog/tradeblocks-ecx-index-for-ethereum-classic-now-publicly-available

## Decentralized naming service on ETC.

Decentralized naming service has been released on ETC, check out the reddit post below for more details.
- https://www.reddit.com/r/EthereumClassic/comments/64ixjb/decentralizednamingserviceyoudontneedabito/

## Article from Dr. Seberino.

“Ethereum Classic Public And Private Keys: A Little Enlightenment.”
- https://steemit.com/eth/@cseberino/ethereum-classic-public-and-private-keys-a-little-enlightenment

## Pay your bills with ETC.

Living Room of Satoshi now lets you pay any Australian bill directly with ETC.
- https://www.livingroomofsatoshi.com/?sc=etc

## ERC20 token “bug” explanation.

Explanation of recently discovered ERC20 token "bug". The bug is specific to exchanges but it is still important to understand the implications and the causes.
- https://www.reddit.com/r/EthereumClassic/comments/63udrb/explanationofrecentlydiscoverederc20tokens/

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Every Friday.
Every Friday we will be discussing what's going on in the ETC community and beyond. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33K followers.
- Reddit /r/EthereumClassic - 3,273 subscribers.
- Slack - 2,471 users.
- WeChat - 497 users.
- Miners - 1083.49 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 359.43 GH/s
- NanoPool 153.14 GH/s
- F2Pool 102.94 GH/s
- MiningPoolHub 71.55 GH/s
- Coinotron 24.31 GH/s

## Introduction

Interactions with the Ethereum Classic (ETC) system depend on special numbers referred to as public keys and private keys. Private keys are used to transfer funds, install programs, and, run programs. These numbers must be kept secret at all times. Public keys are used to confirm knowledge of private keys without their disclosure. Public keys also provide a means of identifying accounts.

## Details

Private keys are 32 byte numbers between 1 and

inclusive. People randomly select them. Some may be concerned that two people might unintentionally select the same private key. The odds of that happening are vanishingly small. In fact, the number of possible private keys is approximately equal to the number of atoms in the entire universe!

Public keys are 64 byte numbers derived from private keys using an odd type of arithmetic with respect to pairs of numbers. Here is a Python script that calculates public keys from private keys:

The reason for this convoluted process is so that private keys cannot be derived from public keys. If you want to learn more, investigate elliptic curve cryptography. The reason for this name is that historically it followed from calculations of the arc lengths of ellipses.

## Miscellany

### Addresses

The first 20 bytes of Keccak 256 hashes of public keys are referred to as account addresses. These are most often used to identify accounts rather than public keys. Interestingly, public keys cannot be determined solely from addresses.

Here is a Python script that calculates addresses from public keys. It requires the PySHA3 package. Addresses are typically expressed in hexadecimal notation and that convention is followed in this script:

### Signatures

Private keys provide a way to effectively sign transactions. For this, ETC uses the Elliptic Curve Digital Signature Algorithm (ECDSA). The basic idea is to create sets of numbers, corresponding to transactions, that can only be generated by the sending account private keys. This is analogous to handwritten signatures that can only be generated by the corresponding hands.

### Programs

Programs, or smart contracts, do not have their own public and private keys. Therefore, programs cannot digitally sign transactions. Furthermore, program account addresses must be selected by some other means.

## Example

Here is a slightly edited session, on a Linux computer, that calculates a public key and address with regards to a random private key. It uses the aforementioned scripts saved in files called etcpubkey and etc_address respectively:

## Conclusion

Public and private keys are widely used in ETC and in other technologies. Therefore, I hope this has been enlightening.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

## Links To Our Community

ETC Website

ETC Dev Team

ETC Grothendieck Team

ETC Today

ETC Slack

ETC Reddit

ETC Twitter

## ETC Development Report

ETCDev Team: Weekly Report
- Two new developers joined the team, Wei Tang @sorpaas and Isaac Ardis @ia
- (Emerald) Signing transactions
- (Emerald) New key generation
- (Emerald) Gas estimation
- (Emerald) Contract creation
- (Emerald) Ability to run as desktop app
- (SputnikVM) Most of operations are implemented now
- ETCDEV Team has been working closely with the Ethereum Classic community, and wants to direct attention to the fact that part of the progress mentioned above was made by community members. We want to say special thanks to community members who also contributed this week; elaineo and gagarin55.
- Recording of the Grothendieck Team meeting from April 18th, 2017.
- https://www.youtube.com/watch?v=pVdynxZ9F3E

The other stories featured in this newsletter are listed below:
- ETC surges towards 300 million marketcap.
- Check out Dexarans' smart lottery post on reddit.
- WHG has extended the DAO withdraw contract.
- Let’s Talk ETC #14 with Joel Dietz aka fractastical.
- Interesting tweet on ‘conservative’ vs ‘progressive’ blockchains.
- Tai Zen discusses ETC with Carlos G
- Check out ETC.today!
- Let's talk ETC! Fridays.
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

Also, now that monetary policy discussion has come to a close I would like to announce some ideas for more organized discussion on the following topics
- Marketing Mondays: Marketing centric discussion and ideas.
- Funding Talk Tuesdays: Funding centric debate and discussion.
- Dapper Devs Wednesdays: Dapp and development centric discussion.
- Think About It Thursdays: How can we accomplish what was discussed during the week.
- Free For All Fridays: Brainstorm/community questions/discussion open to anything.

## ETC surges!

ETC has pushed upwards to new all time highs and is now near $300 million market capitalization.
- https://coinmarketcap.com/currencies/ethereum-classic/

## DAO withdraw contract extended.

The ‘White Hat Group’ has extended the DAO withdraw contract t0 2018.
- https://www.reddit.com/r/ethereum/comments/65ex5c/whgwithdrawcontractextended/)

## Smart lottery....

Check out Dexarans' smart lottery post on reddit.
- https://www.reddit.com/r/EthereumClassic/comments/65bcu0/dexaranssmart_lottery/

## Let’s Talk ETC #14

Let’s Talk ETC #14 with Joel Dietz aka ‘fractastical’.
- https://www.youtube.com/watch?v=bInUynB1HNw

## Conservative vs progressive blockchains?

Interesting tweet on ‘conservative’ vs ‘progressive’ blockchains.
- https://news.bitcoin.com/white-hacker-groupl-claim-4-4-million-controversial-dao-refund/)

## Tai Zen discusses ETC with Carlos G

Ethereum Classic For Investors #16 - Difference Between ETC Dev vs. IOHK Developers - By Tai Zen.
- https://www.youtube.com/watch?v=ItqTxBhFJDE

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Every Friday.
Every Friday we will be discussing what's going on in the ETC community and beyond. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 33.7K followers.
- Reddit /r/EthereumClassic - 3,284 subscribers.
- Slack - 2,545 users.
- WeChat - 482 users.
- Miners - 947.15 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 350.07 GH/s
- NanoPool 153.54 GH/s
- MiningPoolHub 139.73 GH/s
- F2Pool 118.63 GH/s
- coinotron 27.54 GH/s

The Ethereum Classic (ETC) blockchain organizes information into blocks. These
help improve performance and minimize storage requirements. Blocks can be
divided into headers,
transaction
lists, and, uncle header lists. It is informative to also consider the following
three alternative block element divisions: context, computation and
consensus categories.

## Context

The context, or environment, of all ETC computations must be completely
specified. Therefore, blocks contain block numbers, parent header
hashes,
dates and times. Parents of blocks are the preceding blocks:

### Block Numbers

Every block has a unique identifier equal to the number of past blocks. The
first (genesis) block has an identifier of zero.

### Parent Header Hashes

All block elements, except for the transaction and uncle header lists, form the
headers. Every block contains the Keccak 256 hash of the header of its parent.
This is partially for security reasons.

### Dates & Times

All blocks contain the date and time they were added to the blockchain. This is
denoted by the number of seconds since 1970–01–01 00:00:00 UTC.

## Computation

All ETC computations must be completely specified as well. Therefore, blocks
contain transaction lists, transaction list hashes, transaction list gas
requirements, transaction list state hashes, transaction
receipt
list hashes, and, transaction receipt list Bloom
filters.
It may seem problematic that blocks only contain hashes of states and
receipts. This is acceptable because the blockchain contains sufficient
information to repeat the entire history of the ETC world computer. Therefore,
the blockchain implicitly contains all states and receipts:

### Transaction Lists

Entities external to ETC submit jobs as transactions. Blocks contain lists of
these transactions.

### Transaction List Hashes

Blocks contain the Keccak
256
hashes of special
trees
formed from their transaction lists. This is partially for security reasons.

### Transaction List Gas Requirements

ETC resources are measured in units of gas. Blocks include the number of gas
units required to execute their transaction lists.

### Transaction List State Hashes

The
state
refers to all the values in all the accounts. Blocks must specify the states
after the transaction lists, and the related chores, have been executed.
Therefore, blocks include the Keccak 256 hashes of special trees formed from
these states.

### Transaction Receipt List Hashes

Execution information for all transactions is included in receipts. These are
used by search engines and other applications. Blocks contain the Keccak 256
hashes of special trees formed from their list of transaction receipts.

### Transaction Receipt List Bloom Filters

Bloom filters are binary strings used to quickly determine set membership with
nominal storage requirements. Blocks contain Bloom filters for their sets of
transaction receipt logs.

## Consensus

Mining is the process of creating and validating new blocks. This is referred to
as mining because the participants (miners) are rewarded with newly created
funds. The mining procedure is referred to as the consensus algorithm. This
involves a race to find the proof of work information necessary to create new
blocks. The block candidates that lose this race are referred to as the uncles
since they are related to the parents. All information pertaining to the
consensus algorithm must be specified. Therefore, blocks contain: miner extra
data, miner
addresses,
miner validation helps, miner gas maxima, proof of work information, proof of
work difficulty levels, uncle header lists, and, uncle header list hashes:

### Miner Extra Data

Miners can optionally include up to an additional 32 bytes in blocks they
create. There are no further restrictions on this element.

### Miner Addresses

Miners specify account addresses to receive mining rewards in the blocks they
create.

### Miner Validation Helps

Miners include values to speed up block validation. Blocks could in principle
have been designed without these aids. However, some denial of service attacks
are possible if block validation is too slow.

### Miner Gas Maxima

Blocks specify the maximum possible gas requirements of transaction lists.
Miners can adjust these maxima by small amounts relative to the parents.

### Proof Of Work Information

Miners can only add new blocks to the blockchain if they compute the proof of
work information for those blocks. This proof of work information is included in
the blocks.

### Proof Of Work Difficulty Levels

The consensus algorithm automatically increases the difficulty level for finding
proof of work information when new blocks are being added too quickly. Likewise,
the difficulty level decreases when new blocks are being added too slowly.
Blocks include their proof of work difficulty levels.

### Uncle Header Lists

Blocks contain lists of uncle headers. This improves the security of the
blockchain.

### Uncle Header List Hashes

Blocks include the Keccak 256 hashes of their uncle header lists. This is
partially for security reasons.

## Conclusion

Considering these context, computation and consensus categories has hopefully
been enlightening. Sometimes different perspectives can make all the difference.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

The Ethereum Classic (ETC)
blockchain
makes possible an unstoppable, reliable, auditable, trustless and secure world
computer. It exists to serve people. For this reason, it will turn out the
system requires payments leading to transactions and receipts. These
enable people to: send data, send funds, install programs, and, execute
programs. All data, funds and programs are associated with
accounts.

## Payments

People initiate all activity. (Internet devices may also interact with ETC,
but, they are always doing so on behalf of humans.) Therefore, an access control
system is necessary. The ETC access control system relies on payments. These
are made with transactions.

## Transactions

Transactions are data structures containing six elements: an address, datum,
gift, offer, nonce and signature.

### Addresses

All transactions are sent to and from accounts. Accounts are specified by
addresses. Transactions contain receiving account addresses. These are not
used in program installation transactions as they require the creation of new
accounts.

### Data

Transactions send data to accounts. Account programs (smart
contracts)
operate on the data they receive. In program installation transactions, the data
are the program constructors. Constructors allow additional flexibility in
program installation like programs that vary with block numbers.

### Gifts

Transactions can send monetary gifts to accounts. The amounts are denoted in
units of aETC (10⁻¹⁸ ETC) or weis.

### Offers

Resource requirements to execute transactions are measured in gas. Execution
gas requirements may be unknowable beforehand, and, the required mining fees can
vary. Therefore, transactions contain offers. These specify prices willing to
pay per gas unit, and, the maximum gas units willing to purchase.

### Nonces

Accounts have counters denoting the number of transactions they have written to
the blockchain. These counters are referred to as nonces. Nonces are included
in transactions partially to protect against replay
attacks.

### Signatures

For security reasons, sending accounts must digitally sign all transactions.
Digital signatures are specified with three values using the Elliptic Curve
Digital Signature Algorithm (ECDSA). The sending addresses of transactions can
be determined from the digital signatures.

## Receipts

Transaction execution details are available in data structures referred to as
receipts. Receipts are used by search engines and other applications.

## Conclusion

Transactions are foundational to ETC. They allow humans to interact with it in a
usable manner. Understanding transactions will help you become an ETC guru.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

Proof of
work
systems are widely used and have been thoroughly scrutinized. There is concern
that funds will be at risk if proof of work systems are replaced with proof of
stake systems. Fortunately, proof of stake systems can improve security rather
than threatening it!

## Proof Of Stake

In proof of work systems, volunteers assist in the creation and validation of
new
blocks.
Rewards are proportional to the amount of computing resources contributed to
the process. There are built in disincentives for acting maliciously or
foolishly. For example, contributing computing resources to losing chains will
lead to financial losses.

Proof of stake systems attempt to keep the benefits of proof of work systems
while eliminating the problems. There are multiple varieties and much ongoing
research. Volunteers still assist in the
creation and validation of new blocks. Rewards are proportional to the amount of
funds (stakes) temporarily placed in escrow. There are still built in
disincentives for acting maliciously or foolishly. For example, some systems
confiscate escrowed funds if volunteers simultaneously work on multiple chains.

### Benefits

Proof of stake systems can strengthen proof of work systems rather than
replacing them. They can simply add additional steps to the process of
approving candidate blocks. This is analogous to adding a second lock on a door.
Additional protections are welcome because proof of work systems are vulnerable
to participants who control a majority of the computing resources. This can lead
to 51% attacks:
"[A] mining pool — an association of people who own specialized hardware that
produces Bitcoins by running specific mathematical operations — gained a 51
percent share of computing power used in currency production. That gave it the
power to reverse transactions, to pay twice with the same Bitcoins, and to delay
or even cancel other people’s transactions. The pool was GHash.io, run by a
secretive U.K.-incorporated outfit called CEX.io"
Bloomberg, July 17,
2014

and
"I am Chandler Guo, a 51% attack on Ethereum Classic (ETC) is coming with my
98G hashrate. This is roughly 3 times [the] current ETC network hashrate. This
is an action to against Poloniex’s decision to support ETC."
Cointelegraph, July 24,
2016

Such attacks might not be possible with proof of stake system additions.

### Concerns

It is possible that vulnerabilities might be found in proof of stake systems.
Although combining proof of work and proof of stake systems would likely be
beneficial, there might still be problems. This is analogous to losing the key
to a second door lock. Multiple door locks provide additional security, but,
they also increase the chances of denying yourself access.

## Conclusion

Proof of stake systems do not necessarily have to eliminate proof of work
systems. Blockchain systems can simultaneously juggle security and innovation.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgments

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

## Links To Our Community

ETC Website

ETC Dev Team

ETC Grothendieck Team

ETC Today

ETC Slack

ETC Reddit

ETC Twitter

## ETC Development Report

ETCDev Team: Weekly Report
- (Geth) New command line args to clean/rollback blockchain
- (Geth) Improved logging
- (Geth) Internal release for testing
- (Emerald) Use Address Book for transactions
- (Emerald) Install Smart Contracts, show basic details and interaction
- (SputnikVM) Working on confirming all official tests for EVM
- ETCDEV Team has been working closely with the Ethereum Classic community, and wants to direct attention to the fact that part of the progress mentioned above was made by community members. We want to say special thanks to community members who also contributed this week; elaineo, gagarin55 and tranvictor
- Recording of the Grothendieck Team meeting from May 9th, 2017.
- https://www.youtube.com/watch?v=5iq0Caaym-4

The other stories featured in this newsletter are listed below:
- Provably fair ETC gaming platform launched.
- Force behind Ethereum Classic price wave: Community.
- Great post on reddit about investing in cryptocurrency.
- Digix To Return 465,000 ETC To DGD Token Holders.
- Crypto price analysis by Cointelegraph.
- Ethereum Classic For Investors #18 - What Is Stampery?
- Ethereum Classic For Investors #19 - Monetary Policy.
- Korean exchange Bithumb announces support for ETC.
- Check out ETC.today!
- Let's talk ETC! Fridays.
- ETC looking for Rust and JS developers.
- Call To Action : Help with ETC Wikipedia page.
- Community metrics detailed at the bottom of this newsletter.

Also, now that monetary policy discussion has come to a close I would like to announce some ideas for more organized discussion on the following topics
- Marketing Mondays: Marketing centric discussion and ideas.
- Funding Talk Tuesdays: Funding centric debate and discussion.
- Dapper Devs Wednesdays: Dapp and development centric discussion.
- Think About It Thursdays: How can we accomplish what was discussed during the week.
- Free For All Fridays: Brainstorm/community questions/discussion open to anything.

## Check out ETC.today!

Ethereum Classic Today! Your daily hit of ETC, Bitcoin, blockchain news and updates.
- http://etc.today/

## Let's talk ETC! Every Friday.
Every Friday we will be discussing what's going on in the ETC community and beyond. A link to the channel will be posted below, if you have ideas or questions please let us know. Thank you for subscribing to our latest updates and announcements!
- https://www.youtube.com/user/chrisseberino

## Ethereum Classic is looking for Rust & JS developers.

Igor aka Splix is looking for talented Rust and JS developers. Full time, remote. Experienced developers, which can lead projects, make architectural decisions and help other team members to do their job. Self motivated and able to work in a distributed team on Open Source software together with the community.
- https://www.linkedin.com/pulse/rust-js-developers-ethereum-classic-igor-artamonov

## "Call To Action" still in effect. Looking for community contributions for the ETC Wikipedia page.
Reddit user "bitp" has brought it to the communities attention that the "Ethereum Classic" Wikipedia link currently redirects to "Ethereum". ETC community member /u/FaceDeer was previously a Wikipedia editor and has provided some insight on what should be done moving forward. One of his recommendations is that we start the process by adding to the Ethereum Classic section that is currently on the Ethereum Wikipedia page. ETC can then be given its own page after volunteers have submitted enough info. Please see his full post in the reddit thread linked below.
- reddit.com

## Community Metrics
- Twitter - 35.6K followers.
- Reddit /r/EthereumClassic - 3,628 subscribers.
- Slack - 3,014 users.
- WeChat - 489 users.
- Miners - 2,017.97 Total GH/s

## Top 5 miners by average hashrate from the previous 7 days.
- EtherMine 617.93 GH/s
- NanoPool 296.04 GH/s
- F2Pool 263.41 GH/s
- Clona Network 76.18 GH/s
- MiningPoolHub 60.47 GH/s

## A take on radicalism and diplomacy

Radicalism is often seen as a bad thing when in essence it is good. In latin radix means root, therefore being radical means going to the root cause of the matter and taking action to improve it. In the other hand diplomacy is mostly seen as a good thing, mainly because people naturally understand that a diplomatic person is skilled and tactful in dealing with sensitive matters or people.

So being radical and diplomatic at the same time is possible as there is no conflict with these values.
Ethereum Classic is radical in preserving the truth and diplomatic keeping community united for a greater cause.

Radicalism is also evident in Bitcoin community where cypherpunks were radical about creating the peer to peer electronic cash system confining trust rather on cryptography than in the government competence.
In cryptography we trust.
Fiat money's value reflects the government competence to give it value.

Being mostly radical and against the use of force at the same time is a tendency to be anarchist. Most people actually are, but they just don't realize.

## Anarchism and power centralization

Nature itself is mostly anarchist.
Individuals take actions when they strongly feel about a cause.

That is naturally decentralized too. Centralization is actually a recent invention in anthropology. Men didn't know they were parents in the past and women were perceived as divine creatures with the gift to generate life. Once men started to understand that those were their kids, private property was established generating the fundamental spark for the advent of centralization.
Then family hierarchy and powerful heritages being passed to next generations started to change the landscape so rapidly mainly because power started to centralize. As a result, wars started to happen more often and peace became more difficult to settle.
If you don’t fight for your clan you are a deserter and deserves to die.

The power centralized in the hands of few people increases the chances that more lies will be spread to better picture their own interests.
To minimize the effect of power being wasted in vain, technology can be used for example to not tolerate lies to be easily spread by ruling parties. Unfortunately, in the 21th century, humanity still has plenty of ideologies out there posing great barriers to make a real positive difference. I trully believe that ideologies can be greatly reduced with technologies like the Blockchain.
Ideology is a lie told in a beautiful way.

## A world of so many lies

Why are those people going to war?
They are protecting women, human rights, they are fighting for freedom and so on.

A lot of people often say. In reality, they are making war for keeping and making the most powerful people even wealthier.
So the great opportunity for the Blockchain first is telling the right history in such a way it can't be rewritten. The wining party won’t be able to transform reality into a heroic tale.

## Immutability, my friends!

We are in a special moment in history, never in the past we had as much available human intelligence (7 billion people) and computing power we currently have today. The question is how can we improve the efficiency of the available human intelligence?

Immutability is instrumental in preserving the truth and it is also the main value for the insurgence of Ethereum Classic against Ethereum foundation. Once truth is preserved it becomes less hard to control our own existence. The reason is historic truth allows that future generations be able to process cause and effect in a better way with greater processing power than we actually have. So they can set better control mechanisms to make sure sustainable development goals are going to be reached faster and that the mankind is going to be good in essence not evil.

## Social and Financial Value

How to reduce hypocrisy in the social and financial area? Some might ask.
All major companies are social and financial power houses.

C'mon we know it is not true. There are solid metrics already available today to measure not only the financial but also the social impact a company has. And the evolution of that can be recorded live to the Blockchain. It then becomes natural to account for reaction of company's maneuvers. This is radical in the sense that instead of just an empty beautiful speech, real impact is measured, recorded and controlled within the desired range by society.

Sooner or later mankind will also be responsible to drive human genetics evolution artificially. But for that not having terrible outcomes, the truth needs to prevail. So lets record it live in a decentralized way were no player has enough power to cheat the network.

## Invitation for engagement

Stand up from the crowd, do your homework, become more conscious about the challenges and opportunities the world current faces. And let us shape the future of the Blockchain together. Ethereum Classic has a revolutionary technology and can be a disruptive decentralized community as no other. Fight for this cause, let us lead the technology revolution!

Many initiatives are raising capital with initial coin offerings (ICOs). The Ethereum (ETH) project raised 18 million dollars and the DAO project raised 150 million dollars! Furthermore, the entire blockchain space is worth 90 billion dollars! I will describe ICOs and their custom cryptocurrencies on Ethereum Classic (ETC).

## ICO Basics

An ICO is a method of raising funds with the sale of a new cryptocurrency. These cryptocurrencies are often required to purchase goods and services from the issuing organizations. For example, the ETH cryptocurrency (ether) is used to rent ETH system resources. Upcoming ICOs are typically announced on Bitcointalk.org forums and heavily marketed beforehand. Buyers often purchase the new cryptocurrencies by sending bitcoins or ether to escrow accounts. The initial prices are set, then supply and demand determines the future prices. If the organizations are well managed, and their cryptocurrencies prove useful, they should both increase in value. If prices skyrocket, minuscule cryptocurrency subdivisions can typically be used. For example, ETC cryptocurrency tokens can be subdivided into as many as 10 18 pieces.

Caution is required with ICOs as they are effectively unregulated. Participants do not purchase ownership in companies, nor, many privileges protected by established case law. There is great potential for innovation as well as scams. Smith & Crown and ICOrating are two resources that can assist with ICO research.

## ICO Cryptocurrencies

Cryptocurrencies are implemented with smart contracts. ETC provides an excellent smart contract platform. It has all of the functionality of ETH at a fraction of the cost.

Many exchanges and other users prefer crytocurrencies to adhere to the Ethereum Token Standard. This standard specifies the following interfaces for cryptocurrency smart contracts:

| INTERFACE | DESCRIPTION |
|------------------------------------------------------|-----------------------------------|
| transfer(receivingaddress, transferamount) | Transfers funds between accounts. |
| balanceOf(accountaddress) | Returns account balances. |
| totalSupply() | Returns the total supply. |

The standard also specifies the following interfaces for when a user wants another account to also manage their funds:

| INTERFACE | DESCRIPTION |
|-------------------------------------------------------------------|-------------------------------------------|
| approve(approvedaddress, approvedamount) | Allows other accounts to also transfer funds. |
| transferFrom(sendingaddress, receivingaddress, transferamount) | Transfers funds between accounts. |
| allowance(sharedaddress, approvedaddress) | Returns approved amounts. |

It is also common to include the following named constants:

| NAMED CONSTANT | DESCRIPTION |
|----------------|-------------------------------------------------------------|
| name | cryptocurrency name |
| symbol | cryptocurrency exchange ticker symbol |
| decimals | cryptocurrency maximum number of subdivision decimal places |

For example, the ETC cryptocurrency exchange ticker symbol is ETC. Since ETC cryptocurrency tokens can be divided into as many as 10 18 pieces, the maximum number of subdivision decimal places is 18.

### Sample Code

There are many Ethereum Token Standard compliant Solidity smart contract examples available. Here is an example of an Ethereum Token Standard compliant Serpent smart contract:

## Conclusion

ICOs are a new way to raise funds and the ETC platform is an excellent choice for the required cryptocurrency smart contracts. Vigilance due to the lack of regulations remains important. Hopefully, mechanisms to protect against abuse will allow an ever growing number of people to reap the benefits.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

Privacy is the power to control the communication of personal information.
Recent news may discourage some people involved with Ethereum Classic (ETC) from
protecting privacy. Here are the basics of privacy including why it is
indispensable:

## Universal & Traditional

The Constitution does not explicitly mention a right to privacy. However,
according to the Supreme Court, it contains an implicit right to privacy.
Justice William O. Douglas, in Griswold v. Connecticut (1965), wrote that
privacy is “within the penumbra of specific guarantees of the Bill of Rights”.
Furthermore, 150 countries have constitutions granting explicit privacy
rights. The United Nations Declaration of Human Rights also explicitly mentions
a right to privacy:
“No one shall be subjected to arbitrary interference with his privacy, family,
home or correspondence, nor to attacks upon his honour and reputation. Everyone
has the right to the protection of the law against such interference or
attacks.”

A right to privacy is not a new and radical idea. Rather, it is a universal and
traditional one. The Ethereum Classic community is just promoting the principles
of the United States, 150 other countries, and, the United Nations!

## Beneficial & Necessary

Privacy is beneficial partly because everyone wants to hide something that is
appropriate to be kept secret! For example, some may: be working through
embarrassing medical or psychological issues, be on their honeymoon, be
awkwardly exploring new artistic endeavors, or, just be going to the bathroom.
The actions of people that say privacy is not important reveal their true
sentiments. Mark Zuckerberg of Facebook purchased the
houses surrounding his
California home to ensure a haven of privacy. Eric Schmidt of Google punished
CNET for publishing
some of his personal details. Glenn Greenwald, the Guardian reporter who
assisted Edward Snowden, challenges anyone that thinks privacy is not important
make all their emails public. Nobody has yet met his challenge!

Privacy is also beneficial because no government is completely free from
corruption. Global surveillance, confiscation of funds and censorship are just a
few examples of documented governmental abuse. Imagine if you had never heard of
Thomas Jefferson, Martin Luther King, Mahatma Gandhi and Julian Assange because
dissent was not possible.

Some believe privacy must be sacrificed for security. However, it is possible to
have security and privacy. They are not mutually exclusive. An apartment complex
could implement an identification card system thereby providing security at the
expense of privacy. Alternatively, door locks and alarm systems could provide
the same or better security while maintaining privacy!

## Conclusion

A right to privacy is an old, traditional, beneficial and necessary idea. The
Ethereum Classic community is doing a public service in promoting it.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

People often ask the Ethereum Classic (ETC) developers to return their lost
funds. Typically, no one can steal or return lost funds. This is because of
private keys.

## Private Key Basics

Private keys are just random numbers. All ETC user accounts are associated with
unique private keys. These are needed to do nearly everything. ETC clients
(wallets) typically manage user accounts and private keys for users. In my
Ethereum Classic Public And Private Keys: A Little
Enlightenment
paper I show how to derive ETC public keys and addresses from private keys.

## Private Key Security

If private keys are truly random, and kept private, they simply cannot be
determined. Notice cryptographically secure random number generators are
crucial. Some may wonder whether ETC public keys and addresses can divulge
private keys. Computing private keys from ETC public keys and addresses is
unimaginably difficult. It would take billions of computers longer than the
age of the universe!

## Private Key Possibilities

Future mathematical breakthroughs and quantum computers could conceivably
jeopardize ETC private keys. However, after decades of work, these breakthroughs
are still elusive.

## Conclusion

The ETC system was designed to give users control over their funds. Therefore,
typically no one can steal or return lost funds. So please do not ask the ETC
developers to do the impossible!

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

## Ethereum Classic welcomes Ethereum Commonwealth

"If by my life or death I can protect you, I will. You have my sword..."
Aragorn - J.R.R Tolkien

We are very happy to welcome Dexaran's soon to be development team called Ethereum Commonwealth as one of the development powers behind Ethereum Classic. As you know your team is joining us at an exciting time in history, as Ethereum Classic is shifting from the incredible burst of expansion (inflation) to the cooling down phase where matter starts to be formed.

Source BBC

We are hopeful that with your fresh ideas and enthusiasm, this will be one of our best years ever! The community is projecting unprecedented growth this year, and we are counting on you to help us get there.

When you have already established your team, let's coordinate efforts to expand the community in several different and complimentary dimensions. We are all looking forward to working with your team and are certain that you guys are going to be yet a great power to Ethereum Classic as Grothendiek and ETC Dev teams are. Welcome aboard!

## Pledge for support
Contribute to the many development teams powering Ethereum Classic technology, help teams to be born by supporting them as you can. We as a community thank all the brave work already done by developers. But still there is a lot to do.

Source Little Time Machine

There is a beautiful horizon ahead, so let us shape with joy and enthusiasm the future together for good!

The most ambitious goal for Ethereum Classic (ETC) is to replace the World
Wide Web (Web). Blockchain based replacements for the Web are often referred to
as Web 3.0.

## Web 2.0

The Web was developed by Tim Berners-Lee and first made publicly available in
1991. It is a user friendly general purpose system based on the Internet.
Initially the Web mainly contained simple static content such as primitive
personal home pages. As the Web evolved, greater dynamism and interactivity was
possible such as with social media. This improved Web is often referred to as
Web 2.0. The term was popularized by Tim O’Reilly.

## Web 3.0

Neither the Internet nor the Web were initially designed to be trustless
systems. Components have been steadily introduced to improve security such as
Transport Layer Security (TLS), certificate authorities, and, Domain Name System
Security Extensions (DNSSEC). Unfortunately, many such improvements are only
partially adopted.

Gavin Wood popularized the term Web 3.0 for blockchain based trustless
alternatives to the Web. Confusingly, Web 3.0 also sometimes refers to the
Semantic Web. Furthermore, Web3 also refers to a standard set of ETC application
programming interfaces.

### Peer To Peer

Web 3.0 is a peer to peer replacement for the Web. A peer to peer architecture
is required to build trustless systems.

### Pseudonymous

Web 3.0 users are pseudonymous. They are only identified by their accounts,
unlike the Web, where addresses can be associated with identities.

### Extensible

ETC requires access to additional short and long term storage systems to replace
the Web. The InterPlanetary File System (IPFS) is an example of a compelling
peer to peer storage system that can integrate with ETC.

### Evolving

The Web currently coexists with blockchain systems. Websites access these
systems to provide additional functionality. As ETC and related systems mature,
browsers will increasingly just point to these Web alternatives thus ushering in
the era of Web 3.0.

## Conclusion

A public, censorship resistant, pseudonymous, auditable, reliable, secure and
trustless replacement for the Web is a compelling vision. ETC, IPFS and related
tools can deliver Web 3.0. It is therefore understandable why so many are
enamored with ETC and its potential.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

ImageSource: MoneyMetals.

## A new hope
Never before in history mankind had as much available computing power, and also never had as much available human intelligence we have now - over 7.5 billion human brains. How come we are still very primitive in several aspects of life? The reason is trivial. Most individuals are not contributing at all for this global community we happen to be now, they are unfortunately marginalized by the system. To better illustrate the problem:
- 40% of mankind lives with less than 2.5 dollars per day;
- 80% of mankind lives with less than 10 dollars per day;
- only 1.73% of mankind are satisfied with their jobs.

Source: Singularity Global Summit 2017.

Back in 2009, when bitcoin was quietly born in the form of an innocent whitepaper, people didn't realize its disruptiveness. In fact, most people still don't.
Bitcoin permanently revolutionizes the world because of the digitalization power it presents. Although digitalization is a broad term, comprising many technological breakthroughs, the strong pattern emerging is that it promotes otherwise marginalized use cases and people to participate in harmony within society. The iterative process strongly blows the sails of the circular economy windmill - the main propeller for cryptocurrencies explosive growth.
Is there a way to boost the nascent contributions of these use cases and people sooner?

Organizations and governments have struggled with a variety of means for the last centuries. Corruption, lack of transparency, inneficiency and insufficient funds plague the process. And that is exacly why the strongest instrument for social inclusion so far was a recent invention from a pseudonimous person or entity who, together with the community, gave birth to the first social coin, the Bitcoin. How productivity would be if 99% of mankind were satisfied with their jobs?
That is impossible!

Some will say. I believe it is no only possible but the next generation can already achieve it, our kids and grandkids. And here is why.

## The power of the circular economy
Linear economy considers a narrowly defined production model and analysis to maximize profits - only financial dimension. In contrast, circular economy takes into consideration all possible dimensions related to a given activity. It is a multi-objective optimization process where every dimension is measured and controlled to achieve multiple positive outcomes. In that sense circular economy is more powerful and forward thinking than the former linear economy.
An entity that seeks only to maximize the outcome in a single dimension is deemed to fail. The reason is dimensions reflect on each other. A person, for example, most likely won't be happy scoring greatly on spirituality and terribly on health, as the key for happiness is rather a balance on all dimensions. More happiness then boosts the positive outcome on every single dimension as a fortunate consequence. In this regard there is a clear indication that the investment done in the worst performing dimension has greater net impact.
The circular economy development process involves accounting for all the relevant dimensions, simulating and taking action, and measuring impact. It is an iterative process where the outcome of the initial actions are translated into stronger actions able to drive greater impact next round. And naturally, as a consequence, compounded growth is achieved. In other words, circular economy's power lies in the potential multi dimensional controlled growth achieved with the application of its concepts.

## Boosting circular economy to a whole new level
Bitcoin divided the history in two, before and after, and has increadibly transformed the landscape in several relevant dimensions enabling one key pillar of the future society: decentralized finance.

 The four pillars of a decentralized society | Johann Gevers | TEDxZug from TEDx Talks on YouTube .

But there is a derived technology from Bitcoin that can have much greater impact on circular economy - Ethereum. It enables another key pillar of the future society: decentralized law. I don't mean here just the regular law as we know it, but the law as the universe knows it.
Researchers are constantly discovering new laws and relationships that rule the universe. With a better understanding of these laws, predictions of the future are more fit. Likewise circular economy researchers are finding new mechanisms that can be coded into laws, through smart contracts, to grow faster in a more predictable and sustainable way.
As the scope of circular economy can be too wide to properly address all possible dimensions, breaking down social coins into categories is handy. Each category of social coin then has its own ecosystem and is independently driven by its rules focusing on solving a given family of problems.
Ethereum Classsic, besides decentralized law, works hard to also enable the most important pillar of the future society: decentralized governance. Are also pillars of the future society, decentralized communications and decentralized production.

## CCEG now supports Ethereum Classic
We are currently preparing for a small UK£ 5m ICO seratio-coins.world which meets our needs. We have stated that any raise beyond this we would act as a foundation and support worthwhile SDG compliant causes. We think ETC represents this and would be happy to support the work here to a maximum level of UK£ 1M.
Olinga Ta'eed - CCEG director

The Centre for Citizenship Enterprise and Governance is an independent not for profit research think tank and policy institute concerned with the development and use of social value metrics as a measure to promote a just, prosperous and sustainably secure global society.

Seratio is the hosting platform for the social coins ecosystem, say the enterprise ship. And the social coins will be launched by the plaform and will be compatible to transact with its infrastructure. They are kind of independent in the sense states are inside a country. But there is a healthy federation that helps states to succeed in a better way.

Besides the financial support mentioned above CCEG is looking forward to deploy the first 3 social coins to Ethereum Classic network.
We would be happy to place our next 3 ICO's on ETC, out of a dozen commissioned, as long as our partners are agreeable
Olinga Ta'eed

 Seratio Token Vision from Centre for Citizenship, Enterprise and Governance on YouTube .

Gather ‘round boys and girls, it’s time for an update on where Ethereum Classic
is and where it’s heading.

## Development is expanding, marketing is ramping up, and we got spammed

We’ve got the ETC Summit, 4 new ETCDEV Team
members, 2 new
members of the Ethereum Commonwealth, constant
Twitter updates, and a great
podcast.
We’ve actually had the podcast for a while (I was even on
it!),
I just forgot to mention it in the last article. Commonwealth is even
transcribing
it.

We also had some issues with spam on Slack and no effective way to deal with it.
We just didn’t have tools on Slack. So we’ve moved to Discord. Come join us
there!

## For the users

Emerald Wallet —
Now with token and Ledger Nano S support!

Daedulus — In
development. It’s a brand new wallet from IOHK that will support both Classic
and Cardano blockchains. I’ve used it on Cardano, it’s pretty slick. Classic
support is coming soon.

DexNS
— Version 3.0 is being rolled out. It provides several advantages over
Ethereum’s ENS, instant name registration, and simple integration with
smart-contract based services.

My Ether Wallet/Classic Ether Wallet —
Cross-chain security is improving, and easier integration with tokens/DexNS is
in the works. Over 8,000 installs of the CEW Chrome Extension with 25 new users
a day!

ClassicMask — MetaMask for
the Classic network. Now with DexNS support!

Phoenix Project —
Community-created branding guidelines (and a sweet-looking
mascot) are nearly finalized. An announcement is
coming soon.

## For the techies

Callisto — Ethereum Commonwealth is planning to design and launch a new Classic
testnet called “Callisto” where new features can be tested. Yohan
Graterol is heading this project.

SputnikVM — Used
for testing new Classic contracts, written in Rust, with planned features to
make development easier. It’s been updated with better support for the Truffle
Framework and RPC calls to aid
debugging.
The more technical details are covered at Wei Tang’s wonderful
blog.

## For the blockchain

ECIP-1017 — With this fork ETC will have a stable coin
supply. Going live around December 12th.

ECIP-1035 — Stealth
addresses to keep transactions private, just like a bank account or credit card.
This builds upon ECIP-1025
which provides for RingCT/zkSNARKs-style transactions.

So there you have it, all that’s new in Classic in the past 2 months. Delivered
by our 3 development teams, ETCDEV, Ethereum
Commonwealth, and
IOHK. And this is just the new
announcements, for even more recent Classic goodness check out my previous
article.

This article is under the CC0
License. Use it however you
want.

### Pyskell

Coder, Project Manager, Blockchain enthusiast

To help people understand blockchains, I have created a blockchain game
available here. (The source code is
available here.) I will explain
the game rules and the user interface. I will also mention some possible
insights from playing this game.

### Game Rules
- Players can create and submit blocks for inclusion into chains.
- Blocks consist of five fields: block numbers, nonces, previous initials, player
initials, and, payloads.
- Chains are sets of valid blocks that are ordered by block numbers, and, that
start with block number zero.
- Blocks are valid if their hashes begin with a zero, their previous initials
equal the player initials of the preceding block in a chain, and, they
contain a payload from the payload list.
- Nonces can be changed to modify hashes.
- It is possible to submit invalid blocks.
- The game is over when at least one block has been submitted for every possible
block number.
- Winners have the greatest numbers of blocks in the longest chains.
- It is possible for the longest chain to not extend to the largest possible
block number.

### User Interface

Players can enter block fields in the form:

Players select payloads from the payload list:

Players can click the "Hash Block" button to calculate the hash of a block, or,
the "Submit Block" button to submit a block:

Submitted blocks appear in the yellow region. Valid blocks will be blue and
invalid blocks will be red:

Block numbers correspond to rows, and, there is a row for every possible block
number. Therefore, games are over when there is at least one block in every
row of the yellow region. When games are over, the blocks of the longest
chains turn white:

Refresh the web page to start new games.

### Possible Insights

The incentives for winning are the same as for mining. For example, because only
valid blocks contribute towards winning, players are motivated to validate
blocks just like in mining. Also, because only the longest chains contribute
towards winning, players are motivated to ignore the smaller chains just like in
mining.

### Final Thoughts

Hopefully this game will help illuminate many blockchain concepts. Feel free to
share it with anyone interested in blockchains.

### Feedback

You can contact me by clicking any of these icons:

### Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

### License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

First, a disclaimer, despite what you may think I have no inside information,
and honestly prefer the lack of hype to major hype. Major hype is unstable. So
get excited, but don’t get hyped.

## Digital Currency Group (DCG)

Created the Ethereum Classic Investment
Trust which brought
additional investment into Classic. They also created the ETC
Cooperative which is funding the summit and
seeking to fund other projects that improve the Classic ecosystem.

DCG will be represented by Barry Silbert (CEO), Meltem Demirrors (Director), and
Matthew Beck (Research Associate).

## ETCDEV

Has given us geth for ETC
(after EF refused to support us), Emerald
Wallet, two
blockchain
explorers, new dev
tools, and lots more. They’ve got
a whole roadmap you can check out.

Four members of ETCDEV will be attending, Igor
Artamonov (CTO), Constantine
Kryvomaz (Rust Developer), and Isaac
Ardis (Go Developer), and Matt Mazur (Advisor) who
will be talking about the ETC Monetary
Policy.

## Input Output Hong Kong (IOHK)

Is developing a new ETC node called Mantis, formalized the EVM in
K (fancy maths; great for
Classic), gave us Let’s Talk ETC, and is tying ETC
in with their
Cardano platform.

IOHK is sending four employees, Charles Hoskinson (CEO), Christian Seberino
(Education), Alan McSherry (ETC Developer), and Alan Verbner (ETC Developer). A
couple of them have been on Let’s Talk ETC as well: Charles on Let’s Talk
ETC
and Alan on Let’s Talk
ETC.

## Cody Burns

He’s worked on Classic Ether
Wallet, proposed how we can
have private addresses on
ETC, and wants to give us
cross-chain atomic
swaps.
Cody on Let’s Talk ETC.

## Stewart Mackenzie

Founded Fractalide, a marketplace designed to make ETC
contracts easier to develop. Stewart on Let’s Talk
ETC.

## Jihan Wu

He runs Bitmain and Antpool, the
largest Bitcoin mining pool.

Anyway this is only about half of the attendees, there’s lots more miners,
exchange operators, developers attending and contributing to Classic. So again,
get excited, but don’t get hyped!

#####by Pyskell

Ethereum Classic (ETC) light clients are clients that do not maintain a copy of
the entire ETC blockchain. I will explain how they can nevertheless securely
operate.

### Honest Nodes

Light clients obtain blockchain information by communicating with network nodes.
It is possible that malicious network nodes may censor blocks on the longest
chain. Light clients can still operate securely as long as they connect to at
least one honest and up to date node. It is not sufficient to connect to an
honest node. The honest node must itself be connected to another honest node,
and so on. Otherwise, honest nodes may not have all the blocks on the longest
chain.

Here is a list of honest ETC network node TCP sockets that light clients can
connect to. (This list can also be found
here.):

### Block Headers

Hashes are fixed length strings that can guarantee the integrity of all
information. Merkle trees are trees of hashes that can minimize the necessary
communication between network nodes and light clients. The tops of Merkle trees
are referred to as root hashes. Block headers contain the root hashes for light
clients to securely and efficiently obtain state and transaction information
from network nodes. Because block headers are much smaller than entire blocks,
light clients with limited storage can still operate securely by storing just
the block headers of the blockchain.

### Hash Checks

To be sure a light client is connected to the ETC network, confirm the first
block (genesis block) of the blockchain is associated with the following hash:

Also, confirm block 1,920,000 is associated with the following hash:

This block is where the ETC blockchain diverges from the Ethereum (ETH)
blockchain.

### Node Incentives

Some think the need for light clients to request state and transaction
information from network nodes might be a vulnerability. The concern is that
network nodes may not always have sufficient incentives to assist light clients.
Some have suggested compensating network nodes for assisting light clients. At
the very least, supporters of ETC are motivated to support light clients to grow
the number of users. Also, smart contract application providers are motivated to
support light clients to increase the number of potential customers.

### Conclusion

It is amazing that a protocol exists for even tiny embedded devices to securely
utilize the ETC system. By connecting to honest nodes, only storing block
headers, and, utilizing the properties of hashes, even toasters can benefit from
the ETC world computer.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

# ECIP 1017: Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule

https://ecips.ethereumclassic.org/ECIPs/ecip-1017

## Abstract

This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time.

## Motivation

At its core, the purpose of adjusting the current monetary policy of the ETC network, to a policy which places an upper bound on the number of tokens issued and decreases the rate at which ETC is introduced into the system over time, is to “bootstrap” the network’s security. By increasing the security of the network, a proper monetary policy indirectly nurtures the network, providing a secure platform for which smart contract development will be more likely to occur.

If we accept that speculation, a demand function, is the main economic driver of any new system, that the Ethereum Classic Network is a new system, and that speculation will drive the value of the Ethereum Classic token until the utility value of the Ethereum Classic token exceeds its speculative value, it is reasonable to assume that rewarding speculation will help to secure and nurture the network:

Large scale, high risk, and/or high profile applications will be less likely to be developed on a blockchain with weak security ie. a low hashrate. Increasing demand for the Ethereum Classic token will, all else being equal, increase the price of the Ethereum Classic token. An increase in the price of the token incentivizes mining operations to direct their efforts on the Ethereum Classic Network or to begin operations on the Ethereum Classic Network. The additional mining power that is directed towards the network, because of this incentive, further secures the network. An increase in the security of the network assists in building trust between the network and both current and potential users and developers of the network. This increase of trust in the network provides an incentive for large scale, high risk, and/or high profile applications to be developed on the network. Thus, rewarding speculation helps to secure and nurture the Ethereum Classic network.

Especially important to early stage cryptocurrencies, assuming all other variables are equal, a network with a decreasing rate of production and an upper bound on the number of tokens that will be issued will provide more incentive for high risk speculation to occur than one without a known rate of production or an upper bound.

Above all, it is important to recognize that a monetary policy does not directly create value for the network. A stable platform with useful applications and a vibrant community are the variables that drive value. The purpose of a properly structured monetary policy is to create an incentive for people to take a risk on a system that has not yet reached its full potential, providing an additional reason for those who may not otherwise be interested, who cannot or have not developed anything on the platform (yet), or who remain skeptical, to involve themselves in an otherwise nascent platform.

## Specification

Current Ethereum Classic Monetary Policy

The current mining rewards on the Ethereum Classic Network are as follows:
- A “static” block reward for the winning block of 5 ETC
- An extra reward to the winning miner for including uncles as part of the block, in the form of an extra 1/32 (0.15625ETC) per uncle included, up to a maximum of two (2) uncles.
- A reward of up to 7/8 (4.375ETC) of the winning block reward for a miner who has mined an uncled block and has that uncle included in the winning block by the winning miner, up to a maximum of two (2) uncles included in a winning block.
- This reward structure is set to continue in perpetuity.

Proposed Ethereum Classic Monetary Policy

An “Era” is defined as the number of blocks containing a given production rate.

The proposed mining rewards on the Ethereum Classic Network are as follows:
- Era 1 (blocks 1 - 5,000,000)
- Era 2 (blocks 5,000,001 - 10,000,000)
- Era 3+

## Rationale

Why this 5M20 model:
- Minimizes making the first adjustment too “exceptional.” Other than equalizing all uncle rewards at block 5M, the changes/reductions to supply over time are equal.
- The model is easy to understand. Every 5M blocks, total reward is reduced by 20%.
- Uncle inclusion rates through block 5M will likely remain at around the 5%. Because of this, once block 5M is reached, in the worst case scenario (supply wise, which assumes two uncles included every block in perpetuity) the total supply will not exceed 210.7M ETC. Should the network remain as efficient in its ability to propagate found blocks as it has in Era 1 (5.4% uncle rate), the total supply will not be less than 198.5M ETC. This provides for an incentive to miners and client developers to maintain high standards and maintenance of their hardware and software they introduce into the network.
- The 5M model provides a balance between providing an acceptable depreciating distribution rate for rewarding high risk investment into the system and maintaining an active supply production over time. Maintaining this future supply rate keeps the potential price of the ethereum token suppressed enough to ensure transaction prices can remain lower than if the supply were to reduce to zero at an earlier date. This serves as a “blow off valve” for price increases in the case that a dynamic gas model cannot be implemented for the foreseeable future.
- Having the monetary policy begin at 5M provides a balance between delaying the implementation to provide enough time for code development and testing, and accelerating the implementation to provide an incentive to potential early adopters and high risk investors. Based on community discussion, beginning before block 4M is too soon for development, testing, and implementation of the policy, and later than block 6M is too long to interest many potential early adopters/investors.
- Not changing the monetary policy of ETC provides no benefit to risk taking early on in the life of the system, speculation wise. It will be difficult for the network to bootstrap its security. While bitcoin has what is considered to be the generally accepted ideal monetary policy, with its 50% reduction every four years, this model is not likely to yield optimal investment for ETC. If ETC were to adopt the bitcoin halving model, it is arguable that too much of the supply would be produced too soon: 50% of the estimated total ETC supply would be mined 75% sooner than traditional bitcoin because of the pre-mine of 72M ETC that was initially created in the genesis block. While the 5M model does not completely eliminate the effects of the premine, since 50% of total estimated production occurs sooner than would the bitcoin model, it makes up for this, to an extent, with its lengthening of the time until 90%, 99% and 100% of bitcoin are mined. The tail end of ETC production is longer and wider than bitcoin.
- In the current ETC reward schedule, the total reward for uncles is higher than the reward received by the miner who also includes uncles. In this state, a miner is significantly diluting the value of his reward by including these uncled blocks. By equalizing the rewards to uncle block miners with the rewards to miners who include an uncle block, the reward structure is more fairly distributed. In addition, equalizing the uncle rewards reduces the incentive for miners to set up an ETC “uncle farm,” and instead drives them to better secure the network by competing for the latest “real block.”
- Because the rate at which uncled blocks can vary with extreme, reducing the reward for uncle blocks assists considerably with being able to forecast the true upper bound of the total ETC that will ultimately exist in the system.
- The model is the best attempt at balancing the needs to incentivize high risk investment into the system in order to bootstrap security and create a potential user base, be easy to understand, include a reduction to the rate of production of ETC over time, include an upper bound on supply, provide for a long term production of the ETC token, and allow enough time for development, adoption, and awareness.

In a parallel universe near you…

“IT’S JUST NOT FAIR!” shouted Gully Bull into his microphone so loud his voice
thundered over the audience. Bull is the car delivery business owner and
activist who put together the Save Toll Equality March On Washington. Toll
equality is the principle that every vehicle should pay the same toll road fees.
Small cars pay an average of $5 at most toll roads. Big 18 wheelers pay
$30 or
more depending on their weight. Intertoll Service Providers (ISPs) that manage
the national toll road network (Intertoll) argue that heavier vehicles should
pay greater fees since they cause more road wear. Former President O. Bammer
required the Federal Cargo Commission (FCC) to begin a policy enforcing toll
equality: “This is the great moral issue of our time. Nothing less than the very
survival of the Intertoll is at stake.” Unfortunately for President Bammer, his
chosen successor lost in a stunning upset to now President Trunk. Gully Bull and
others were terrified that now ISPs would continue charging different vehicles
different toll fees.

Trunk’s new FCC could have weathered Gully Bull’s trouble making. However, there
were thousands of other like minded “Gully Bulls” all over the country.
Furthermore, all the major trucking companies had poured millions into the Save
Toll Equality campaign. Facetruck CEO Mark Tuckerberg donated $50
million.
YouTruck CEO Eric Smith donated another $40 million. Major media outlets
blared
constant headlines about the Save Toll Equality movement. Every American was
talking about it.

Just two hours before Gully Bull’s current speech, the massive campaign had
finally forced Trunk’s FCC to reverse its position. “Today I stand before you,
not as a small business man, but as an American. An American that wants an
Intertoll that is not just affordable for us, but, also for our childrens’
children.”

### 18 MONTHS LATER…

“IT’S JUST NOT FAIR!” screamed Gully Bull into his smartphone to the CEO of
Verizone, the largest ISP in the nation. Since toll equality, many ISPs went out
of business. Verizone survived thanks to a massive rate hike. It was easy since
much of their competition disappeared. Although everyone now paid the same, the
new $10 rate was double the previous $5 for small cars. Truckers
fared better as
$10 was one third of their previous $30.

“Mr. Bull, we believe in treating everyone fairly and strictly honor toll
equality on all our toll roads. We raised our rates on small cars to cover the
extra wear from heavier trucks. We also had to make up the lost revenue from the
new lower truck rate.”

“Yes but $10 is killing my car delivery business! And, you’re giving the
truckers a handout!”

“I’m sorry you feel that way. Please take up any further concerns with the FCC.
Good day.”

The next week, Gully Bull’s company went bankrupt and the country slid into a
recession. Facetruck and YouTruck reported record quarterly earnings.

On a completely unrelated note. Since I have your attention dear reader, allow
me to comment on something completely unrelated, net neutrality: DON’T BELIEVE
THE HYPE!

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

A talented developer referred to as Dexaran funded and formed the Ethereum
Commonwealth, the third Ethereum Classic (ETC) development team. Dexaran has
been accused of being the DAO attacker. Here are Dexaran’s answers to some
questions:

### Tell us a little about yourself.

I prefer to stay a pseudonymous person, thus, I can only tell [you] that I live
in Russia. I could say that my main direction is “information security and
cryptography”. I came into [the] crypto space seeking [the] opportunity to
protect myself from the influence of “uncontrollable centralized authorities”
(such as Russian government) and the opportunity to resist censorship since this
is [extremely] relevant in my country.

### Why do you support and believe in ETC?

I have two main reasons to be here, in [the] ETC community[:]

The first and the most important one is my ideology. Each blockchain project
consists of two core parts: a protocol and a history of transactions. Ethereum
is a good protocol but Ethereum’s history of transactions was violated by TheDAO
hardfork. Ethereum C[l]assic is exactly the same protocol but [with] a clean
history of transactions. I’m not against hardforks and I’m not against Ethereum.
I am against a violation of someone’s rights after they were given. TheDAO
hardfork was exactly the result of [the] “the influence of centralized
authorities” which I do not support. As the result, I’m in [the] C[l]assic camp.
I can not say that [the] Ethereum Foundation was wrong. I will say that we think
different[ly]. Let people who believe in [the] Ethereum Foundation join Ethereum
and people who believe in decentralization and censorship resistance join
C[l]assic.

The second reason is that I had some ideas of how to improve Ethereum. I thought
that it [would] be easier to realize [these] ideas for ETC, but now I see that I
was wrong. I was told[,] “Go propose [a] new token standard on Ethereum and if
they decide that it is a good idea then we will follow” when I came with a
proposal to fix a bug in [the] ERC20 token standard[,] which [has] caused
millions of dollars [of] loss already. [The] ETC community is smaller[,] but it
is much more conservative[,] and it is harder to achieve an agreement about new
features compared to Ethereum.

### Why do you wish to remain anonymous?

Some might consider my views radical enough. I’d like to remain anonymous for
now, but I think that someday I will deanonymize myself.

### Why did you feel it was necessary to create a new ETC development team?

There was a slight discrepancy between my vision of what should be done and what
the existing teams were offering.

The main one is financial transparency. I believe that it is one of the most
important issues for any organization especially in [the] crypto space. We are
the only Ethereum C[l]assic development team that [adheres] to a policy of
[complete] financial transparency.

There was a proposal to establish a treasury for Ethereum Classic. It could
solve [the] problems of financial transparency and [the] lack of [a] governance
system. Unfortunately, it was rejected.

The second reason to create a separate team was that none of the existing teams
[were] working on solving already-existing problems. Both [of] our teams are
working on moving forwards but no one tends to learn from Ethereum’s mistakes
and solve any of the already-existing problems or prevent the emergence of
Ethereum’s problems. Someone had to solve [the] existing problems, for example
[the] loss of money due to [the] token standard flaw or [the] lack of [a]
browser extension for accessing Ethereum (C[l]assic) enabled distributed
applications. There was MetaMask for Ethereum, but there was no analog that
supports the [Classic] chain. MetaMask is a key point for most [dapps] that
require user interaction with them. For example[,] you [cannot] create a fully
decentralized exchange and let someone use it without MetaMask. That’s why I
decided to work in this direction. There are still many problems that have to be
solved yet.

### What are your main goals for the ETC Commonwealth?

The main goal is to develop solutions [for] those problems of the ETC network
that no one is willing to solve.

Currently, the most important problems of ETC are:
1. Lack of [a] governance system.
1. Lack of [an] address-to-address messaging system.
1. Scalability problems.
1. Lack of [an] address checksum that can prevent transaction[s] to a
non-exist[ent] address.
1. ETC testnets and testnet explorer.
1. There is no alternative to [the] Gastracker block explorer.

Address-to-address messaging seems to be the most relevant for me because no one
else is working in this direction. It is a great problem of the whole Ethereum
ecosystem. I’m planning to create a global smart-contract based messaging
service which will allow you to contact [the] owner of any address directly.
This will liquidate [the] problem of “I sent my ETC to some ETH address and I
don’t know who owns it and how to contact him”.

### What is the size of the team currently?

There are four developers in [the] Ethereum Commonwealth currently. Me and Yohan
Graterol are public. The other two are private. Their [G]ithub profiles are
available [in the] Ethereum Commonwealth financial report and their
contributions are available [in the] Ethereum Commonwealth projects commit
history. I don’t know their real names.

### Can you describe your management style and how the system works?

It is difficult to manage a large team of developers. As a result, I decided
that we will work as a small group, [each] working on a separate task. I’m
coordinating everything through our separate Ethereum Commonwealth [G]ithub
organization. We communicate through Discord or e-mails. Each task requiremen[t
is] described at the corresponding issue [in the] Ethereum Commonwealth Roadmap
repository. It serves as [an analog] of [the] ECIPs repository for [the]
Ethereum Commonwealth.

Unfortunately, I have not raised enough funding to hire a professional manager
to form a separate group to work on more tasks simultaneously.

Ethereum Commonwealth is now open for contributions. Ideally, I see it as a
“local treasury” where everyone can define a task and anyone else can propose a
solution and receive payment from [the] ETC [Commonwealth] fund if the solution
[is] accepted.

We have a decision making process based on token voting. This utilizes
blockchain advantages to resolve conflicts of [interest] transparently.

### Some have suspected that you are the DAO attacker. Would you mind addressing
these accusations?

I can only say that I never hacked TheDAO. If I were [T]heDAO hacker then why do I
need an ICO to fund my own team?

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

To the beginner, some necessary information may appear to be missing from the
Ethereum Classic (ETC) blockchain. This information is implicitly contained in
the blockchain which may lead to confusion.

### Examples

Account Balances - Regarding accounts, the blockchain specifies transfers
but not balances. They can nevertheless be determined by accounting for all the
transfers in all the blocks.

Smart Contract Storage - Regarding smart contracts, the blockchain specifies
machine codes and input data but not storage values. They can nevertheless be
determined by executing all the invocations on all the input data in all the
blocks.

Transaction Sending Accounts - With respect to sending accounts,
transactions contain digital signatures but not addresses. They can nevertheless
be determined from the digital signatures and transactions using the
mathematical properties of the signature algorithm.

Transaction Gas Requirements - The blockchain specifies the gas requirements
for certain sets of transactions. It does not specify the requirements for
every transaction separately. They can nevertheless be determined from the given
transaction set gas requirements.

Average Mining Hash Rates - The blockchain specifies mining block creation
times and mining difficulty parameters. It does not specify mining hash rates.
However, the mining hash algorithm and mining difficulty parameter are defined
such that:

<H> ≅ <D> / <ΔT>

where <H> is the average mining hash rate, <D> is the average mining difficulty parameter, and,
<ΔT> is the average creation time difference between consecutive
blocks. The averages can be taken over any desired number of blocks.

### Conclusion

The ETC blockchain brilliantly encodes information in a practical manner. It
supports the ETC world computer without being unwieldy. Although it may at first
appear incomplete, it still includes all the essentials.

### Feedback

You can contact me by clicking any of these icons:

### Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

### License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

The Ethereum Classic (ETC) mining difficulty parameter may seem mysterious to
some. I will show it has a beautiful easy to understand interpretation.

### Background

Some ETC network computers receive rewards for creating, distributing and
validating the blocks of the ETC blockchain. This work is referred to as
mining and the computers as miners. To create valid blocks, miners keep
adjusting random numbers in those blocks until corresponding 256 bit hashes meet
a certain requirement. The random numbers are referred to as nonces. The hash
requirements involve a number referred to as the difficulty. For a hash value
H and difficulty d, this is the requirement:

H ≤ 2²⁵⁶ / d

### Interpretation

The probability of an arbitrary hash meeting the requirement is equal to the
number of acceptable hashes divided by the number of possible hashes. In other
words, for a difficulty d, this probability is equal to the following:

(2²⁵⁶ / d) / 2²⁵⁶ = 1 / d

I will now show that d equals the average required number of hashes to find an
acceptable nonce. I will do this first using software and second using calculus:

Software Based Derivation - The following Python program finds the average
required counts of random numbers, between zero and one, to obtain values less
than 1 / d for various values of d:

Here is the output:

The errors can always be made smaller by averaging over a larger quantity of
numbers. Clearly the average count is the difficulty.

Calculus Based Derivation - The probablity of a hash count of one is 1 /
d. The probability of a hash count of two is (1 / d)(1 - 1 / d). The
probability of a hash count of three is (1 / d)(1 - 1 / d)², etc. The
average hash count is the sum of the products of these probabilities and their
corresponding hash counts:

(1 / d)(1) + (1 / d)(1 - 1 / d)(2) + (1 / d)(1 - 1 / d)² (3) + …

Let A(x) be a function based on this expression such that the average hash
count is A(1):

A(x) = (1 / d) + (2 / d)(1 - 1 / d)x + (3 / d)(1 - 1 / d)² x² + …

Here is the antiderivative of A(x):

(1 / d)x + (1 / d)(1 - 1 / d)x² + (1 / d)(1 - 1 / d)² x³ + …

This is equal the following geometric series divided by d - 1:

(1 - 1 / d) x + (1 - 1 / d)² x² +(1 - 1 / d)³ x³ + (1 - 1 / d)⁴
x⁴ + …

Using the formula for an infinite geometric series, this can be shown to equal:

d / (d + x - dx) - 1

Since A(x) is equal to the derivative of its antiderivative, A(x) is equal
to the derivative of the above expression divided by d - 1:

A(x) = d / (d + x - dx)²

Clearly the average hash count A(1) = d.

### Conclusion

The mining difficulty can be understood as the average number of hashes required
to find a valid nonce. If it was mysterious before, hopefully now it is less so.

### Feedback

You can contact me by clicking any of these icons:

### Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

### License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0

International License.

Multisig smart contracts will likely be the dominant smart contract type in the
future. The security and other benefits are that compelling. I will describe
these smart contract types and scenarios where they are useful.

### Introduction

Malware, keyboard loggers and “man in the middle attacks” are just some of the
ways passwords can be stolen. Therefore, many use multifactor authentication to
increase security. For example, accessing a website from a laptop may require a
password and approval from a smartphone.

Ethereum Classic (ETC) and other smart contract systems can also benefit from
multifactor authentication. ETC users are associated with accounts. ETC account
authentication involves digital signatures. Therefore, ETC smart contracts
requiring multifactor authentication are referred to as multisig smart
contracts.

### 2 Of 3 Applications

One of the most common types of multisig smart contracts requires digital
signatures from any two of three accounts. Here are some applications where this
is useful:

Single Individuals - Imagine always requiring a digital signature from a
laptop based account and a smartphone based account. To protect against the loss
of either device, store the information for the third account in a secured paper
wallet.

Online Shopping (Trusted Escrow) - When purchasing products and services
online, imagine buyers placing funds in multisig smart contracts. Have buyers
and sellers each control an associated account. Allow an arbiter to control the
third associated account. Notice buyers and sellers can together release funds
without the arbiter. In the event of disagreements notice the arbiters can,
together with buyers or sellers, release funds to the desired choices. This is
referred to as trusted escrow because the arbiter does not control of any
funds.

Small Businesses - Imagine a small business controlling one associated
account, and, a separate inspection service company controlling the second
associated account. All transactions must be approved by the inspection service.
To protect against issues with either account, store the information for the
third associated account in a secured paper wallet.

### Additional Applications

Here are two more multisig smart contract types and applications:

Majority Rule - Imagine all members of a group controlling separate
associated accounts. Always require digital signatures from any majority of
the accounts. This would implement a majority rule arrangement.

Unanimity Rule - Imagine all members of a group controlling separate
associated accounts. Always require digital signatures from all of the
accounts. This would implement a unanimity rule arrangement.

### Standardization

There are currently no ETC multisig smart contract standards. However, open
source templates are available such as from the
OpenZeppelin project.

### Conclusion

There are several common scenarios where multisig smart contracts are useful and
significantly increase security. Therefore, it is likely they will take over ETC
and the world.

### Feedback

You can contact me by clicking any of these icons:

### Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

### License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0

International License.

Ethereum Classic (ETC) mining rewards changed with the new monetary policy. I
will discuss these changes and their effects.

### New Formula

ETC miners are rewarded for adding valid blocks to the ETC blockchain. These
rewards consists of three parts:

Base Rewards - This part depends on the block numbers. It is paid with newly
created funds. Every five million blocks (about 2.5 years) this part decreases
by 20%. Initially it was 5 ETC. It changed to 4 ETC after block number five
million. It will change again to 3.2 ETC after block number ten million around
April 2020.

Define the block era E as a function of the block number N as follows (//
denotes integer division):

E = (N - 1) // 5000000

Then the base reward is as follows:

5 ⋅ 0.8ᴱ

Uncle Rewards - This part depends on the number of uncle blocks included as
well as the block numbers. It is also paid with newly created funds. Each block
can include at most two uncle blocks. The reward for each uncle block is an
additional 3.125% of the base reward. It is now 0.125 ETC per uncle block and
will change to 0.1 ETC after block number ten million.

For the block era E and number of uncles U, the total uncle reward is as
follows:

0.03125 ⋅ U ⋅ (5 ⋅ 0.8ᴱ )

After block number five million, miners that create the uncle blocks also get
this same reward per uncle block.

Gas Rewards - This part depends on the transactions included. It is paid
from the originating accounts. Miners execute the transactions and receive
payments for the gas required. Each transactions specifies a price paid per unit
gas.

For gas requirements G₁, G₂, G₃, … and gas prices P₁, P₂, P₃, …, the
total gas reward is as follows:

G₁ ⋅ P₁ + G₂ ⋅ P₂ + G₃ ⋅ P₃ + …

Therefore, the total reward for creating a block is the following:

(1 + 0.03125 ⋅ U ) ⋅ (5 ⋅ 0.8ᴱ ) + G₁ ⋅ P₁ + G₂ ⋅ P₂ + G₃ ⋅
P₃ + …

### Example Calculations

Here is a Python script that uses this mining reward formula to calculate mining
rewards:

Here are some example calculations on real ETC blockchain data:

### Total Supply

The new monetary policy bounds the supply of ETC. Notice only the base and uncle
rewards increase the supply since the gas rewards just transfer existing funds.
Because the uncle rewards vary, the eventual total supply of ETC can only be
approximated.

The formula for the future increase in supply per era, assuming a constant
number of uncle blocks, is the following:

5000000 ⋅ (1 + 2 ⋅ 0.03125 ⋅ U ) ⋅ (5 ⋅ 0.8ᴱ )

The factor of 2 is necessary to include the uncle block creator rewards. The
total supply can be estimated from this formula by adding the contributions for
the remaining eras. Era 192, which will occur in about 456 years, is the last
era which increases the supply.

Assuming no more uncle blocks gives a lower bound of about 198.3 million ETC.
Assuming the maximum number of uncle blocks gives an upper bound of about 210.6
million ETC.

### Conclusion

The new monetary policy modifies mining rewards and limits the total supply of
ETC. Hopefully all the details are now more clear.

### Feedback

You can contact me by clicking any of these icons:

### Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

### License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

Read this article on Medium (looks nicer)

Lately there’s been a lot of speculation about ETC, the price is rising, the
Callisto airdrop is happening, and Crypto Twitter is tweeting up a storm about
ETC. Some are certainly trading for short term profits, and it’s their right to,
but they’re not seeing the forest for the trees. Even worse, some have dubbed
ETC a shitcoin, as if we’ve existed this long to just be another pump and dump.
We haven’t, we aren’t, and we won’t be if I have anything to say about it.

This article sets out to give some insight into the advancements ETC has made
and the bright roadmap it has for its future.

The future of ETC is the future of all Cryptocurrencies, and that future is
interoperability, there will be no one winner. ETC will become highly
interoperable while others naively fight to be dominant.
At the core of our sidechains is SputnikVMwhich can run smart contracts
anywhere... You can do this today. Not at some nebulous time in the future.

#### Sidechains

We’re going to have sidechains this year, transactions on them will be free, and
even very low powered devices will be able to use them. We’ll be the first
blockchain to properly address the needs of IoT devices. While others claim to,
and start announcing partnerships before anything even works, we’ll be the first
to really get it done.

At the core of our sidechains is SputnikVM which can run smart contracts
anywhere, such as in the
browser or you can put it in
embedded devices. You can do this
today. Not at some nebulous time in the future.

Our sidechains will be highly flexible. They’ll allow whoever created them to
choose between PoA or PoS approaches. They can be public, private or otherwise
permissioned depending on your needs.

#### Ease of use

Every blockchain still needs to improve their usability but we’ve made great
strides. We’ve got beautiful, well-working wallets (Emerald Wallet, CEW). A
simple DNS-like system (via CEW). Mobile wallets exist and more are coming.
We’re supported everywhere, we’re on every major exchange, we’re very popular
internationally, we’re even making our way into Cardano’s wallet.
Sent myself some ETC and it showed up in Emerald Wallet in about 20 seconds.

#### Easier development

Currently developing for blockchain tech is fairly low-level, while we have
languages like Solidity which very much look like JavaScript, they function like
a low-level language. This leads to a lot of difficulty in development and a lot
of bugs cropping up.

Emerald Project will provide a common high-level framework to ease development
on Ethereum Classic. Imagine libraries where integrating with hardware wallets
is as easy as ledger.connect(), or interacting with tokens is as simple as
Token t = new Token(0xbeef..); t.transfer(0xfa34..). This is just pseudocode
but that’s where we are heading. No messing with RPC or hunting down ABIs
necessary.

Emerald Project doesn’t end at just the code though, it also extends to the UI.
Check out Emerald Wallet, look how great it looks, your apps will be able to
seamlessly drop in the same elements. On the user end the consistent UI will
create a familiar and cohesive feel across ETC projects.

Improved developer documentation is also coming and will be announced in the
coming months.

#### Emerald Wallet

Installing Emerald Wallet took me literally 1 minute to install and immediately
start using ETC.

I’ve also just installed Mist for Ethereum and it looks like I’ll be waiting a
while. I clicked on “Launch Application” several times and nothing is happening.
I seem to just be stuck on block 10,240 now.

While in Emerald Wallet I sentmyself some
ETC
and it showed up in Emerald Wallet in about 20 seconds.

Mist on the other hand appears to have crashed. I restarted it.

Back to waiting.

In fairness it did eventually sync. And before you get mad that this is a dig at
Mist developers, it’s really not, developing a good wallet is hard work, it is
not easy, errors happen, and I’m sure they’ll fix these above issues.

This is simply to illustrate that ETC does have a good wallet which is able to
go from install to using the ETC network in about a minute. Those who claim ETC
can’t accomplish a “simple” task like a wallet are misinformed at best and
willfully ignoring the issues within their own communities.

#### Open community

The Subreddits, Forums, Discord, and Telegrams all have separate owners.
Discussion is very open and you’re not required to agree with the crowd.

We’re very anti-pump and dump, want to know why ETC’s price doesn’t rise
endlessly like other coins? Because when you join our forums you may very well
find that many in the community won’t promise you the moon, and we’re aware of
our flaws and working hard to fix them. We think this will make ETC much more
widely used in the long term, at the cost of short term lambo-moon pipe dreams.

We’re also not going to police you and tell you what to believe in or what not
to. And we’re not going to put our names/faces on every project that comes
along. We have principles and we will stick to them.

Follow me on Twitter

Follow me on Medium

Coder, Project Manager, Blockchain enthusiast

Read this article on Medium (looks nicer)

Wanted to give everyone a quick rundown of what ETC has been up to this week.
There’s been a flurry of news about the Callisto airdrop and some news may have
gotten missed in the shuffle.

So what happened in ETC last week?

#### New people

ETCDEV took on a new hire, Richard
Schumann, who is working on improving the
graphics and usability of ETCDEV projects for end users.

Here’s a little preview of the ETCDEV projects he’ll be working on.

We’ve also upped our moderation team. Mario Michel is now a mod on the main
Telegram and the Forums, some community members decided to start and mod a
second Telegram, and there’s an ETC Italia
Telegram! Molto bene!

#### ETC Cooperative is Expanding

They’ve added a Board of Advisors with
some very well known people in Cryptocurrencies, in alphabetical order: Igor
Artamanov, Charles Hoskinson, Elaine Ou, Barry Silbert, James Wo.

They’re also hiring additional personnel, creating a system to fund
community-driven projects, revamping the ETC website, and have a few surprise
announcements coming.

The full announcement can be seen
here.

#### Community Fund

In the coming weeks we’ll announce a community fund with $500k+ to put towards
projects. These are funds that have been donated by the community and are going
to be put to good use improving the ETC ecosystem.

If you’d like to get started before launch, you can out the Ecosystem Proposal
section on the forums.
A bigger announcement will be coming with the official launch.

#### Centra Card adds ETC

ETC is now spendable with a Centra Card debit card.

Read this article on Medium (looks nicer)

## Circle Invest will carry ETC

Goldman Sach’s answer to Coinbase will allow for the trading of ETC/USD as
first reported by
CCN
(not CNN).

A USD onramp will be huge for ETC, it’s already a preferred method of moving
funds. Many traders I’ve spoken to like ETC because of its speed and low
transaction fee (half-cent to 1-cent transactions).

With ETC sidechains coming out later this year I think we’ll see ETC keep up
with the increased usage Circle Pay will bring.

Seems Circle chose ETC over XRP.

#### Website Redesign

Very long overdue improvements are coming to
ethereumclassic.org, we’ll be bringing the site
up to modern standards and making it far more informative for new users and
developers alike.

I could write an entire article about it but want to keep this short so if you
want to learn more about the redesign and provide some input then please
respond to the forum
post.

We’ll have mockups in a couple of weeks for a more visual preview so stay tuned
for further announcements.

#### Community Fund

The contract is live and located here, just awaiting two of
the signers to approve their test transactions.

We’ll be using it to fund various bounties and other proposals which will be
posted in the Ecosystem Proposals
category on the
forums.

If you want to submit a proposal feel free to make a new post, just remember to
follow the
template
if you’re submitting a funding request.

#### Disabling the Difficulty Bomb

We’ll be turning off the difficulty bomb at block 5,900,000; expected to occur
around May 8th. ETCDEV has contributed the code
for this fork and no, there are no new coins, this is a network improvement, not
a cash grab, please stop asking.

This bomb was originally put in place by the Ethereum Foundation in order to
push the network towards PoS. However it has become apparent that PoS is both
far more complicated and risky than originally thought. So rather than further
delay the difficulty bomb we’re simply going to remove it and stay PoW since it
works.

There’s also a mailing list for hard forks and security alerts now, it’s run by
The ETC Cooperative, if you’re an exchange, miner,
node operator, wallet creator, or just plain interested then signup to it here:
http://eepurl.com/dmc_AX

Ethereum Classic (ETC) digital signatures secure transactions. These involve elliptic curve cryptography and the Elliptic Curve Digital Signature Algorithm (ECDSA). I will describe ETC digital signatures without these topics using only small Python functions.

### Basics

Signing and verifying will be implemented using the following four constants and three functions:

The invert function defines an operation on numbers in terms of other numbers referred to as moduli. The add function defines an operation on pairs of numbers. The multiply function defines an operation on a number and a pair of numbers. Here are examples of their usage:

### Private & Public Keys

Private keys are any nonzero numbers less than the constant N. Public keys are the products of these private keys and the pair (Gx, Gy ). For example:

Notice that public keys are pairs of numbers.

### Signing

Signing transactions involves an operation on the Keccak 256 hashes of the transactions and private keys. The following function implements this operation:

For example:

Notice that digital signatures are pairs of numbers. Notice also that the sign function can give different results for the same inputs!

### Verifying

Verifying digital signatures involves confirming certain properties with regards to the Keccak 256 hashes and public keys. The following function implements these checks:

For example:

To verify that public keys correspond to specific ETC account addresses, confirm that the rightmost 20 bytes of the public key Keccak 256 hashes equal those addresses.

### Recovery Identifiers

Strictly speaking, ETC digital signatures include additional small numbers referred to as recovery identifiers. These allow public keys to be determined solely from the signed transactions.

### Conclusion

I have explained ETC digital signatures using code rather than mathematics. Hopefully seeing how signing and verifying can be implemented with these tiny functions has been useful.

### Feedback

You can contact me by clicking any of these icons:

### Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

### License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

Read this article on Medium (looks nicer)

 via
Reddit

#### SputnikVM to Manage Satellite Data

The news is very new, so we’re waiting for more information but the reality for
satellite data right now is that it’s very segmented, each station has its own
data and they don’t really talk to each other. SAT-1 aims to use SputnikVM to
solve
that.
They have a lot planned so check out their roadmap.

ETCDEV’s goal of bringing IoT to the ETC blockchain is quickly becoming a
reality and they all deserve our thanks. So go ahead and tweet them something
nice.

#### ETC Cooperative’s New Members

Myself and Christian
Xu are joining the ETC Cooperative. We’re going to
be working to gain ETC the larger exposure and recognition that it deserves.
We’ll be improving our resources, messaging, and international community
support.

ETC’s Resources: such as the
website,
documentation, and all the odds-and-ends that have gone a bit neglected.

ETC’s Message: Like everyone else we’re tired of hearing “ETC is just about
The DAO”, “ETC is just about immutability”. We want everyone to see how great it
is to use, and the potential we have for IoT.

Our Asian Communities: Christian will be focusing on China, South Korea,
Japan, and Taiwan. He’ll be running meetups and starting some more chat channels
(WeChat, Telegram, etc.).

Oh, and we’ll also be hosting ETC’s 2018 Summit! More information to come on
this one.

#### Forums Reached 1,000 Users

In just 3 short months since launch we’ve now reached 1,000 users on the ETC
forums and we’re growing every day.
Congratulations Yaz Khoury, and excellent work
running the forums!

If you haven’t joined yet you’ll be able to find guides on common ETC
uses, ecosystem
improvement proposals,
and ask a question in the help me
section. Plus all the usual
suspects of news, introductions, mining, and tech talk. So come join the party!

#### ETC on the Stock Market

Later this year the Ethereum Classic Investment Trust will be publicly tradeable
on OTCQX market. This means that soon you will be able to invest in ETC through
your 401k, IRA, and regular brokerage accounts. Michael
Sonnenshein spilled the news on CNBC’s Fast
Money (skip to 2:20).

#### More Fiat Pairs

Both Abra and
BitIt have added the
ability to purchase ETC using USD, EUR, KRW, CNY, JPY, and many others.

Ethereum Classic (ETC) uses Recursive Length Prefix (RLP) encoding to store and send data structures. I will describe RLP and how it is used in ETC.

## Introduction

Serialization is the process of encoding data structures into byte sequences. It is also referred to as marshalling and pickling. Serialization is necessary when storing and sending data structures.

RLP is a serialization format created by Ethereum developers for all data structures such as accounts, transactions and blocks. RLP is simpler than the alternatives such as Extensible Markup Language (XML), JavaScript Object Notation (JSON), Binary JSON (BSON), Protocol Buffers and Bencode.

RLP is also consistent. Identical objects are always converted to identical byte sequences. This is not true of all serialization formats. For example, when encoding sets of key value pairs, some schemes do not specify an ordering for the keys.

## Details

RLP operates on byte sequences and lists. Lists can contain byte sequences and other lists. The interpretation of all inputs is handled by other protocols. For byte sequences, small headers are added which depend on the length. For lists, the elements are encoded separately and concatenated. As with byte sequences, small headers are added which depend on the length. Lastly, all lengths are encoded in big endian format.

## Code

Here are Python functions which implement RLP encoding and decoding:

Notice that the functions are recursive. Notice also that the functions work for inputs requiring up to about 18 million terabytes. Here are examples of their usage:

## Conclusion

RLP is an elegant and approachable serialization format used extensively by ETC. It can be quickly mastered thereby illuminating this important aspect of the system.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

I will describe tries and explain why they are so important.

## Introduction

Tries are used extensively in blockchain systems and elsewhere. They are tree
structures that represent sets of key value pairs in software. It is possible to
instead just represent key value pairs contiguously. However, then it would be
more difficult to make changes and perform searches than with tries. Tries are
composed of connected nodes that store values. Different nodes imply different
keys based on their positions. A common application that uses tries is
internet routing.

## Examples

In the trie diagram above, the dots represent nodes and line segments represent
connections. Note that each dot has a left and right line segment below it. The
key corresponding to each node is found as follows:
1. Find the path from the top node to the node.
1. For each left line segment along the path, add a "0" to the key.
1. For each right line segment along the path, add a "1" to the key.

Therefore, the yellow dot corresponds to the key "010". The blue dot corresponds
to the key "11". A similar procedure is used for all tries to determine keys.

The diagram above represents a trie where each node connects to 16 nodes below
it. Note that each line segment will add one of 16 possible values (nibbles) to
the keys. Therefore, the yellow dot corresponds to the key with the hexadecimal
representation "0x0f2". The previous trie diagram represented 15 nodes. This one
represents 4369 nodes!

## Compression

When representing sets of key value pairs with tries, there is often thousands
of unused nodes. Compression techniques are often used to more efficiently store
tries with lots of unused nodes.

## Nomenclature

The terms radix trees and Patricia trees also refer to tries. Sometimes, but not
always, these terms imply "compressed" tries that more efficiently manage unused
nodes.

## Conclusion

Tries are tree structures that store key value pairs in a format that
facilitates changes and searches. They are used extensively in many
applications. Hopefully now you have gained the fundamentals to be able to take
a deeper dive into these concepts.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0
International License.

The Ethereum Classic (ETC) blockchain does not contain all the necessary state
information for the ETC system to operate. It does not even implicitly contain
all that is needed! I will elaborate and discuss how this is handled.

## State

The state of the ETC system includes all the balances, programs, nonces and
other values in memory. This data is organized into accounts. Therefore, the
state is the set of all account values.

Blocks contain transactions which specify changes to states. If the state is
known for any time, the state can be determined for all future times by
analyzing the transactions in the following blocks. However, the blockchain does
not completely specify the state for any time! Admittedly, all blocks
contain state hashes. But, these hashes are irreversible!

The initial state for the first block contains accounts with nonzero balances.
In other words, all funds did not originate from mining. Do you wonder how
miners know the account balances when processing account transfers involving
these initially funded accounts? The answer involves the ETC node databases.

## Database

ETC nodes typically contain databases that store the blockchain as well as
additional information. For example, Linux Parity ETC node databases typically
use the following directory:

Linux Geth ETC node databases typically use this directory:

For performance reasons, Parity and Geth use nonrelational (NoSQL) key value
databases. These databases can be accessed directly. They can also be accessed
using the Web 3 library.

## Solution

All ETC nodes must contain a complete specification of the initial state for the
first block. This is required in addition to the blockchain. For example, on
Geth ETC nodes, this initial state is in the database and can be viewed with the
following command:

## Conclusion

ETC nodes require a complete specification of the initial state for the first
block as well as the blockchain. ETC nodes typically store this information in
databases. Only with both of these pieces of information can the ETC system
operate.

## Feedback

You can contact me by clicking any of these icons:

## Acknowledgements

I would like to thank IOHK (Input Output Hong Kong) for funding this effort.

## License

This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.

# ECIP 1041 - Remove Difficulty Bomb

https://ecips.ethereumclassic.org/ECIPs/ecip-1041

## Abstract

This ECIP proposes removing Difficulty Bomb from Ethereum Classic Mainnet at block 5,900,000

## Motivation

As Ethereum Classic Mainnet is not planned to migrate to PoS in near future there is no reason to have it and the Difficulty Bomb should be removed to avoid collapse of the network.

## Specification

Difficulty Bomb is an artificial increase of mining difficulty of Ethereum blockchain which was introduced to Ethereum protocol as a motivation for developers to migrate to Proof of Stake consensus algorithm. It was introduced in Ethereum Homestead by EIP-2.

With that additional element, Minimum Mining Difficulty grows exponentially every 100,000 blocks by factor of 2. It was paused by ECIP-1010 from block 3,000,000 to block 5,000,000. With continued growth at the block 6,500,000, which is scheduled for September 2018, the mining of ETC chain will become unprofitable. There is a small chance that miners will quit mining ETC because of mining difficulty growth before that block.

Removing that part of the formula is a trivial change, but because it’s a part of consensus rules it produces a Hardfork. To make it successful it requires modifications to all of existing ETC peer implementations and providing time to upgrade for miners, exchanges and other critical parts of ETC ecosystem.

It seems reasonable to allocate up to 6 weeks to update and release all critical software and up to 6 weeks to upgrade for miners and exchanges. Which gives up to 3 months for enabling this proposal. With that requirements the earliest safe block to enable new hardfork would be 5,700,000 which is expected at April 2018

Growing Difficulty Bomb above 20% of standard difficulty is dangerous, also for additional security we should consider scenario when half of the current miners left the network. With current difficulty at about 7,000 Gh/s it shouldn’t grow above 700 Gh. Under that requirements the latest safe block to enable new hardfork would be 6,100,000 with 550Gh of extra difficulty, which fits our requirements. Block 6,100,000 is expected at June 2018.

Hardfork boundaries:
- Earliest block is 5,700,000 at April 2018
- Latest block is 6,100,000 at June 2018

It’s proposed here to use block 5,900,000 which is in the middle between these boundaries.

Block 5,900,000 expected at May 2018 and will require 137Gh of additional difficulty. It’s an optimal block under current circumstances.

## Implementation

For most of peer implementations it’s a trivial modification and can be done through configuration without changing actual code.

## References
- ECIP-1010 Delay Difficulty Bomb Explosion
- EIP-2 Homestead Hard-fork Changes

https://ecips.ethereumclassic.org/ECIPs/ecip-1054

## ETC Core Devs Call - Atlantis Finalization
- When: Thursday, May 30, 2019, 3pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #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

### 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

https://github.com/ethereumclassic/ECIPs/issues/78

https://ecips.ethereumclassic.org/ECIPs/ecip-1054

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

## Intermediate Atlantis Upgrade Scheduling Call
- 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
- [B] ETCLabs "July 1st" schedule
- [C] Moderately accelerated schedule

### Please comment to add items to the agenda

https://github.com/ethereumclassic/ECIPs/issues/80

https://ecips.ethereumclassic.org/ECIPs/ecip-1054

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

### Please comment to add items to the agenda

https://github.com/ethereumclassic/ECIPs/issues/79

https://ecips.ethereumclassic.org/ECIPs/ecip-1054

## 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

### Please comment to add items to the agenda

https://github.com/ethereumclassic/ECIPs/issues/83

# ECIP 1054: Atlantis EVM and Protocol Upgrades

https://ecips.ethereumclassic.org/ECIPs/ecip-1054

## Simple Summary

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.

## Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Spurious Dragon and Byzantium hardforks. The proposed changes for Ethereum Classic’s Atlantis upgrade include:
- Spurious Dragon state-trie clearing.
- Spurious Dragon contract-code size limit.
- Byzantium EVM opcodes, namely REVERT, RETURNDATASIZE, RETURNDATACOPY, and STATICCALL.
- Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve altbn128, optimal ate pairing check on the elliptic curve altbn128, and BIGINT modular exponentiation.
- Replacing the intermediate state root field in transaction receipts with the contract return status.
- Change difficulty adjustment to target mean block time including uncle.

This document proposes the following blocks at which to implement these changes in the Classic networks:
- 100 on Kensington Classic PoW-testnet (early June 2019)
- 716617 on Kotti Classic PoA-testnet (mid June 2019)
- 4729274 on Morden Classic PoW-testnet (early July 2019)
- 8772000 on Ethereum Classic PoW-mainnet (mid September 2019)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

## Motivation

To enhance the Ethereum Virtual Machine’s (EVM) capabilities, various opcodes and precompiled contracts shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. Adoption of the receipt status feature provides a helpful method for decentralized-application developers to access the successful or failed state of a contract. This would establish a higher level of interoperability between Foundation and Classic EVMs, and make a more extensive array of tooling available for the ETC network (e.g., Solidity version, contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate.

## Specification

Technical specifications for each EIP can be found at those documents respectively:
- EIP 100 (Change difficulty adjustment to target mean block time including uncles)
- EIP 140 (REVERT instruction in the Ethereum Virtual Machine)
- EIP 161 (State-trie clearing)
- EIP 170 (Contract-code size limit)
- EIP 196 (Precompiled contracts for addition and scalar multiplication on the elliptic curve altbn128)
- EIP 197 (Precompiled contracts for optimal ate pairing check on the elliptic curve altbn128)
- EIP 198 (Precompiled contract for BIGINT modular exponentiation)
- EIP 211 (New opcodes RETURNDATASIZE and RETURNDATACOPY)
- EIP 214 (New opcode STATICCALL)
- EIP 658 (Embedding transaction status code in receipts)

In case any of the before mentioned proposals define a variable similar to the pattern FORKBLKNUM named after Spurious Dragon or Byzantium*, it shall be replaced by a ATLANTISFORK_BLKNUM.

## Rationale

Atomicity: This protocol specification notably omits the scheduled features of the anticipated Constantinople protocol upgrade, which would be expected to include various further EVM upgrades. This allows for dedicated testing of the proposed changes in light of multiple delays of the Constantinople fork (a postmortem of the latest delay).

Interoperability: establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes and precompiled contracts to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

## Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Spurious Dragon and Byzantium features currently:
- Geth Classic: partial support for EIP-658 receipt status code change
- Parity Ethereum: all features due to Ethereum Foundation compatibility
- Multi Geth: all features due to Ethereum Foundation compatibility
- Mantis: all features due to Ethereum Foundation compatibility

### Copyright

Copyright and related rights waived via CC0.

# ETC Summit 2019

https://etcsummit.com/

## Join the Ethereum Classic Summit

We’ll have a diverse range of topics spanning development, IoT, cross-chain interoperability, market dynamics, smart contracts, social issues surrounding blockchains, and much more.

The Summit will be held at the Vancouver Convention Centre right in the heart of downtown Vancouver.

## Why Attend

We are a community, and platform that takes cryptocurrency further; allowing for limitless smart contracts that operate autonomously and resist censorship.

Come join our yearly summit to learn about and connect with all things ETC.

https://etcsummit.com/

# Mordor Testnet Launch

https://youtu.be/sURnZEeIqBU

## State of the Ethereum Classic Testnets Summary

There are a massive number of Ethereum Classic testnets.
- --morden
- --kotti
- --astor
- --kensington
- --nazgul

## Remove ETC Testnet Redundancies

Mordor Testnet Launch Video

### --mordor
- 2019 Genesis
- Ethash Proof-of-Work
- Replaces Morden, Kensington, Nazgul
- Supported by all clients
- No Premine, No Presale, Fair launch!

## Introduction

In the years since the DAO fork and the unexpected
birth of Ethereum Classic, strong social
consensus has emerged in support of ETC remaining
POW mined into the indefinite future.

In order for Ethereum Classic to remain
self-sovereign, merge-mining ETC would not be
acceptable either.

There is very little appetite for proposals of
POS at the ETC base protocol layer, though POS
sidechains or L2 solutions on top of POW are
generally well received within the ETC ecosystem.

This consensus was evident at the recent ETC Summit
2019 conference in Vancouver, Canada, and this
proposal seems to make that consensus explicit.

## Proposal

There is a broad perception that ETC has an implicit
social contract in favor of POW mining. This ECIP
seeks to transform that implicit assumption into
an explicitly written social contract, as an
ECBP which is adopted using the ECIP process.

This adoption could occur as part of the next
hard-fork (just to "batch" discussions), or it could
happen independently of that timeline. This
proposal is a formalization of an aspect of the
ETC social layer, not a technical protocol consensus
concern. Because of that, it does not need to be
synchronized with a hard fork.

## How would this be adopted?

This proposal would be adopted by means of the ECIP
editors moving it to Final state, if they are
convinced of broad ecosystem consensus in its
favor.

The Editors should use all signalling
mechanisms at their disposal to assure themselves
of broad support. That could include polls on social
media platforms, miner votes, coinvotes, public debates at meetups and events, testing the water
with "opinion pieces", repeated discussion during
the ECIP community calls, and anything else which seems prudent to them.

They should not rush this decision.

## Potential downsides of adopting this proposal?

Unlike a protocol-level consensus change,
dissent against this proposal being adopted would
not result in a chain-split - just in dissenting
voices grumbling about its adoption. That is not
problematic. The ETC ecosystem generally welcomes
dissent, and the people who would oppose this
proposal's acceptance already likely oppose
sticking with POW mining. They will be dissenters
irrespective of the result of this process.

If they choose to exit the ecosystem as a result
of this proposal being adopted then that is probably
a good thing.

## Intended benefit of adopting this proposal?

This proposal would give stakeholders in the Ethereum
Classic mining ecosystem (miners, pools, ASIC manufacturers, GPU manufacturers, etc) certainty
that any investments they make are not going to be
negated by rash future decisions by the Ethereum
Classic ecosystem to change course on the current
implicit social contract.

Making the implicit explicit, as Kirk Dameron
would often say, is a simple but immensely
powerful means for coordination.
Ambiguity is often as bad or worse than any decision,
even if that decision is not the one you would have
wanted. Like the ECIP for Monetary Policy, adoption
of this proposal will attract entities with long-term
aligned incentives to Ethereum Classic.

Bitcoin is likely the single project which has
a strong enough implicit social contract around
SHA256 that businesses can assume that it will not
be changing course - barring a situation where the
Bitcoing hashing algorithm had reached end of life,
with collisions signalling that it was time to
upgrade.

Ethereum Classic would have a uniquely strong social
signal with such an explicit statement.

## What if we "change our mind"?

If some future unforeseen event or change of
participants in the ETC ecosystem leads to broad
consensus that it is necessary for the good of the
network to break this explicit social contract then
that decision would have to go through the exact
same ECIP process as this proposal. That will
not be an easy process.

Even if it that new proposal did get approved,
the chances are that such a reversal of an
explicit social contract would be seen as so
divisive that a chain split would likely result.
This guarantee would still be respected on one of those chains (likely the majority chain).

Whatever the case, adoption of this ECIP would be
an unmistakeable sign that the Ethereum Classic
community is a very strong ally of the POW mining
ecosystem, in a way which likely on Bitcoin can
match at the moment.

## Isn't this proposal running counter to "The Manifesto"?

Some people may feel that adoption of a proposal
which seeks to make explicit social layer matters
goes against elements of the "openness"
and "neutrality" points of Arvicco's "A
Crypto-Decentralist Manifesto". This document
is broadly seen as a "Founding document" for
Ethereum Classic. There may indeed be such a perception about the manifesto, but in truth
the document is inspiration, not gospel truth,
and certainly not law.

## The need for a written Constitution and Bill of Rights for Ethereum Classic.

There is no written "Constitution" or "Bill of
Rights" for Ethereum Classic. No proposal for
such documents has ever been submitted to
the ECIP process. We have never explicitly
defined our social and ethical baseline
assumptions - only the hardness of
the protocol itself.

We depend on implicit social conformance and
watchdogs to reject proposals which breach those
baselines (ie. ProgPOW), but social conformance
to unwritten baseline assumptions is not a
safe approach.

We pride ourselves on our conservatism
and our focus on security, but we have nothing
but subjective humans standing in defence of Ethereum
Classic's unique value. We depend on particular
individuals and their "toxicity" to defend
Ethereum Classic. This approach is not socially
scalable. Those individuals may not be around
in the future. Social trends may shift.
Social attacks may grow.

This kind of loose arrangement is how British
government works. They refer to the unwritten
"Constitution" which it is expected that governments
will conform to. Essentially just precedent and
an expectation that people will "play fair".
This is an incredibly weak basis for governance.
Do we want that for Ethereum Classic?
That is what we currently have.

The author would advocate that Ethereum Classic
needs to be a Republic, not a mob Democracy, and
that we need a written Constitution and Bill of
Rights to ensure our mutual future freedom.

We need such rules to avoid the "Permissionless
Fallacy" which Donald McIntyre has explained.
There are certain proposals which would undermine
the very shared assumptions which make Ethereum
Classic "Decentralized, Unstoppable, Immutable".

The Monetary Policy ECIP was somewhat akin to
proposals which could be adopted into a
Constitution, because that policy also provided
long-term certainty for all ecosystem partipants.
The difference for the Monetary Policy is that
it was also a protocol-level consensus change,
not purely a social contract.

In actually broke immutability by changing the
future emissions schedule, but that exception
to our unwritten guiding principles was made
with broad social consensus. It had the
explicit goal of locking that economic policy
in stone forever.

## So is this proposal a Constitution?

Not really. It would just consist of a single
sentence. Something like:

"Adoption of this proposal by the ECIP authors
is an explicit social contact between the
Ethereum Classic ecosystem and the POW mining
ecosystem that ETC intends to stay with POW
mining (not merged mining) into the
indefinite future."

Such a contract could easily be adopted into
a future Constition for Ethereum Classic though.

If there is consensus that ETC needs a written
Constitution then the author will partner with
suitable co-authors and will propose one.

## IP Protections for Ethereum Classic

This work is licensed under the Apache 2.0 license.
The author,
Bob Summerwill,
attests to his sole authorship of this work,
and that
he is able to contribute this work
to the ECIP process under the Apache 2.0 licence.

He further attests that he neither holds nor is aware of any patents, trademarks, copyright issues or other IP hinderances associated with this work.

17th October 2019 – Vancouver, Canada – The ETC Cooperative today announced that it has extended Yaz Khoury's contract for another year. Yaz joined the ETC Cooperative in October 2018 and has been doing amazing work every since:

    - “Ethereum Classic on Raspberry Pi” - 10th Jan 2019.

    - “Analyzing Ethereum Classic with Google BigQuery” - 6th Feb 2019.

    - “Kotti, Solidity, ETC, Oh My!”" - 22nd March 2019.

    - “ETC: Wanted Dev or Alive" - talk given at EDCON 2019 in Sydney, Australia, 11th April 2019. Covering Kotti/Gorli, Ethernode, Mantis, OpenRPC, IOHK research work, BigQuery and Kaggle.

    - “Quantifying Immutability" - 6th May 2019.

    - “Ethercluster: An Open-Source Alternative to Infura” - 1st July 2019.

Executive Director Bob Summerwill tweeted "I am delighted to say that I have just signed a contract extension for our very own ETC Aquaman, Yaz,so he can continue his great work at the ETC Cooperative for another year!"

Yaz replied "Happy to continue working at the ETC Coop, the best nonprofit with the best leader I have the pleasure of working for!"

## About ETC Cooperative

The ETC Cooperative is a Delaware-incorporated 501(c)(3) public charity, which seeks to accelerate the growth of Ethereum Classic.

18th October 2019 – Vancouver, Canada – The ETC Cooperative today announced that it has joined the Enterprise Ethereum Alliance (EEA), the defacto standards organization for enterprise blockchain – one that is backed by the largest developer community in the world and a worldwide member-base.

As a member of the EEA, the ETC Cooperative will collaborate with industry leaders in pursuit of Ethereum-based enterprise technology best practices, open standards, and open-source reference architectures.

The ETC Cooperative is a Delaware-incorporated 501(c)(3) public charity, which seeks to accelerate the growth of Ethereum Classic. The Cooperative is working with the Ethereum community and the Ethereum Foundation on shared challenges between Ethereum and Ethereum Classic.

The Executive Director of ETC Cooperative, Bob Summerwill, was co-Lead Architect during the launch period of the EEA and then served as the first Secretary of the Technical Working Group and then as Vice-Chair of the Technical Steering Committee.

Bob Summerwill says: “I am absolutely delighted to return to the EEA – an organization which is very close to my heart. We at the ETC Cooperative plan to engage deeply in the EEA Mainnet Initiative and to work to help standardize the “Ethereum Stack” which is emerging as the defacto standard for smart contracts. That tech stack is common to Ethereum, Ethereum Classic, Enterprise Ethereum, EVM-in-Fabric and to other emerging related smart contract platforms. Ethereum is unique in its span of both public and private use-cases, and the EEA is the best place on the planet to find collaborators to mature that technology in the world-changing way which I know is possible.”

The EEA membership base represents hundreds of companies from every region of the world across a wide variety of business sectors, including technology, banking, legal, government, healthcare, energy, pharmaceuticals, marketing, and insurance. The EEA’s industry-focused, member-driven Special Interest and Technical Working Groups define market requirements needed to contribute to future versions of the EEA specification, helping to scale the number of market categories the specification supports. The EEA specifications and related materials are available for public download on the EEA website at entethalliance.org.

## About the EEA

The EEA is a member-driven, standards organization whose charter is to develop open, blockchain specifications that drive harmonization and interoperability for businesses and consumers worldwide. Our global community of members is made up of leaders, adopters, innovators, developers, and businesses who collaborate to create an open, decentralized web for the benefit of everyone. For additional information about joining the EEA, please reach out to membership@entethalliance.org.
For additional information about joining EEA, please reach out to membership@entethalliance.org or visit www.entethalliance.org.

## About ETC Cooperative

The ETC Cooperative is a Delaware-incorporated 501(c)(3) public charity, which seeks to accelerate the growth of Ethereum Classic.

19th October 2019 – Vancouver, Canada – The ETC Cooperative today announced that Alison Alexis CPA has joined the ETC Cooperative as its Financial Controller on a one-year, part-time contract.

Alison is a Canadian Chartered Professional Accountant (CPA) with 13 years of professional experience.

Alison spoke at [ETC Summit 2018] on the Immutability panel:

She is Alison Emily (@aalexis1234) on CryptoTwitter.

Bob Summerwill said: “I am delighted that Alison will be joining the ETC Cooperative as Financial Controller. The Cooperative is committed to financial transparency, and Alison brings deep accounting experience to the table. She will also assist me in defining the ETC Cooperative's governance for 2020 onwards as we become fully independent of Grayscale.”

## Public Disclosure

Bob Summerwill, the Executive Director of the ETC Cooperative, and Alison Alexis CPA, the newly appointed Financial Controller, are business partners at Varro Technologies, and are also in a common-law relationship and have a child together.

## About ETC Cooperative

The ETC Cooperative is a Delaware-incorporated 501(c)(3) public charity, which seeks to accelerate the growth of Ethereum Classic.

19th October 2019 – Vancouver, Canada – The ETC Cooperative today announced that Bob Summerwill, its Executive Director, will be speaking at the Global Digital Assets (Vancouver) Summit 2019 on Sunday 27th October 2019 on "What's Happening with Ethereum Classic?"

The Global Digital Asset Vancouver Summit is on Sunday, October 27 at the Pan Pacific Hotel in Vancouver, Canada. This second annual event brings together enterprise blockchain and entrepreneurs who are interested in exploring or working in the cryptocurrency or blockchain space.

Other speakers include Jun Du, founder of Node Capital, Founder of Jinse Finance, Co-founder of ChainUP and BiKi, Matthew Unger, CEO of iComply and Afshin Doust, CEO of Advanced Intelligent Systems.

Register at http://www.gdasummit.com/

## About ETC Cooperative

The ETC Cooperative is a Delaware-incorporated 501(c)(3) public charity, which seeks to accelerate the growth of Ethereum Classic.

https://ecips.ethereumclassic.org/ECIPs/ecip-1056

Ref #131 ECIP-1056

## ETC Core Devs Call - Agharta Finalization
- When: Thursday, October 24, 2019, 1pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #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 a timeline for the protocol upgrade
- anything else related to Agharta

### Bonus
- Sha3 / ECIP-1049
- DAG Size / ECIP-1043

### Please comment to add items to the agenda

https://github.com/ethereumclassic/ECIPs/issues/135

https://ecips.ethereumclassic.org/ECIPs/ecip-1061

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 #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

### Anything else related to Aztlán

### Please comment to add items to the agenda

https://github.com/ethereumclassic/ECIPs/issues/177

https://ecips.ethereumclassic.org/ECIPs/ecip-1061

## ETC Core Devs Call - Confirm consensus for Aztlán Upgrade (Yingchun Edition)
- When: Thursday, December 5, 2019, 1pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc.

Meeting Coordinator: @developerkevin.

## Agenda

### Aztlán Upgrade (Yingchun Edition) (ECIP-1061) is in "Last Call" status with review ending on 19th Dec 2019.
- Establish that we have new consensus on ECIP-1061, after several days of crisis.
- No finger-pointing, blame or post-mortem in this specific meeting. It would make a lot of sense to do a post-mortem on the last few days, and anybody is welcome to create an issue to start that process, or to publish their own post-mortem, etc. Just out of scope HERE.
- No discussion of #221 and #224 or other process clarifications. Similar to post-mortem, these have value and when we have fully-formed ECIPs we should certainly discuss those. Just out of scope HERE.

This is the full scope of the agenda. We won't add any items to this call. Laser focus.

The aim of the meeting is to calm everybody's nerves and to get back on track. We should record the audio. Multiple people should take minutes. The outcome should be reported on.

https://github.com/ethereumclassic/ECIPs/issues/215

On Thursday, December 12, 2019, 1pm UTC, an Ethereum Classic Core Devs call will be held to determine the final block selection for Agharta.

The call will be held in our English-language Discord channel, which you can join in this link

Ask one of our moderators or community organizers to be granted the right permissions to join the Voice Call.

## Agenda

The agenda for the call is the following:

We will first have a client check-in with representatives of the 4 clients for ETC:
1. Parity-Ethereum
2. Hyperledger Best
3. Multi-Geth
4. Classic Geth

Currently, the Agharta Hardfork is scheduled for mid-January 2020 and is currently in last call.

So, this call will be to achieve rough consensus on moving it to Final and selecting a block number together for when we should activate it.

We will also be evaluating results of the Agharta hard fork activation on our test nets Mordor, Kotti and Morden.

The reference to the issue discussion is found here

So please join us on this important call so we can finalize Agharta and get ready for some amazing changes to be added to ETC!

Looking forward to seeing you all there!

https://ecips.ethereumclassic.org/ECIPs/ecip-1056

Ref #131 ECIP-1056

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 #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
- discuss a timeline for the protocol upgrade

### Please comment to add items to the agenda

https://github.com/ethereumclassic/ECIPs/issues/175

### Recording of Core Devs Call

Core Devs Call: Agharta hard fork finalization

There was an ETC Devs / Miners / Community Call a day ago to talk about options to manage rampant chain bloat, which is on the ETC mainnet at the moment and is being caused by GasToken, with most blocks being filled with garbage, adding gigabytes to the state every day. This will compromise decentralization in short order and is an existential threat to the health of the network.

### Recording of Core Devs Call

Core Devs Call: Gas Limit Reduction

Bob S.’s suggested action items:
- Blog post on https://ethereumclassic.org/ by @zacmitton explaining the situation and appealing to miners to voluntarily reduce gaslimit. To 1M? To 2M? To 4M?
- Outreach on the above (using existing contacts we have used for prior HFs)
- Volunteers to generate pull-requests against Parity-Ethereum, Geth Classic, MultiGeth and Hyperledger Besu which change the defaults for ETC to the same
- Volunteers to consider countermeasures to reverse as much of the damage-to-date as we can by buying gastokens (using community fund if this is expensive) and then using them to debloat the chain
- Volunteers to consider protocol changes for the long-term, which could include:
- Gas price changes
- Removing opcodes (remove refund opcode, remove selfdestruct)
- Hard cap gas and curve (my pending ECIP) to give multi-decade certainty

Future discussion is best done on Github issues within the ECIP process, for global visibility and permanent papertrail on the decision-making process.

Thanks to Zac Mitton (one of the developers) for setting up and hosting the meeting.

This post was copied from https://bobsummerwill.com/2019/12/27/gas-limit-configuration-call/

# ECIP 1056: Agharta EVM and Protocol Upgrades

https://ecips.ethereumclassic.org/ECIPs/ecip-1056

## Simple Summary

Enable the outstanding Ethereum Foundation Constaninople and Petersburg network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Agharta to enable maximum compatibility across these networks.

## Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Constaninople and Petersburg hardforks. The proposed changes for Ethereum Classic’s Agharta upgrade include:
- Constantinople bitwise shifting instructions
- Constantinople skinny CREATE2 opcode
- Constantinople EXTCODEHASH opcode

This document proposes the following blocks at which to implement these changes in the Classic networks:
- 5000381 on Morden Classic Testnet (November 13, 2019)
- 301243 on Mordor Classic Testnet (November 20, 2019)
- 1705549 on Kotti Classic Testnet (December 11, 2019)
- 9573_000 on Ethereum Classic Mainnet (January 15, 2020)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

## Motivation

To enhance the Ethereum Virtual Machine’s (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since early 2019.

## Specification

Enable the following three hard fork features:
- EIP 145 (Bitwise shifting instructions)
- EIP 1014 (Skinny CREATE2 opcode)
- EIP 1052 (EXTCODEHASH opcode)

## Rationale

Atomicity: This protocol specification notably merges the scheduled features of the anticipated Petersburg protocol upgrade, which would removes the buggy proposal SSTORE net-gas metering.

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

## Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Constaninople and Petersburg features currently:
- Geth Classic: full support in v6.1.0 and later
- Parity Ethereum: all features due to Ethereum Foundation compatibility
- Multi Geth: all features due to Ethereum Foundation compatibility
- IOHK Mantis: no support
- Hyperledger Besu: all features due to Ethereum Foundation compatibility

### Copyright

Copyright and related rights waived via CC0.

https://ecips.ethereumclassic.org/ECIPs/ecip-1078

ref #217 #226 #227 #262

ref ECIP-1078 ECIP-1079 ECIP-1080

## ETC Core Devs Call - ECIP-1078 Phoenix Finalization
- When: Wednesday, February 05, 2020, 4pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc.

## Agenda

### Quick client teams check-in
- Parity Tech
- ETC Core
- ChainSafe
- Multi-Geth

### Aztlán needs to be fixed, options are:
- patch ECIP-1061 with EIP-1884 #280 - very unlikely
- replace ECIP-1061 with ECIP-1079 - unlikely
- update ECIP-1061 with ECIP-{1078,1080} - more likely

### Phoenix (ECIP-1078) needs to be either accepted or updated (or rejected)
- discuss included ECIP-1080 without gas repricing
- discuss swap of EIP-2200 for EIP-1706 (1283 fix)
- discuss a timeline for the protocol upgrade

### Anything else related to Aztlán and Phoenix

### Going through the pending ECIP PRs together

### Please comment to add items to the agenda.

https://github.com/ethereumclassic/ECIPs/issues/284

### Recording of Core Devs Call

Core Devs Call: ECIP-1078 Phoenix Finalization

https://ecips.ethereumclassic.org/ECIPs/ecip-1088

ref #297

ref ECIP-1061 ECIP-1078 ECIP-1086

## ETC Core Devs Call - Phoenix Upgrade from Scratch
- When: Wednesday, February 26, 2019, 1pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc.

## Agenda

### Quick client teams check-in
- Parity Tech
- ETC Core
- ChainSafe
- Multi-Geth

### Aztlán needs to be rejected as it's having multiple issues:
- #217
- #226
- #227

### Phoenix needs to be rejected as it's not of a sufficient patch especially with the context of the broken testnet activations:
- #262

### Testnet patch should be rejected to favor a clean new hardfork meta:
- #293
- #297

### It's still possible to do Phoenix on the same block number if we agree to activate one of the following options (ECIPs pending):
- Phoenix hardfork same as ETH Istanbul (including EIP-1884)
- Phoenix hardfork "classic flavor" (ECIP-1080 instead of 1884, EIP-1706 instead of EIP-2200)

### Anything else related to Aztlán and Phoenix

### Please comment to add items to the agenda.

https://github.com/ethereumclassic/ECIPs/issues/298

### Recording of Core Devs Call

Core Devs Call: Phoenix Upgrade from Scratch

# ECIP 1017: Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule

https://ecips.ethereumclassic.org/ECIPs/ecip-1017

## Abstract

This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a theoretical upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time.

## Motivation

At its core, the purpose of adjusting the current monetary policy of the ETC network, to a policy which places an upper bound on the number of tokens issued and decreases the rate at which ETC is introduced into the system over time, is to “bootstrap” the network’s security. By increasing the security of the network, a proper monetary policy indirectly nurtures the network, providing a secure platform for which smart contract development will be more likely to occur.

If we accept that speculation, a demand function, is the main economic driver of any new system, that the Ethereum Classic Network is a new system, and that speculation will drive the value of the Ethereum Classic token until the utility value of the Ethereum Classic token exceeds its speculative value, it is reasonable to assume that rewarding speculation will help to secure and nurture the network:

Large scale, high risk, and/or high profile applications will be less likely to be developed on a blockchain with weak security ie. a low hashrate. Increasing demand for the Ethereum Classic token will, all else being equal, increase the price of the Ethereum Classic token. An increase in the price of the token incentivizes mining operations to direct their efforts on the Ethereum Classic Network or to begin operations on the Ethereum Classic Network. The additional mining power that is directed towards the network, because of this incentive, further secures the network. An increase in the security of the network assists in building trust between the network and both current and potential users and developers of the network. This increase of trust in the network provides an incentive for large scale, high risk, and/or high profile applications to be developed on the network. Thus, rewarding speculation helps to secure and nurture the Ethereum Classic network.

Especially important to early stage cryptocurrencies, assuming all other variables are equal, a network with a decreasing rate of production and an upper bound on the number of tokens that will be issued will provide more incentive for high risk speculation to occur than one without a known rate of production or an upper bound.

Above all, it is important to recognize that a monetary policy does not directly create value for the network. A stable platform with useful applications and a vibrant community are the variables that drive value. The purpose of a properly structured monetary policy is to create an incentive for people to take a risk on a system that has not yet reached its full potential, providing an additional reason for those who may not otherwise be interested, who cannot or have not developed anything on the platform (yet), or who remain skeptical, to involve themselves in an otherwise nascent platform.

## Specification

Current Ethereum Classic Monetary Policy

The current mining rewards on the Ethereum Classic Network are as follows:
- A “static” block reward for the winning block of 5 ETC
- An extra reward to the winning miner for including uncles as part of the block, in the form of an extra 1/32 (0.15625ETC) per uncle included, up to a maximum of two (2) uncles.
- A reward of up to 7/8 (4.375ETC) of the winning block reward for a miner who has mined an uncled block and has that uncle included in the winning block by the winning miner, up to a maximum of two (2) uncles included in a winning block.
- This reward structure is set to continue in perpetuity.

Proposed Ethereum Classic Monetary Policy

An “Era” is defined as the number of blocks containing a given production rate.

The proposed mining rewards on the Ethereum Classic Network are as follows:
- Era 1 (blocks 1 - 5,000,000)
- Era 2 (blocks 5,000,001 - 10,000,000)
- Era 3+

## Rationale

Why this 5M20 model:
- Minimizes making the first adjustment too “exceptional.” Other than equalizing all uncle rewards at block 5M, the changes/reductions to supply over time are equal.
- The model is easy to understand. Every 5M blocks, total reward is reduced by 20%.
- Uncle inclusion rates through block 5M will likely remain at around the 5%. Because of this, once block 5M is reached, in the worst case scenario (supply wise, which assumes two uncles included every block in perpetuity) the total supply will not exceed 210.7M ETC. Should the network remain as efficient in its ability to propagate found blocks as it has in Era 1 (5.4% uncle rate), the total supply will not be less than 198.5M ETC. This provides for an incentive to miners and client developers to maintain high standards and maintenance of their hardware and software they introduce into the network.
- The 5M model provides a balance between providing an acceptable depreciating distribution rate for rewarding high risk investment into the system and maintaining an active supply production over time. Maintaining this future supply rate keeps the potential price of the ethereum token suppressed enough to ensure transaction prices can remain lower than if the supply were to reduce to zero at an earlier date. This serves as a “blow off valve” for price increases in the case that a dynamic gas model cannot be implemented for the foreseeable future.
- Having the monetary policy begin at 5M provides a balance between delaying the implementation to provide enough time for code development and testing, and accelerating the implementation to provide an incentive to potential early adopters and high risk investors. Based on community discussion, beginning before block 4M is too soon for development, testing, and implementation of the policy, and later than block 6M is too long to interest many potential early adopters/investors.
- Not changing the monetary policy of ETC provides no benefit to risk taking early on in the life of the system, speculation wise. It will be difficult for the network to bootstrap its security. While bitcoin has what is considered to be the generally accepted ideal monetary policy, with its 50% reduction every four years, this model is not likely to yield optimal investment for ETC. If ETC were to adopt the bitcoin halving model, it is arguable that too much of the supply would be produced too soon: 50% of the estimated total ETC supply would be mined 75% sooner than traditional bitcoin because of the pre-mine of 72M ETC that was initially created in the genesis block. While the 5M model does not completely eliminate the effects of the premine, since 50% of total estimated production occurs sooner than would the bitcoin model, it makes up for this, to an extent, with its lengthening of the time until 90%, 99% and 100% of bitcoin are mined. The tail end of ETC production is longer and wider than bitcoin.
- In the current ETC reward schedule, the total reward for uncles is higher than the reward received by the miner who also includes uncles. In this state, a miner is significantly diluting the value of his reward by including these uncled blocks. By equalizing the rewards to uncle block miners with the rewards to miners who include an uncle block, the reward structure is more fairly distributed. In addition, equalizing the uncle rewards reduces the incentive for miners to set up an ETC “uncle farm,” and instead drives them to better secure the network by competing for the latest “real block.”
- Because the rate at which uncled blocks can vary with extreme, reducing the reward for uncle blocks assists considerably with being able to forecast the true upper bound of the total ETC that will ultimately exist in the system.
- The model is the best attempt at balancing the needs to incentivize high risk investment into the system in order to bootstrap security and create a potential user base, be easy to understand, include a reduction to the rate of production of ETC over time, include an upper bound on supply, provide for a long term production of the ETC token, and allow enough time for development, adoption, and awareness.

# ECIP 1088: Phoenix EVM and Protocol Upgrades

https://ecips.ethereumclassic.org/ECIPs/ecip-1088

## Simple Summary

Enable the outstanding Ethereum Foundation Istanbul network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Phoenix to enable maximum compatibility across these networks.

## Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Istanbul hardforks. The proposed changes for Ethereum Classic’s Phoenix upgrade include:
- Add Blake2 compression function F precompile
- Reduce altbn128 precompile gas costs
- Add ChainID opcode
- Repricing for trie-size-dependent opcodes
- Calldata gas cost reduction
- Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

This document proposes the following blocks at which to implement these changes in the Classic networks:
- 999983 on Mordor Classic PoW-testnet (April, 2020)
- 2200013 on Kotti Classic PoA-testnet (April, 2020)
- 10500839 on Ethereum Classic PoW-mainnet (June 10th, 2020)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

## Motivation

To enhance the Ethereum Virtual Machine’s (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since end of 2019.

## Specification

Technical specifications for each EIP can be found at those documents respectively:
- EIP-152: Add Blake2 compression function F precompile
- EIP-1108: Reduce alt_bn128 precompile gas costs
- EIP-1344: Add ChainID opcode
- EIP-1884: Repricing for trie-size-dependent opcodes
- EIP-2028: Calldata gas cost reduction
- EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

## Rationale

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Mordor, Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

## Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Istanbul features currently and would be able to support the Phoenix upgrade:
- Core-Geth
- Hyperledger Besu
- Multi-Geth
- OpenEthereum

## Final Note

Both, the Geth Classic client and the Morden testnet will no longer be supported by the community and not receive the Phoenix ugrades.
- Users of the Geth Classic client are urged to migrate their services to Parity Ethereum, Multi-Geth, or Hyperledger Besu. It is no longer recommended to run Geth Classic in production.
- Users of the Morden Classic testnet are urged to migrate their applications to the Kotti Classic or Morder Classic testnets.

### Copyright

Copyright and related rights waived via CC0.

A Proposal for An Ethereum Classic Treasury System.pdf

Topic discussion references:
- 2017: A Proposal for An Ethereum Classic Treasury System - IOHK Research
- 2017: Let's Talk ETC! (Ethereum Classic) #10 - Charles Hoskinson & Roman Oliynykov - Treasury Proposal - IOHK Proposal
- 2017: ETC Community Fund
- 2018: ECIP 1051: Ethereum Classic Treasury system - Dexaran Proposal
- 2018: ECIP 1051 Dicussion: Ethereum Classic Treasury system - Dexaran Proposal
- 2018: ECIP 1052: Smart-contract Security Auditing core - Dexaran Proposal
- 2018: ECIP 1052 Dicussion: Smart-contract Security Auditing core - Dexaran Proposal
- 2019: ECIP-1051: Reject Ethereum Classic Treasury system - ETC Coop
- 2019: ECIP-1052: Reject Smart-contract Security Auditing core - ETC Coop
- 2020: Securing Proof-of-Work Ledgers via Checkpointing - IOHK Research Securing Proof-of-Work Ledgers via Checkpointing.pdf
- 2020: ETC at Crossroads - IOHK Renewed Proposal
- Example: A brief history of GnuPG: vital to online security but free and underfunded - Tragedy of the Commons example
- 2020: ETC at Crossroads Follow Up - Bailout? - IOHK Follow up
- 2020: EDCON 2020 | Ethereum Classic Resilience by Terry Culver, CEO of ETC Labs - ETC Labs Current Climate Input
- 2020: Ethereum Classic Ungovernance Explained - Donald's Opposition to a Treasury System
- 2020: Ethereum Classic Treasury Roadmap Call: Initial Discussions

## ETC Core Devs Call - Treasury Roadmap Initial Discussions
- When: Thursday, August 13, 2020, 3pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc.

## Agenda

### Quick client teams check-in
- Core-Geth - ETC Labs
- Hyperledger Besu - ETC Coop/ChainSafe
- Mantis - IOHK

### IOHK Proposal for an Ethereum Classic Treasury:
- A Proposal for An Ethereum Classic Treasury System
- ETC at Crossroads
- A brief history of GnuPG: vital to online security but free and underfunded
- Bailout?

### Gather Community feedback on Proposal via Q&A

### Measure Rough Consensus to Determine if IOHK will move forward with making an ECIP for the ETC Treasury.

### Anything else related to an Ethereum Classic Treasury System

### Please comment to add items to the agenda.

https://github.com/ethereumclassic/ECIPs/issues/332

### Recording of Core Devs Call
- https://www.youtube.com/watch?v=8EOz79tU_xo

Topic discussion references:
- proposal gathering and discussion only

## ETC Core Devs Call - Proposal Gathering
- When: Thursday, August 20, 2020, 12pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc.

## Agenda

### 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?

### Anything else related to an Ethereum Classic Hard Fork

### Please comment to add items to the agenda.

https://github.com/ethereumclassic/ECIPs/issues/333

### Documentation of Core Devs Call
- Action Items: ETC Q3 Hard Fork Draft 1
- IOHK CDC Feedback: Process for Decision Making and Innovation for ETC

Preface: Ethereum Classic suffered a second round of 51% attacks. As a result of the attacks, the development ecosystem around Ethereum Classic has seen a surge in activity via proposed solutions to safeguard the network.
- July 31, 2020
- August 6, 2020.

## Participant Feedback
The 8/20 Core Dev Call set out with the intent of "proposal gathering and discussion only" for the next hard fork on the Ethereum Classic network. Many of the participants felt the call lacked adequate time for proposal explanation, discussion, and constructive dialogue. These topics are technical in nature and cannot be accomplished in a one hour audio call. In fact, an hour call for each topic likely is not a sufficient amount of time to thoroughly analyze each proposal. Charles Hoskinson of Input Output Global offered some feedback on his experience with the CDC: Process for Decision Making and Innovation for ETC.

Everyone's time is valuable and no one likes to feel like they wasted their resources. Hopefully the consensus builders can take this feedback constructively and adjust the modus operandi for future technical calls. Also development teams have the freedom to host their own calls to adequately discuss their proposals. Participation in the network is encouraged, there are no centralized leaders in Ethereum Classic. Your voice is valuable. Join the conversation and be heard.

In an effort to steer the dialogue down a constructive path, please engage in the technical threads related to the proposals. The following is not an exhaustive list, due to the volume of new proposals, but this article will be updated as proposals formalize to the ECIP process.

### Algorithm-Agnostic Proposals to PoW Security
- ECIP 1092 "Pirlguard" - Technical Discussion
- ECIP 1094 "VeriBlock"
- ECIP xxxx "Checkpointing and Timestamping" - Video, Whitepaper

### Change the Algorithm Proposals
- Do Nothing. Stay with Ethash, unaltered.
- ECIP 1043 "Fixed DAG" - Technical Discussion
- ECIP 1049 "Keccak256" - Technical Discussion
- ECIP 1093 "RandomX" - Technical Discussion
- Related: ECBP 1076 "Miner Signaling" - Technical Discussion, Archived Discussion

### Parity with ETH Discussions:
- EIP-2315: Simple Subroutines for the EVM
- EIP-2537: BLS12-381 curve operations
- EIP-2046: Reduced gas cost for static calls made to precompiles
- EIP-2565: Repricing of the EIP-198 ModExp precompile

### Other ETC topics:
- Gas related proposals: ECIP 1042, ECIP 1047, ECIP 1083, ECIP 1084
- Backwards Compatibility proposals: ECIP 1040, ECIP 1068, ECIP 1069
- Slower blocks

### Contribute to the Discussion

The development proposals are where technical discussions occur. To stay current on Ethereum Classic development, please read and participate in the ECIP repo.

### Documentation of August 20, 2020 Core Devs Call
- Action Items: ETC Q3 Hard Fork Draft 1
- Input Output Global CDC Feedback: Process for Decision Making and Innovation for ETC

Topic discussion references:
- proposal gathering and discussion only

## ETC Core Devs Call - Evaluation and Consensus Finding
- When: Friday, August 28, 2020, 4pm UTC, 60 minutes max.
- Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc.

## Agenda

### Change the Algorithm Proposals
- Do Nothing. Stay with Ethash, unaltered.
- ECIP 1043 "Fixed DAG" - Technical Discussion
- ECIP 1049 "Keccak256" - Technical Discussion
- ECIP 1093 "RandomX" - Technical Discussion
- ECIP 1095 "SHA3" - Technical Discussion

### Anything else related to an Ethereum Classic Hard Fork

### Please comment to add items to the agenda.

https://github.com/ethereumclassic/ECIPs/issues/333

### Recording of Core Devs Call
- https://www.youtube.com/watch?v=4W1l5krLPqI

## ETC Core Devs Call - IOHK Checkpointing Presentation and Q&A
- When: Friday, September 04, 2020. 14:00 UTC; 30 minute presentation followed by Q&A
- Where: Crowdcast https://www.crowdcast.io/e/9epmnuoc

Please follow the meeting discussion here as they finalize the variables in real-time:
- https://github.com/ethereumclassic/ECIPs/issues/361

### Checkpointing Presentation

IOHK (IOG) has released ECIP-1097 #347 which covers their proposed "Checkpointing" system which aims to prevent 51% attacks on ETC. They'll explain the proposal and conduct a presentation, followed by a community Q&A.

### Goals

The goal of this call is simply to get contributors, community members, stakeholders and especially other teams who have created similar proposals (They implore other proposal authors @max-sanchez, @VeriBlock, @Dexaran, @rsksmart, @rootstock to show up to ask as many questions as needed) to properly understand this proposal. More details to come.

### Q&A
Questions will be submitted directly in the Crowdcast meeting (Link will be posted when date/time is confirmed)

### References
- Checkpointing Explanation Video: https://youtu.be/aasUIB1W81E
- Securing Ethereum Classic via Checkpointing: https://youtu.be/1JeL4pAjmXM
- Securing PoW Ledgers via Checkpointing Paper: https://iohk.io/en/research/library/papers/securing-proof-of-work-ledgers-via-checkpointing/

### Recording of Core Devs Call
- Crowdcast https://www.crowdcast.io/e/9epmnuoc

## ETC Core Devs Presentation - ECIP-1092 Pirlguard Presentation and Q&A
- When: Monday, September 09, 2020. 14:00 UTC; 30 minute presentation followed by Q&A
- Where: https://www.crowdcast.io/e/t1jytfn2/

Please follow the meeting discussion here as they finalize the variables in real-time:
- https://github.com/ethereumclassic/ECIPs/issues/364

### ECIP-1092 PirlGuard Presentation

Ethereum Commonwealth proposed a solution to 51%-attack on Ethereum Classic network: ECIP 1092. ECIP-1092 Proponents will present the ECIP and answer questions.

### Goals

Following the recommendations of representatives of other teams (mostly IOHK) and requests from community members, we decided to organize a live Q&A session. The goal of this call is to get contributors, community members, stakeholders and other teams who have created similar proposals to ask questions as needed to properly understand this proposal.

### Q&A

Questions must be submitted to this issue comment thread or directly at ETC Discord.

### References
- ECIP-1092
- Amendment to Nakamoto Consensus and network attack resolutions

### Recording of the Core Devs Presentation
- https://www.crowdcast.io/e/t1jytfn2/

## ETC Core Devs Call - ECIP-1043 and ECIP-1049
- When: Friday, September 11, 2020, 4pm UTC, 90 minutes max.
- Where: Jitsi Web/App ETCCoreDevsCall13, Dial in PIN 1401 7587 98 for ETCCoreDevsCall13 numbers
- Focus: Mining Algorithm, Last-Call Proposals

## Agenda
- ECIP 1043 Fixed Dag Size Restriction (Last Call)
- ECIP 1099 Calibrate Epoch Duration (Draft, alternative to 1043)
- ECIP 1049 KECCAK256 (Last Call)
- ECIP 1095 SHA3-256 (Last Call, alternative to 1049)

### Please comment to add items to the agenda.

https://github.com/ethereumclassic/ECIPs/issues/362

### Recording of Core Devs Call 13
- https://www.youtube.com/watch?v=9rqz81eh4

## ETC Core Devs Presentation - ECIP-1096 Bitcoin Merged Mining Presentation and Q&A
- When: Monday, September 14, 2020. 14:00 UTC; 30 minute presentation followed by Q&A
- Where: https://www.crowdcast.io/e/mqongnrs

Please follow the meeting discussion here as they finalize the variables in real-time:
- https://github.com/ethereumclassic/ECIPs/issues/343

### ECIP-1096 Bitcoin Merged Mining Presentation

We present a proposal for ETC to use blocks mined with SHA-256 in Bitcoin to detect blockchain branches that have been mined in private and rise alarms that can prevent double-spend attacks. The proposal enables full nodes to take local decision to prevent certain attacks, but also the existence of a public view of the different competing ETC branches enables the use a Fork Monitoring System that can provide more detailed alerts to full nodes and to the community.

### Goals

Following the recommendations of representatives of other teams (mostly IOHK) and requests from community members, we decided to organize a live Q&A session. The goal of this call is to get contributors, community members, stakeholders and other teams who have created similar proposals to ask questions as needed to properly understand this proposal.

### Q&A

Questions must be submitted to this issue comment thread or directly at ETC Discord.

### References
- ECIP-1096

### Recording of the Core Devs Presentation
- https://www.crowdcast.io/e/mqongnrs

## ETC Core Devs Presentation - ECBP-1100 Modified Exponential Subjective Scoring Presentation and Q&A
- When: Wednesday, September 23, 2020. 14:00 UTC; 30 minute presentation followed by Q&A
- Where: https://www.crowdcast.io/e/mess-classic-ecbp-1100

Please follow the meeting discussion here as they finalize the variables in real-time:
- https://github.com/ethereumclassic/ECIPs/issues/383

### ECBP-1100 Modified Exponential Subjective Scoring Presentation

ETC Labs Core, in consultancy with OpenRelay and ChainSafe, develop and propose a finality algorithm called MESS for Ethereum Classic that, if adopted by the honest majority, would raise chain state finality near-exponentially with negligible risk of network bifurcation.
- Overview "Artificial Finality" and non-invasive 51-percent-protection
- Quick explanation of the "MESS" protocol (ECIP-1100)
- LIVE Demo on the MESS testnet using Geth
- Community Q&A session

### Motivation
A low hashrate has caused Ethereum Classic's consensus algorithms to yield inconvenient and undesirable finality rates. ECIP-1100 "MESS" offers a way to increase the finality rate without tampering with existing "hard" chain consensus functions or characteristics, and to do so with minimal negative side effects.

### Q&A

Questions must be submitted to this issue comment thread or directly at ETC Discord.

### References
- Proposal: ECIP 1100: MESS (Modified Exponential Subjective Scoring)
- Read more: Agreeing To Disagree: Proposing a Weakly-Subjective Finality Solution for Ethereum Classic
- Discussion: 374
- Bonus: MESSnet TV - Visualization of an ad-hoc Classic testnet implementing MESS.

### Recording of the Core Devs Presentation
- https://www.crowdcast.io/e/mess-classic-ecbp-1100

## ETC Core Devs Call - 51% Attack Solutions
- When: Friday, September 25, 2020, 4pm UTC, 90 minutes max.
- Where: Discord
- Focus: 51%-Attack Solutions.

## Agenda

51% Attack Proposals
- ECIP 1092 51-percent attack solution PirlGuard by Callisto (Draft) - was skipped, nobody spoke in favor of it.
- ECIP 1094 VeriBlock Proof-of-Proof 51%-Attack Prevention (Draft) - was skipped, there will be a presentation by max next week.
- ECIP 1096 51% Attack protection system based on Bitcoin Merged Mining (Draft) - was discussed.
- ECIP 1097 Checkpointing based 51% attack resistance (Draft) - was discussed, requires either a hardfork or optionally a soft fork, we would have to chose trusted parties for committee.
- ECIP 1099 Calibrate Epoch Duration (Last Call) - 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.
- ECBP 1100 Modified Exponential Subjective Scoring (Draft) - 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.

### Please comment to add items to the agenda.

https://github.com/ethereumclassic/ECIPs/issues/362

### Recording of Core Devs Call 14
- https://youtu.be/_VChbJd87WM

## ETC Core Devs Call 15 - ECIP-1049 Keccak Breakout Session
- When: Friday, October 2nd, 2020, 4pm UTC, 120 minutes max.
- Where: Discord
- Focus: SHA3-256/Keccak256 Mining Algorithm Change Opposition Formal Conversation

## Agenda
- Review opposition comments.
- Give the authors a chance to discuss the opposition concerns on voice recording.
- Goal: Work at finding consensus as suggested by the ECIP process.

### Please review the issue thread to find the most up to date information.
- https://github.com/ethereumclassic/ECIPs/issues/382

### Recording of Core Devs Call 15
- https://vimeo.com/464336957

### Conclusion
- At this moment, Consensus did not appear to be present for ECIP-1049 due to many unanswered questions.
- Recommendation from the collective call was to keep ECIP-1049 in Last Call, while the network analyzes the impacts of other Accepted proposals like ECIP-1099 and MESS.
- It was recommended the ECIP-1049 authors work to clarify the proposal's specs/motives to draft a more solidified version of the proposal before being considered for Accepted or Rejected status.

Please direct future commentary to the ECIP 1049 discussion thread:
- https://github.com/ethereumclassic/ECIPs/issues/13

# ECIP 1100: MESS (Modified Exponential Subjective Scoring)

https://ecips.ethereumclassic.org/ECIPs/ecip-1100

## Abstract

Define a function arbitrating chain acceptance using relative total difficulty and common ancestor time to raise finality confidence.

## Motivation

A low hashrate has caused Ethereum Classic’s consensus algorithms to yield inconvenient and undesirable finality rates.

This proposal offers a way to increase the finality rate without tampering with existing “hard” chain consensus functions or characteristics, and to do so with minimal negative side effects.

## Specification

General

This proposal is built on a proposed core principle to Ethereum Classic neatly summed as:
Small reorgs are normal and healthy; large reorgs are suspicious. Given a reorg of unusual length, nodes should value their local (first-available) segment with preference over the later proposed segment, despite that it may have greater difficulty. Source

What follows is an algorithm and implementation details toward a way to realize this opinion programmatically as convention for network clients.

More Specifics

## Rationale

This is a modified (M) version of Buterin’s Exponential Subjective Scoring (ESS) by
- using a capped polynomial function instead of an unbounded exponential function
- using the difference of local head time(stamp) from common ancestor time(stamp), rather than the previously described block lengths or times of block reception used by Buterin.

See References for what I’ve found on the topic.

The Case and Place of Subjectivity

This specification maintains the (modified) GHOST protocol as an invariant; existing consensus rules are not modified nor sidestepped. Modified only is the schedule (ie “pace”, “timeline”) at which clients choose to implement these established procedures. The heaviest (most difficult) chain will – still – always, eventually, win. Proposed only is to make clients somewhat stubborn in their opinion and processing of chains; it makes them sluggish and resistant to big changes. It gives them a (temporary) opinion.

Opinions are allowed under GHOST and the rest of Ethereum’s Yellow Paper (and Satoshi’s email chains). Nowhere is it specified that blocks must be imported or included immediately, nor that a miner must mine on the heaviest chain available to them, nor that submitted transactions must be processed, nor that blocks must be propagated regularly.

The normal functioning of the chain is explained (as in rationalized) by some game theory and economics, but it is not subject to it. Miners are not forced (as in caused by the protocol) to mine on the heaviest chain available to them; they normally do so because they bet that that will turn out to be profitable for them. But sometimes mining on the heaviest chain may not be profitable for them; like if the heaviest chain was apparently made by a criminal, and perpetuating that association may lower the exchange rate of their reward. Miners can mine on whatever chain they want, can include whatever transactions they want, and can process, propagate, postpone, or ignore blocks however they want; all without offending Satoshi or his idolators.

In consideration here is a proposal of CONVENTION for network participants that is designed to keep the network as unified as possible while describing an opinion (implemented as algorithm) that prevents big ugly late-coming chain segments from being immediately and automatically accepted.

This is functionally no different than a thought experiment where the human miners are watching their nodes day-in and day-out, every minute, arbitrating with their own personal opinions about whether or not to allow geth to mine on top of block 10550798. Again, they are allowed to do this. They can do this. Sometimes they do do this. This proposal is a specification of a way that they can make this same order of decisions, but with the help of some math, a computer, and heuristics that will allow them to do it in coordination without requiring the use of the world’s most boring conference call.

In fact, one of the first evolutions of this proposal was made by @BelfordZ:
When geth wants to reorganize its existing chain for a too-long or too-old chain segment, have it just send an email to its operator saying: Geth has found a suspicious chain segment and requires a human’s wisdom and advice… and then turn off.

Except for a few fancy bells and whistles (ie maybe not shutting down… :)), and a proposed CONVENTION for determining suspicion, these proposals are more alike than different.

Network participants are allowed to be stubborn curmudgeons with opinions. ECIP1100 wants to help them do that gracefully.

Benefits
- Mini-forks and normal reorganizations are not effected, since their difficulty variances fall within the curve in this domain (200 seconds, give or take).
- There is no Edge-of-Eternity attack vector (no vulnerable focal points for an attacker to target).
- Partitions resolve quickly and consistently.
- Intentional partitions are extremely difficult to establish and maintain.
- The polynomial function yields a “ceiling” that would be extravagantly high for an attacker to achieve relative to the main network, but within reasonable operating bounds for the victim of an eclipse attack to eventually recover and rejoin the network. Unbounded exponential growth for the antigravity function serves no purpose beyond some point.

The graphs below show a 200 block chain accepting, sidechaining or rejecting reorganizations of varying relative difficulty and length.

Costs
- Nodes subject to eclipse attacks (mostly considered as nodes coming online after a long time or starting out) are vulnerable to destitution, even once released. This is addressed by the function’s ceiling causing the attacker to need to establish (and maintain) a total difficulty 1/31x of the competing honest chain, and can be addressed further by the operator including a checkpoint value.
- It may be anticipated that the network uncle and waste rates will rise slightly, as blocks that would otherwise be randomly included will be rejected. ETC currently has a 3.5% uncle rate compared to ETH’s 5.5%.
- A network vulnerability resulting in bifurcation exists given the condition that competing segments become available with near-equal total difficulty within the window of the antigravity curve allowance. This state of balance must be maintained until the antigravities force the network partitions to reject each other’s segments. If a state of near-perfect balance in total difficulty between the partitions can be maintained, this bifurcated state shall be indefinite. However, achieving and maintaining a balanced competition between segments can be seen to be extraordinarily challenging, expensive, and ultimately unlikely. Confounding variables for an attacker in this scenario are normal network hashrate variability, network propagation times and protocol, disproportionate mining entity hashpower share, unpredictable block times, and existing subjective arbitration steps.

Discussion of Constant Parameters

The polynomial function uses constant parameters xcap = 2pi/8000 and amplitude = 15, the values of which are reasoned as follows.

The x cap value of 2pi/8000 causes the peak of the curve (and ultimate ceiling) to occur at 25132 seconds (approximately 7 hours). This falls in between the rates of the previously considered exponential functions. The “ramp up” domain (nearest x=0) sees a flattened curve, yielding a more generous lenience for competing short segments. The curve eventually intersects the original exponential function at about 900 seconds (15 minutes) at about y=1.09.

The amplitude value of 15 causes the peak to occur at (215)+1 = 31. This value means that the maximum “antigravity” an attack will face is a 31, where the proposed chain would need a total difficulty 31 times that of the chain it would replace.

These values were chosen for ETC with the following assumptions and reasoning.
- Assume global Ethash hashrate availability is 200TH.
- Assume greatest single Ethash mining entity is 33% of the global, yielding about 66TH. This is considered as the largest possible antagonist for the ETC chain.
- Assume ETC has 3TH total contributed hashrate.
- Following this, we deduce that the largest Ethash mining entity has 22 times of ETC’s current mining power. An “attack” by this entity on ETC would result in a (66/(66+3))100 = 95% attack.
- Given a 22x anticipated “reasonable” worst-case scenario, the amplitude of 15 yielding a total 31 ceiling, around 50% above the anticipated worst-case scenario, is intended to be sufficiently future-proof and resilient to unforeseen scenarios.

Alternatives Considered

An bounded exponential function would work in much the same way, although it would not have a continuous ceiling transition and would, in a far-edge case, present an exploitable focal point of vulnerability at that transition.

## Implementation

This feature does not require a hard fork, but the network stands to benefit and avoid risk with majority coordinated acivation.

Core-Geth
- Feature is tentatively proposed to activate in Core-Geth on Ethereum Classic network at and above block 11380000 (10 October 2020).
- Feature is proposed to activate in Core-Geth on Ethereum Classic’s Mordor test network at and above block 2380000 (ETA 29 September 2020).
- Core-Geth feature implementation includes a few additional safety mechanisms:
- MESS is disabled for any sync mode besides full sync.
- MESS is only enabled once a peer has completed initial chain synchronisation, not while they are fast syncing or even full syncing during the download and process phase. This reduces the chances of a node coming online being lured into an eclipse scenario.
- MESS is only enabled if a peer has greater than or equal to the MinimumSyncPeers peers. In Core-Geth this value is by default 5.
- MESS is disabled if, once synced, a node’s head block is not changed within a time limit (ie becomes stale). In Core-Geth this value is by default 30 * 13 seconds.

The associated Core-Geth implementation is available here.

Testing
Cross client tests are included as assets as “first” and “second” RLP-encoded chain segments. A genesis configuration is provided describing the necessary chain and genesis configuration.

The file names describe the test, as well as providing expectations for the outcome of the second chain import via the suffix secondWins-true vs. secondWins-false.

# ECIP 1099: Calibrate Epoch Duration

https://ecips.ethereumclassic.org/ECIPs/ecip-1099 by Luke Williams

## Abstract

The purpose of this ECIP is to calibrate the epoch length used in DAG calculations.

Inspiration: ECIP 1043: Fixed DAG limit restriction by Cody Burns, Wolf Spraul

## Motivation

The original intent of the DAG was to provide ASIC resistance to the mining protocol in order to prevent centralization of mining distributions and thereby provide for an objectively fair distribution of tokens. As evident by ASICs being developed that are capable of matching current GPU miners while being more energy efficient, the DAG has succeeded in leveling the playing field between GPU incumbents and ASIC challengers, avoiding ASIC takeover and domination, and leading to a competitive and large mining ecosystem. However the original parameters are proving too aggressive, resulting in obsoleting support for GPUs still in wide use today by miners.

Calibrating these parameters to better reflect today's hardware markets and mining ecosystem will bring the DAG growth back in sync with commonly used GPUs. Allowing the DAG system to continue to serve it’s purpose far into the future.

## Rationale

At current epoch (372) the DAG size is 3.91 GB. 4GB GPUs are getting obsoleted while they still make up a significant amount of ethash hashrate. Activating this change at epoch 376 (for example), would reduce the DAG size from 3.94GB to 2.47GB. With the reduced growth rate, 4GB GPUs will remain supported for an additional 3+ years.

## Implementation

A Hard fork required for activation. Mining software and pool implementations required.

For the smoothest possible transition activation should occur on a block in which an epoch transition to an even epoch number is occurring.
- Epoch 388/2 = 194 (good) = block 11640000
- Epoch 389/2 = 194.5 (bad) -
- Epoch 390/2 = 195 (good) = block 11700000

The Mystique hard-fork will be activated on the Ethereum Classic mainnet at block 14,525,000 which is estimated to occur on Feb 13th, 2022.
This is not a contentious hard-fork, just a routine protocol upgrade.

It is anticipated that all the major pools, exchanges, wallets and other
services are ready or are actively preparing for Mystique.
Outreach is ongoing, but service providers are also encouraged to
publicly signal their readiness to the public in whatever way makes
most sense for them.

Adoption across publicly visible ETC nodes can be tracked on this dashboard
by looking at the percentage of nodes for which ForkId (Next) = Mystique:
- ETC Node Explorer

At the time of writing (January 27th), there is 35% readiness. The historic
adoption pattern has seen a spike in readiness close to the activation block,
following slow and steady increases in earlier weeks. It is not unusual for
total readiness to only hit 60-70% by the activation block. That is not
problematic as long as the economically important nodes (primarily those run
by mining pools and exchanges) are updated in time. If other node operators
do not upgrade then they get stranded on the old chain, but that does not
harm anybody but themselves. When they upgrade their own nodes, they will
be back on the right chain.

## Clients supporting Mystique hard-fork?

The following client releases contain Mystique support. All node operators are encouraged to upgrade as soon as possible.
- Core-geth v1.12.4 or later.
- Hyperledger Besu v21.10.8 or later.

If you are using a managed API service or third-party service provider, then please ensure they are ready for Mystique. The more people who ask, the more
likely a provider is to make a public statement confirming their readiness.

## What is the Mystique hard-fork?

Mystique is a hard-fork bringing a subset of the EIPs which are part of
Ethereum's London hard-fork across into Ethereum Classic. The hard-fork
is specified in
ECIP-1104 (Mystique EVM and Protocol Upgrades).

Included:
- EIP-3529 (Alternative refund reduction)
- EIP-3541 (Reject new contracts starting with the 0xEF byte)

Excluded:
- EIP-1559 (Fee market change)
- EIP-3198 (BASEFEE opcode)
- EIP-3554 (Difficulty bomb delay)

The fee market change and associated BASEFEE opcode are undesirable for ETC
because they conflict with the fixed monetary policy. The difficulty bomb
delay is not applicable because ETC has already removed the difficulty bomb
entirely.

See you on the other side!

Announcement thanks to https://www.ethereumclassic.technology/

The ETC Mystique hard-fork successfully activated at block 14,525,000.

Congratulations and thanks, everyone!

Announcement:
https://twitter.com/ETCCooperative/status/1492574609463341056#m

Forkmon:
https://forkmon.etccoopstats.com/

Mining pools:
https://miningpoolstats.stream/ethereumclassic

Huzzah!

## ETC Core Devs Call 22 - ECIP-1049 Proposed Rejection
- https://github.com/ethereumclassic/ECIPs/issues/460
- When: Monday, February 21st, 2022, 17:00 UTC, 120 minutes max.
- Where: Ethereum Classic Discord, the mods will set up a voice channel for the call. Please mute your microphone unless you are talking for clear recording. Participation is encouraged.
- Focus: REJECT SHA3-256/Keccak256 Mining Algorithm Change due to a high-probability risk of Contentious Chain Split between GPU Miners on ETCHash and FPGA & ASIC Miners on SHA3. ECIP-1049 is in violation of Ethereum Classic founding documents and the ECIP process. At this point, the contentious proposal has negative externalities on the network and is a resource drain. Move to reject the proposal after three years of technical discussion. If the proposal is not rejected, begin plans for a chain split.

## Agenda

ECIP-1000 Clause: "ECIPs should be changed from Draft or Last Call status, to Rejected, upon request by any person, if they have not made progress in three years. Such a ECIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Last Call if it meets the criteria required as described in the previous paragraph."

The reason for "Rejected" status under this clause is that the champion has not met this requirement during the three years: "the champion provides revisions that meaningfully address public criticism of the proposal". Rather, the champion has ignored much valid criticism and abandoned the proposal.
https://ecips.ethereumclassic.org/ECIPs/ecip-1000
- Follow Up from: #382
- Formal Proposed Rejection: #394 comment
- Documented Github Opposition: #394 comment
- If time permits: review ECIP-1094 and ECIP-1096 for activity. Newer proposals but appear to be abandoned by the authors as well. Should these be Withdrawn?

### Please review the issue thread to find the most up to date information.

### Related Discussions:
- 1. ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8
- 2. ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13
- 3. ETC Core Devs Call(s) 2020 Q3: Hardfork #333
- 4. ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342
- 5. ETC Core Devs Call 13 & 14 #362
- 6. ETC Core Devs Call 15 - ECIP-1049 Breakout Session Keccak-256 #382
- 7. SHA3 Precompile ethereum/EIPs#2951
- 8. Core Devs Call 15 Recording
- 9. Change the ETC Proof of Work Algorithm to Keccak-256 #394
- 10. Core Devs Call 19 Recording
- 11. Community Call 005 Recording
- 12. Community Call 010 Recording
- 13. ETC Core Devs Call 22: Proposed Rejection of ECIP-1049 #460

### It should be noted in this new discussion thread, this ECIP appears to be contentious (as documented in all the previous threads/recordings) and has a high-probability of a chain split between the GPU Miners on ETCHash and the FPGA & ASIC miners on SHA3.

### Recording of Core Devs Call 22
- To be posted after meeting...

### Conclusion
- To be updated after meeting...

Please direct future commentary to the newest ECIP 1049 discussion thread. However, please review the historical threads. There is plenty of technical discussion.
- Thread 394

## ETC Core Devs Call 22 - Proposed Rejection of Keccak256 ECIP-1049 Call Results
- https://github.com/ethereumclassic/ECIPs/issues/465
- ETC Core Devs Call 22 Recording: https://www.youtube.com/watch?v=lpdZgsAbPXo.

### ETC Core Devs Call 22: Conclusion
- A new ECIP-1049 Champion was selected in Bob Summerwill. The old champion, Alexander Tsankov has stepped down from the proposal stating he is too busy to champion this proposal.
- It was agreed by the ECIP Editor r0n1n and the new Champion of ECIP-1049, Bob Summerwill, that the ECIP-1049 proposal needs a material rewrite to meet ECIP-1000 compliance and remain in Draft status.
- The new Champion vocalized intent to bring the ECIP-1049 proposal up to ECIP-1000 standards within the coming months during 2022.
- The ECIP Editor and others on the call felt it was reasonable to afford the new champion time to clean up the ECIP-1049 proposal, as it was vocalized that undocumented technical work has been done by the champion's paid staff.
- The ECIP editor vocalized intent to leave PR 465 open to push this proposal to Rejected status should this proposal continue to sit in a state that violates the ECIP-1000. This comes after the CDC 15 meeting where Alexander Tsankov, the old champion of this proposal, vocalized intent to update the proposal after a failed push to Accepted status in 2020 and did not follow through with the ECIP-1000 requirements regarding criticism and dissenting opinions to the ECIP-1049 proposal from the community.
- It was recommended to split the ECIP to multiple ECIPs to align with ECIP-1000 guidelines; technical work, transition strategy, social consensus building, activation plan. These were some examples provided to the champion.
- The elephant in the room on ECIP-1049 has been a documented lack of consensus. The ECIP-1049 proposal aims to displace the current mining ecosystem. This is a violation of the ECIP-1000 in itself.
- Pushing contentious hard forks on the network is a violation of the ECIP-1000 process. It's unlikely the ETChash mining ecosystem will update nodes to this proposal should a hard fork be attempted. Many in the community; mining pools, miners, developers, core development teams, community members have vocalized support for the non-fork ETChash side of a contentious hard fork should the proponents of ECIP-1049 push a contentious hard fork on the Ethereum Classic network.
- The ETChash mining ecosystem was assured continued support from community members should any centralized actor attempt a contentious hard fork on the Ethereum Classic network.
- The opposition to ECIP-1049 has provided the new champion material criticism of ECIP-1049 to address during the champion's material redraft of the proposal.
- The proposal will be reviewed at a later date for ECIP-1000 compliance. Should compliance not be met, this proposal will move to Rejected status. Note: the Champion can always revive a Rejected proposal when ECIP-1000 compliance is met.

Note: This ECIP appears to be contentious, as documented in all the previous threads and recordings. This proposal has a high-probability of a chain split between the Mining Ecosystem on ETCHash (GPUs and ETChash ASICs) and the proposed new mining ecosystem on Keccak256 (FPGA & KEC ASICs).

### New Proposal Champion:

Given the new champion is active, Bob Summerwill is provided time to update the ECIP-1049 proposal to be ECIP-1000 compliant. This was recommended in October, 2020 to the previous champion after Core Developers Call 15, but did not happen. The hope is with a new champion we will see compliance with the ECIP process.
- ETC Core Devs Call 15 - ECIP-1049 Breakout Session Keccak-256

Some comments from Bob Summerwill on the undocumented technical work from his staff:
- Support for Astor already integrated in Besu. There is a pull request for core-Geth (and blocks successfully mined on Astor), but some rearchitecting needed to make that clean enough to integrate.
- The transition is where more client work is needed (ie. having a Testnet which goes through the transition versus being Keccak256 from Genesis). More work needed on mining side software too.
- So not tons left to do, but probably needs a couple of months of focus to do it right. Note - this is the technical work.
- Roll out via testnets, all the social layer etc etc is more time again, of course.
- I was asked where June, 2022 was feasible (end to end). I think that is a pretty clear not really possible.

Here is the open PR to move 1049 to Rejected status if the new champion does NOT bring the ECIP-1049 proposal up to ECIP-1000 standards:
- Rejected Status ecip-1049

Thanks for everyone's participation. Please direct future commentary to the newest ECIP 1049 discussion thread. However, please review the historical threads. There has been plenty of technical discussion on this matter over the years.

### Related Discussions:

Please review the issue thread to find the most up to date information.
- 1. ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8
- 2. ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13
- 3. ETC Core Devs Call(s) 2020 Q3: Hardfork #333
- 4. ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342
- 5. ETC Core Devs Call 13 & 14 #362
- 6. SHA3 Precompile ethereum/EIPs#2951
- 7. ETC Core Devs Call 15 - ECIP-1049 Breakout Session Keccak-256 #382
- 8. Core Devs Call 15 Recording
- 9. 2020 Document: Change the ETC Proof of Work Algorithm to Keccak-256 #394
- 10. Admin Clean Up on ecip-1049
- 11. Core Devs Call 19 Recording
- 12. Community Call 005 Recording
- 13. Community Call 010 Recording
- 14. Community Call 011 Recording
- 15. Community Call 012 Recording
- 16. Community Call 013 Recording
- 17. ETC Core Devs Call 22: Proposed Rejection of ECIP-1049 #460
- 18. Rejected Status ecip-1049 #465

### Recording of Ethereum Classic Core Devs Call 22 - Proposed Rejection of Keccak256 ECIP-1049
- ETC Core Devs Call 22: https://www.youtube.com/watch?v=lpdZgsAbPXo

Note: Issues with the ETC Discord server audio was reported by numerous call participants and observed on the recording. This led to talking over/interruptions during the call. Apologies to those listening after the fact from the organizer of the call and the third-party community member who recorded the call. Future CDC calls will be held on a platform with hand raising and the ability to mute interrupting parties during the call.
- Thread 394

# 5M20 Era 4 Fifthening: ETC Nears Bitcoin inspired Block Reward Reduction

## Ethereum Classic's Fixed Monetary Policy

Ethereum Classic is the original Ethereum network launched in 2015. One of ETC's most desirable properties, is its Bitcoin inspired monetary policy which features a fixed total supply and known emission schedule via ECIP-1017. The fixed total supply of Ethereum Classic is 210,700,000 ETC. To date, 67% of all ETC has been emitted and are circulating in the market. The emission schedule is a block reward reduction of 20% every 5,000,000 blocks, known as the 5M20 monetary policy. A visual countdown and chart of the 5M20 emission schedule can be found at ETCis.Money.

## 5M20 Era 4: Block Reward Reduction

Toward the end of April, 2022 the Ethereum Classic network is expected to cross the 15,000,000 block and enter the fourth era of the 5M20 emission schedule. This will result in a decrease of block rewards from 3.2 ETC to 2.56 ETC per block. This reduces the avaialable sell side liquidity provided to miners for securing the Ethererum Classic network via its ETChash Proof of Work consensus mechanism. We see similar market properties with Bitcoin's emission schedule every four years.

The table below shows the block reduction amounts and the total ETC emitted to miners during each 5M20 Era. Note, this table only highlights the first five 5M20 Eras. This 5M20 monetary policy will continue as long as the Ethereum Classic network continues to operate.

## ETC is Sound Money

The 5M20 emission schedule was inspired by Bitcoin. However the authors of ECIP-1017 desired a faster emission schedule to catch up to Bitcoin's low inflation rate. The "Fifthening" event for ETC occurs more frequently than Bitcoin's 4 year "Halvening" event. Also, the 5M20 features a smoother reduction curve with a 20% decrease compared to Bitcoins 50% reduction. The result is a decrease in Ethereum Classic's inflation at a quicker rate than Bitcoin. ETC uniquely provides the digital asset space with sound, programmable money on a censorship resistant, decentralized network.

So when someone asks you: "What are the unique properties that make Ethereum Classic special in a crowded cryptocurrency space?"

The logic is easy to convey: ETC is programmable sound money built on top of the largest Proof of Work smart contract blockchain. Ethereum Classic is censorship resistant and the premiere network to build unstoppable applications. Code is law.

## Plan C

If Bitcoin is Plan B. Ethereum Classic is Plan C.

Stay Classy. Stack ETC. ~ r0n1n

The Ethereum Classic Discord is an open and active community. Please join the conversation. It is unlikely there will ever be another network like Ethereum Classic due to its origin story. There is no centralized foundation that controls this network. There is no corporation or centralized planning that controls this network. There are no gatekeepers for your involvement in this network. Join the Ethereum Classic network and contribute to one of the very few truly decentralized and open source networks in the blockchain space. Build Unstoppable Applications.

## Learn More About ETC

Why Ethereum Classic
But some, like yourself, decide to dive a little deeper, and they discover some interesting facts that debunk that initial skepticism. Their journey down the rabbit hole begins when they find out that Ethereum Classic is not a clone of Ethereum™, but a continuation of the original Ethereum launched in 2015, which The Ethereum Foundation forked away from by launching a new protocol one year later in 2016.
- https://ethereumclassic.org

You can listen to or watch this video here:

## The EVM Needs an Upgrade

Ever since the launch of the Ethereum network in 2015, one of its most important components, the Ethereum Virtual Machine (EVM) has hardly ever been upgraded.

The EVM is a software component of all EVM compatible blockchains, including Ethereum Classic (ETC), that contains more than 120 operation codes (opcodes), which provide decentralized programmability to the networks.

Through all these years there have been several improvement proposals to upgrade the EVM, but in general they have always been set aside to prioritize other goals such as the migration of Ethereum to proof of stake.

However, now that the merge to proof of stake has already occurred in that network, the EVM upgrades are being included in the next set of improvements.

## The EVM Object Format (EOF)

The EVM Object Format (EOF) is a group of improvement proposals that have accumulated over the years, but that together form a consistent and logically sound upgrade for the Ethereum Virtual Machine.

Improvement proposals, called “Ethereum Improvement Proposals”, or EIPs for short, are formally structured documents that put forward ideas to the Ethereum ecosystem at large, of which Ethereum Classic is part, to make the system better from different technical standpoints.

These EIPs together will completely change for the better the way the EVM works, and all blockchains who wish to be compatible with the general EVM standard, such as ETC, need to follow these changes.

The motivations for these proposals are to solve some inefficiencies, high execution costs, and security issues in the current design.

## EIPs Included in EOF

The six EIPs considered part of the EOF upgrade are the following (summaries for each EIP were extracted from the improvement proposals themselves):
- EIP-3860: It limits the maximum size of initcode to 49152 and applies extra gas cost of 2 for every 32-byte chunk of initcode.
- EIP-3540: An extensible and versioned container format for the EVM with a once-off validation at deploy time. The version described here brings the tangible benefit of code and data separation, and allows for easy introduction of a variety of changes in the future.
- EIP-3670: Introduces code validation at contract creation time for EOF formatted (EIP-3540) contracts. Rejects contracts which contain truncated PUSH-data or undefined instructions. Legacy bytecode (code which is not EOF formatted) is unaffected by this change.
- EIP-4200: Three new EVM jump instructions are introduced (RJUMP, RJUMPI and RJUMPV) which encode destinations as signed immediate values. These can be useful in the majority of (but not all) use cases and offer a cost reduction.
- EIP-4750: Introduces the ability to have several code sections in EOF-formatted (EIP-3540) bytecode, each one representing a separate subroutine/function. Two new opcodes, CALLF and RETF, are introduced to call and return from such a function. Dynamic jump instructions are disallowed.
- EIP-5450: Introduces extended validation of code sections to guarantee that neither stack underflow nor overflow can happen during execution of validated contracts.

## When Are the EOF Upgrades Expected to Happen?

The Ethereum mainnet ecosystem has two upgrades, also called hard forks, programmed for 2023, Shanghai and Cancún, and the EIPs for EOF will likely be included in the second one, Cancún, which is aimed to be performed in the second half of 2023.

Again, the EIPs that will likely be included in this hard fork are:
- EIP-3860 “Limit and meter initcode”
- EIP-3540 “EVM Object Format v1”
- EIP-3670 “Code Validation”
- EIP-4200 “Static relative jumps”
- EIP-4750 “Functions”
- EIP-5450 “Stack Validation”

This means that, if everything goes according to plan, the Ethereum network EVM will be fully upgraded by the end of 2023 and that the Ethereum Classic blockchain will be totally compatible with the new EVM standard specifications by the first half of 2024, as it usually waits from 3 to 6 months to follow new upgrades for security reasons and because it is a more conservative blockchain.

## ETC Cooperative’s Contribution to EOF

The ETC Cooperative is a non-profit organization that is dedicated to supporting the Ethereum Classic network. One of its functions is to maintain and upgrade the protocol and software clients of ETC: Core Geth, Hyperledger Besu, and Erigon for ETC.

The core developers who perform these tasks are Isaac Ardis and Chris Ziogas (Core Geth and Erigon for ETC), and Diego López León (Hyperledger Besu).

The contribution of the ETC Cooperative to the EOF project is that core developers Isaac Ardis and Chris Ziogas will help in the upgrade process of the Erigon software client, the upstream master branch of the Erigon for ETC client, and Diego López León will help in the upgrade of Hyperledger Besu, the master branch of the client that works with ETC.

The benefit to Ethereum Classic is that it will necessarily inherit the EOF upgrades as Erigon for ETC is a downstream client to Erigon that will stay compatible with the EVM standard, and Hyperledger Besu supports the ETC network in its master branch.

An additional contribution of the ETC Cooperative to the EOF upgrade is that it will be helping the Vyper team through contracts with engineers Charles Cooper and Harry Kalogirou.

Vyper is an alternative smart contract language, so this is another path for testing EOF.

## Expected Results of the EOF Upgrade

According to Bob Summerwill, ETC Cooperative’s executive director, EOF is basically adding structure and versioning around the bytecode which was missing in the EVM before.

EOF helps in implementing future upgrades without breaking backwards compatibility, and also adds better up-front analysis at compile time.

In other words, it will make the system cheaper, faster, and safer.

Smart contract authors will see no difference in their work - just that the compiler output will get better and will cost less gas.

It is one of the very few EVM changes which Summerwill thinks is a “must have” prior to considering progress ossification of the ETC protocol.

## Conclusion

The original design goals of the EVM were simplicity, reduction of ambiguity in the specification, space saving, specialization to expected use cases, high security, and optimization friendliness.

It has been amazing that to a great degree all these goals have been met. However, some problems have emerged and been identified over the years, and several proposals had been put forward, but delayed in time.

The solution are the EOF upgrades and their accumulated EIPs.

This upgrade is certainly a major project and change in the industry.

Thank you for reading this article!

To learn more about the EOF upgrade please go to: https://notes.ethereum.org/@ipsilon/eof1-checklist

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

## What is the Fifthening in ETC?

Ethereum Classic’s monetary policy has a rule that every 5,000,000 blocks it will reduce the mining reward by 20%. This is called the fifthening because it is a 1/5 cut in the issuance of the coin.

The mining reward is the amount of ETC that is issued to pay for miners to produce blocks for the network.

In ETC, a block is currently being produced every 13.1525 seconds on average.

The historial schedule of payments per block to miners by the Ethereum Classic network has been the following:

Era 1: 5.00 ETC, from block 0, which happened on June 30, 2015

Era 2: 4.00 ETC, from block 5,000,000, which happened on December 11, 2017

Era 3: 3.20 ETC, from block 10,000,000 which happened on March 17, 2020

Era 4: 2.56 ETC, from block 15,000,000 which happened on April 25, 2022

Because ETC is now on block 17,088,524 as of this writing, it is paying 2.56 ETC per block as we are in era 4.

In the next era, which will be era 5, the block reward will be reduced to 2.048 ETC.

## When Will ETC’s Next Fifthening Happen?

To estimate when the next ETC fifthening will happen we need to know how many blocks are left until the next fifthening. Then, we need to multiply that number of blocks by the average block time of the network in seconds. This will give us the number of seconds left until the next fifthening. If we transform that amount into days, then we will be able to add the result to the current date and determine when the next fifthening will happen.

Following the above logic we will do the following calculation:

Current ETC block at the time of this writing: 17,088,524

Next fifthening block number: 20,000,000

Blocks left until the next fifthening: 20,000,000 - 17,088,524 = 2,911,476

Seconds left until the next fifthening: 2,911,476 x 13.1525 = 38,293,188

Days left until the next fifthening: 38,293,188 / 60 / 60 / 24 = 443.2081

Current date at the time of this writing: March 8, 2023

Current date + 443.2081 days = May 25, 2024

## What is the Halving in Bitcoin?

Bitcoin’s monetary policy has a rule that every 210,000 blocks it will reduce the mining reward by 50%. This is called the halving because it is a 1/2 cut in the issuance of the coin.

The mining reward is the amount of BTC that is issued to pay for miners to produce blocks for the network.

In BTC, a block is currently being produced every 9.2660 minutes on average.

The historial schedule of payments per block to miners by the Bitcoin network has been the following:

Era 1: 50.00 BTC, from block 0, which happened on January 03, 2009

Era 2: 25.00 BTC, from block 210,000, which happened on November 28, 2012

Era 3: 12.50 BTC, from block 420,000 which happened on July 09, 2016

Era 4: 6.25 BTC, from block 630,000 which happened on May 11, 2020

Because Bitcoin is now on block 779,961 as of this writing, it is paying 6.25 BTC per block as we are in era 4.

In the next era, which will be era 5, the block reward will be reduced to 3.125 BTC.

## When Will Bitcoin’s Next Halving Happen?

To estimate when the next BTC halving will happen we need to know how many blocks are left until the next halving. Then, we need to multiply that number of blocks by the average block time of the network in minutes. This will give us the number of minutes left until the next halving. If we transform that amount into days, then we will be able to add the result to the current date and determine when the next halving will happen.

Following the above logic we will do the following calculation:

Current BTC block at the time of this writing: 779,961

Next halving block number: 840,000

Blocks left until the next halving: 840,000 - 779,961 = 60,039

Minutes left until the next halving: 60,039 x 9.2660 = 556,321

Days left until the next halving: 556,321 / 60 / 24 = 386.33

Current date at the time of this writing: March 8, 2023

Current date + 386.33 days = March 29, 2024

## Why Are the Fifthening and the Halving Important?

The most important feature of the ETC and BTC currencies is that they are considered digital gold because they require enormous amounts of work and energy to create them.

In addition to this cost of production, both Ethereum Classic and Bitcoin have capped supplies as their monetary policies reduce the payments to miners in the quantities explained above.

These characteristics of both coins mimic the scarcity of gold in the real world, giving them great demand as decentralized and permissionless units of exchange and stores of value.

The fifthening and the halving are important because they approximate the inflation rate of ETC and BTC to that of gold, which is historically around 1.7%. As both ETC and BTC issuances will eventually go to zero, they will actually have lower inflation rates than gold.

The current inflation rate of BTC is 1.84% and by the next halving, in March of 2024, it will go down to 0.92%.

The current inflation rate of ETC is 4.83% and by the next fifthening in May of 2024 it will go down to 3.87%. By the year 2032, ETC will have an inflation rate of 1.67%, very similar to that of gold, and lower than the current inflation of Bitcoin.

Both ETC and BTC are sound money and transferable permissionlessly over the internet.

Thank you for reading this article!

To monitor the ETC fifthening clock go to: https://etcis.money/

Tomonitor the Bitcoin halving clock go to: https://buybitcoinworldwide.com/halving/

To learn more about ETC please go to: https://ethereumclassic.org

## ATTENTION ETHEREUM CLASSIC NODE OPERATORS AND MINERS:

The Ethereum Classic upgrade, code named SPIRAL, will occur on block 19,250,000. The estimated date for SPIRAL is January 31 2024.

Ethereum Classic core developers have posted ECIP-1109, which provides information for ETC’s SPIRAL hard fork.

This document proposes the following blocks at which to implement these changes in the Ethereum Classic networks:

 on Mordor testnet (already upgraded in November of 2023)

 on Ethereum Classic mainnet (estimated for January 31 2024)

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.

## Technical Details, Motivation, and Rationale

For technical details, motivation, and rationale for the hard fork, please visit ECIP-1109: http://ecips.ethereumclassic.org/ECIPs/ecip-1109

## Node Explorer

Adoption across publicly visible ETC nodes can be tracked on this dashboard by looking at the percentage of nodes for which ForkId (Next) = Spiral:

– https://etcnodes.org/fork/spiral

## Client supporting the SPIRAL hard-fork

The following client release contains SPIRAL support. All node operators are encouraged to upgrade as soon as possible.

– Core-geth v1.12.17 or later.

## Communications

If you are using a managed API service or third-party service provider, then please ensure they are ready for SPIRAL.

The more people who ask, the more likely a provider is to make a public statement confirming their readiness.

If you are a miner, mining pool, node operator, wallet operator or other kind of ETC stakeholder, please upgrade your node/s to minimize the risk of network splits.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

We are pleased to announce that the Ethereum Classic (ETC) Spiral upgrade was a success!

The purpose of Spiral was to bring ETC up to parity with the Ethereum Virtual Machine standard and the Ethereum network. It accomplished this by enabling the outstanding Ethereum Foundation Shanghai network protocol upgrades on ETC.

Spiral added support for a subset of protocol-impacting changes introduced in Shanghai.

The changes for Ethereum Classic included the following:

To learn more about the Spiral upgrade please refer to the corresponding ECIP: https://ecips.ethereumclassic.org/ECIPs/ecip-1109

Spiral was activated network wide on block 19,250,000 which occurred on February 5 2024 at 1:34:37 hours UTC.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

Just as Bitcoin (BTC) has the “halving” event every four years, Ethereum Classic (ETC) has the “fifthening” event every two years.

Also, like Bitcoin, it is an important event in the history of ETC each time there is a fifthening because it brings the issuance rate lower, and a lower issuance rate means harder money.

ETC has recently successfully gone through a very important event, which was the Spiral hard fork. The next exciting moment will be the day of the fifthening which is estimated to be between May 27 and June 11 of 2024.

The inflation rate of ETC is currently running at 4.26%. After the next fifthening it will go down to 3.41%. This is good news for ETC investors and savers.

## What Is the Fifthenning?

When Satoshi Nakamoto set the supply schedule of BTC, he determined that every 210,000 blocks, or 4 years, the payment to miners was going to be reduced by 50%, hence the “halving”. This payment schedule will reduce the issuance of BTC until it reaches zero. This will determine a total supply of BTC that will ever exist of 21,000,000.

Similarly, when the ETC community set the supply schedule of ETC in 2017, it determined that every 5,000,000 blocks, or 2 years, the payment to miners was going to be reduced by 20%, hence the “fifthening”. This payment schedule will also reduce the issuance of ETC until it reaches zero. This will determine a total supply of ETC that will ever exist of 210,700,000.

## How Do You Track the Fifthenning?

The easiest way to track the Ethereum Classic schedule of fifthenings is to go to etcis.money and check there how many days are left until the next 20% discount to miners.

As may be seen in the image in this section, at the time of this writing, February 20 2024, we are on block 19,351,247 and the next fifthening happens on block 20,000,000.

As block 20,000,000 is estimated to happen in 112 days and 15 hours, then the current date plus 112 days and 15 hours will be June 11 2024.

The etcis.money website has other interesting data points and information about ETC, such as its features and a comparison chart between ETC, BTC, and ETH.

## How Do You Calculate the Fifthenning?

Historically ETC has had block times between 13 and 15 seconds, so below we are going to go through the processes of calculating the remaining days to the next fifthening using 13 and 15 second estimates.

To estimate when the next ETC fifthening will happen we need to know how many blocks are left until the next fifthening.

Then, we need to multiply that number of blocks by the average block time of the network in seconds (we will use 13 and 15 seconds).

This will give us the number of seconds left until the next fifthening. If we transform that amount into days, then we will be able to add the result to the current date and determine when the next fifthening will happen.

How Do You Calculate the Fifthenning?

### Following the above logic, using 15 seconds, we will do the following calculation:

Current ETC block at the time of this writing: 19,351,247

Next fifthening block number: 20,000,000

Blocks left until the next fifthening: 20,000,000 - 19,351,247 = 648,753

Seconds left until the next fifthening: 648,753 x 15 = 9,731,295

Days left until the next fifthening: 9,731,295 / 60 / 60 / 24 = 112.63

Current date at the time of this writing: February 20 2024

Current date + 112.63 days = June 11 2024

### Now, we will use 13 seconds:

Current ETC block at the time of this writing: 19,351,247

Next fifthening block number: 20,000,000

Blocks left until the next fifthening: 20,000,000 - 19,351,247 = 648,753

Seconds left until the next fifthening: 648,753 x 13 = 8,433,789

Days left until the next fifthening: 8,433,789 / 60 / 60 / 24 = 97.61

Current date at the time of this writing: February 20 2023

Current date + 97.61 days = May 27 2024

The above estimates mean that the next ETC fifthening will happen between May 27 and June 11 2024.

## ETC Is Programmable Digital Gold

The most important goals of blockchains are trust minimization and sound money. In the case of ETC, it is sound money with smart contracts, which makes it programmable sound money.

Because ETC has this fixed monetary policy explained in this article, it is hard money as its new issuance will continue to diminish until inflation will reach zero.

Not only ETC is hard money due to its fixed supply, but it is also a proof of work (POW) blockchain.

POW ensures that the cost of creating the coins is the same as creating the blocks.

This gives ETC the same unforgeable costliness that Satoshi Nakamoto gave Bitcoin making it digital gold. And, because ETC supports smart contracts, then it is programmable digital gold.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

# Olympia Upgrade: Protocol Funding and Governance for Ethereum Classic

Ethereum Classic community developers have submitted a set of four Ethereum Classic Improvement Proposals (ECIPs) under the collective banner of the Olympia Upgrade. This coordinated protocol initiative introduces a decentralized, non-inflationary system for funding and governance built natively into the Ethereum Classic network.

All four ECIPs are now in Draft status and open for public comment per the ECIP-1000 process.

## 📜 Included ECIPs

| ECIP # | Title | Summary |
|--------|-------|---------|
| 1111 | Olympia Network Upgrade | Activates EIP-1559 on Ethereum Classic and redirects the BASEFEE to an on-chain treasury contract. |
| 1112 | Olympia Treasury Contract | Introduces an immutable, non-custodial smart contract to hold protocol-level revenue. |
| 1113 | Olympia DAO Governance Framework | Defines a modular, on-chain governance system to manage treasury fund disbursement. |
| 1114 | Ethereum Classic Funding Proposal Process (ECFP) | Establishes a standardized lifecycle for submitting, reviewing, and executing funding requests. |

## 🎯 Motivation

Ethereum Classic has long struggled with decentralized funding for core development, infrastructure, and ecosystem growth. Historically, funding decisions have relied on off-chain donations, central entities, or ad hoc coordination — models that are not sustainable, transparent, or permissionless.

The Olympia Upgrade solves this by:
- 🔁 Redirecting protocol revenue into a public treasury (ECIP-1111, ECIP-1112)
- 🗳 Empowering ETC holders to govern disbursements through on-chain voting (ECIP-1113)
- 📄 Establishing a standardized process for builders to propose, justify, and receive funding (ECIP-1114)

This architecture brings Ethereum Classic into alignment with modern, DAO-first networks — without requiring inflation, custody, or off-chain gatekeeping.

## 🔍 Addressing Common Concerns

Some initial questions and concerns are expected, especially around compatibility, decentralization, and network ethos. The Olympia Upgrade has been designed from first principles to align with ETC’s core values:

### ✅ Opt-In, Non-Disruptive, Additive
- Olympia is opt-in — participation in governance is entirely voluntary.
- Legacy transactions (Type 0) are unaffected. No changes are required for users, dApps, or miners not using the treasury.
- Client compatibility is preserved — no changes to the EVM, state format, or core consensus logic beyond EIP-1559 activation.

### 🛠 No Inflation or Monetary Dilution
- No new tokens are minted — Olympia is entirely funded by redirecting the introduced BASEFEE, which would otherwise be burned under EIP-1559.
- Miners retain their block rewards and priority fees, while the protocol-level basefee serves public goods.

### 🌐 Anti-Centralization by Design
- The Olympia Treasury is non-custodial, immutable, and enforced on-chain by smart contracts — not human signers.
- The Olympia DAO uses permissionless governance with public proposals, timelocks, and auditability.
- Disbursements are executed automatically via smart contracts after successful on-chain votes — no single party can override or block community-approved proposals.

### 🧱 Decentralization and Transparency Improvements

Olympia represents a meaningful shift away from opaque, centralized funding structures that have historically:
- Blocked contributors from accessing support
- Made arbitrary decisions behind closed doors
- Mismanaged resources with little accountability

Instead, Olympia introduces:
- Transparent on-chain voting and funding records
- Reproducible proposal formats (ECFPs) open to all contributors
- Immutable audit trails enforced at the protocol layer
- No gatekeeping or favoritism — if a proposal meets quorum and passes, it executes

Olympia is not a centralizing force — it is the antidote to centralization that has plagued ETC’s growth in the past.

## ⛓ Technical Overview
- EIP-1559 activation introduces a BASEFEE, which Olympia redirects to a protocol treasury instead of burning.
- The Olympia Treasury holds these funds in a verifiable smart contract (ECIP-1112).
- The Olympia DAO governs the treasury using on-chain voting with secure execution mechanisms (ECIP-1113).
- Builders submit ECFPs (ECIP-1114) to propose work and receive funding through a standardized, transparent process.

## 🧪 Rollout Plan
- Testnet deployment on Mordor is scheduled for Q4 2025.
- Security audits, governance testing, and documentation will follow.
- Target Mainnet activation: By end of 2026, subject to ecosystem consensus and readiness.

## 🗣 Community Discussion

These proposals are currently in Draft form and subject to revision. Feedback from all corners of the community is encouraged.
- Join the discussion:
 https://github.com/orgs/ethereumclassic/discussions/530

## 📣 Call to Action

Please review the proposals and share feedback. This is your opportunity to shape the future of funding and coordination on Ethereum Classic:
- ECIP-1111: Olympia Network Upgrade
- ECIP-1112: Olympia Treasury Contract
- ECIP-1113: Olympia DAO Governance Framework
- ECIP-1114: Ethereum Classic Funding Proposal Process (ECFP)

This is the most significant advancement to ETC’s sustainability since the project’s inception. With your feedback and support, Olympia can ensure that Ethereum Classic remains decentralized, permissionless, and self-sovereign — for the long haul.

—
Posted by Chris Mercer, with contributions from Cody Burns

You can listen to or watch this in video here:

In the blockchain industry, and in Ethereum Classic in particular, many think that the proof of work consensus mechanism is a voting system. This stems from a mistake Satoshi Nakamoto made when writing the Bitcoin white paper where he stated "proof-of-work is essentially one-CPU-one-vote".

What he meant by the above phrase was that proof of work was better than using IP addresses to prevent sock puppet attacks and sybil attacks on peer to peer networks to reach consensus on their latest state, but he did not mean to say that voting per se existed in the system or that it was part of the consensus mechanism he invented.

That proof of work is a voting mechanism can't be further from the truth. If it were true, then it would be much more efficient, scalable, and cheap to just have a voting process to establish what is the next block and order of transactions in a blockchain.

Voting is a conflict minimization device, not even a good decision making process, and even less a blockchain consensus mechanism.

Proof of work enables consensus by merit, free choice, and adoption, not by voting.

In the following sections I will explain these concepts.

## 1. Voting as a Pure Conflict Resolution Device

Voting is a conflict resolution device, not a good decisions making process.

To illustrate this idea I will describe the three stages of conflict resolution between humans when selecting alpha leaders (group alpha males or females, kings or queens, or presidents).

### Caveman Era

In the caveman era, group size was between 50 and 150 individuals composed of related families and individuals so they generally trusted each other. However, this did not eliminate the violent struggle that often ensued when alpha leaders died and they needed to be replaced. The method that resolved this kind of costly conflict was always brute force. This is, the strongest individuals with the best alliances (and luck) just grabbed the position by brute force (the famous "law of the jungle").

### Monarchy Era

As groups grew and humans organized themselves in tribes and city states, then the most common form of alpha leadership was the monarchy model. Because the fights and violent processes of succession became too costly, then they naturally gravitated to another conflict minimization device which was to just follow the eldest son or daughter of the last monarch as the new alpha leader.

### Voting Era

As tribes and city states grew into countries and nations, and because the monarchy system was prone to abuse, then a new model emerged (although it was practiced several times in antiquity but with much less success) which was to "revert power to the people" and to vote by majority who would be the next alpha leader when it was time to change.

Hence, the purpose of voting is only to reduce the costs of conflict and to provide a peaceful process for alpha leadership succession in the context of larger nations and societies.

### Voting Is a Bad Decision Making Device

If the pilot in a flight you are traveling suddenly dies, would you have a vote between the passengers to elect the next pilot so everyone may survive, or would you just want the co-pilot, another trained and experienced pilot, to complete the flight?

The above rhetorical question illustrates how voting per se, although it is a good conflict resolution device, is a bad decision making device.

Proof that it is a conflict minimization device and not a good decision making process is that alpha leaders were established by brute force in the caveman era, by blood in the monarchy era, and by majority vote in the voting era, but none imposed leadership by merit or qualifications.

## 2. Voting and the Illusion of Individual Participation

Voting tricks us by making our limited brains believe that we are actually influencing the outcome of a change or that we are making our own choices when casting our ballots.

However, the truth is that, in large groups, our influence and choices when voting are extremely diluted (e.g. in a nation of 20 million inhabitants our vote is just 1 in 20 million at most) and the forces that really count are the charisma of dishonest leaders and their ability to manipulate the crowds. Not their virtue nor their capability to govern.

When we accept the results of voting it is because we have an inherent desire to avoid conflict and to lower the cost of succession. This is why we have idealized views and dreams about voting and the illusion that the world will be happy and free if everything were decided and resolved by voting.

## 3. Merit, Free Choice, and Adoption vs Imposition by Majority

In proof of work, any miner from anywhere in the world freely competes against other miners to produce the next block by investing a lot of capital in more and faster machines and spending a lot of money in energy to find the cryptographic stamp or hash for that block. When any of the competing miners finds the hash, then it sends it as soon a possible to the rest of the network so that all individual nodes may check that the transactions and the cryptographic stamp in it are good so they can include it as the next block in the blockchain, and pay the miner a reward.

All participating miners and individual nodes are totally independent and don't talk to each other to decide or vote which block is correct. Even being totally isolated and possibly receiving many false blocks from many imposters, they can know which is the correct one with a high degree of certainty just by verifying that the enormous amount of work was done by the honest miners.

The whole mechanism above works with zero impositions, zero voting, and zero penalties or violence. All participants just produce blocks or verify blocks and, in their complete isolation and free will, decide by themselves what is the next block to include in their local blockchain and what chain to follow.

This means that proof of work is:
- Merit, by determining the winner of the next block and paying it the reward by pure competition, ability, and individual risk.
- Free choice, by enabling all participants, whether miners or nodes, to participate voluntarily from anywhere in the world to produce blocks or to verify them if they wish.
- Adoption, by enabling all participants, whether miners or nodes, to select the chain they wish to follow, with no penalties nor impositions of any kind and in absolute isolation without any external influence.

## 4. Proof of Stake is Voting and Imposition by Majority

Proof of Stake is voting and imposition by majority plus violent penalties, therefore purely subjective.

This is why this method can get rid of proof of work as a consensus mechanism and is loved by centralist social designers who think they can plan the individual lives of millions of people from a laptop, tablet, or cellphone.

In proof of stake system, the core of the imposition mechanism (I call it this because it is not a consensus mechanism) is that one of many stakers is randomly selected to create the next block, then it sends it to a selected committee of other stakers who vote by majority if the block is valid, and then they send it and impose it to the rest of the network at large.

Anyone who does not follow these steps is penalized with an over-complex system of checks and balances.

Because proof of stake imposition mechanisms have this traditional top down method of reaching unity in the state of the network, they are very capturable by corporations and governments, for which there are real life examples in the industry.

Because proof of stake systems use voting and are capturable, then they are not decentralized, censorship resistant, immutable, nor permissionless.

## 5. Proof of Work Is Pure Permissionlessness

Proof of work has these four features:

1. Enables consensus: All participants in the network can have the knowledge of which is the correct and honest chain because it is very easy to discard any attackers or imposters as the only way to build a legitimate block is by using enormous amounts of energy. This method has enabled full consensus every 10 minutes for 14 years in the case of Bitcoin, and full consensus every 15 seconds for 7 years in the case of Ethereum Classic.

2. Enables chain selection for free exit and entry: The same method of discarding the imposters who did not do the work and only including the blocks that did the work make proof of work blockchains absolutely free to enter and exit at any time, because it is very easy for any machine to just verify what chain of blocks has the real work done and to discard all others.

3. Protects transactions: Because to build the blocks requires so much work by machines and expenditure of enormous amounts of electricity, if any attacker wanted to reverse the chain of blocks to the past to introduce fake transactions, censor, or eliminate accounts or balances, they would have to do all the work again for all the blocks they wished to revert. This is practically impossible as not only would they need an enormous amount of computing power, but also to purchase and use all that energy all over again.

4. Imposes a cost to create the money: This was the original objective of the Cypherpunks, to impose a large cost to create what they called "Bit Gold" at the time so that the cost of creating the proofs of work would be the same of creating the money (or what is called in economics "sound money"). This feature is what is analogous to gold in the real world and gives value to BTC and ETC as they have the same features of scarcity and unforgeable costliness as gold in the real world.

These features combined guarantee the key benefits of a true blockchain, which are decentralization, censorship resistance, immutability, and thus permissionlessness.

This is why anyone can enter or exit a proof of work blockchain whenever they want, adopt the chain they wish, and do all of this with no top down obligation or impositions but their own will.

Majority voting is the top down imposition to use the block and the chain that the majority voted for with no other option. This is the implicit agreement in voting mechanisms.

Proof of work permissionlessness is diametrically opposite to imposition by majority vote.

Thank you for reading this post!

To learn more about ETC and how it works please go to: https://ethereumclassic.org/why-classic

You can listen to or watch this video here:

## Main Image on ethereumclassic.org and Its Symbolism

When you go to the Ethereum Classic website you find the image below which has a lot of symbolism and meaning for the ETC blockchain.

As may be seen above we marked the sections of the image with the meaning of each section. The three pillars are:
- smart contracts or programmability,
- fixed supply which gives ETC its property of digital gold,
- Proof of Work which is the heart of the network as it provides the security of the whole system.

In the image, the three pillars hold up and support the main principle of the Ethereum Classic network, represented as justice scales in between software code, which means Code Is Law.

In abstraction, the image symbolism on the home page may be represented as in the diagram below.

## Explanatory Text Beside the Image

Beside the image on the website, there is a text that explains to newcomers what is Ethereum Classic and implicitly lists five benefits of the pillars of ETC as well as the principle of Code Is Law.

From the text above I underlined the keywords that represent the benefits of the Code Is Law principle, which is upheld by the three pillars of ETC, and below I list them with their meaning:
- Survivability: Because of ETC's security, accounts, balances, and smart contracts will survive in the long term.
- Censorship Resistance: ETC is censorship resistant and unrestricted, therefore permissionless.
- Unstoppability: Currency transfers and decentralized applications are unstoppable.
- Uncompromisable: Accounts, balances, and decentralized applications cannot be compromised as in traditional systems.
- Uncapturable: ETC cannot be captured by corporations or special interests.

So, the three pillars uphold the principle of Code Is Law, and the principle of Code Is Law guarantees the benefits of survivability, censorship resistance, unstoppability, and make ETC uncompromisable and uncapturable.

Then, the question is: How do the three pillars of Ethereum Classic guarantee the principle of Code Is Law and its main benefits?

This is what we will explain in the rest of this article.

## Pillar 1: Smart Contracts

When we use the traditional web and apps on our phones or computers they interact with the central servers of tech companies and banks. This presents the risks of censorship, confiscation, restricted access, and manipulation of our activities by corporations and governments.

What good is a decentralized cryptocurrency as Bitcoin if to use it through applications, the applications themselves may be captured? What good would it be to supposedly make that cryptocurrency “programmable” if the programmers are hosted in centralized data centers and cloud services?

As smart contracts inside Ethereum Classic are decentralized software programs, they can power applications, making them decentralized applications (dapps). This means dapps on the ETC blockchain truly provide the benefits decentralization.

This is, that the Code Is Law principle is true in ETC and this enables applications to have the same security as the currency inside the blockchain.

By “security” we mean survivability in the long term of the code on the network, resistance against censorship, unstoppability of dapps, and hence that they will be uncompromisable and uncapturable as in traditional systems.

## Pillar 2: Fixed Supply

As the security model of a proof of work blockchain depends in a great measure on demand for its services (a secure and programmable cryptocurrency in the case of Ethereum Classic) then the properties of sound money must be a key component of the system to provide the economic incentives to increase its demand.

Sound money means that the native token must be scarce, durable, costly to create, portable, divisible, fungible, and transferable. However, the more important innovation that blockchains brought to the world with regards to sound money was that the currency is also trust minimized.

Trust minimization means that the ability for any centralized entity or special interest to change the supply of the currency is significantly reduced, or practically eliminated.

This gives a much higher assurance that the monetary policy will not be arbitrarily modified and increased, diluting the wealth and property of holders, as it happens systematically with fiat money.

Because ETC’s cryptocurrency is programmed in the protocol and it has a decreasing supply that tends to zero, with a supply cap of 210,700,000 coins, then it has these desirable features and properties that we seek, therefore it is sound money and secures property rights on a global scale.

If sound money increases demand, and growing demand increases security, then sound money means survivability in the long term, censorship resistance, unstoppability of dapps, and that the system is uncompromisable and uncapturable.

## Pillar 3: Proof of Work

The Proof of Work Based Nakamoto Consensus mechanism guarantees decentralization because it:
1. Enables consensus: All participants in the network can have the knowledge of which is the correct and honest chain because it is very easy to discard any attackers or imposters proposing alternative chains as the only way to build legitimate blocks is by doing a lot of work, consuming enormous amounts of energy.
2. Enables chain selection for free exit and entry: The same method of discarding the imposters who did not do the work and only including the blocks that did the work make proof of work blockchains absolutely free to enter and exit at any time with no permission nor direction from anyone.
3. Protects transactions: Because to build the blocks requires so much work by machines and expenditure of enormous amounts of electricity, if any attacker wanted to reverse the chain of blocks to the past to introduce fake transactions, censor, or eliminate accounts or balances, they would have to do all the work again.
4. Imposes a cost to create the money: The reward per block, which issues new native tokens, only happens if the work to build a block is done. This feature is what is analogous to gold in the real world and makes ETC digital gold.

The decentralization provided by the above features is the heart of the security of Ethereum Classic, thus survivability in the long term, censorship resistance, unstoppability of dapps, and that the system is uncompromisable and uncapturable.

## In Summary

Smart contracts provide programmability inside the blockchain and this enables applications to have the same security as the currency.

Fixed supply provides economic incentives in the form of sound money for the network to grow and become more secure.

Proof of Work makes the network truly decentralized, censorship resistant, immutable, and enables anyone in the world to participate permissionlessly.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

The permissionless paradox in Ethereum Classic is this: To maximize permissionlessness in the ETC blockchain, you must reduce permissionlessness in the community that most influences it. Or, to put it more bluntly, the ETC community should not be permissionless.

By "ETC community" I mean the social media outlets such as the Discord server, the GitHub organization and its various repositories, the ECIP process, and other non-mainnet forums.

There is something I call the "freedom conservation law" which means that to increase freedom in one place, you need to reduce freedom in another. This is how civilization works.

In civilized societies, no one can go around destroying life and property. These are individual guarantees that need strong rules and enforcement to be implemented and took thousands of years to develop. So, in essence, all participants in a civilized society must sacrifice their absolute individual freedom, by following the rule of law, to maximize their individual freedom in the context of civilized society. To maximize your freedom you must sacrifice your absolute freedom.

This marks a separation between the operating network and the ETC community. The ETC community is the social layer. The social layer is where ideas and actors exist and work. If all the ecosystem participants in the social layer were convinced of a bad idea by a bad actor, then bad ideas would be introduced to the operating network, reducing its decentralization, thus reducing its permissionlessness.

A system that seeks freedom, must not allow anti-freedom in the system.

All the above ideas seem counterintuitive: If freedom is freedom, and permissionlessness is permissionlessness, then why should anything be prohibited or not allowed?

The answer is that freedom is not a normal state in nature. It is not, like many believe, "the law of the jungle". To the contrary, freedom is the result of artificial and very strict and thoroughly enforced rules. The "law of the jungle" is anti-freedom and only depends on brute force. In it, the destruction of life and liberty are permitted.

Despite what utopian thinkers believe, life, liberty, and property are not natural occurrences, nature is actually hostile to living beings. Any man or woman who lives in civilized society would likely not survive very long if they were left in the wilderness.

Life, liberty, and property are artificially created benefits of artificial environments, very carefully designed by men to organize civilized society.

In the same way, permissionlessness in a blockchain as Ethereum Classic is not a natural state, it is the result of a carefully designed protocol that guarantees sound money, property, and agreements in a decentralized network on a global scale. Deviations in that protocol would significantly weaken these guarantees.

Another thing that sounds counterintuitive is that the more zealous about its principles and intolerant about deviations the Ethereum Classic community is, then the more permissionless ETC will be.

Indeed, ETC community members and the ecosystem at large; including core contributors, community participants, volunteers, miners, node operators, investors, dapp developers, and users; should memorize and know by heart the Ethereum Classic philosophy and principles just as Rabbis and Pastors cite the Bible by book, chapter, and verse.

There shouldn't be a drop of misunderstanding or doubt in anyone, and everyone should defend the Code Is Law principle with all their hearts and souls.

That ETC is permissionless means that, as long as they have an internet connection, anyone from any place in the world should be able to freely create accounts, enter transactions and smart contracts, or participate in the network as a miner, node operator, user, investor, or any other prescribed capacity.

However, with the same intensity and passion, to keep and maintain this level of freedom, the ETC social layer must always reject and never permit bad ideas or bad actors in any of its forums or assets, including the Discord server, the GitHub organization and its various repositories, and the ECIP process.

It is common to hear many people in ETC community forums confounding permissionlessness with "freedom of speech". This is wrong. Bad ideas and bad actors must be prohibited. The community must not be permissionless.

Permissionlessness in the operating ETC network is guaranteed by a very strong set of rules, enforced by the strength of cryptography and by the enormous power of the proof of work consensus mechanism. Bad ideas introduced through the social layer can seriously undermine this structure, and thus undermine permissionlessness itself.

And, because the social layer is where the security holes are, then the social layer must be extremely principled and very carefully guarded.

Permissionlessness is for the blockchain, not the community.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

In January of 2009 Satoshi Nakamoto launched the Bitcoin network. Previously, in October of 2008, he had already published the Bitcoin white paper where he mentioned trust minimization 14 times.

However, Bitcoin as a technology provides a very simple task: It is a ledger that only holds accounts and balances and people can send transactions to move money from one account to another. That's it. Nothing more.

Nevertheless, the fact that it provides a simple service must not undermine the incredible innovation and philosophical objectives that it accomplished. The proof of work mechanism that Satoshi Nakamoto invented is a giant leap forward for humanity, comparable to the printing press in the 1450s or the internet in the 1990s. It is a historic change of paradigm in the way money works.

The philosophy and accomplishment of trust minimization in Bitcoin means that now individuals and businesses may control and hold their money in their own custody without any intermediaries. They can also send transactions to make transfers in a permissionless and censorship resistant manner.

In banking, providers have custody of wealth and grant permissioned access to owners. In Bitcoin, owners have custody of their wealth and may do whatever they want with no permission.

This stemmed from a strong Cypherpunk philosophical basis. Their objective was sound and decentralized money in a peer-to-peer system, and the only way to accomplish this was to eliminate trusted third parties. It is no coincidence that Satoshi made this statement in the first paragraph of his paper:

"...but the main benefits are lost if a trusted third party is still required..."

To accomplish the goal of trust minimization, the technology of proof of work is fundamental. The main benefit of this consensus mechanism, called Nakamoto consensus, is that it provides a means for all participants in the network to arrive at the same exact state of the ledger every 10 minutes just by verifying the proof of work hash created by miners when sending a block of new transactions.

Additionally, this same feature enables any participant to exit and enter the network whenever they want, without asking permission or without the supervision from anyone.

These benefits, plus the fact that the work in proof of work protects the integrity of transactions by creating a security wall, and imposes a cost to create the currency, making it sound money, made it possible to run the system without trusted third parties.

Bitcoin's core innovation is this level of security, not innovation in the form of the latest gimmicks or bells and whistles.

Ethereum Classic has this exact same philosophy. ETC stayed with the proof of work consensus mechanism despite all major smart contracts networks using proof of stake, and even when Ethereum migrated from proof of work to proof of stake in September of 2022.

In ETC, as in Bitcoin, the innovation is security through trust minimization.

But Ethereum Classic does not operate like Bitcoin. ETC has the same exact design as Ethereum. In other words, it is an EVM blockchain.

What is an EVM blockchain?

Another of the Cypherpunks' goals was to integrate smart contracts, or decentralized software programs, inside the digital currency network. What use is a decentralized currency as Bitcoin if to use it and program the money you need to use apps that are hosted in centralized servers, data centers, or cloud services?

This was the solution that Vitalik Buterin invented in 2013: Ethereum.

Like Bitcoin, Ethereum holds accounts and balances in its ledger, but unlike Bitcoin, Ethereum also supports the addition of smart contracts, which are decentralized software programs that may be used to program the money. This made Ethereum a programmable blockchain.

The Ethereum Virtual Machine (EVM) model consists of the following components:
1. A ledger with accounts and balances, and a cryptocurrency.
2. A virtual machine that is replicated in all participating nodes of the network, making it a virtual decentralized computer.
3. More than one hundred and twenty operation codes (opcodes) that the virtual machine may execute, making near Turing complete.
4. A programming language, called Solidity, that can produce code in the form of software programs that are executable by the virtual machine.
5. The ability to store these programs inside the network's database which is replicated in all participating nodes, making the programs decentralized, also known as "smart contracts".
6. A gas system, that designates a number of computation units, called gas, that each opcode in the virtual machine consumes, and that must be paid for by users, so that all the nodes running the virtual machine may get paid for their work and know when to stop executing a program, solving the halting problem in a decentralized manner.
7. Blocks of new transactions are created every 15 seconds.

With all the above features combined, the Ethereum network accomplished the task of adding smart contracts to the basic accounts and balances network that was Bitcoin.

Ethereum Classic has exactly the same design as Ethereum, and shares the same features. This is because Ethereum Classic is actually the original Ethereum!

Ethereum and Ethereum Classic were one chain since inception in 2015, but due to a controversy called TheDAO) in 2016, Ethereum split from the mainnet and departed with a completely different philosophy than ETC.

The controversy was that the Ethereum side wanted to manually confiscate the funds of a hacker to return them to the original owners, and the Ethereum Classic side wanted to uphold the philosophy of immutability of the chain and not confiscate the funds, but to have people solve those things outside of the network. This principle in ETC became known as Code Is Law and is its most fundamental tenet.

Since that split, Ethereum has decided to follow a philosophy called weak subjectivity. This was the moral basis for migrating to the less secure proof of stake consensus mechanism, which is basically to run the network very much like the banking system. Weak subjectivity has a security of last resort that they call "social consensus" which means that, ultimately, anything that goes on inside the network may be modified, rectified, or manually managed by the participants in the network. This is absolutely antithetical to Bitcoin's and thus Ethereum Classic's philosophy of trust minimization and immutability.

This is why in Ethereum Classic we say "ETC is BTC philosophy, with ETH technology".

Due to its design choices, ETC has a system where both the currency and the decentralized applications are inside the same security environment of the proof of work blockchain. With this technology it is possible to design decentralized applications (dapps) where, even if the founders or the company of a dapp disappear, the smart contracts, accounts, and balances may still be perfectly safe inside the blockchain.

ETC is a fusion of the best of both worlds: The marvel of proof of work as a consensus mechanism with its true censorship resistance, permissionlessness, and immutability, and the computability, programmability, and versatility of smart contracts.

In ETC the money and the dapps are decentralized, immutable, permissionless, and censorship resistant. This is the essence of the principle of Code Is Law, which is largely upheld by the combination of Bitcoin's invention of the proof of work consensus mechanism and Ethereum's innovation of smart contracts.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

Ethereum Classic (ETC) is a cryptocurrency, a blockchain, and a world computer.

It is a cryptocurrency because it has a coin called Ether or ETC, which trades under the symbol $ETC, that has a fixed monetary policy and a capped supply of 210,700,000 coins, making it not only suitable for global permissionless payments, but also for use as a store of value.

ETC is a blockchain because it is a network of machines around the world which follow a censorship resistant protocol to manage a database that contains accounts and balances, and accepts blocks of new transactions every 15 seconds to move money from one account to another.

It is a world computer because it also stores decentralized programs, called smart contracts, that can be used to power unstoppable applications or dapps.

## Structure

To accomplish the features mentioned above, ETC has a virtual machine called the Ethereum Virtual Machine, or EVM for short, that has more than 120 opcodes, which is replicated in all the network nodes, making it a decentralized virtual machine. This component enables the participating computers to execute the decentralized software programs stored in the blockchain's ledger.

The decentralized software programs, or smart contracts, are programmed in a software language called Solidity that encodes them using the opcodes of the EVM so they can be executed inside the system.

One of the great inventions of Ethereum Classic was the gas system, which is a model that designates a number of units, called gas, per opcode so users may pay for these units for the participating machines to execute them. This method solved several problems such as spam, the halting problem, and the compensation for miners, to enable smart contracts in a decentralized peer-to-peer network.

## Difference With Bitcoin

Bitcoin is a cryptocurrency and a blockchain only and its sole function is to maintain accounts and balances. This makes it like a pocket calculator compared to Ethereum Classic.

However, what makes Ethereum Classic and Bitcoin similar is that both use the key invention of Satoshi Nakamoto, which is proof of work.

The full name of the system is "Proof of Work Based Nakamoto Consensus" and it consists of making a subset of the machines of the network, called miners, perform a function called mining, which requires lots of computational work and expenditure of electricity. The result of this work is a cryptographic stamp that is added to blocks of transactions, hence the term "blockchain", which are produced in specific time intervals and then sent to the rest of the network to include them as the latest state of the system.

Nakamoto Consensus achieves something that was not possible before, which is that computers in the network, no matter where they are in the world or who they belong to, can agree, without permission or supervision, in a decentralized manner, what is the latest state of the network.

## Difference With Ethereum

There are four things that define the differences between Ethereum Classic and Ethereum (ETH).

1. ETC is the original chain and ETH is a fork: When Ethereum was launched in 2015, both Ethereum Classic and Ethereum were one chain, but in 2016 there was a controversy called TheDAO that provoked Ethereum to split from the mainnet. Ever since, they have been two separated networks and ETC has followed a very conservative philosophy of high security called Code Is Law and Ethereum has followed a more risky philosophy called Weak Subjectivity with the aim of making it more scalable.
2. ETC is proof of work and ETH is proof of stake: Ethereum migrated from proof of work to proof of stake, which is less secure, but more scalable so this was more in line with their philosophy. ETC stayed and will stick to proof of work forever, so this means that it is truly decentralized, permissionless, and immutable.
3. ETC has a fixed monetary policy and ETH does not: ETC has a fixed monetary policy very similar to that of Bitcoin, with a cap of 210,700,000 coins, making it programmable digital gold. Ethereum does not have a fixed monetary policy, they have changed it six times since inception and it is uncertain what the supply will be in any given year.
4. ETC is censorship resistant and ETH is not: As miners who produce blocks to include new transactions in proof of work blockchains as ETC do not have to comply with financial regulations or international sanctions because they are not financial providers, and because they may move from place to place and mine anonymously, they can include all transactions sent to the network from anywhere inside the blocks. Ethereum proof of stake stakers are in a large measure regulated financial institutions based in western nations who have to comply with local and international restrictions and sanctions and this has made Ethereum a predominantly censored network because they are obligated to exclude transactions from certain sanctioned accounts.

## The Security vs Scalability Tradeoff

As mentioned above, Ethereum Classic is highly secure because it uses proof of work and full replication of the database as its consensus model. Indeed, ETC is the largest and most secure smart contracts blockchain in the world. This makes it optimal as a base layer blockchain system as it may be used for settlements and high value, low volume use cases.

As proof of work does not enable scalability in the form of high transaction volumes, then ETC may have other systems in higher layers that may process larger transaction volumes, but settle inside ETC. This design is the most popular in the industry to achieve scalability, examples of which are the Lightning Network as a layer 2 of Bitcoin and rollups as a layer 2 of Ethereum.

## Dapps Are Inside the Secure Environment of the Blockchain

As the largest and most secure smart contracts network in the world, ETC has one thing that differentiates it and makes it unique. Unlike Bitcoin, Dogecoin, and Litecoin (the other large proof of work blockchains in the world) ETC is programmable with smart contracts. This means that dapps may exist inside its highly secure environment.

What use are Bitcoin, Dogecoin, and Litecoin if to program their coins or use applications on them the software programs have to be hosted in centralized servers, corporate data centers, or cloud services?

In ETC, the backbone of dapps can be as trust minimized as the money, which makes ETC an incredibly unique and valuable system for truly secure applications and use cases.

## Known for Its Principle of Code Is Law

As mentioned in this article, the three pillars of Ethereum Classic are that it uses proof of work as its consensus mechanism, it has a fixed supply, and it supports smart contracts.

The three pillars in its design and structure make true the principle of Code Is Law because ETC is concretely and tangibly decentralized, immutable, and permissionless.

Because of these features, then ETC has the benefits of survivability, censorship resistance, unstoppability, and therefore is uncompromisable and uncapturable.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

Before the existence of Ethereum Classic, applications were stoppable. After the existence of Ethereum Classic, applications hosted inside it became unstoppable.

The reason for this is that the invention brought by Bitcoin, Nakamoto Consensus, solved the problem of peer-to-peer networks. The problem was that they could be disrupted with just one third of the participating nodes colluding to attack it.

Nakamoto Consensus raised this threshold to one half.

Not only that, but the proof of work in Nakamoto Consensus added even more barriers to just collusion. Proof of work meant that the colluding participants needed have the necessary computing power to create blocks faster than the rest of the computing base in the system.

Another barrier to attacking the network imposed by proof of work based Nakamoto Consensus was that the colluding attackers would have to consume enormous amounts electricity.

Before Nakamoto Consensus attackers only needed 33% of participating nodes to disrupt a network, and there was no need to have powerful computers nor to use any significant amount of electricity.

After Nakamoto Consensus, not only did they need to convince 51% of participants, but also needed to have an enormous computing base and burn enormous amounts of electricity to do it.

However, because of technical difficulties, Bitcoin does not host applications inside its highly secure environment. But, Ethereum Classic does.

This is what makes ETC so different and powerful.

Ethereum Classic has the technologies and systems that existed before; full transmission of the data and full replication of the database in all nodes of the peer-to-peer network; and it uses the first key innovation of Bitcoin; proof of work based Nakamoto Consensus; to keep the system coordinated and secure.

On top of this, ETC adds the second and only other major innovation that existed in the industry: Smart contracts.

In other words, Nakamoto Consensus and smart contracts are the only two innovations of the industry and Ethereum Classic has both.

The key to making applications in Ethereum Classic unstoppable is precisely that they are hosted inside its highly secure environment.

Smart contracts are software programs that power applications, and when they are sent to ETC they are retransmitted and replicated in all the nodes of the system. This makes these applications decentralized, hence their name “decentralized applications” or “dapps”.

The unstoppability of dapps is accomplished by this decentralization, because it produces resistance to censorship, permissionlessness, and immutability.

Decentralization is accomplished by the proof of work component of the system. Proof of work makes it very easy for all nodes in the network to know which is the correct chain of blocks just by checking whether the work was done.

This is because if imposters were to send alternative blocks without such work done, then it would be very easy to discard them. And, to build such large computing base to compete with the existing one is extremely difficult.

The same information of the proof of work that serves to reach consensus on the correct chain is also used to exit and re enter the chain, or to join the network for the first time. When any nodes want to join or re enter they only have to check which chain has the most work done to know, in their complete isolation, without checking with any other source in the universe, that that is the correct blockchain to join.

This ability to run Ethereum Classic nodes or miners, and to send transactions without any need to check with others, without any supervision, is what makes it censorship resistant and permissionless.

Immutability is accomplished by the sheer amounts of work and electricity needed to change or alter the blockchain.

Proof of work not only protects the data of the current block being processed, but also the whole history of the database.

In fact, the older a transaction or a dapp gets, the more difficult it is to alter it.

This is because any attacker would not only need to change the current block but the whole history of blocks, re doing all the work again and burning all the needed electricity again, to be able to make any changes to past transactions or dapps.

The only new inventions of the blockchain industry are Nakamoto Consensus and smart contracts, and both combined in Ethereum Classic produce unstoppable applications.

This is the revolutionary paradigm change in the world. Nothing more.

All the other gimmicks such as proof of stake, scalability, sharding of the database, and channels, which are hot buzzwords in the industry that only serve to suck the money of gullible investors and traders, already existed before and are widely used in centralized traditional industries.

The banking industry, for example, is a proof of stake system: There is a central authority that creates a protocol which says that to participate, banks need to make a deposit in the form of minimum capital.

Computational scalability already exists in the world with cloud services and large data centers that enable companies like Visa to process billions of transactions per day.

All this scalability in traditional systems is only accomplished with centralization: They all use sharding to break up the database so they can produce inputs and outputs faster and in parallel. They all use channels as all systems are layered, where the top layers handle large numbers of transactions and then accumulate and net out the results to send them to the lower layers.

This was all invented before and are hallmarks of centralized systems as they depend on trusted third parties to run them.

The only true innovation is the unstoppability of applications, and the only system that possesses that is Ethereum Classic.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

Design philosophies and principles are a big influence of how blockchains work. After the Ethereum (ETH) migration to proof of stake, which completely changed its security model, it seems appropriate to make a comparison of that system's and Ethereum Classic's (ETC) core philosophies.

Ethereum's philosophical model may be called "Social Consensus" and Ethereum Classic's "Code Is Law". In this post, we will explain and compare both.

We will write "Social Consensus" and "Code Is Law" with capital case when used as the names for the philosophies.

## Ethereum's Social Consensus

The terminology used by the Ethereum Foundation, ETH ecosystem, and community has varied with time. On different occasions, their set of principles has been referred to as "weak subjectivity", "social slashing", "social information", or "people: the last line of defense". However, the latest name used with more frequency to describe their views has been "Social Consensus", so we are going to use this term to explain their general philosophical position.

It is worth noting, though, that the term "weak subjectivity" is a sort of acknowledgement that using people's subjective opinions and voting to run a cryptocurrency network is a sort of misdeed, since they called it "weak" to try to give some reassurance.

Social Consensus advocates claim that proof of stake and subjective agreement between network node operators is more secure than Code Is Law blockchains which use proof of work. This is false as Social Consensus doesn't even provide a focal point for participants to join, leave, and rejoin the network. This focal point provided by the "most work done" rule in proof of work is the only way to make a blockchain permissionless, decentralized, and censorship resistant.

The best chain selection mode that Social Consensus philosophy can provide is "ask a friend" or check with block explorers or some other website on the internet.

This truly weak decision making process of Social Consensus and proof of stake stems from two beliefs they hold:
- That blockchain consensus is a human process, not a mechanical physical process.
- That humans are pretty good at achieving consensus in the long run.

As Social Consensus has these principles as its core beliefs, blockchains are built and used only for automation and scalability. Just as computers and software programs in traditional centralized systems, for them, blockchains are just mere practical tools.

This focus on humans as sources of safety makes Social Consensus proponents believe that proof of stake and proof of work can each ultimately be overpowered by state actors indifferently. For them, both systems are equally vulnerable, therefore whether they have human intervention as an embedded design feature is irrelevant.

Again, Social Consensus emphasizes that communities are good at consensus.

Because Social Consensus believes in human agency, then it also believes in very human methods. This leads to the erroneous conclusion that proof of work is actually weaker because it incentivizes block producers only with rewards; that proof of stake does this with rewards and penalties, therefore, it must be more complete as an economic mechanism.

Social Consensus proponents focus a lot on what they call efficiency, but their definition of efficiency is whether block producers and validators have to be paid more or less to participate in the network. The measurement of efficiency they use is to calculate the total amount of capital locked for producing blocks, multiplied by the total rewards needed to pay for this capital, multiplied by how much time such capital is locked. The claim is that because proof of stake demands less of these metrics, then it must be more efficient.

The above is not only based upon a bad definition of efficiency, but it also shows a lack of understanding of the economic implications of the different models. If proof of stake validators require a lower reward, thus a lower return on investment (ROI), it is because their role in the system has significantly less risk for them as they do not actually sink capital to recover it in the distant future with uncertainty. Proof of work miners make enormous commitments of capital that they sink into hardware, data centers, human resources, and electricity with the expectation that they will recover their investment with a reasonable ROI in the long term.

Social Consensus has nearly zero marginal cost and risk. Proof of work requires risk taking, competitive merit, and sunk capital.

And this is where they are confused. Proof of work is purposely costly and unscalable computationally precisely to guarantee the benefits of decentralization, which is correctly measured by its social scalability: Anyone in the world may use a Code Is Law blockchain. Only a subset of the world may use Social Consensus networks.

Another deep misunderstanding held by Social Consensus supporters is that they believe that proof of work is centralized through mining pools and ASIC computing. This kind of thinking is incomprehensible at this point because after 14 years of operation of Bitcoin, and 7 years of Ethereum as a proof of work chain until the migration to proof of stake, neither chain has ever been centralized or captured by mining pools, mining firms, ASIC producers, or any other kind of agent.

To the contrary, proof of stake, with its Social Consensus philosophy, was captured from the start when Ethereum migrated to that system as more than 70% of its blocks are censored on behalf of government agencies due to international sanctions policies.

One of the strongest (and most erroneous) arguments in Social Consensus philosophy is that blockchains are technological and social designs where their safety is sourced from cryptography, economics, and social agreement. This leaves out the most important invention of Bitcoin, and the only reason why the whole industry actually exists: Nakamoto Consensus.

Nakamoto Consensus is based on proof of work and can only be based on proof of work because it is the only way to assure the consensus of machines owned by strangers, spread across the world, who don't talk to each other, have no reason to trust each other, and who, in their complete isolation and without consulting anyone, reach absolute consensus on the state of the system every 10 minutes in the case of Bitcoin and every 15 seconds in the case of Ethereum Classic.

Cryptography, economics, and social agreement are just marginal tools and methods used to implement the system, they are not the keys to the design and its security.

It was the enormous amount of electricity needed, the enormous amount of computational power required, the difficulty adjustment, and the importation of this information from the real physical world into the system that was the revolutionary solution to the problem of consensus and safety in the network.

Social Consensus' lack of acknowledgment of this truth and its naive refocusing on human virtue as a security measure is the major flaw of that philosophy.

This flaw fosters a belief in several falsehoods, one of which is that a blockchain is a sort of "crypto-economic organism" or some sort of righteous organization of people who will always be good for the world.

Social Consensus focuses on economics and virtue rather than physics and energy.

Social Consensus glorifies "the community", considers it the security of last resort, and believes that human voluntary agreement is what ultimately protects the accounts, property, dapps, and contracts inside a blockchain.

We would argue that a Social Consensus network is not even a blockchain. Blocks are defined as batches of data that have to be sealed with a proof of work hash that must cost block producers enormous amounts of capital and energy.

The ultimate purpose of Social Consensus is to protect the planet, to do no harm to the environment, and to heal the climate. The whole reason for the existence of Bitcoin, Ethereum Classic and other true blockchains is human flourishing through trust minimization.

Indeed, proof of work actually helps the environment as an externality much more than proof of stake because renewable energy is cheaper than fossil fuel electricity, and miners are constantly seeking to lower their costs so they naturally move to renewable energy sources, providing cash flow to that segment of the industry and promoting its growth.

As Social Consensus believes in human agency, but human agency is prone to cheating, then penalties through slashing are required. Also, forks to reverse the chain, confiscate funds, slash bad actors, and change the history of the chain by majority voting are perfectly fine in that philosophy. If trust in intermediaries and human intervention were never the problem, then why was "trust minimization" even a concern?

Of course, Social Consensus has very little awareness of the perils that such actions and interventions will bring. It is unlikely that any actor in the network that is slashed by social consensus will passively accept a significant loss of their capital without a fight. Lawsuits and legal bureaucracy will be the name of the game in the Social Consensus world.

In Social Consensus philosophy, "finality" is defined as a 66% vote of validators. This seems to be strong to the naive eye, but it is just a mirage. It really means that with only 33% of bad actors, the network may be disrupted. This has been the vulnerability that has existed in computing networks since they were invented.

To describe finality as a vote, is like saying that finality can be decreed by law or by a government. It is precisely because this is not true that Satoshi Nakamoto invented Bitcoin, Ethereum Classic exists, and Cypherpunks had been working on these technologies for decades.

However, people are the last defense for Social Consensus advocates, governance is paramount as an emergency response, and TheDAO hard fork is regarded as an accomplishment.

## Ethereum Classic's Code Is Law

In Ethereum Classic the term "Code Is Law" has been unequivocal, unambiguous, determined, and clear since the day that Ethereum split from the original blockchain on July 20th of 2016 on block 1,920,000.

Code Is Law is as inextricably linked to proof of work as Social Consensus must escape it. Proof of work is the most secure consensus mechanism known to humankind for reaching consensus on the state of a peer to peer network.

Code Is Law is a principles first philosophy, all the rest comes after.

Code Is law means unstoppability, no downtime, censorship resistance, and the thorough minimization of the influence of third parties. These features are the only ones that can guarantee that the network will not be captured or influenced by special interests.

Code Is Law advocates believe in freedom from censorship, immutability, and that decentralized applications must run exactly as programmed.

Immutability, decentralization, and complete neutrality, which means no intervention by supposedly virtuous humans, is the only way to guarantee zero discrimination against anyone. Code Is Law beliefs include pseudo-anonymity, decentralization, a rejection of decisions by voting, and a rejection of irregular state changes to the network.

Code Is Law philosophy has the knowledge at its root that superficial things like funds recoveries, returns to legitimate owners, and other on-chain manual interventions are wrong, not right. And they are wrong because nothing guarantees that such human interventions will not be used against the capital, applications, and transactions of users.

For Code Is Law to be true, and it is true in ETC, the ledger must be inviolable and immutable. "The greater good" in Social Consensus is a false promise, it is actually completely opposite to the safety of the property, agreements, and transactions of individuals.

Proof of work is the only mechanism known to man that guarantees permissionlessness, decentralization, censorship resistance, and immutability. And, these features guarantee no discrimination against any nationality, culture, creed, politics, race, or human condition.

Where Social Consensus believes "people are good" Code Is Law believes "people are the problem we were trying to solve in the first place!"

Code Is Law means trust minimization and that Ethereum Classic cannot be shut down or intervened. This has been proven multiple times in its history. Forks are only to fix bugs or make necessary upgrades. Nothing more.

If Social Consensus were used for any kind of "good" change, then what prevents it to be used for any change. The only solution is no social consensus. Thus, Code Is Law.

Code Is Law means no change and the sanctity of the ledger. Anyone, anywhere in the world, even refrigerators, can use ETC. This is only possible with complete neutrality, and neutrality is only possible with true immutability. "Governance" doesn't even exist in Code Is Law. This is why neither ETC nor Bitcoin have foundations or leaders.

Code Is law is about rough consensus, which is free adoption, free and unlimited participation, and no tyranny of the elites or voting majorities. This makes the blockchain antifragile.

Code Is Law does not mean it supports crooks and thieves. Indeed, the worst crooks and thieves are actually kept out of it! And, the petty ones can be dealt with through the normal and time tested channels of legal systems and law enforcement.

Code Is Law is on the blockchain. Executions and transactions are final and immutable. It has nothing to do with human law. It is like the laws of physics.

The communities of Ethereum, Bitcoin, or Ethereum Classic cannot have the knowledge or capability for dealing with the disputes of billions of people worldwide. There is no such thing as blockchain justice. The resolution of these things must be carried out outside of the blockchain.

The only answer is neutrality, therefore the Code Is Law philosophy.

### Sources:

### Ethereum Social Consensus ideas and writings:
- Proof of Stake: How I Learned to Love Weak Subjectivity: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity
- Proof of Stake Design Philosophy: https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51
- What Is Social Coordination and Why It Is Needed: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/faqs/#what-is-social-coordination
- People: The Last Line of Defense: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/attack-and-defense/#people-the-last-line-of-defense

### Ethereum Classic foundational documents:
- The Ethereum Classic Declaration of Independence: https://ethereumclassic.org/ETCDeclarationof_Independence.pdf
- Code is Law and the Quest for Justice: https://ethereumclassic.org/blog/2016-09-09-code-is-law
- A Crypto-Decentralist Manifesto: https://ethereumclassic.org/blog/2016-07-11-crypto-decentralist-manifesto
- Code is Law - Ethereum Classic community website: https://ethereumclassic.org/why-classic/code-is-law

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

Immutability in Ethereum Classic (ETC) means that accounts, balances and smart contracts cannot be modified except by holders of corresponding private keys by entering transactions according to protocol rules.

Immutability and backward compatibility are like two sides of the same coin: Immutability is a feature in space and time, but looking forward, as it promises that things that are done today should not be modified by third parties in the future. Backward compatibility is also a feature in space and time, but looking backward, as it promises that third parties should not break today what users have done in the past.

Space relates to place and geography. It means that anyone, anywhere in the world, should be able to have access permissionlessly and without censorship to their money, smart contracts, and dapps. Time means that accounts, balances, transactions, and dapps entered in the present or the past should be immutable and no changes of the protocol in the future should break them or stop them from working.

Both immutability and backward compatibility are related to the principle of Code Is Law in ETC in that decentralized applications (dapps) should always work as intended and designed, forever.

Thus, immutability and backward compatibility have the same underlying goal: No change.

No change means reduced chances of manipulation and also guarantees that the flow of economic transactions between people and businesses will continue uninterrupted. All this contributes to the reliability of the system on a global scale for a long time.

The problem that the principle of backward compatibility addresses specifically is that when making changes through hard forks, implementing upgrades and fixing things as time passes by, sometimes existing smart contracts break rendering them unusable.

This is a very serious problem.

Imagine applications, agreements, benefactors and beneficiaries depending on continuous streams of cash flows on a highly secure and decentralized system as Ethereum Classic, but when an upgrade is made, then the code powering such affairs breaks and stops working.

From a safety perspective, future upgrades that break backward compatibility are security holes as they may be used as stealth attack vectors, disguised as upgrades and bug fixes, but that really break things. This vulnerability reduces the finality of accounts, balances, transactions, and decentralized applications as the upgrades themselves may be leveraged by bad actors to change or stop things from working.

The use cases that need backward compatibility are decentralized applications, contracts, and agreements that should work for a long time. And "long time" here means decades or even centuries.

Examples of these use cases may be long term publicly traded bonds and debt obligations; long term business contracts and cash flows; legal persons and partnerships represented as DAOs on the blockchain; property registries; bilateral agreements between nations; university, hospital, and other types of endowments; church funds; national treasuries with complex administrative rules; long standing charities; family trusts; inheritance contracts and wills; and even plain and simple multisignature wallets.

Fortunately, there are several efforts in the Ethereum Virtual Machine (EVM) segment of the blockchain industry, where Ethereum Classic is a major player, that have as an objective ensuring long term and reliable backward compatibility.

All these ideas usually revolve around creating versions of the blockchain components to be upgraded and then making smart contracts, accounts, and dapps work with their corresponding versions, regardless of when they were deployed.

Some of the ideas being debated are:

EVM versioning: Setting and identifying a version of the EVM every time there is a change or upgrade so that accounts and smart contracts can use that version. Then, all the future versions of the EVM will be included in the protocol and node software clients so they can be perpetuated in time.

Account versioning: Creating account versions and formats for regular and smart contract accounts that are related to specific EVM versions so they can call that EVM version each time they need to be executed. As all future EVM versions will be hosted on the blockchain, then no accounts or smart contracts would break if these features were added.

EVM Object Format (EOF) upgrade: Similar ideas as the above, and others related to them, are being worked on and tested, and will likely be included in an upgrade, called EOF, that will greatly improve backward compatibility in EVM standard blockchains such as ETC.

Backward compatibility is a very high priority in ETC so any innovation or upgrades that enhance this guarantee will very likely be adopted by the ecosystem.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

The first problem with the concept of security is that it is the absence of something. This makes it difficult for the great majority of people to feel or reason about, especially those living in advanced nations.

If we want a detailed explanation of security, we could say that it is "the absence of hazards which increase the risk of perils that could cause loss". This may be simplified to the phrase "the absence of danger".

The second problem with the concept of security is that for many things; especially matters of money, wealth, information, and contracts; the key to achieving it is to actually eliminate human agency. The great majority of people believe that the more "good people" are in charge the more secure things are. We are conditioned to think that people create security when in reality people are the most common source of insecurity.

The third problem with the concept of security is that it is viewed differently in different cultures and regions. As mentioned above, the lack of true danger in advanced societies means that the great majority of individuals and organizations using blockchains do so for superficial purposes which normally range between trading and making money to the excitement of technological innovation.

The above leads people to do stupid things such as creating more and more proof of stake and proof of authority blockchains that are worth hundreds of billions of dollars but are useless in terms of the true promise of the blockchain: the absence of danger.

Only a fraction of users in the world are using blockchains and Ethereum Classic for their true value of security.

However, everything will change because the world will be a dark place very soon.

The forces of centralism are strong and will get stronger in an accelerating technologically driven world:
- Censorship is already spreading and will become rampant. Even our thoughts will be produced and controlled by the state, if not by a global government.
- Social credit scores and id's will eliminate our privacy and render us naked in front of the global empire.
- Control of behavior through biased AI agents will be more prevalent than individual sovereignty and representative governance. Indeed, the guise of representation will continue to exist, but for what use if our vote will be decided by the central controller?
- Disinformation will be only produced by official sources (supposed conspiracy theories and subversive information sources will become the new truth).
- In essence, there will be straight central manipulation of entire societies.
- The name of the game will be the stripping of wealth through direct means such as taxes and indirect means such as inflation (i.e. Modern Monetary Theory).

Then, the current traders and investment opportunists will see that they are truly naked and will change their focus to security. And, those playing with their little proof of stake and proof of authority toys of innovation, in their pompous university labs, will fail miserably and re-focus their projects to the presently abstract concept of security.

Because security will not be abstract anymore, it will be very tangible and real.

So, the meaning of security in Ethereum Classic will be this: It will be a refuge for those escaping centralization on a global scale, arbitrary confiscation, persecution, and tyranny.

ETC will be a real life instrument of Life, Liberty, and Property. Not just a written text on an old piece of parchment with fancy signatures.

This is when Ethereum Classic will shine as a shield for the world; a shield against the beast of globalization. Suddenly, everybody will want to escape the overlord.

ETC is a haven of basic rights. Basic rights are represented in it by means of a fully replicated ledger with accounts, balances, assets, programs, and smart contracts which crosses all borders and reaches everyone in the world regardless of their country, culture, ideology, beliefs, gender, race, or any other human condition.

People who believe in human agency think of finality and immutability as the result of human decision-making. For example, in proof of stake systems, they believe that a two-thirds vote by the block validators produces finality as if people were the guarantors of last resort. This makes proof of stake only suitable to protect people's wealth and applications from what may be called unauthorized theft.

However, when it comes to authorized theft, the arbitrary over-taxation, confiscation, censorship, limitation, or elimination of people's Life, Liberty, and Property by tyrannical law, then proof of stake advocates are either absolutely compliant or totally in favor of such situations.

Ethereum Classic security is true because it is a sanctuary against any kind of theft.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

Bitcoin (BTC) was launched in January of 2009 and has been working uncensored ever since.

Ethereum Classic (ETC) has been working since July of 2015 and it has never been censored to this day.

When Ethereum (ETH) migrated to proof of stake (PoS) in September of 2022, it was censored immediately.

Why is this?

The reason is that Ethereum Classic uses proof of work (PoW) based Nakamoto Consensus and Ethereum uses proof of stake as its consensus mechanism.

To be fair, if all block producers (miners or stakers/validators) in any of these systems were to be captured by governments or agreed on a censorship strategy, then both proof of work and proof of stake consensus systems would be censored.

But, what makes ETC's proof of work more resistant to these problems?

The answer is a series of features that differentiate PoW from PoS. In essence, it is much easier to group and capture stakers in a proof of stake system than miners in a proof of work system.

To begin with, the economics of proof of stake consensus in Ethereum have made it practically impossible for small stakers to produce and validate blocks independently. To run your own validator node, you need to deposit 32 ETH in an account (more than $52,000 at the time of this writing) and install complex infrastructure that requires two Ethereum nodes: an execution layer (EL) client and a consensus layer (CL) client.

In addition to this, proof of stake in Ethereum imposes penalties for as trivial things as being offline to more serious offenses as proposing invalid blocks. This makes it a financially dangerous endeavor to run nodes, risking your capital if you don't have a large and professional operation managing a sophisticated data center that is available and correct all the time.

For the above reasons, Ethereum block production and validation is largely performed through staking pools.

This by itself wouldn't be such a bad problem. After all, ETC mining is also largely channeled through mining pools. The problem is that, because of proof of stake's design, pools are organized in ways that foster much more centralization and capture than in proof of work networks.

In proof of stake pools, the staking capital is actually separated from the validators, also called node operators (NOs).

This means that there may be hundreds of thousands of individuals who stake their ETH in small amounts through pools, but they don't actually run any machine or software to validate or produce blocks. They just receive stake tokens representing the ETH that they deposited. Aside from that, they delegate 100% of the responsibility and operation to the staking pools.

Then, the staking pools usually do one of two things, they either run their own node operation in professional data centers, or they hire in the open market a set of controlled node operators.

These two models are well represented by centralized crypto exchanges, such as Coinbase, Kraken, and Binance; who take staking deposits from their clients and then run their own validator nodes; and Liquid Staking Derivatives (LSD) pools, such as Lido and RocketPool; who take deposits from their users through smart contracts on Ethereum and then hire a set of NOs who run the machines with the EL and CL clients and receive the staking deposits from the pools, sharing the earnings.

Note: Kraken has actually closed its staking services due to regulatory [controls and capture]() as we write this post, confirming our hypothesis in real time! Further down we comment on the effects of these events.

In both cases (the centralized crypto exchanges and the LSD pools) there is already some sort of filtering and censorship just to participate.

In the case of the centralized crypto exchanges, they filter who may stake or not by using the traditional know your customer (KYC) and anti-money laundering (AML) rules from the countries where they operate. In other words, staking through these services is not permissionless nor censorship resistant. Stakers need to actually show them their passports and prove they are a good citizens to be able to stake through them.

In the case of the LSD pools, they don't filter who may stake, as that is done through smart contracts on Ethereum, so anyone may make a deposit, but they filter and censor who can run validator nodes and be their NOs.

This is done through a selection process through a "sub-governance group" and then by voting the final candidates through a DAO, in the case of Lido, or through an algorithm, where they constantly filter who are the most profitable NOs to allocate the staked ETH and reject all the others, in the case of RocketPool.

The fact that regulated and centralized exchanges have a large share of pooled stake deposits is already a source of capture and censorship in Ethereum's proof of stake consensus system, but that the pools that are supposed to be "decentralized" actually control who may be the NOs is an additional source of centralization and thus of eventual censorship and cartelization as expressed even by the Ethereum Foundation.

Once we understand the huge flaw that is the risk of centralization described above in proof of stake networks, then we can list a host of additional centralization vectors and drivers that are already causing the current high rate of block censorship in Ethereum, and will likely bring all sorts of additional capture problems in the future that will never be present in proof of work blockchains as ETC.

Staking pools and node operators/validators are static and easy to find: Staking in Ethereum PoS requires static accounts on the network, therefore it is easy to track and find NOs and to which pools they work for. If to this we add that they are dependent hired contractors by the pools, or that the pools are themselves the NOs in the case of centralized exchanges, then we can see that they are easy to capture and control by special interests and abusive government regulation. In ETC, mining is a process of deploying capital in large data centers, purchasing enormous amounts electricity, working hard to win blocks by merit, and miners and pools may use different accounts on a block by block basis. This is done all over the world as cheap electricity generation resources are naturally distributed around the globe, creating diseconomies of scale. Mining pools are consequently also distributed around the world, there has been historically and empirically a significant rotation of players in the industry, and neither mining nor mining pools have ever held dominant or controlling positions in the market.

Staking pools take deposits that are securities: As we mentioned above, the Securities and Exchange Commission in the United States has decided that staking deposits in exchanges are securities, therefore completely subject to government regulation. It is a matter of time until the LSDs are also included in this definition. Therefore, all staking will be subject to regulation, thus additional capture and censorship. In ETC's proof of work, mining is not done by depositing money that may be interpreted as a security, nor are mining pools or mining operations considered financial services, but just plain computing warehouses and data centers.

Staking pools and node operators are inside the ledger: Many idealist Ethereum insiders and developers say that they will appeal to Social Consensus if staking pools behave badly by increasing censorship and imposing restrictions to permissionlessness. This is a very difficult task to achieve because when a set of exchanges and LSD pools capture the network with their cartelized stakers and NOs they will be planted inside the blockchain itself in the form of the staking validator accounts and the smart contracts that fund those deposits. This means that the action of last resort that proof of work blockchains have, to make a protocol change and fork away from the attackers, is impossible because the whole block producing industry is inside the ledger. In ETC's proof of work, miners import energy into the blockchain in the form of block hashes, this is done externally and they have no say and may be easily replaced if the ecosystem forks away from them with a different mining algorithm. Because of this possible action of last resort, in proof of work, miners are humbly submitted to the rest of the ecosystem, not the other way around.

Staking pools will all be regulated financial institutions: As seen with the growth and market share of centralized exchanges in the staking pool business, and now that the SEC has defined such business as a security, we can now more clearly observe that financial institutions are going to be the main stakers, node operators, and pool operators in Ethereum proof of stake. There will be no other kind of business or institution that will be allowed to manage staking pools and validation operations. It will be very difficult for Lido, RocketPool, and the other "decentralized" pools to not be either forced to shut down, taken over by regulated financial institutions, or just lose market share because of the strong competition in capital and distribution. This will turn Ethereum, and any proof of stake system for that matter, into a hyper-regulated traditional financial system.

Staking pools suffer unrestricted economies of scale: Just as the banking system, the staking industry will be dominated by 3 or 4 cartelized entities. This is because capital inside Ethereum may flow with no local or real world restrictions. These economies of scale will favor a few large centralized pools, managed by financial institutions, who will be able to negotiate lower fees with NOs, always have more capital for marketing and distribution, and present the best solvency guarantees to their stake depositors, all this reinforcing their cartelization. This makes it much easier than in proof of work to concentrate capital and thus control of the network. Once pools achieve large scales, they will be even more capturable in any jurisdiction. As mentioned before, to the contrary, proof of work has diseconomies of scale because it will always have local political constraints for the size of its physical operations and energy use, cheap electricity generation is naturally distributed around the globe, pools actually do not control block production, eand the industry has been constantly rotating its players since 2009.

Staking pools and validators must be online all the time: The fact that the design of proof of stake has many restrictions that ETC's proof of work does not, such as locked deposits, liveness penalties, and slashing, makes it very difficult to exit the system to relocate or hide in case of legal changes or geopolitical problems. When China suddenly prohibited Bitcoin mining in 2021, the majority of the hashrate moved to new locations, such as Kazakhstan, Paraguay, and Canada, in a matter of weeks. Not only that, but currently, even with the sanctions still in place, China has re-emerged as a leading BTC hashrate player with nearly 20% share, proving that miners can fly under the radar. This is the case with ETC as well. But, once proof of stake validator infrastructure is in place, it is very difficult and costly to exit, move, hide, and re-enter the network whenever needed. This locks down pools and validators forcing them to comply with whatever jurisdictions they are dealing with.

In proof of stake, there is no alternative to centralized and captured pools: Once the staking pool industry is centralized, there is no recourse by Ethereum users to enter transactions that could eventually be processed by some staker outside of the dominating cartels. For the reasons stated above, the pooling cartel in proof of stake will necessarily have nearly 100% control of the system. In ETC's proof of work, because entry and exit is truly permissionless, there are no penalties, and the mining base may be anywhere in the world, then there will always be a set of miners with sufficient share that will gladly earn the fees for transactions that may not be processed by cartelized and censoring pools. Indeed, these pools and miners will actually always have a significant market share because they will consistently earn more than the censored ones, enabling them to invest in ever growing infrastructure and electricity, thus outcompeting their captured peers. In proof of stake, special interest capture is a benefit, in proof of work it is a serious disadvantage.

Proof of stake does not have the decentralization guarantees that proof of work has: Proof of work guarantees that miners and mining pools may change all the time, migrate from place to place, and exit and enter the network whenever they please because it has the two guarantees that proof of stake does not have: It enables consensus without having to check with anyone in the world except by just verifying the proof of work in the latest block, and it enables free entry and exit without having to check with anyone in the world except by just checking the most work done on the network. Proof of stake is a system where stakers, pools, and validators are locked in their places and easy to capture and censor due it its design restrictions as described above, and it doesn't provide the permissionless chain selection focal point that proof of work does. This shows how different both systems are and that proof of work was the real invention of the blockchain industry. Proof of stake is just the traditional centralized banking system but reframed to make it look decentralized.

Nick Szabo's essay "Trusted Third Parties are Security Holes" explained why trusted third parties were hazards that increased the risk to networks and computing systems. This created incentives so that people like Satoshi Nakamoto and Hal Finney) could build decentralized peer-to-peer systems, and POW has been the best invention to solve this problem.

However, the reverse incentives will likely occur with Ethereum's proof of stake: As they continue building the system by adding fixes and patches to close the myriad of security holes that it has, they will end up with a set of centralized validators, just like banking, and the only difference will be that the database will be completely replicated among these validators.

Then, when these cartelized pools and node operators realize that they may trust each other because they know each other, have the same special interests, and are all buddies in the same state sponsored regulatory framework, then one day they will say to themselves "why do we replicate the data in public nodes, locking so much capital in staking, if we can reduce costs and be more efficient just by using our own data centers and cloud services?".

This is when the world will realize that proof of stake was just a slow, tedious, and complexity-obfuscated way of re-building a new centralized banking system, bit by bit, without anyone noticing.

Thus, in the end, their glorified "cryptoeconomic" pseudoscience will drive the system to total centralization.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

## The Howey Test

To determine whether a unit of value, contract, or transaction is a security the U.S. Securities and Exchange Commission (SEC) uses what is called the Howey test, which was the basis for a ruling by the Supreme Court in 1946 that defined what is a security.

Under the test, a unit of value, contract, or transaction qualifies as a security if it has the following elements:
1. An investment of money
2. In a common enterprise
3. A reasonable expectation of profit
4. Derived from the efforts of others

Bitcoin (BTC) and Ethereum (ETH), and thus Ethereum Classic (ETC) after Ethereum split from it in 2016, were determined to be commodities by the Commodity Futures Trading Commission (CFTC) in 2015 because they were decentralized, therefore had no common enterprise directing them and their returns were not derived from the efforts of others.

The question is whether Ethereum, now under its proof of stake (PoS) consensus mechanism, still qualifies as a commodity.

## Comparing ETC and ETH Using the Howey Test

The table above serves to compare ETH and ETC as to how they fare with regards to the Howey test.

As seen in the table, in our opinion Ethereum now passes the test, therefore should be categorized as a security, because it involves all four elements while ETC is still a decentralized project so it should remain a commodity.

In the following sections we explain our comparison and rationale.

### 1. An Investment of Money:

In the first element of the Howey test, it is clear that both ETH and ETC are an investment of money in a unit of value. Many people use both cryptocurrencies just as way to pay for things, thus as units of exchange rather than as investments, but for many others they are stores of value and ways of trading in the market for profit.

### 2. In a common enterprise:

Since its migration to proof of stake in September of 2022, ETH is a common enterprise because proof of stake is centralized. The model uses capital instead of proof of work based mining to determine who produces blocks. This makes the staking business have strong economies of scale which inexorably concentrate the industry into very few and entrenched staking pools.

These pools may filter who may stake and/or who may be part of their validator set, or may be the node operators themselves who validate blocks and transactions.

These few entities will remain mostly static. Seldom will any rotate away from the industry because of the moat inherent to their business models. They will act in conjunction with the Ethereum Foundation and, coordinating together, will clearly form a common enterprise directing the future of the system.

This level of centralization in Ethereum combined with the lack of cryptographic stamps when producing blocks without proof of work completely eliminates the chain selection point, thus nullifying the attributes of free exit and entry, permissionlessness, censorship resistance, and immutability without which Ethereum becomes a common enterprise with traditional centralized features and controls.

Ethereum Classic, however, remains a commodity because it uses and will continue to use the decentralized proof of work method of consensus for the foreseeable future.

Therefore, there are not and can never be enterprises or groups that control ETC. Mining the coin and owning the coin will always be totally separate activities.

ETC has no foundation directing the roadmap of the system. Producing or verifying blocks are free, decentralized, and merit-based activities.

### 3. A reasonable expectation of profit:

As said before, although both ETH and ETC may be used purely as units of exchange, they may also be used as a store of value for price appreciation, therefore both qualify as having a reasonable expectation of profit.

### 4. Derived from the efforts of others:

For the same reasons that Ethereum is now a common enterprise, it is also a system where the expectation of the success of the system, and thus its future profits, are derived from the efforts of others.

These “others” are easily identifiable as they will be the four or five large staking pools and the Ethereum Foundation who, all together, will act as a single enterprise.

The proof of stake system used by ETH is not a free merit system like that found in systems using proof of work. It is, rather, a collaborative relationship wherein the validators are not equal, independent free actors because they are essentially contractors subordinate to the pools.

In the ETH system, validators divide their tasks on a per-block basis where one produces a block, then sends it to the other validators who vote on the block, then send it to the rest of the network who must accept it without objection.

Because ETC uses proof of work and is, therefore, decentralized, miners may pop up or leave whenever they want from anywhere in the world, compete to build blocks in complete isolation, send blocks produced to the rest of the network for verification, and get paid based on their sole merit. No other filters or conditions exist.

For ETC, the same reasons why it was deemed a commodity in 2015 remain valid today: There is no common enterprise, therefore the future value of the token is solely dependent upon future general adoption by the market, not by the activities of a defined collaborative group of centralized operators or managers as is now the case with Ethereum.

## A Historical Perspective of ETC’s and ETH’s Legal Status

From 2014 to 2016 both Ethereum and Ethereum Classic were one project, so we refer to them in this period as ETH/ETC.

The project was financed with a crowdsale. Based on the Howey test, it may be inferred that the ETH/ETC crowdsale was, indeed, a security.

It was founded by Vitalik Buterin; then he partnered with several individuals to form a group of co-founders; they promised the expectation of profits out of the investment; created a foundation with the name of the network, even registering its trademarks; sold a unit of value previous to the creation of the cryptocurrency to gather funds for development; and promoted the crowdsale and Ethereum’s features, benefits, and appreciation potential just like any initial public offering of a stock would have been promoted.

However, this status as a security was likely limited to the period between the crowdsale and the launch of the network on July 30th of 2015.

On July 30th of 2015, the initial securities of the project were transformed into the ETH cryptocurrency, which was subsequently categorized as a commodity by the CFTC.

This step may be interpreted to be an exchange and exit of the initial common enterprise between investors, Vitalik Buterin, his partners, and the Ethereum Foundation as the director of the project.

From there, the project became a truly decentralized, proof of work based, public blockchain.

Even after Ethereum split from the ETC mainnet in 2016 due to the TheDAO hard fork, ETH kept its decentralization because it remained a proof of work blockchain.

This period lasted until September 15th of 2022.

Beginning September 15th of 2022, Ethereum cannot be described as a decentralized project because it migrated to Proof of Stake. Indeed, the moment it migrated, 51% of the blocks were censored by mega-staking pools to comply with international sanctions imposed by the U.S. Office of Foreign Assets Control (OFAC). A few months later, up to 70% of its blocks were censored.

As said before, PoS depends on large and entrenched pool operators that control the network. This, together with the control and influence that the Ethereum Foundation had from before, and the fact that the developers have incredible clout in the decisions about the protocol (for example, changing the supply of the token 6 times in its history) make it a centralized project dependent on others from the units’ of value perspective.

In the meantime, Bitcoin has always maintained its status as a commodity as determined by the CFTC in 2015. ETC is functionally a commodity, just like BTC, because it has exactly the same consensus design with its decentralist guarantees.

## Conclusion

It is worth noting that anything built on top of Ethereum Classic may be a commodity or a security. As a generalized and decentralized computing system, whatever the designs of dapps, layer 2 systems, and tokens may be will determine their status.

DAOs inside ETC structured as corporate stock, bonds, or derivatives will be securities. ERC-20 tokens that create coins, meme coins, or other tokens that don’t fall under the Howey test may be classified as commodities.

However, ETC as the base layer of these technologies is still a generic commodity.

The proof of stake algorithm in Ethereum implies a constant collaboration between validators, who are contractors of the pool operators. They produce blocks, vote on these blocks, and then send them to the rest of the network who have to accept them without question.

Additionally, participation by stakers from the public or node operators to run validating clients is filtered and restricted by pool operators. There is no decentralized free entry and exit from the system, therefore it is clearly a common enterprise.

ETH/ETC went through a centralized sale process when it was promoted during the crowdfunding, but then it became a decentralized blockchain when it was launched and was a proof of work system.

When ETH split from the ETC mainnet in 2016, ETC was separated from the main community of developers and leaders of the Ethereum Foundation and became even more decentralized at the social layer. This is when its Code Is Law principle was established.

ETC never had a defined group of promoters. In fact, all the different groups of constituents in ETC rotate and migrate constantly.

For all the reasons stated above, we conclude that Ethereum Classic remains a commodity while Ethereum has reverted to being a security.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

## What Is Trust Minimization?

A common misconception in the blockchain industry is that these systems are “trustless”, but this is not the correct term nor definition.

The truth is that blockchains such as Ethereum Classic (ETC) are “trust minimized” because there is still some dependency on third parties, and this is precisely why the focus should be on keeping it this way.

This dependency we are talking about may be illustrated by giving 6 examples:

1. Dependency on miners: Miners receive transactions from the network, hash them using enormous amounts of computational power and electricity, and then send the blocks to the rest of the network to include them in the blockchain. This means the network depends on the miner base to guarantee its security.

2. Dependency on verification nodes: When blocks are sent by miners to the rest of the network, then verification nodes get the new blocks and verify them. Once verified, blocks are included in the blockchain and the reward is deposited in the miner’s account. This establishes a dependency by regular users and miners on verifiers to keep the integrity of the data, to not include false information or transactions, and to get paid in the case of miners.

3. Storage of the replicated database: The blockchain itself is a giant database. Verification nodes not only verify, but also store the blockchain to keep the history for daily use, security, and for posterity. This is a huge dependency that the world has on node operators because the fully replicated database in all machines in the network is one of the keys to its security, which is maximized redundancy of the data.

4. Transaction and block distribution: For full replication of the database to exist, there has to be a distribution process of the transactions and blocks across all nodes globally. This is achieved by having all participating machines receive all transactions and all blocks and then re-send them to all other nodes. This is a dependency for participants and external users as this function would not be possible if it were not for the collaborative effort of all nodes.

5. Bootstrapping nodes: To be able to join the network for the first time or to connect again after being offline, each network software client has a list of bootstrapping nodes who are there to receive new entrants and to send them all the blocks of the database so they may synchronize and be part of it. This is a dependency on others to be able to join, and re-enter, and to be able to synch the history of the blockchain.

6. Core developers: Core developers are computer scientists and engineers who do research and development for upgrades and fix bugs that the system may have from time to time. They also act immediately on emergencies in case there is a split of the network or an attack that must be prevented. This is seldom the case, but it has happened even on the best and largest blockchains. This is a dependency on developers for these tasks.

So, if these dependencies exist, then why are blockchains considered trust minimized and secure?

The key to trust minimization is to distribute these dependencies amongst many third parties who may perform them indistinctly and interchangeably.

From miners, to node operators, to developers, the way Ethereum Classic is designed is that none of these constituents are individually indispensable nor irreplaceable.

Any miner in the world may join and leave the network whenever they want, any node operator may do the same, and core developers are several professionals from different regions, and anyone in the world may check and learn the code of ETC and work on it because it is an open source project.

At the operating network layer, the way of achieving this level of global distribution among many miners and verifying nodes is by using the proof of work based consensus mechanism because it is the only system that provides a permissionless point of entry and exit, which is the cryptographic stamp in each block.

## Satoshi Nakamoto’s Focus on Trust Minimization

As an example of how important trust minimization is, and how it had been the central goal of Cypherpunks when building systems, Satoshi Nakamoto mentioned trust minimization directly or indirectly 14 times in the Bitcoin white paper.

Mention of trust minimization in the abstract:

- A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.

In the introduction:

- Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments.

- While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model.

- With the possibility of reversal, the need for trust spreads.

- These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.

- What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.

In the Transactions section:

- A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending.

- After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent.

- To accomplish this without a trusted party, transactions must be publicly announced, and we need a system for participants to agree on a single history of the order in which they were received.

In the Privacy section:

- The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party.

In the Privacy section diagram:

A trusted third party is shown in the top part of the diagram to illustrate the traditional banking system. No trusted third party is shown in the bottom part as an indication of a more secure model.

In the Conclusion:

- We have proposed a system for electronic transactions without relying on trust.

In the References section:

- [2] H. Massias, X.S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal trust requirements,” In 20th Symposium on Information Theory in the Benelux, May 1999.

## Why Should ETC Focus on Trust Minimization?

There are two reasons why Ethereum Classic should continuously focus on trust minimization.

The first is that once we understand that these systems are trust minimized and not trustless, then we are aware that there is some marginal risk that we are still depositing in trusted third parties. This risk may be augmented if there is no focus on trust minimization as any new changes or upgrades could increase it.

The second reason is that we are going to a world of globalization and centralization where trusted third parties will control every aspect of our lives if we don’t use systems as Ethereum Classic. ETC is a refuge against the inexorable arbitrary behavior of trusted third parties and a beacon of freedom for the world. And it must be kept this way.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

The fact that Ethereum Classic (ETC) is a proof of work blockchain, with fixed monetary policy, and smart contracts gives it features that make it very valuable.

The main benefits of these features are true decentralization, soundness of the money, and programmability.

Decentralization means trust minimization, which makes it secure. And, by secure we mean that it is immutable, permissionless, and censorship resistant on a global scale.

All these benefits combined make ETC valuable to many types of participants around the world for various reasons that we will explain in this post.

## ETC Is Sound Money

ETC is sound money because its coin is scarce, durable, costly to create, portable, divisible, fungible, and transferable. These features are basic physical attributes we evolved to demand so we could have a unit of value to exchange for goods and services and to use as a store of value for future spending.

A basic need of humans is to work to provide value to others so we can be rewarded for that value to sustain ourselves, our families, and our communities.

With sound money we reduced transactional costs and we introduced a unit of value that could be distributed between ourselves to divide labour, thus foster the explosion of innovation that resulted in our current modern age.

ETC is sound money that provides all these benefits because its currency is very costly to create due to proof of work, it has a fixed monetary policy that guarantees that the stock of the coin will not exceed 210,700,000 units, and it will be distributed fairly, at a decreasing rate, over the next 120 years.

## ETC Is Programmable

In addition to being sound money, the native cryptocurrency of ETC is programmable through smart contracts.

Smart contracts are software programs that application developers write that, when sent to the network, become decentralized as they are replicated across all nodes in the system thus making them decentralized applications, or d'apps for short.

This programmability, combined with its decentralization and the soundness of its money, gives ETC incredible value and versatility for users and developers alike.

Smart contracts are a key for further trust minimization, making ETC even more valuable than simple ledger systems as Bitcoin and Litecoin, because decentralized applications are like autonomous agents that replace the need for service providers hosted in proprietary data centers or cloud services.

## ETC Is Good Business For Miners

As ETC is the largest proof-of-work smart contracts blockchain in the world and has a market capitalization in the billions, it is a very good business for proof-of-work miners.

Because ETC still has a long way to rise on its run to become one of the top two blockchains in the world, miners are flocking to the network for the opportunity to put their GPUs and ASIC machines to work, many of whom are accumulating ETC for the long term rather than liquidating to pay bills or exchanging for other assets.

ETC currently ranks fourth largest mining computing base following Bitcoin, DogeCoin, and Litecoin but in the near future will likely surpass DOGE and LTC to become the second-largest mining base in the world.

## ETC Is Good Business for Economic Nodes

Economic nodes are those nodes in the ETC network that are operated by businesses that use ETC to generate revenues. Examples of these are exchanges, wallet providers, block explorers, node-as-a-service (NaaS) providers, data services, crypto custody services, and many others.

Historically, the trading volume of ETC against fiat and other cryptocurrencies has ranked very high at exchanges. This makes ETC a very good business for these players as well as for software and hardware wallet providers.

ETC is listed in most top exchanges and featured in most top wallet brands. As it is widely used by the public globally, it is featured in many data services and various blockchain access and custody providers.

Because running an ETC node is simple and straightforward, many of these businesses are node operators who value the ability to verify the data, transactions, and blocks by themselves. This is the basis of the saying “run your own node!” in the industry.

## ETC Is Good for Global Users

ETC is incredibly valuable for users globally.

Because it is a proof-of-work blockchain with a fixed monetary policy and smart contracts, ETC provides something that the world will increasingly demand as time passes: unstoppability.

The fact that ETC is truly decentralized, trust minimized, and thus censorship resistant, permissionless, and immutable is of an incalculable value for millions across the planet.

As governments and corporations cooperate more and more to centralize and control money, speech, and property through technology; even imagining a central world government reducing the basic rights of people everywhere; the demand for real decentralized computing and money will rise proportionately. People will be able to escape the tyranny of this dystopian world by using ETC as their refuge.

For all of these reasons, Ethereum Classic has enormous value.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

You can listen to or watch this video here:

The whole purpose of blockchains is decentralization.

Decentralization means to reduce the dependency on any particular trusted third party to act as intermediary in economic transactions between individuals and businesses.

Trust minimization is important in order to reduce the possible restrictions that trusted third parties can and usually do impose on users of their system.

Restrictions that trusted third parties usually impose may range from transactional costs, lock-in costs, to even blocking access to services altogether.

The more centralized a system is, the greater risk it has for a trusted third party to restrict it. Therefore, being careful in how a blockchain is designed, where the risks of centralization are reduced as much as possible, is a crucial task of the industry.

Striking a balance between trust minimization, change, complexity, and protocol politics is the topic of this post.

## What Is Social Scalability?

The term “social scalability” was coined by Nick Szabo in his seminal post “Money, blockchains, and social scalability”.

Social scalability, as defined by Szabo, is the ability of a system to be used by increasing numbers of users without encountering restrictions that reduces or blocks new entrants from using it.

A good example of a system that is not socially scalable is the banking system. In an advanced economy such as the United States, there are nearly six million households that are unbanked. Outside of the US, the great majority of countries have unbanked population shares that range from 7% to upwards of 50%.

The reason for these exclusion levels is twofold. The first is that governments, in their ambition to control people while touting “security reasons”, impose strict regulations on financial institutions to filter out potential customers who may not be able to prove that they are not criminals. The second is that due to these regulations, it becomes very costly for financial institutions to acquire and service customers, therefore they concentrate their marketing and distribution efforts only on the middle and higher-income segments of their markets.

In the proof of work based Nakamoto Consensus sector of the blockchain industry, networks such as Ethereum Classic (ETC), Bitcoin (BTC), and Litecoin (LTC) focus on high social scalability at the expense of computational scalability.

This means that the process of full replication of the data, hashing it, and then fully replicating the blocks again, producing an exact replica of exactly the same ledger with the same accounts, balances, and smart contracts, in the case of ETC, is extremely computationally inefficient, but it is the only way of producing a level of decentralization that enables everyone in the world to access the systems with no restrictions.

This is the tradeoff of computational scalability for social scalability.

Because of the physics of peer-to-peer networks, whichever system focuses on computational scalability must sacrifice decentralization, thus social scalability.

This is more or less the reason why governments seeking total and pure security sacrifice considerable numbers of their populations to remain excluded from basic services such as banking.

## What Is ETC Ossification?

As we said before, being careful in how a blockchain is designed, where the risks of centralization are reduced as much as possible, is a crucial task of the industry.

On the other hand, these systems need to be updated with new features every now and then, and, whenever they appear, bugs must be fixed.

However, the more frequently a blockchain is upgraded, the more risk there is for bad or faulty modifications to be introduced into the system.

This problem is usually called “attack surface”, which means that the larger the surface of the system is, the easier it will be to poke holes in it. In other words, the more code and rules it has, the easier it will be to find ways to attack it.

This is why the term “ossification” is usually used and is a goal in the industry. Ossification means to reach a point where the network is sufficiently functional to warrant a complete halt in its upgrades and bug fixes. Then, all new features and functionality may continue to be built on top in higher layers.

In the case of networks as Ethereum Classic, the attack surface problem has three angles: Complexity, politics, and change.

## Complexity

The complexity attack surface: The more complex rules and code needed to build the system, the more hidden ways hackers will find to attack it.

Complexity also raises the risk of hidden bugs or unforeseen failures.

The way of reducing this surface is by reducing complexity or reaching a point of ossification where the system is functional enough to support all new features and innovation in external complementary protocols.

Examples of this may be rollups, channels, and other scaling systems built on top of ETC, instead of sharding it internally or integrating them into the network.

## Protocol Politics

The argument attack surface: The more decisions to argue over, the more the opportunity to convince the ecosystem to accept bad upgrades that reduce decentralization.

In blockchain networks there are several constituents that participate in the debates when there are new proposals for change. These debates may become very passionate and even toxic at times. Sometimes, parties with enough budgets, charisma, or influence may actually convince participants to make horrible changes. The most famous of these examples is the migration of Ethereum from proof-of-work to proof-of-stake, a system prone to total centralization.

These processes turn developers, economic node operators, and miners into political animals fighting for their self interest.

Ossification would avoid this problem entirely as there would be no possibility of tricking the ecosystem with fancy arguments and gimmicks anymore.

## Change

The change attack surface: The more changes and upgrades there are, the more opportunities to introduce faulty rules or bugs.

Similar to protocol politics, the frequency of changes made, even if necessary and benevolent, is a risk to the system.

As an example, Bitcoin once had a critical bug introduced as part of an update. When it was discovered, deployment of an urgent hot-fix was required to patch the error.

Except for those hidden and already present in the code, ossification eliminates the introduction of new bugs or errors because there would be no new code or rules deployed to the protocol.

## Striking a Balance

The best way to strike a balance between trust minimization, change, complexity, and protocol politics is to reduce change by reaching protocol ossification and letting all new features and design goals to be built on higher layers.

In this way, the highest level of social scalability is achieved.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org

In this post, we'll delve into how Ethereum Classic's future potential can be explained through a well-known pattern found in nature. Just like the resilient oak tree, ETC begins its journey with modest origins. Gradually, it outperforms its competitors, defying short-term trends with its long-term strategy. As a result, it has the ability to survive numerous cycles, maturing into a towering presence and imprinting an enduring legacy.

## Rooted in Core Principles

An oak tree's strength and resilience are deeply connected to its roots, which anchor it firmly to the ground and provide essential nutrients. Similarly, Ethereum Classic's success is deeply rooted in its unwavering commitment to core principles of decentralization, immutability, and security. These principles have not only guided ETC's development but have also created a solid foundation for its long-term growth. By staying true to its roots, Ethereum Classic has built a platform that can weather the storms of the rapidly evolving crypto landscape and continue to thrive.

## Cutting Through the Weeds

ETC has maintained a foundation capable of weathering the crypto market's short-term thinking, much like a great oak tree. Its first significant test came in the form of the DAO hack and subsequent hard fork. Ethereum chose short-term convenience, intervening to reverse the hack's effects, whereas ETC remained committed to its "Code is Law" philosophy, preserving the platform's integrity.

This unwavering dedication to core principles highlights Ethereum Classic's resilience and determination, allowing it to stand firm amidst challenges. In contrast, the rapid growth of other projects, like weeds, may momentarily grab attention. However, their weaker roots and foundations often lead to their quick demise, as they lack the stability to withstand the test of time.

Ethereum Classic's solid foundation, rooted in decentralization, immutability, and security, primes it for slow but steady growth like a mighty oak tree. As it continues to expand and strengthen its presence in the crypto space, ETC's commitment to its core principles ensures it will outperform competitors with weaker foundations. In the long run, Ethereum Classic has the potential of a lasting impact in the world of decentralized technology, as many other projects come and go like seasonal weeds.

## From Sapling to Maturity

Just like an oak sapling in a crowded field of weeds, ETC has faced numerous challenges and attacks over the years. Since the DAO fork, it has survived 51% attacks and resisted contentious hard forks. The ETC community has weathered these storms and the project only grew to be stronger on the other side. Each challenge has tested ETC's resilience and commitment to decentralization, and it has consistently passed with flying colors.

Today, ETC resembles a young oak that has survived the initial challenges of growth and has begun to grow its roots deep into the earth. The hard part is over, and as it continues to mature and expand, it will become a towering symbol of strength and resilience in the world of decentralized technology.

## Withstanding the Storms of Change

As Ethereum shifts to a Proof of Stake (PoS) consensus mechanism, Ethereum Classic stands tall as the largest smart contract platform still embracing the proven and secure Proof of Work (PoW) model. This transition further highlights ETC's long-term potential in the ever-evolving crypto landscape.

Imagine a lush and fertile forest where two trees stand side by side. The first tree is a mighty oak, deeply rooted and strong, while the second tree, though tall and seemingly robust, has shallow roots and is not as firmly grounded. A fierce storm rolls in, and the shallow-rooted tree struggles to hold its ground, eventually toppling over, while the mighty oak remains unyielding, withstanding the tempest without faltering.

In the world of cryptocurrencies, Ethereum Classic (ETC) is like the mighty oak, steadfast and deeply rooted in its core principles and PoW consensus mechanism. Many other projects, on the other hand, are venturing into uncharted territory with the PoS consensus mechanism, exposing themselves to unforeseen risks and challenges, much like the shallow-rooted tree in the storm.

## Hard Wood Truths

ETC's longevity is a hard truth that sets it apart from other crypto projects. Like a mighty oak tree that has survived countless storms, ETC has stood the test of time and continues to grow stronger with each passing cycle.

While other projects have come and gone like dandelions in the wind, ETC has remained steadfast and committed to its vision. Its longevity and staying power are impressive, forcing people to wonder why it has continued to grow while others have faded away.

With its proven longevity and staying power, ETC is well-positioned to attract more attention and interest from the crypto community. As more people recognize the impressive feat of its continued existence and growth in a volatile market, it is positioned to snowball into greater awareness and adoption.

## Symbiotic Compatibility

Just as plants in an ecosystem coexist and collaborate for mutual benefit, Ethereum Classic's compatibility with Ethereum (ETH) Smart Contracts opens up a world of opportunities for synergy between the two networks. This compatibility enables developers to easily build and deploy applications on both networks, harnessing the unique strengths of each platform. By embracing this symbiotic relationship, Ethereum Classic can continue to innovate and evolve, growing stronger as part of a larger, interconnected ecosystem.

## Branching Out

A thriving oak tree provides a lush and fertile environment for various plants and animals to flourish. In the same way, Ethereum Classic is cultivating a growing ecosystem of decentralized applications (dApps) that can thrive on its platform. As ETC attracts more developers and users, the potential for new and innovative use cases expands, driving further growth and adoption. By fostering a rich and diverse ecosystem, Ethereum Classic is creating a fertile ground for creativity, innovation, and collaboration in the world of decentralized technology.

As the crypto market continues to evolve, it's evident that ETC is here to stay. Its long-term strategy and proven track record distinguish it from other projects that prioritize short-term gains. ETC is poised to rise above the noise and reach new heights, like an oak tree that has weathered many storms.

## Planting Seeds for Future Generations

In summary, Ethereum Classic (ETC) exemplifies resilience and long-term potential, much like a mighty oak tree, with its deeply rooted commitment to core principles of decentralization, immutability, and security.

By nurturing the growth of Ethereum Classic, we are not only investing in its present success but also fostering a legacy that will benefit the future of decentralized technology. As we continue to plant the seeds of innovation and collaboration within the ETC ecosystem, we are paving the way for a brighter, more inclusive, and decentralized future for all.

Let us be the ones to water the tree of Ethereum Classic today, so that the generations to come may enjoy the fruits of our labor and find shelter in the shade of a thriving and resilient network.