The Lightning Network

Getting Started

The genesis of payment channels was born in some of the earliest Bitcoin code, namely version Bitcoin 0.1. Years later, the genius of payment channels was realized and the nascent Lightning Network as a layer 2 solution emerged. Shortly thereafter, payment channels were adopted by the Ethereum community as well.

Overview

The Lightning network is its own protocol and its own blockchain. As of right now, the Lightning network is compatible with the Bitcoin blockchain and the Litecoin blockchain. All standard payment channel operations such as, opening a channel, closing a channel, settling a channel, etc., are done by the network upon request from the user. The implementation of Lightning we used is called Lightning Network Daemon (LND) and it is based on the BOLT specifications.

LND Capacity

• Payment channels
• Single-hop/multi-hop payments
• Atomic swap

The lightning team has achieved a cross-chain atomic swap with LND, however it isn’t exactly clear how this is done in practice.

How it works

Payment Channels

When two parties decide to open a bidirectional payment channel they create one on-chain transaction to deposit funds into a multi-signature output to be used off-chain.¹ Immediately prior to this transaction a refund transaction is created which will return the funds to each party respectively in case either party decides they don’t want to participate. After the initial on-chain transaction the payment channel is ready for off-chain transactions.

In the example above, if Alice wants to make an off-chain transaction, Bob must first generate an invoice/payrequest for a specified amount and then send the invoice over to Alice.² Alice will then make an off-chain transaction for the amount specified in the invoice.

The payment channel can be closed unilaterally by either party at any time with the most recent transaction as their current balance. If a channel is closed unilaterally while the other party is offline then the funds are frozen for a period of time dependant on the channel policy which is negotiated when the channel is initially opened. The latest transaction state is maintained by the network and does not have to be stored manually, besides for auditing purposes.

1. The process is the same for unidirectional payment channels except only one party deposits funds into the multi-signature output.
2. A payrequest is a serialized invoice that has the amount owed encoded into it. Payrequests are strictly one time use and cannot be recycled. Since payrequests contain a payment hash, after an invoice is paid out the hash preimage becomes public. Multiple uses of a payrequest could lead to an attacker saving the preimages and reusing them for a future payment using the same payrequest.

Multi-hop Payments

Traditional payment channels are single-hop payments because they are made directly from one node to another through a direct channel. Multi-hop payments, on the other hand, are payments made from one party to another through an implicit channel. For example, let’s say Alice, Bob, Carol and Dave are participants on the Lightning Network and Alice has a channel with Bob, Bob has a channel with Carol and Carol has a channel with Dave (Alice -> Bob -> Carol -> Dave). Alice wants to pay Dave 1BTC, but Alice does not have a direct channel with Dave. Luckily for Dave, Alice has a payment channel with Bob who has a payment channel with Carol who has one with Dave. By using this implicit payment channel, Alice can pay Dave via Bob and Carol.

Dave wants to get paid by Alice, so he generates a random secret x. From the preimage x Dave generates the hash h(x) and sends it over to Alice.

Then, Alice creates a Hashed TimeLock Contract (HTLC)with Bob for the amount of 1BTC and with an expiry so that if the funds are never claimed they don’t stay locked inside the contract.¹

Following Alice, Bob does the same thing with Carol, making a HTLC for 1BTC, and Carol does the same thing with Dave. The only difference between the HTLCs is that each successive one must have a shorter expiry time (timelock).²

Dave has the preimage for the for the HTLC that was created between him and Carol so he can redeem the 1BTC contained within the contract. As soon as Dave does this the preimage becomes public and Carol and Bob can do the same thing and each redeem 1BTC as well. Finally, Alice is left with 1BTC less than before the transaction and Dave is left with 1BTC more.

1. TimeLock Contracts are contracts with two fundamental mechanisms. The first mechanism is called a hashlock. A hashlock ensures that the funds contained within a contract can only be redeemed by a contract participant who supplies the preimage of the hash that the contract was instantiated with. The second mechanism is a timelock and timelocks specify that the funds of a contract are to be refunded to the originator if the preimage of the hash isn’t supplied within the allotted time period.
2. Having a shorter timelock for each successive HTLC in a multi-hop payment is a crucial property insofar as security is concerned. Suppose the HTLC Alice <-> Bob has an expiry of 24 hours and the HTLC . Carol <-> Dave has an expiry of 48 hours. Dave could potentially wait 25 hours before he claims his 1BTC from Carol, but by this time HTLC Alice <-> Bob has expired and Alice has been refunded her 1BTC. Essentially, what ends up happening is that Bob pays Dave instead of Alice! This is not what we had intended.

Atomic Swap

Atomic swaps are very similar to multi-hop payments except they are cross-chain. Suppose Alice wants to trade 1BTC for Bob’s 100LTC. So, Alice generates a random secret x and uses it as a preimage for the hash h(x). Then Alice sends Bob 1BTC using h(x) as the hashlock for the HTLC and sends h(x) over to Bob. Bob then does the same thing, sending Alice 100LTC and using the same hash, h(x), as the hashlock for the HTLC.

Since Alice knows the preimage, she can collect the 100LTC from the HTLC created by Bob. Once she does this the preimage becomes public and Bob can go collect his 1BTC from the HTLC created by Alice. As with HTLCs in multi-hop payments, Alices HTLC must have a longer timelock as to not expose security concerns.

Thanks for reading our blog, we hope you learned a little bit about the Lightning Network. Be sure to stay tuned for Part 2 talking about our experience with spinning up our own nodes and making off-chain transactions!