<p>This is a really good question.</p>
<blockquote>
<p>Is it safer to try using the emergency.recover file first? If the peer cooperates, is this completely safe? If the peer tries to cheat me, do I still have time to use the backup from the backup plugin?</p>
</blockquote>
<p>Yes this is safe, the peer can not cheat for two reasons:</p>
<ul>
<li>The backup is encrypted so if something changes your node you will easily find out.</li>
<li>If your backup db is old I think you can start from this recovery before and if fails (maybe you have no peer that supports the peer backup feature) you can try to use the database.</li>
</ul>
<p>Before trying this you should read in deep this page <a href="https://docs.corelightning.org/docs/backup-and-recovery" rel="nofollow noreferrer">https://docs.corelightning.org/docs/backup-and-recovery</a></p>
<blockquote>
<p>What's the best way to deal with this to reduce the chances of losing funds?</p>
</blockquote>
<p>The best practice is not making the backup of the database by hand, as you said this will be always outdated. CLN has different ways to do the backup like [1].</p>
<p>As good news, all the implementations today use <code>option_data_loss_protect</code>. This means that you trigger this part of the spec [2]</p>
<pre><code>  - otherwise, if it supports `option_data_loss_protect`:
    - if `next_revocation_number` is greater than expected above, AND
    `your_last_per_commitment_secret` is correct for that
    `next_revocation_number` minus 1:
      - MUST NOT broadcast its commitment transaction.
      - SHOULD send an `error` to request the peer to fail the channel.
      - SHOULD store `my_current_per_commitment_point` to retrieve funds
        should the sending node broadcast its commitment transaction on-chain.
    - otherwise (`your_last_per_commitment_secret` or `my_current_per_commitment_point`
    do not match the expected values):
      - SHOULD send an `error` and fail the channel.
</code></pre>
<p>So your old backup should trigger just force closes.</p>
<p>Good luck.</p>
<p>[1] <a href="https://docs.corelightning.org/docs/advanced-db-backup#sqlite3---walletmainbackup-and-remote-nfs-mount" rel="nofollow noreferrer">https://docs.corelightning.org/docs/advanced-db-backup#sqlite3---walletmainbackup-and-remote-nfs-mount</a>
[2] <a href="https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#message-retransmission" rel="nofollow noreferrer">https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#message-retransmission</a></p>

CC BY-SA 4.0
2023-10-06T16:08:14.027Z
Thanks Vincenzo! This mostly makes sense, but having read your explanations, I'm now thinking it's better to use the possibly-outdated database backup before emergency.recover. If the peer is honest it makes no difference (right?), but if the peer isn't honest, my reconstructed node using a slightly outdated backup knows *some* of the outdated channel states and will detect these if a dishonest peer offers them, making it harder to cheat. Whereas if I reconstruct my node using emergency.recover, it will accept *any* outdated channel state the peer choses to offer it. Have I got this right?
Steve
CC BY-SA 4.0
2023-10-06T16:18:31.517Z
Mh no it makes sense more using the emergency.recover because if you have an old state of the channel the other peer force close the channel with you. So it is better to use emergency.recover and then use your database. In this case you can have the old state, so you are not honest peer (just because you lost the data)
vincenzopalazzo
CC BY-SA 4.0
2023-10-07T16:48:01.947Z
Thanks again. It's interesting to realise that my node is (potentially) "dishonest" in this state. I think I understand the situation now - emergency.recover is preferred not because it has a higher chance of not losing funds (it's the same as the outdated database backup in this respect), but because it allows the channels to remain open instead of being forced closed. Have I got that right now?
Steve
CC BY-SA 4.0
2023-10-07T17:30:08.960Z
yeah, with emergency.recover you are asking the other peer, please provide me the last backup that we did for the channel. So if all goes well you get the last state of the channel from some peer and you can start your node again without any problems
vincenzopalazzo
CC BY-SA 4.0
2023-10-06T07:46:21.540Z
2023-10-06T07:46:21.540Z
vincenzopalazzo
<p>Suppose my Core Lightning node has suffered a catastrophic failure. I have a copy of the HSM secret. I also have copies of the emergency.recover file and the backup file maintained by the backup plugin.</p>
<p>However, I can't be certain the emergency.recover file or the backup file are absolutely up to date. My node does a small amount of routing. Even if the backups were copied off the failed node a minute before it died, I can't be completely certain there wasn't a change in the channel balances during that minute. The situation might be even worse and the backups might be several hours old.</p>
<p>What's the best way to deal with this to reduce the chances of losing funds? Can I test the backup in some way to see if it is up-to-date? Or do I have to start up the rebuilt node using the backup and wait to see if a penalty transaction gets triggered?</p>
<p>Is it safer to try using the emergency.recover file first? If the peer cooperates, is this completely safe? If the peer tries to cheat me, do I still have time to use the backup from the backup plugin?</p>
<p>This hasn't happened yet, but I want to learn how to handle it if it does.</p>

