How the Lightning Network Helps Blockchains Scale

This introduction to the Lightning Network was originally published at Bruno’s Bitfalls website, and is reproduced here with permission.

Bitcoin is currently impractical to use because of slow and expensive transactions plaguing its blockchain. Most people use it as a store of value (the digital gold fallacy) or to trade on exchanges. A concept known as the Lightning Network was introduced as a solution to this scalability issue.

The Basics of the Lightning Network

The Lightning Network was first described in a 2015 whitepaper by Joseph Poon and Thaddeus Dryja. The concept, however, was actually introduced by Satoshi Nakamoto in an email to Mike Hearn in 2013.

The Lightning Network works through payment channels which are actually multi-sig wallets (multiple signature). A multi-sig wallet is just a Bitcoin address which requires a signature or private keys of several owners before money in that address can be spent. You can view them as bank vaults which require the turning of two different keys at the same time in order to open.

A multi-sig wallet can, for example, be the common Bitcoin address of a married couple, wherein they both have to sign a transaction in order to spend their common Bitcoin.

The purpose of payment channels is regular execution of smaller payments and avoidance of high transaction fees. Examples of relationships ideal for LN channels are employee-employer, consumer-producer, utility provider-utility consumer, coffee drinker-coffee shop, etc. The idea is letting a customer open a payment channel with his coffee shop, regularly paying for coffee without having to wait for confirmation (10 to 60 minutes currently).

How the Lightning Network Works

Let’s explain with a step-by-step example. Our imaginary scenario is as follows:

Bob wants to pay Alice to write articles for him. The deal is 10 BTC for a total of 100 posts, or 0.1 BTC per post.

In a traditional Bitcoin system, that would require one hour on average with a fee of $5 to $500 per transaction, depending on how backlogged the network is. Because both Alice and Bob are bitcoin maximalists, they chose to open an LN channel rather than go with a cheaper and easier to use altcoin.

Step 1: Opening a Channel

Bob creates a regular Bitcoin transaction on the main chain which defines the following:

• who he’s opening the channel with
• how much BTC he’s sending into the channel (10 BTC)
• after how long a period of time (one week in this case) he has the right to take the 10 BTC back if Alice does not respond.

The latter is actually a sub-transaction in the main transaction with a “timelock” function, which makes sure that, in spite of both parties having confirmed it, the money is not moveable for a week.

So, Bob sends Alice two transactions — one in which he suggests opening a payment channel with a 10 BTC deposit on a multi-sig which is opened with that transaction, and one in which he says the 10 BTC go back to him if there’s been no activity in the channel for a week.

Step 2: Accepting the Opening of a Channel

Alice receives two transactions in which she can see that Bob is offering 10 BTC on the multi-sig address with the two of them as the participating parties. She can also see he’s added the condition to return the money to him after one week of inactivity. She accepts this and signs the transactions, after which she broadcasts the transactions and they’re sent to the main blockchain, finalizing the channel’s creation.

It’s important to define two concepts here: signing a transaction and confirming or broadcasting a transaction. A signed transaction is merely ready for sending to the blockchain and constitutes an agreement between parties. It’s not visible on the blockchain. A broadcast or confirmed transaction is sent to the blockchain and closes the payment channel, settling balances.

Signing the first transaction opens the channel and causes Bob’s 10 BTC to be deposited into the multi-sig address. Signing the other, despite allowing Bob to take all 10 BTC back, can only become active after a week.

Alice and Bob now have a week to do the first bit of business.

3. Sending the First Transaction

Alice wrote an article and Bob likes it. He pays 0.1 BTC by doing the following:

• He generates a new transaction which states “I’m sending 0.1 BTC from the multi-sig address containing 10 BTC, and I’m sending 9.9 to myself”. Alongside it, he generates another transaction: “If the previous transaction is not broadcast within one week of signing it, then I send myself all 10 BTC from the multi-sig address”.
• He sends the transactions over to Alice for signing via Lightning Network nodes without sending them to the main blockchain. Remember: transactions are only finalized in the blockchain once both parties sign and broadcast them.
• Alice receives the transactions and checks conditions: 0.1 BTC for an article, OK, and a week to accept and get 0.1 BTC which means I have a week to send a new article in.

Alice doesn’t have to sign these new transactions. By not responding to them, she will trigger the week-long timeout which will return the money to Bob and cancel their arrangement. To keep the deal open, she needs to keep it “on the table” by just signing it and not broadcasting.

This “leaving on the table” is the part the Lightning Network nodes are taking care of. The software accepts and signs the transactions, but only on the LN layer, not the main Bitcoin blockchain. After a signature from Alice, the new state of the channel is the valid state.

The transaction is, at any given point in time, immutable and the conditions described in it must be satisfied before any change can occur: either a week needs to expire, or the transaction needs to be broadcast by either Alice or Bob to finalize the latest distribution: 0.1 – 9.9 BTC.

4. Sending the Second Transaction

