What is the Lightning Network?  A Beginner’s Guide

If you’ve ever dealt in Bitcoin, you may have suffered through hour-long (or at worst, day-long) transaction times.  It’s becoming commonplace for Bitcoin to have backlogs of 150k+ unconfirmed transactions at times of high transaction volume, and when we couple this with its exorbitant fees, it’s a wonder how you’re ever gonna use it to pay for that 5 piece meal at KFC.

The lightning network is here to help with that.  This concept is the brainchild of Thaddeus Dryja and Joseph Poon, and the duo presented it with a whitepaper back in 2015. If you’re not too keen on reading the lengthy paper chock-full of tech jargon, we’re gonna lay it out for you in layman’s terms here.

What is the Lightning Network?

On its most basic level, the lightning network is a method for Bitcoin users to exchange currency value off the Bitcoin blockchain.  This is accomplished using a few complex algorithms that interact with Bitcoin’s base script, and it allows for, that’s right, lightning quick payments at a fraction of the transaction fees. As such, it’s been presented as a necessary scalability tool, one that Bitcoin will need if it wants to be a viable payment option in the future.  This practice can extend to cross-chain atomic swaps.  These swaps are the same in practice, except that they take place between two different currencies/blockchains. We go over atomic swaps in more detail here.

Now that we’ve covered the much-too-simple explanation, it’s time for a lengthier one.

Lightning Network: How it Works

Opening a Bilateral Payment Channel

To get started using the lightning network, you’d want to set up a payment channel.  Payment channels are the transaction avenues through which the lightning network transfers value. To establish one, you have to open a transaction for this channel directly on the blockchain.

“But I thought you said all of this takes place off-chain?”  Don’t worry–it still does, but you first have to let the Bitcoin network know that you’re opening a transaction.  Once you’ve done this, you and the other party you’re transacting with will keep your own balance sheet of the exchanges you make on the channel.  Transactions and updated account balances will be recorded on this ledger every time funds are moved, and after you’ve conducted your business on the channel, you’ll broadcast the final result to the blockchain to close the account.

Multi-signature Wallets

“So if payment channels take place off-chain, where/how are the funds managed until they’re recorded onto the blockchain?”  What a good-looking question.  In order to use a payment channel, both parties need to send their funds to a multi-signature wallet address.

Let’s say Molly and Steve have placed bets on the outcome of the Super Bowl.  They each wager 1 BTC and want to make sure that the other holds his/her end of the bargain, so they deposit both of their funds into a multi-signature wallet.  This wallet functions like a safe for deposits, while a set of private keys for the transactions functions like combinations that allow either party to access the funds.  The funds will remain locked in the wallet until:

• both Molly and Steve sign a finalizing transaction with these private keys,
• one party decides to finalize the transaction themselves, or
• a time limit is reached and the transaction is automatically submitted.  Once this happens, the funds will be moved back to either party’s individual wallets.

In order to successfully set up the multi-signature wallet, both Molly and Steve create a value (essentially, a secret key to unlock transactions) which they then use to create a hash and send to each other.  Hold onto this information–it’s vital to understanding how commitment transactions work later.

Once Molly and Steve deposit their respective funds into the multi-signature wallet, they can then create what’s called an open transaction and broadcast it to the blockchain.  Once this is broadcasted, a series of commitment transactions are then used to manage funds.

Transferring Value with Commitment Transactions

Turns out, Molly won the bet, but she’s nice, so she says Steve only owes her 0.5 BTC instead of 1.  To initiate a transfer of this wealth, both Molly and Steve would update their respective balances in the payment channel by signing a commitment transaction.  Commitment transactions divide funds between both participants per their mutual agreement–in essence, these transactions act like IOUs that will be paid out once the payment channel is closed.  

For example, in order to exchange values, Molly signs a transaction that sends 1.5 BTC to herself and .5 to a new multi-signature wallet address. Then, she signs this transaction and sends its hash to Steve. In turn, Steve signs a commitment transaction to mirror Molly’s, wherein he sends .5 BTC to himself and 1.5 to another multi-signature wallet.  He then signs this and sends this transaction’s hash over to Molly.

So, we’ve got a) the original 2 BTC sitting in the payment channel’s multi-signature wallet, b) .5 BTC sitting in a multi-signature wallet that’s payable to Steve, and c) 1.5 BTC sitting in a multi-signature wallet that’s payable to Molly.  Effectively, once either party sends their respective transaction hashes, the balance sheet in the payment channel’s multi-signature would update as both parties have agreed to the transfer.  Viola, the currencies have been exchanged without using Bitcoin’s blockchain.

The values from these wallets can be unlocked only under three conditions:

1. a certain amount of time expires,
2. either party unlocks the funds from the multi-signature wallets they set up with the wallet’s value (key), or
3. both parties decide to sign off on the transaction together.  

It’s important to note that, if one party decides to close the channel and sign off on a transaction alone, s/he will have to wait a pre-determined amount of time (dictated by the contract) from the time that the transaction is signed to receive his/her funds.  This may seem excessive, but it’s imperative to prevent cheating through payment channels–more on this in a bit.

Recurring Payments/Updating the Channel

What if Molly and Steve want to keep updating the channel or make more than one exchange?

To illustrate this further, say Steve was paying Molly for a recurring service, like a haircut.  Steve deposits 0.2 BTC into their multi-signature wallet, and every time he gets his locks trimmed, he signs a commitment transaction to Molly for 0.001 BTC and sends it to the new multi-signature address.  To do this, he’d have to repeat the steps we just went over, sans opening a transaction on the network as that’s accomplished by the time the first commitment transaction is signed.

So, to process recurring payments, account balances in the multi-sig need to be updated each time.  To do this, every time Steve gets his haircut, he’d commit a new sum of money to the multi-signature wallet that he set up to pay Molly.  But in doing so, he creates a new value and a new hash for this new transaction.  Molly does the same, and when both parties exchange the new hashes, they also include the old values (keys) for the previous transaction.

In effect, this ensures that neither party can cheat the other.  If upon closing the payment channel Steve tries to cheat Molly out of her payments by broadcasting an old transaction amount, he’s in trouble.  

For instance, if when he closes the channel Steve owes Molly 1 BTC out of the original 2 BTC he deposited, but he signs the original transaction to give himself the original amount, Molly can call him on it because she has the values from all prior transactions.  What’s more, Steve has to wait before his transaction clears according to the timeframe both parties agreed on before conducting business, while Molly’s is instant.  Thus, if she sees that she’s been paid 0 BTC for her services, she can sign off on the 2 BTC in the multi-signature wallet because she has the key for this transaction, and thus, the ability to unlock its funds.

Thus, if one party attempts to defraud another, the counterparty is awarded all of the malicious party’s funds.  This penalty is in place to deter bad actors from abusing the payment channel’s shared fund allocation.

Additionally, node operators and miners who spot this foul play can act on Molly’s behalf if she’s not online to notice the cheating.  In compensation, these guardian angels are awarded a bounty (fee) in the transacted currency for their services.

Closing a Payment Channel

When Molly and Steve are ready to close out their accounts, they simply sign a transaction with their private keys to broadcast their final account balances to the blockchain. At this point, miners will verify it per usual and store it on the public ledger.  As with an opening transaction, this closing transaction is the only interaction that either party will have with Bitcoin’s blockchain.

Alternatively, two parties could also set an expiration date for the length of the contract.  For example, using the nLockTime algorithm, they could open a payment channel for 30 days, after which time, the channel will close and the final balances will be broadcasted to the blockchain.  Every time the parties want to update their balances, however, the expiration date is decreased.  So, if Molly and Steve were placing bets on multiple football games throughout a season, every time a wager was paid, the nLockTime contract would have a new, shortened expiration date (e.g., if the first commitment transaction would be finalized in 30 days, the second transaction would pay out in 29, then the third would pay out in 28, and so on).

The purpose of nLockTime contracts is simple: it keeps account balances up to date and prevents one party from falsifying an account statement.  Like we went over earlier, every time a commitment transaction is agreed upon, the old account balance is replaced with a fresh one, and each involved party has records of this new balance as well as an old transactions value (key).  If any party attempts to defraud the other, the fraudulent party will be penalized.

Multichannel Payments and Hash Time Locked Contracts

