<p>The main difference is that Bitcoin in lightning network channels are in 2of2 multisig wallets. You own a key and your channel peer owns the second key. Your funds are "safe" because you have pre-signed transactions that spend from that multisig wallet (similar to an offline signing of a transaction). As soon as you keep those pre-signed transactions, your funds are safe (technically you need to also keep some state information to sweep the outputs of those transactions). Apparently it is harder to keep several presigned transactions with a little state in comparison to just a private key. </p>

CC BY-SA 4.0
2019-10-23T15:36:51.287Z
2019-10-24T09:56:34.463Z
2019-10-24T09:56:34.463Z
Rene Pickhardt
<p>There are a few reasons why a user can lose funds in the lightning network. But to understand why that happens let us look at some of the basic constructs of Lightning Network.</p>

<hr>

<h2>Lightning Basics</h2>

<p>When two parties open a channel in Lightning Network what they essentially do is send some bitcoins to a 2-of-2 multi-sig that they both control (in current specs only one party can send it). This 2-of-2 multi-sig UTXO is then consumed as an input to create commitment transactions where the outputs pay out the bitcoins to the two parties based on who is owed what (just like a balance sheet).</p>

<p>However, the commitment transaction outputs are asymmetric. Below is an example of commitment transactions that Alice and Bob will hold for their channel with total capacity of 0.1 BTC. Alice currently has 0.07 BTC and Bob has 0.03 BTC in terms of their balance in the channel. The below commitment transaction state also considers the case where Alice is asking Bob to add a HTLC of 0.01 BTC (thus reducing her balance to 0.06 BTC).</p>

<p><a href="https://i.sstatic.net/62UpV.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/62UpV.png" alt="Commitment transaction infographic"></a></p>

<p>As you can see from the infographic above, the outputs that pay to self are guarded by the revocation keys. It pays the revocation key immediately but pays the self's public key after a delay of say N blocks. Whenever, Alice and Bob will sign a new commitment transaction, they will revoke the previous commitment state by sharing their side of the revocation secret with the other. Thus, if one of the party tries to broadcast the previous state of the channel, the other party can take <strong>the entire balance of the channel</strong> by using the revocation secret (until N blocks after which both parties can spend). This deters them from broadcasting a commitment transaction that reflects the previous state of the channel due to the risk of losing their entire funds from the channel.</p>

<hr>

<h2>Losing funds from losing backups</h2>

<p>Revocation is a double edged sword. Both the parties <strong>must</strong> keep the revocation keys that were shared for the previous states and all of the commitment transactions. If one of them is lost, the other party can possibly cheat the other. This is especially scary when your machine crashes making you to lose your backups. Below are the two different ways in which a user can lose funds:</p>

<p>(1) <strong>You lose your partner's revocation keys:</strong> If you lose your partner's revocation keys then if the other side publishes a previous state of the channel, that was more beneficial to them, you cannot use the power of the revocation keys to take the entire balance state. You must have delivered some goods to them by adding a new commitment transaction that reflects that, but since you lost the revocation key to the previous transaction state, your partner can broadcast the previous state without any worry of you taking their entire balance.</p>

<p>(2) <strong>You lose the commitment transactions:</strong> There are two ways in which an attack can happen on your funds if you lose the previously signed commitment transactions: (1) If your counterparty tries to broadcast a previous state of the channel, you will not be able to watch the blockchain for the <code>txid</code> as you have lost your commitment transaction. You might have to use a more expensive way by looking at each input of every transaction that enters the blockchain and seeing the spending from the 2-of-2 multisig. (2) If you lose your commitment transactions and the counterparty becomes unresponsive, then there is no way for you to get back your bitcoins. The bitcoins will remain locked in the multi-sig which you will not be able to spend until the other party comes back online.</p>

<p>There are couple of ways in which lightning implementations try to solve this like <code>option_data_loss_protect</code>. This allows the node for knowing the current commitment state and see if it has fallen behind. However, this relies on the fact that the party that is most up-to-date is honest. The other party might take the advantage that the other node has fallen behind and might cheat it.</p>

<hr>

<h2>Losing funds from going offline</h2>

<p>There is also a risk of losing funds by going offline. Suppose say Alice wanted to send 0.01 BTC to Charlie. Alice will sign a commitment transaction with Bob and Bob will sign one with Charlie as shown above. Just after adding a commitment transaction with Charlie, Bob faces a power outage that cuts his internet connection. Charlie releases the preimage to the HTLC and gets his funds immediately. Suppose say Bob couldn't come online for a day. After some blocks Alice will assume that the HTLC did not go through and get the funds back to her after the delay of M blocks. Thus Bob lost the amount of BTC that Alice wanted to send to Charlie. Imagine this happens if you have multiple HTLCs added and you cannot come back online.</p>

CC BY-SA 4.0
2019-10-23T17:44:44.247Z
2019-10-28T09:34:10.313Z
2019-10-28T09:34:10.313Z
Ugam Kamat
<p>In Bitcoin once you own a private key associated with an address that has bitcoins on it, your funds are theoretically safe forever.
But on the Lightning Network, I see that once you send bitcoin to an address there, your funds can somehow disappear. What is the difference with Bitcoin and who or what owns the Bitcoin once they are there?</p>

