2

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.

1 Answer 1

1

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

4
  • 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
    Oct 6, 2023 at 16:08
  • 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) Oct 6, 2023 at 16:18
  • 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
    Oct 7, 2023 at 16:48
  • 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 Oct 7, 2023 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.