“What if Molly and Steve want to send Bitcoin to each other but they don’t have a payment channel open?”  Well, they can go through an intermediary.  We’ll call this guy Chuck–tell Chuck hello.

Turns out, Molly and Steve both have payment channels open with Chuck, so instead of opening up a new channel, they decide to us their respective bidirectional payment channels to trade through Chuck.

Now, this is theoretically a trusted trade, so the trick is facilitating the exchange in a secure way.  To do this, the Lightning Network implements Hash Time Locked Contracts (HTLCs).

Say Molly wants to give 0.5 BTC to Steve because she’s just really nice like that–seriously, what a peach.  In order to do so, Steve must create a string of cryptographic numbers called a value (essentially a confirmation code or key).  He then creates a hash of this value to send to Molly.  To simplify this written illustration, we’ll represent value with V and hash with H.

When Molly receives H, she shares it with Chuck.  At this point, Molly will only send Chuck the 0.5 BTC if he reveals V.  To get V, Chuck sends 0.5 of his own BTC to Steve in exchange for V.  Once he has this number, he sends V to Molly who then sends 0.5 BTC to Chuck.  And there you have it–Molly effectively transferred 0.5 BTC to Steve.

In case you got lost, here’s how it went down:

Steve creates V and H→ Steve sends H to Molly→ Molly sends H to Chuck→ Chuck sends BTC to Steve→ Steve sends V to Chuck→ Chuck sends V to Molly→ Molly sends BTC to Chuck

Thus, the value (V) serves as a confirmation code/key for the hash (H), which represents a receipt/lock for the transaction.

“That’s all fine and dandy, but how does Molly know that the value Chuck sends her is legit, and what’s keeping Steve from running away with the BTC Chuck pays him?”

Again, good questions.  Just as nLockTime keeps everyone honest in a bidirectional payment channel, Hash Time Locked Contracts keep parties accountable in this model.

With HTLCs, the Bitcoin funds being transacted are locked up yet again in a multi-signature wallet and can only be unlocked a) after the value (V) and hash (H) are presented or b) the contract expires after a timeout period.

In effect, this means that, when Molly and Chuck go into an agreement for Molly to pay Steve, she locks the Bitcoin she owes Chuck in a multi-signature wallet using the HTLC.  Once Chuck pays Steve and receives V, he can then enter V and H into the HTLC to be reimbursed with the Bitcoin Molly committed to the contract.  Alternatively, if Chuck fails to hold up his end of the bargain and the contract expires after, say, a week, then Molly’s Bitcoin is freed up and goes back into her personal wallet.

The same interaction takes place on Chuck and Steve’s own payment channel.  Chuck can not relinquish his Bitcoin to Steve until Steve reveals V.  Once Steve reveals V into the multi-sig contract, Chuck now has V and Steve receives his BTC.

This process could, theoretically, be run through multiple payment channels and multiple individuals.

Wrapping Up: Why the Lightning Network Matters

It’s a complicated topic.  Synthesizing this information into digestible chunks was hard enough, so cheers to you for sticking with it this long.

For a TL;DR recap: The Lightning Network is an off-chain system that allows individuals to swap currencies multiple times without having to put all of these transactions on-chain.  Instead, only two transactions (and opening and closing) are recorded on the blockchain, while all other transactions, as many as there may be, are processed through a secondary layer of off-chain nodes.

There are a couple of key benefits to this model:

Effective microtransactions: The Lightning Network is geared towards microtransactions.  Instead of having to pay exorbitant fees that may outweigh the value being transferred, the Lighting Network allows users to send small sums of currency to each other without having to go through the Bitcoin network directly.  They still have to pay a fee to node operates, but it is minuscule compared to Bitcoin’s usual network fee.

Scalability and latency solutions: Going along with the prior point, the Lightning Network would cut back on network bloat.  Reducing the number of on-chain transactions means less work for miners which, in turn, means faster transaction times and lower fees.  If every transaction doesn’t have to be put on the blockchain’s public ledger, the network would run much more smoothly.  Further, Lightning Network transactions would be much quicker than those on-chain.

You’re probably wondering how any average user would be able to navigate the multi-step process we just outlined properly.  Well, Dryja, Poon, and others are working on applications/interfaces that work out all of the complicated steps for you–all you have to do is press a few buttons.