<backup><core-lightning><ln-penalty-transaction><static-channel-backups>
How can I recover a Core Lightning node as safely as possible if the backups might be out of date?
Steve
# How can I recover a Core Lightning node as safely as possible if the backups might be out of date?

(Asked by: username_0 on 2023-10-05)

Suppose my Core Lightning node has suffered a catastrophic failure. I have a copy of the HSM secret. I also have copies of the emergency.recover file and the backup file maintained by the backup plugin.

However, I can't be certain the emergency.recover file or the backup file are absolutely up to date. My node does a small amount of routing. Even if the backups were copied off the failed node a minute before it died, I can't be completely certain there wasn't a change in the channel balances during that minute. The situation might be even worse and the backups might be several hours old.

What's the best way to deal with this to reduce the chances of losing funds? Can I test the backup in some way to see if it is up-to-date? Or do I have to start up the rebuilt node using the backup and wait to see if a penalty transaction gets triggered?

Is it safer to try using the emergency.recover file first? If the peer cooperates, is this completely safe? If the peer tries to cheat me, do I still have time to use the backup from the backup plugin?

This hasn't happened yet, but I want to learn how to handle it if it does.

**Tags:** backup, core-lightning, ln-penalty-transaction, static-channel-backups


---

## 1 answers

### Answer by username_1 on 2023-10-06. Score: 1 | Accepted answer

This is a really good question.

> Is it safer to try using the emergency.recover file first? If the peer cooperates, is this completely safe? If the peer tries to cheat me, do I still have time to use the backup from the backup plugin?

Yes this is safe, the peer can not cheat for two reasons:

* The backup is encrypted so if something changes your node you will easily find out.
* If your backup db is old I think you can start from this recovery before and if fails (maybe you have no peer that supports the peer backup feature) you can try to use the database.

Before trying this you should read in deep this page <https://docs.corelightning.org/docs/backup-and-recovery>

> What's the best way to deal with this to reduce the chances of losing funds?

The best practice is not making the backup of the database by hand, as you said this will be always outdated. CLN has different ways to do the backup like [1].

As good news, all the implementations today use `option_data_loss_protect`. This means that you trigger this part of the spec [2]

```
  - otherwise, if it supports `option_data_loss_protect`:
    - if `next_revocation_number` is greater than expected above, AND
    `your_last_per_commitment_secret` is correct for that
    `next_revocation_number` minus 1:
      - MUST NOT broadcast its commitment transaction.
      - SHOULD send an `error` to request the peer to fail the channel.
      - SHOULD store `my_current_per_commitment_point` to retrieve funds
        should the sending node broadcast its commitment transaction on-chain.
    - otherwise (`your_last_per_commitment_secret` or `my_current_per_commitment_point`
    do not match the expected values):
      - SHOULD send an `error` and fail the channel.

```

So your old backup should trigger just force closes.

Good luck.

[1] <https://docs.corelightning.org/docs/advanced-db-backup#sqlite3---walletmainbackup-and-remote-nfs-mount>
[2] <https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#message-retransmission>

> **Comments:**
> **username_0**: Thanks Vincenzo! This mostly makes sense, but having read your explanations, I'm now thinking it's better to use the possibly-outdated database backup before emergency.recover. If the peer is honest it makes no difference (right?), but if the peer isn't honest, my reconstructed node using a slightly outdated backup knows *some* of the outdated channel states and will detect these if a dishonest peer offers them, making it harder to cheat. Whereas if I reconstruct my node using emergency.recover, it will accept *any* outdated channel state the peer choses to offer it. Have I got this right?  
> **username_1**: Mh no it makes sense more using the emergency.recover because if you have an old state of the channel the other peer force close the channel with you. So it is better to use emergency.recover and then use your database. In this case you can have the old state, so you are not honest peer (just because you lost the data)  
> **username_0**: Thanks again. It's interesting to realise that my node is (potentially) "dishonest" in this state. I think I understand the situation now - emergency.recover is preferred not because it has a higher chance of not losing funds (it's the same as the outdated database backup in this respect), but because it allows the channels to remain open instead of being forced closed. Have I got that right now?  
> **username_1**: yeah, with emergency.recover you are asking the other peer, please provide me the last backup that we did for the channel. So if all goes well you get the last state of the channel from some peer and you can start your node again without any problems  

---

