TL;DR
=====
* Dynamic management of Lightning channel capacity is required to support
efficient Lightning Network (LN) payments
- On-chain resizing introduces delays, adds costs and limits scalability
- Fast and cheap resizing may be required to support watchtower-free LN
payments for casual users
- Channel factories allow off-chain channel resizing, but only by exchanging
capacity within a single factory
* Hierarchical channels allow flexible, off-chain resizing of channels
- They don't require an exchange of capacity within a limited pool of users
- They also support watchtower-free casual users without stranding any
channel capacity
* Hierarchical channels do for channel capacity what the LN does for bitcoin
* No change to the underlying Bitcoin protocol is required
Overview
========
The ability to move Lightning channel capacity to where it's most needed is
central to the efficient operation of the LN.
In fact, it's been stated that the "main (probably only) job of" a dedicated
Lightning user "is to efficiently allocate their liquidity" [10].
The use of on-chain transactions to resize channels limits the LN's scalability
and increases its fees.
In addition, resizing channels on-chain can introduce substantial delays.
In fact, delays of multiple months are possible in the case of a casual user
who operates in a watchtower-free manner [3], thus stranding capital and
potentially preventing such users from operating in a watchtower-free manner in
the current environment [10].
Existing proposals for resizing channels off-chain consist of creating a
channel factory [1] or CoinPool [7] and exchanging capacity between channels
within the same factory or pool.
However, only a very small fraction of the LN's channels can be expected to be
in a single factory or pool [8], so the ability to match channels that have
insufficient capacity with channels that have excess capacity is highly
constrained.
This post uses hierarchical Lightning channels to solve two problems.
First, as long as Lightning channels are created within hierarchical channels,
it's possible to resize them flexibly, nearly instantly and off-chain.
Thus, hierarchical channels do for channel capacity what Lightning does for
bitcoin.
In fact, this is more than just an analogy, as the channel capacity is actually
transferred over the LN.
Second, hierarchical channels can be created by a casual user and a pair of
dedicated users such that the casual user can send and receive bitcoin in a
watchtower-free manner, while the dedicated users can use all of their channel
capacity to route payments even while the casual user is inactive.
As a result, casual users can operate in a watchtower-free manner without
stranding any capital.
The remainder of this post describes hierarchical channels and how to use them.
A more complete description, including figures, is available in a paper [6].
Hierarchical Channels
=====================
A *party* is a group of one or more users.
A *hierarchical channel* is a 2-party channel that has two main outputs, one
per party, plus zero or more HTLC outputs.
Each output from a hierarchical channel that pays to a multi-user party funds
another (potentially hierarchical) channel.
As a result, each output in a hierarchical channel (including an HTLC output
once it has been resolved) can be viewed as the root of an off-chain tree of
outputs where the leaves are owned by single users.
In order to update a hierarchical channel, funds are offered by one party to
the other party in an HTLC.
One user within the party offering the HTLC is designated as the *payer* and
one user within the party offered the HTLC is designated as the *payee*.
All of the funds for the HTLC are provided by the payer, and if the HTLC
succeeds, the bulk of the funds go to the payee (but users within the offered
party other than the payee can also get routing fees).
Before the channel state is updated to include a new HTLC output, all of the
users in the channel sign new transactions that spend the new channel state's
main outputs, its existing HTLC outputs, and the new HTLC output.
The users then sign transactions that implement the new channel state
(including the new HTLC output) and revoke the previous channel state.
Once the HTLC is resolved, the channel state is updated to include the HTLC's
funds in the offered party's main output (if the HTLC succeeded) or in the
offering party's main output (if the HTLC failed).
Because the two parties within a hierarchical channel can use an HTLC to
exchange bitcoin, they can link their HTLC to HTLCs in other (potentially
hierarchical) channels, thus making payments over the LN.
In particular, each party in a (potentially hierarchical) channel appears as a
node in the LN channel graph and each (potentially hierarchical) channel
appears as a pair of unidirectional edges linking the channel's two parties.
As in the current LN, a payment consists of a path where the node that's
offered an HTLC in one hop offers an HTLC in the next hop (and the user that is
the payee in one hop is the payer in the next hop).
Resizing Routing Channels Off-Chain
===================================
Dedicated users who provide routing services to others can use hierarchical
channels to resize their Lightning channels off-chain.
For example, consider dedicated users A, B, C and D who create a hierarchical
channel with parties AB and CD.
This hierarchical channel's main outputs fund the (non-hierarchical) channels
owned by AB and by CD.
Also, assume that party CD has a separate hierarchical channel with
(single-user) party E.
If AB wants to reduce the capacity of their (non-hierarchical) channel, they
can create a payment through the LN from party AB (with user A being the payer)
to party (and user) A consisting of the path AB -> CD -> E -> F -> G -> A.
Because this payment is from party AB within the hierarchical channel owned by
parties AB and CD, this payment reduces the value of the main output that pays
to AB from this hierarchical channel.
Furthermore, because the (non-hierarchical) channel owned by A and B is funded
by the main output that pays to AB from that hierarchical channel, this payment
reduces the size of the channel owned by A and B.
Finally, because this payment is paid by A (as the payer within the offering
party AB at the payment's first hop) and pays to A (as the payment's
destination), user A neither gains nor loses funds (except for paying routing
fees to users C, D, E, F and G).
Furthermore, as in any LN payment, each routing node that gains funds in one
hop loses an identical (minus fees) amount of funds in the next hop, so their
overall balance is unchanged (except for a slight increase due to fees).
There's nothing new about this for routing nodes E, F and G, as they act as
they do in the current LN.
However, it's worth looking in more detail at routing node CD, as the existence
of multi-user nodes in the LN is new with hierarchical channels.
Like any routing node, CD gains funds in the hierarchical channel with AB and
loses an identical (minus fees) amount of funds in the hierarchical channel
with E.
Note that C and D also appear as nodes within the LN channel graph, the channel
between C and D that's funded by the hierarchical channel with AB appears as a
pair of unidirectional edges between C and D, and the channel between C and D
that's funded by the hierarchical channel with E appears as a pair of
unidirectional edges between C and D.
Thus, the sum of the capacities of the two channels between C and D is
unchanged, except for a slight increase due to fees.
The effects of this payment from AB to A on a portion of the LN channel graph
are shown below.
Each party appears as a box and each channel appears as a pair of directed
edges between a pair of parties.
The channel's capacity is shown between the pair of directed edges, and each
party's balance appears either above or below the pair of edges.
200
PHYSICAL CHANNELS +--+ -> +--+
BEFORE AB -> A PAYMENT |C | 500 |D |
OF 100 UNITS PLUS FEES | | <- | |
| | 300 | |
| | | |
800 800 400 200 500 500 | | 700 | |
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ | | -> | |
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 800 |B | | | 800 | |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
500 200 600 200 200 300 100
308
PHYSICAL CHANNELS +--+ -> +--+
AFTER AB -> A PAYMENT |C | 609 |D |
OF 100 UNITS PLUS FEES | | <- | |
| | 301 | |
| | | |
691 694 296 98 400 391 | | 594 | |
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ | | -> | |
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 691 |B | | | 694 | |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
609 306 704 302 300 300 100
Logical vs. Physical Channels
=============================
Because there are two separate channels between C and D (one funded by the
hierarchical channel with AB and the other funded by the hierarchical channel
with E), it's natural to express these channels as two separate pairs of edges
between C and D (as is shown above).
However, a better viewpoint is obtained by logically merging the two physical
channels between C and D into a single logical channel containing the sum of
the capacities of the two physical channels.
In fact, a large payment can be routed between C and D by using parallel HTLCs
in the two physical channels connecting them.
In addition, when logical (rather than physical) channels are advertised to LN
peers, the resulting channel capacities are much more stable, as they don't
change (other than increasing due to fees) when the parties owning the channel
are used to route a payment.
For example, in the payment shown above the capacity of the channel between A
and B is decreased by the amount of the payment from AB to A (plus fees), and
the capacity of all other logical channels (including the one between C and D)
is unchanged (other than increases due to fees).
LOGICAL CHANNELS
BEFORE AB -> A PAYMENT
OF 100 UNITS PLUS FEES
800 800 400 200 500 500 900
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ +--+ -> +--+
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 800 |B | |C |1300 |D |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
500 200 600 200 200 300 400
LOGICAL CHANNELS
AFTER AB -> A PAYMENT
OF 100 UNITS PLUS FEES
691 694 296 98 400 391 902
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ +--+ -> +--+
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 691 |B | |C |1303 |D |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
609 306 704 302 300 300 401
Of course, the example given above could be reversed (by making a payment from
A to AB) in order to increase the capacity of the channel between A and B
off-chain.
Supporting Casual Users Without Stranding Capacity
==================================================
Hierarchical channels can also be used to support watchtower-free casual users
without stranding any channel capacity.
Consider a watchtower-free casual user A who creates a hierarchical channel
with dedicated users B and C, where A is one party and BC is the other party in
the channel.
Assume A wants to make a payment to G, and that party BC has a separate
hierarchical channel with user D, D has a channel with E, E has a channel with
F, and F has a channel with G.
In this case, A can create a payment through the LN consisting of the path A ->
BC -> D -> E -> F -> G.
Of course, this example could be reversed in order to make a payment from G to
casual user A.
The key observation is that whenever A is neither sending nor receiving a
payment, dedicated users B and C can utilize all of the capacity in the channel
between them to route LN payments.
Also, note that as long as B and C advertise their two physical channels
(namely the one funded by the hierarchical channel shared with A and the one
funded by the hierarchical channel shared with D) as a single logical channel,
the capacity of the logical channel is unchanged (other than in increase due to
fees) when B and C route payments to and from A.
Protocols For Hierarchical Channels
===================================
Several issues have to be addressed in order to create a protocol for
hierarchical channels.
First, each main output (or resolved HTLC output) from a hierarchical channel
must be able to pay to a tree of transactions that distribute the output's
funds to individual users at the leaves.
This can be achieved by requiring the users in the hierarchical channel to
exchange signatures for the tree of transactions that spend each output of a
given Commitment transaction prior to signing that Commitment transaction.
Second, a Lightning channel is currently announced with a channel_announcement
message that references the on-chain UTXO funding the channel and the channel's
capacity is static.
These channel_announcement messages won't work for hierarchical channels that
are funded by off-chain UTXOs and have dynamic capacities.
Russell's proposal [9] for channel_update_v2 messages is well-suited to
hierarchical channels as it merges the concepts of channel announcements and
channel updates and it includes the channel's capacity, thus supporting dynamic
capacities.
In addition, it supports channels that are funded off-chain by allowing
on-chain UTXOs to be cited when announcing channels with capacities that are at
most a fixed multiple of the on-chain UTXOs' value.
Third, hierarchical channels need to support more than two users per channel.
The current Lightning channel protocol only works for 2-user channels, as it
penalizes a user that puts an old Commitment transaction on-chain by allowing
the other user to obtain all of the channel's funds.
Such an approach doesn't work if there are more than two users in the channel,
where at least two are dishonest.
In such a case, a dishonest user could put an old Commitment transaction
on-chain and another dishonest user could "punish" that user by claiming all of
the channel funds, including those from the honest users.
Even if the dishonest users can't guarantee that they'll take the channel's
funds, the expected value obtained by dishonest behavior could exceed the
expected value from honest behavior.
In contrast, channel factory protocols are designed to allow more than two
users to update factory states off-chain, where each factory state consists of
a division of the factory's funds among the factory's users.
Therefore, if we define the hierarchical channel's state as consisting of its
two main outputs, plus any HTLC outputs, a channel factory protocol can be used
to update the channel's state off-chain.
In particular, the Invalidation Tree protocol [2], the Tunable-Penalty Factory
protocol [5] or the Single-Commitment Factory protocol [5] can be used.
Of these, the Tunable-Penalty Factory protocol appears most attractive, as it
requires only O(1) time and O(1) on-chain bytes for a unilateral close.
Finally, in addition to maintaining the channel's current set of outputs, each
HTLC output must be resolved according to the terms of its associated HTLC.
A simple approach, based on the current Lightning protocol, is to allow the
HTLC output to be spent by either:
* an HTLC-success transaction put on-chain by the payee and providing the
HTLC's required preimage, or
* an HTLC-timeout transaction put on-chain by any user within the offering
party after the HTLC's expiry.
This approach works, but it has two serious performance problems:
1) resolving an HTLC on-chain requires closing the hierarchical channel, and
2) the latency required for putting the HTLC output on-chain can significantly
delay the HTLC's expiry.
Fortunately, both of these performance challenges are solved by using separate
control transactions to resolve the HTCLs, as is done in the FFO and FFO-WF
channel protocols [4].
Specifically, the FFO protocol can be extended to resolve HTLCs in hierarchical
channels owned by more than two dedicated users, and the FFO-WF protocol can be
extended to resolve HTLCs in hierarchical channels with more than two users,
exactly one of whom is a casual user.
The details are given in the paper [6].
Conclusions
===========
Sending bitcoin between users can be performed on-chain.
However, allocating bitcoin to a Lightning channel allows it to be sent
off-chain nearly instantly, with much lower fees, and in a far more scalable
manner.
Similarly, Lightning channel capacity can be moved to where it's needed
on-chain.
However, allocating Lighting channel capacity within a hierarchical channel
allows the channel to be resized off-chain nearly instantly, with much lower
fees, and in a far more scalable manner.
In addition, hierarchical channels can be used to support watchtower-free
casual users without stranding any Lightning channel capacity.
As a result, providing watchtower-freedom to casual users appears to be
cost-effective.
Given that these results can be achieved without making changes to the
underlying Bitcoin protocol, it's hoped that hierarchical channels will
eventually be adopted in BOLTs and implemented in order to improve the
scalability, efficiency, and usability of the Lightning network.
Regards,
John
[1] Burchert, Decker and Wattenhofer, http://dx.doi.org/10.1098/rsos.180089
[2] Decker and Wattenhofer,
https://tik-old.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
[3] Law, https://github.com/JohnLaw2/ln-watchtower-free
[4] Law, https://github.com/JohnLaw2/ln-factory-optimized
[5] Law, https://github.com/JohnLaw2/ln-efficient-factories
[6] Law, https://github.com/JohnLaw2/ln-hierarchical-channels
[7] Naumenko and Riard, https://coinpool.dev/
[8] Riard,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020370.html
[9] Russell,
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html
[10] Teinturier,
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003712.html
Sent with [Proton Mail](https://proton.me/) secure email._______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
