-
Notifications
You must be signed in to change notification settings - Fork 20.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eth_getWork RPC call is missing block number of seed hash #2333
Comments
If you are going to add block number as additional parameter for getWork response, please append in to array, not prepend for backward compatibility. Also would be cool to also get both number and difficulty from getBlockByNumber as part of getWork. Currently there is no way to get consistent result with 2 rpc calls. |
I don't think the block number is required at all. You can infer the epoch for the dag from the seed hash itself, that's also how ethminer does it |
Epoch is epoch, I need a block number for logging. |
http://ethereum.stackexchange.com/questions/8341/pool-mining-how-is-dag-generation-possible-without-knowing-the-block-number if anybody knows please answer on SO. |
Another reason for implementing this feature is that Parity already has a 4th parameter. See https://github.com/ethcore/parity/wiki/JSONRPC-eth-module#eth_getwork |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
The eth_getWork rpc call appears to be missing the block number of the seed hash needed to compute a DAG for mining. From reading the documentation I need two parameters to generate a DAG, a seed hash and the corresponding block number of that seed hash. Based on that the only way to generate a DAG is to make a separate RPC call such as an eth_blocknumber call and then use that to infer the block number of the seed hash, but that doesn't seem to be the right way to do this.
The text was updated successfully, but these errors were encountered: