For many scenarios in this article we will assume that both parties use fully-functional SPV LN wallets on mobile devices, because there is no reason to talk about global adoption, until LN will be fully usable on mobile devices.

Closing channels uncooperatively

User’s funds will be locked for a long time after closing channel unilaterally

In order to prevent cheating by broadcasting an older state of LN channel, there is CSV (CheckSequenceVerify) time-lock, which will literally lock the funds for certain amount of time, giving a counterparty a chance to punish a cheater by broadcasting a transaction that contains a ‘secret key’ from that old state.

The most common delay will probably be around 144 blocks (~1 day), but it might vary a lot. And here is a problem: if we decrease a time-lock value, so user can get money onchain much faster, then a risk to lose money due to cheating will dramatically increase as well; but if we increase a time-lock value to decrease risks of cheating, then user won’t be able to spend his funds for a long time.

Solution: there is no perfect solution with a current logic, because time-locks will always balance between safety and liquidity, but Submarine Swaps might help to get money onchain faster, if they will be widely adopted. 3rd party LN Watchtowers might also decrease a common delay time without a big safety trade-off, but it’s still not clear how they will operate.

User should make backups after each LN transaction

To recover all his funds, user should not only have a recovery seed, but also backups of latest states for all his LN channels. It is very important to have a latest version, because broadcasting any previous state will be punished by losing all funds.

If a network somehow avoids centralization, then this problem will become even more severe, because many people will relay payments (routing), so the backups must be made automatically and be saved in the cloud, which will introduce privacy risks.

Even if data will be encrypted, it will be possible to track a ‘backup event’, and potentially identify an amount of hops, which is crucial information e.g. when using big hubs with just 1–2 hops. Also the data will be stored in some data center, instead of being deleted after a channel closure, so later it might be decrypted with (or without) user’s leaked keys.

Solution: it’s still unclear how and when ‘backups’ problem will be solved, but Lightning Labs (lnd) claims that ‘dynamic’ backups will be implemented as a Watchtower feature (one day), but the privacy issue is still relevant.

Exhausted channels

Many imbalanced (exhausted) LN channels will occur — when all or most money are on one side. It will be very dangerous, if a counterparty has an older state, where all or most money on his side, because it becomes very lucrative to cheat (risk almost nothing for a chance to get all channel’s funds).

E.g. Alice opens a channel with Bob and funded it for 1 BTC. After a few transactions, all 1 BTC moved to Bob’s side.

Alice (1btc) — — (0btc) Bob ←old state

Alice (0btc) — — (1btc) Bob ←latest state

Now Alice can try to cheat Bob by broadcasting on the blockchain an old state, where she had all the funds. If Bob punished her, Alice will lose nothing, but onchain fees for a cheating transaction. If Alice succeeds, she will get 1 BTC.

User should keep untrusted counterparty from exhausting a channel

As a result, a user should be at least aware of ‘exhausted channel’ risks and make right decisions in each particular situation.

Solution: a minimum collateral should be set automatically (especially if routing is enabled), but user still should be aware of a problem and not change default settings when dealing with untrusted nodes. User should also be able to enable full ‘exhaustion’ for some channels (e.g. with friends). And anyway, even if automatic collateral will be implemented, it will introduce many other issues:

Where minimum collateral value will be set?

There are different approaches, e.g. a minimum collateral value to prevent exhaustion can be set in user’s client (wallet), but it might create problems, when other nodes will check for an available channel capacity for routing. It will also introduce many UX confusions, e.g. “why I have $100 in LN channel, but can spend only $80?” Also it will be unclear when creating a new channel, how much you will be able to spend there, because some nodes might set minimum collateral value to 10%, while others to 30%.

Another approach is to set fixed minimum collateral value during channel creation, but it will again introduce several issues, because a system will be less flexible to changes, and non-savvy users might become victims of thieves, who will create channels with them, setting minimum collateral to zero or to a very low value, and then try to cheat them after some routing.

