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.