Increase our default/minimum dust limit and decrease our max#1065
Increase our default/minimum dust limit and decrease our max#1065TheBlueMatt merged 6 commits intolightningdevkit:mainfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1065 +/- ##
==========================================
+ Coverage 91.01% 92.19% +1.17%
==========================================
Files 65 65
Lines 33767 41822 +8055
==========================================
+ Hits 30732 38556 +7824
- Misses 3035 3266 +231
Continue to review full report at Codecov.
|
767370f to
0501354
Compare
| }; | ||
|
|
||
| for outp in closing_tx.output.iter() { | ||
| if !outp.script_pubkey.is_witness_program() && outp.value < MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS { |
There was a problem hiding this comment.
Wait, the closing requirement implemented by this change is "Require cooperative close payout scripts to be Segwit" ? If so why also checking MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS, we want to reject non-segwit output no matter their output values ?
There was a problem hiding this comment.
The new requirement is "our users have to use segwit scripts, but the counterparty can use something else, but if they do we may have to force close". I tweaked the commit message text to be more clear.
f738691 to
3734846
Compare
This should be reverted at some point, but the test is deficient and breaks on later changes that are important to land ASAP.
330 sat/vbyte, the current value, is not sufficient to ensure a future segwit script longer than 32 bytes meets the dust limit if used for a shutdown script. Thus, we can either check the value on shutdown or we can simply require segwit outputs and require a dust value of no less than 354 sat/vbyte. We swap the minimum dust value to 354 sat/vbyte here, requiring segwit scripts in a future commit. See lightning/bolts#905
3734846 to
5918d1c
Compare
|
Rebased and squashed the fixup commits. I think we should go ahead and take this and just open an issue for the broken test to re-add it later - without this we're going to be unable to open any channels with other nodes very soon. |
valentinewallace
left a comment
There was a problem hiding this comment.
One suggestion, otherwise looks good
| /// transaction non-standard and thus refuses to relay it. | ||
| /// We also use this as the maximum counterparty `dust_limit_satoshis` allowed, given many | ||
| /// implementations use this value for their dust limit today. | ||
| pub const MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS: u64 = 546; |
There was a problem hiding this comment.
The MAX_STD part is throwing me off because from the comment, this constant seems to be the min std output value. Think diff might make it the clearest to me:
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 2d165adf..51963347 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -559,7 +559,9 @@ pub const MAX_FUNDING_SATOSHIS: u64 = 1 << 24;
/// transaction non-standard and thus refuses to relay it.
/// We also use this as the maximum counterparty `dust_limit_satoshis` allowed, given many
/// implementations use this value for their dust limit today.
-pub const MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS: u64 = 546;
+pub const MIN_STD_OUTPUT_SATOSHIS: u64 = 546;
+
+pub const MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS: u64 = MIN_STD_OUTPUT_SATOSHIS;
/// The dust limit is used for both the commitment transaction outputs as well as the closing
/// transactions. For cooperative closing transactions, we require segwit outputs, though accept
Then MIN_STD could be used in fn closing_signed and MAX_DUST could be used everywhere else
There was a problem hiding this comment.
Did something similar which I think captured your intent, lmk.
There was a problem hiding this comment.
Oops, I meant in my original diff to rename the new const back to MAX_DUST_LIMIT_SATOSHIS (since it seems like an implementation detail what the actual value is)
There was a problem hiding this comment.
Ah, ok, i see your point now. reverted the fixup, take a look now.
93e8971 to
88c0619
Compare
| pub const MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS: u64 = 546; | ||
|
|
||
| /// The maximum channel dust limit we will accept from our counterparty. | ||
| pub const MAX_CHAN_DUST_LIMIT_SATOSHIS: u64 = MAX_STD_OUTPUT_DUST_LIMIT_SATOSHIS; |
There was a problem hiding this comment.
For conciseness, why not MAX_DUST_LIMIT_SATOSHIS?
There was a problem hiding this comment.
I find it a bit confusing, the distinction between the network's dust limit, and the channel's dust limit, both of which have the same name but mean different things.
There was a problem hiding this comment.
Isn't MIN_DUST_LIMIT_SATOSHIS also a channel dust limit? Mainly the inconsistency between them I find confusing
There was a problem hiding this comment.
Yes I agree MIN_DUST_LIMIT_SATOSHIS could be MIN_CHAN_DUST_LIMIT_SATOSHIS as it's applied at the minimal channel's dust_limit_satoshis accepted by our implementation.
There was a problem hiding this comment.
Pushed a commit to rename that, too :)
2a96092 to
0f6e0c3
Compare
546 sat/vbyte is the current default dust limit on most implementations, matching the network dust limit for P2SH outputs. Implementations don't currently appear to send any larger dust limits, and allowing a larger dust limit implies higher payment failure risk, so we'd like to be as tight as we can here.
There is little reason for users to be paying out to non-Segwit scripts when closing channels at this point. Given we will soon, in rare cases, force-close during shutdown when a counterparty closes to a non-Segwit script, we should also require it of our own users.
If a counterparty (or an old channel of ours) uses a non-segwit script for their cooperative close payout, they may include an output which is unbroadcastable due to not meeting the network dust limit. Here we check for this condition, force-closing the channel instead if we find an output in the closing transaction which does not meet the limit.
While channel and P2P network dust limits are related, they're ultimately two different things, and thus their constant names should reference that.
0f6e0c3 to
2da0d6c
Compare
|
Squashed with no diff. Diff since ariard's ack is a trivial constant rename. Will land after CI. |
CC @ariard can you take a look at the test I dropped here - its not documented how you came up with the constants used so its rather difficult to fix the test. Would be nice to replace all the constants with calculation based on the dust limits set.