multi: include commitment fees in dust calculation #8824
Conversation
|
Important Review skippedAuto reviews are limited to specific labels. Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Crypt-iQ
force-pushed
the
precise_dust_limit
branch
3 times, most recently
from
454be5c
to
0364eae
Compare
This commit expands the definition of the dust limit to take into account commitment fees as well as dust HTLCs. Dust HTLCs are fees anyways so it makes sense to account for commitment fees as well. The link has been modified slightly to calculate dust. In the future, the switch dust calculations can be removed.
Crypt-iQ
force-pushed
the
precise_dust_limit
branch
from
0364eae
to
8043864
Compare
Crypt-iQ
force-pushed
the
precise_dust_limit
branch
from
8043864
to
6266d9d
Compare
There was a problem hiding this comment.
My main feedback here is around terminology. I think we should avoid stretching the definition of "dust" since this conveys a certain understanding that spans more than just LND/Lightning and is an industry wide term.
I would recommend using terminology like "fee exposure" since that is both more accurate in what it is measuring and also accurate with respect to how we are letting the value influence our decisionmaking.
The implementation is fine but I'd like to see the optional parameter made required. I anticipate there may be hiccups here as it would require you to be able to supply the current state at the callsite. I don't think that computing that will be too onerous, but let me know if you think otherwise.
| // DustThreshold is the threshold in milli-satoshis after which we'll | ||
| // restrict the flow of HTLCs and fee updates. | ||
| DustThreshold lnwire.MilliSatoshi |
There was a problem hiding this comment.
I think we should consider renaming this to something like max fee exposure given the expanded role. Intuitively it feels that the name "dust threshold" means the threshold at which something becomes dust. The role this value is playing is the maximum fee exposure we want to have.
| // DryRunUpdateFee applies a proposed feerate to the channel and returns the | ||
| // commitment fee with this new feerate. It does not modify the underlying | ||
| // LightningChannel. | ||
| func (lc *LightningChannel) DryRunUpdateFee( |
There was a problem hiding this comment.
I think we should rename this for CommitFeeTotalAt or something like that. This is essentially a pure function and so calling it a "dry run update" doesn't make a lot of sense.
| // DustThreshold limits the number of outstanding fees in a channel. | ||
| // This value will be passed to created links. | ||
| DustThreshold lnwire.MilliSatoshi |
There was a problem hiding this comment.
same rec here about renaming.
| updateState bool, dryRunFee fn.Option[chainfee.SatPerKWeight]) ( | ||
| lnwire.MilliSatoshi, lnwire.MilliSatoshi, lntypes.WeightUnit, | ||
| *htlcView, error) { |
There was a problem hiding this comment.
I'm thinking maybe we don't take the parameter optionally and just requiring you to pass it in. Then at the callsite we can just grab the current fee rate and pass it in?
| getDustSum(remote bool, | ||
| fee fn.Option[chainfee.SatPerKWeight]) lnwire.MilliSatoshi | ||
|
|
||
| // getFeeRate returns the current channel feerate. | ||
| getFeeRate() chainfee.SatPerKWeight | ||
|
|
||
| // getDustClosure returns a closure that can evaluate whether a passed | ||
| // HTLC is dust. | ||
| getDustClosure() dustClosure | ||
|
|
||
| // getCommitFee returns the commitment fee in satoshis from either the | ||
| // local or remote commitment. | ||
| getCommitFee(remote bool) btcutil.Amount |
There was a problem hiding this comment.
I think the main question I have at this point is what the formal distinction is between the commit fees and the dust. It seems like starting with this commit, you want to redefine dust to be the commitment fees themselves.
| // isDustWithFee returns whether or not the new proposed fee-rate increases the | ||
| // total dust and fees within the channel past the configured dust threshold. | ||
| // It first calculates the dust sum over every update in the update log with | ||
| // the proposed fee-rate and taking into account both the local and remote dust | ||
| // limits. It uses every update in the update log instead of what is actually | ||
| // on the local and remote commitments because it is assumed that in a | ||
| // worst-case scenario, every update in the update log could theoretically be | ||
| // on either commitment transaction and this needs to be accounted for with | ||
| // this fee-rate. It then calculates the local and remote commitment fees given | ||
| // the proposed fee-rate. Finally, it tallies the results and determines if the | ||
| // dust threshold has been exceeded. | ||
| func (l *channelLink) isDustWithFee(feePerKw chainfee.SatPerKWeight) (bool, |
There was a problem hiding this comment.
Yeah I think redefining this to just be exceedsFeeExposureLimit or something to that effect would make more sense.
| // Finally, check whether the dust threshold was exceeded on either | ||
| // future commitment transaction with the fee-rate. | ||
| totalLocalDust := localDustSum + lnwire.NewMSatFromSatoshis(localFee) | ||
| if totalLocalDust > l.cfg.DustThreshold { | ||
| return true, nil | ||
| } | ||
|
|
||
| totalRemoteDust := remoteDustSum + lnwire.NewMSatFromSatoshis( | ||
| remoteFee, | ||
| ) | ||
| if totalRemoteDust > l.cfg.DustThreshold { | ||
| return true, nil | ||
| } | ||
|
|
||
| return false, nil |
There was a problem hiding this comment.
This can be combined into a single expression rather than the procedural fallthrough.
| // fail so amounts below 800sats will breach the dust threshold. | ||
| // Alice will send 354 HTLC's of 700sats. Bob will also send 354 HTLC's | ||
| // of 700sats. | ||
| numHTLCs := 354 |
There was a problem hiding this comment.
does the change in the magic number result in anything significant?
| @@ -504,7 +504,7 @@ func testBidirectionalAsyncPayments(ht *lntest.HarnessTest) { | |||
| args := []string{ | |||
| // Increase the dust threshold to avoid the payments fail due | |||
| // to threshold limit reached. | |||
| "--dust-threshold=5000000", | |||
| "--dust-threshold=10000000", | |||
There was a problem hiding this comment.
Is this due to the expanded definition of dust?
Small-ish change to the link to include commitment fees in dust calculation.