From 63970c8cab4beb413c55a10369f26c7a87ac8ecf Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 12:55:03 +0200 Subject: [PATCH 01/32] Create ECIP1011 --- ECIPs/ECIP1011 | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 ECIPs/ECIP1011 diff --git a/ECIPs/ECIP1011 b/ECIPs/ECIP1011 new file mode 100644 index 0000000..acb141f --- /dev/null +++ b/ECIPs/ECIP1011 @@ -0,0 +1,40 @@ +### Title + + ECIP: 1011 + Title: Modification of Ethereum Classic (ETC) Transaction Signing Process to Prevent Replay Attacks + Author: Avtar Sehra + Status: Draft + Type: Standard + Created: 2016-10-02 + +### Abstract +This ECIP describes the process of modifiying the ETC hash process used for signing and validating transactions for inclusion into the ETC blockchain, where the proposed approach is akin to the BTC process. + +### Motivation +Other methods proposed for the replay fix require either modification of key symbolic values (i.e. the account nonce) or increasing the transaction sizes by adding an extra field to the transactions (e.g. a reference block hash). Such modifications impact backward compatibility of transaction structures. With the approach prosed here there is no change in the structure of the transaction, however there would be a minimal modification for the transaction signing and validation process. This difference would take the form of adding an extra arbitray value to the transaction prior to performing the hash. This would result in a unique message and thus signature that would differ from that of the ETH chain. Such processes 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 signing is for historical reasons rather than any logical reason. + +In the ethereum protocol a transaction (formally, ```T```) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. Both, message call and contract creation transatcions, 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 algorithem utilised 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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` +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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s))) + +The modification process proposed would be by inserting an extra step between points 1 and 2, which appends an arbitrary value to the transaction. However, unlike in BTC, where the value is taken from the source transatcion, the suggestion here is to utilse a constant value e.g. the transaction hash of block ``Netc = 1920000``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: + +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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` +2. Append the Tx Hash of ```Netc``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_Netc)``` +2. The Keccak Hash is than calculated: ```h(T)=KEC(M_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) of 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, the transaction structures would remain backwards compatible and all key symbolic fields would remain unchanged. + +Even though this is a much simpler change for implmentation compared to other suggestions and does not require changes to the standard transaction structures, this does require a change in a 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 by users. + +The trigger block is expected to be at ```3000000```, which is the HardForking block for delaying the Difficulty Bomb. From db2eb79e4d70e0dcb11309e66119071a2b0f3829 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 12:55:25 +0200 Subject: [PATCH 02/32] Create ECIP1011.md --- ECIPs/ECIP1011.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 ECIPs/ECIP1011.md diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md new file mode 100644 index 0000000..acb141f --- /dev/null +++ b/ECIPs/ECIP1011.md @@ -0,0 +1,40 @@ +### Title + + ECIP: 1011 + Title: Modification of Ethereum Classic (ETC) Transaction Signing Process to Prevent Replay Attacks + Author: Avtar Sehra + Status: Draft + Type: Standard + Created: 2016-10-02 + +### Abstract +This ECIP describes the process of modifiying the ETC hash process used for signing and validating transactions for inclusion into the ETC blockchain, where the proposed approach is akin to the BTC process. + +### Motivation +Other methods proposed for the replay fix require either modification of key symbolic values (i.e. the account nonce) or increasing the transaction sizes by adding an extra field to the transactions (e.g. a reference block hash). Such modifications impact backward compatibility of transaction structures. With the approach prosed here there is no change in the structure of the transaction, however there would be a minimal modification for the transaction signing and validation process. This difference would take the form of adding an extra arbitray value to the transaction prior to performing the hash. This would result in a unique message and thus signature that would differ from that of the ETH chain. Such processes 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 signing is for historical reasons rather than any logical reason. + +In the ethereum protocol a transaction (formally, ```T```) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. Both, message call and contract creation transatcions, 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 algorithem utilised 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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` +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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s))) + +The modification process proposed would be by inserting an extra step between points 1 and 2, which appends an arbitrary value to the transaction. However, unlike in BTC, where the value is taken from the source transatcion, the suggestion here is to utilse a constant value e.g. the transaction hash of block ``Netc = 1920000``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: + +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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` +2. Append the Tx Hash of ```Netc``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_Netc)``` +2. The Keccak Hash is than calculated: ```h(T)=KEC(M_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) of 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, the transaction structures would remain backwards compatible and all key symbolic fields would remain unchanged. + +Even though this is a much simpler change for implmentation compared to other suggestions and does not require changes to the standard transaction structures, this does require a change in a 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 by users. + +The trigger block is expected to be at ```3000000```, which is the HardForking block for delaying the Difficulty Bomb. From 34ba8b0b6de40e223649fa470786aa1ec6a5485b Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 12:55:52 +0200 Subject: [PATCH 03/32] Delete ECIP1011 --- ECIPs/ECIP1011 | 40 ---------------------------------------- 1 file changed, 40 deletions(-) delete mode 100644 ECIPs/ECIP1011 diff --git a/ECIPs/ECIP1011 b/ECIPs/ECIP1011 deleted file mode 100644 index acb141f..0000000 --- a/ECIPs/ECIP1011 +++ /dev/null @@ -1,40 +0,0 @@ -### Title - - ECIP: 1011 - Title: Modification of Ethereum Classic (ETC) Transaction Signing Process to Prevent Replay Attacks - Author: Avtar Sehra - Status: Draft - Type: Standard - Created: 2016-10-02 - -### Abstract -This ECIP describes the process of modifiying the ETC hash process used for signing and validating transactions for inclusion into the ETC blockchain, where the proposed approach is akin to the BTC process. - -### Motivation -Other methods proposed for the replay fix require either modification of key symbolic values (i.e. the account nonce) or increasing the transaction sizes by adding an extra field to the transactions (e.g. a reference block hash). Such modifications impact backward compatibility of transaction structures. With the approach prosed here there is no change in the structure of the transaction, however there would be a minimal modification for the transaction signing and validation process. This difference would take the form of adding an extra arbitray value to the transaction prior to performing the hash. This would result in a unique message and thus signature that would differ from that of the ETH chain. Such processes 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 signing is for historical reasons rather than any logical reason. - -In the ethereum protocol a transaction (formally, ```T```) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. Both, message call and contract creation transatcions, 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 algorithem utilised 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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` -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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s))) - -The modification process proposed would be by inserting an extra step between points 1 and 2, which appends an arbitrary value to the transaction. However, unlike in BTC, where the value is taken from the source transatcion, the suggestion here is to utilse a constant value e.g. the transaction hash of block ``Netc = 1920000``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: - -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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` -2. Append the Tx Hash of ```Netc``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_Netc)``` -2. The Keccak Hash is than calculated: ```h(T)=KEC(M_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) of 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, the transaction structures would remain backwards compatible and all key symbolic fields would remain unchanged. - -Even though this is a much simpler change for implmentation compared to other suggestions and does not require changes to the standard transaction structures, this does require a change in a 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 by users. - -The trigger block is expected to be at ```3000000```, which is the HardForking block for delaying the Difficulty Bomb. From 8f92378bead9672ede3cb27ca027917982bff033 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 12:57:08 +0200 Subject: [PATCH 04/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index acb141f..2ec5999 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -29,7 +29,7 @@ The modification process proposed would be by inserting an extra step between po 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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` 2. Append the Tx Hash of ```Netc``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_Netc)``` -2. The Keccak Hash is than calculated: ```h(T)=KEC(M_s(T)) +2. The Keccak Hash is than calculated: ```h(T)=KEC(M_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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s))) From 9b9310feefdf42655a9a4dca3561ead2ba8f487a Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 12:57:30 +0200 Subject: [PATCH 05/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 2ec5999..979aec4 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -31,7 +31,7 @@ The modification process proposed would be by inserting an extra step between po 2. Append the Tx Hash of ```Netc``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_Netc)``` 2. The Keccak Hash is than calculated: ```h(T)=KEC(M_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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s))) +4. We can then define the sender function S (giving the sender's address) of 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, the transaction structures would remain backwards compatible and all key symbolic fields would remain unchanged. From 68d15ae40819f11daddd7649292047cb3e9b23f3 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 13:50:09 +0200 Subject: [PATCH 06/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 979aec4..3ec8550 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -23,7 +23,7 @@ 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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` 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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s))) +4. We can then define the sender function S (giving the sender's address) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s)))``` The modification process proposed would be by inserting an extra step between points 1 and 2, which appends an arbitrary value to the transaction. However, unlike in BTC, where the value is taken from the source transatcion, the suggestion here is to utilse a constant value e.g. the transaction hash of block ``Netc = 1920000``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: From b1fa6ee808a440eb75c2b35ae207cc35f7fa6007 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 14:52:55 +0200 Subject: [PATCH 07/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 3ec8550..fd05aa8 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -8,15 +8,15 @@ Created: 2016-10-02 ### Abstract -This ECIP describes the process of modifiying the ETC hash process used for signing and validating transactions for inclusion into the ETC blockchain, where the proposed approach is akin to the BTC process. +This ECIP describes the process of modifiying 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) transctions can not be replayed on the ETC network. ### Motivation -Other methods proposed for the replay fix require either modification of key symbolic values (i.e. the account nonce) or increasing the transaction sizes by adding an extra field to the transactions (e.g. a reference block hash). Such modifications impact backward compatibility of transaction structures. With the approach prosed here there is no change in the structure of the transaction, however there would be a minimal modification for the transaction signing and validation process. This difference would take the form of adding an extra arbitray value to the transaction prior to performing the hash. This would result in a unique message and thus signature that would differ from that of the ETH chain. Such processes will be cryptographically secure, and ensure that all transactions broadcast from the ETH network cannot be accepted in the ETC network and vice-versa. +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 prosed here there is no change in the structure of the transaction and or the intrinsic values, however there would be a modification for to transaction signing and validation process. This difference would take the form of adding an extra arbitray 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 signing is for historical reasons rather than any logical reason. +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 Ethereum. Both, message call and contract creation transatcions, 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 algorithem utilised in the Ethereum protocol. +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 algorithem utilised in the Ethereum protocol. The current signing process is as follows: From 761865ca050f35ee92bb00cec7b95202a5194e17 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 15:00:48 +0200 Subject: [PATCH 08/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index fd05aa8..5148d17 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -20,21 +20,22 @@ In the ethereum protocol a transaction (formally ```T```) is a single cryptograp 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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` -2. The Keccak Hash is than calculated: ```h(T)=KEC(L_s(T)) +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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s)))``` +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 modification process proposed would be by inserting an extra step between points 1 and 2, which appends an arbitrary value to the transaction. However, unlike in BTC, where the value is taken from the source transatcion, the suggestion here is to utilse a constant value e.g. the transaction hash of block ``Netc = 1920000``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: +The modified process proposed would be to insert an extra step between points 1 and 2, which appends an arbitrary value to the transaction. However, unlike in BTC where the value is taken from the source transatcion the suggestion in this approach is to utilse a constant value e.g. the transaction hash of block ```Netc = 1920000``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: -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``` or ```T_d``` is an unlimited size byte array if ```T_t<>null``` +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``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_Netc)``` -2. The Keccak Hash is than calculated: ```h(T)=KEC(M_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) of the transaction as: ```S(T)=B_(96...255) (KEC(ECDSARECOVER(h(T), T_w, T_r, T_s)))``` +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, the transaction structures would remain backwards compatible and all key symbolic fields would remain unchanged. +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 implmentation compared to other suggestions and does not require changes to the standard transaction structures, this does require a change in a 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 by users. +Even though this is a much simpler change for implmentation 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 lose through errors in the signing process. The trigger block is expected to be at ```3000000```, which is the HardForking block for delaying the Difficulty Bomb. From 12a634399b6f02d5982fdc010012acab62a8da2f Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 15:35:09 +0200 Subject: [PATCH 09/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 5148d17..a68b60d 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -38,4 +38,4 @@ In this way no extra information needs to be added to the transactions to increa Even though this is a much simpler change for implmentation 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 lose through errors in the signing process. -The trigger block is expected to be at ```3000000```, which is the HardForking block for delaying the Difficulty Bomb. +The trigger block is expected to be at ```Netc_trigger=3,000,000```, which is the HardForking block for delaying the Difficulty Bomb. From 44086cd15706c1b4859f597b12c6871b0e1d5016 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 18:33:48 +0200 Subject: [PATCH 10/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index a68b60d..e80b056 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -26,10 +26,10 @@ The current signing process is as follows: 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 to the transaction. However, unlike in BTC where the value is taken from the source transatcion the suggestion in this approach is to utilse a constant value e.g. the transaction hash of block ```Netc = 1920000``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: +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. However, unlike in BTC where the value is taken from the source transatcion the suggestion in this approach is to utilse a constant value e.g. the transactions hash of block ```Netc = 1920000``` i.e. ```T_a = H_e``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: 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``` : ```M_s(T)=(T_n, T_p, T_g, T_t, T_v, T_(i or d), T_Netc)``` +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)))``` @@ -39,3 +39,6 @@ In this way no extra information needs to be added to the transactions to increa Even though this is a much simpler change for implmentation 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 lose through errors in the signing process. The trigger block is expected to be at ```Netc_trigger=3,000,000```, which is the HardForking block for delaying the Difficulty Bomb. + +### Alternative For Discussion +The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000``, ```T_a```, was chosen due to simplicity. This value can be easily updated in future forks, by using a new reference block, and this process can also be easily managed by light clients. However, an alternative method would be to utilise a dynamic value for ```T_a```. One possibilty would be to use the transactions hash of a reference block that gets updated after a lead time of ```N_lead``` blocks. So In the first "epoch" you would use the ```T_a=H_e(Netc)```, and after ```N_lead``` blocks you have ```T_a=H_e(Netc+N_lead)```. This way would ensure the replay attack is resolved after a time lag of ```N_lead``` (or one epoch). This would mean that in any future fork replay issues will be resolved after one epoch. From 2240151a392bd93ebdd5c3a2eb1f2ebd92e0128d Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 18:38:47 +0200 Subject: [PATCH 11/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index e80b056..889c8f5 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -8,15 +8,15 @@ Created: 2016-10-02 ### Abstract -This ECIP describes the process of modifiying 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) transctions can not be replayed on the ETC network. +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 prosed here there is no change in the structure of the transaction and or the intrinsic values, however there would be a modification for to transaction signing and validation process. This difference would take the form of adding an extra arbitray 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. +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 prosed here there is no change in the structure of the transaction and or the intrinsic values, however there would be a modification for to 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 algorithem utilised in the Ethereum protocol. +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: @@ -26,7 +26,7 @@ The current signing process is as follows: 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. However, unlike in BTC where the value is taken from the source transatcion the suggestion in this approach is to utilse a constant value e.g. the transactions hash of block ```Netc = 1920000``` i.e. ```T_a = H_e``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: +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. However, unlike in BTC where the value is taken from the source transaction the suggestion in this approach is to utilse a constant value e.g. the transactions hash of block ```Netc = 1920000``` i.e. ```T_a = H_e``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: 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)``` @@ -36,9 +36,9 @@ The modified process proposed would be to insert an extra step between points 1 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 implmentation 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 lose through errors in the signing process. +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 lose through errors in the signing process. -The trigger block is expected to be at ```Netc_trigger=3,000,000```, which is the HardForking block for delaying the Difficulty Bomb. +The trigger block is expected to be at ```Netc_trigger=3,000,000```, which is the Hard Forking block for delaying the Difficulty Bomb. ### Alternative For Discussion -The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000``, ```T_a```, was chosen due to simplicity. This value can be easily updated in future forks, by using a new reference block, and this process can also be easily managed by light clients. However, an alternative method would be to utilise a dynamic value for ```T_a```. One possibilty would be to use the transactions hash of a reference block that gets updated after a lead time of ```N_lead``` blocks. So In the first "epoch" you would use the ```T_a=H_e(Netc)```, and after ```N_lead``` blocks you have ```T_a=H_e(Netc+N_lead)```. This way would ensure the replay attack is resolved after a time lag of ```N_lead``` (or one epoch). This would mean that in any future fork replay issues will be resolved after one epoch. +The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000```, ```T_a```, was chosen due to simplicity. 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 bloc (if the option is made available). However, an alternative method would be to utilize a dynamic value for ```T_a```. One possibility would be to use the transactions hash of a reference block that gets updated after a lead time of ```N_lead``` blocks. So In the first "epoch" you would use the ```T_a=H_e(Netc)```, and after ```N_lead``` blocks you have ```T_a=H_e(Netc+N_lead)```. This way would ensure the replay attack is resolved after a time lag of ```N_lead``` (or one epoch). This would imply that in any future fork replay issues will be resolved after one epoch, as transactions hash, ```H_e``` in the headers of forks would vary immediately as different transactions start taking place. From 1279a8a7b41f31d26432f7de42204fa2ec2d1129 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Sun, 2 Oct 2016 19:09:12 +0200 Subject: [PATCH 12/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 889c8f5..b349946 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -41,4 +41,6 @@ Even though this is a much simpler change for implementation compared to other s The trigger block is expected to be at ```Netc_trigger=3,000,000```, which is the Hard Forking block for delaying the Difficulty Bomb. ### Alternative For Discussion -The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000```, ```T_a```, was chosen due to simplicity. 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 bloc (if the option is made available). However, an alternative method would be to utilize a dynamic value for ```T_a```. One possibility would be to use the transactions hash of a reference block that gets updated after a lead time of ```N_lead``` blocks. So In the first "epoch" you would use the ```T_a=H_e(Netc)```, and after ```N_lead``` blocks you have ```T_a=H_e(Netc+N_lead)```. This way would ensure the replay attack is resolved after a time lag of ```N_lead``` (or one epoch). This would imply that in any future fork replay issues will be resolved after one epoch, as transactions hash, ```H_e``` in the headers of forks would vary immediately as different transactions start taking place. +The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000```, ```T_a```, was chosen due to simplicity. 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 (if the option is made available). + +An alternative method would be to utilize a dynamic value for ```T_a```. One possibility would be to use the transactions hash of a reference block that gets updated after a lead time of ```N_lead``` blocks. So in the first "epoch" you would use ```T_a=H_e(Netc)```, and after ```N_lead``` blocks you have ```T_a=H_e(Netc+N_lead)```. This way you would ensure the replay attack is resolved after a time lag of ```N_lead``` (or one epoch). This would imply that in any future fork replay issues will be resolved after one epoch, as the Transactions Hash field, ```H_e``` in the blockheaders of forks would vary immediately as different transactions start taking place. From 42b4caae68d6941119d03cf79298e54892c69606 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 13:58:43 +0200 Subject: [PATCH 13/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index b349946..4559fce 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -11,7 +11,7 @@ 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 prosed here there is no change in the structure of the transaction and or the intrinsic values, however there would be a modification for to 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. +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 for to 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. From 01675eb0a3c9bc1db1ad9896d644952beefb9594 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 14:06:16 +0200 Subject: [PATCH 14/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 4559fce..b0547a2 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -11,7 +11,7 @@ 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 for to 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. +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. @@ -36,11 +36,11 @@ The modified process proposed would be to insert an extra step between points 1 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 lose through errors in the signing process. +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_trigger=3,000,000```, which is the Hard Forking block for delaying the Difficulty Bomb. ### Alternative For Discussion -The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000```, ```T_a```, was chosen due to simplicity. 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 (if the option is made available). +The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000``` or ```3,000,000``` for ```T_a```, are chosen due to simplicity. 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 transactions hash of a reference block that gets updated after a lead time of ```N_lead``` blocks. So in the first "epoch" you would use ```T_a=H_e(Netc)```, and after ```N_lead``` blocks you have ```T_a=H_e(Netc+N_lead)```. This way you would ensure the replay attack is resolved after a time lag of ```N_lead``` (or one epoch). This would imply that in any future fork replay issues will be resolved after one epoch, as the Transactions Hash field, ```H_e``` in the blockheaders of forks would vary immediately as different transactions start taking place. From a6743ce001f873d9888a0d77ba8cc0570818c7b8 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 19:28:33 +0200 Subject: [PATCH 15/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index b0547a2..6dd6243 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -26,7 +26,7 @@ The current signing process is as follows: 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. However, unlike in BTC where the value is taken from the source transaction the suggestion in this approach is to utilse a constant value e.g. the transactions hash of block ```Netc = 1920000``` i.e. ```T_a = H_e``` (which contained the execution of an irregular state change in the ETH chain). In this way the process would then become: +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)``` @@ -38,9 +38,18 @@ In this way no extra information needs to be added to the transactions to increa 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_trigger=3,000,000```, which is the Hard Forking block for delaying the Difficulty Bomb. +The trigger block is expected to be at ```Netc=3,000,000```, which is the Hard Forking block for delaying the Difficulty Bomb. -### Alternative For Discussion -The arbitrary value above e.g. the transactions hash of block ```Netc = 1920000``` or ```3,000,000``` for ```T_a```, are chosen due to simplicity. 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). +### Fixed and Dynamic Variable Netc +The value of T_a can be chosen in an arbitrary way if it is constanct 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 transactions hash of a reference block that gets updated after a lead time of ```N_lead``` blocks. So in the first "epoch" you would use ```T_a=H_e(Netc)```, and after ```N_lead``` blocks you have ```T_a=H_e(Netc+N_lead)```. This way you would ensure the replay attack is resolved after a time lag of ```N_lead``` (or one epoch). This would imply that in any future fork replay issues will be resolved after one epoch, as the Transactions Hash field, ```H_e``` in the blockheaders of forks would vary immediately as different transactions start taking place. +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 ```t_0``` we are at block number ```N_t0```. We use block from ```6 epochs``` back which equals ```N_e=6,144 bock``` +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 : ```t_0, t0-24, t_0-48 ... t_0-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 dyanamic 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. From a051331bcc94a280f3147e25d3ba4760d7069171 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 19:29:51 +0200 Subject: [PATCH 16/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 6dd6243..5836b28 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -46,10 +46,10 @@ The value of T_a can be chosen in an arbitrary way if it is constanct e.g. the b 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 ```t_0``` we are at block number ```N_t0```. We use block from ```6 epochs``` back which equals ```N_e=6,144 bock``` -2. Block header hash of relevant reference point block: ```BlockHEaderHash(N_t0 - N_e) = T_a``` +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 : ```t_0, t0-24, t_0-48 ... t_0-168```, which implies at most 7 checks would need to be performed for transactions that would be delayed by 7 days. +4. Validation can then take place with up to 1 weeks of values: ```t_0, t0-24, t_0-48 ... t_0-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 dyanamic 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. +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. From c4adab62a5ac390ac3ae3dc26f7977ff3bc43cbb Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 19:35:36 +0200 Subject: [PATCH 17/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 5836b28..1e3834a 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -40,7 +40,7 @@ Even though this is a much simpler change for implementation compared to other s 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 Netc +### Fixed and Dynamic Variable Usage The value of T_a can be chosen in an arbitrary way if it is constanct 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``` From e7952054df83f54d149ce5ed18932615920b972a Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 22:24:39 +0200 Subject: [PATCH 18/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 1e3834a..0825ce3 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -45,10 +45,10 @@ The value of T_a can be chosen in an arbitrary way if it is constanct e.g. the b 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 ```t_0``` we are at block number ```N_t0```. We use block from ```6 epochs``` back which equals ```N_e=6,144 bock``` +1. At time ```t0``` we are at block number ```N_t0```. We use block from ```6 epochs``` back which equals ```N_e=6,144 bock``` 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: ```t_0, t0-24, t_0-48 ... t_0-168```, which implies at most 7 checks would need to be performed for transactions that would be delayed by 7 days. +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```). From 1d3e8c3a6836c8d8535a7f9df695de42f16bb384 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 22:50:24 +0200 Subject: [PATCH 19/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 0825ce3..3cf2cb5 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -45,7 +45,7 @@ The value of T_a can be chosen in an arbitrary way if it is constanct e.g. the b 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 bock``` +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. From 2a7233ca1554157f0c8e220c91451abf7a5338fa Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Mon, 3 Oct 2016 23:21:52 +0200 Subject: [PATCH 20/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 3cf2cb5..0f2ab28 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -41,7 +41,7 @@ Even though this is a much simpler change for implementation compared to other s 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 constanct 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). +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``` From 56a8238b7d46dc94d789ede017f6edda0e436c0a Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 4 Oct 2016 09:30:44 +0200 Subject: [PATCH 21/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 0f2ab28..5e0e988 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -23,8 +23,7 @@ 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)))``` +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: @@ -41,15 +40,30 @@ Even though this is a much simpler change for implementation compared to other s 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). +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_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``` +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```). -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. +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: -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```). +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] -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. +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 weeks of values: ```t0, t1, t2 ... t7```, which implies at most 7 checks would need to be performed for transactions that are delayed by up to 7 days. + +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. From 368a77bc3fc7b880cbf512f37ccbf8147d149ef1 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 4 Oct 2016 09:31:19 +0200 Subject: [PATCH 22/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 5e0e988..c76868c 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -46,19 +46,19 @@ An alternative method would be to utilize a dynamic value for ```T_a```. One pos 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] +```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] +tn : T_a = BH[Netc - N_l + N_l * n]``` or -tn : T_a = BH[Netc + N_l * (n - 1)] +```tn : T_a = BH[Netc + N_l * (n - 1)]``` where -n = RoundDown[ (N_c - Netc)/N_l ] +```n = RoundDown[ (N_c - Netc)/N_l ]``` ```N_c``` is the most recent block number. From 4c7b8aa22a9b65b740eb51e8b6668fae430f8bf4 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 4 Oct 2016 09:32:00 +0200 Subject: [PATCH 23/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index c76868c..912f3a3 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -46,11 +46,11 @@ An alternative method would be to utilize a dynamic value for ```T_a```. One pos 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]``` +```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 From b0d8778c739ee557b6f9d5eeb156abbcec24c614 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 4 Oct 2016 09:36:05 +0200 Subject: [PATCH 24/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 912f3a3..e872750 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -46,19 +46,25 @@ An alternative method would be to utilize a dynamic value for ```T_a```. One pos 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]``` +``` +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)]``` +``` +tn : T_a = BH[Netc + N_l * (n - 1)] +``` where -```n = RoundDown[ (N_c - Netc)/N_l ]``` +``` +n = RoundDown[ (N_c - Netc)/N_l ] +``` ```N_c``` is the most recent block number. From 43c310ef701638313a1c684d6b985bec7d7e6705 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 4 Oct 2016 09:39:27 +0200 Subject: [PATCH 25/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index e872750..98479b6 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -68,7 +68,7 @@ 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 weeks of values: ```t0, t1, t2 ... t7```, which implies at most 7 checks would need to be performed for transactions that are delayed by up to 7 days. +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```). From afcc98941665182ef6a6f4b17d2c6ebedeaa699c Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 4 Oct 2016 19:12:18 +0200 Subject: [PATCH 26/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 98479b6..1aed9c9 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -5,7 +5,7 @@ Author: Avtar Sehra Status: Draft Type: Standard - Created: 2016-10-02 + 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. From 60147c691b45bc4f41f51653d5b6631c9cf45482 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Wed, 5 Oct 2016 09:17:54 +0200 Subject: [PATCH 27/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 1aed9c9..243fbf2 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -37,9 +37,14 @@ In this way no extra information needs to be added to the transactions to increa 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. +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. -### Fixed and Dynamic Variable Usage +For example the hash of block ```Netc=3,000,000```, which is exepcted to be the Hard Forking block for delaying the Difficulty Bomb. + + +### Fixed and Dynamic Variable Usage (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```). From 11c6e01c7650c1c67eebe46ca2fa897fac79939e Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Thu, 6 Oct 2016 08:42:32 +0200 Subject: [PATCH 28/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 243fbf2..9d5276b 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -78,3 +78,5 @@ In this way validation can then take place using a pool of 1 week of values: ``` 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). From 06140a3e609ba981008df1ec5bfc0d16fac83239 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Thu, 6 Oct 2016 08:43:08 +0200 Subject: [PATCH 29/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 9d5276b..6794ed5 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -44,7 +44,7 @@ The choice of signing variable will be a fixed value, but support for offline tr For example the hash of block ```Netc=3,000,000```, which is exepcted to be the Hard Forking block for delaying the Difficulty Bomb. -### Fixed and Dynamic Variable Usage (For Reference Only) +### Fixed and Dynamic Variable Usage (*** 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```). From 82d144fea9238ede05051693345155aea8fd5e09 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Thu, 6 Oct 2016 08:43:45 +0200 Subject: [PATCH 30/32] Update ECIP1011.md --- ECIPs/ECIP1011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECIPs/ECIP1011.md b/ECIPs/ECIP1011.md index 6794ed5..22f81bd 100644 --- a/ECIPs/ECIP1011.md +++ b/ECIPs/ECIP1011.md @@ -44,7 +44,7 @@ The choice of signing variable will be a fixed value, but support for offline tr For example the hash of block ```Netc=3,000,000```, which is exepcted to be the Hard Forking block for delaying the Difficulty Bomb. -### Fixed and Dynamic Variable Usage (*** For Reference Only ***) +### 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```). From cd12c2c583e8eba4f4d7f366a6464e00c4e67a95 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 21 Feb 2017 22:38:22 +0000 Subject: [PATCH 31/32] Create ECIP1021 --- ECIPs/ECIP1021 | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 ECIPs/ECIP1021 diff --git a/ECIPs/ECIP1021 b/ECIPs/ECIP1021 new file mode 100644 index 0000000..ecf9511 --- /dev/null +++ b/ECIPs/ECIP1021 @@ -0,0 +1,38 @@ +### Title + + ECIP: 1018 + Title: Ethereum Classic (ETC) Fiscal Policy Proposal + Author: Avtar Sehra + 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 + From d8ee0611fba410499a81a86f96e915c26305b847 Mon Sep 17 00:00:00 2001 From: Avtar Sehra Date: Tue, 21 Feb 2017 22:47:18 +0000 Subject: [PATCH 32/32] Update and rename ECIP1021 to ECIP1021.md --- ECIPs/{ECIP1021 => ECIP1021.md} | 1 - 1 file changed, 1 deletion(-) rename ECIPs/{ECIP1021 => ECIP1021.md} (99%) diff --git a/ECIPs/ECIP1021 b/ECIPs/ECIP1021.md similarity index 99% rename from ECIPs/ECIP1021 rename to ECIPs/ECIP1021.md index ecf9511..1ceb110 100644 --- a/ECIPs/ECIP1021 +++ b/ECIPs/ECIP1021.md @@ -10,7 +10,6 @@ ### 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.