One more approach I can think of is to change a protocol, and force everybody to use the same minimum collateral value (e.g. 20%), but it’s very inflexible and poor UX, especially for channels with trusted nodes (relatives, friends).

Minimum collateral will introduce more complexity to UI

Apart from additional values for ‘settings’, users should also be able to see how much they can spend from the total amount of LN balance, so here is a user-friendly version:

3 BTC — lightning network available to spend

4 BTC — lightning network balance

5 BTC— onchain balance

9 BTC — total

I’ve also added ‘total’, because otherwise non-savvy users might be confused, because 3+4+5=12 BTC.

This UI might be fine for geeks, but I doubt that regular users will like it, because most other e-payment solutions have just 1 balance, not 4.

User won’t be able to send money from single-funded channels

Alice pays 1 BTC salary to Bob every month. They decided to use LN and opened a single-funded channel: Alice deposited 10 BTC, Bob deposited nothing. Default (or common) minimum collateral value is still not defined, so let’s assume it’s 20%.

Alice (10 btc) — — (0 btc) Bob ←initial state

After one month, Alice transfered a salary of 1 BTC to Bob.

Alice (9 btc) — — (1 btc) Bob ←after first month

Unfortunately, Bob cannot spend his salary (e.g. by routing through Alice), because a minimum collateral value is set to 20% to prevent channel exhaustion, which is 2 BTC in this case. He will be able to spend some funds only after third salary (when his balance will be above 2 BTC), or after closing a channel.

One can argue that 20% is too much, but the problem will remain even if we decrease a minimum collateral to 10%, while a chance to be cheated will become exponentially higher.

There is also an argument that LN should be used only for small transactions, while big transactions should happen onchain. But as we already discussed, a relatively ‘small’ transaction can be a weekly salary in developing countries.

Solution: calculate a minimum collateral not from a total channel capacity, but from a sum that adversary can ‘steal’ by cheating, and also dynamically recalculate a minimum collateral value after each transaction — should fix this problem, but it will add even more confusions to UX, e.g.:

Alice (10 btc) — — (0 btc) Bob ←initial state

Alice ( 9 btc) — — (1 btc) Bob ←after first month

After the first month Bob can cheat Alice for the maximum of 1 BTC (if he routes 1 BTC payment through Alice and then broadcasts a previous state, where he had 1 BTC). So 20% of minimum collateral value should be calculated not from a total channel capacity (10 BTC), but from a maximum sum, which Bob can ‘steal’ from Alice by cheating (1 BTC after first month). Sounds reasonable so far, right? But let’s see what happens further:

After receiving his first salary, Bob will be able to spend 0.8 BTC, because 0.2 BTC will become a collateral.

Alice (10 btc) — — (0 btc) Bob ←initial state

Alice (9 btc) — — (1 btc) Bob ←Alice paid salary for a first month

Alice (9.8 btc) — — (0.2 btc) Bob ←Bob spent 0.8 BTC through Alice

Alice (8.8 btc) — — (1.2 btc) Bob ←Alice paid salary for a second month

Now Bob can ‘steal’ from Alice up to 1.2 BTC (after routing), so a collateral will be set to 0.24 BTC (20% from 1.2), so Bob can spend 0.96 BTC more after a second salary.

Alice (9.76 btc) — — (0.24 btc) Bob ←Bob spent 0.96 BTC through Alice

So after 2 salaries Bob was able to spend 1.76 BTC totally (0.8+0.96).

It’s not perfect, because some Bob’s funds are locked as a collateral, but it might work out. However, let’s see what happen, if Bob don’t spend his first salary, because he has another source of income, and he is saving some money to buy something after a second month.

Alice (10 btc) — — (0 btc) Bob ←initial state

Alice (9 btc) — — (1 btc) Bob ←Alice paid salary for a first month

Alice (8 btc) — — (2 btc) Bob ←Alice paid salary for a second month

