In a typical Lightning Network channel, how many Bitcoin transactions will be created per state of the channel that may end up on-chain ?
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:
- The remote party
- 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
1revocation transaction per party
1delayed 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_deltaconfiguration 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.
- 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