-
Notifications
You must be signed in to change notification settings - Fork 405
Closing fee_range
uses invalid max
value
#1071
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
Comments
Sure, happy to change it to whatever, though ideally the spec would say that we have to keep it within a range if you're gonna check for it - much more sustainable than opening issues on all the implementations :) |
I agree, there's no obvious place in the spec right now where we could require that "all bitcoin amounts sent in LN messages must be <= 21 million btc", but I'll add this before the next spec meeting. |
Set it to the channel size? |
Patch I hacked up just sets it to the remote balance, cause obviously the full channel balance isn’t spendable either :).
… On Sep 8, 2021, at 19:33, Rusty Russell ***@***.***> wrote:
Set it to the channel size?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
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
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
Hey,
I've been testing the quick close mechanism with the latest LDK, and there's one (small) incompatibility between eclair and rust-lightning. It's exactly similar to ElementsProject/lightning#4599 (comment). When rust-lightning doesn't care about the upper bound it sets
max_fee_satoshis = 0xffffffffffffffff
.This is rejected by eclair, because we're strict on what values a
satoshi
field can hold.0xffffffffffffffff
is bigger than 21 million BTC so we consider it an invalid value. We could relax this but I'd like to avoid it if possible. That happens when rust-lightning is simply accepting a value inside eclair's proposed fee range, so I don't think it's necessary to set this to0xffffffffffffffff
, you could just return the samemax_fee_satoshis
you received.WDYT?
The text was updated successfully, but these errors were encountered: