We propose an alternate proof-of-work algorithm tuned for commodity hardware in order to close the efficiency gap available to specialized ASICs. Thanks in advance for your thoughts and comments!
Did you implement the OpenCL and CUDA changes there?
I started a new implementation of ethash on a side: https://github.com/chfast/ethash. This is now used in ethminer, partly used in cpp-ethereum and is going to be used in ethereum-js and maybe in Python clients. The library also has good test coverage and testable big-endian support. It might be easier to present your changes there and later depend on other projects to pull in the library.
Thanks for the tip! We will take a look at your ethash. We hope you can continue to provide helpful advice for this effort.
We did optimize for both OpenCL and CUDA in our miner code. This was important to give a fair shake to the capabilities of different GPU implementations.
The reference to the upstream project was dropped when I cloned the project into an initially private repo. Once I made it public, the reference wasn’t restored.
Hi chfast, could you remind me how ethminer/cpp-ethereum using https://github.com/chfast/ethash? I don’t see any chfast/ethash’s file used by ethminer and eth.
The chfast/ethash library is a package in Hunter package manager.
ethminer uses it to get metadata about the epoch context (light cache size, full dataset size, etc) and to verify solutions coming from GPUs. It also uses keccak implementation from ethash.
cpp-ethereum uses only keccak implementation from ethash. The legacy ethash library is still in use in cpp-ethereum (libethash dir). I’m working on API changes in chfast/ethash to allow full replacement of ethash library in cpp-ethereum.
I got, chfast. Thx for your explanation.
I would like to know if there is a implementation for go-ethereum also?
Is the fnv1a change related to this discussion? https://gitter.im/ethereum-mining/ethminer?at=5b1a1af1144c8c6fea7d40ca
The functions like ROTL32, clz, popcount should be specified together with cases that are undefined behavior in C.
Please clarify the Keccak hash function params.
You stated that the bitrate is 448, so the output size is 176 (!) because 800 - 2*176 = 448. But the actually output was truncated to 64-bits. There is no padding (I have to read that from the implementation!). So the name should look like
Maybe just name this weirdo
Edit: in other place 256 bits are taken from the Keccak state (while by the spec the output has only 176 bits). Is this allowed by the Keccak spec?
The implementation of
keccak_f800 takes a header hash and interprets it as an array of 8 32-bit words. This will give different results on big-endian architectures. See https://github.com/chfast/ethash/pull/79.
The EIP states:
If the program only changed every DAG epoch (roughly 5 days) certain miners could have time to develop hand-optimized versions of the random sequence, giving them an undue advantage.
I’m curious what kind of optimization would only be possible by hand here. Do you have any examples?