Now Bob can ‘steal’ from Alice up to 2 BTC (after routing), so a collateral will be set to 0.4 BTC (20% from 2), so Bob can spend 1.60 BTC.

Alice (9.6 btc) — — (0.4 btc) Bob ←Bob spent 1.6 BTC through Alice

So after 2 salaries Bob was able to spend only 1.60 BTC (0.17 less than in the previous example).

Now try to explain to a regular non-tech savvy LN user that he will be able to spend less money, if he saves more.

It not only sounds weird, but also introduces problems with planning, because users won’t be sure how much they will be able to spend after receiving a salary. That might be crucial, if a person needs to buy food, but his money suddenly stacked as a collateral.

Collateral funds will be locked out from economy

Regardless of an implementation (voluntary or mandatory, dynamic or static, client-side or during channel opening), the collateral funds will be locked out from the money circulation.

Collateral doesn’t totally fix a problem of imbalanced channels

Even with a big collateral of 20%, the initial problem of exhausted (or better say, imbalanced channels) will remain, because there will be many channels with 1:3 risk/reward ratio, so a cheater will have to succeed only in 26% of his attacks in order to profit.

26% is an achievable number for hubs, that will monitor users’ activity and uptime, especially if there will be no reputation system to punish them for malicious behavior. Don’t forget that every day people unexpectedly lose their phones, fall into coma, get imprisoned, or lose internet connection due to natural disasters, which creates a big room for cheating.

And 20% collateral is pretty ambitious, because many people will want to set it to 10%, which will significantly increase risk/reward ration to 1:8, or even to 5% with 1:18 risk/reward ration, so cheaters will have to succeed just in 6% of their attacks in order to make a profit.

One can argue that most people will use only ‘spending’ wallets and won’t participate in routing, but then we will end up with a heavily centralized system. And if LN wants to global-scale, then all participants should also receive money through it, they can’t only spend.

Solutions: there are at least 3 approaches I can think of.

A system can somehow increase a collateral without locking funds out of a circulation, example by sharing a collateral over a few channels, so cheating in 1 channel will lead to losing a portion of collateral in many other channels. That will make cheating attempts more ‘expensive’, but it can introduce new issues.

Another approach is to implement reputation systems, so cheating hubs will have less users, but then system will complete stop being ‘trustless’ and it will add more complexity to UX. Also it won’t stop a big hub from exit-scam (more about that in the next articles).

The best solution so far is to make cheating less likely to succeed by using 3rd party Watchtowers that will always monitor blockchain for cheating attempts and broadcast ‘punishing’ transactions when it’s needed. The problem is that Watchtowers are not ready yet, and they are also very flawed, which we will talk about in the next articles.

Spending

User has to be online to receive a payment

This is a big UX problem for global adoption, but it was partially covered in a previous section about channel creation.

I’ll just emphasize once again, that the problem is very important for people without stable internet connection (e.g. in developing countries) and for international companies because of different timezones. However, it’s a poor UX even for people from developed countries with stable connection.

User has to expose his private keys to receive payments

All LN wallets are ‘hot’, meaning that you cannot use ‘cold storage’ for LN payments, which introduces major security risks.

Solution: there are a few proposed solutions, e.g. Alex Bosworth wrote:

The most promising method is the lock and unlock model. The daemon process enforces arbitrary security rules, users check the daemon deployment before giving it decrypted wallet data.

Hopefully, one day online wallets will become more secure, but the downside of securing ‘hot’ wallets is more LN centralization, because hubs will have less risks.

There is also a misconception that big hubs should store huge amounts of money on ‘hot’ wallet to collect LN fees from routing, but we will talk about this misconception in the next articles.

Poor UX with hardware wallets

It’s still not clear how full hardware wallet (HW) integration will function.

If HW will blindly auto-sign all LN transactions (e.g. for routing), then user might still lose his funds by signing a withdrawal request from a malicious software.

If HW will auto-sign only routing LN transactions (HTLC), but require all other LN transactions to be manually confirmed on a device, then an attacker can still fake HTLC transactions and withdraw all user’s funds.

