From 72fbb3ef2a70a4d747140b6ae2f46859a8e505e1 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 19:42:06 -0400 Subject: [PATCH 01/12] Added initial ASIC-resistant EIP details --- EIPS/eip-X-ASIC-resistant-block-mining.md | 176 ++++++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 EIPS/eip-X-ASIC-resistant-block-mining.md diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md new file mode 100644 index 00000000000000..a93a015c7ac906 --- /dev/null +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -0,0 +1,176 @@ +--- +eip: +title: Poisoning the Well +author: David Stanfill +discussions-to: +status: Draft +type: Standards Track +category Core +created: 2018-04-03 +--- + + +## Simple Summary + +This EIP attempts to break ASIC miners specialized for the current ethash +mining algorithm. + + +## Abstract + +There are companies who currently have dedicated hardware based ethereum miners in +production, and probabalistically actively mining. This EIP aims to "Poison +the well" by modifying the block mining algorithm in a manner that +probabalistically *"breaks"* these miners if they are in-fact built on ASICs. + + +## Motivation + +ASIC based miners will have lower operational costs than GPU based miners which +will result in GPU based mining quickly becoming unprofitable. Given that +production of ASIC based miners has a high barrier to entry, this will cause a +trend towards centralization of mining power. + +This trend towards centralization has a negative effect on network security, +putting significant control of the network in the hands of only a few entities. + +Furthermore, Ethereum was initial designed as an ASIC resistant algorithm and +the community has voiced strong support for making a definitive stand on our position +regarding dedicated mining hardware development to discourage future R&D investments. + +## Specification + +If `block.number >= ASIC_MITIGATION_FORK_BLKNUM`, require that the ethash solution +sealing the block has been mined using `ethashV2`. + +## EthashV2 + +`ethashV2` will be identical in specification to the current `ethash`(v1) algorithm, with +the exception of the implementation of `fnv`. + +The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 +seperate instances defined as fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing +`FNV_PRIME_A=0x10001a7 +FNV_PRIME_B=0x10001ab +FNV_PRIME_C=0x10001cf +FNV_PRIME_D=0x10001e3 +FNV_PRIME_E=0x10001f9` +` + + +`fnvA` replaces `fnv` in the DAG item selection step +`fnvB` replaces `fnv` in the DAG item mix step +`fnvC(fnvD(fnvE` replaces `fnv(fnv(fnv(` in the compress mix step + +`fnv` as utilized in DAG-item creation should remain unchanged. + +## Node Changes + +A new field of `EthashVersion` defined as an 8 bit unsigned enumeration is added to +the the block header. If this field is absent, its value is assumed to be equal to + zero. + +The enumeration should be forward compatible and defined as: +`EthashUndefined = 0x00 +EthashVersion1 = 0x01 +EthashVersion2 = 0x02 +... +EthashVersion255 = 0xFF` + +When this field is present and set to 0x02, the `mine` and `VerifySeal` operations +utilize the `ethashV2` algorithm. If this field is set to any value other than 0x01, +0x02, or 0x00 `VerifySeal` shall reject the block. + +`VerifySeal` shall also fail verification in the event +`block.Number >= ASIC_MITIGATION_FORK_BLKNUM && block.EthashVersion < EthashVersion2` + +## Agent Changes + +GetWork may optionally return the proposed blocks `EthashVersion` field. While a +miner or pool may infer the requirement for ethashV2 based on the computed +epoch of the provided seedHash, it may be beneficial to explicitly provide this +field so a miner does not require special configuration when mining on a chain +that chooses not to implement the ASIC_Mitigation hardfork. + +Due to compatibility concerns with implementations that already add additional +parameters to GetWork, it may be desired to define a 33 Byte BlockHeader, where +the first octet represents the EthashVersion enumeration value desired for the +block. + +## Rationale + +This EIP is aimed at breaking existing ASIC based miners via small changes to the +existing ethash algorithm. We hope to accomplish the following: + +1. Break existing ASIC based miners. +2. Demonstrate a willingness to fork in the event of future ASIC miner production. + +Goal #1 is something that we can only do probabalistically without detailned +knowledge of existing ASIC miner design. Our approach should balance the +inherent security risks involved with changing the mining algorithm with the +risk that the change we make does not break existing ASIC miners. This EIP +leans towards minimizing the security risks by making minimal changes to the +algorithm accepting the risk that the change may not break dedicated hardware +miners that utilize partially or fully configurable logic. + +Furthermore, we do not wish to introduce significant algorithm changes that +may alter the power utilization or performance profile of existing GPU hardware. + +The change of FNV constant is a minimal change that can be quickly +implemented across the various network node and miner implementations. + +It is proposed that `ASIC_MITIGATION_FORK_BLKNUM` be no more than 5550000, giving +around 30 days of notice to node and miner developers and a sufficient window +for formal analysis of the changes by experts. We must weight this window against +the risk introduced by allowing ASICs to continue to probalistically propagate +on the network, as well as the risk of providing too much advanced warning to +ASIC developers. + +It is further understood that this change will not prevent redesign of existing +dedicated hardware with new ASIC chips. The intention of this change is only +to disable currently active or mid-production hardware and provide time for +POS development as well as larger algorithim changes to be well analyzed by +experts. + +The choice of FNV constants is made based on the formal specification at +https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1 + +Typical ASIC synthesis tools would optimize multiplication of a constant +in the FNV algorithm, reducing the area needed for the multiplier according +to the hamming weight of the constant. To reduce the chance of ASIC adaptation +through minor Mask changes, we propose choosing new constants with a larger +hamming weight, however care should be taken not to choose constants with too +large of weight. + +The current FNV prime, 0x1000193 has a hamming weight of 6. +`HammingWeight(0x10001a7) = 7; +HammingWeight(0x10001ab) = 7; +HammingWeight(0x10001cf) = 8; +HammingWeight(0x10001e3) = 7; +HammingWeight(0x10001ef) = 9; // Not chosen +HammingWeight(0x10001f9) = 8; +HammingWeight(0x10001fb) = 9; // Not chosen + +An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193. + +TODO - results of dispersion analysis + +## Backwards Compatibility + +This change implements a backwards incompatable change to proof of work based +block mining. All existing miners will be required to update to clients which +implement this new algorithm, and all nodes will require updates to accept +solutions from the new proof of work algorithm. + +## Test Cases + +TODO: will need to generate test cases for `ethereum/tests` repository corresponding to the consensus +changes. + +## Implementation + +TODO + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From bee324394d734e24f99d89a7ba0eea963d38fed5 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 19:49:09 -0400 Subject: [PATCH 02/12] Format fixed --- EIPS/eip-X-ASIC-resistant-block-mining.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index a93a015c7ac906..488c9b0fc43e0f 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -49,13 +49,12 @@ sealing the block has been mined using `ethashV2`. the exception of the implementation of `fnv`. The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 -seperate instances defined as fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing +seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing `FNV_PRIME_A=0x10001a7 FNV_PRIME_B=0x10001ab FNV_PRIME_C=0x10001cf FNV_PRIME_D=0x10001e3 FNV_PRIME_E=0x10001f9` -` `fnvA` replaces `fnv` in the DAG item selection step From bd886fc836c75e991c934079bdc97e0a7a8825dd Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 19:49:59 -0400 Subject: [PATCH 03/12] Format fixed --- EIPS/eip-X-ASIC-resistant-block-mining.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index 488c9b0fc43e0f..f2ecfd64c73d39 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -50,11 +50,12 @@ the exception of the implementation of `fnv`. The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing -`FNV_PRIME_A=0x10001a7 -FNV_PRIME_B=0x10001ab -FNV_PRIME_C=0x10001cf -FNV_PRIME_D=0x10001e3 -FNV_PRIME_E=0x10001f9` + +`FNV_PRIME_A=0x10001a7` +`FNV_PRIME_B=0x10001ab` +`FNV_PRIME_C=0x10001cf` +`FNV_PRIME_D=0x10001e3` +`FNV_PRIME_E=0x10001f9` `fnvA` replaces `fnv` in the DAG item selection step From 680e684970b63d2ac91116ee1a5f54a1f65132b8 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 19:51:39 -0400 Subject: [PATCH 04/12] Format fixed --- EIPS/eip-X-ASIC-resistant-block-mining.md | 33 ++++++++++++----------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index f2ecfd64c73d39..4fa4dfd9092e23 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -51,11 +51,11 @@ the exception of the implementation of `fnv`. The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing -`FNV_PRIME_A=0x10001a7` -`FNV_PRIME_B=0x10001ab` -`FNV_PRIME_C=0x10001cf` -`FNV_PRIME_D=0x10001e3` -`FNV_PRIME_E=0x10001f9` +`FNV_PRIME_A=0x10001a7` +`FNV_PRIME_B=0x10001ab` +`FNV_PRIME_C=0x10001cf` +`FNV_PRIME_D=0x10001e3` +`FNV_PRIME_E=0x10001f9` `fnvA` replaces `fnv` in the DAG item selection step @@ -71,10 +71,10 @@ the the block header. If this field is absent, its value is assumed to be equal zero. The enumeration should be forward compatible and defined as: -`EthashUndefined = 0x00 -EthashVersion1 = 0x01 -EthashVersion2 = 0x02 -... +`EthashUndefined = 0x00 +EthashVersion1 = 0x01 +EthashVersion2 = 0x02 +... EthashVersion255 = 0xFF` When this field is present and set to 0x02, the `mine` and `VerifySeal` operations @@ -143,13 +143,14 @@ hamming weight, however care should be taken not to choose constants with too large of weight. The current FNV prime, 0x1000193 has a hamming weight of 6. -`HammingWeight(0x10001a7) = 7; -HammingWeight(0x10001ab) = 7; -HammingWeight(0x10001cf) = 8; -HammingWeight(0x10001e3) = 7; -HammingWeight(0x10001ef) = 9; // Not chosen -HammingWeight(0x10001f9) = 8; -HammingWeight(0x10001fb) = 9; // Not chosen +`HammingWeight(0x10001a7) = 7; +HammingWeight(0x10001ab) = 7; +HammingWeight(0x10001cf) = 8; +HammingWeight(0x10001e3) = 7; +HammingWeight(0x10001ef) = 9; // Not chosen +HammingWeight(0x10001f9) = 8; +HammingWeight(0x10001fb) = 9; // Not chosen +` An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193. From 09400c2ddf81264f93cc7375ec5d47af185af394 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 19:52:30 -0400 Subject: [PATCH 05/12] Format fixed --- EIPS/eip-X-ASIC-resistant-block-mining.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index 4fa4dfd9092e23..d456808f8df184 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -143,14 +143,13 @@ hamming weight, however care should be taken not to choose constants with too large of weight. The current FNV prime, 0x1000193 has a hamming weight of 6. -`HammingWeight(0x10001a7) = 7; -HammingWeight(0x10001ab) = 7; -HammingWeight(0x10001cf) = 8; -HammingWeight(0x10001e3) = 7; -HammingWeight(0x10001ef) = 9; // Not chosen -HammingWeight(0x10001f9) = 8; -HammingWeight(0x10001fb) = 9; // Not chosen -` +`HammingWeight(0x10001a7) = 7;` +`HammingWeight(0x10001ab) = 7;` +`HammingWeight(0x10001cf) = 8;` +`HammingWeight(0x10001e3) = 7;` +`HammingWeight(0x10001ef) = 9; // Not chosen` +`HammingWeight(0x10001f9) = 8;` +`HammingWeight(0x10001fb) = 9; // Not chosen` An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193. From b8e73d8836e48b70ff74cd142a797a680f7bd15c Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 19:52:52 -0400 Subject: [PATCH 06/12] Format fixed --- EIPS/eip-X-ASIC-resistant-block-mining.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index d456808f8df184..365af5eabce6b1 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -142,7 +142,7 @@ through minor Mask changes, we propose choosing new constants with a larger hamming weight, however care should be taken not to choose constants with too large of weight. -The current FNV prime, 0x1000193 has a hamming weight of 6. +The current FNV prime, 0x1000193 has a hamming weight of 6. `HammingWeight(0x10001a7) = 7;` `HammingWeight(0x10001ab) = 7;` `HammingWeight(0x10001cf) = 8;` From 214eb59d73b11c1c89e3d38d6e49a686cdd5ad02 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 20:05:46 -0400 Subject: [PATCH 07/12] Grammar fixes --- EIPS/eip-X-ASIC-resistant-block-mining.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index 365af5eabce6b1..ff414bc408ad19 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -34,7 +34,7 @@ trend towards centralization of mining power. This trend towards centralization has a negative effect on network security, putting significant control of the network in the hands of only a few entities. -Furthermore, Ethereum was initial designed as an ASIC resistant algorithm and +Furthermore, Ethereum was initially designed as an ASIC resistant algorithm and the community has voiced strong support for making a definitive stand on our position regarding dedicated mining hardware development to discourage future R&D investments. @@ -94,8 +94,8 @@ that chooses not to implement the ASIC_Mitigation hardfork. Due to compatibility concerns with implementations that already add additional parameters to GetWork, it may be desired to define a 33 Byte BlockHeader, where -the first octet represents the EthashVersion enumeration value desired for the -block. +the first octet represents the EthashVersion enumeration value required for the +block. If this octet is not present, it may be assumed to be zero. ## Rationale @@ -105,7 +105,7 @@ existing ethash algorithm. We hope to accomplish the following: 1. Break existing ASIC based miners. 2. Demonstrate a willingness to fork in the event of future ASIC miner production. -Goal #1 is something that we can only do probabalistically without detailned +Goal #1 is something that we can only do probabalistically without detailed knowledge of existing ASIC miner design. Our approach should balance the inherent security risks involved with changing the mining algorithm with the risk that the change we make does not break existing ASIC miners. This EIP @@ -119,9 +119,9 @@ may alter the power utilization or performance profile of existing GPU hardware. The change of FNV constant is a minimal change that can be quickly implemented across the various network node and miner implementations. -It is proposed that `ASIC_MITIGATION_FORK_BLKNUM` be no more than 5550000, giving +It is proposed that `ASIC_MITIGATION_FORK_BLKNUM` be no more than 5550000 (epoch 185), giving around 30 days of notice to node and miner developers and a sufficient window -for formal analysis of the changes by experts. We must weight this window against +for formal analysis of the changes by experts. We must weigh this window against the risk introduced by allowing ASICs to continue to probalistically propagate on the network, as well as the risk of providing too much advanced warning to ASIC developers. @@ -138,7 +138,7 @@ https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1 Typical ASIC synthesis tools would optimize multiplication of a constant in the FNV algorithm, reducing the area needed for the multiplier according to the hamming weight of the constant. To reduce the chance of ASIC adaptation -through minor Mask changes, we propose choosing new constants with a larger +through minor mask changes, we propose choosing new constants with a larger hamming weight, however care should be taken not to choose constants with too large of weight. From 7d82f1c24e43972f7b05d6eb0f00952740bcc652 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 20:33:46 -0400 Subject: [PATCH 08/12] Added mention of more invasive hash algorithm replacements --- EIPS/eip-X-ASIC-resistant-block-mining.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index ff414bc408ad19..f37150b2e1f7fb 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -153,7 +153,11 @@ The current FNV prime, 0x1000193 has a hamming weight of 6. An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193. -TODO - results of dispersion analysis +It can be empirically confirmed that no duplicates occur in the 32 bit word space with these constants. + +It is worth noting that FNV is not a cryptographic hash, and it is not used as such in ethash. With +that said, a more invasive hash algorithm change could consider other options. One suggestion has been +MurmorHash3 (https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp) ## Backwards Compatibility From bdfc94817decd40e2423e77a684fe3b974a781d8 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 20:36:32 -0400 Subject: [PATCH 09/12] Added mention of the single duplicate in 0x010001cf --- EIPS/eip-X-ASIC-resistant-block-mining.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index f37150b2e1f7fb..84a437caef8749 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -153,7 +153,7 @@ The current FNV prime, 0x1000193 has a hamming weight of 6. An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193. -It can be empirically confirmed that no duplicates occur in the 32 bit word space with these constants. +It can be empirically confirmed that no more than 1 duplicates occur in the 32 bit word space with these constants. It is worth noting that FNV is not a cryptographic hash, and it is not used as such in ethash. With that said, a more invasive hash algorithm change could consider other options. One suggestion has been From 2a0858af36d13b074134aed6a9e731c15893563b Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Tue, 3 Apr 2018 22:49:28 -0400 Subject: [PATCH 10/12] Adjusted language to remove speculation and focus on the purpose and motivation of this pull request --- EIPS/eip-X-ASIC-resistant-block-mining.md | 24 ++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-X-ASIC-resistant-block-mining.md index 84a437caef8749..f096c93473d560 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-X-ASIC-resistant-block-mining.md @@ -19,24 +19,26 @@ mining algorithm. ## Abstract There are companies who currently have dedicated hardware based ethereum miners in -production, and probabalistically actively mining. This EIP aims to "Poison -the well" by modifying the block mining algorithm in a manner that -probabalistically *"breaks"* these miners if they are in-fact built on ASICs. +production, and may be actively mining. This EIP aims to "poison +the well" by modifying the block mining algorithm in a low risk manner that +may *"break"* these miners if they are in-fact built as traditional ASICs. ## Motivation ASIC based miners will have lower operational costs than GPU based miners which will result in GPU based mining quickly becoming unprofitable. Given that -production of ASIC based miners has a high barrier to entry, this will cause a -trend towards centralization of mining power. +production of ASIC based miners has a high barrier to entry and few market players, +this will cause a trend towards centralization of mining power. This trend towards centralization has a negative effect on network security, putting significant control of the network in the hands of only a few entities. -Furthermore, Ethereum was initially designed as an ASIC resistant algorithm and -the community has voiced strong support for making a definitive stand on our position -regarding dedicated mining hardware development to discourage future R&D investments. +Ethash remains ASIC resistant, however ASIC manufacturer technology is advancing +and ethash may require further changes in order to remain resistant to unforeseen +design techniques. This EIP seeks explicitly to buy time during which newly developed +ASIC technology will face a barrier while more long term mechanisms to ensure +continued ASIC resistance can be explored. ## Specification @@ -64,7 +66,7 @@ seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utiliz `fnv` as utilized in DAG-item creation should remain unchanged. -## Node Changes +## Node Changes (Optional Variant) A new field of `EthashVersion` defined as an 8 bit unsigned enumeration is added to the the block header. If this field is absent, its value is assumed to be equal to @@ -84,7 +86,7 @@ utilize the `ethashV2` algorithm. If this field is set to any value other than 0 `VerifySeal` shall also fail verification in the event `block.Number >= ASIC_MITIGATION_FORK_BLKNUM && block.EthashVersion < EthashVersion2` -## Agent Changes +## Agent Changes (Optional Variant, stand alone or combined with Node Changes) GetWork may optionally return the proposed blocks `EthashVersion` field. While a miner or pool may infer the requirement for ethashV2 based on the computed @@ -122,7 +124,7 @@ implemented across the various network node and miner implementations. It is proposed that `ASIC_MITIGATION_FORK_BLKNUM` be no more than 5550000 (epoch 185), giving around 30 days of notice to node and miner developers and a sufficient window for formal analysis of the changes by experts. We must weigh this window against -the risk introduced by allowing ASICs to continue to probalistically propagate +the risk introduced by allowing ASICs that may exist to continue to propagate on the network, as well as the risk of providing too much advanced warning to ASIC developers. From 444ff3dccbb8238df5854920958a7bb15becf1a4 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Wed, 4 Apr 2018 10:09:11 -0400 Subject: [PATCH 11/12] Assigned EIP number and discussion URL, altered language to be more descriptive about the intention and risk. Removed unneeded Concensus/Block field changes. --- ...C-resistant-block-mining.md => eip-969.md} | 47 +++++++------------ 1 file changed, 16 insertions(+), 31 deletions(-) rename EIPS/{eip-X-ASIC-resistant-block-mining.md => eip-969.md} (81%) diff --git a/EIPS/eip-X-ASIC-resistant-block-mining.md b/EIPS/eip-969.md similarity index 81% rename from EIPS/eip-X-ASIC-resistant-block-mining.md rename to EIPS/eip-969.md index f096c93473d560..a5207ab072ebee 100644 --- a/EIPS/eip-X-ASIC-resistant-block-mining.md +++ b/EIPS/eip-969.md @@ -1,18 +1,18 @@ --- -eip: -title: Poisoning the Well +eip: 969 +title: Modifications to ethash to invalidate dedicated hardware implementations author: David Stanfill -discussions-to: +discussions-to: https://gitter.im/ethereum/topics/topic/5ac4d974109bb043328911ce/eip-969-discussion status: Draft type: Standards Track -category Core +category: Core created: 2018-04-03 --- ## Simple Summary -This EIP attempts to break ASIC miners specialized for the current ethash +This EIP modifies ethash in order to break ASIC miners specialized for the current ethash mining algorithm. @@ -31,6 +31,10 @@ will result in GPU based mining quickly becoming unprofitable. Given that production of ASIC based miners has a high barrier to entry and few market players, this will cause a trend towards centralization of mining power. +Risks include market dominance by a single manufacturer that may utilize production +stock to mine themselves, introduce backdoors in their hardware, or otherwise +facilitate a 51% attack that would be infeasible. + This trend towards centralization has a negative effect on network security, putting significant control of the network in the hands of only a few entities. @@ -66,38 +70,19 @@ seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utiliz `fnv` as utilized in DAG-item creation should remain unchanged. -## Node Changes (Optional Variant) - -A new field of `EthashVersion` defined as an 8 bit unsigned enumeration is added to -the the block header. If this field is absent, its value is assumed to be equal to - zero. - -The enumeration should be forward compatible and defined as: -`EthashUndefined = 0x00 -EthashVersion1 = 0x01 -EthashVersion2 = 0x02 -... -EthashVersion255 = 0xFF` - -When this field is present and set to 0x02, the `mine` and `VerifySeal` operations -utilize the `ethashV2` algorithm. If this field is set to any value other than 0x01, -0x02, or 0x00 `VerifySeal` shall reject the block. - -`VerifySeal` shall also fail verification in the event -`block.Number >= ASIC_MITIGATION_FORK_BLKNUM && block.EthashVersion < EthashVersion2` - -## Agent Changes (Optional Variant, stand alone or combined with Node Changes) +## Agent Changes (Optional Variant) -GetWork may optionally return the proposed blocks `EthashVersion` field. While a +GetWork may optionally return the proposed blocks algorithm. While a miner or pool may infer the requirement for ethashV2 based on the computed -epoch of the provided seedHash, it may be beneficial to explicitly provide this +epoch of the provided seedHash, it is beneficial to explicitly provide this field so a miner does not require special configuration when mining on a chain that chooses not to implement the ASIC_Mitigation hardfork. Due to compatibility concerns with implementations that already add additional -parameters to GetWork, it may be desired to define a 33 Byte BlockHeader, where -the first octet represents the EthashVersion enumeration value required for the -block. If this octet is not present, it may be assumed to be zero. +parameters to GetWork, it is desired to add BlockNumber as an explicit 4th parameter +as suggested https://github.com/ethereum/go-ethereum/issues/2333. Algorithm +should then be returned as either `"ethash"` or `"ethashV2"` according to the +`block.number >= ASIC_MITIGATION_FORK_BLKNUM` criteria. ## Rationale From 5be0c8a2a84cd995a2c9613d07b4f57a5faf70c4 Mon Sep 17 00:00:00 2001 From: David Stanfill Date: Wed, 4 Apr 2018 11:21:57 -0400 Subject: [PATCH 12/12] Clarified FNV rational, provided code for basic sanity FNV candidate analysis and FNV selection, grammar fixes --- EIPS/eip-969.md | 67 +++++++++++++++++++++++++++++++++++++------------ 1 file changed, 51 insertions(+), 16 deletions(-) diff --git a/EIPS/eip-969.md b/EIPS/eip-969.md index a5207ab072ebee..cc3c69c25ddafb 100644 --- a/EIPS/eip-969.md +++ b/EIPS/eip-969.md @@ -1,6 +1,6 @@ --- eip: 969 -title: Modifications to ethash to invalidate dedicated hardware implementations +title: Modifications to ethash to invalidate existing dedicated hardware implementations author: David Stanfill discussions-to: https://gitter.im/ethereum/topics/topic/5ac4d974109bb043328911ce/eip-969-discussion status: Draft @@ -55,7 +55,7 @@ sealing the block has been mined using `ethashV2`. the exception of the implementation of `fnv`. The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 -seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing +separate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing `FNV_PRIME_A=0x10001a7` `FNV_PRIME_B=0x10001ab` @@ -72,15 +72,15 @@ seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utiliz ## Agent Changes (Optional Variant) -GetWork may optionally return the proposed blocks algorithm. While a -miner or pool may infer the requirement for ethashV2 based on the computed +The JSON-RPC `eth_GetWork` call may optionally return the proposed blocks algorithm. +While a miner or pool may infer the requirement for ethashV2 based on the computed epoch of the provided seedHash, it is beneficial to explicitly provide this field so a miner does not require special configuration when mining on a chain that chooses not to implement the ASIC_Mitigation hardfork. Due to compatibility concerns with implementations that already add additional parameters to GetWork, it is desired to add BlockNumber as an explicit 4th parameter -as suggested https://github.com/ethereum/go-ethereum/issues/2333. Algorithm +as suggested in https://github.com/ethereum/go-ethereum/issues/2333. Algorithm should then be returned as either `"ethash"` or `"ethashV2"` according to the `block.number >= ASIC_MITIGATION_FORK_BLKNUM` criteria. @@ -92,13 +92,16 @@ existing ethash algorithm. We hope to accomplish the following: 1. Break existing ASIC based miners. 2. Demonstrate a willingness to fork in the event of future ASIC miner production. -Goal #1 is something that we can only do probabalistically without detailed -knowledge of existing ASIC miner design. Our approach should balance the -inherent security risks involved with changing the mining algorithm with the -risk that the change we make does not break existing ASIC miners. This EIP -leans towards minimizing the security risks by making minimal changes to the -algorithm accepting the risk that the change may not break dedicated hardware -miners that utilize partially or fully configurable logic. +Goal #1 is something that we can only do probabilistically without detailed +knowledge of existing ASIC miner design. The known released miner is available for +purchase at https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7 +with delivery slated for mid-summer. + +Our approach should balance the inherent security risks involved with changing +the mining algorithm with the risk that the change we make does not break existing + ASIC miners. This EIP leans towards minimizing the security risks by making minimal + changes to the algorithm accepting the risk that the change may not break dedicated + hardware miners that utilize partially or fully configurable logic. Furthermore, we do not wish to introduce significant algorithm changes that may alter the power utilization or performance profile of existing GPU hardware. @@ -122,12 +125,20 @@ experts. The choice of FNV constants is made based on the formal specification at https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1 +@goobur provided the following python code to output primes matching this criteria + +`candidates = [2**24 + 2**8 + _ for _ in xrange(256)]`
+`candidates = [_ for _ in candidates if is_prime(_)]`
+`["0x%x" % _ for _ in candidates if _ % (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7)]`
+ +The minimal prime constraint was relaxed, as has already been the case in ethashV1. + Typical ASIC synthesis tools would optimize multiplication of a constant -in the FNV algorithm, reducing the area needed for the multiplier according +in the FNV algorithm, while reducing the area needed for the multiplier according to the hamming weight of the constant. To reduce the chance of ASIC adaptation through minor mask changes, we propose choosing new constants with a larger hamming weight, however care should be taken not to choose constants with too -large of weight. +large of a weight. The current FNV prime, 0x1000193 has a hamming weight of 6. `HammingWeight(0x10001a7) = 7;` @@ -138,7 +149,25 @@ The current FNV prime, 0x1000193 has a hamming weight of 6. `HammingWeight(0x10001f9) = 8;` `HammingWeight(0x10001fb) = 9; // Not chosen` -An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193. +An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193 +using the following process. + +``` +uint32_t candidate = 0; +uint32_t dups = 0; +uint32_t fnv_candidate = 0x10001a7; +uint8_t *counts = malloc(0xFFFFFFFF); +memset(counts, '\0', 0xFFFFFFFF); +for ( candidate = 0; candidate <= 0xFFFFFFFF; candidate++) { + uint32_t result = (uint_32)(candidate * fnv_candidate); + uint8_t oldCount = counts[result]; + counts[result] = counts[result]+1; + if (oldCount != 0) { + dups++; + } +} +printf("Candidate 0x%08x : %i dups", dups); +``` It can be empirically confirmed that no more than 1 duplicates occur in the 32 bit word space with these constants. @@ -146,9 +175,15 @@ It is worth noting that FNV is not a cryptographic hash, and it is not used as s that said, a more invasive hash algorithm change could consider other options. One suggestion has been MurmorHash3 (https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp) +Other suggestions have been made for complete algorithm changes, including off-the-shelf solutions +such as Argon2, Equihash of Zcash fame, and Balloon Hashing. +(https://twitter.com/el33th4xor/status/981292363627810818). This may be considered once +the exact mechanism of the released ASICs is known and their effectiveness against its optimisations +can be fully evaluated. + ## Backwards Compatibility -This change implements a backwards incompatable change to proof of work based +This change implements a backwards incompatible change to proof of work based block mining. All existing miners will be required to update to clients which implement this new algorithm, and all nodes will require updates to accept solutions from the new proof of work algorithm.