Skip to content
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

Need to correct the proof of work algorithm #11

Open
jcopley opened this issue Nov 3, 2017 · 2 comments
Open

Need to correct the proof of work algorithm #11

jcopley opened this issue Nov 3, 2017 · 2 comments
Assignees

Comments

@jcopley
Copy link

jcopley commented Nov 3, 2017

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.

@rcherukuri83
Copy link

need to priortize this issue .. looking for an assignee

@jcopley jcopley self-assigned this Nov 16, 2017
@jcopley
Copy link
Author

jcopley commented Nov 16, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants