Introduction to the Lightning Network

July 4th 2019

To understand the Lightning Network, we are going to take a journey through the required parts behind the implementation, and then how all of it comes together.

What is the Lightning Network?

The lightning network can be briefly described as: (1) a network of user-generated channels that send payments back and forth, (2) secured by smart contract functionality, and (3) privatized in a trust-less fashion (trust-less means you don’t need to trust or even know your counter-party).

Rather than transacting in a trusted fashion as you would normally do in a standard transaction, the Lightning Network transactions are completely trust-less. What this means is that since these styles of transactions operate on top of a multi-signature-based platform, participants remain anonymous and transactions are ensured to be secure due to smart contract capabilities.

Core components:

Trust-less bi-Directional Payment Channels:

One of the primary components of the Lightning Network is its established network of bi-directional payment channels. Bi-directional payment channels enable transactions to be made independently without trusting intermediate nodes. In order to understand this concept, we must first breakdown the individual pieces to the entire puzzle.

Unconfirmed Transactions:

At its core, the Lightning Network is built up from regular transactions, the fundamental difference here is that these transactions are not broadcasted over the Bitcoin network. Instead, they are stored locally, on the nodes of the users, and can be broadcasted over the network at any time as agreed by the parties.

Double-spend protection:

As the name implies, if there are two of the same output, only one of them will be confirmed by the network.

P2SH-Addresses:

P2SH-addresses, or Multi-signature (Multi-sig) as it is commonly known, require multiple private keys to “unlock” or spend Bitcoins. Unlike traditional payment services, there is no centralized handling of user funds at any point in time. Participants generate their own pairs of private keys and public addresses.

Hash Time-Locked Contracts — CheckLockTimeVerify (CLTV) & CheckSequenceVerify (CSV):

CLTV “Time-locks” effectively “lock Bitcoins” in an output to make them spendable at a specific point (time & date), or specific block height, in the future. There are two different types of time-locks, CLTV which is absolute and CheckSequenceVerify (CSV) which is relative. While CLTV has a definitive lock up time, CSV, instead, uses relative time. Once a CSV-output is recorded on the blockchain, it takes a specific amount of Bitcoin from that point onwards before the Bitcoin can be spent again.

Cryptography:

While cryptography is a fundamental building block for Bitcoin and crypto as a whole, it is applied in a new way specifically for the Lightning Network. In essence, a hash is included in an output (spend), and requires the subsequent input to include the corresponding “secret” or “value” in order to be spendable.

Now that we have covered the basics, let’s dive deeper into the rabbit hole to explore the challenges and how the Lightning Network solves them.

Deep Dive

Bi-Directional Payment Channels:

At its core, The Lightning Network is primarily comprised of extensive series of trust-less bi-directional off-chain payment channels. Brace yourselves, things are about to get messy.

In order to setup a bi-directional payment channel, two parties must first agree to put funds into an open transaction.

I will be using Anthony and Billy for purposes of illustration. Since Anthony and Billy expect to transact frequently, they decide to open-up an off-chain bi-directional payment channel and use this to send Bitcoin (BTC).

Anthony and Billy decide they want to establish a channel with the total value of 10 BTC. In other words, Anthony and Billy need to set a pre-defined “limit” on the overall transaction value that cannot be surpassed. Each user then sends 5 Bitcoin to a multi-signature address which will then serve as the “safety deposit box”. This box acts like a lock, which is only unlocked if enough keys — out of a set of predefined ones — decide to unlock it.

For example, In our case, both signatures derived from the private keys of both Anthony and Billy are required to spend any BTC from this address.

In short, think of the payment channel as a safety deposit box where two people deposit equal amount of money and each put a lock on it. The action of both users depositing funds into this box is recorded on the blockchain in the form of an “Opening Transaction” and thereafter a payment channel is open between both parties.

I know what you’re thinking, “What’s the purpose of that?” — The idea behind locking money into such a box is that no one person can spend the money in the box without the other. The money set aside in this box is then used to transact between each party involved.

How do transactions occur between both parties?

Anthony and Billy have already established the payment channel between themselves with a total of 10 BTC split 5/5 between both. Anthony then decides he wants to send 2 BTC to Billy. In order to do that, he would transfer a promise of ownership for two of his Bitcoins in the deposit box to Billy. After this transfer of promise, if the box is unlocked, Billy would be able to take 7 BTC while Anthony will be left with 3 BTC.

However, Since Anthony and Billy want to continue to transact between themselves for an undetermined amount of time (the time period could range from a few days, to a decade if required, and there are no time limitations) they do not open or unlock the box as this would finalize the transactions and publish them to the blockchain.

To summarize:

A bi-directional payment channel, simplified, is nothing but a combination of pooling money together and then transferring the promise of ownership of the pooled-in money in the agreed upon manner. If ever either Anthony or Billy wants to close the channel, they can.

Closing a channel would simply mean opening the box and taking the money inside. This opening of the box must happen on the blockchain and the “who owns how much” is recorded on the blockchain.

Why are bi-directional payment channels important to the Lightning Network?

The Lightning Network works by moving the inherent value from “ownership” of the currency in question, to the “promise of ownership” of said currency.

To explain, let’s refer to another example where we have three people partaking in a transaction.

Anthony and Billy have already established their payment channel between themselves. In addition to this, there now exists a payment channel between Billy and Charlie.

Note: that there is no payment channel between Anthony and Charlie.

In this situation, if Anthony wanted to transfer 2 BTC to Charlie, he can use the payment channel between Billy and Charlie to do that. To accomplish this task, Anthony asks Billy to transfer a promise of 2 BTC to Charlie on the “Billy & Charlie” payment channel and then Anthony reimburses Billy with 2 BTC on the “Anthony & Billy” channel.

With the capabilities to create and maintain limitless amounts of trust-less bi-directional payment channels between individual parties, a huge chunk of transactions can be off-loaded from the blockchain and carried out off the chain. This frees up a significant amount of the chain’s available bandwidth there-by greatly increasing on chain transactional performance.

It is also worth noting that as an added benefit to end users, rather than having to pay higher transactional fees to incentivize miners to include your transaction in a block as soon as possible, millions of transactions can happen on these bi-directional payment channels without having to worry about paying transactional fees.

Hash Time-Locked Contracts (HTLC):

A hash time-locked contract is a type of payment in which two people agree to a financial arrangement where one party will pay the other party a pre-determined amount of crypto. These contracts are “time-locked” which basically means that the receiving party has a certain amount of time to accept the payment, otherwise, the money is returned to the sender.

These styles of payments can help to eliminate the need for third party contracts via contracts that are established between two parties. Third parties that are often involved in contracts are lawyers, banks, etc. Lawyers are often required to draw up contracts, and banks are often required to help store money that is then transferred to the receiving party as stated in the contract.

With HTLC’s, two parties can setup contracts and transfer money without the need for third party involvement.

How do HTLC’s work?

The best way to describe this is the following example:

Charlie wants to pay Dan for X via HTLC. Charlie sets up a specific hash which represents the amount of money that will be paid and an allotted time window in which Dan will be able to receive his funds. In order for Dan to receive the payment he will have to create cryptographic proof of payment, within the pre-defined time limit.

If Dan meets the deadline and procures the necessary proof required to release the funds, Dan is paid. However, if Dan fails to meet the deadline the money is returned to Charlie.

Benefits of HTLC

1. As previously mentioned, HTLC’s eliminate the need for third party involvement when implementing a contract between two parties which in-turn also eliminates the need for third party trust.

2. Since these contracts are time sensitive, it prevents the person who is making the payment from having to wait indefinitely to find out whether or not his or her payment goes through. Also, it prevents money being wasted since if cryptographic acknowledgment is not obtained, funds are simply returned back to the sender.

3. Because cryptographic proof of payment is required, the recipient automatically helps validate the payment on the blockchain.

4. Since hash time-locked contracts are based on hashes, they are easily added to blockchains.

5. Each party is protected from counter-party risk due to the structure of these contracts. The parties involved in sending and receiving the payments do not have to trust each other or even know each other to make sure that the contract will be executed correctly.

It is important to note that for this write up we will only be covering HTLC’s importance regarding the Lightning Network. This technology also plays an integral part in Cross-Chain Atomic Swaps which will be covered in a future article.

Relevance to the Lightning Network:

As mentioned previously, Anthony has established a bi-directional payment channel With Billy. Anthony then decides he wants to pay 2 BTC to a third person, Charlie. To do this, Anthony and Charlie could open a payment channel between themselves, but they don’t need to since Billy and Charlie already have a mutual channel, Anthony can simply pay Charlie through Billy.

Simply put, Anthony is going to send 2 BTC to Billy to be sent to Charlie.

The problem, however, is that Billy is a shady guy, and Anthony doesn’t trust him — Or anyone for that matter. Anthony’s concerns are either Billy is never actually going to pay Charlie OR Charlie could potentially claim he never received his 2 BTC. In this instance, Anthony would not know who was at fault, which creates a rather precarious situation.

To alleviate his concerns, Anthony wants to ensure that he only pays Billy 2 BTC, and that Billy also pays Charlie 2 BTC. This could potentially be accomplished with a simple cryptographic trick.

For Example:

1. Since Anthony wants to send Charlie 2 BTC, he tells Charlie to create a value and send him the hash. Anthony also tells Charlie to exchange the original value with Billy for 2 BTC.

2. Anthony then takes the hash from Charlie and instructs Billy to provide him the corresponding value X which only Charlie has.

a. Note X = secret Hash | string

3. Billy then turns to Charlie and gives him 2 BTC in return for the value X.

4. Finally, Billy turns back to Anthony, Gives him the value X.

Anthony knows that Billy must have gotten the value X from Charlie in the exchange and concludes that Charlie got his 2 BTC. Anthony can then confidently give Billy the 2 BTC reimbursement knowing all debts are settled.

The above stated example provides a sticky situation where Billy, the middleman, is forced to trust Anthony and Charlie to some extent. Billy must trust that Charlie is going to provide the correct value, and he must trust Anthony to really give him 2 BTC upon presenting the value. Since all parties involved do not trust one another, this is where hash time-locked contracts come into play.

Rather than trying to utilize a manual trust-based cryptographic trick, Anthony decides to initialize a HTLC with Billy. Instead of sending 2 BTC directly, Anthony sends the 2 BTC to a new Multi-signature address (safety deposit box). The bitcoins are effectively locked up in this box and can be unlocked in two different ways. Billy can either include his signature & the value X OR Anthony can include his own signature which has a CLTV Time-Lock attached to it.

If Anthony opts for the CLTV method, Billy would have a predetermined set amount of time to create a subsequent transaction in which he includes his signature, the value X, and broadcasts it to send the bitcoin from the earlier stated multi-signature address. As such, this trade is guaranteed. Billy can only claim Anthony’s bitcoin if he provides the value X: Broadcasting it over the bitcoin network which makes it publicly visible for Anthony to see.

As mentioned, Anthony and Billy have established an HTLC as well as Billy and Charlie. So, if Charlie claims his 2 bitcoins from Billy, Billy will get the value in return; it will be visible on the blockchain.

If that happens, Billy is guaranteed to get 2 bitcoins from Anthony as well. Billy can take the value that Charlie made publicly visible on the blockchain, include it in his HTLC with Anthony, and claim 2 bitcoins from himself too. The two independent channels are effectively linked.

It is very important to note that Billy gets his value from Charlie before Anthony can reclaim his bitcoin from Billy. If Billy gets the value from Charlie after Anthony already reclaimed his back, Billy is stuck in the middle after all. The time-out in Billy and Charlies HTLC must therefore expire before the time-out on Anthony and Billy’s HTLC expires.

I.e., Billy would need to specify the time-out window to be shorter than that of the HTLC that exists between him and Anthony to ensure transactional fluidity.

To summarize, hash time-lock contracts link different trust-less bi-directional payment channels together to create an extensive and hypothetically limitless network of off-chain inter-connected payment channels.

The Lightning Network

Let’s recap, so far Anthony and Billy opened a bi-directional payment channel, which they both funded with five bitcoins. They’ve made two transactions back and forth, and at the current channel state, both Anthony and Billy can claim 5 bitcoins for themselves by “dropping the channel” on the blockchain.

Now, they want to include a HTLC in the channel. This is to ensure that if Charlie claims 2 bitcoins from Billy in return for his value X, Billy is guaranteed 2 bitcoins from Anthony in return.

