Lightning Network
The Lightning Network isn’t off chain layer two network, but aims to scale the Bitcoin and Litecoin networks to be able to handle anywhere from millions to billions of transactions per second, instantly, through a power of smart contracts. A typical transaction consists of a sender and receiver. In this case, Lucy sending Alex some coins directly. Whilst this works fine in most situations, Lucy has to pay growing transaction fee due to increased demand on the network, limited block space, and on top of that, have to wait for her transaction to confirm.
The Lightning Network solves issue for the use of payment channels by allowing users to send multiple transactions to and from each other off chain, in a form of redeemable IOUs, kind of, sort of, let me explain. Payment channels use multi signatory addresses and exist between two users for a set period of time. In this case, 10 days, which will be represented by the nLockTime. Before Lucy consent any coins into the shared two of two multi signature addresses, she must first get Alec to sign a refund a transaction to her. For one, the amount she is going to deposit and two, with an nLockTime of 10 days. This ensures or at worst, Lucy has to add her signature to the refunds transaction and wait out the 10-day nLockTime before her money is refunded in full to her, in the case that Alex doesn’t cooperate.
With this, Lucy can now send her coins over and from here, start signing transactions from the multi signatory addresses to Alex. During this 10-day time period, Lucy can make numerous half sign payments to Alex without incurring any transaction fees. However, once Alex adds his signature to a transaction, since it doesn’t have an nLockTime, it is committed the blockchain, and that channel is closed. This is an example of a university-directional channel. If Lucy signs a transaction with an nLockTime of nine days, meaning it will occur one day before the refund transaction, Alex, by signing it, knows that in nine days time, he will earn those coins. As such, he can use it to pay Lucy, simply by creating a new transaction of an nLockTime of eight days, one day before her payment to him and so on. Each time the payment channel changes direction, and nLockTime must be brought forward by one in order to override the previous transactions.
This is an example of a bidirectional channel. Things gets a bit more complicated when we start adding more people and using three plus party payments. In this case, Lucy wants to pay Alex, but they don’t have a channel open between each other. They do, however, both have existing channels open with Brian, who runs a popular service they both frequent. A similar issue arises here, however, is this system isn’t trustless. Brian could choose to keep the coins and claim that he sent them to Alex. Likewise, Alex could claim that well, Brian never sent him the coins and accuse him of theft. Since there’s no records on the blockchain, you couldn’t prove him wrong. Thankfully, however, the parties here can use hashed time-locked contracts in order to prove payment and resolve this issue.
By utilizing one-way hash functions, every single party member in this chain, no matter how many, can prove a paid the next person in the chain, all thanks to some [inaudible 00:03:29] mathematics. It goes like this. One, Alex creates a random string represented by the letter S which will be used to sign transactions. Two, he hashes it, represented by H and shares H with Lucy. Three, Lucy ventures H with Brian and they both agree to create an H TLC between, comprising of a refund transaction to Lucy with an nLockTime of two days, and a 100-coin payment to Brian, so long as Brian can produce S. Four, Brian sends Alex H to prove that Lucy has paid him, and they even both agree to create an H LTC between themselves. But this time, with a refund nLockTime of one day to ensure that channel closes first.
Five, Alex sands Brian S to prove that he is indeed the payee, but instead of using it to broadcast for transaction onto a blockchain, they each agree to novate/remove the contract and update their channel with a new unencumbered transaction that does not require S for 100 coins to Alex. Six, Brian sends Lucy S, proving that he has paid Alex on her behalf, and they both agree to do the same. At this point, since no one was uncooperative, the entire transaction chain hasn’t taught for blockchain and Lucy has effectively paid Alex. If, however, say Lucy chooses to ignore Brian, Brian can then broadcast channel along with S, onto the blockchain and it will forcefully pour his funds from her, paying him, so long as he does say before the refund nLockTime on that channel runs out.
Otherwise, Lucy is free to redeem the funds leaving Brian 100 coins poorer. The nLockTime limit then effectively provides as an incentive that every member to react, and both protects and ensures that each party’s channel doesn’t tries before the other, so each can pour funds safe in that knowledge. That, in essence, is how The Lightning Network works.
Why does this all sounds very complicated to set up and actually get working? The two main developers behind The Lightning Network, Joseph Pune and Thaddeus Dryja are both working on an interface, which would hopefully make using it as simple as sending a standard Bitcoin or Litecoin transaction today. Meaning it will require no real extra input from a user’s perspective, which is very welcome news. Not to mention it will go a significant way to helping with its adoption. That’s of course, is not to mention the other benefits that come with this, including reduced blockchain growth as more and more transactions are handled off chain by The Lightning Network.
Oh, and micro transactions, which can actually be a thing now, as user won’t be charged a transaction fee until funds are committed from a payment channel on to the actual blockchain. So, you don’t have to pay 20 cents of the luxury of buying a coffee with Bitcoin. From an average user perspective, and this is pretty good, all we need to do is keep trading our transaction, I.e, use it across The Lightning Network, and every now and then update our channels between each other. From a minus however, not so much as they’ll start to receive less and less income from transaction fees. They will, however, still remain a necessary part of the ecosystem. And, whilst the Bitcoin and Litecoin networks resemble mesh networks, The Lightning Network will, we imagine, most likely resemble multiple hub networks as it matures. Connected to each other, where users send funds through one central service, so there’s an exchange or a crypto bank.
This is even more apparent when we start looking into and judging their user statistics, although there will always be the option to open your own private channel if you wish. There are, however, some caveats. Without implementing the necessary transaction malleability fixes, it is not safe or feasible to continue use The Lightning Network. One way to achieve is would be for the use of SegWit or segregated witness, which we previously discussed here. However, whilst SegWit looks set to be activated on Litecoin, it looks far less likely to ever be activated on Bitcoin. Meaning, we will most likely see The Lightning Network fully in action first on Litecoin whist Bitcoin in the meantime, searches for another solution.
Many thanks to Charlie Lee of Litecoin and Joseph Poon, one of the main developers of The Lightning Network, for helping to compile this guide. A reminder that you can stay up to date with everything regarding The Lightning Network and its development by simply following them or visiting their site, lightning.network.
