You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our proof of work algorithm incorrectly produces a predictable series of nonces, which would allow a dishonest node to modify or replace the chain. See our wiki for more details.
This issue was uncovered in the dvf github that is the ancestor to this chain. I don't think they have corrected it yet, but you can find a proposed fix in the issues list.
The text was updated successfully, but these errors were encountered:
I have re-read the Mastering Bitcoin chapter on mining and confirmed that its proof of work algorithm compares the difficulty target with the hash of the header of the candidate block, which includes the nonce, the transaction Merkle root, the target itself, and the previous block hash.
The book doesn't say why it is done this way, but it makes intuitive sense that the proof for a given block incorporates all of its validated data, plus the existing chain (via the previous block hash). If the proof only included the previous block hash, then any block at the tip of a chain with valid transactions would have to be considered valid as long as it had the right nonce. Nodes with different but valid blocks would build on them causing permanent forks.
Also note that as hashing power has increased, miners often run through all possible nonce values without hitting the target. They can increase the effective range of nonce values by updating the candidate block's timestamp and re-running the nonce values, or adding an extra nonce to the coinbase transaction. Of course to do this they must include the candidate block in the proof algorithm.
If I am missing something let me know; meanwhile I will continue with using the candidate block in the proof of work.
Our proof of work algorithm incorrectly produces a predictable series of nonces, which would allow a dishonest node to modify or replace the chain. See our wiki for more details.
This issue was uncovered in the dvf github that is the ancestor to this chain. I don't think they have corrected it yet, but you can find a proposed fix in the issues list.
The text was updated successfully, but these errors were encountered: