jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-17 📝 Original message: TL;DR ===== * Dynamic ...
📅 Original date posted:2023-03-17
📝 Original message:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230318/2dfda9d8/attachment-0001.html>;
📝 Original message:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230318/2dfda9d8/attachment-0001.html>;