This document is an attempt to describe the various kinds of payment channels that are possible in Bitcoin with today’s technology. It is a top-to-bottom description of the payment channel and covers:
The reader is assumed to have a knowledge of the format of bitcoin transactions and transaction outputs, the concept of pay-to-[witness-]script-hash and the workings of opcodes and the Script language. No prior knowledge of payment channels is assumed.
A few things this article doesn’t cover:
This document is necessarily a work in progress. The rate of innovation in this area is extremely rapid, and new varieties of payment channels will most likely continue to be developed. Please direct any feedback to @jonnynewbs or raise a ticket against the github repo.
With that, let’s get started!
A payment channel is a sequence of valid Bitcoin transactions which are constructed, signed and exchanged off-chain by two counterparties. The transactions are not broadcast to the Bitcoin network during the operation of the channel. Only when one or both of the parties are ready to close the channel is a single closing transaction broadcast. This allows the balances between the two parties to be updated many times while only resulting in two transactions on the blockchain: one to open the channel and one to close the channel.
There are many reasons we’d want to do this:
Payment channels exist as a sequence of commitment states. For a channel to be in a commitment state:
To update the balances in the channel, the channel goes through a commitment state change or commitment transition and enters a new commitment state with updated balances. A payment channel will always be in a commitment state or a commitment transition between two commitment states.
The consistency property guarantees that the channel remains synchronized between both parties and that the channel never enters a state where the parties’ balances are inconsistent. The escape property guarantees that at all times during channel’s existence, both parties have an escape route to claim their balance. The safeguard property guarantees that by entering into a payment channel, neither party can be denied their full balance (so long as they act correctly).
Taken together, these properties ensure that payment channels do not require any trust between counterparies and mean that neither party takes on risk by entering into the channel.
For more advanced types of payment channel, we need to avoid first or third party malleability. For this reason, all of the transactions described below are assumed to be segregated witness transactions (either P2WSH or P2WPK).
The format for P2WSH TXOs are defined in BIP 141. For simplicity, we refer only to ‘scripts’ and ‘signatures’ in this article, and ignore the technical aspects of including those scripts and signatures in the spending transaction’s witness program. Readers can just assume that the script locks the TXO and the signatures provide the requirements for unlocking the TXO.
Simple one-way payment channels can be implemented using standard P2SH without worrying about malleability. Again, we refer only to ‘scripts’ and ‘signatures’ for the locking and unlocking conditions.
Bitcoin transactions are collections of Transaction Inputs (TXIs) and Transaction Outputs (TXOs). The simplest Bitcoin transaction consists of a single TXI and a single TXO. The value of the TXO is equal to the value of the TXI (less the transaction fee):
A TXI is simply an unspent TXO (a UTXO) from a previous transaction, and the TXO from this transaction will go on to be a TXI in a future transaction. We can draw a chain of transactions as follows:
Often we’re not interested in the transaction that funded our channel, just that there’s a UTXO which we use as our TXI. We also don’t know how the TXO from our transaction will be spent until it’s included as a TXI in a future transaction. Our standard transaction ends up looking like this:
Of course, most Transactions don’t have just a single output. Here’s an example transaction with two TXOs:
Finally, a single TXO can be spent in many ways. We can illustrate that with branching from the TXO:
This is slightly arbitrary since the TXO could be spent in an infinite number of ways. However, it is instructive to see the different ways that we’re expecting the TXO to be spent. In the following payment channels we’ll be constructing many commitment transactions, each of which is spending the same TXO, so this notation will be useful.
If a transaction has been broadcast to the Bitcoin network, we’ll colour it green:
We’re not going to consider blockchain confirmations in this document. As with all Bitcoin transactions, users should wait for a transaction to be confirmed before building on top of it, but whether they actually do, and how many confirmations they wait for is an implementation decision. For the rest of the article we’ll assume that all broadcast transactions are confirmed and will not be double-spent or invalidated.
If a transaction has been constructed and one party has a valid witness for the transaction, then we colour it yellow:
This transaction can be broadcast to the network (potentially after a relative or absolute locktime) by at least one party to close the channel.
There may be several unbroadcast transactions using the same TXOs. We’ll keep the most recent one coloured yellow, but the older transactions will be a lighter yellow to show that we’re not expecting them to be used:
Once a transaction has a valid witness, that witness is valid forever. However, the transaction can be invalidated by creating and broadcasting a different transaction which spends the same TXO that our original transaction was spending. We’ll colour transactions that have been invalidated in this way red:
Message exchange is depicted using ladder diagrams. As well as showing message exchange between the participants in a channel, the ladder diagram can also show one of the participants broadcasting a message to the blockchain:
In practice, when we show Alice sending a ‘signed transaction’ to Bob within the channel, Alice may only be sending a signature. As long as Bob knows what the transaction format should be, there’s no need for Alice to send the full transaction to Bob.
Payment Channel Balance Diagrams are used to show the balance within a payment channel.
Alice and Bob start with their own stock of Bitcoin:
Alice funds a new payment channel with 20 BTC. Those funds are hers, but are temporarily locked in the payment channel. The balance of funds within the payment channel (indicated by the downward-pointing arrow) can move left and right as the parties create and exchange new commitment transactions:
Alice then pays 10 BTC to Bob within the channel. The channel now contains a balance of 10 BTC for Alice and 10 BTC for Bob:
Alice continues to pay Bob in the channel until her balance is 5 BTC and Bob’s balance is 15 BTC:
Finally, Alice closes out the channel, freeing up 5 BTC for herself and 15 BTC for Bob:
This is the simplest form of Payment Channel. It is One-way (also called Simplex or Unidirectional), which means that funds can only flow in one direction from payer to recipient. It is also Fixed-duration, which means that the payment channel has to be closed with a closing transaction before a fixed expiry time. If the payer wishes to continue paying the recipient through a channel after this time, she must open a fresh payment channel with a new anchor transaction.
As is tradition, Alice is the payer and Bob is the recipient. Alice wishes to pay Bob in increments of 0.01 BTC up to a maximum of 1 BTC.
To open the channel, Alice constructs and signs an anchor transaction and then broadcasts it to the Bitcoin network. The anchor transaction has a single TXO which can be spent either:
Alice needs a refund branch to protect her funds from being stranded in the channel. This is required for the escape property of channels - both parties must have an escape route to reclaim their funds at all times in the channel’s existence. If the anchor transaction didn’t have a refund branch and was just a 2-of-2 multisig, then Alice wouldn’t have an escape route.
Without an escape route Alice’s funds could become stranded or held to ransom inside the channel. If Bob stops responding to Alice’s messages (either inadvertently or maliciously), Alice would have no way to get her funds back. A malicious Bob might hold Alice’s funds to ransom and only agree to unlock the multisig TXO in return for a ransom fee.
The script is as follows:
OP_IF <Bob's public key> OP_CHECKSIGVERIFY # Spend branch - requires both signatures OP_ELSE <channel expiry duration> OP_CHECKSEQUENCEVERIFY OP_DROP # Refund branch - after the channel expiry duration only Alice's signature is required OP_ENDIF <Alice's public key> OP_CHECKSIG # Both branches require Alice's signature
To finish opening the channel, Alice constructs and signs the first commitment transaction (CTx1) and sends it directly to Bob. This transaction has the anchor transaction TXO as its only TXI, and produces two TXOs:
Both of those TXOs can be standard P2PKHs.
We’re now in commitment state 1:
Let’s check the commitment state properties:
Let’s assume that Bob hasn’t closed out the channel and Alice wants to pay a further 0.01 BTC to Bob. She constructs and signs a second commitment transaction CTx2 and sends it to Bob. This second transaction has exactly the same anchor transaction TXO as its TXI, but now produces the following TXOs:
Commitment state 2 looks like this:
In effect, this is a double-spend of the anchor transaction TXO, so only one of those transactions can be included in the blockchain.
Let’s check the commitment state properties again:
Alice can continue paying Bob through the payment channel in this fashion. Each time she wants to pay another 0.01 BTC to Bob, she constructs a new CTx from the same anchor transaction output and sends it to Bob.
There are two ways that the channel can be closed:
Bob may choose to sign and broadcast his latest CTx to close the channel for a couple of reasons:
In either case, he should make sure he signs and broadcasts the most recent CTx well before Alice does, to make sure the RTx doesn’t steal the TXIs for his CTx.
Here’s a diagram of Bob closing the channel after 4 commitment transactions:
In this example:
Bob broadcasts CTx4 transaction, which has the following signature:
<Alice's sig> <Bob's sig> 1
Bob should never let the channel expiry time pass without broadcasting a CTx. Once the channel is expired, Alice is able to broadcast the RTx and reclaim all the funds in the channel.
However, if Bob stops responding, Alice needs a way to reclaim the funds from the channel. She does this by constructing and broadcasting a refund transaction.
Here’s a diagram of Bob disappearing after 2 CTxs, and Alice reclaiming the funds with an RTx:
The refund transaction takes the anchor transaction TXO as its TXI and has the following signature:
<Alice's sig> 0
An advantage of this style of payment channel is that it is extremely simple. The anchor TXO script is essentially either a 2-of-2 multisig in the spend branch, or a P2PKH with relative timelock in the refund branch. Commitment transitions are achieved simply by Alice constructing and signing new CTXs and sending them to Bob.
The channel is also almost entirely passive from Bob’s point of view. He simply needs to keep hold of the most recent CTx, and then sign and broadcast it when he’s ready to close the channel. Simple channels should be very straightforward for wallets and applications to implement.
One of the most obvious limitations of the simple payment channel is that it is one-way. Bob’s balance in the channel can only ever increase (and Alice’s balance can only ever decrease). This is because every commitment transaction that Alice signs and sends to Bob is valid forever, or at least until one of them is broadcast and confirmed. Even if Alice constructs and signs a new CTx with a smaller balance for Bob, Bob will always be able to broadcast the CTx which assigns him the greatest balance. Alice has no way to stop Bob from doing this, and no way to invalidate the old commitment trasactions.
However, there is a trick that allows Alice to ensure that Bob can’t use a previous commitment transaction to claim an old balance. This trick uses hash pre-images and timelocks to construct a revocable transaction. That’s what we’ll look at next.
The trick to creating revocable transactions is to construct one of the TXOs such that it is either encumbered by:
To revoke the transaction, Bob reveals the pre-image of his secret revocation hash to Alice. If Bob ever broadcasts the revoked transaction, then Alice will have the chance to spend before him, since his spend branch is encumbered by a timelock and Alice’s isn’t. Bob is effectively blocked from being able to use the revoked transaction.
We’ll call this type of TXO a revocable TXO or rTXO for short. The secret revocation hash is h(rev) and its pre-image is rev.
Transactions will normally have multiple TXOs. Within a payment channel, there will be one TXO for Alice’s balance and an rTXO for Bob’s balance (which can be spent by Alice when the rTXO is revoked):
Once Bob has revealed the revocation secret, he’s no longer able to broadcast the revocable transaction since Alice would be able to collect her spend TXO as well as the rTXO. The transaction has been revoked:
We’re going to use rTXOs a lot for more advanced channels, so it makes sense to have a special notation for them:
Conceptually, the combined up/down facing chevron indicates that the rTXO can be revoked.
The script for a revocable transaction is:
OP_IF # Bob's spend branch - after the revocation timeout duration, Bob can spend with just his signature <TXO revocation timeout duration> OP_CHECKSEQUENCEVERIFY OP_DROP <Bob's public key> OP_ELSE # Revocation branch - once the revocation pre-image is revealed, Alice can spend immediately with her signature OP_HASH160 <h(rev)> OP_EQUALVERIFY OP_DROP <Alice's public key> OP_ENDIF OP_CHECKSIG
For Bob to spend the TXO, he needs to wait for the revocation timeout duration and then provide the following signature:
<Bob's sig> 1
If Bob broadcasts a revoked transaction, Alice can claim the revocation TXO by providing the following signature:
<Alice's sig> <rev> 0
The revocation hash is the 160 bit image of hashing a secret revocation pre-image first with SHA256 and then with RIPEMD-160. Bob needs to make sure that Alice can’t guess the pre-images for the revocation hashes. If she could do that then she’d be able to steal the funds from the rTXO before Bob had revoked it.
The simplest way for Bob to create revocation secrets would be to use a pseudo-random number generator every time he needed to provide Alice with a new revocation hash. However, we’re going to use revocation secrets in channels where we expect a large number of CTxs. Alice needs to store all the revocation secrets to ensure Bob doesn’t broadcast an old revoked transaction, and the space required for Alice to store those pre-images would grow linearly with the number of commitment transactions in the channel.
Much better is if Bob uses a seed to generate the revocation secrets, and then shares information with Alice that would allow her to generate all the revocation pre-images that have been revealed so far.
One way to do this is to use a hash chain. Take a random seen and run SHA256 on it 1,000,000 times. Use the 1,000,000th hash as the first revocation pre-image, the 999,999th hash as the second pre-image and so on. Alice only needs to store the most recent pre-image, since she can derive all the other pre-images by hashing it repeatedly. The downside to this is that Bob needs to hash a value 1,000,000 times when the channel opens, and then either:
A better way is to use a seed to construct an efficient binary tree of revocation secrets. The method for constructing and storing the sha-tree is described in https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt.
Using this method:
To create a two-way payment channel, Bob first needs to provide two revocation hashes h(rev1) and h(rev2) to Alice. Alice then constructs the anchor transaction exactly as before. The ATx’s TXO can be spent either by a 2-of-2 multi-sig or by just herself after the channel expiry duration.
Alice completes the channel opening by constructing and signing CTx1 and sending it to Bob. The difference from the one-way payment channel is in the construction of the CTxs: instead of including a standard P2PKH for Bob’s TXO, she includes an rTXO with a revocation hash h(rev1) provided by Bob.
The message exchange for channel opening is:
Commitment state 1 is as follows:
If Alice then wants to increase Bob’s balance in the channel to 0.02 BTC, she constructs a new CTx which sends 0.98 BTC to herself and 0.02 BTC to Bob. The only difference from a simple channel is that the TXO for Bob in the CTx is an rTXO. Alice uses the second revocation hash h(rev2) to construct CTx2.
To acknowledge and commit the new CTx, Bob sends the revocation secret for CTx1 rev1 along with a new revocation hash hash(rev3) so Alice can construct CTx3.
The message exchange for the first channel payment from Alice to Bob is:
Commitment state 2 is:
Strictly speaking, Alice could use re-use the previous revocation hash to construct CTx2. That’s because Alice only needs Bob to revoke an old CTx if her balance in the new CTx has increased. She doesn’t need to revoke CTx1 (which gives her 0.99 BTC) since she’d be perfectly happy for Bob to broadcast CTx1 instead of CTx2 (which gives her 0.98 BTC).
However, we’re not going to use that optimization. It makes things simpler just to use a new revocation secret for each new CTx. The sha-tree described in section 5.2 means that additional revocation secrets are cheap to generate and store, so the slight additional overhead in using unnecessary revocation hashes is acceptable for keeping the protocol simple.
Bob now wants to pay Alice 0.01 BTC and reduce his balance in the channel back to 0.01 BTC. Bob sends a request to Alice to create a new CTx with the new channel balances. Alice then constructs and signs CTx3 using h(rev3) and sends it to Bob. As before, Bob revokes the previous transaction and provides Alice with a new revocation hash.
The message exchange for Bob’s channel payment to Alice is:
Commitment state 3 is:
Two-way payment channel can be closed either unilaterally by Bob or co-operatively. As with a simple payment channel, Alice also has the option to close the channel using the refund branch if Bob disappears.
Bob can close the channel at any point by signing and broadcasting the most recent CTx. Once the CTx is broadcast, he must then wait for the rTXO timeout duration before he’s able to spend his output from the CTx.
The message exchange diagram below shows Bob unilaterally closing the channel after commitment state 3. Note that Alice has access to her funds as soon as Bob broadcasts the CTx, but Bob must wait for the revocation timeout delay.
Bob may not want to wait for an rTXO timeout duration before spending his funds. If Alice is acting co-operatively, they can work together so he can get his funds as soon as the channel closes. The protocol for doing that is as follows:
The message exchange diagram below shows Alice and Bob acting co-operatively to close the channel. Note that Alice and Bob both have access to the funds from the CTx immediately.
Once Alice has constructed and signed an unrevocable CTx, she should consider the channel closed and not sign any further CTxs. If Bob doesn’t broadcast it to the network, Alice must close the channel unilaterally and should not sign any more commitment transactions. That’s because if she continues to use the channel and constructs a future CTx with a lower balance for Bob, she’d have no way to revoke the unrevocable CTx and Bob could steal funds by broadcasting an old CTx.
If the channel expiry time passes, Alice can close the channel using a refund transaction, in exactly the same way as for a simple channel.
So far we’ve seen how to construct one-way and two-way payment channels. However, we’re still limited by the channel expiry duration, which is determined by the relative locktime on Alice’s refund branch. This means that our payment channels can only be open for a limited period of time before the channel has to be closed by Bob.
Next we’ll look at how to construct a payment channel that can stay open indefinitely.
Payment channels have two branches. So far, the payment channels we’ve seen have a spend branch for Bob and a refund branch for Alice. The refund branch is required to prevent Alice’s funds from being stranded (Alice’s escape clause), and needs to have a relative timelock to prevent Alice from prematurely claiming (ie stealing) all the funds in the channel (Bob’s safeguard clause).
If we construct the channel in such a way that instead of having a refund branch, Alice has her own spend branch, then the channel doesn’t need an expiry time. Either party can unilaterally close the channel at any time, which means they both have an escape route. Alice’s spend branch is an exact mirror of Bob’s.
These mirrored symmetric commitment transactions require the balance in one commitement transaction to go down when the balance in its mirror commitment transaction goes up. For that reason, we can’t have symmetric commitment transactions for a simple channel since balances in simple channels can only go one way. However, using revocable transactions we can create symmetric commitment transactions where the balance in one commitment transaction decreases as the balance in the other commitment transaction increases.
Under this scheme Alice signs CTxA and sends it to Bob, and Bob signs CTxB and sends it to Alice.
The anchor transaction for a symmetric payment channel is simply a 2-of-2 multisig transaction. Alice’s branch is no longer a refund branch, but a mirror of Bob’s spend branch, so the anchor transaction TXO doesn’t need a refund branch for Alice with a relative locktime. All CTxs in the channel are the same as for the two-way channel, but are constructed as pairs - CTxA is constructed and signed by Alice and CTxB is constructed and signed by Bob.
Alice needs to be a bit careful in opening the payment channel. If she just pays into a multisig address and Bob disappears, then her funds would be stranded. Therefore, the sequence for opening a symmetric transaction is as follows:
Commitment state 1 is as follows:
We’re now in a commitment state. Either party is able to close the channel unilaterally and (after the revocation timeout) claim their full balance.
If Alice wants to pay Bob in the channel, she needs to transition the channel to a new commitment state with an increased balance for Bob. She does this as follows:
Commitment state 2 is as follows:
If Bob wants to pay Alice in the channel, the protocol proceeds exactly as above, except that the roles are reversed (ie Bob starts by constructing a new CTxB and sending it to Alice).
In any commitment state, both parties hold a valid CTx. Either party can close out the channel by broadcasting the CTx, and then claim their funds after waiting for the revocation timeout duration.
This is exactly the same message exchange and protocol as closing a two-way channel unilaterally. The only difference is in a two-way channel only Bob could close the channel unilaterally, whereas in a symmetrical channel either party can close the channel unilaterally.
If both parties agree that they want to close the channel, they can do so co-operatively and have access to their funds immediately without having to wait for the revocation timeout delay. The message exchange protocol for closing the channel co-operatively is exactly the same as in the earlier two-way channel case. Again, the only difference is that both Alice can propose to close the channel co-operatively since the channel is entirely symmetrical.
As in the two-way channel, if one of the parties constructs and sends an unrevocable closing transaction but the other doesn’t broadcast it to the network, the party that has constructed the closing transaction must close the channel unilaterally and should not sign any more commitment transactions.
Many people have contributed ideas to the concept of bitcoin payment channels. The list below aims to identify ideas that have been particularly important in that development. There’s no doubt that I’ll fail to acknowledge everyone. Please contact @jonnynewbs or raise a ticket against the github repo if you believe there to be any egregious omissions.