The Lightning network is a layer 2 solution allowing for cheap and near-instant bitcoin payments. As with standard ‘on-chain’ transactions, it works in a peer-to-peer fashion without requiring trust in third parties. This network is built up from a collection of connected payment channels between pairs of individuals, each of which operates by exchanging zero-confirmation bitcoin transactions which are not actually submitted for inclusion in the blockchain. This reduces load on the chain, and allows settlement to occur in fractions of a second — much less than the 10 minutes average block production time.
Here, I concentrate on explaining how a single payment channel between two parties operates. The method by which these channels are connected to route payments will be explained in a separate post. I did previously discuss the use of zero-confirmation transactions to speed up payments, and the considerations leading to the idea of Lightning channels. Now, I will give a more detailed description of how this works. For more information, see the Lightning whitepaper. Also, medium.com has a pretty good explanation of how and why payment channels work in the way that they do.
To aid the exposition, let us suppose that two parties named Alice and Bob set up a payment channel between themselves. It is initially funded with 100 coins, with 50 from each of the two parties. At today’s prices, 100 bitcoin would be rather a lot to commit to a channel. I choose this quantity simply for a nice round number, and you can suppose that it is in units of 0.0001 bitcoin or 10,000 Satoshi, for more reasonable values.
Next, Alice and Bob start making payments to each other. As they already have coins locked up in the channel, this can be done by simply updating the quantities of these coins belonging to each party. See figure 1 below where, once the channel is funded, one payment is made on each of four days. They keep a tally of the amount of coins owed to each person, updated after every transaction. After this, the channel is closed and Alice and Bob receive back their current balance of coins.
This is, of course, a much simplified example. In practice, many thousands of payments could be completed before the channel is closed. Also, multiple payments could be made per second, rather than just once per day as here.
How does this look, in terms of transactions actually submitted for inclusion in the blockchain? The situation is shown in figure 2. There are only two on-chain transactions. The first of these is to fund the channel and has two inputs, one from Alice and the other from Bob, so they both must sign for it to be valid. The output is to a multi-sig address requiring both Alice and Bob to sign to release the coins.
Nothing further is done on-chain until the channel is closed. At this time, a single transaction is made from the multi-sig address and paying each of Alice and Bob their closing channel balances. Since it is multi-sig, both Alice and Bob must sign this transaction. Continue reading “Lightning Channels”