<p>I think one of the biggest risks is that there could exist an issue with the two way pegging mechanism. Such a failure could introduce issues where perhaps coins are unable to be retrieved from the sidechain and returned to the bitcoin blockchain. There is also the risk of an unknown network attack on the lightning network, perhaps a ddos attack against validator nodes that would render transactions unable to be processed on the off chain network. There could be others as well.</p>

CC BY-SA 3.0
2016-06-13T14:15:55.137Z
You're not saying this explicitly, but just to clarify if anyone besides me feels that it is implied: Lightning network is not a sidechain.
Murch
CC BY-SA 3.0
2016-07-22T10:11:16.870Z
A sidechain is also not an off-chain solution. It is a means for experimenting with new blockchain technology without needing to introduce a new currency. But there is still a chain, and it has problems similar to that of the main chain.
Pieter Wuille
CC BY-SA 3.0
2016-05-26T00:54:51.460Z
2016-05-26T00:54:51.460Z
Mark S.
<p>TL;DR:</p>

<p>The security assumptions of using a LN channel for payments:</p>

<ul>
<li>The blockchain is functioning well (confirming transactions quickly)</li>
<li>Channel nodes can keep secret data safe</li>
<li>There aren't any significant bugs in the software</li>
</ul>

<hr>

<p>With the Lightning network specifically, the security of the off-chain payment always depends on being able to take the transaction onto the real blockchain "if needed". When both parties cooperate, the number of on-chain transactions is minimized, but both parties rely on being able to cash out, using the real blockchain, if the other party stops cooperating or goes offline for an extended period of time. In addition, if the other party acts maliciously, you rely on being able to use the blockchain to punish their malicious actions. </p>

<p>One security risk lies here: if you cannot get transactions confirmed into the blockchain, you won't be able to get your money out of the channel, or to take counter measures when the other party tries to cheat you! <strong>So a well-functioning blockchain (confirming transactions quickly) is a definitely one security assumption of using the lightning network.</strong> So block crowding is one risk, since there won't be enough room for your transactions. Miners could also be bribed to not mine your transactions, although this is not a severe risk since it is likely that a different miner would confirm your transaction.</p>

<hr>

<p>To understand some of the other security assumptions used in the lightning network, consider the following example. Suppose Alice has a payment channel open with Bob. First the channel balances read:</p>

<pre><code>Channel Balance 1:
Alice: 0.5 BTC
Bob:   0.5 BTC
</code></pre>

<p>Then Alice makes a payment to Bob for 0.1 BTC, and the updated channel balances read:</p>

<pre><code>Channel Balance 2:
Alice: 0.4 BTC
Bob:   0.6 BTC
</code></pre>

<p>But Alice decides she wants to try to cheat Bob! She tries to broadcast the transaction for <code>Channel Balance 1</code>, in which she gets 0.5 BTC, which is more favorable to her than her balance in <code>Channel Balance 2</code>, just 0.4 BTC. What's to stop her from doing this?</p>

<p>First, there is a waiting period before she can actually spend the funds from her 0.5 BTC output in <code>Channel Balance 1</code> (technically the wait period applies to <code>Channel Balance 2</code> as well). This wait period exists to give Bob sufficient time to notice that Alice has closed out the channel, and possibly take action if Alice has broadcasted an old version of the channel. In this case, since Alice closed out the channel with an older version of the channel state, Bob can actually take all of the funds in Alice's 0.5 BTC output! Hence, Alice is disincentivized from broadcasting old versions of the channel state. </p>

<p>The problem is that if Bob can't get his transaction that took the 0.5 BTC from Alice into the blockchain, then the wait period will end and Alice will have the opportunity to take the 0.5 BTC, successfully stealing 0.1 BTC (because she should only be allowed to take 0.4). <strong>So Bob depends on being able to take counter measures against Alice in the real blockchain before a wait period ends if Alice tries to broadcast an older version of the channel state.</strong></p>

<p>(Note that this wait period also applies to Bob if he needs to get funds out of the channel without the help of Alice. Even if he broadcasts the most recent state of the channel, he has to wait. While this wait period may be inconvenient for Bob, Alice also has to abide by the wait period, which is what gives Bob a chance to take all of the funds in the channel if Alice tries to broadcast an old version of the channel. If things go as planned, though, and no one goes offline, then Alice and Bob can agree to make a new transaction to close the channel, where neither one has to wait to spend their funds.)</p>

<hr>