But even with a fully safe HW integration, user will have to be always connected to his HW to participate in routing, which is not an option for an average user, until hardware wallets will be built into computers and mobile devices.

As for end node user, he will have to connect his HW to receive LN payments, which is so poor UX, that most people will not use hardware wallets if LN got widely adopted beyond crypto geeks.

Solution: use two separate wallets for storing money onchain and spending them via LN. This is not a bad approach from a security standpoint, but it can over-complicate an onboarding process.

Your boss will track your financial activity and be a middleman

Bob doesn’t use Bitcoin, but he found a new IT job in a company, where salary is paid via LN. After one month his boss Alice opened a LN channel with Bob, she funded it with 6 BTC, and transfered to Bob a first salary of 1 BTC.

Can Bob start opening new channels and spending his first salary? No.

All his funds are in LN channel with Alice and, even if there is no minimum collateral value, Bob can spend his funds only via Alice’s channel, but for that she has to enable routing and be online 24/7 (or close to that).

Alice will also be able to track when Bob makes his payments, what’s the amount and approximate destination (next hop) of each transaction, and how much Bob spends/saves after a month. And yeah, Alice can also charge fees for routing as a middleman.

Solution: there might be a few solutions, but all of them have downsides.

Bob can use Submarine Swaps to transfer his 1 BTC from offchain to onchain, and then open channels to merchants, but Alice should still allow routing for that to happen, all hops should have enough capacity available for routing of 1 BTC, and Bob still will get less money, because of onchain fees. So there is no point to receive a salary via LN, he could just ask Alice to send him salary onchain and cover fees by himself.

Bob can transfer all his salary at once via Alice to his another LN channel, which is connected to a big hub, but Bob needs to already have this channel with at least 1 BTC capacity, and all hops should have enough capacity available for routing of 1 BTC, and Alice still has to allow routing. Don’t forget that most regular users will just choose the most convenient option, which is to route all small payments through Alice in this case.

Another solution is to use LN only for micropayments, but a relatively ‘small’ transaction can be a weekly salary in developing countries. And even in rich countries people might choose other e-payment systems, which don’t have so high fees and complex logic.

This problem can be solved if LN will be wide-adopted and become dominant payment solution, and onchain fees will be low enough for users (even from developing countries) to open many channels. But that’s not gonna happen any time soon.

Routing

Similar to Tor, Lightning Network uses Onion Routing, but Tor doesn’t have channel capacities with constantly changing balances (states), which makes things much more complicated for LN.

Also Tor messages (cells) have fixed size of 512 bytes to make traffic analysis much harder, while most crypto payments have very unique value like e.g. 0.0018261 BTC, which introduces additional risks, but let’s leave anonymity issues for the next articles.

LN payments cannot be split into smaller payments for routing

The full path discovery is made by the user (his software) before the routing, and since large payments cannot be split info smaller payments, each hop in the path should have enough channel capacity on the right side.

Also time is very limited, because ideally LN wallet should find different paths and choose the most cheapest one with low offchain fees and at least a few hops for anonymity. Unfortunately, a path can become invalid in any second, if somebody else uses at least one channel from user’s path, especially if user tries to route a relatively big payment.

That will incentivize average users to use one big hub with enough liquidity (centralization).

Solution: Atomic Multipath Payments (AMP) will fix that by allowing large payments to be split into multiple small payments, which would be sent via different routes to a single recipient, who will combine all payments into one.

However, it’s still not clear when AMP will be released.

Funds will weight to certain side because of a routing

Alice opens 6 BTC channel to Bob, she also has 1 BTC channel to Shop.

Shop (0 btc) — — (1 btc) Alice (6 btc) — — (0 btc) Bob

Alice pays 1 BTC salary to Bob.

Shop (0 btc) — — (1 btc) Alice (5 btc) → → (1 btc) Bob

Bob sends 1 BTC to Shop via Alice (routing).

