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
bugfix: throw an error if an invalid parameter is passed to getnetworkhashps RPC #28554
bugfix: throw an error if an invalid parameter is passed to getnetworkhashps RPC #28554
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 057b3e0
057b3e0
to
6074de6
Compare
reACK 6074de6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to do this. Not sure if a release note is needed, because strictly speaking this could be a breaking change.
786ba64
to
1fd3715
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
nit: Remove pb == nullptr
check below, as it is no longer possible.
reACK 1fd3715 |
lgtm ACK 1fd3715 |
1fd3715
to
ec54efd
Compare
Upon further inspection I realized that the "lookup" nblocks parameter also had insufficient validation so I've added checks to ensure that it's either a positive number or -1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure about the last change
7198be5
to
565ad11
Compare
565ad11
to
435ff29
Compare
Not sure what's going on with the windows build; it failed on a wallet address test with a socket timeout. Seems unrelated to my PR. Looks like it's a known issue. #28509 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lightly tested ACK 435ff29
Any further concerns? |
…oint Github-Pull: bitcoin#28554 Rebased-From: 435ff29
435ff29
to
9ac114e
Compare
Thanks for rebasing. re-utACK 9ac114e |
reACK 9ac114e |
ACK 9ac114e |
…oint Github-Pull: bitcoin#28554 Rebased-From: 9ac114e
When writing some scripts that iterated over many blocks to generate hashrate estimates I realized that my script was going out of range of the current chain tip height but was not encountering any errors.
I believe that passing an invalid block height to this function but receiving the hashrate estimate for the chain tip instead should be considered unexpected behavior.