ECIP1011 for Replay Attack Fix Using Change in the Signing Process

ECIPs/ECIP1011.md

@@ -0,0 +1,82 @@
+### Title
+
+    ECIP: 1011
+    Title: Modification of Ethereum Classic (ETC) Transaction Signing Process to Prevent Replay Attacks
+    Author: Avtar Sehra <avtarsehra@ethereumclassic.org>
+    Status: Draft
+    Type: Standard
+    Created: 2016-10-02 
+
+### Abstract
+This ECIP describes the process of modifying the ETC process used for signing and validating transactions for inclusion into the ETC blockchain. The proposed approach is akin to the BTC signing process, and will ensure Ethereum Hard Fork Chain (ETH) transactions can not be replayed on the ETC network.
+
+### Motivation
+Other methods proposed for the Replay Attack fix require either modification of key symbolic values (e.g. the account nonce, which represents the number of transactions sent from the sender's address) or increasing the transaction sizes by adding an extra field to the sent transaction (e.g. an arbitrary reference block hash). Such modifications would impact backward compatibility of transaction structures. With the approach proposed here there is no change in the structure of the transaction and or the intrinsic values, however there would be a modification to the transaction signing and validation process. This difference would take the form of adding an extra arbitrary value to the transaction prior to performing the transaction hash for signing. This would result in a unique message and thus signature that would differ from that of the ETH chain. Such a process will be cryptographically secure and ensure that all transactions broadcast from the ETH network cannot be accepted in the ETC network and vice-versa.
+
+### Specification
+In the Bitcoin protocol the scriptPubKey script is copied from the source transaction into the spending transaction (i.e. the transaction that is being signed) before calculating the signature. Then the signature script, scriptSig, is embedded in the transaction. Using the previous transaction's scriptPubKey during the signing process is for historical reasons rather than any logical ones.
+
+In the Ethereum protocol a transaction (formally ```T```) is a single cryptographically-signed instruction constructed by an actor externally to the scope of the Ethereum network. Both message call and contract creation transactions specify a number of common felds: ```T=(T_n, T_p, T_g, T_t, T_v, T_(i or d),T_w, T_r, T_s)```,  where ```T_w, T_r, T_s``` are the signature components for the elliptic curve digital signature algorithm utilized in the Ethereum protocol.
+
+The current signing process is as follows:
+
+1. The message to be signed is constructed: ```L_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d))``` where ```T_i``` contains the EVM code if ```T_t=null``` (no target address) or ```T_d``` is an unlimited size byte array if ```T_t<>null``` (has target address)
+2. The Keccak Hash is than calculated: ```h(T)=KEC(L_s(T))```
+3. The signature process then generates: ```(T_w, T_r, T_s)=ECDSASIGN(h(T),p_r)```, where ```p_r``` is the senders private key.
+4. We can then define the sender function ```S``` (giving the sender's address) for the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s)))```
+
+The modified process proposed would be to insert an extra step between points 1 and 2, which appends an arbitrary value, T_a, to the transaction prior to signing and or validating. However, unlike in BTC where the value is taken from the source transaction the suggestion in this approach is to utilse a block header hash i.e. ```T_a = Block Header Hash```. So the process becomes:
+
+1. The message to be signed is constructed as before: ```L_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d))```
+2. Append the Tx Hash of ```Netc``` i.e. given by ```T_a``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_a)``` 
+3. The Keccak Hash is than calculated: ```h(T)=KEC(M_s(T))```
+4. The signature process then generates: ```(T_w, T_r, T_s)=ECDSASIGN(h(T),p_r)```
+5. We can then define the sender function S (giving the sender's address) for the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s)))```
+
+In this way no extra information needs to be added to the transactions to increase their size, the transaction structures would remain backwards compatible and all key symbolic fields would remain unchanged.
+
+Even though this is a much simpler change for implementation compared to other suggestions and does not require changes to the standard transaction structures, this does require a change in the fundamental process related to the Ethereum Classic protocol. As a result it is a higher risk change and would require much deeper testing to ensure transactions are not lost through unforseen errors in the signing process.
+
+The choice of signing variable will be a fixed value, but support for offline transactions using hardware wallets would also need to be included. Therefore the choice of the signing varibale can be: 
+1. 0 (null) to support offline transactions
+2. Block hash of the most recent fork, T_a, where T_a is the hash of the Genesis block if no forks have occurred.
+
+For example the hash of block ```Netc=3,000,000```, which is exepcted to be the Hard Forking block for delaying the Difficulty Bomb.
+
+
+### Dynamic Signing Variable (*** For Reference Only ***)
+The value of T_a can be chosen in an arbitrary way if it is constant e.g. the block header hash of a specific block can be chosen for simplicity to be ```Netc = 1920000``` (the point of the ethereum fork) or ```Netc = 3,000,000``` (as noted above). This value can be easily updated in future forks by using a new reference block. This process can also be easily managed by light clients, even with end users making an update to the reference block variable to match the relevant value chosen by the network (if the option is made available to end users). 
+
+An alternative method would be to utilize a dynamic value for ```T_a```. One possibility would be to use the block header hash of a reference block that is updated after a lead time of ```T_l``` or after ```N_l lead blocks```. If we say ```1 epoch``` is ```1024 blocks``` or ```4 hours```, then we can use a lead time of ```T_l = 6 epochs``` or ```N_l = 6,144 blocks```. Therefore the reference block is updated every ```24 hours``` (every ```6 epochs```). 
+
+For example, starting at ```Netc = 3,000,000``` we update ```T_a``` with the new reference value after each ```N_l``` blocks. If ```BH(N)``` is the function for the block header hash for the ```Nth``` block, and we choose to reference a lagging block we have:
+
+```
+t0 : T_a = BH[Netc - N_l]
+t1 : T_a = BH[Netc - N_l + N_l]
+t2 : T_a = BH[Netc - N_l + N_l + N_l]
+...
+tn : T_a = BH[Netc - N_l + N_l * n]
+```
+
+or 
+
+```
+tn : T_a = BH[Netc + N_l * (n - 1)]
+```
+
+where 
+
+```
+n = RoundDown[ (N_c - Netc)/N_l ]
+```
+
+```N_c``` is the most recent block number.
+
+In this way validation can then take place using a pool of 1 week of values: ```t0, t1, t2 ... t7```, which implies at most 7 checks would be required to be performed for transactions that are delayed by up to 7 days. A limit should be in place to identify how far checks should go.
+
+This approach would ensure that for any future forks the replay attack is resolved after a time lag of ```6 epochs``` (or 24 hours ```~ 6,144 blocks```).
+
+In this dynamic approach, an option could be used where ```T_a``` is also an arbitrary value ```0``` that is used by light clients or for constructing off-line transactions. However, this means that light clients or offline transaction construction is suciptible to replay attacks. 
+
+The dynamic signing variable is only highlighted here for completeness and is not being considered for Replay Attack Fix due to potential concerns related to enforcing transaction expiry times at the protocol level and the added cost of computation required for long expiry times (validation period above).

ECIPs/ECIP1021.md

@@ -0,0 +1,37 @@
+### Title
+
+    ECIP: 1018
+    Title: Ethereum Classic (ETC) Fiscal Policy Proposal
+    Author: Avtar Sehra <avtarsehra@ethereumclassic.org>
+    Status: Draft
+    Type: Standard
+    Created: 2017-02-20
+
+### Abstract
+This ECIP describes the process of implementing a minimal Fiscal Policy (FP) change that would provide a mechanism to finance a Dapp level Treasury Smart Contract. The FP change will enable a fixed “FP fee” to be deducted from the proposed supply release (excluding TX fees). It is proposed that on entering a new Era the percentage allocation to the FP fee is reduced by a factor that is significantly higher than the supply reduction proposed in ECIP1017. This means as supply release decreases to zero over consecutive Era’s the FE fee allocation will tend to zero faster. This Fiscal Policy model will ensure that TX fees will never subsidize ongoing FP fees and no perpetual supply release will be required to accommodate the fees. This method ensures consistency with ECIP1017’s ultimate deflationary roadmap. In addition an approach is highlighted in this work to leverage BitEther smart contract tokens as a means to execute votes for distribution of funds. Such a mechanism would also provide utility (and implied value) for the BitEther tokens, which could then start to replace the Treasury financing.
+
+### Motivation
+Over the last 8 years, since the release of Bitcoin, discussion and debate of Monetary Policies has become a core component of crypto-currencies. However, such focus has not been effectively placed on the concept of Fiscal Polices. At a high-level the definition of a Fiscal Policy is “the means by which a government adjusts its spending levels and tax rates to monitor and influence a nation's economy.” However, while such a policy is irrelevant within a simple public blockchain network, it becomes increasingly relevant in networks that propose some form of “treasury fee”, which is allocated through a deduction from block rewards. 
+
+Such deductions (Fiscal Policy (FP) Fees) can be collected and distributed for the upkeep of the network. The current application of such model either require an inflationary model where a small perpetual supply release is maintained to finance the FP fees; or a deflationary model which requires the replacement of the supply release fees as they tend to zero with TX fees from the transactions being mined into blocks. Either way the focus is to ensure an ongoing financing of a central network treasury through an appropriate Fiscal Policy.
+
+While a perpetual release and resulting inflationary model is not considered an appropriate approach for an open and decentralized blockchain network, the enforcement of a deflationary model through replacement of perpetual release with sharing of TX fees has its own issues as such models appear as an enforced tax on miners (in particular for the case of networks with PoW consensus mechanisms).  In the opinions of the authors neither of these methods are acceptable for a sustainable public infrastructure that is expected to tend to a stable state over time. 
+
+This stable state means a standardized protocol that requires limited upkeep and change. Also as the steady state is achieved it can also be assumed that successful companies will form on the network that will deploy self-sustaining business models. Such companies will also be able to finance the development of improved clients that are consistent with the standardized network protocol. In this steady state future consortiums of such companies may also form that can decide on how to make fundamental changes to the network if required. This is the model being implemented in the internet/web protocol industries. However, until such a steady state is achieved the key principles of public blockchain architecture need to be maintained. This means ensuring an open and decentralized infrastructure, but most importantly it must be indifferent to the value being transacted and must not impose fees on those providing vital services in securing the network at their risk/cost i.e. the miners in a PoW system. Applying TX FP Fee deductions  (which are essentially TX taxes) violates the principles of a public blockchain, and even more so it violates the principles that ETC was founded on.
+It is the purposes of this ECIP to propose a potential Fiscal Policy model that enables a short term FP fee to be added to the supply release with a minimal change to the supply cap. However, the FP fee would tend to zero over a fixed number of Eras. For example if an X% fee is added to the supply release this can be structured to tend to zero over a period of Y Eras (~Y*2.38 years). In such a model no deduction of TX fees will be made. This would ensure that the network TX fees are not taxed and used to subsidize the treasury expenditure. In addition this will also ensure that a deflationary monetary policy can be maintained on the network.
+
+One of the key aspects for such a Fiscal Policy is that as the FP fees are distributed to a Dapp level Treasury Smart Contract it can be used for the appropriate distribution of the funds to core development team(s) based on a simple contract based voting mechanism. The key aspect of this is that if the voting is triggered through mechanisms that leverage ETC tokens, the treasury could also become self-financing over time through votes and donations. In addition a model can be adopted where BitEther tokens are used for voting (a Dapp level crypto currency that is allocated to miners in parallel to ETC rewards). If BitEther tokens are used in this manner they also gain utility, which would result in increased implied value. This increased value will imply BitEther tokens can thus eventually replace ETC tokens as a means of funding the treasury. In this approach the system is potentially able to become self-financing without ETC token. 
+
+Implementation of this FP model requires minimal change at the protocol level, which can be activated at a certain future block height. Then as the FP fees tend to zero, no further action is required at the protocol level as the FP fees will cease paying out and will be deactivated at the expected block height in the future. 
+
+In this model three scenarios may emerge:
+1.	The ETC tokens will increase in value substantially. In this case the surplus ETC collected in the Treasury smart contract by the final FP Era may be leveraged for an extended period to support core development and support of the network until a self-sustaining stable state is reached.
+2.	The ETC tokens will not increase in value substantially, but the voting mechanism using the BitEther tokens (or other tokens) will gain utility and thus implied value. In this case the BEC tokens can replace the ETC tokens for financing the Treasury for core development and support work, which will ensure a self-sustaining stable state is reached.
+3.	Neither the ETC or the BEC tokens increase in value and the final FP Era is reached. In this case the Treasury will cease to be funded, and any surplus will diminish over a short number of Eras. In such a scenario, where ETC value ceases to increase sufficiently to enable the prolonged funding of core client upkeep, the financing of ongoing development work will likely be a lower priority as the challenges will be mostly due to a lack of utility of the core ETC token. In such a scenario alternative strategies will need to be reviewed. 
+
+As part of the specification work, in the next section, an appropriate FP policy model is structured to ensure sufficient time is allowed for the funding of a treasury smart contract. This will also need to ensure such funding has minimal impact on the total supply cap and zero impact on the TX fees paid to miners. In this model the deflationary objectives will be maintained along with ensuring miners expected returns in relation to TX fees are unaffected. In addition this model requires minimal change and complexity in the core protocol, with treasury and voting mechanism changes being made at a DAPP level. In the specification it will be proposed that these changes will not need to be applied during the ECIP1017 change, and such changes can be applied at a later date when the Treasury and Governance Smart Contract Dapps are better defined.
+
+
+
+### Specification
+