Bit boundary fix for the DAG generation routine #223
Conversation
|
Thanks for this. We are running a few sync tests and general otherwise sanity checks, but in general this looks good and unless we find something unexpected we'll have it merged very soon. |
|
I just completed a successful test where I
Node completed sync successfully. I have also run some basic checks on the interoperability of the ethash cache (etchash) data between the current It will probably be safest for miners to regenerate their DAG dirs and caches when they upgrade. |
There was a problem hiding this comment.
LGTM.
Please note comments at ethereum/go-ethereum#21793 (comment), and ethereum/go-ethereum#21793 (comment).
|
@iquidus, please give your review and merge if and when OK by you too. We'll aim for tagging and publishing a release today. |
|
@meowsbits "It will probably be safest for miners to regenerate their DAG dirs and caches when they upgrade." With the https://github.com/etclabscore/core-geth/releases/tag/v1.11.17 release today, would that be your only recommendation? For all Core-Geth users to upgrade and further for miners to regenerate? And it does not appear that any blocks have been mined with broken DAGs, eh? We are not dependent on replicating the bug into the future, right? |
|
Yes, yes, yes, yes! |
If DAG size is exceeding the maximum 32 bit unsigned value, the DAG generation will produce incorrect results depending on the number of threads available on the host machine. Switch the generation to 64 bit variable to fix this.
Note that a hard fork may be required on the ETC network for the time being as we're already on the epoch 385 which generates a DAG file of 4.008 Gb, causing some nodes to reject valid blocks, depending on the conditions under which they have generated a new DAG file under.