Lightning Network: Establishing direct payment channels

In the lightning network, payment channels define a financial relationship between network-connected peers, within which peers can make multiple fast, cheap, and private off-chain payments, by distributing the funds from a 2-of-2 multisignature address constructed with the public keys of the channel peers. Visually, a payment channel can be thought of as a link/edge between two nodes/vertices. I learned to visualize payment channels as the strings on an abacus where micro-payments between peers Bob and Alice could be made by sliding millisats along.

Figure 1: Lightning: Micropayments on a string

The creation of payment channels is foundational to the lightning network, underpinning the ability of connected nodes to make off-chain payments. Establishing these channels involves six (6) message exchanges between prospective peers to set channel capabilities, create funding and refund transactions, and enter channel operations of forwarding payments. In this article, I will briefly explain each one of these messages with a particular focus on funding & refund transactions.

Part I: Setting channel capabilities

Prospective channel peers who would like to make millisat payments with each other start the process of creating a payment channel by sending two messages: open_channel where the initiator communicates their channel expectations, and accept_channel where the recipient accepts the proposed channel.

1. Requesting to open a channel

In the former, information regarding how much the channel will be funded with, the minimum channel balance, the time a peer needs to wait before claiming their funds in unilateral channel closing, the public key of the initiator, among others.

2. Accepting proposed channel

If the proposed channel expectations are found acceptable, the recipient responds with the latter message, providing their public keys also, alongside other information. The public keys of both the initiator and the recipient are needed to construct a 2-of-2 multisignature address for the funding transaction.

Part II: Creating funding and refund transactions

Having established a willingness to operate a channel between themselves, the initiating channel peer will do the following, in order:

• create a transaction payable to multisignature address constructed from both their public keys,
• create a funding transaction without broadcasting the said transaction,
• create a refund transaction chained with the funding transaction’s outpoint,
• send a funding_created message to the recipient channel peer with the funding transaction’s ID and output index.

The recipient channel partner will, upon receiving the message from the initiator:

• create and sign their version of the refund transaction
• send a funding_signed message to the initiator

With both signatures, the funding transaction can be broadcast and confirmed for channel operations to commence. This section will look a the creation of multisignature addresses, and the creation of funding and refund transactions.

1. Multisignature Address Generation

Consider the scenario where some entity created a *p2wpkh* transaction paying Alice 200,000 sats as depicted below. If Alice can provide a witness script structured in the same format as the witness script of Tx0P that redeems the UTXOs in Tx0Q:3, then Alice can spend the amount contained in Tx0P:0 by providing a valid signature and a public key whose hash produces the same 20-byte hash contained in the transaction output.

Figure 2: A p2wpkh transaction payable to Alice

Note:

• The hash contained in the locking script is hash160, i.e. SHA256 + RIPEMD.

With the function below, the serialized locking script *s* is doubly hashed to produce a 32-byte hash.

Alice (iniitaiting channel partner) can create a p2wsh multisignature address by doing the following:

• Create a multisignature witness/redeem script with both hers and Bob’s public keys. Take note that the ordering of public keys presented here is just for depiction and not as is done in practice. Ideally, the ordering is done lexicographically.
• Hash the script to get a 32-byte hash

Figure 3: Hashing witness script to generate a p2wsh public key script

2. Funding transaction

With the multisignature hash address, Alice can construct a funding transaction that pays say 140,000 sats to Bob (recipient channel partner). A visualization of the transaction is shown. Here Alice spends from a single input and pays to two addresses. The first is the payment to the multisignature address, and the second is change back to her.

Figure 4: Creating a p2wsh funding transaction object (Tx01)

This transaction (Tx01) is not broadcast to the network by Alice but withheld. This withholding is done because Alice does not have the second quorum (Bob’s signature) to unlock the transaction if it is mined, without which she essentially has thrown money away if Bob withholds his signature. To get this signature, Alice has to send Bob a funding_created message, but not before creating a refund transaction that spends the UTXOs locked to the multisignature address, payable to herself.

3. Refund transaction

With the funding transaction created, Alice gets to create a p2wpkh refund transaction that pays the UTXOs locked in the 2-of-2 multisignature address to herself. As much as the funding transaction has not been broadcast, Alice can trust that the transaction’s ID will remain unchanged so that when it is eventually relayed to the network and mined, there is no malleability vector to worry about (thanks to segwit). When it is relayed and mined, Alice also needs Bob’s signature to spend the UTXO.

Figure 5: Creating a p2wpkh refund transaction (Tx02)

To get the needed signature, Alice sends a funding_created message to Bob letting him know about the funding outpoint. Bob creates and signs his version of the refund transaction and lets Alice know by sending a funding_signed message containing the signature corresponding to his public key used in creating the 2-of-2 multisignature address.

With both signatures, Alice has enough information to broadcast the funding transaction to the bitcoin network without fear of losing her money. She has the signatures needed in the witness script as shown in the rightmost transaction (see Figure 5) to recover all her money.

Having broadcast and confirmed the transaction, both channel partners share a funding_locked message that signals the readiness of the channel for operations (sending payments) between the peers.

Conclusion

In this article I looked at the messages prospective channel partners must share before a payment channel between them can be established using some diagrams that helped me visualize the processes better. Prospective peers must agree on the channel capabilities, the initiator must create funding and refund transaction and inform the other partner about this, sending enough information for the partner to create and sign their copy of the refund transaction, sharing the signature needed to refund the initiator if something goes wrong.

Contact me

I would deeply appreciate any feedback you can provide. If you found this article helpful/useful or found factual misrepresentation, please do not hesitate to comment or contact me here or on Twitter @engb_os.

References

1. Song, J. (2019). Programming bitcoin: Learn how to program bitcoin from scratch
2. Rosenbaum, K. (2019). Grokking Bitcoin
3. Antonopoulos Andreas, Osuntokun Olaoluwa, & Pickhardt René. (2021). Mastering the lightning network: A second layer blockchain protocol for instant bitcoin payments