Don’t Count Your FUD Before the Lightning Strikes: 15 Claims Against Lightning, Answered

Click Here if you would rather LISTEN to this article as an episode of the Cryptoconomy Podcast.

I will start this off by stating that even though the majority of the claims I’m addressing are, in fact, nonsense, this is not a puff piece for the lightning network. It definitely has a long way to go before being a fully realized network and, more importantly, an easily utilized product. It will take a lot more development from many teams, and innovative, risk-taking businesses in order to find ways to translate the technology to the average user. Much like routers had to simplify the use and connection to the internet down to a wifi name and password.

An Elementary Understanding

If you haven’t listened to them yet, and would like a far more advanced understanding of the lightning network than this article can provide, I urge you to go back to parts 1–3 of “Understanding the Lightning Network” written by Aaron van Wirdum. I have also made audio versions of these, as well as added a summary, some commentary, and made a few clarifications, in 3 corresponding podcast episodes. But for our purposes today, we will start with just a basic overview.

Image from Bitcoin Magazine (

#1 — Lightning is Too Complicated For the Average User

Lightning is absolutely in its development and bootstrapping phase. The software is in Beta after all. It is certainly hard to utilize for anyone who doesn’t understand what’s occurring behind the scenes. The Lightning network would likely not be successful if a user has to understand what a channel is, or who they should open it with, and so on. The protocol is very complex and will only be successfully realized if most people don’t need to know how or why it works. With that being said, can you explain each step in a TCP/IP handshake? Can you tell me all the different ways broadband signals are encoded to expand the amount of data packed into a digital transmission? Do you know how your router determines a connection to Google, which servers should be used to get there, which ports to use, etc? Do you even know your public IP address right now, without having to look it up? When the internet was first being realized, you couldn’t utilize it without a lot of this knowledge. These are age-old challenges of protocols that never go away. Bitcoin was equally complicated 7–8 years ago and didn’t even have a single decent GUI. You can’t just skip this stage of development. There is nothing about this engineering challenge that suggests it can’t be hidden behind an easy-to-use software interface. To the contrary, we have plenty of routing and and network software that already accomplishes very similar goals. I see this as merely a matter of time, and continued exploration of the protocol. This claim, just as it was used against Bitcoin for years, always sounds like grasping for straws in my opinion.

#2 — Lightning Requires Two Transactions When no Route is Available

Many people mistakenly think you must close a channel if it doesn’t immediately present you with an available route to where you want to spend funds. In truth, it makes far more sense to leave the channel open, and add another channel to a different node. The more channels, the better the network will work. After a few additional channels, you may now have a route, through your new peers, back to the original channel that was giving you trouble.

#3 — If Bob doesn’t use a Lightning Wallet, Alice Can’t send him a payment

If Bob doesn’t use a Bitcoin wallet, Alice can’t send him Bitcoin. This happens to be true of practically any network, and really has little to do with Lightning in particular. Interestingly enough, thanks to HTLC payments, there are already services and payment methods being created by developers (i.e. Alex Bosworth, you can check out his interview on The Noded Podcast for more details) that allow someone to make a trustless payment on your behalf if you are using lightning, to someone who is not using it. Similarly, they are able to do this in reverse. So while this is true in a basic sense today, there are already avenues where this is solved in a trustless manner. Not to mention the same can be applied for altcoins and competing blockchains, to make cross chain payment invoices. It will be interesting when you can pay a Bitcoin invoice by sending Litecoin or Ethereum to an HTLC payment, fulfilled by a random node on the Lightning network, without any concern that the payment won’t arrive. So despite this criticism having little to do with Lightning itself, being merely a reality of any network adoption (i.e. you can’t be Facebook friends with someone on Twitter, and can’t send an email to someone’s physical mailbox) we may actually be able to negate this limitation with continued development and adoption.

#4 — Lightning Forces us to “Lock Up” Our Money

This is an often heard claim that completely misses the point and, like many Lightning complaints, leverages negative language to make it sound like something that it isn’t (we will hit the “IOU” claim later). Its analogous to complaining that to use roads you have to “lock” yourself in a car and therefore who would ever want to do that. Or maybe that to use the internet you have to “lock” your computer with a single IP address.

#5 — Others must Offer Liquidity to Receive Payments

In order to receive payments on the Lightning Network a channel needs capital owned by a different node on the network, to be placed within your channel (e.g. they need to upfront money that may be sent to you in the future). So with an online store I would need to connect to nodes that offered to maybe match my channel capacity, or better. As nodes can basically publish small amounts of information, establishing fees, channel routes, and likely many other elements as development progresses, this seems like a rather mundane problem in the long term.
In addition, there are actually a few clever tricks to doing this on your own if you just think about it for a minute.
Remember, I mentioned earlier about Alex Bosworth’s trick using HTLCs to make a trustless on-chain payment from a Lightning payment? Let’s apply this simple tool.
First, I open a basic channel with all the coins allocated to me, then I use this HTLC trick to pay the full Lightning balance into the network, that comes back as an on-chain payment to another address that I own. Boom, the channel is now fully balanced toward the other node, and I just received an on-chain payment to a different address. Now I can receive payments for the full amount that I placed inside the channel.
To add to this, any money that I spend within open channels, becomes money I can receive as payments later. But basically, using the HTLC trick will essentially clear the channel for receiving any future payments. I can simply do this periodically if my store is selling tons of items. There may be better solutions at a later date, or it could simply become one of the realities of using the Lightning software. Either way, in my view, this is just an interesting engineering challenge.

#6 — You Must be Online to Receive Lightning Payments

This is true. There may be a clever solution to this down the road, but currently the only “fix” is the one already discussed using HTLCs to pay someone else on Lightning, who then broadcasts a normal transaction on your behalf. This would however, come with a normal transaction fee, making it only a partial solution. The limitation here is just a reality of the smart contract’s security profile. However, there are many services and applications that can’t be utilized on the internet unless you are online (you know, like credit cards), so this isn’t really the end of the world. But it is certainly something to consider if you have an online store.

#7 — You need a Channel with Starbucks to buy from Starbucks

I think we have technically covered this one multiple ways, but why not? The very idea that makes Lightning an interesting technology is that channels are routed as a network. In exactly the same way that I don’t need a direct broadband straight to Google in California in order to visit their site, I don’t need a direct channel with Starbucks in order to buy from them. My internet routes can take 7–15 hops to reach their destination. I just checked, and I’m currently using 9 hops, to write this article on Lightning does this same thing with payment channels. In its early iterations, finding routes may be difficult, due to how early the software is in development, and due to the fact that the network itself is still in its bootstrapping phase. But this is essentially the same problems experienced with the internet when there were few broadband lines and few available servers. There is little logical reason to assume this will always be the case, and the claim that we need direct channels, is obviously baseless.

#8 — Lightning is an Altcoin

Believe it or not I think there is an alt coin called lightning, and also another called bitcoin lightning, so I can’t truthfully say that “lightning” isn’t an alt coin. But I can tell you without a shadow of a doubt that the lightning network, built on top of bitcoin, (referring here to the c-lightning, eclair, lnd and other clients) is not an altcoin in any form. Lightning network, as we have thoroughly demonstrated with Aaron’s van Wirdum’s articles and reiterated with multiple explanations, is Bitcoin locked into a smart contract and exchanged as valid, and half-signed, sub-transactions (a transaction constructed from an on-chain input).

#9 — Lightning is Centralized

This one can only be loosely addressed by explaining how the network is established. The developers don’t build the network here, they simply engineer the protocol. The users and node operators build the network and setup the channels independently.
It is probable that the network will have some degree of a hub-and-spoke like architecture around popular services, not much unlike the ISP and server based internet infrastructure, but with one enormous caveat. The model of the internet today is hub and spoke because it is built upon physical hardware, to route around your ISP you literally have to spend millions of dollars to run fiberoptic cable to a different geographical location. The hardware that builds the internet is not censorship resistant, and it is extraordinarily time consuming and expensive (sometimes impossibly so) to build alternative routes around some centralized points of control. (imagine trying to avoid the fiber lines laid across the Atlantic Ocean)
The Lightning Network, by contrast, has an infrastructure built entirely from easily deployed, low cost, and censorship resistant Bitcoin transactions. Meaning routing around any centralized point of failure that has failed to provide a service, or becomes unreliable, requires nothing more than a single transaction and a 10 minute confirmation time. If we could ever achieve such a monumental shift for establishing lines within the current internet infrastructure, it would be hailed as the breakthrough that freed the internet from centralized institutions. Apparently to some, however, that same reality in the Lightning Network is representative of “all the banks are taking over again.”

MUCH CENTRALIZED!! — (view from

#10 — Lightning is an IOU

This is another example of language used to leverage a preconceived negative association without presenting any useful information. I could just as easily call a car a four-wheeled bike. So why is calling it an IOU a negative term in the first place, and do the issues of an IOU apply to Lightning?

#11 — Lightning is Built so Banks can Control Bitcoin

I want to hit this idea hard, because I think it can be considered highly unlikely by an evaluation of any of these elements individually:

#12 — Lightning Will Just Become Fractional Reserve

In a recent episode of his podcast, Vin Armani, after explaining what channels were and that large institutions would never need or want to close them, proceeded to extrapolate that this somehow negated all of the reserve checks, escrow script, on-chain validation, hashing of balances, and HTLCs for routing payments within the LN protocol. In other words, he said the banks would suddenly gain the magical crypto power, of re-implementing fractional reserve.
This would be almost identical to saying that Bitcoin held in escrow for 1 day is still secure bitcoin, but if held there for 100 days… who knows?
The reason, I think, that this is immediately inferred from a weak understanding of the Lightning Network specifics, is that the words “off-chain” immediately induce the idea that all the data isn’t being validated, which is simply not true.
Of course it’s true that banks could make their own layer, and they could call it Lightning too, I guess. I mean Bcash is the “real” Bitcoin after all, amiright? And maybe this layer will allow them to make additional fake coins that didn’t exist. But when is this ever not true? Anyone, the banks included, could also fork bitcoin to be centralized, remove mining, and make themselves trusted nodes. Neither would be compatible with either Lightning or Bitcoin. The Lightning Network is a very specific scripting protocol, none of the bitcoin scripts it uses allows the escrow or signing of fake Bitcoin balances.
Another important piece is that even if such a thing were somehow the case, the only thing anyone needs to care about are their local channels. Lets say you had a channel with this evil bank. To update that lightning channel, it is YOU who is writing the commitment transaction that secures your withdrawal from the channel, signing it, and then giving it to the bank. If you somehow wrote the commitment to screw yourself out of coins, you only have yourself to blame.

#13 — Lightning will Allow Censorship

If a bank was trying to prevent spending from a certain bitcoin address (i.e. blacklisting), they would simply not accept payment from that address. Simultaneously they wouldn’t allow you to open a channel with them from that address. A rather simple way to get around this is to open a channel with a different person who is also connected to the bank (if you needed the bank’s route at all that is). The way this claim is stated makes it seem like we are all going to be forced to make channels with the bank, and then they will decide who can and cannot spend money. I don’t quite get why either the bank, or the customer would open a channel if the bank isn’t going to allow them to spend anything, but whatever.
Seeing as Lightning transactions are onion routed, if you don’t open a channel directly with said bank, they don’t know for certain where transactions are coming from or going to, outside their immediate channels.
In my opinion, the lightning network makes censorship of Bitcoin addresses actually more difficult, not less. Think of it from the point of view of Starbucks. Let’s say they can’t legally accept payments from address A. But they can accept payments from my address B. I open a channel with Starbucks. In addition, I also have a channel with my VPN, then address A also has a channel with that VPN. The owner of address A can use this route (and likely many others) to spend money at Starbucks and they will be none the wiser.
Another consideration is there’s a difference between routing on the internet versus on Lightning. An internet packet is handed closer to its destination as each server receives it, determining the path one step at a time. In Lightning however, the original sender determines the full route before beginning the payment. This means that any chosen or available route is entirely determined by the person who sends the payment, and again thanks to onion routing, isn’t even known in full by the nodes along the way. By this measure, it is entirely up to the user to choose whatever route gets the payment there using the fastest, or most private/trustworthy nodes (if such a concern even matters in the first place).

#14 — Lightning will Destroy Privacy or Force KYC/AML

Bitcoin payments are broadcast to the entire global network and the originating addresses, the balances, the transaction amount, and the destination are 100% public. Lightning payments are only transmitted over the specific route used to reach their destination, and are encrypted using the onion routing standard, making the origin and destination very difficult to determine (if at all). With Lightning, the person you have a channel with may be able to (but likely can’t) determine where the payment went. With a normal Bitcoin transaction, however, anyone can see the payment and it is publicly available forever into the future. I just can’t see any merit in the claim that this is bad for privacy.

#15 — Lightning Will Require Trusted Watchtowers

A watchtower is an idea to have random nodes across the network watch for competing transactions, possibly for a small fee, so that if a user goes offline they don’t have to worry about their channel partner broadcasting an old state in their absence. The Watchtower can enforce the valid state on your behalf. It isn’t true that you need to trust them with giving away the transaction balances or any specific privacy information. They are actually able to do this with knowing only the Tx ID thanks to the malleability fix implemented with the Segwit soft fork.
Oddly enough, this claim would be true (you have to trust Watchtowers) if Lightning were adapted to a network like Bcash that doesn’t yet have a malleability fix (as I understand it, they have a few proposals but nothing is implemented). Which is ironic, as this criticism is often touted by Bcash supporters. Many Bcash proponents, like Roger Ver, claim Lightning will work better on their network, despite the reality that this claim isn’t a problem on Bitcoin, but would be a problem on Bcash. In addition, no one appears to be rewriting the lightning protocol to work on the Bcash network. Due to the lack of Segwit, much of the work will have to be redone just to be compatible.
It is also important to note that you could use one of your own devices as a watchtower if you so choose. Lets say your computer and home router go offline, you can have your smartphone act as your tower to close the channel over cellular in case of any problems.


The core idea behind layered scaling solutions is that the Bitcoin security, decentralization, and immutability are paramount. So trying to clog the network with minor purchases only limits its ability to do its job properly, and threatens to reduce the number of people auditing the system, which is the very means used to create that security to begin with. The layered approach acknowledges this supreme security as more of an independent digital court, that can be used to enforce contracts built on top of that platform. Thereby freeing the judge (the Bitcoin network) from the endlessly tedious and resource hogging task of signing, stamping, and indefinitely storing every single coffee receipt across the globe. Instead, we can create smart contracts that establish beyond any reasonable doubt, what the Bitcoin court would enforce when we eventually present the contract to be executed. This allows us to transact tens of thousands or even millions of times without burdening the Bitcoin system, and the Bitcoin court can largely be used for what its best at, trustlessly settling disputes, and proving true ownership. That is what the Lightning Network does, and this is only the beginning.