Don’t Count Your FUD Before the Lightning Strikes: 15 Claims Against Lightning, Answered
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.
I have had my own moments of excitement, and moments of great frustration while using the Lightning Network (LN) software. I’m not going to tell you Lightning is perfect and that it will put VISA out of business in the next two weeks. However, there is a significant amount of utter nonsense being repeated by people who would know how wrong their statements actually are, with only an elementary understanding of the protocol. That’s what this article is for. To address and detail what the real challenges of the LN are, and to cut down the mountain of crap that many ignorant people want to stand on, to look down at everyone else.
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.
The Lightning Network is a means of taking advantage of the cryptographic scripts built into the Bitcoin network, in order to establish a new Bitcoin payments layer. A network, on top of a network, if you will. One of the first pieces is called a payment channel. To create a channel, two parties must first put their coins into a mutually owned address (called a multisig address), which is confirmed on-chain, and is used to prove reserves and allows for valid signing of the smart contract that they will build for Lightning. Think of this contract like a bar tab, except that both parties (me and the bar) have to prove collateral, and the contract can be immediately taken to a judge and enforced in the case of any dispute (in this case, the judge is the Bitcoin blockchain). But like a bar tab, there is no need to broadcast a transaction every time I buy a beer, instead we update the contract between me and the bartender. A bar tab is anything but secure, however, so the LN introduces an array of security features that removes the need for me and the bartender to trust or even know each other.
The first of these security measures is a time delay in the case of a one-sided close of the tab. If the bar tries to close my tab without me, I have time to take a more recent version of the tab (If I have one) to the judge (the Bitcoin network). Every time I make a purchase of beer, the bartender and I rewrite this time delay to represent the updated balance.
The second security measure is in the form of a secret lock and key, that both myself, and the bartender have. Every update of the tab is locked with a new secret key from each of us. But the update can’t take place, unless we exchange the secret keys used on the previous tab update. So when I purchase my first beer, I put the lock of my first secret key on it, as does the bartender with his. When I buy my second beer, we both lock it with new secret keys, and exchange our first keys with each other. This secures it in a way that if the bartender, or myself, tries to take an old bar tab balance to the judge (broadcasts the old transaction), the other party simply presents the secret key that was used on it, and is then able to return all of the funds to their address. So if either party attempts to cheat the other out of a mutually signed update, they risk being punished with the loss of the entire balance of the tab.
This is all accomplished because the Lightning contract has 3 different routes available within it. Together the combined scripts provide a proof-of-reserves (by the signing of valid, on-chain bitcoin balances), a form of insurance (by pre-establishing a refund route and window of time for dispute), and punishment against dishonesty (by exchanging secret keys to out-dated states of the tab).
The image below from Bitcoin Magazine illustrates the contract
This is all well and good, but only allows for transacting between two parties. The secret power of Lightning is the ability to bridge tabs together. In the case that we have seen before, I can pay Carol because we both have a Lightning tab with the Bartender. This is accomplished with a similarly constructed contractual arrangement. Let’s say I am routing a coin to Carol through my tab to the bar, and then from the bar, to Carol. The coin to be routed is essentially put into escrow on my bar tab, and then a corresponding coin is escrowed between the Bartender and Carol. The lock placed on this coin in both bar tabs is owned by Carol, can only be unlocked with her secret key. When both tabs have a coin safely locked in escrow, Carol gives the Bartender her secret key, unlocking the coin in her tab, and then the Bartender uses that same key to unlock the coin on my tab. If I try to abandon the agreement beforehand without the Bartender’s approval, I hit a similar time lock as before, giving bartender time to show Carol’s key to the judge. This would prove he already sent a coin forward on my behalf, and therefore I owe him a coin. In addition, Carol cannot take the coin from the Bartender, without publicly presenting the secret key used to lock it up. This ensures the Bartender can always use it after she claims the coin, to enforce my agreement. Since both coins are locked in escrow before the payment can be made, the Bartender never has to worry about being left holding the bag, and Carol and myself can ensure the payment will either go through completely, or not at all.
This is the basic methodology of the Lightning Network smart contract, and it can be extended across a global network of nodes and channels to facilitate possibly millions of off-chain contractual payments with a comparatively tiny burden on the Bitcoin blockchain.
A few additions to this overview are that the payments are onion routed, a form of encryption used in the Tor network. This means that each person in the route has data that only decrypts to reveal the next hop, leaving the remainder of the route encrypted, and therefore private. So the Bartender cannot know for certain that the payment originated with me, as I may have a channel with Michael, and he also doesn’t know that it stops with Carol, as she may have another channel with Starbucks. From the Bartender’s perspective, I could have being paying Carol, but it would look no different if Michael had been paying Starbucks. The Bartender is unconcerned with this knowledge anyway, he just wants to ensure his balances are safe, and gets paid a tiny fee to route the payment for others, whether its from me to Carol, or someone else’s payment through both of our tabs, to reach an entirely different destination.
For now, that’s as far as we need to go in order to answer most of the claims around Lightning network. So let’s take them one by one and see what truth, if any, they hold.
#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.
Second, this problem becomes less and less prevalent as more channels and nodes appear on the network. This is likely to be a common problem early on, and far less of a concern after a year or more of adding infrastructure.
Lastly, thanks to batching and a number of other Bitcoin improvements, the closing of one channel can actually be in the same transaction as the opening of another. So even if the sentiment that you always had to close a channel with few routes was true, it can still be accomplished with a single transaction, not two.
#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.
It’s not “locking” your money unless you do it to a node that doesn’t have any other routes. Same as if you connected to an ISP with no other connections, or exited onto a road that goes to a dead end. During these situations on Lightning, you can simply mutually close the channel, or in the case of the node disappearing you may have to wait for the time-lock. But with a fully fledged LN and a plethora of reliable nodes, “locking” your coins is akin to establishing and “locking” a route onto the internet. It is much less a “lock” than it is a doorway, as you will be able to spend your “locked” coins, at practically any location that also has a connection to the Lightning Network.
During a time when nodes are going offline, this can, indeed, be a real hassle. I wrote an article on yalls.org about this very issue. But these are extremely early days and we haven’t even seen the first release of a major app on the Lightning Network. So to complain about reliability problems at this stage as if they negate the entire technology itself, is similar to claiming the difficulty of connecting with a 56k modem and establishing your own email server is the reason the internet will never be useful.
#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 Medium.com. 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).
When you put funds into escrow to buy something on openbazaar or sell on localbitcoins, would you think of them as suddenly becoming an altcoin? Can you spend more Bitcoin inside the escrow than actually exist? Of course not, because it’s real bitcoin put into a real script that will execute as a real and valid transaction on the bitcoin network. A bitcoin transaction includes the hash of all the data within the input transaction, there is no way to make a valid one that alters the balance of those input addresses.
Lightning is built entirely of Bitcoin scripts, so if anyone wanted to prove that Lightning is an altcoin that can create fake bitcoins, they could simply demonstrate which of the handful of Bitcoin scripts, can be executed with a fake balance of Bitcoins. Spoiler alert: it’s none of them.
#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.”
Luckily, even with this basic knowledge, we actually have a network today that we can explore. Even at this early stage, Lightning shows itself to be an incredibly decentralized network with many available routes and nodes. This claim now has to be made in the face of Lightning explorers (like the one above) that tease at the potential this technology has to secure a future of decentralized and trustless payments.
#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?
Accepting this declaration at face value generally creates feelings of “oh gross, I’ll never use such a thing.” The reason is because a traditional IOU is often am empty promise with no guarantee. It screams of the current banking system, they tell me they will pay me back, but I have no idea if they can and no way to enforce their promise if they fail to keep it. I am wholly at the bank’s mercy and competence. In short, we would never want to build the new financial system on the same weak promises that have undermined the legacy system and drowned it in debts that are impossible to pay back.
Also, in the IOU case, whatever funds (if any) that back the IOU are entirely under someone else’s custodial control. As we have learned in the 3 Cryptoconomy episodes on Understanding the Lightning Network, this is clearly not the case on Lightning. Instead each party holds a valid, signed commitment transaction that allows them to retrieve their coins whenever necessary.
So if we take a close look at all the pieces involved in the commitment transaction, but still insist on using the IOU language, here’s my best description of Lightning. It is a mutually agreed upon Bitcoin smart contract that can be updated only with the express consent of both parties; it has confirmed, on-chain proof-of-reserves; it has a wait time for withdrawal if only one party is present; it has a built-in insurance policy in the case of dispute; and it has a punishment clause for any party that initiates an attempt to rescind an updated and signed version of this contract.
This is not exactly an agreement that I would simplify to a label as unenlightened as “an IOU.” Which brings us to our next point.
#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:
• the topology of the current lightning network.
• the current methods that banks use to make money and direct finances.
• ̶t̶h̶e̶ ̶c̶u̶r̶r̶e̶n̶t̶ ̶m̶e̶t̶h̶o̶d̶s̶ ̶t̶h̶a̶t̶ ̶V̶I̶S̶A̶ ̶a̶n̶d̶ ̶o̶t̶h̶e̶r̶ ̶p̶a̶y̶m̶e̶n̶t̶ ̶n̶e̶t̶w̶o̶r̶k̶s̶ ̶u̶s̶e̶ ̶t̶o̶ ̶s̶t̶a̶y̶ ̶p̶r̶o̶f̶i̶t̶a̶b̶l̶e̶.̶ *I’ve removed this because I never actually returned to this point later and it’s mostly unrelated to whether or not banks have an incentive to build Lightning. It was intended to show that the Lightning protocol could potentially be disruptive of both banks and payment processors, thereby also competing for market share with their business partners.(i.e. Apple has a business relationship with Corning, would you expect Corning to invest in an open source hardware that threatens Apple’s market share?*
• an elementary understanding of the scripting and security measures built into the Lightning protocol.
However, assessing this claim against all of these elements together, in my opinion, makes it patently absurd.
The very first thing to ask, if this is an attempt for the banks to take over, is why aren’t they trying to get a head start on these “supernodes” I keep hearing about? If this really is their mission, then where are they on the lightning network? I’ve not heard of a single, legacy bank anywhere in the world even opening cryptocurrency accounts yet, much less spinning up Lightning “supernodes.” So seriously, where are they, why are they letting thousands of others establish themselves before making a move?
Aside from that. What would they possibly gain by creating the Lightning smart contract? The whole reason banks enjoy enormous power, is because they have custodial control of everyone’s funds, and customers have no way to enforce the agreement with the bank. Banks can loan your money out without your knowledge. Banks have the politically granted authority to actually issue new money against your balance and then collect interest on it.** They aren’t even legally obligated to pay you back anymore in the case of the bank going under. According to new laws passed both in the US and across the EU during the 2008 financial crisis, all customers are now “creditors” to the banks, and therefore our deposits can be used to pay off the banks liabilities.***
The Lightning network strips all of this power away from them. Even worse, it needlessly opens them up to an ocean of competition that is already 1500 nodes ahead of the game. What do they gain from open sourcing the software for some new cryptocurrency payment system that they had intended to have monopoly control over?
** Obviously this is a gross simplification and some have taken issue. First, banks don’t “directly” loan deposits. Second, new money isn’t issued against deposits, but first issued as a loan, and then it becomes a deposit. Either way, the imbalance is essentially the same, someone else owes the bank the money that makes up your deposit. If they fail to pay it, (aka 2007–2008) then it all crashes down.
*** This comment has been corrected by some who say depositors were essentially always creditors to the banks. My thinking here was in reference to the laws that solidified the “Bail-In” scenario, like that in Cyprus that was widely publicized in the crypto space, and now has a legal framework across EU and the US. My wording here is inaccurate, but what I was trying to convey still applies.
The lightning protocol fully neuters them from any kind of fractional reserve (which we will address in full shortly). It gives the customer a secure way to extract funds without the banks approval. It allows the customer to *punish the bank* if they attempt any unapproved control of their deposits. It completely eliminates the idea of overdraft fees. It wipes out the idea of international or wire transfer fees. It forces the banks to put up real on-chain collateral in order to maintain channels with customers and businesses. And it destroys their ability to loan out any money in customer accounts. I genuinely cannot imagine a business plan more destructive to the banks a̶n̶d̶ ̶V̶I̶S̶A
than the Lightning Network. It eliminates practically 99% of the revenue generation model that banks currently use. Any employee that brought this to their superior, would either get fired or laughed out of the room.
Second, what reason would they think they needed to build something like this in order to dominate the cryptocurrency industry? Especially if the goal was forcing off-chain payments? Why do they need anything else besides the addition of crypto accounts so they can utilize the same payment infrastructure and prevent them from having to make enormous structural changes to their businesses? It isn’t as if they have reason to believe this wouldn’t work. Look at Coinbase, they are the largest Bitcoin service in the world with probably 12 or 13 million customer accounts now. They didn’t have to create an elaborate smart contract layer or give up any custodial control for their market dominance. So despite Coinbase’s success, I’m supposed to believe that a handful of powerful banks have gotten together and decided that the only way to dominate the Bitcoin industry is to do all of the following:
• they must rebuild the entire global payment infrastructure on an entirely novel software protocol.
• they must open source their payment software allowing competition from anyone with Bitcoin and a raspberry Pi.
• they must remove their advantage of having any custodial control of customer funds.
• this new network must undermine the licenses and regulatory privileges they already have as established financial services. And let’s just add encrypted routing for fun.
• they must abandon every major revenue generating method of the current modern banking model.
• And they must delay their entry into the industry for 4 or 5 years while they develop a complicated and theoretical cryptographic smart contract network.
And they have willingly made the commitment to all of these changes just to squeeze out a few cent fee per transaction? This is their plan to monopolize the Bitcoin ecosystem? Call me skeptical.
Food for thought: Vin Armani recently said in an episode of his show that the Lightning Network allows banks to create fake coins, but he also said Lightning unfairly benefits the banks because channels need large amounts of capital to back them. So which is it? Do they need capital to back the channels, or can they just create fake Lightning coins? Seems a bit of a contradiction doesn’t it?
#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.
Unfortunately, creating a new system and challenging people’s preconceived notions of Bitcoin will undoubtedly be met with fierce opposition, as it should be. But there is way more FUD out there than can be fully addressed, which is always a basic truism. It takes a lot less energy to make up an ignorant criticism or lie, than it takes to truly understand and refute them. I hope this article at least gives a more proper image of the reality of this new technology, and its true potential.
The only real defense against the endless waves of bullshit is to inform and educate yourself. A good way to do that is to listen to the Cryptoconomy podcast, among others. If you haven’t done so, don’t forget to listen to the three part audio series reading Aaron van Wirdum’s “Understanding the Lightning Network,” and you are sure to be equipped with the tools to put them back in their seat, the next time someone tells you “Lightning coins were made so the banks could take over Bitcoin.”
Until then… keep reading, keep learning, and keep listening.