Lightning Network: 27 concerns about UX and centralization

Published in

Crypto Punks

33 min readMay 22, 2018

Please leave a comment below if you know an original source of this mem, so I can link to it

Disclosure: I own some BTC, BCH, ETH and many other altcoins, but my portfolio is heavily diversified, so I don’t have financial incentives to shill for any particular coin. I support different projects with onchain and offchain scaling solutions, so each user can have a freedom of choice.

Intro

Lightning Network

High VS low onchain fees

Opening a new channel

Dual funded channels

Full node

Closing channels uncooperatively

Exhausted channels

Spending

Routing

Takeaways

Intro

Because of BTC vs BCH drama, most articles about Lightning Network have an established agenda: LN-savvy fans rarely expose flaws in the system, while many LN critics lack knowledge about LN, spreading misconceptions. I’ve decided to spend a few months researching LN in attempt to write a candid article about possible LN flaws, as this is what I usually do as a consultant.

I want to say big thanks to all LN experts and enthusiasts who answered hundreds of my tweets, while I was writing this article, especially to: Alex Bosworth, Cryptoconomy, Youssef GHOUBACH, and Stadicus.

Please feel free to follow them if you are interested in Lightning Network.

As for my opinion about BTC vs BCH drama, I agree with both tweets below:

Lightning Network is a second layer scaling solution, which, if succeed, will be used on many other altcoins, so please leave all the drama aside while reading this article. You can treat this article as QA/UX review of Lightning Network at its current state, and let’s focus on tech.

If you’ll find any mistakes in the article, feel free to leave a comment, so I can edit them and link to your reply.

Please also remember that all other projects and scaling solutions have their downsides as well. I don’t know any perfect system in the crypto space, yet.

Lightning Network

This article assumes that you already have basic knowledge about LN, but if you don’t, then here is a rough explanation:

Instead of broadcasting each transaction on blockchain, you can create a private LN channel with your friend, exchange funds inside the channel for many times without paying any fees, and finally close your channel by broadcasting the final state (balances) on the blockchain. So with LN you need to pay onchain transaction fees only 2 times: to open and to close the channel. Users can also create many channels and route their payments via other people’s channels, similar to how Tor works.

Lightning is a protocol with at least 3 different open-source implementations that are interoperable and BOLT (Basics Of Lightning Technology) compliant: lnd (Lightning Labs), eclair (ACINQ), c-lightning (Blockstream).

To dive into Lightning Network, I suggest the following articles and videos.

Pro-LN:

Against LN:

How The Banks Bought Bitcoin (by Decentralized Thought)
Lightning Network Onion Routing (by Decentralized Thought)
Lightning Network vs. Bitcoin Cash (by Ryan X. Charles)
Mathematical proof that LN cannot be decentralized (by Jonald Fyookball)
Lightning Network Routed Payment Scalability (by Coin Decrypt)
LN is fundamentally flawed (interesting discussion on reddit)

Special:

Samson Mow (BTC) VS Roger Ver (BCH) debates at Deconomy

Ideally LN system should be decentralized, censorship-resistant, trustless and privacy-oriented, but can this really be achieved? And when?

In this article we will look at 27 weak points in User Experience (UX) and see how that can incentivize LN to become a centralized ‘hub and spoke’ network. Some issues are severe, while the rest are minor issues or concerns, but they can certainly add up.

Many problems and solutions in this article are already well-known in LN community, but some of them are unique and I haven’t heard about them before, like e.g. parasite nodes, forcing users pay higher offchain fees, or sharing collateral over multiple channels to increase punishment for cheating, without locking out too much funds from a circulation.

High VS low onchain fees

High onchain fees will increase LN centralization

We’ve already seen $50 fees for 1-input-transactions during BTC network congestion in the end of 2017 because of cryptocurrency mania spike. The fees can increase much further if BTC gets adopted globally with the same 1mb block size limit.

E.g. with 7 onchain transactions per second (7tps), it will take more than 30 years to open 7.6 billion LN channels, which is just ~1 channel per each individual on Earth (or ~2 channels in fully decentralized network without big hubs), not taking into account any other onchain transactions. Even if SegWit will be widely adopted, the amount of years is still significant, unless block size will be heavily increased, or the size of channel opening transaction will be somehow dramatically decreased, but it can introduce new issues.

High onchain fees will lead to centralization, because why should user open 10 channels for $500, when he can open just one channel with a big hub for $50 or even for ‘free’ (read below) and route all payments with 1–2 hops?

Solution: Channel Factories might slightly mitigate this problem, but the final implementation is not clear, and system will probably stop being ‘trustless’.

Update: Kristiyan Lukanov commented that ‘7tps issue’ is biased, because it’ll dramatically increase in the future. You can read my more detailed reply here.

High ‘channel opening’ fees are for privileged countries only

1 cent is a small sum in most countries, but not $20. In developed countries $20 sounds more like an hourly rate, while in developing countries $20 can be a weekly salary.

Why should anybody give away his weekly salary to open LN channel, if he can just use cash, local centralized e-payment system (similar to PayPal), social media tokens (Telegram, Facebook) or other altcoins with low fees? Also some funds might be ‘locked’ from spending in LN as a collateral to prevent channel exhaustion (read below) or to be able to close a channel.

Lightning Labs’ Autopilot will open channels with at least 5 routing nodes at the start, so it’s a pretty big sum even with low onchain fees like $5 to $10, which makes onboarding very difficult for many people.

I don’t think that an average person in developing country will voluntary pay $20 to open a channel, because offchain scaling solution ‘may be’ gives more decentralization than onchain scaling. I’m not sure that he even knows what does that mean. (No offense, but I’ve been living in developing countries).

Even if a person does pay $20, he most likely will open only 1 channel to a big hub for all his transactions, which is centralization.

Low onchain fees will decrease LN adoption

On the other hand, if BTC onchain fees will somehow stay low or suddenly decrease, then it will also decrease LN adoption, because users will be less incentivized to open channels with each other, which will put a whole LN system in danger.

So LN might become a complex system with a few beneficiaries, which will require high onchain fees to exist. That will financially incentivize big hubs, watchtowers and other centralized LN services to lobby high fees by bribing community influentials and using sock puppets, thus achieving even more centralization and higher revenues.

Opening a new channel

Alice and Bob want to open a new LN channel.

Problems:

Bob’s node should be online to auto-confirm channel creation

This is not a huge deal for nerds from developed countries with stable internet connection, but if LN hits a global scale, then this UX issue could increase centralization.

Most regular people turn off their computers/phones or switch to ‘airplane’ mode for a night time, so if Alice and Bob live in different timezones (e.g. New York and Shanghai have 12h difference), then Alice will most likely choose to route a payment through a big hub like Amazon/AliExpress, because average users always go for convenience.

Don’t forget that in developing countries most people have unstable internet connection, so again it will be more convenient to use hubs to send payments.

Solution: may be Channel Factories can fix this, but they won’t be widely used any time soon.

Bob should manually confirm a creation of ‘dual funded’ channel

This adds even more incentives to use big hubs for payments, because Alice won’t be able to send money to Bob, until he manually confirms a creation of a new dual funded channel, and an opening TX will be added to blockchain.

Keep in mind that most users should have multiple dual funded channels available for routing to achieve a high level of decentralization, which is essential for censorship-resistance and anonymity.

Solution: use only one side funded channels, but this will push regular people to open only ‘spending’ channels with one big hub (again centralization).

Dual funded channels

Alice and Bob can’t open a channel by depositing 1 BTC each, because LN channels can currently be funded by only one party, which means that Alice can open a channel to Bob, but she can’t receive any funds through it, until she sends some money to Bob via this exact channel.

