Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

local/remote balances and channel phases clarification #4067

Closed
zoedberg opened this issue Mar 10, 2020 · 3 comments · Fixed by #4111
Closed

local/remote balances and channel phases clarification #4067

zoedberg opened this issue Mar 10, 2020 · 3 comments · Fixed by #4111
Assignees
Labels
accounting channel management The management of the nodes channels

Comments

@zoedberg
Copy link

Background

Hi,

I'm having a hard time getting local and remote balances of channels.

Environment

  • version of lnd: v0.9.1-beta
  • operating system: Linux host 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-4~bpo9+1 (2019-06-19) x86_64 GNU/Linux
  • version of bitcoind: 0.18.1 (regtest)

Steps to reproduce

Briefly:

  • open channel between lnd and another node
  • wait for it to appear in the “open” channel list
  • close channel
  • retrieve balances for the various scenarios and channel phases

Expected behaviour

The sum of these balances to always be equal to the capacity of the channel,
therefore including reserves and commit fees.

Actual behaviour

From the Channel message I'm able to recover this information by adding
the commit_fee to the balance of the initiator (local if true, remote otherwise).

From the PendingOpenChannel message I'm unable to recover this information.
The parameter commit_fee is available but I don't have the initiator.

From the ClosedChannel message I'm unable to recover this information.
The issue here is different, I'm unable to receive information at all.
Channels closed mutually appear in waiting_close_channels and disappear after
a block is mined (doesn't matter who initiated closing), never showing up in pending_closing_channels.

From the ForceClosedChannel message, assuming the sum of local and remote balances equates the capacity, I could subtract local balance from capacity (remote balance seems to be always 0 in this case), but I'm not sure the resulting amount is correct.
Moreover it seems that only channels force-closed by us move from
waiting_close_channels to pending_force_closing_channels (the others disappear).

From the WaitingCloseChannel message I'm unable to recover this information.
I miss both the commit_fee and the initiator parameters.

@carlaKC
Copy link
Collaborator

carlaKC commented Mar 11, 2020

rpc additions

From the PendingOpenChannel message I'm unable to recover this information.
The parameter commit_fee is available but I don't have the initiator.

From the WaitingCloseChannel message I'm unable to recover this information.
I miss both the commit_fee and the initiator parameters.

Starting with the easy to address issues, it should be simple enough to add fields to the rpc messages, I'll will add them 👍

channel classification

Channels closed mutually appear in waiting_close_channels

waiting_close_channels`: contains channels that have had their close initiated, but the close tx has not confirmed on chain, so this is as expected.

and disappear after a block is mined (doesn't matter who initiated closing), never showing up in pending_closing_channels.

We consider cooperatively closed channels with one confirmation as closed (as of #1248), so we do not expect cooperatively closed channels to show up in pending_closing_channels. The channel should be in ClosedChannels after one block, can you confirm it's there for me?

accounting issues

From the ForceClosedChannel message, assuming the sum of local and remote balances equates the capacity, I could subtract local balance from capacity, but I'm not sure the resulting amount is correct.

Unfortunately this isn't the case, because when a channel is force closed it may still have some active htlcs on the commitment. This means that these htlcs will be separate outputs in the commitment tx that goes on chain, and need to be factored in when trying to fully account for your capacity. I'm working on some changes to make this information more accessible.

(remote balance seems to be always 0 in this case)

I managed to replicate this for 0.9.1

  • waiting_close_channels: correct balance
  • Generate Blocks
  • pending_force_closing_channels: zero balance

When we list waiting close channels, we have the full OpenChannel struct available, so we can set remote balance here. However, once we are listing pending force closed channels, we are relying on the CloseSummary which does not have the remote balance, so we omit remote balance here. Will look into how this can be addressed.

@wpaulino wpaulino added accounting channel management The management of the nodes channels labels Mar 11, 2020
@zoedberg
Copy link
Author

rpc additions

Great, thank you!

channel classification

I cannot reproduce a case in which the channel appears in pending_closing_channels.
Am I missing something or this list is unused?

I confirm that after mining a block the channel appears in ClosedChannels.

accounting issues

Ok, thank you again!

@carlaKC
Copy link
Collaborator

carlaKC commented Mar 23, 2020

From the WaitingCloseChannel message I'm unable to recover this information

Getting back to this, @zoedberg what do you need fees for in this case? In WaitingCloseChannel we are not certain of the commitment that will go on chain yet (eg, it is possible that both parties force close, and then only one commit will make it on chain). Commit fee can be added, but we'd need to add 3 different possible fees (local, remote and pending remote).

Am I missing something or this list is unused?

pending_close_channels was left in place to cover an edge case where somebody updated the lnd version in the middle of a close, see todo in code. It is not used anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accounting channel management The management of the nodes channels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants