Understanding Payment Channels

Off-chain transactions seem to be the best option for Bitcoin scaling, while multiple companies are building and testing off-chain transaction infrastructures, few people have ever experienced how they work.

The problem

First, why do we need to do transactions outside the blockchain anyway? People that use Bitcoin are looking for security, and the blockchain is certainly the best way to achieve secure transactions. The problem is, of course, that the blockchain is quite expensive and inefficient, since every participant in the network stores a copy of the whole history and the usage has to be limited in order to keep sustainable the participation in the network.

The limited quantity of data that can be put on the blockchain creates competition to have the transactions included on the ledger, driving the transaction costs up. So in order to keep the blockchain layer light and secure, we need to use it as little as possible and find other ways to transact.

Off-chain payment channels

Payment channels are based on the idea of transaction replacement to update the state of an unconfirmed transaction before broadcasting it to the network. This concept is older than most people think, indeed Satoshi himself implemented something similar in the first Bitcoin release (however his goal at the time was not to improve scalability but to enable high-frequency trades between a set of parties).

By replacing transactions before broadcasting, numerous trades can occur without using the expensive and slow blockchain. Off-chain payment channels can be divided in three groups:

• Mono-directional payments channels
• Time-based bi-directional payment channels
• Punishment-based bi-directional payment channels

Mono-directional payment channels

Mono-directional payment channels have seen the first implementation back in 2013, when Matt Corallo and Mike Hearn added support on BitcoinJ, but they were quite limited use-cases since they only let you move money from A to B but not the other way around.

The basic design of a mono-directional payment channel is as follows:

• Alice sends 1 BTC to a 2-of-2 multisig contract between Alice and Bob.
• To send 0.1 BTC to Bob, Alice creates and signs a transaction that gives 0.9 BTC to herself and 0.1 BTC to Bob and sends it Bob.
• To send other 0.2 BTC in a second moment Alice updates the state of the channels creating another transaction that send 0.7 BTC to herself and 0.3 to Bob.
• Alice cannot broadcast to the network and have included on the blockchain any of those transactions, since she does not have the required signature of Bob (remember that the funds are locked in a multisig contract).
• Bob is always incentivised to broadcast only the last state of the channel, since it represents the outcome where he receives more bitcoins.
• To protect Alice from the risk that Bob is unresponsive and does not cooperate to broadcast any state of the channel (blocking also Alice’s funds), a time-locked transaction that refunds Alice of one BTC is created at the opening of the multisig contract. The time-lock is needed to make sure that Alice can use this transaction only in the case Bob is unresponsive.
• Before the end of the time-lock period, Bob will broadcast the last state of the channel in order to avoid the risk of Alice broadcasting the time-locked transaction.

However the time-lock transaction is not an ideal solution, since it is vulnerable to malleability attacks. To mitigate this, in 2015 a protocol upgrade introduced CLTV (check lock-time verify), which allows to include the time-lock in the script of the contract itself, instead of creating a specific transaction, avoiding the malleability problem.

N.B. Such payment channels have a predetermined limited life, it is indeed insecure for Bob to keep using the channel after the time-lock expires, requiring the closing of the channel before that date.

Time-based bi-directional payment channels

While in a mono-directional payment channel only Alice can send the money to Bob, but not the other way around, in a bi-directional channel the flow can go in both ways.

The security of a mono-directional payment channel is based on the fact that Bob does not have an incentive to broadcast an old state of the channel, since it would only benefit Alice (who, missing Bob signature, cannot broadcast old states on her own). However, in a bidirectional channel both parties may have an incentive to broadcast an old state of the channel at different times, so a different security model is required. To do so there are two different approaches: time-based and punishment based security. We will start analysing the former.

A time-based channel achieves security by time-locking transactions in so that the last state of the channel has always the lowest time-lock, meaning it is the first one that can be broadcast on the blockchain. Every new transaction having a lower time-lock invalidates all the previous ones, updating the state of the channel.

To make such system really trust-less, it is necessary to create the first transaction that sends back the funds to both parties before any bitcoin is moved to the multisig, just in case one of the two parties becomes unresponsive. However, creating a transaction that spends an unconfirmed transaction exposes the parties to the risk of malleability attacks, meaning that only SegWit transactions can be used in this process since, unlike normal transactions, they are immune to malleability problems.

Such design however has an evident problem, the security of the channel is guaranteed only until the first time-lock expires, after which it has to be closed (i.e. sending the funds to the two parties), giving the channel a predetermined limited life time.

To overcome this problem a slightly different design can be implemented using relative time-locks instead of the previously seen absolute time-locks. With a relative time-lock, the clock starts ticking only after the transaction is included in a block. To achieve channels without expiry date using relative time-locks, we need to build a special kick-off transaction pre-signed by both parties, with the purpose of activating the time-locks (start the ticking). It will then be broadcast only when one of the parties wishes to unilaterally close the channel (if both agree, they can send a simple transaction to the respective addresses with the correct amounts). Before the kick-off transaction happens, the time-lock is frozen and can stay in that condition indefinitely.

