[feature]: Add CanSend amount to listchannels output

[ziggie1984]

Add a CanSend amount in MilliSats to the listchannels rpc output which shows the exact bandwidth of a channel which can be used.

Right now we only have the local_balance and the remote balance, tho this only accounts for the reserve and the current commitment fee, since LND 18 we also keep a Buffer so it makes sense to introduce a field called CanSend which shows in detail how much liquidity can be used on this channel.

"channels":  [
        {
            "active":  true,
            "remote_pubkey":  "02797cc2b9b01f73ddd0daa98277d867089583f75de89655a774352042bd80b842",
            "channel_point":  "f4e7e624de80ad684d16c94d19ff05cfcc83957a414c902618429d1390cb5048:1",
            "chan_id":  "118747255865345",
            "capacity":  "250000",
            "local_balance":  "246530",
            "remote_balance":  "0",

...

[feelancer21]

Good point. Let me drop two comments:

1. We should also wonder if a mirrored CanReceive is not also needed, especially for rebalancing and inbound liquidity management. Here we would have to work with the assumption that the remote peer has implemented the fee spike buffer with the same methodology, but that is better than nothing.

2. I have been wondering for some time whether the local balance or remote balance in its current form is meaningful at all, as the amount is influenced by both the commit fees and the pending htlcs. From my point of view, in addition to the available amount already mentioned, only the settled local balace and settled remote balance are needed, e.g. for accounting. To define it more precisely: How many sats does a noderunner get from the channel assuming a hypothetical closure at 0 cost and all pending htlcs fail. From my point of view, we could then even deprecate the current two fields.

[kilrau]

As just discussed with @ziggie1984 , please also add the total anchor amount as this is currently missing to make numbers add up: local_balance+remote_balance+commit_fee+anchor=capacity

[alexbosworth]

would it be tricky in terms of thinking about the offchain send actually expands the commit fee, so like how much would the weight expand for a send, how much fee rate would that be, and what is the expectation for number of htlcs, like what if you actually need to add 10 mpp htlcs to effectively send all the balance in a single payment?

[ziggie1984]

would it be tricky in terms of thinking about the offchain send actually expands the commit fee, so like how much would the weight expand for a send, how much fee rate would that be, and what is the expectation for number of htlcs, like what if you actually need to add 10 mpp htlcs to effectively send all the balance in a single payment?

@alexbosworth

I am not sure I understand your vision, could you elaborate further ? The current idea in my mind would be something like:

Consider sending the whole amount in one htlc or capping it with the max_pending_amt_msat of the channel constraint. Based on this and the current fee buffer we would calculate the actual Amount of sats which can be send through this channel.

I wonder how we would find out that the full amount can only be send via a 10 mpp payment, you mean because of the channel constraint restriction ?

[alexbosworth]

right so it could be multiple htlcs that you want to send the entire balance, or you are forced to via the pending values or max htlc values. so if you add multiple htlcs each htlc expands the commitment weight and therefore fee and therefore reduces the balance available for paying? maybe we can't really know then what the canpay value is at all, it's more of an interactive question, in that case it could be that instead of revealing an opaque sum that you would reveal the per htlc cost and the fee buffer and documenting how to come up with a canspend on the client side given various assumptions