Dual funded channels have been proposed in LN white paper and there was a specification proposal on June, 2017 by ACINQ, but nobody knows how the final implementation will look like, and when it will be rolled out.

Also there are a few unsolved issues with dual funded channels:

Initial funder pays opening fees even in dual funded channels

Alice will pay onchain ‘opening’ fees even if both parties (Alice & Bob) funded the channel. So regular users will have less incentives to open new channels because of high onchain fees, so they would rather wait until somebody will want to open a dual funded channel with them. This will lead to further centralization (big hubs like Amazon).

Solution: a new trustless logic, where both parties pay equal opening fees for creation of dual funded channels. Please let me know if this logic is already in development, because I haven’t seen it.

Huge hubs will pay onchain ‘opening’ fees for users

The concept of so-called ‘free’ wi-fi/pizza/shot/trial will be used in LN as well. After implementing dual funded channels, big merchants like eBay or Flipkart may offer to pay ‘opening’ TX fees for a user if he buys something worth of $N. This will lead to more centralization and less anonymity because of KYC.

Why bother creating a channel with a ‘small’ node, pay high onchain fees, and later pay more offchain fees for routing, when you can just open one channel with a big hub for ‘free’ and route most payments with 1 hop? Average Joe will always choose the most convenient option.

Solution: I didn’t find any good solution, because even a logic where both parties pay ‘opening’ fees won’t work, since big merchants (hubs) will offer a discount worth of user’s half in ‘opening’ TX fees. Please feel free to share your thoughts.

Bob should actively double-spend inputs if dual funded channel was not created

As it was pointed out by Christian Decker, a current specification of dual funded channels forces Bob to double-spend his inputs if a channel has failed to be created, because Alice can broadcast an ‘opening’ TX much later (when Bob wants to spend his inputs for something unrelated), thus locking the funds into the unilateral closure procedure, potentially hurting Bob.

Solution: adding timeouts should help, but the implementation is not clear.

Funds should be deposited upfront

Most regular people don’t have much savings. Many westerns got used to borrowing money via credit cards, while many people in developing countries live ‘from salary to salary’. Since onchain fees will be high, it makes sense to deposit lots of money to a new LN channel, and spend funds over the next few weeks with lower offchain fees.

Why bother depositing lots of funds upfront to save on future fees, if user can keep using Visa or other altcoins with low transaction fees? Average user will choose convenience.

Recharging a channel (e.g. with Submarine Swaps or Splicing) won’t help, because user still needs to pay onchain fees and thus he should ‘deposit’ a big sum upfront again, to save on fees in the future.

Solution: this won’t be a problem if everybody use LN, because all payments would be done offchain, but this won’t happen any time soon.

Full node

User should run full node to use LN

LN user should run a full node to monitor the blockchain to prevent his counterparty from cheating. The current BTC blockchain size is ~200GB, so there will be a lot of hassle to use LN on a mobile device even for people from privileged countries with new smartphones.

Solution: SPV (Simplified Payment Verification) LN wallets like Neutrino, eclair, CoinClip will fix that, but they are still in early development stage.

According to official readme, Neutrino has “multiple known major issues with the client, so it is not recommended to use it with real money at this point.”

Eclair has a great FAQ, so here are more detailed issues:

users can’t receive funds, but only send them (critical)
there is no iOS version, and no short term plans for it
eclair mobile LN wallet can’t be used for routing (centralization)
users need to reserve some funds in case of a channel closure
there are no backups yet, so user will lose all funds in open LN channels, if he deletes the app (even if he has recovery seed), unless his counterparties will eventually close channels without cheating
upgrading to a newer version implies closing all LN channels
there are many unresolved serious bugs

SPV LN wallets might be widely used one day, but it won’t happen any time soon. And don’t forget that a fully-functional SPV LN wallet should be able to receive funds, so it should be used with 3rd party LN Watchtowers, which will monitor the blockchain to prevent cheating. Unfortunately, LN Watchtowers are still in alpha and they have many flaws (we will talk about Watchtowers in the next articles).