<transactions><address><security><private-key><lightning-network>
How can someone lose funds in Lightning Network?
Saxtheowl
# How can someone lose funds in Lightning Network?

(Asked by: username_0 on 2019-10-23)

In Bitcoin once you own a private key associated with an address that has bitcoins on it, your funds are theoretically safe forever.
But on the Lightning Network, I see that once you send bitcoin to an address there, your funds can somehow disappear. What is the difference with Bitcoin and who or what owns the Bitcoin once they are there?

**Tags:** transactions, address, security, private-key, lightning-network


---

## 2 answers

### Answer by username_2 on 2019-10-23. Score: 6 | Accepted answer

There are a few reasons why a user can lose funds in the lightning network. But to understand why that happens let us look at some of the basic constructs of Lightning Network.

---

## Lightning Basics

When two parties open a channel in Lightning Network what they essentially do is send some bitcoins to a 2-of-2 multi-sig that they both control (in current specs only one party can send it). This 2-of-2 multi-sig UTXO is then consumed as an input to create commitment transactions where the outputs pay out the bitcoins to the two parties based on who is owed what (just like a balance sheet).

However, the commitment transaction outputs are asymmetric. Below is an example of commitment transactions that Alice and Bob will hold for their channel with total capacity of 0.1 BTC. Alice currently has 0.07 BTC and Bob has 0.03 BTC in terms of their balance in the channel. The below commitment transaction state also considers the case where Alice is asking Bob to add a HTLC of 0.01 BTC (thus reducing her balance to 0.06 BTC).

[![Commitment transaction infographic](https://i.sstatic.net/62UpV.png)](https://i.sstatic.net/62UpV.png)

As you can see from the infographic above, the outputs that pay to self are guarded by the revocation keys. It pays the revocation key immediately but pays the self's public key after a delay of say N blocks. Whenever, Alice and Bob will sign a new commitment transaction, they will revoke the previous commitment state by sharing their side of the revocation secret with the other. Thus, if one of the party tries to broadcast the previous state of the channel, the other party can take **the entire balance of the channel** by using the revocation secret (until N blocks after which both parties can spend). This deters them from broadcasting a commitment transaction that reflects the previous state of the channel due to the risk of losing their entire funds from the channel.

---

## Losing funds from losing backups

Revocation is a double edged sword. Both the parties **must** keep the revocation keys that were shared for the previous states and all of the commitment transactions. If one of them is lost, the other party can possibly cheat the other. This is especially scary when your machine crashes making you to lose your backups. Below are the two different ways in which a user can lose funds:

(1) **You lose your partner's revocation keys:** If you lose your partner's revocation keys then if the other side publishes a previous state of the channel, that was more beneficial to them, you cannot use the power of the revocation keys to take the entire balance state. You must have delivered some goods to them by adding a new commitment transaction that reflects that, but since you lost the revocation key to the previous transaction state, your partner can broadcast the previous state without any worry of you taking their entire balance.

(2) **You lose the commitment transactions:** There are two ways in which an attack can happen on your funds if you lose the previously signed commitment transactions: (1) If your counterparty tries to broadcast a previous state of the channel, you will not be able to watch the blockchain for the `txid` as you have lost your commitment transaction. You might have to use a more expensive way by looking at each input of every transaction that enters the blockchain and seeing the spending from the 2-of-2 multisig. (2) If you lose your commitment transactions and the counterparty becomes unresponsive, then there is no way for you to get back your bitcoins. The bitcoins will remain locked in the multi-sig which you will not be able to spend until the other party comes back online.

There are couple of ways in which lightning implementations try to solve this like `option_data_loss_protect`. This allows the node for knowing the current commitment state and see if it has fallen behind. However, this relies on the fact that the party that is most up-to-date is honest. The other party might take the advantage that the other node has fallen behind and might cheat it.

---

## Losing funds from going offline

There is also a risk of losing funds by going offline. Suppose say Alice wanted to send 0.01 BTC to Charlie. Alice will sign a commitment transaction with Bob and Bob will sign one with Charlie as shown above. Just after adding a commitment transaction with Charlie, Bob faces a power outage that cuts his internet connection. Charlie releases the preimage to the HTLC and gets his funds immediately. Suppose say Bob couldn't come online for a day. After some blocks Alice will assume that the HTLC did not go through and get the funds back to her after the delay of M blocks. Thus Bob lost the amount of BTC that Alice wanted to send to Charlie. Imagine this happens if you have multiple HTLCs added and you cannot come back online.


---

### Answer by username_1 on 2019-10-23. Score: 4

The main difference is that Bitcoin in lightning network channels are in 2of2 multisig wallets. You own a key and your channel peer owns the second key. Your funds are "safe" because you have pre-signed transactions that spend from that multisig wallet (similar to an offline signing of a transaction). As soon as you keep those pre-signed transactions, your funds are safe (technically you need to also keep some state information to sweep the outputs of those transactions). Apparently it is harder to keep several presigned transactions with a little state in comparison to just a private key.


---

