-
Notifications
You must be signed in to change notification settings - Fork 624
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
Add check to max difficulty transition threshold #2337
Add check to max difficulty transition threshold #2337
Conversation
Note, this is an API breaking change. Done on purpose so users have to decided what to do about the network. |
Note this cannot be backported because we didn't have the max attainable consts yet in the last release. |
We also need to check that our minimum shift doesn't go below 1. (And unlike the maximum, the minimum limit has actually been hit on the mainchain many times.) |
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 205b8c7
Yeah, ACK with fixed minimum.
We could backport those. But it can't be backported because it's a breaking change. :) And while it's a bugfix it's easily solvable in user code. We should probably actually backport the constants - but only the constants and tell people to manually implement the check for now. |
205b8c7
to
2499a15
Compare
Add check for not less than 1 to minimun transition threshold. |
Pull Request Test Coverage Report for Build 8515679554Details
💛 - Coveralls |
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 2499a15
2499a15
to
8f3537b
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.
ACK 8f3537b
77ea0c3
to
1f2d561
Compare
1f2d561
to
14ab447
Compare
477077f
to
7518706
Compare
I've split the PR up into multiple patches so each patch does one conceptual thing. |
7518706
to
a5d60c7
Compare
CI failure looks real. |
I added 16e64ef at the front of the PR to do the clippy allow. No other changes. |
1ed6e54
to
aa4591d
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.
ACK aa4591d
@sanket1729 this only has rebases since you last acked.
|
0ca5a43 hashes: Bump version to v0.14.0 (Tobin C. Harding) Pull request description: In preparation for release add a changlelog entry and bump the version. Note the hashes 0.13.0 dependency stays in the dependency graph because of secp, we can update secp after releasing `hashes` then update the secp dependency in `rust-bitcoin` thereby removing the `hashes v0.13.0` dependency - phew. Note we are right to release this immediately, the two open PRs (#2337 and #2541) that touch `hashes` only add a clippy attribute so can safely be ignored. ACKs for top commit: apoelstra: ACK 0ca5a43 sanket1729: ACK 0ca5a43 Tree-SHA512: d1d26acb8fbf13f785b25add3f1dac05bb392b5bdbad16ead2bc5dd26f3d668824c4b653c373f88c3562a37e775146766680606cedd19db40e0f197b26ca86b8
aa4591d
to
1dd3444
Compare
This lint triggers when parsing a reference to a large struct as a generic argument, which is wrong. Allow it crate wide because [subjectively] this lint never warns for anything useful.
Improve rustdocs on the `Target::difficulty_float` function, specifically the return value if self is zero.
The `difficulty` calculation requires dividing a target value by `self`. Add an assertion that `self` is not zero to help devs debug this. Note that this should never really be hit, but its possible there is a bug somewhere causing the target to be set to zero - so this may help debugging. Also, add panics section to rustdocs.
What we really want is the maximum target, but since this is a const in `Params` use an `AsRef<Params>` argument in the `difficulty` functions. Requires implementation of `AsRef<Params> for Params`.
The maximum "attainable" target is a `rust-bitcoin` thing, Core use max unattainable. Deprecated the `Params::pow_limit` field and add a new field `max_attainable_target`. The `Params` type is `non_exhaustive` so this is not an API breaking change.
These two functions calculate the min/max threshold transition which is a _target_ not a "difficulty" number. Using "difficulty" in the function name is unnecessarily confusing. Rename and deprecate the functions.
The maximum target threshold has a network dependant upper bound. Currently we are not checking this bound. One complication is that there is currently heated open debate around the `Network` type. We can bypass the `Network` issue by using `AsRef<Params>` instead. Add a function that does the checks based on the `Params` type as well as an unchecked version.
1dd3444
to
fd6fedc
Compare
Rebased, some changes show up in |
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 fd6fedc
This has minimal changes since @sanket1729 acked (just rebase and the stuff caused by now being on top of a formatted codebase after #2462). Can be merged by way of rule 4 of the one ack carve-out. |
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 fd6fedc
@@ -245,6 +245,10 @@ impl Target { | |||
/// | |||
/// See [`difficulty`] for details. | |||
/// | |||
/// # Returns | |||
/// | |||
/// Returns [`f64::INFINITY`] if `self` is zero (caused by divide by zero). |
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.
Interesting, TIL.
When computing the maximum difficulty transition threshold we forgot to check that the returned
Target
is not bigger than the maximum. This value is network specific so keep the original logic but with_unchecked
on the function name.This was noted in the discussion on #2161