Lightning Payment Channels

Payment channel image by https://happypeter.github.io/

Payment channels are the backbone of the Lightning Network as they enable the sending and receiving of off-chain payments.

What Is A Payment channel?

A payment channel is a trustless duplex financial relationship between two nodes on the Lightning Network, implemented by multi-signature Bitcoin transactions that share control over the bitcoins in the channel between the two Lightning nodes.

Payment channels are constructed by sending bitcoins to a 2-of-2 multisig address, with both channel partners as signers in the multisig.

When you choose to open a channel, one or both users agree to send some bitcoins to the 2-of-2 multisig address. Once the transaction is mined the bitcoins in the multisig can’t be spent without cooperation from your channel partner, because their signature is also required to spend the coins.

Note: payment channels can be funded by one of the two channel partners, or dual-funded by both peers, but single-funded channels are more popular at the moment. Dual-funded channels have been implemented only by Core Lightning (formerly known as C-Lightning), If you want to open a dual-funded channel you have to use a Core Lightning node.

How Is A Payment Channel Created?

To start transacting on the Lightning Network, a payment channel needs to be opened or users can also use a service that has an already open channel in a custodial manner. Either way, there has to be an open payment channel before sending and receiving Lightning payments is possible.

To open a payment channel both peers have to be connected, if the counterparties are not already connected, the channel initiator should connect to the counterparty using their public key, server URL or IP address, and port number.

Connection string example

02fea0a032d365dfabe00347bad493281172fcf30564f40b8a45da6bc176349a67@localhost:9735

After the connection is made the initiating node sends an open channel message to the other peer. If the peer accepts to open a channel with the initiating node, the initiating node prepares a funding transaction.

A funding transaction is a transaction sending coins to a 2-of-2 multi-signature address that consists of the public keys of both the channel peers. Bitcoins sent will be locked to the multi-signature address and require both the signatures of the channel peers to unlock the funds in the future. The channel initiator then sends the funding transaction to his peer to sign and also creates a refund transaction before broadcasting the funding on-chain to open the channel.

A refund transaction is the first commitment transaction created by the channel that serves as a guarantee to the channel creator that his funds can’t be stolen by the other peer. The refunding transaction spends the output of the funding transaction that hasn’t been published yet, this is possible because the transaction ID of the funding transaction is not malleable thanks to Segwit.

After the refund transaction is created successfully the channel initiator broadcasts the funding transaction on-chain, then waits for an agreed-upon number of confirmations. After confirmation the channel is open and the channel peers can optionally gossip about the existence of the channel to the wider network.

Commitment transaction

Commitment transactions are a series of off-chain Bitcoin transactions that update the state of the Lightning payment channel balances according to how the channel partners distribute the channel capacity amongst themselves.

The commitment transaction also includes additional outputs for in-flight payment attempts in the form of hash time-locked contracts (HTLCs).

The commitment transactions also rely on Bitcoin’s ability to curb double-spending, so only one valid commitment transaction will be able to spend the funds in the 2–2 multisig address created by the funding transaction when broadcasted on-chain.

Each time a payment is made through the channel an updated version of the commitment transaction is created and signed by both parties. This commitment transaction reflects the updated balance of the channel taking into consideration the new payment and is a valid on-chain transaction, although we hope that we never need to broadcast it on-chain (see the channel closing section).

Creating A Payment Channel with LND

To open a channel on LND, you have to connect with the peer node if not connected.

$ lncli connect 02fea0a032d365dfabe00347bad493281172fcf30564f40b8a45da6bc176349a67@localhost:9735

Then you can open a channel using the open channel command with the public key of the node you want to connect with as a second argument, and the amount in satoshi you want to use in opening the channel as the third argument.

$ lncli openchannel 02fea0a032d365dfabe00347bad493281172fcf30564f40b8a45da6bc176349a67 100000

To list all your open channels using LND you can use the listchannels command

$ lncli listchannels
{
    "channels": [
        {
            "active": true,
            "remote_pubkey": "026721a3077374a439d21d71987e63d8c111ea80272f37656580990757886765da",
            "channel_point": "a28e4fda3d21fb681ffeb2cc72ff84e5cfc60e30674d3b8df0ce1eec62087773:0",
            "chan_id": "131941395398656",
            "capacity": "500000",
            "local_balance": "600",
            "remote_balance": "490350",
            "commit_fee": "9050",
            "commit_weight": "724",
            "fee_per_kw": "12500",
            "unsettled_balance": "0",
            "total_satoshis_sent": "0",
            "total_satoshis_received": "600",
            "num_updates": "12",
            "pending_htlcs": [
            ],
            "csv_delay": 144,
            "private": false
        }
    ]
}

Closing A Payment Channel

A payment channel can either be closed cooperatively, force closed or closed with the penalty transaction.

Cooperative closing

Cooperatively closing is the best way to close a payment channel. To carry out a cooperative close both of the channel partners negotiate a final version of the commitment transaction called the closing transaction that pays each party their balance immediately to the destination wallet of their choice. Then, the partner that initiated the channel closing flow will broadcast the closing transaction.

When a payment channel is not cooperatively closed (force close), it may reveal unresolved outputs on-chain that are specific to Lightning, these additional outputs lead to more cost in fees.

Also, the person who initiated the closed must wait longer for the timeout before they can spend from the force close transaction (this timeout allows the other party to check for fraud and issue a penalty transaction if necessary).

Force closing

You can choose to force close a channel if your channel counterparty is unavailable and cannot participate in a cooperative close.

A force close (also called a unilateral close) is performed when either of the channel peers broadcasts a commitment transaction rather than negotiating a closing transaction.

A force close is accepted if the commitment transaction that is broadcasted is the latest agreed upon by the channel participants, if a revoked commitment transaction is broadcasted the force close is fraudulent and can be disputed by the other peer when they notice it, by providing the newest commitment transaction.

When a channel is forced closed both parties in the channel will receive their to_local amount differently, the party who initiates the force close will have to wait for a certain amount of time specified by the timelock, while their partner will receive their funds immediately. The delay provides their partner an opportunity to dispute the commitment transaction broadcasted, if the broadcaster broadcasted a revoked commitment transaction, the peer can challenge it with a penalty transaction.

The party who opened the channel will have to pay higher fees during a force close, if the channel is being closed by a peer who didn’t open the channel they may have to pay on-chain fees to abort or settle HTLCs.

The fees are higher because a commitment transaction includes additional outputs for pending HTLCs, which makes the commitment transaction larger (in terms of bytes) than a cooperative close transaction, and larger transactions result in higher fees.

Fraudulent Force Close

A channel can be closed when a channel partner decides to force close fraudulently, by broadcasting an old commitment transaction that does not represent the newest channel state agreed upon to cheat their channel partner, the cheating node will lose all their funds if the channel partner discovers they are trying to cheat.

If the force close with the wrong commitment transaction is detected by the channel partner, the partner will provide their revocation keys and claim all the channel funds, and close the channel with a penalty transaction that requires no timelock.

If the false close is not detected by the channel partner within the to_self_delay agreed upon when they opened the channel, the malicious peer will get away with the invalid close, and their channel partner may lose some of their funds.

Note: A fraudulent false close can also happen if a user’s node crashes and data is lost from the user’s database during the crash; if the user starts back up as normal and tries to use a commitment transaction that they believe is the current state, they could still end up being punished.

It can also happen if for example a hard drive disk is lost and the user can’t recover his lost data. Data Loss Protection (DLP) could be used to recover the channel’s current channel state by requesting it from the remote peer if the peer is honest. You can read about DLP here.

Conclusion

Payment channels are the building blocks for the Lightning Network, A Lightning node that doesn't have an open payment channel cannot pay or receive a Lightning payment.

Even when a Lightning user uses a custodial Lightning wallet without the user having a need to create a payment channel, behind the scenes the Lightning wallet provider has an open channel that enables their users to send and receive Lightning payments.

If you are an African developer and you are interested in transitioning into Bitcoin development, the Qala program is perfect for you, consider registering for the next Qala cohort.

Thank you.