[Custom Transactions] Abstract the weight of HTLC transactions away from channel

[tankyleo]

Hence, we let TxBuilder set the total endogenous fees spent on a set of HTLC transactions via htlc_txs_endogenous_fees_sat.

Furthermore, we also let TxBuilder set the dust limit for offered and accepted HTLCs on commitment transactions; channel will use those limits when sorting dust HTLCs from non-dust HTLCs.

These limits are a function of the weight of HTLC transactions in legacy channels.

As a result of this commit, implementers of TxBuilder may now set arbitrary dust limits for HTLCs on commitment transactions.

[ldk-reviews-bot]

👋 Thanks for assigning @carlaKC as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tankyleo]

We discussed earlier passing the entire list of HTLCs to TxBuilder, and letting it do the dust-vs-non-dust sorting itself. There are nonetheless multiple places in channel that are interested in knowing the exact HTLC dust limit (see get_pending_{inbound, outbound}_htlc_details, get_available_balances_for_scope).

So we prefer to add a single method that surfaces this limit to channel, and then let channel sort HTLCs depending on whether their value sits above or below that amount.

As a result, builders of custom transactions will only have a say on where the dust limit sits, and won't be able to choose arbitrary subsets for dust and non-dust HTLCs.

[carlaKC]

We discussed earlier passing the entire list of HTLCs to TxBuilder, and letting it do the dust-vs-non-dust sorting itself.

Is the main motivation for this to get all of the commitment-related logic out of channel.rs, or that we think that custom tx builders will want to specifically choose certain htlcs to be dust?

get_available_balances_for_scope

The key questions we're looking to answer seems to be "can I afford a commitment with this theoretical dust/nondust htlc"? This does seem to be something we could move into TxBuilder if we pass the full HTLC set and use a version of HTLCCandidate which just tells TxBuilder whether it is dust (we never actually use this amount other than the dust check).

Sadly here's no getting around needing to know the dust limit if we want to clamp our capacity to that value, so we'd still need to surface htlc_success_timeout_dust_limits.

get_pending_{inbound, outbound}_htlc_details

Tempting to suggest just adding an is_dust check to TxBuilder for these to make it slightly more abstract than surfacing the second stage fees, but given the above requirement to know the exact dust limit maybe we just want to leave as-is.

so tl;dr: I'd be interested in seeing what trying to pull more of the dust logic out into TxBuilder looks like, even if just gives us a clearer idea of where the trait line should be.

---

Meta note: This has got a lot of overlap with 3bb0586, so I think we should either:

1. Rebase Update fee and dust handling for zero fee channels #3884 on this PR
2. Pull the commit out into a common prefactor (I have a slight pref for this, but happy with either)

[tankyleo]

Is the main motivation for this to #3775 (comment), or that we think that custom tx builders will want to specifically choose certain htlcs to be dust?

I would say we focus on the latter for this PR, and let the former be the overarching goal :)

so tl;dr: I'd be interested in seeing what trying to pull more of the dust logic out into TxBuilder looks like, even if just gives us a clearer idea of where the trait line should be.

Let me know what you think of this new direction here. Still have some clunkiness to resolve, but that's what it's looking like right now.

• htlc_success_timeout_dust_limits is used only in get_available_balances_for_scope, and I will see if I can come up with a better method call that fits better with the "what is our available balance" question.
• Definitely take your point about surfacing second-stage tx fees, will review that part too. Right now we only need it to calculate dust exposure due to excess feerates set by a counterparty (in a channel where they are the funder), see https://delvingbitcoin.org/t/disclosure-irrevocable-fees-stealing-from-ln-using-revoked-commitment-transactions/1314

[tankyleo]

Meta note: This has got a lot of overlap with 3bb0586

Definitely let me rebase on top of your PR, you've rebased once already :)