<p>There is also a data security risk. Proving to the other channel party that you will not try to broadcast previous versions of the channel balance state involves giving the other channel party a bit of secret information, typically the preimage of a hash. Usually you only reveal this data to your channel counter-party when you update the state of the channel and receive a new guarantee of payment (just with a different balance). After you receive the new payment, you can reveal the secret information that invalidates the previous payment by giving them the ability to steal the funds from that old channel state if you try to broadcast it.</p>

<p>But if the secret data associated with the current state of the channel is revealed or stolen before you get a separate payment guarantee transaction, then effectively all of your transactions have been revoked and your channel counter-party can steal all the funds from any channel transaction you broadcast! So, <strong>the security of a LN payment channel depends on being able to keep data safe.</strong> </p>

<hr> 

<p><strong>Another risk is simply bugs in software.</strong> If your software doesn't automatically handle all the edge cases of broadcasting the right transaction at the right time, and your counter party discovers that, they can take advantage of it and steal funds from the channel. </p>

CC BY-SA 3.0
2018-01-21T09:46:50.400Z
Couldn't you theoretically launch a successful attack on the lightning network just by having your node prefer LN transactions (since they're chained between many parties) which result in you gaining funds (e.g. which transfer to other parties) then favoring funds which result in losing funds (e.g. withdrawing from other parties) then waiting on the node to disconnect from the network (e.g. power outages, ISP failures, etc - that stuff happens all the time and if you have enough open LN connections you're bound to hit on a large number of them) before broadcasting an old state?
CoryG
CC BY-SA 4.0
2019-01-16T16:22:56.290Z
The submitter of the penalty transaction chooses the transaction fee, and it should always be possible to chose a higher transaction fee for the penalty transaction as for the fraudulent old commitment transaction, and theoretically both or none of the transactions should go through.  Ok, so Alice knows a miner and sneaked in that transaction ... but Bob can also get the penalty transaction in that way, some mining pool has paid services for prioritizing transactions.
tobixen
CC BY-SA 3.0
2016-05-26T02:31:48.123Z
2016-07-21T17:09:54.383Z
2016-07-21T17:09:54.383Z
morsecoder
<p>What type of security weaknesses are potentially created by using off chain solutions (such as the lightning network) for a portion of Bitcoin network traffic?</p>

CC BY-SA 3.0
2016-05-26T08:11:28.147Z
I don't know what bitcoin.se is like, but on Stack Overflow a question like this would be closed for being too broad. How do you define security? *Which* off-chain solutions for *which* traffic? There's an answer that assumes you're talking about using the Lightning network for payments, and security means being able to keep the money you think you've received.
Criticize SE actions means ban
<security><lightning-network>
What security weaknesses result from using off chain solutions?
Brad Collins
# What security weaknesses result from using off chain solutions?

(Asked by: username_0 on 2016-05-25)

What type of security weaknesses are potentially created by using off chain solutions (such as the lightning network) for a portion of Bitcoin network traffic?

**Tags:** security, lightning-network

> **Comments:**
> **username_1**: I don't know what bitcoin.se is like, but on Stack Overflow a question like this would be closed for being too broad. How do you define security? *Which* off-chain solutions for *which* traffic? There's an answer that assumes you're talking about using the Lightning network for payments, and security means being able to keep the money you think you've received.  

---

## 2 answers

### Answer by username_5 on 2016-05-26. Score: 18 | Accepted answer

TL;DR:

The security assumptions of using a LN channel for payments:

* The blockchain is functioning well (confirming transactions quickly)
* Channel nodes can keep secret data safe
* There aren't any significant bugs in the software

---

With the Lightning network specifically, the security of the off-chain payment always depends on being able to take the transaction onto the real blockchain "if needed". When both parties cooperate, the number of on-chain transactions is minimized, but both parties rely on being able to cash out, using the real blockchain, if the other party stops cooperating or goes offline for an extended period of time. In addition, if the other party acts maliciously, you rely on being able to use the blockchain to punish their malicious actions.

One security risk lies here: if you cannot get transactions confirmed into the blockchain, you won't be able to get your money out of the channel, or to take counter measures when the other party tries to cheat you! **So a well-functioning blockchain (confirming transactions quickly) is a definitely one security assumption of using the lightning network.** So block crowding is one risk, since there won't be enough room for your transactions. Miners could also be bribed to not mine your transactions, although this is not a severe risk since it is likely that a different miner would confirm your transaction.

---

To understand some of the other security assumptions used in the lightning network, consider the following example. Suppose Alice has a payment channel open with Bob. First the channel balances read:

```
Channel Balance 1:
Alice: 0.5 BTC
Bob:   0.5 BTC

```

Then Alice makes a payment to Bob for 0.1 BTC, and the updated channel balances read:

```
Channel Balance 2:
Alice: 0.4 BTC
Bob:   0.6 BTC

```

But Alice decides she wants to try to cheat Bob! She tries to broadcast the transaction for `Channel Balance 1`, in which she gets 0.5 BTC, which is more favorable to her than her balance in `Channel Balance 2`, just 0.4 BTC. What's to stop her from doing this?

First, there is a waiting period before she can actually spend the funds from her 0.5 BTC output in `Channel Balance 1` (technically the wait period applies to `Channel Balance 2` as well). This wait period exists to give Bob sufficient time to notice that Alice has closed out the channel, and possibly take action if Alice has broadcasted an old version of the channel. In this case, since Alice closed out the channel with an older version of the channel state, Bob can actually take all of the funds in Alice's 0.5 BTC output! Hence, Alice is disincentivized from broadcasting old versions of the channel state.

The problem is that if Bob can't get his transaction that took the 0.5 BTC from Alice into the blockchain, then the wait period will end and Alice will have the opportunity to take the 0.5 BTC, successfully stealing 0.1 BTC (because she should only be allowed to take 0.4). **So Bob depends on being able to take counter measures against Alice in the real blockchain before a wait period ends if Alice tries to broadcast an older version of the channel state.**

(Note that this wait period also applies to Bob if he needs to get funds out of the channel without the help of Alice. Even if he broadcasts the most recent state of the channel, he has to wait. While this wait period may be inconvenient for Bob, Alice also has to abide by the wait period, which is what gives Bob a chance to take all of the funds in the channel if Alice tries to broadcast an old version of the channel. If things go as planned, though, and no one goes offline, then Alice and Bob can agree to make a new transaction to close the channel, where neither one has to wait to spend their funds.)

---

There is also a data security risk. Proving to the other channel party that you will not try to broadcast previous versions of the channel balance state involves giving the other channel party a bit of secret information, typically the preimage of a hash. Usually you only reveal this data to your channel counter-party when you update the state of the channel and receive a new guarantee of payment (just with a different balance). After you receive the new payment, you can reveal the secret information that invalidates the previous payment by giving them the ability to steal the funds from that old channel state if you try to broadcast it.

But if the secret data associated with the current state of the channel is revealed or stolen before you get a separate payment guarantee transaction, then effectively all of your transactions have been revoked and your channel counter-party can steal all the funds from any channel transaction you broadcast! So, **the security of a LN payment channel depends on being able to keep data safe.**

---

**Another risk is simply bugs in software.** If your software doesn't automatically handle all the edge cases of broadcasting the right transaction at the right time, and your counter party discovers that, they can take advantage of it and steal funds from the channel.

> **Comments:**
> **username_6**: Couldn't you theoretically launch a successful attack on the lightning network just by having your node prefer LN transactions (since they're chained between many parties) which result in you gaining funds (e.g. which transfer to other parties) then favoring funds which result in losing funds (e.g. withdrawing from other parties) then waiting on the node to disconnect from the network (e.g. power outages, ISP failures, etc - that stuff happens all the time and if you have enough open LN connections you're bound to hit on a large number of them) before broadcasting an old state?  
> **username_7**: The submitter of the penalty transaction chooses the transaction fee, and it should always be possible to chose a higher transaction fee for the penalty transaction as for the fraudulent old commitment transaction, and theoretically both or none of the transactions should go through.  Ok, so Alice knows a miner and sneaked in that transaction ... but Bob can also get the penalty transaction in that way, some mining pool has paid services for prioritizing transactions.  

---

### Answer by username_2 on 2016-05-26. Score: 4

I think one of the biggest risks is that there could exist an issue with the two way pegging mechanism. Such a failure could introduce issues where perhaps coins are unable to be retrieved from the sidechain and returned to the bitcoin blockchain. There is also the risk of an unknown network attack on the lightning network, perhaps a ddos attack against validator nodes that would render transactions unable to be processed on the off chain network. There could be others as well.

> **Comments:**
> **username_3**: You're not saying this explicitly, but just to clarify if anyone besides me feels that it is implied: Lightning network is not a sidechain.  
> **username_4**: A sidechain is also not an off-chain solution. It is a means for experimenting with new blockchain technology without needing to introduce a new currency. But there is still a chain, and it has problems similar to that of the main chain.  

---

