What security weaknesses result from using off chain solutions?

Question

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?

Answer 1

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.

Answer 2

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.