Calculating on-chain and off-chain balances from frcli audit data

[Tinymaxd]

Hi,

I am trying to calculate the current balances of my node from the values of the csv file created by frcli audit. By balances I mean the wallet balance (on-chain balance) and the available outbound liquidity (off-chain balance) of the node.

I calculate the on-chain balance by adding all values with OnChain=true and Type!=CHANNEL_CLOSE_FEE and Type!=SWEEP_FEE. In other words:

SUM(OnChain=true) - SUM(Type=CHANNEL_CLOSE_FEE) - SUM(Type=SWEEP_FEE)

This works, and the result matches the wallet balance.

I calculate the off-chain balance (available outbound liquidity) as follows:

SUM(OnChain=false) - SUM(Type=LOCAL_CHANNEL_OPEN) - SUM(Type=CHANNEL_CLOSE) + SUM(Type=CHANNEL_CLOSE_FEE) - SUM(Type=SWEEP) + SUM(Type=SWEEP_FEE)

However, the result of this calculation does not correspond exactly to the available outgoing liquidity, but only approximately. Is this calculation correct in principle? And is it even possible to calculate the available outbound liquidity exactly from the data generated by frcli audit?

Initially, I naively calculated the sum of all values in the csv file and thought that this should correspond to the sum of off-chain and on-chain balance, but this also does not match at all.

[guggero]

The channel balance (and with that I mean the output of the lnrpc.ChannelBalance RPC) doesn't include the commit fee the initiator of the channel will have to pay. So for channels that are still open, that value will not appear in any of the audit entries, as that amount hasn't been "spent" yet (it is what pays for the on-chain fees when the channel is force closed).
If you loop through every active channel and sum up the commit_fee if initiator: true, does that make up for the difference?

[Tinymaxd]

I also thought about that later. If I consider the commit_fee when I am the initiator, I get closer, but there is still a difference.

That difference is probably the anchor output reservations, which seem to be 330 sat per side.

The following applies capacity = local_balance + remote_balance + commit_fee + 660 sat for all channels, except for one where my local_balance = 0, here it is capacity = local_balance + remote_balance + commit_fee + 330 sat.
If I assume for each channel that my anchor output reservation is 330 sat, then the difference to my audit calculation is only a single digit sat number.
But I don't understand why I should have an anchor reservation for a channel with local_balance=0 and my peer has none. Overall, I'm not sure about the amount of anchor output reservations.

So far I have used listchannels to calculate the local_balance, but this does not give the balance in msat accuracy, only in sat. Compared to channelbalance, the result only differs by the decimal places (which is good). However, the decimal places differ from those I get when I sum with the data from audit.

Edit: I guess the msat differences are due to closed channels as on-chain only sat accuracy is possible Overall, this could be a reason why the calculation cannot be accurate. However, I need to do more research to understand this in detail.

[guggero]

But I don't understand why I should have an anchor reservation for a channel with local_balance=0 and my peer has none.

I think a channel with local_balance=0 should indeed not reserve the 330 sats for the anchor. Unless there's an in-flight HTLC. Perhaps this is simply displayed incorrectly in the lncli listchannels output? Because your peer definitely should have an anchor reserve.

[Tinymaxd]

Thanks for clarification. I'm poking around in the dark here. lncli listchannels does not display info about the anchor output reservation. I am not aware of any lncli command that shows me the anchor output reservations.