How many transactions will be created in a Lightning Network channel

Question

In a typical Lightning Network channel, how many Bitcoin transactions will be created per state of the channel that may end up on-chain ?

Answer 1

The number of transaction per Lightning Network channel may change depending on two main factors:

• The type of channel used.
  As a protocol in development, the Lightning Network specifications may change. This includes the specification of the transactions used for each channel state. For instance, the "Anchor Outputs" proposal which was merged in 2020 included a complete rewrite of the transaction tree.
• The number of payments being currently routed through the channel (HTLCs in flight).

The following description is for a non-"anchor outputs" channel.

Without any in-flight HTLC

The channel begins with:

• The funding transaction (onchain)
• Two commitment transactions (one for each participant)

So we are at 3 transactions. But there is a quirk (there is always a quirk!), each of the transaction pays to:

1. The remote party
2. The local party after a delay OR the remote party with the revocation key.

Since i want the count to showcase the complexity of the client implementation, i'm going to include the special transactions in the counter.
Note that the specifications call the "simple outputs" (basic P2WPKH, as an onchain payment) as being resolved, and the "contract outputs"[*] to not be resolved until a "special transaction" spending it is confirmed.

It therefore brings us to 7 transactions:

• 1 revocation transaction per party
• 1 delayed transaction per party

Now, let's add some real complexity.

Adding the HTLCs

Lightning Network channels are bi-directional, therefore both parties can offer or receive an HTLC. Intuitively.. HTLCs are translated into outputs than can be in both these states (offered or received) in both the commitment transactions.

So you can have:

• An HTLC offered by the local party
• An HTLC received by the local party
• An HTLC offered by the remote party
• An HTLC received by the remote party

As well as any combination of the above.

For an HTLC offered by the local party, an "offered-htlc" output is added to the local party's commitment transaction and a "received-htlc" output is added to the remote party's commitment transaction. Each of these outputs are the first stage of the onchain HTLC resolution, they are later finalized in a second-stage pre-signed "HTLC transaction", and finally sweeped by a "special transaction" (the same kind as those in the first section: delayed or revocation).

An offered HTLC output in the local party's commitment transaction may be spent by:

• A "preimage transaction" (to the remote party -- ie "successful-but-quite-long payment")
• A revocation transaction (to the remote party -- you need to prevent cheating at each step of the process)
• A pre-signed "timeout transaction" which may then be spent by either:
  • A delayed transaction (to the local party -- ie "cancelled payment")
  • A revocation transaction (to the remote party -- we can still cheat at this point!)

A received HTLC output in the local party's commitment transaction may be spent by:

• A timeout transaction (to the local party -- that's the cltv_delta configuration on your node)
• A revocation transaction (to the remote party -- as usual)
• A pre-signed "success transaction", which may then be spent by either:
  • A delayed transaction (to the local party -- ie "successful-but-quite-long payment")
  • A revocation transaction (to the remote party, -- still to decincentivize cheating)

This brings us to 10 new transactions per commitment transaction for two HTLCs in flight (one in both direction).

Summing it up

For the example i've showcased above it brings us to:

7 # Nuked channel
+ 10 # htlc offered on one side, received on the other one
+ 10 # htlc received on one side, offered on the other one
= 27

That's for one channel state (the next one will use new keys!) for the common scenario of being currently forwarding a payment in both directions.

To answer your question precisely, the number of transactions per state may vary between 7 (no HTLC) and 7 + 483 * 5 * 2 = 4837 (maximum number of HTLCs in both directions). Note that the latter is unrealistic as the maximum number of in-flight HTLCs is currently bounded on implementations in order to avoid DOS.

---

More resources:

• The BOLTs if you want all the nitty-gritty details: #5 (onchain) and #3 (transactions) cover this.
• This post by Rusty Russell -- outdated but still gives the intuition. Touchs also the challenge of managing the keys.

---

[*] Terminology mine on this one

Answer 2

Yes, however, this created infrastructure you reference has the capacity to support many transactions on LND before the channel is closed, reducing the overall number of transactions on the blockchain probably significantly.