ECIP1011 for Replay Attack Fix Using Change in the Signing Process

ECIPs/ECIP1011.md

@@ -0,0 +1,55 @@
+### Title
+
+    ECIP: 1011
+    Title: Modification of Ethereum Classic (ETC) Transaction Signing Process to Prevent Replay Attacks
+    Author: Avtar Sehra <[email protected]>
+    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 trigger block is expected to be at ```Netc=3,000,000```, which is the Hard Forking block for delaying the Difficulty Bomb.
+
+### Fixed and Dynamic Variable Usage
+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 shosen for simplicity to be ```Netc = 1920000``` (the point of the ethereum fork) or ```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 one 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_lead``` or after ```N_lead blocks```. If we say ```1 epoch``` is ```1024 blocks``` or ```4 hours```, then we can use a lead time of ```6 epochs``` or ```6,144 blocks``` or ```24 hours```
+
+1. At time ```t0``` we are at block number ```N_t0```. We use block from ```6 epochs``` back which equals ```N_e=6,144``` blocks 
+2. Block header hash of relevant reference point block:  ```BlockHeaderHash(N_t0 - N_e) = T_a```
+3. Use ```T_a``` as the reference value in above signing and validation method
+4. Validation can then take place with up to 1 weeks of values: ```t0, t0-24, t0-48 ... t0-168```, which implies at most 7 checks would need to be performed for transactions that would be delayed by 7 days.  
+
+With this approach, it would ensure that for any future forks the replay attack is resolved after a time lag of ```6 epochss``` (or 24 hours ```~ 6,144 blocks```).
+
+In this dynamic approach, an option could be used that T_a could also be an arbitrary value ```0```, which can be used by light clients or for constructing off-line transactions.