Recall that in our previous article, we discussed how Lightning network make payments in Bitcoin faster, cheaper and more private. This article aims to give a high level understanding of how payment channels work in Lightning network covering ways payment is sent, how funds are protected and delivered within the network.
On the lightning network, there are popularly two ways by which a payer can send payment to a recipient. A payer can choose to create a path that connect them directly to the recipient peer called a channel or the recipient can create an invoice which contains the amount, their identity on the network amongst other things. Both approaches does not require that you trust the other party and are secure. Let’s look at the former in detail.
Payment channels are suitable for multiple payments. Channels are created between peer nodes (connected nodes) on the Lightning network. To open a channel, the two nodes exchange series of messages, negotiate the time funds can be locked, amongst others. Thereafter, both parties will create both a public/private keys and exchange the public keys (funding public keys). Then the payer (wallet) will derive an address called Pay-to-Witness-Script-Hash (P2WSH) Bitcoin address from the public keys, then construct a a 2-of-2 multisignature transaction called the funding transaction that spends to the address, which effectively place the funds in an output that requires both the payer and the recipient to jointly sign a transaction to spend from its output. When this transaction has been transmitted and recorded on the Bitcoin network, it form the basis of a channel. Now, what happens if the recipient decline to sign any transaction that spends from the funding transaction? Is the payer’s money locked up? Let’s consider this scenario closely.
In a decentralised network like Bitcoin and Lightning network, transacting parties are not required to trust each other for them to transact. They are governed by the cryptographic protocol which ensure that no one party is cheated. Before the channel funding transaction is broadcasted to the Bitcoin network, the payer creates another transaction signed both by themself and the recipient that spends all the output back to the payer’s address. This is a prerequisite step that protects the payers’ funds. This way, if the recipient who is a channel partner no longer cooperates, attempt to cheat or disappears, the payer can recover all their funds by simply broadcasting the signed transaction to the bitcoin network. This same protective principle is applied when the channel becomes operational.
When the channel has been established, the payer can pay the recipient by simply constructing a transaction (referencing the funding transaction id as input) that send the required number of sats to their channel partner (recipient), and the balance back to their address. These transactions are called commitment transactions, and any of the channel partner can send a payment to the other. They can exchange as many commitment transactions as they want without fees. Because these commitment transactions are not broadcasted to the bitcoin network, they are incredibly fast. Use cases exists where payments can be made per bit of streaming services. You might be wondering what happens if one of the channel partners broadcasts a prior state transaction which is not the latest commitment transaction in the channel to the Bitcoin network?
Since commitments transactions are valid Bitcoin transactions, once they are broadcasted to the bitcoin network, they cannot be stopped, censored or cancelled. Lightning network works in a way that punishes the party who broadcast a previous transaction. It does this by locking the part of the transaction output that pays the party that broadcasts the transaction and pay immediately the channel partner’s balance. This timelock (delay) can be the number of blocks or the duration of time (negotiated by the channel partners) from when that transaction was confirmed on the blockchain. Also, the outputs to the party are not just timelocked, they contain a condition that permits the channel partner to spend that output using a revocationpub key. The key permits the party to construct a transaction that claim the entire balance immediately. This key is exchanged between the channel partners per a previous commitment whenever they acknowledge, sign and commits to a new commitment transaction. This is similar to giving the other party a means to punish them if they attempt to broadcast the previous transaction.
As we have seen above, it is not in the best interest for anyone to attempt to cheat in a channel. So how can they close the channel and each party claim their due balances? when any of the channel party wants to close the channel, they will initiate a closing transaction that both parties will negotiate and agree. This closing transaction pays each party their balance immediately. The closing transaction does not have timelock and penalty revocation keys.
In summary, in this writeup, we have looked at how payment channels permits a large number of transactions to be carried out in a secure, cheap and fast way. In another article, we will look at how a node can send payment to another node when they are not in a channel. Thank you for reading. I look forward to your comments.
Top comments (0)