status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 969 

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing draft EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
David Stanfill 2018-04-06 09:15:32 -04:00 committed by EIP Automerge Bot
parent ea5b7b32fe
commit 9fba86e56d
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
EIPS/eip-969.md
View File

@ -94,8 +94,7 @@ existing ethash algorithm. We hope to accomplish the following:
Goal #1 is something that we can only do probabilistically without detailed 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 knowledge of existing ASIC miner design. The known released miner is available for
purchase at https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7 purchase [here](https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7) with delivery slated for mid-summer.
with delivery slated for mid-summer.
Our approach should balance the inherent security risks involved with changing 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 the mining algorithm with the risk that the change we make does not break existing
@ -173,13 +172,14 @@ It can be empirically confirmed that no more than 1 duplicates occur in the 32 b
It is worth noting that FNV is not a cryptographic hash, and it is not used as such in ethash. With 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 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) [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 [Other suggestions have been made](https://twitter.com/el33th4xor/status/981292363627810818). [Argon2](https://github.com/P-H-C/phc-winner-argon2), [Equihash](https://blog.z.cash/why-equihash/) of Zcash fame, and [Balloon Hashing](https://crypto.stanford.edu/balloon/).
such as Argon2, Equihash of Zcash fame, and Balloon Hashing.
(https://twitter.com/el33th4xor/status/981292363627810818). This may be considered once Another possible candidate is [Cuckoo Cycle](https://github.com/tromp/cuckoo), although there are some concerns regarding unaddressed optimization vulnerabilities. One review is found [here](https://da-data.blogspot.com/2014/03/a-public-review-of-cuckoo-cycle.html)
the exact mechanism of the released ASICs is known and their effectiveness against its optimisations
can be fully evaluated. 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 ## Backwards Compatibility