Skip to content

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

Merged

Conversation

valentinewallace
Copy link
Contributor

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.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a 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.

Copy link
Contributor

@arik-so arik-so left a 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.

@valentinewallace valentinewallace force-pushed the fix-feerate-new-channel branch 2 times, most recently from 359de55 to 981cd9f Compare June 15, 2020 20:10
@codecov
Copy link

codecov bot commented Jun 15, 2020

Codecov Report

Merging #639 into master will increase coverage by 0.01%.
The diff coverage is 98.52%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
lightning/src/chain/chaininterface.rs 91.89% <ø> (ø)
lightning/src/util/errors.rs 81.39% <ø> (ø)
lightning/src/ln/channel.rs 86.80% <97.72%> (+0.08%) ⬆️
lightning/src/chain/keysinterface.rs 94.78% <100.00%> (ø)
lightning/src/ln/chan_utils.rs 97.17% <100.00%> (ø)
lightning/src/ln/channelmanager.rs 85.45% <100.00%> (ø)
lightning/src/ln/channelmonitor.rs 95.71% <100.00%> (ø)
lightning/src/ln/functional_tests.rs 97.11% <100.00%> (+0.01%) ⬆️
lightning/src/ln/onchaintx.rs 93.94% <100.00%> (ø)
lightning/src/util/enforcing_trait_impls.rs 100.00% <100.00%> (ø)
... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1c9b11...f917187. Read the comment docs.

@valentinewallace
Copy link
Contributor Author

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.

Fixed!

@valentinewallace valentinewallace force-pushed the fix-feerate-new-channel branch from 16db924 to 4b6b68a Compare June 15, 2020 21:34
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]>
@valentinewallace valentinewallace force-pushed the fix-feerate-new-channel branch 2 times, most recently from d47cfcd to ca96c87 Compare June 15, 2020 22:33
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a 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).
@valentinewallace valentinewallace force-pushed the fix-feerate-new-channel branch from 48ccae1 to f917187 Compare June 16, 2020 01:53
@TheBlueMatt TheBlueMatt merged commit bd2fa43 into lightningdevkit:master Jun 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants