Chris Ward - A Developer’s Guide to Ethereum

This introduction to the Lightning Network was originally published at Brunos 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 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).

Lets 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.

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

• who hes opening the channel with
• how much BTC hes 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 theres been no activity in the channel for a week.

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 hes 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 theyre sent to the main blockchain, finalizing the channels creation.

Its 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. Its 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 Bobs 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.

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

• He generates a new transaction which states Im sending 0.1 BTC from the multi-sig address containing 10 BTC, and Im 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 doesnt 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.

Alice sends a new article three days later and its up to Bob to send a new 0.1 BTC. Seeing as its 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 Im sending 0.2 BTC to Alice and 9.8 to me and another If Alice doesnt sign and broadcast this state within a week, I get all 10 BTC.