<p>No, a mutual close is not possible. For signing a mutual close, both the parties should be aware as to what the current state of the channel is at. Since one of the party has fallen behind, it does not know how much it is owed (or more correctly cannot prove to the other party how much it is owed). Moreover, if the last signed commitment transaction included adding of HTLCs, it is impossible for the fallen behind node to know what those HTLCs are, if the pre-images were sent, or if the HTLCs have timed out.</p>

<p>The one way that can be though of is that when the other party detects that its peer has fallen behind, it sends its peer the last signed serialized commitment transaction (without signatures) that it holds and the signature that the fallen behind peer sent it. They can then negotiate the closing condition including the fees. However, the protocol allows only messages that are not more than 65535 bytes long. Commitment transactions can be as much as 400,000 WU (>100,000 bytes) so it would not fit in a single Lightning message. May be the protocol can use the new TLV format to indicate multiple messages to follow, but as is, the current specs do not allow it.</p>

CC BY-SA 4.0
2019-11-02T11:36:53.487Z
I'm confused. What did he mean in this tweet? https://twitter.com/forieq0/status/1187411491554779136?s=19
Chris Chen
CC BY-SA 4.0
2019-11-02T12:00:56.150Z
That is confusing. I think what they are referring to is that force close is not allowed when both parties are synced up. If one party sends a `channel_restablish` message and the other party detects that it's peer has fallen behind then the specs recommends force close. Try reading [Olaolu' reply](https://twitter.com/roasbeef/status/1187463645279576064?s=08). It seems they had backed up an old state which led to force closure.
Ugam Kamat
CC BY-SA 4.0
2019-11-03T01:58:07.790Z
I can't see why mutual closing is impossible - on the contrary, to my understanding, it's much better than requesting the counterparty to unilaterally close the channel, because unilateral closing consumes more vbytes, thus more miner fee/block space. Unilateral closing also introduces a to-local delay, ironically, the data-losing party doesn't suffer from such time-locking, AFAIK.
Chris Chen
CC BY-SA 4.0
2019-11-03T02:02:04.720Z
By the way, I had actually asked the second question: was there once a period that using an old backup was still unable to recover the off-chain funds, and, these funds were permanently lost/destroyed, because the corresponding private keys didn't exist in the world any more.
Chris Chen
CC BY-SA 4.0
2019-11-03T09:46:32.733Z
@ChrisChen I do not know the answer to the second question. I might have to search the web for it. If you find it then you can comment here and then we can see as to what the reasons were. Coming back to your first question, the problem with mutual close is that the other party has lost all its commitment transactions since a particular point. So it does not know how much it is owed. The only way to prove is that the counterparty sends the last signed commitment transaction to it. Can you think of how you can let the fallen behind node know what the balance of the channel is?
Ugam Kamat
CC BY-SA 4.0
2019-12-11T06:50:47.910Z
Might be related: https://bitcoin.stackexchange.com/questions/92149/lightning-why-are-commitment-transactions-supposed-to-use-different-keys
Chris Chen
CC BY-SA 4.0
2019-11-02T10:30:08.743Z
2019-11-02T11:05:11.807Z
2019-11-02T11:05:11.807Z
Ugam Kamat
<p>As far as I know, the "Data Loss Protection" feature would just request the counterparty to unilaterally close the channel. I wonder if mutual closing is still possible, with old channel states?</p>

<p>By the way, I roughly remember that I once seen a comment like this:</p>

<p>Before the "Static Channel Backup" feature was introduced, there was once a bad situation that the funds could be permanently lost, even if the channel counterparty unilaterally closed the channel. However, this bad situation was a trade-off in exchange for better (or easier) watchtower implementation.</p>

<lightning-network><wallet-recovery>
If a user recovered data directory of LN node software with an old backup, what would happen? Would cooperative channel closing be possible?
Chris Chen
# If a user recovered data directory of LN node software with an old backup, what would happen? Would cooperative channel closing be possible?

(Asked by: username_0 on 2019-11-02)

As far as I know, the "Data Loss Protection" feature would just request the counterparty to unilaterally close the channel. I wonder if mutual closing is still possible, with old channel states?

By the way, I roughly remember that I once seen a comment like this:

Before the "Static Channel Backup" feature was introduced, there was once a bad situation that the funds could be permanently lost, even if the channel counterparty unilaterally closed the channel. However, this bad situation was a trade-off in exchange for better (or easier) watchtower implementation.

**Tags:** lightning-network, wallet-recovery


---

## 1 answers

### Answer by username_1 on 2019-11-02. Score: 1

No, a mutual close is not possible. For signing a mutual close, both the parties should be aware as to what the current state of the channel is at. Since one of the party has fallen behind, it does not know how much it is owed (or more correctly cannot prove to the other party how much it is owed). Moreover, if the last signed commitment transaction included adding of HTLCs, it is impossible for the fallen behind node to know what those HTLCs are, if the pre-images were sent, or if the HTLCs have timed out.

The one way that can be though of is that when the other party detects that its peer has fallen behind, it sends its peer the last signed serialized commitment transaction (without signatures) that it holds and the signature that the fallen behind peer sent it. They can then negotiate the closing condition including the fees. However, the protocol allows only messages that are not more than 65535 bytes long. Commitment transactions can be as much as 400,000 WU (>100,000 bytes) so it would not fit in a single Lightning message. May be the protocol can use the new TLV format to indicate multiple messages to follow, but as is, the current specs do not allow it.

> **Comments:**
> **username_0**: I'm confused. What did he mean in this tweet? https://twitter.com/forieq0/status/1187411491554779136?s=19  
> **username_1**: That is confusing. I think what they are referring to is that force close is not allowed when both parties are synced up. If one party sends a `channel_restablish` message and the other party detects that it's peer has fallen behind then the specs recommends force close. Try reading [Olaolu' reply](https://twitter.com/roasbeef/status/1187463645279576064?s=08). It seems they had backed up an old state which led to force closure.  
> **username_0**: I can't see why mutual closing is impossible - on the contrary, to my understanding, it's much better than requesting the counterparty to unilaterally close the channel, because unilateral closing consumes more vbytes, thus more miner fee/block space. Unilateral closing also introduces a to-local delay, ironically, the data-losing party doesn't suffer from such time-locking, AFAIK.  
> **username_0**: By the way, I had actually asked the second question: was there once a period that using an old backup was still unable to recover the off-chain funds, and, these funds were permanently lost/destroyed, because the corresponding private keys didn't exist in the world any more.  
> **username_1**: @ChrisChen I do not know the answer to the second question. I might have to search the web for it. If you find it then you can comment here and then we can see as to what the reasons were. Coming back to your first question, the problem with mutual close is that the other party has lost all its commitment transactions since a particular point. So it does not know how much it is owed. The only way to prove is that the counterparty sends the last signed commitment transaction to it. Can you think of how you can let the fallen behind node know what the balance of the channel is?  
> **username_0**: Might be related: https://bitcoin.stackexchange.com/questions/92149/lightning-why-are-commitment-transactions-supposed-to-use-different-keys  

---

