Payment channels

A Micropayment Channel or Payment Channel is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.

Several channel designs have been proposed or implemented over the years. This article describes some of them.

Concept

Nakamoto high-frequency transactions

Implemented in Bitcoin 0.1 were features such as transaction replacement, input sequence numbers (nSequence), and nLockTime that would allow two or more parties to repeatedly update the state of an unconfirmed transaction prior to it becoming confirmed.

Satoshi Nakamoto described the technique to a Bitcoin developer in a personal email:

This design was not secure: one party could collude with a miner to commit a non-final version of the transaction, possibly stealing funds from the other party or parties.

Spillman-style payment channels

Discussed on the bitcoin-development mailing list and implemented in BitcoinJ, this one transaction to create a secured deposit and a second transaction to release the deposit funds in the manner agreed to by both parties, preventing miners from being able to commit a non-final version of the transaction. However, opening a channel in the Spillman model exposed the depositor to malleability risk where the counter party would be able to hold the depositor’s funds hostage.

CLTV-style payment channels

Were made possible in Decemember 2015 by the activation of the CLTV soft fork after discussion that began in the #bitcoin-wizards IRC channel, moved to the bitcoin-development and bitcoin-dev mailing lists, and included a design specification in BIP65. Channels constructed using the new OP_CLTV opcode were resistant to the malleability problem inherient in the Spillman-style construction.

Hashed Time-Locked Contracts (HTLCs)

Full article: Hashed Timelock Contracts

A technique that can allow payments to be securely routed across multiple payment channels. For example, if Alice has a channel open to Bob and Bob has a channel open to Charlie, Alice can use a HTLC to pay Charlie through Bob without any risk of Bob stealing the payment in transit. HTLCs are integral to the design of more advanced payment channels such as those used by the Lightning Network.

Poon-Dryja payment channels

Poon-Dryja payment channels were presented in the paper that also introduced the Lightning Network. Channel backing funds are locked into a 2-of-2 multisig, but before the funding transaction is even signed, commitment transactions for each party are first written and signed. As it requires referring to transactions that have not been signed yet, it requires using a transaction format that separates signatures from the part of the transaction that is hashed to generate the txid, such as Segregated Witness.

Poon-Dryja channels may be closed unilaterally (requires the participation of only one party) or bilaterally (requires the participation of both parties). When closed bilaterally Poon-Dryja channels are indistinguishable on-chain from 2-of-2 multisig address spends. When closed unilaterally, the funds of the party that closed the channel is temporarily timelocked; this allows the other party to dispute the state transmitted by the closing party (who might have given old state on closing).

Poon-Dryja payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The Lightning BOLT specifications include recommended implementation of Poon-Dryja payment channels.

Decker-Wattenhofer duplex payment channels

Duplex payment channels were presented in a paper by Christian Decker and Roger Wattenhofer. This type of payment channel requires the new BIP68 meaning of nSequence. As the name implies, a duplex payment channel is composed of two unidirectional payment channels, one in both directions. The unidirectional payment channels are essentially Spillman channels, but using relative lock time (nSequence) instead of nLockTime.

However, instead of funding unidirectional payment channels directly from an on-chain funding transaction, there is an “invalidation tree” of off-chain transactions between the funding transaction and the payment channel finalization transactions. The invalidation tree transactions also use relative lock time; the first version of the transaction has a large relative lock time, and the next version of the transaction (which invalidates the first) uses a slightly smaller relative lock time, and so on. There is also a “kick-off” transaction that starts the timeout for the relative locktime. The sequence of transactions is thus: funding -> kickoff -> invalidation tree -> payment channel.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

The invalidation tree structure may actually have more than two participants; it would be possible for groups of 3 or more parties to build multiple payment channels between them that are backed by this invalidation tree structure, and to rebalance their payment channels without hitting the blockchain. It would also be possible for the invalidation tree structure to fund Poon-Dryja rather than pairs of unidirectional payment channels.