Lightning Network Review and Potential Pitfalls
For those that have been following Bitcoin or the cryptosphere in general, one of the most anticipated software updates for the coin that has been in development for quite some time now — is the Lightning Network.
Disclaimer: This article is not financial advice. The author is not a financial advisor and this article was not paid for.
What is the Lightning Network?
According to its website:
Even though this idea is just now starting to gain a substantial amount of traction in the minds of most supporters, the project’s development has been in the works for quite a few years at this point.
Here’s a link to a whitepaper, which represents an iteration of the idea from 2015.
However, before we delve into the technical aspects of the Lightning Network and how it came to be within the community, let’s get the basics out of the way first:
Who Developed/Created the Lightning Network?
The innovators that are credited with manifesting the idea of the Lightning Network itself are Joseph Poon and Thaddeus Dryja.
However, there are three teams that are currently working on the Lightning Network right now:
● Lightning Labs
We’ll get to these individuals soon.
When Does it Launch?
There’s no definitive date for the product at this point. Although, there are a number of articles out right now that are alleging that the Lightning Network’s release is imminent.
An example article that has been released recently
There’s no shortage of hype around the payment network as well. Just one Google Search of ‘What is Lightning Network’ will inundate you with multiple pages of bubbly statements claiming that it will be the savior to ‘cure’ Bitcoin and usher it into a new era.
One of the first logistical concerns that must be noted is the fact that several exchanges have noted that they will not adopt the Lightning Network. This article outlines how Coinbase has publicly stated that they won’t be implementing the Lightning Network.
I’m also skeptical about the idea that the Lightning Network will reduce the fees on Bitcoin as a whole because creating an offchain channel or transferring fees to the offchain channel counts as an onchain transaction. Same with moving funds back onto the chain.
If you’re wondering how Lightning Network is supposed to operate, I can give you the most basic of overviews right here:
So we all know how Bitcoin has been really slow with super high fees, right? Well, to make this really basic and non-controversial as possible, the reason for this is because the amount of transactions that the network is receiving is exceeding it’s ‘memory space’.
The block size for Bitcoin is still 1 MB (Segwit enhances the capability to 4MB but not really-ish, we’ll get to that later).
Each transaction is a piece of ‘data’ — so there are only so many transactions that can be included in each block. Think of a ‘block’ as a USB drive and the transactions are all the files you can put on a USB drive.
Now imagine if you have 1 GB of files that you have to save on USB drives, but you can only put 1MB on each drive. On top of that, imagine you can only fill up a USB drive once every 10 minutes. You can see how you would get backlogged with files right? I hope this analogy is making sense.
Those backlogged files = transactions. The purpose of attaching the fees is to give your transaction a higher priority. The ‘miners’ who are deciding which transactions to include in the block can see that you have a higher fee and move your transaction to the ‘front of the line’, so your ‘file’ can get uploaded quicker.
The purpose of the Lightning Network is to bypass all of that. Instead of waiting for miners to process your transaction, you can create your own separate ‘channel’ that exists outside of the blockchain. It’s like a “private chat” except for money instead of conversation.
Let’s use the Alice and Bob example:
Alice wants to send money to her friend Bob. So Alice decides to create a private channel (Lightning Network enabled) with Bob.
This is what it looks like logistically
In order to do this — Alice would send money to a designated ‘offchain wallet’ that is on the Lightning Network. Bob would then be invited to join the channel with Alice. Once they’re both in this channel, Alice and Bob can send money back and forth to each other instantaneously.
These channels work PARTY to PARTY, so in the picture you see above, ONLY Alice and Bob may be participants in this connection.
In this setup, Bob is connected with both Alice and Carol, but this does not mean that Alice is connected with Carol and Carol is not connected with Alice.
So let’s say Alice wants to give money to Carol? Let’s be more specific and say that Alice wants to give Carol 2 BTC. In order to do so on the Lightning Network, Bob would have to be the middle man. So, Bob would have to give Carol 2 BTC, and once Carol receives the 2 BTC, Alice would then give Bob the 2 BTC.
This occurs through a ‘time lock’, which is a type of smart contract — so Alice can’t have Bob pay Carol and then ‘cheat’ him when it comes time for her to pay Bob. I’m not 100% how this works on a code level — I haven’t used the Lightning Network myself.
Perhaps the most famous illustration in the community right now of the topology of Lightning Network can be seen in the picture below:
Once again, I’m not condemning the Lightning Network, “spreading FUD” or whatever the folks call it these days. But I am trying to realistically define what LN is and help set a practical expectation for what it means to the BTC network and what it will and won’t fix.
I’m not a ‘maximalist’ as they call it and I don’t believe in the white and black theory of “centralization=evil” / “decentralization=pure” arguments that the community puts forth. I think these terms are ambiguous at best and unquantifiable in any context. It’s almost like attempting to define beautiful and ugly.
In my opinion, the objective truth is that the Lightning Network mandates that there be some level of centralization for its implementation to make sense. Honestly, it would take a high level of centralization. Might even birth new businesses that are erected specifically for the purpose of connecting people together with BTC.
I could see this being problematic, though because the offchain transactions don’t afford the same protections as what you get with Blockchain. The properties are similar of course, but there are no ‘confirmations’ occurring or mined transactions on these offchains.
I could see this being problematic though because the offchain transactions don’t afford the same protections as what you get with Blockchain. The properties are similar of course, but there are no ‘confirmations’ occurring or mined transactions on these offchains.
Again, this may just be my ignorance. I’m diving through though.
Here’s a good paper (albeit technical) on the phenomenon of double-spending itself. Written in 2012, but still relevant in most ways today — https://eprint.iacr.org/2012/248.pdf
Does it Work Logistically?
Okay, so this is straight from the lightning.network site that they have up by Joseph Poon and the other guy whose name is too difficult to pronounce — https://lightning.network/lightning-network-presentation-time-2015-07-06.pdf
Perhaps I’m missing something here, but this setup makes me think that robbing people here would be easier than taking candy from a baby. Looks like consensus among the nodes involved in the entire transaction determine the settlement of payments. Hang on, let me put up some visuals to get a better grasp.
Hopefully that sent in the exact order that I put it up because this is a slide to slide breakdown on this here.
That’s from the lightning.network website
Here’s a definition of HTLCs
So my question is what the hell stops Alice and Dave from colluding? Or what stops 3/4 parties from colluding here?
Let me just take the three-person example and scale this back a bit.
Here’s step 1
Here’s my shitty little chart, but that’s what we got going on here
Step 2 — once again, simple enough
Step 3: Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
This confuses me as to how Bob is protected.
What It Sounds Like to Me
So, this random number and SHA256 hash that Charlie generates is given to ALICE.
Alice then gives BOB this hash that Charlie gave her along with the payment.
So, Alice sets a condition for the payment that she gives Bob that says:
Bob can’t get reimbursed for his 1,000 satoshis that he gave Charlie until Bob PROVES that he gave Charlie the money.
That concludes all of the steps.
So, after Charlie receives the 1,000 satoshis from Bob, he’s going to ‘sign off’ on the payment using his ‘pre-image’ — which comes from the data he created. Once that happens — he can swing Bob the pre-date and once Bob provides that to Alice, she’ll have confirmation that Bob delivered it.
This system protects Alice and Charlie completely. Charlie would never sign off on something he didn’t get and Alice would never reimburse Bob without proof that Charlie accepted the payment. Great.
But What About Bob?
What if Alice and Charlie collude with each other? Instead of creationg a hash for 1,000 satoshis, he creates data for just 1 satoshi?
He sends that to Alice and she sends that data to Bob along with 1,000 satoshis.
Charlie receives the 1,000 and confirms using the function for 1 satoshi and sends the pre-image of THAT transaction back to Bob.
When Bob redeems the transaction — he only receives 1 satoshi.
Alice retains her initial payment, Charlie is up ahead (maybe he splits this with Alice later) and Bob is left out to dry. Both Charlie and Alice are at a consensus on the settlement of the money. What prevents this? If anyone knows, I’d love to know myself as well.
Lightning Network Revocations
Read this if you get a chance: https://rusty.ozlabs.org/?p=450
Here’s the title to the first part of the Lightning Transactions:
That’s the crux of how continuous payments would work in the Lightning Network. Another aspect of it that, in my opinion, requires trust (isn’t Bitcoin supposed to be based on a trustless system?)
Further down the rabbit hole here — but here’s another good explanation here that breaks down this super complex Lightning Network idea even further — https://medium.com/@x0100/lightning-network-45b4b2119d97
Here’s an excerpt here:
I thought Bitcoin was supposed to be trustless…but the whole premise of LN requires trust.
This is corroborated by a recent article that was released today that touches on the idea of ‘watchtowers’.
But, back to revocable payments which are mandatory for the Lightning Network to function correctly.
Here’s an excerpt that shows how it works:
Once again, I might be an idiot — but this seems like I have to do a LOT just to make a couple transactions with someone. Nevermind the fact that the move off-chain and the move back on-chain = two TX already. Even if this did make BTC get huge, the scaling issue would persist.
Here’s something else that I found interesting:
This is what worries me most. I don’t see how collusion couldn’t occur under this scenario, if you look at the logic I put forth in the Alice-Bob-Charlie example. Charlie and Alice are protected against each other, but Bob is not protected AT ALL against collusion by Alice+Charlie.
I dare anyone to read this excerpt about payment revocation in the #LightningNetwork and tell me that this sounds simple in ANY way at all. Tell me how Jenny the soccer mom down the street uses this? Maybe I’m just dumb.
If you don’t know what I’m talking about, you have to REVOKE previous payments in the Lightning Network channel in order to do more than one transaction within it. This revocation is only secured by giving the other party your temporary private key for the previous TX.
This is what I mean by “security”
Also, check this out:
For those that can’t read the print here, I’ll re-post it for you:
“Commitment Transaction: a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The Initial Commitment Transaction is the first of these transactions; it records the initial balances within the channel. This is the second of the maximum of three on-channel transactions needed to maintain a Lightning channel; it can be combined with a funding transaction for a new channel under the cooperative conditions necessary to create an exercise settlement transaction.”
Another issue I have is the fact that you may need a considerable number of on-chain transactions while maneuvering within the LN. Could total up to 6+ just for one channel with someone where the payments are updated semi-occasionally.
There is some potential to the Lightning Network if we look at it in a vacuum. However, in its present form as an idea, it is very difficult to imagine that the Lightning Network will be able to successfully gain the type of widespread adoption that its proponent are claiming that it will gain. There are many technical aspects about the Lightning Network, such as giving another person the private key, or paying ‘watchtowers’ to monitor payments, that are entirely new to the crypto community, never mind the ‘lay people’ that Bitcoin hopes to obtain as well.
It also stands in stark contrast of the purported principles of Bitcoin by the current Bitcoin community. If it is meant to be ‘digital gold’, then it must not change in any way from its current iteration. However, if it is meant to be a fast method of payment processing or disbursing micropayments, then the Lightning Network, in its current iteration, is not the best solution to meet that goal.
Thus, in my opinion, I believe that it would be prudent to temper our expectations of what we believe that the Lightning Network will bring to the crypto world in general.