Skip to content

Reduce our stated max closing-transaction fee to be the true value #1072

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

TheBlueMatt
Copy link
Collaborator

When communicating the maximum fee we're willing to accept on a
cooperative closing transaction to our peer, we currently tell them
we'll accept u64::max_value() if they're the ones who have to pay
it. Spec-wise this is fine - they aren't allowed to try to claim
our balance, and we don't care how much of their own funds they
want to spend on transaction fees.

However, the Eclair folks prefer to check all values on the wire
do not exceed 21 million BTC, which seems like generally good
practice to avoid overflows and such issues. Thus, our close
messages are rejected by Eclair.

Here we simply relax our stated maximum to be the real value - our
counterparty's current balance in satoshis.

Fixes #1071

When communicating the maximum fee we're willing to accept on a
cooperative closing transaction to our peer, we currently tell them
we'll accept `u64::max_value()` if they're the ones who have to pay
it. Spec-wise this is fine - they aren't allowed to try to claim
our balance, and we don't care how much of their own funds they
want to spend on transaction fees.

However, the Eclair folks prefer to check all values on the wire
do not exceed 21 million BTC, which seems like generally good
practice to avoid overflows and such issues. Thus, our close
messages are rejected by Eclair.

Here we simply relax our stated maximum to be the real value - our
counterparty's current balance in satoshis.

Fixes lightningdevkit#1071
@TheBlueMatt TheBlueMatt force-pushed the 2021-09-tighter-max_fee-constant branch from d06da07 to b348d9c Compare September 10, 2021 00:31
@codecov
Copy link

codecov bot commented Sep 10, 2021

Codecov Report

Merging #1072 (b348d9c) into main (4c4d99b) will increase coverage by 0.53%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1072      +/-   ##
==========================================
+ Coverage   90.87%   91.40%   +0.53%     
==========================================
  Files          65       65              
  Lines       33229    35185    +1956     
==========================================
+ Hits        30196    32162    +1966     
+ Misses       3033     3023      -10     
Impacted Files Coverage Δ
lightning/src/ln/channel.rs 92.45% <100.00%> (+3.70%) ⬆️
lightning/src/util/enforcing_trait_impls.rs 88.97% <0.00%> (-0.31%) ⬇️
lightning/src/ln/functional_tests.rs 97.44% <0.00%> (-0.07%) ⬇️
lightning/src/ln/chan_utils.rs 97.93% <0.00%> (+0.52%) ⬆️
lightning/src/chain/keysinterface.rs 96.16% <0.00%> (+1.48%) ⬆️

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 4c4d99b...b348d9c. Read the comment docs.

Copy link

@ariard ariard left a comment

Choose a reason for hiding this comment

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

Code Review ACK b348d9c

@TheBlueMatt TheBlueMatt merged commit de9fba8 into lightningdevkit:main Sep 13, 2021
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.

Closing fee_range uses invalid max value
3 participants