Quote from: n0nce on September 11, 2022, 11:25:54 PM

I would have expxected a 'Lightning Force Close' transaction to have 1 (Multisig) input and 2 outputs.

While you and I both know how a force close works in theory, I haven't found an actual flow graph or similar, that would definitely help explain the current situation (only one of the 2 nodes got the 'Lightning Force Close' transaction, basically).

I made a post explaining uncooperative channel close some time ago.

Quote from: Rath_ on July 06, 2021, 01:00:54 PM

First of all, the timelock is decided before the channel is established. By default, most nodes force the other peer to wait 144 blocks (~1 day). The maximum acceptable value by default is 2016 blocks (~2 weeks). I configured my node to create channels with their_to_self_delay = 432 blocks (~3 days), so if someone decides to close the channel opened to my node uncooperatively, they will have to wait 432 blocks (after the commitment transaction has been included in a block) before they can spend the output belonging to them. Those timelocks are relative which means that you do not have to sign a new commitment transaction whenever a new block is mined. New commitment transactions are signed periodically because their fees need to match the current state of the mempool. There is no point in paying 60 sat/vbyte when 1 sat/vbyte transactions are getting confirmed in just a few minutes. It also applies the other way around.

The first transaction is the commitment transaction. Let's say there's node A(lice) and node B(ob), and node A broadcasts the commitment transaction. That commitment transaction includes two outputs:

- output #0: 3 BTC (spendable by node B's private key) - reflecting node B balance
- output #1: 6 BTC (RSMC) - reflecting node A balance

There is one more important detail before we go any further. Whenever a new commitment transaction is signed, both parties exchange revocation keys for the previous commitment transaction so that they can both be sure that the other party is very unlikely to broadcast an old state of the channel.

RSMC is short for Revocable Sequence Maturing Contract. Such an output contains a relative timelock. This means that you can't spend this output until a certain amount of blocks have been mined since the transaction which includes that output was mined.

Let's say node B didn't change the default value of 144 blocks and the commitment transaction has been confirmed. There are two possible scenarios.

1) Node A attempts to cheat and broadcast an old commitment transaction. Node B has 144 blocks to spend the RSMC output using his and node A's revocation key which he got while they were working on a new commitment transaction.

2) Node A broadcasts the latest commitment transaction. In such a case, node B never got node A's revocation key for that commitment transaction, so he cannot spend that RSMC. Node A can broadcast another transaction spending that output after 144 blocks have been mined.

In this case, node 2 broadcast a commitment transaction with the following outputs:

1) RSMC - this output can be spent by node 2 after 144 blocks. Node 2 should move those coins to its own address as soon as possible in case node 1 somehow got their hands on the revocation key.
2) Standard output - this output should be immediately spendable by node 1

So, what can you do to recover your coins? Well, use lightning-hsmtool guesstoremote just like @nonce has already suggested. As for max_channel_dbid....

Quote from: https://lightning.readthedocs.io/lightning-hsmtool.8.html?highlight=max_channel_dbid

max_channel_dbid is your own guess on what the channel_dbid was, or at least the maximum possible value, and is usually no greater than the number of channels that the node has ever had.

You have to count all channels - even closed ones. So, if your node has had a total of 3 channels, you should set that parameter to 3.

I can give you a more detailed explanation on why that's necessary once you confirm that it has worked.