-
Notifications
You must be signed in to change notification settings - Fork 411
Use our actual feerate in open_channel messages, not a new one #639
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
Use our actual feerate in open_channel messages, not a new one #639
Conversation
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.
Probably makes sense to swap our entire feerate_per_kw type globally for a u32. There is no reason to let the user-visible API return a type that we cannot use.
Also, needs a trivial full_stack_target fuzz fix since a previously-used fee-get is now unused.
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.
LGTM! Just needs test fix.
359de55
to
981cd9f
Compare
Codecov Report
@@ Coverage Diff @@
## master #639 +/- ##
==========================================
+ Coverage 91.26% 91.28% +0.01%
==========================================
Files 35 35
Lines 21122 21138 +16
==========================================
+ Hits 19278 19295 +17
+ Misses 1844 1843 -1
Continue to review full report at Codecov.
|
Fixed! |
16db924
to
4b6b68a
Compare
When we were sending an open_channel messages we were asking the feerate estimator for a new value instead of using the one we had. If the feerate estimator gave a different value than the one it did when we created the Channel struct, we'd start out-of-sync with our counterparty and blow up on funding_signed. Even worse, the ConfirmationTarget used was different, so its highly likely they would disagree. Also remove newly unused fee estimator parameter from get_open-channel API. Co-authored-by: Matt Corallo <[email protected]> Co-authored-by: Valentine Wallace <[email protected]>
d47cfcd
to
ca96c87
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.
Nice job, thanks for this. A few nits re: preferring to cast up to u64 and not down to u32, but otherwise looks great.
The protocol only allows a u32, so if we received or sent something larger it would be an issue (though it's unlikely).
48ccae1
to
f917187
Compare
When we were sending an open_channel messages we were asking the
feerate estimator for a new value instead of using the one we had.
If the feerate estimator gave a different value than the one it did
when we created the Channel struct, we'd start out-of-sync with our
counterparty and blow up on funding_signed. Even worse, the
ConfirmationTarget used was different, so its highly likely they
would disagree.
Also remove newly unused fee estimator parameter from get_open-channel
API.