How to tell if channel was closed by local or remote in JSON-RPC API?

[gone-to-the-future]

Description

When requesting data about lightning channels via the JSON-RPC API, is there a concise way to tell who requested a channel close, whether cooperatively or via a force close?

I see in the code there is a channel state, but only FORCE_CLOSING and REQUESTED_FCLOSE seem to clearly indicate the "who".

Thank you :)

[SomberNight]

No, this logic is currently missing.

there is a channel state, but only FORCE_CLOSING and REQUESTED_FCLOSE seem to clearly indicate the "who".

Those states do not "persist" longer term -- the channel state will keep progressing e.g. to CLOSED when the closing tx is mined. I imagine we would want an API that can tell what happened even after that.

If you inspect the logs, you can tell what happened. Or if you manually inspect the onchain txs, you can distinguish between (1) local force closed, (2) remote force closed, (3) someone coop closed. Internally lnwatcher is already doing this:

electrum/electrum/lnchannel.py

Lines 319 to 326 in ca410be

	if self._who_closed != who_closed: # mostly here to limit log spam
	self._who_closed = who_closed
	if who_closed == LOCAL:
	self.logger.info(f'we (local) force closed')
	elif who_closed == REMOTE:
	self.logger.info(f'they (remote) force closed.')
	else:
	self.logger.info(f'not sure who closed. maybe co-op close?')

We could maybe have a four-state enum persisted for the channel (e.g. ChanCloseDiagnosis):
(1) local force closed
(2) remote force closed
(3) local coop closed
(4) remote coop closed
and expose that via the CLI/RPC.

note that these 4 states would not distinguish e.g. REQUESTED_FCLOSE (us deliberately sending an error to get the remote to force close) and voluntary remote force-close, but I think that's fine.

Also note ChanCloseDiagnosis could change until the channel close is (deeply) mined, e.g. we might set "local coop close" as soon as we initiate the close, but then the remote might easily decide to simply force-close.

[gone-to-the-future]

Thank you for the detailed response :). When you say this data may be available in the transaction itself, you are talking about on-chain data that can be analyzed further, not something that would show up in existing commands like onchain_history or ln_history, correct?

The use case for this for us is to be able to tell over longer time periods how "cooperative" a specific lighting node is. If they frequently close channels with us, we don't want to keep using that node.

[SomberNight]

When you say this data may be available in the transaction itself, you are talking about on-chain data that can be analyzed further, not something that would show up in existing commands like onchain_history or ln_history, correct?

Right, I mean it is possible to (e.g. manually) analyze the on-chain data, potentially combined with some of the channel keys to figure out what happened. It is not something I would expect users to do.
How a channel got closed is not something that is currently shown in either the CLI or the GUI, but I fully understand it would be a nice-to-have.