<p>Unlike bitcoin stored in an on-chain wallet, funds in the lightning network are stateful. Some channel data cannot be deterministically reconstructed like keys derived from a BIP32 seed. If you do not have backups and your channel counterparty is non-responsive, you will likely experience permanent loss of funds. Make sure to have backups of your channel data made with each additional transaction you send/receive/route to other nodes in the network.</p>

<p>If a node falls down and loses critical state data it is important not to broadcast commitment transactions from old backups. If these commitment transactions have been <a href="https://bitcoin.stackexchange.com/a/56768/89313">revoked</a>, the channel counterparty will submit a justice transaction to the network and claim all of the funds in the channel. </p>

<p>This failure scenario can be partially mitigated by nodes that use <code>option_data_loss_protect</code> as specified in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#message-retransmission" rel="nofollow noreferrer">BOLT 2</a>. This allows a node to detect that it has fallen behind when reestablishing its connection. This only works when both nodes support this feature and the node that has not fallen behind is honest. If the honest node detects its counterparty has fallen out of sync, it should unilaterally close the channel and the fallen-behind node can then reclaim its funds with data it received on connection reestablishment (<code>my_current_commitment_point</code>). </p>

<p>In the future, state backups can be outsourced to 3rd parties on-the-fly, such that if a node falls down it can call on these 3rd parties to provide the necessary data for channel reconstruction. It has been proposed that <a href="https://cyber.stanford.edu/sites/default/files/hardening_lightning_updated.pdf" rel="nofollow noreferrer">Watchtowers</a> - nodes that can be compensated to monitor channels for bad behavior - could also be tasked with storing encrypted state backups. </p>

<p>If you do have a backup you can restore it and reestablish connections with your peers and get back to business!</p>

CC BY-SA 4.0
2019-05-01T18:32:46.037Z
I believe Selfishminer is referring to Bolt 2, not Bolt 12. Bolt 12 doesn't exist (11 is the last BOLT).
Paul Kania
CC BY-SA 4.0
2019-05-01T18:44:07.127Z
@paulrozehnal: You can suggest an edit!
Murch
CC BY-SA 4.0
2018-11-07T12:02:05.787Z
2019-06-12T22:19:53.597Z
2019-06-12T22:19:53.597Z
selfishminer
<p>If my lightning node crashes after receiving payments (but before I have closed the channel) can I recover my funds? What happens if I do not have backups of all the channel updates? </p>

<p>Is the restoration process fundamentally different from dealing with on-chain Bitcoin? </p>

<lightning-network><backup>
How do I restore a Lightning Node with active channels that has crashed causing data loss? Is it similar to restoring a Bitcoin wallet?
user1778171
# How do I restore a Lightning Node with active channels that has crashed causing data loss? Is it similar to restoring a Bitcoin wallet?

(Asked by: username_0 on 2017-08-15)

If my lightning node crashes after receiving payments (but before I have closed the channel) can I recover my funds? What happens if I do not have backups of all the channel updates?

Is the restoration process fundamentally different from dealing with on-chain Bitcoin?

**Tags:** lightning-network, backup


---

## 1 answers

### Answer by username_1 on 2018-11-07. Score: 4 | Accepted answer

Unlike bitcoin stored in an on-chain wallet, funds in the lightning network are stateful. Some channel data cannot be deterministically reconstructed like keys derived from a BIP32 seed. If you do not have backups and your channel counterparty is non-responsive, you will likely experience permanent loss of funds. Make sure to have backups of your channel data made with each additional transaction you send/receive/route to other nodes in the network.

If a node falls down and loses critical state data it is important not to broadcast commitment transactions from old backups. If these commitment transactions have been [revoked](https://bitcoin.stackexchange.com/a/56768/89313), the channel counterparty will submit a justice transaction to the network and claim all of the funds in the channel.

This failure scenario can be partially mitigated by nodes that use `option_data_loss_protect` as specified in [BOLT 2](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#message-retransmission). This allows a node to detect that it has fallen behind when reestablishing its connection. This only works when both nodes support this feature and the node that has not fallen behind is honest. If the honest node detects its counterparty has fallen out of sync, it should unilaterally close the channel and the fallen-behind node can then reclaim its funds with data it received on connection reestablishment (`my_current_commitment_point`).

In the future, state backups can be outsourced to 3rd parties on-the-fly, such that if a node falls down it can call on these 3rd parties to provide the necessary data for channel reconstruction. It has been proposed that [Watchtowers](https://cyber.stanford.edu/sites/default/files/hardening_lightning_updated.pdf) - nodes that can be compensated to monitor channels for bad behavior - could also be tasked with storing encrypted state backups.

If you do have a backup you can restore it and reestablish connections with your peers and get back to business!

> **Comments:**
> **username_2**: I believe username_1 is referring to Bolt 2, not Bolt 12. Bolt 12 doesn't exist (11 is the last BOLT).  
> **username_3**: @paulrozehnal: You can suggest an edit!  

---