Shop (1 btc)← ← (0 btc) Alice (6 btc) ← ← (0 btc) Bob

Now Alice wants to pay to Shop (e.g. buy something), but she cannot do it, because all her channel capacity has shifted towards Shop’s side.

Let’s see what Alice can do:

Open a new channel, but then she will pay high onchain fees.

Recharge her channel with Submarine Swaps or Splicing, but that will again imply onchain fees.

Rebalance a channel by sending transaction back to herself, if she has another channel (or route) with 1 BTC capacity to Shop, but then there is no sense in rebalancing.

Try to route a payment to Shop through Bob if he has other channels opened with a path to Shop, assuming that Bob doesn’t have a direct channel to Shop, otherwise he won’t need to route a first payment through Alice. So even if Bob has 1 BTC path to Shop via other nodes, Alice will have to make more hops and pay more offchain fees. And the fees that she received from Bob won’t cover that, because Bob paid fees for only 1 hop, while Alice will have to pay fees for at least 2 hops.

Finally, Alice can wait until somebody will route 1 BTC payment to her via Shop, but that can take an unknown period of time.

As we can see, all options implies either high onchain fees (if Bob is an end node), or more offchain fees than if she paid directly to Shop, or waiting.

Of course, this scenario won’t happen all the time, but it will create certain problems here and there, like traffic jams, which might make a whole system unreliable for day-to-day spending.

Just imagine, you want to buy some food in a grocery shop, but 10 minutes ago your employee Bob (he didn’t have a direct channel to shop, because he is from another neighborhood) routed a payment through you, shifting all your channel balance towards the shop. If there are no other paths to this shop, then you have to open a new channel (or do Submarine Swap/Splicing), pay onchain fees, wait for confirmation, and only then pay with LN. And yeah, Bob might have some hard time in the office after that.

Solution: Alice might disable routing, but that will lead to centralization, if most users will be ‘end nodes’ instead of ‘forwarding nodes’. More than that, Bob won’t be able to spend his salary until channel closure, which is a deal breaker.

One can argue that Alice shouldn’t open a channel to Bob in the first place, but just route all salaries via a hub (e.g. Shop), but that implies Bob being already connected to that Shop with enough balance on the Shop’s side to route his salary, which is impossible as Bob is a new LN user.

And “don’t use LN for big payments” is not a solution, because in developing countries $20 might be a weekly salary. And even in rich countries people might choose other e-payment solutions with less fees and complexity.

This problem can be mitigated if LN will become wide-adopted decentralized dominant payment solution with a high number of average channels per user, but that’s not gonna happen any time soon.

The only reasonable solution for this problem, that I see so far, is channel factories, if they will ever be implemented. However, channel factories is still just a concept, which can introduce many new issues during implementation.

Parasite nodes can force users pay high fees or become end nodes

Parasite nodes will artificially imbalance users’ channels and force them to route payments through parasite nodes with much higher offchain fees. Hubs can also use parasite nodes to achieve more centralization if onchain fees will be not very high. Example:

Alice is an average user, and she decided to be a forwarding node (participate in routing) for more decentralization and earn some money from small fees.

Mallory (parasite) is already connected to hubs.

Mallory connects to Alice, funds the channel, and sends funds to herself via Alice, making sure that all Alice’s funds in the channels to hubs are shifted towards hubs, so Alice can send LN payments to hubs only through Mallory.

Mallory also sets high offchain fees for routing (higher than she paid for Alice + hub routing). And if Mallory works together with hubs to achieve more centralization, then she won’t even need to pay hubs fees for routing, so her attacks will be even cheaper.

Hubs(0 b) — — (1 b) Alice (0 b) — — (1 b) Mallory (0 b) — — (1 b)Hubs

Alice (0 b) — — (1 b) Mallory (0 b) — — (1 b)Hubs Hubs(1 b)← ←(0 b) Alice (1 b) ← ←(0 b) Mallory (1 b) ←← (0 b)Hubs