While this design greatly improves the lifetime of a payment channel, there is still a huge limitation: you quickly run out of time if you do many transactions, as the time-lock decreases every time the channel changes its state, until it reaches zero. Luckily there is a trick to extend the life of the channel even further: when the time-lock of the transactions is becoming too low, instead of sending money to the two parties, you send again bitcoins to the multisig, creating another kick-off transaction for a new series of time-locked transactions. This procedure can be repeated as many time as necessary to keep the channel alive, but the trade-off is that to unilaterally close the channel more transactions have to be broadcast, with potentially very high fees.

Such structure requires some blockchain monitoring to see if the other party has broadcast the kick-off transaction, because in that eventuality it is important to be ready to close the channel with the last state before previous transactions become broadcastable.

Punishment-based payment channels

A different approach to create channels with no expiry date is to base the security on the punishment of a malevolent counterparty rather than on time. The idea is still to lock funds in a multisig contract between the two parties involved in the channel, but to guarantee that the right behaviour is respected both parties sign transactions that spend to a more complex smart contract design to make transaction replacement secure. Such payment channel design is what is used for Lighting Network implementations.

To set up the channel, first Alice and Bob have to generate a secret (i.e. a random number) and exchange the hash. The two parties create a funding transaction and deposit some coins on a 2-of-2 multisig contract, let’s say they put 0.5 BTC each, but before broadcasting it to the network they both create a subsequent transaction of the funding transaction, the so called commitment transaction. In the commitment transaction Alice sends 0.5 BTC to herself and 0.5 BTC to a contract where the coins can be spent either by Bob after a predetermined amount of time (e.g. one week after the transaction goes on the blockchain) or by Alice including in the transaction the secret that Bob generated.

At this point Alice signs the transaction and gives it to Bob, who now can sign it as well and broadcast it at any point when he wishes to close the channel (in case Alice is unresponsive or he needs liquidity on-chain).

In the meantime, Bob creates a commitment transaction which is specular to Alice’s one, sending 0.5 BTC to himself and 0.5 to a contract where the coins can be spent by Alice after one week or by himself including the secret generated by Alice.

Each party signs his commitment and gives it to the counterparty, who can sign and broadcast it at any time

The scripts of Alice’s commitment transaction will follow the template below:

Output 0: 0.5 BTC to the following contract

OP_DUP OP_HASH160 <hash160(pubK Alice)> OP_EQUALVERIFY OP_CHECKSIG

Output 1: 0.5 BTC to the following contract

OP_IF
“+7 days” OP_CHECKSEQUENCEVERIFY OP_DROP
<Bob pubkey> OP_CHECKSIG
OP_ELSE
OP_SHA256 <sha256(Bob secret)> OP_EQUALVERIFY
<Alice pubkey> OP_CHECKSIG
OP_ENDIF

At this point the funding transaction can occur and it gets broadcast on the blockchain. Now Alice knows that if her counterparty becomes unresponsive with the funds locked in the channel, she can unilaterally sign and send on-chain the transaction received by Bob, recovering the bitcoins. She will however have to wait one week in order for the time-lock to expire, but during this period Bob cannot spend the other branch of the contract because he still does not know Alice’s secret.

The script of the multisig address Alice and Bob are sending bitcoins to will look like this:

OP_2 <pubK A> <pubK B> OP_2 OP_CHECKMULTISIG

So far all we have done is to safely set-up the channel, but the first real off-chain transaction still has to occur. Similarly to what we have already seen with time-based channels, off-chain payments are achieved through transaction replacement, but this time old transactions will be invalidated using the secrets instead of time-locks.

When Bob wants to pay 0.1 BTC to Alice, first they both need to generate a new secret and share the corresponding hashes, which will be used to build a new commitment transaction with the same structure of the previous one, but instead of sending 0.5 BTC to Alice and 0.5 to himself, he now sends 0.6 BTC to Alice and 0.4 BTC to himself.

Now two different, but both valid, commitment transactions exist. Since Bob could try to broadcast on the blockchain the old transaction (which gives to him 0.1 extra BTC) it is important to invalidate it and enable secure transaction replacement. To do so, both parties can now share the secret they generated for the previous transaction. In this way if Bob tries to broadcast the old transaction, Alice has a full week to spend the funds locked in the contract providing Bob’s secret before Bob can move any BTC out of it. Now Bob is strongly dis-incentivized to attempt an old transaction broadcasting as he would lose all the money he put on the channel.

Operations necessary to conclude a transaction in the payment channel

The described process enables secure transaction replacement allowing the channel to stay open indefinitely, with no increasing settlement costs after many transactions occurred (making it superior to time-based channels), but still requiring some blockchain monitoring to ensure security.

Moving forward

Payment channels are the building blocks of off-chain scaling solutions, but alone they are not enough since they would require opening a channel (and locking liquidity) with every person you want to do transactions with. To overcome this problem, the Lightning Network introduces some extra hashlock-based cryptographic magic that makes different payments channels communicate with each other forming a network (ok that was oversimplified, you can learn more about the Lightning Network here).

Other solutions to improve the scalability of Bitcoin payments are being explored by multiple teams and devs around the globe, such as the channels factories to help the re-balancing of payment channels, Schnorr signatures and MAST scripts to reduce the size (while improving the privacy) of on-chain settlement transactions and many other amazing proposals.

Making the blockchain scale is not easy, and currently there are limited resources to finance infrastructure improvements. It may take some time for Bitcoin to be competitive with mainstream centralized solution, but Bitcoin is here to stay for centuries, so it is totally worth to wait the time needed for proper development.