Alice sends a new article three days later and it’s up to Bob to send a new 0.1 BTC. Seeing as it’s not possible to alter an existing transaction and Bob is unable to send another 0.1 into the same transaction as before, he generates a new one which says: “From the multi-sig address with 10 BTC I’m sending 0.2 BTC to Alice and 9.8 to me” and another “If Alice doesn’t sign and broadcast this state within a week, I get all 10 BTC”.

Alice now has the opportunity to either sign and broadcast the new transaction, thereby taking 0.2 BTC and finishing the work relationship, or continue with it, send more articles, and get more of such incremental transactions. She can also stay offline or idle for a week and lose it all.

5. Docking Pay

In the second article, Alice accused a competing company of plagiarism but didn’t do enough fact checking. This harmed the company’s reputation and Bob decides to dock 0.05 off her pay.

Bob generates a new transaction which says “From the multi-sig address with 10 BTC I’m sending 0.15 BTC to Alice and 9.85 BTC to myself” alongside a transaction saying “If Alice does not sign and broadcast this within a week, I get all 10 BTC”.

Alice now has the following options:

• tolerate the pay cut and sign the transaction, continuing with the work
• broadcast the last signed transaction, the one for 0.2 BTC and get more money than Bob is currently offering, but this would finish their relationship
• not respond and lose it all.

5a. Alice Cheats

Let’s assume that because of the second article’s incident the relationship has been permanently damaged and Alice wants out but she already signed the 0.15 BTC transaction. Can she decide to sign the 0.2 BTC one instead that still on the table?

The LN is set up in such a way that signed (but not sent) transactions are ranked by age. Trying to send an older signed transaction is a punishable offense in the network which sends all the money from the multi-sig to the non-offending party.

This security system makes sure only the latest signed transaction can be broadcast, but has other implications as well: it requires the users to be constantly online to have their nodes be able to communicate with one another. To prevent users from having to be online at all times, the concept of Watchtowers was introduced, which we’ll explain in another post.

5b. Bob Cheats

Let’s assume Bob is the cheater. Alice sent the third article, but Bob decides to punish her further by not paying at all. Alice has no idea whether or not she’ll ever be paid again, and wants to end the relationship. She can simply broadcast the last signed transaction and the 0.15 BTC will be sent to her. She’ll only lose as much money as she spent on writing a single (third) article.

But what if this further offends Bob and he decides to send in another transaction in which he says “from the multi-sig address I’m sending 0 to Alice and 10 to me, and if she doesn’t sign and broadcast within a week it’s all mine anyway”.

This is where the aforementioned concept of signed and broadcast transactions comes into play. For an LN transaction to be valid, it needs to be signed by both parties. If it’s not signed, the last signed transaction is valid for broadcasting.

This makes Alice safe from ultimate fraud.

5c. All Good

The alternative that’s best for everyone involved is for Alice to do her job perfectly and Bob to send incremental transactions. Let’s say that Alice had another mistake or two and ended up earning 9.9 BTC, so that’s what Bob’s latest transaction says: 9.9 BTC to Alice, 0.1 BTC to him. Both are happy with this agreement and Alice signs and broadcasts this transaction.

The following occurs:

• Alice signs and broadcasts the transaction and it’s written to the blockchain.
• The transaction costs a transaction fee, docked from the total being paid out. Seeing as it’s only a single tx now, and not 100 of them, it’s only the cost of a single tx.
• Within ten minutes to an hour, the transaction will be finalized on the Bitcoin blockchain and the money will be transferred, the channel closed.

It’s important to note that, while this process sounds incredibly complex, they’re working on masking this complexity and hiding it from users. The payment channels are expected to be invisible in end-user software.

Network and Routing

In the example above, Alice and Bob have a clearly defined relationship with an end goal in mind. In theory, payment channels will stay open indefinitely because of routing. The idea is to connect several nodes and then route payments from one to the other, allowing payments to be sent to nodes you’re not connected with through nodes that are. The software should be able to find a way to get there.

For example, if Alice is working with Roko, a graphic designer, and Bob is working with him too, let’s assume Alice will need a 0.1 BTC graphic design work done. She can send this to Roko through Bob as long as Bob has at least 0.1 BTC in the channel open towards Roko, and Alice has 0.1 BTC in her balance towards Bob. Bob is running a mediator Lightning Network node in this case.

The problem is that if someone already paid Roko through Bob and Bob no longer has a 0.1 BTC balance towards Roko, no one else can pay Roko through Bob; they need to find another route. This video explains it well.

This is an argument for keeping channels open indefinitely and permanently locking funds into the LN, because it’s assumed LN’s popularity will be so big anyone will be able to pay anyone anywhere. But all this has its own set of problems which we’ll cover in another post.

Conclusion

In essence, the LN is a practical solution to some problems that currently don’t exist in the Bitcoin network. Does this make it an efficient way of scaling Bitcoin? We think not, because some problems seem impossible to solve. We do, however, feel like the concept is interesting and are looking forward to seeing where the developers can take it.