Mobile full nodes will increase data and battery usage

One of the reasons to keep block size very small, is to allow an average user to run a full node on a mobile device, even though he doesn’t vote with any hash power (no mining).

Let’s assume that hardware will develop much faster, than Bitcoin blockchain size grows, then in 5–10 years an average user might be able to run a full node on a mobile device, as well as be a routing LN node.

The biggest downside, is that it will increase battery usage, forcing people to recharge a device much more often. It will also increase a global electricity consumption by a network, if every user will validate blocks and search for cheating LN transactions. As a result, many people might be not interested in running a full node, even though they will have this opportunity.

More than that, running a full LN node on a mobile device will not solve LN hubs centralization, nor ASIC-manufacture centralization.

So it’s most likely that users will run SPV LN wallets on mobile devices and use 3rd party Watchtowers to check blockchain for cheating transactions.

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
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.

Takeaways

LN has a great potential as a second layer solution, which relies solely on software evolution in opposite to hardware evolution (big blocks)
Current LN state has poor UX for average users, but it’s developing rapidly
LN needs lots of time to mature, until it can be adopted globally
2018: it’s very unlikely that LN will save BTC from network congestions and high fees, if crypto mania will come back later this year
With a current protocol, LN has many incentives to become a heavily centralized ‘hub and spoke’ system, which has strong downsides (more about that in the next articles)

Message to LN critics and fans

For those who think that Lightning Network is already on the mainnet and this article is a pure FUD:

“We’re talking about Bitcoin scale. LN doesn’t work right now at Bitcoin scale. Technically broken clock also works, just doesn’t show right time.”
by xZeroTheGreat

One can argue that an average user will just use ‘autopilot’, but that won’t fix most of the issues written above, and autopilot is not developed yet.

As for LN critics, they remind of people, who claimed that Bitcoin won’t work, because it’s too complex.

What side I am on? I’m on the side of technical progress, free market and fair competition.

Small experiment

This article should be interesting for both LN fans and LN critics, but since there is so much drama in the space, I’m afraid that a target audience won’t find it.

I’ll publish this article in both /r/Bitcoin (mostly pro-LN) and /r/btc (mostly against LN), to see which community will appreciate this 30-minutes-read paper more, and I will update this section with results in a few days.

Update: a post on /r/Bitcoin was downvoted by people who didn’t even read it (they admitted that). A post on /r/btc got 41 points with 78% upvotes and 1K+ views, but they are not a target audience, since they are mostly against LN and thus not very interested in reading 30 minutes article about possible LN flaws.

More to come

Originally I thought to publish all issues in one article, but the amount of material is so huge, that I’ve decided to start only with UX and centralization concerns.

If this article will get some interest from the community, then I’m planning to write a few more articles about LN, covering issues with hubs, watchtowers, anonymity, KYC, and different possible attacks on target users or on a whole system.

So please feel free to share this article if you want to support more candid articles about Lightning Network.

Disclaimer: I am not a licensed financial advisor, and this article is not a financial advice. The information presented here is for educational purpose only, it represents my personal opinion, and is not purported to be fact. Cryptocurrencies are very volatile and can move quickly in any direction. I am not responsible for any trading loss incurred after reading this article. Seek a duly licensed professional for investment advice.

If you still think that a small Tether market cap can’t influence the 400 billion market, just read this article:

Biggest misconception about Tether market cap and why it’s totally different from all other coins

Tether threat is still undervalued and only recently got some attention due to CFTC subpoena and following huge price…

medium.com

New article about Lightning and Raiden networks:

Lightning VS Raiden: can watchtowers and monitoring services scale?

Why LN watchtowers and RDN monitoring services are essential for off-chain scaling, how do they operate, and what are…