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

chainstate only needs the previous block hash #706

Merged
merged 1 commit into from
Jun 21, 2017
Merged

chainstate only needs the previous block hash #706

merged 1 commit into from
Jun 21, 2017

Conversation

dajohi
Copy link
Member

@dajohi dajohi commented May 24, 2017

... not the entire block header.

@dajohi dajohi changed the title chainstate only needs to previous block hash chainstate only needs the previous block hash Jun 8, 2017
Copy link
Member

@davecgh davecgh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK.

I think the name should probably be BestPrevHash instead of BestPrevBlock since the latter seems to imply it's the entire block. I know the header field is actually named PrevBlock (and it probably should've been PrevBlockHash or PrevHash honestly, but that ship has sailed). However, in the case of the header, it is already well known that it's just a hash. In the case of chain, it often deals with actual blocks.

... not the entire block header.
@dajohi
Copy link
Member Author

dajohi commented Jun 21, 2017

updated

Copy link
Contributor

@jolan jolan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

testnet solo-mining tACK.

Mined a few blocks OK. Then turned off voting on my nodes and caused a re-org, got through that OK, now back to normal and still OK.

@davecgh davecgh merged commit 2ffbad1 into decred:master Jun 21, 2017
davecgh added a commit that referenced this pull request Aug 2, 2017
As noted in issue #706, the existing code had an issue where the
normalized result was > P when both the first and second words of the
field representation being normalized were BOTH greater than or equal to
the first and second words of P.  Although this condition is rare in
practice, it needs to be handled properly.

This resolves the issue by comparing the low words in the final
reduction step against the normalized low order prime bits to ensure the
final subtraction occurs correctly any time they're > P.  This approach
retains the constant time property as well.
@dajohi dajohi deleted the chainstate branch February 28, 2019 00:51
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

Successfully merging this pull request may close these issues.

3 participants