To continue, Anthony and Billy create a new commitment transaction each. In many ways, these commitment transactions are very similar to previous commitment transactions. They include a normal output, and an output to a multi-signature address with a CheckSequenceVerify Time-Lock (CSV) and a special hash. Anthony and Billy then exchange their old private keys to effectively invalidate the previously created payment channel. Once exchanged, both Anthony and Billy can sign their halves of the commitment transactions and potentially drop them on the blockchain at any time.

The difference here is that Anthony’s and Billy’s commitment transactions now include one new output, worth 2 bitcoins, which makes the new balance 3 bitcoins for Anthony, 5 bitcoins for Billy, and 2 bitcoins for the new output. The new output includes the HTLC, with a twist, as this output has three ways to unlock it.

First:

The new output in both Anthony’s and Billy’s commitment transactions releases 2 bitcoins on condition that Billy’s signature and the value X is included in the subsequent transaction. As such, regardless of whether Anthony or Billy signs and broadcasts the commitment transaction, only Billy can unlick this output — If he includes the value X.

The difference between the two commitment transactions: If Billy drops the channel, there is a CSV-timelock involved and he will need to wait 1,000 blocks. If Anthony drops the channel he can claim the bitcoins immediately.

Second:

If Anthony ever tires to cheat and broadcast this channel when it’s already outdated, Billy can claim the bitcoins using Anthony’s secret and he wouldn’t need to provide the value X.

Third:

As with all other HTLCs, both commitment transactions also include the usual CLTV time-out fall-back for Anthony. If Billy does not include the value within the determined time window, Anthony can claim his bitcoins back. In this case it does not matter whether Anthony or Billy drops the channel.

At this point you may be asking “What does all of this mean?”

Both Anthony and Billy hold a half-valid commitment transaction. If Anthony drops his commitment transaction on the blockchain, he immediately sends 5 bitcoins to Billy. Additionally, he can wait for 1,000 blocks, and claim 3 bitcoins for himself. Plus, Billy has two weeks to provide the value X, and claim the 2 bitcoins in the HTLC output, and, if he fails to provide the value X, Anthony can reclaim it.

Billy, meanwhile, can drop his commitment transaction at any time as well, and immediately send 3 bitcoins to Anthony. Then, he’d have to wait 1,000 blocks to claim 5 more bitcoins from one address, and another 2 bitcoins from the HTLC output if he provides the value X, and, again, if he fails to provide the value X, Anthony can reclaim it.

What this all boils down to is this:

Billy is guaranteed to receive 2 bitcoins in exchange for the value X (assuming he has it). Anthony knows there is no way he can cheat Billy out of his bitcoins — not even if he found out what the value X is through some other means.

Knowing this, Billy and Anthony “settle” outside of the channel. Billy gives the value X to Anthony, and Anthony can agree to update the channel status to the more normal state without the HTLC and the time-out deadline, assuming both parties want to keep the channel open. This is less of a hassle than having to drop the channel on the blockchain.

Put a bow on it already:

We covered all the above stated information to address the key benefit of the Lightning Network. Almost everything described in the examples involving Anthony, Billy, and Charlie will typically never need to hit the bitcoin blockchain at all.

If both Anthony and Billy want to close the channel “peacefully” they can simply create a transaction from the original opening transaction to override everything that happened since the opening transaction. From this closing transaction, they send themselves their fair share of the safety deposit box, as represented by the most recent channel state.

Respectively, if Anthony wants to close the channel, he can at this point simply create a transaction paying himself 3 bitcoins and Billy 5 bitcoins. He can then ask Billy to sign and broadcast the transaction close the channel.

In the end, only two transactions will have been broadcast over the Bitcoin network and included in a block: the opening and the closing transactions. This closing statement holds true regardless of the number of transactions that occur between Anthony and Billy. If Anthony and Billy left the trust-less bi-directional payment channel open for a decade and transacted 1,000,000 times, there would still only be two transactions broadcasted over the network.

This is the true power of the Lightning Network.

For an interactive visual representation of the Lightning Network check out the link below:

https://rompert.com/recksplorer/

Please show your support!

Be sure to up-vote this article by pressing the clap button down below, Your support is greatly appreciated.

You can clap up to 50 times if you really like the article!

Thank you for your support!