As a result, Alice can make payments only through Mallory and pay high offchain fees.

Of course, Alice can try to rebalance her channels via Mallory, but she will need to pay Mallory high offchain fees, so there is no point in rebalancing.

Alice can increase her routing fees, but then Mallory will increase them, too.

Alice can connect to multiple hubs, but Mallory will still be able to perform this attack with just more LN transactions.

Alice can find a parasite node and blacklist it, but Alice will need to pay onchain fees for closing a channel to retrieve her funds, and Mallory can attack from different nodes again.

Alice can receive new funds through hubs, but her initial funds (1 BTC) will stuck in a channel with Mallory. And Mallory can imbalance new funds again if she has enough capacity in a parasite channel.

More important is that most users will run ‘autopilot’ mode, so they won’t even know about parasite nodes, they will just pay higher fees to parasites, than if they were a simple end node.

And Alice won’t succeed in being a forwarding node either, because of high offchain fees that users need to pay while routing through her and Mallory, so users will automatically choose other routing paths (use big hubs).

Parasite nodes will also collect all the transactions data, which might be later analyzed to make certain assumptions.

Solution: very high onchain fees can mitigate this attack, because risks associated with creating a parasite channel will increase, but that will mean centralization of a few huge hubs.

One more solution is to allow only trusted nodes to connect, but the system will stop being ‘trustless’ and it will introduce anonymity issues, because it will be easier to identify Alice and her friends.

Another solution is to teach Autopilot discover parasite nodes, pay one time high offchain fees for routing all funds back to owner via correct nodes, and then blacklist a parasite node without closing a channel. But this will become an ongoing arms race, because parasite nodes will constantly mimic ‘normal’ behavior, since parasiting can become a lucrative business if onchain fees will be relatively low.

Bully nodes can shut down small forwarding nodes

In the example above, Mallory can open a parasite node with Alice and benefit from all transactions as one more middle-man, forcing higher fees, over a long period of time without being noticed.

Bully nodes will exploit similar technique, but for the purpose of shutting down a certain forwarding node for a period of time. Big hubs can use this type of attack to fight with their smaller competitors. Example:

Alice became a popular routing node in her district with 100+ channels.

Hubs hired Grace to shut Alice down.

Grace connects to Alice with enough funds to perform an attack.

Grace sends funds to herself via Alice, making sure that all Alice’s funds in the channels to hubs are shifted towards hubs, so routing though Alice will also imply routing through Grace.

Then Grace sets extremely high fees for routing (more than onchain fees) and waits, or blacklists Alice or just goes offline.

As a result, all end nodes, that are connected to Alice, won’t be able to route funds ‘to the world’ via Alice either because of extremely high fees, or because Grace is offline.

Alice will have to spot the issue (might take some time), then unilaterally close her channel, pay onchain fees, wait for ~1 day (CSV time-lock) to get her funds onchain, then open new channels with hubs or rebalance existing ones with Submarine Swaps or Splicing, which might require paying multiple onchain fees, because Atomic Multipath Payments (AMP) aren’t implemented yet.

Grace won’t lose anything, but onchain fees for opening a channel.

If Grace will convince Alice to accept a channel with custom CSV time-lock (e.g. 1 week), then Alice will be “down” for a very long time.

Also there is a tiny chance that Alice will accidentally broadcast an older state (some software bug with backups), then she can lose all funds, because Grace will punish her.

Solution: high onchain fees won’t mitigate a problem of bully nodes, because Alice will have to pay the same amount of fees to close all bully channels.

Not accepting high capacity channels won’t help either, because Grace can perform an attack from multiple nodes. That will cost more onchain fees to open many channels, but Alice will need to pay onchain fees to close all those channels as well.

In most scenarios, victims will have to pay at least the same amount of fees or even more, than an attacker, and their business will be ‘down’ for some time.

Parasite and bully nodes can be effectively used to fight with small forwarding nodes, forcing average people to use a few big hubs, even if onchain fees will be relatively small.