Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
Replies inline: > > > One thing that confuses me about the paper is how to think about routing > > > to a "channel" rather than a node -- ie the payment from "E->FG->A" where > > > "FG" isn't "F" or "G", but "both of them". > > Yes, I found it very difficult to think about, and I kept getting confused > > between concepts like "user", "node", "channel", and "factory". > > The thing that works best for me is to create a clear definition of each of > > these terms, along with the term "party". > Okay, that makes sense. I think it might work better to treat "node" as > synonymous with "user" rather than "party" though -- that way you can say > "you create a lightning node by running lightning node software such as > lnd/cln/eclair/etc". That means not all vertices in the payment routing > network are nodes; but all vertices in the *gossip* network are nodes, > so that seems okay. Yes, it's probably best to refer to a user who runs lightning node software as being a "node". On the other hand, it sounds really awkward to talk about routing in a directed graph without using the word "node" in some form. Maybe "routing node" for entities in the routing network? > (I'm not sure "channel factories" is really the most evocative way of > describing them -- at least when I think of a factory, I think the product > should be accessible to everyone; but for channel factories you have to > be involved in the factory's original mutlisig to be able to use one of > its channels. Maybe better to call them "channel coops", where you're > creating a little commune of friends/allies to work together with each > other. Could be pronounced like "workers' co-op" or like "chicken coop", > either way :) Good point regarding "factories". I like "channel co-op" as an alternative. > > * Logical Channel: a layer 2 construct that consists of all of the physical > > channels owned by a specific pair of parties > > - the size (capacity) of a logical channel is the sum of the sizes of > > their physical channels > > - (Footnote: It's possible, with a significant amount of software > > development work that I in no way discount, to route a payment through a > > logical channel where the payment traverses multiple physical channels at > > the same time. This is done by using separate HTLCs, all sharing the same > > secret, in each of the physical channels that the payment traverses. I can > > write more about this if that would be helpful.) > I think it might already be interesting to write a BOLT/BLIP for that? > Having a single channel backed by multiple on-chain utxos is probably > interesting for splicing (adding or spending a utxo while keeping the > channel open on the other utxos might be able to be done more simply than > splicing in general), and having multiple utxos might let you increase > some of your channel limits, eg `max_accepted_htlcs` might be able to > be increased to 483*U where U is the number of UTXOs backing the channel. Sounds good. I'm glad to write something up, but I'm afraid it may take me a few months. > > > It feels like there's a whole > > > mass of complications hidden in there from a routing perspective; like how > > > do you link "FG" back with "F" and "G", how do you decide fees, how do > > > you communicate fees/max_htlc/etc. > > Regarding the specific issues you raised: > > Q: How do you link "FG" back with "F" and "G"? > > A: In terms of gossiping and the channel graph, you don't > Yeah, I think that simplifies things substantially. > I think the main thing that misled me here was the "CD->E->FG" payment > chain -- it doesn't make sense to me why E would want to devote funds > that can only be used for rebalancing channels, but not normal payments. Actually, E's funds in the channels ((C,D),E) and (E,(F,G)) can be used for normal payments. It might not seem attractive to do so, but there may be reasons for doing just that (see below). > Having that be CD->DE->FG seems like it would make much more sense in that > model. (Though, obviously, no one except D and E could necessarily tell > the difference between those two scenarios in practice, and just because > something doesn't make sense, doesn't mean nobody will actually do it) I included going from a single-user party to a multi-user party and back to a single-user party, as in E->FG->HI->A in Figure 4 in the paper, just to show the poassibility. I didn't think it would be common, given the extra signatures and fees required. However, I'm now thinking that routing through multi-user parties could be important in practice, even when making normal LN payments between single users. There's a lot more on that idea below. > The other thing was that going from N nodes to C*N channels, then > re-considering each of the C*N channels (A->B, etc) as also potentially > being nodes and adding an additional K*C*N channels (AB->CD, etc) seemed > like it might be quadratic to me. But it's probably not -- C (channels per >
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
On Tue, Apr 18, 2023 at 07:17:34PM +, jlspc wrote: > > One thing that confuses me about the paper is how to think about routing > > to a "channel" rather than a node -- ie the payment from "E->FG->A" where > > "FG" isn't "F" or "G", but "both of them". > Yes, I found it very difficult to think about, and I kept getting confused > between concepts like "user", "node", "channel", and "factory". > The thing that works best for me is to create a clear definition of each of > these terms, along with the term "party". Okay, that makes sense. I think it might work better to treat "node" as synonymous with "user" rather than "party" though -- that way you can say "you create a lightning node by running lightning node software such as lnd/cln/eclair/etc". That means not all vertices in the payment routing network are nodes; but all vertices in the *gossip* network are nodes, so that seems okay. Just saying "channel" (instead of "logical channel") and "utxo/off-chain utxo" (instead of "physical channel") might also work okay. > I also think it's best to imagine a world in which there are hierarchical > channels, but there are no "factories" per se. Personally, I use "channel factory" to mean "anything that lets a single utxo contain multiple channels between different users, that can be reorganised without going on-chain", so I think once you've got hierarchial channels, you've implicitly got (a variation of) channel factories. (I'm not sure "channel factories" is really the most evocative way of describing them -- at least when I think of a factory, I think the product should be accessible to everyone; but for channel factories you have to be involved in the factory's original mutlisig to be able to use one of its channels. Maybe better to call them "channel coops", where you're creating a little commune of friends/allies to work together with each other. Could be pronounced like "workers' co-op" or like "chicken coop", either way :) > * Logical Channel: a layer 2 construct that consists of all of the physical > channels owned by a specific pair of parties > - the size (capacity) of a logical channel is the sum of the sizes of their > physical channels > - (Footnote: It's possible, with a significant amount of software > development work that I in no way discount, to route a payment through a > logical channel where the payment traverses multiple physical channels at the > same time. This is done by using separate HTLCs, all sharing the same secret, > in each of the physical channels that the payment traverses. I can write more > about this if that would be helpful.) I think it might already be interesting to write a BOLT/BLIP for that? Having a single channel backed by multiple on-chain utxos is probably interesting for splicing (adding or spending a utxo while keeping the channel open on the other utxos might be able to be done more simply than splicing in general), and having multiple utxos might let you increase some of your channel limits, eg `max_accepted_htlcs` might be able to be increased to 483*U where U is the number of UTXOs backing the channel. > > It feels like there's a whole > > mass of complications hidden in there from a routing perspective; like how > > do you link "FG" back with "F" and "G", how do you decide fees, how do > > you communicate fees/max_htlc/etc. > Regarding the specific issues you raised: > Q: How do you link "FG" back with "F" and "G"? > A: In terms of gossiping and the channel graph, you don't Yeah, I think that simplifies things substantially. I think the main thing that misled me here was the "CD->E->FG" payment chain -- it doesn't make sense to me why E would want to devote funds that can only be used for rebalancing channels, but not normal payments. Having that be CD->DE->FG seems like it would make much more sense in that model. (Though, obviously, no one except D and E could necessarily tell the difference between those two scenarios in practice, and just because something doesn't make sense, doesn't mean nobody will actually do it) The other thing was that going from N nodes to C*N channels, then re-considering each of the C*N channels (A->B, etc) as also potentially being nodes and adding an additional K*C*N channels (AB->CD, etc) seemed like it might be quadratic to me. But it's probably not -- C (channels per node) and K (utxos per channel) are probably constant or logarithmic in N, so it's probably okay? On the other hand, I could see the rebalancing channels not actually being very useful for routing payments (they require 3+ signatures, and may not even be publicly connected to any of the level-1 nodes), so it could make sense to just treat them as two different networks, where regular people doing payments only see the base channels, but high-availability nodes also find out about the rebalancing channels. If so, then the extra nodes/channels in the rebalancing graph only affect people who can afford to dedicate the resources to
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
> One thing that confuses me about the paper is how to think about routing > to a "channel" rather than a node -- ie the payment from "E->FG->A" where > "FG" isn't "F" or "G", but "both of them". Yes, I found it very difficult to think about, and I kept getting confused between concepts like "user", "node", "channel", and "factory". The thing that works best for me is to create a clear definition of each of these terms, along with the term "party". I also think it's best to imagine a world in which there are hierarchical channels, but there are no "factories" per se. The distinction is meaningful in the sense that a hierarchical channel requires that there are exactly *two* *fixed* "parties" to which the hierarchical channel pays out, and all changes to the balances paid to those parties are made via HTLCs. In contrast, a "factory" can pay out to an arbitrary number of users or groups of users, and changes to the balances paid to those users or groups of users are made via updating the state of the factory (typically without an HTLC being required). So, in a world with hierarchical channels, but without factories, we have the following terms: * User: a person * Party: a fixed group consisting of one or more users * Node: a party - so "party" and "node" are synonyms, with "party" emphasizing the human side of things and "node" emphasizing the graph side of things, such as when discussing the Lightning routing graph * Physical channel: a layer 2 construct that is funded by an on-chain or an off-chain UTXO, is owned by 2 parties, pays a balance to each of the parties, and updates the parties' balances through HTLCs and a channel protocol - a physical channel can be non-hierarchical (where each of the 2 parties is a single user) or hierarchical (where at least one party consists of more than 1 user) - (Footnote: The concept of an "off-chain UTXO" is itself a bit tricky, as it often refers to one of multiple possible transaction outputs, where the transactions or their ancestors conflict, so only one of them can actually be instantiated. For example, a Lightning channel (using the current penalty protocol) can be said to create an off-chain UTXO that pays to one of the users, even though it's not clear which of the users' Commitment transactions will actually be instantiated. In general, an off-chain UTXO is a guaranteed way of getting a certain portion of a specific on-chain UTXO's funds. Let's skip going down this rabbit hole any further and just assume we understand these issues.) * Logical Channel: a layer 2 construct that consists of all of the physical channels owned by a specific pair of parties - the size (capacity) of a logical channel is the sum of the sizes of their physical channels - (Footnote: It's possible, with a significant amount of software development work that I in no way discount, to route a payment through a logical channel where the payment traverses multiple physical channels at the same time. This is done by using separate HTLCs, all sharing the same secret, in each of the physical channels that the payment traverses. I can write more about this if that would be helpful.) * Lightning Network (LN): a layer 2 network consisting of parties and logical channels between parties - the LN can be represented as a directed graph, where each party is a node and each logical channel is pair of arcs (one in each direction) between two nodes - the LN can be used to make payments from one node to another node via a path through the graph - the purpose of the payment could be to send bitcoin from one user to another (in this case, the payment's source and destination nodes are both 1-user parties) - the purpose of the payment could be to increase or decrease the size of a logical channel (in this case, the payment's source and/or destination node is a multi-user party) - (Footnote: Here's another great opportunity for confusion, as the source and/or destination of the payment is a multi-user party, which is defined as more than two users, and yet the purpose of the payment is to resize a logical channel. Obviously, a group of users is different from a logical channel (as shown in the definitions above), so how does making a payment to or from a group of users change the size of a logical channel? The answer is that the logical channel being resized is the one owned by the group of users.) * Factory: a term that doesn't exist in this world view Sorry if all of this seems overly pedantic. It's the only way I've been able to keep these concepts straight in my mind. I've also found that drawings help clarify these issues, which is why the paper has 20 drawings, many of which are examples of payments and channel graphs. > It feels like there's a whole > mass of complications hidden in there from a routing perspective; like how > do you link "FG" back with "F" and "G", how do you decide fees, how do > you communicate
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
On Sat, Apr 08, 2023 at 10:26:45PM +, jlspc via Lightning-dev wrote: > From my perspective, this paper makes two contributions (which, to be fair, > may only be "interesting" :) One thing that confuses me about the paper is how to think about routing to a "channel" rather than a node -- ie the payment from "E->FG->A" where "FG" isn't "F" or "G", but "both of them". It feels like there's a whole mass of complications hidden in there from a routing perspective; like how do you link "FG" back with "F" and "G", how do you decide fees, how do you communicate fees/max_htlc/etc. I think it also implies that channel capacity is no longer really something you can gossip very sensibly -- if you have a factory ((A,B),C,D,E) then every payment through AB to C or D or E will decrease AB's channel capacity. You could still gossip the capacity of the overall factory, and sum that to get an overall lightning network capacity, of course. But a lot of the ways of simplifying it also make it harder to do all the nice rebalancing. Anyway, I've tried a few times now to put some thoughts together on that and come up with nothing that I'm happy with, so figured it might be at least worth posing explicitly as a problem... Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
Comments below: >> Step 1: Tunable penalties; >> > href="https://github.com/JohnLaw2/ln-tunable-penalties;>https://github.com/JohnLaw2/ln-tunable-penalties >> > href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html;>https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html >> This is a clever constructions that lets you do a 2-party lightning >> channel with existing opcodes where cheating doesn't result in you >> losing all your funds (or, in fact, any of your in-channel funds). > Ah, a significant difference between this and eltoo is in the game > theory of what happens if you lose access to the latest state. > In eltoo, how things would work in that case, is that you would attempt > to close the channel to an old state that you do still remember (from a > backup), at which point either (a) your counterparty publishes a later > state, and you settle with that (possibly with you paying some modest > penalty if you're using a Daric-like protocol), or (b) your counterparty > does nothing, and you settle at the old state. > With tunable penalties, you are in more of a quandry. If you broadcast > an old "St" transaction to attempt to close to an old state, then your > counterparty will simply claim those funds and penalise you; however > there is nothing forcing them to publish any newer state as well. At > that point your counterparty can hold your share of the channel funds > hostage indefinitely. > Holding your funds hostage is probably an improvement on simply losing > them altogether, of course, so I think this is still a strict improvement > on ln-penalty (modulo additional complexity etc). Yes, that's a good point. I did describe an extension, called "Unilateral Close after an Old Transaction is Put On-Chain", in the Tunable Penalties paper and in the Factory Optimized Channels paper. The idea is to add a Trigger transaction that spends the output of the Funding transaction. In response to seeing the Trigger transaction, the other party can put their final State transaction and (after a to-self-delay) Commitment transaction on-chain. However, if the other party doesn't do so, then after a 3*to-self-delay, the party that forgot the state can initiate the Decker-Wattenhofer protocol to settle the channel. Of course, the eltoo protocol could be used instead of the Decker-Wattenhofer protocol at this point if APO is available. Regards, John ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
Hi aj,
Thanks for your great write-up!
Comments below:
> Even with Harding's optech write ups, and the optech space, I barely
> follow all this, so I'm going to try explaining it too as a way of
> understanding it myself; hopefully maybe that helps someone. Corrections
> welcome, obviously!
> I think understanding all this requires going through each of the four
> steps.
[...]
> Step 3: Factory Optimized protocols for Lighting
> href="https://github.com/JohnLaw2/ln-factory-optimized;>https://github.com/JohnLaw2/ln-factory-optimized
> href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html;>https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html
> href="https://bitcoinops.org/en/newsletters/2022/12/14/#factory-optimized-ln-protocol-proposal;>https://bitcoinops.org/en/newsletters/2022/12/14/#factory-optimized-ln-protocol-proposal
> In this case your transactions are:
> F - the funding output, only available once the factory is closed
> InB - as before
> StBi - your state commitment, one output that will be spent by ComBi,
> k outputs for each pending HTLC paying to B in state i.
> HBi-j-k - the kickoff transaction for HTLC "j" paying to B, spends
> the appropriate output of StBi, conditional on revealing the
>HTLC preimage and B's signature. Spendable either by B after
>to-self-delay, or by A after the HTLC's expiry plus
>to-self-delay
> HBi-j-s - the success transaction, spendable by B
> HBi-j-p - the payment transaction, spends HBi-j-s and the HTLC output
> from ComB_i
> HAi-j-p - the payment transaction, spends HBi-j-s and the HTLC output
> from ComA_i
> I think there's an error in the paper here; it says as well as being
> spendable by H{A,B}i-j-p as above, the HTLC output in ComA_i should be
> spendable by A after to-self-delay. I believe it should require both
> to-self-delay (relative timelock) and the HTLC expiry (absolute timelock)
> before it can be spendable by A.
It's not actually an error in the paper, because the paper includes a
"max_cltv_expiry" parameter that prevents the race you're concerned about.
However, it's easy to miss that parameter (it's only introduced in an appendix)
and I like your idea of using an absolute delay in the HTLC output in ComA_i
when it is spent by A.
I plan to change the paper to add such an absolute delay (which I believe
should be Alice's to-self-delay after the HTLC's expiry) and remove the
"max_cltv_expiry" parameter.
Thanks for the good idea!
> While this is described as an optimisation focussed on improving channels
> within factories; it seems to me that the reduction in state compared to
> the "tunable penalties" approach in step 1 makes this a strict improvement
> in general.
I agree.
> Every participant needs 1+c "In" confirmed utxos available -- one for
> the factory itself, and one for each channel they're involved in.
While 1+c "In" confirmed utxos will work, it's also possible to just have a
single confirmed utxo and to create the 1+c desired "In" utxos from it by
putting a transaction, or a tree of transactions, on-chain if and when needed.
This optimization is described as the "Off-Chain Control Outputs" extension in
the original Tunable Penalties paper and in the Factory Optimized Channels
paper.
> Step 4: Resizing Lightning Channels Off-Chain / Hierarchial Channels
>href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html;>https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html
>href="https://github.com/JohnLaw2/ln-hierarchical-channels;>https://github.com/JohnLaw2/ln-hierarchical-channels
>href="https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories;>https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories
> Hey, we made it to this thread!
> I'm not entirely sure of the novelty in this proposal; once you have
> channels in factories, lots of magic is possible, but it's all very
> complex. I believe the particular proposal here is something like:
> - Instead of just having Alice/Bob/Carol/etc as identities in
>lightning, let them "pair" up, so that AliceBob is considered a node,
>and CarolDave is also a node.
> - So we have a utxo where AliceBob has a channel with CarolDave, and
>another where CarolDave has a channel with Elizabeth, eg.
> - But actually the AliceBob/CarolDave utxo is a factory; and there's
>an internal channel between Alice and Bob, and another between Carol
>and Dave
> - Now, because we describe AliceBob and CarolDave as a channel, that
>means funds can move between AliceBob and CarolDave; but that is
>equivalent to saying the overall capacity of the internal Alice/Bob
>channel is actually decreasing without any on-chain
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
On Tue, Apr 04, 2023 at 12:00:32AM +1000, Anthony Towns wrote: > On Sat, Mar 18, 2023 at 12:41:00AM +, jlspc via Lightning-dev wrote: > > TL;DR > > Step 1: Tunable penalties; > https://github.com/JohnLaw2/ln-tunable-penalties > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html > > This is a clever constructions that lets you do a 2-party lightning > channel with existing opcodes where cheating doesn't result in you > losing all your funds (or, in fact, any of your in-channel funds). Ah, a significant difference between this and eltoo is in the game theory of what happens if you lose access to the latest state. In eltoo, how things would work in that case, is that you would attempt to close the channel to an old state that you do still remember (from a backup), at which point either (a) your counterparty publishes a later state, and you settle with that (possibly with you paying some modest penalty if you're using a Daric-like protocol), or (b) your counterparty does nothing, and you settle at the old state. With tunable penalties, you are in more of a quandry. If you broadcast an old "St" transaction to attempt to close to an old state, then your counterparty will simply claim those funds and penalise you; however there is nothing forcing them to publish any newer state as well. At that point your counterparty can hold your share of the channel funds hostage indefinitely. Holding your funds hostage is probably an improvement on simply losing them altogether, of course, so I think this is still a strict improvement on ln-penalty (modulo additional complexity etc). Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
Hi Dave,
Thank you for your clear and insightful response.
Comments inline below:
>Hi John,
>Thank you for another innovative application of your tunable penalties.
>I see two key benefits being described by your paper[1]:
>- **Offchain channel resizes:** in state 0, Alice and Bob share control
> over an offchain UTXO valued at x satoshis; in state 1, the value of
> the offchain UTXO is y satoshis.
>- **Liquidity multiplexing:** Alice, Bob, Carol, and Dan each rightfully
> own some portion of a UTXO. Alice and Bob expect to always be
> available; Carol and Dan may sometimes be unavailable. The proposal
> allows Carol and Dan to spend/receive in combination with Alice and
> Bob, but also ensures Alice and Bob can spend back and forth the
> entirety their portions of the UTXO even if Carol, Dan, or both of
> them are unavailable.
>For the Offchain Channel Resizes, I don't see how your proposal
>functionally differs from a classic channel factory. In section 3, you
>show the set {A, B, C, D} with the subset {A,B} where A reduces its
>balance in {A,B} by transfering it to {C,D} via an HTLC to another of its
>nodes (A').
>Your description uses hierarchical channels (which may have 2
>participants per channel). In a classic pair-producing channel factory,
>each channel only has two participants, e.g. the factory {A, B, C, D}
>produces the channels,
> {A,B}
> {A,C}
> {A,D}
> {B,C}
> {B,D}
> {C,D}
>However, the same thing is possible, A as part of {A,B} can pay through
>{B,C} out of the factory to A'. After the HTLCs are settled, the
>offchain channel setup transactions inside the factory can be
>regenerated with the cooperation of all {A, B, C, D}.
>Am I missing something, or is this first key benefit something that was
>already possible (in theory) with pair-producing channel factories?
When the first key benefit is defined as:
Benefit 1: Ability to resize a channel owned by Alice and Bob
offchain from x satoshis to y satoshis
you are correct that this can be achieved with existing techniques
using channel factories.
However, when the key benefit is defined differently, it becomes clear
that it can be achieved only with hierarchical channels. I'll give two
other definitions of the benefit that demonstrate what is new. In these
definitions, note that the quantity "delta" could be positive or
negative. Also, assume that all capacity owned by the users considered
must be in a Lightning channel at all times (in order to avoid
stranding liquidity). Finally, for simplicity, ignore routing fees
in the following.
Benefit 2: Ability to resize a channel owned by Alice and Bob
offchain from x satoshis to y = x - delta satoshis, while
resizing a channel owned by Harriet and Isaac from u satoshis
to v = u + delta satoshis, where:
a) Harriet and Isaac do not know Alice and Bob and
never co-sign transactions with Alice and Bob, and
b) all other 2-user channels' capacities are
unchanged.
Note that Benefit 2 can't be achieved with channel factories, as they
would violate requirement a) above. In contrast, Benefit 2 can be
achieved with hierarchical channels, as long as all channels are
viewed as logical (rather than physical) channels. An example of
how this can be achieved is with the payment given in Figure 4 of
the paper (p. 8), but stopping the payment one hop earlier as it
is received by H and I (Harriet and Isaac). Benefit 2 matters, as
it's a lot easier to find a channel that wants to make a capacity
change that offsets the capacity change that Alice and Bob want
to make if the offsetting channel can be anywhere in the world
(but connected via the Lightning Network) as opposed to in a
channel factory containing Alice and Bob (as there will only
be, say, 10 or 100 users in each such factory). Having to offset
a channel capacity change by finding a channel making the opposite
change within a channel factory is like having to make LN payments
without using HTLCs. It would be possible to make payments within
a factory, but in most cases that wouldn't help, as the payer and
payee would not happen to be in the same factory.
Benefit 3: Ability to resize a channel owned by Alice and Bob
offchain from x satoshis to y = x - delta satoshis, where all
other 2-user channels' capacities are unchanged.
Note that Benefit 3 cannot be achieved with channel factories, as any
change in the capacity of a channel in a factory must be offset by
the opposite change in one or more other channels within the factory
(given our requirement that all capacity is always kept within channels
in order to avoid stranding liquidity).
In contrast, Benefit 3 is possible with hierarchical channels, as
long as they are viewed as logical channels. Examples include the
payment shown in Figure 1 of the paper (p. 4). This somewhat
surprising result is due to the existence of
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
On Sat, Mar 18, 2023 at 12:41:00AM +, jlspc via Lightning-dev wrote:
> TL;DR
Even with Harding's optech write ups, and the optech space, I barely
follow all this, so I'm going to try explaining it too as a way of
understanding it myself; hopefully maybe that helps someone. Corrections
welcome, obviously!
I think understanding all this requires going through each of the four
steps.
Step 1: Tunable penalties;
https://github.com/JohnLaw2/ln-tunable-penalties
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html
This is a clever constructions that lets you do a 2-party lightning
channel with existing opcodes where cheating doesn't result in you
losing all your funds (or, in fact, any of your in-channel funds). It
also retains the ability to do layered commit transactions, that is you can
immediately commit to claiming an HTLC or that it's already timed out,
even while you're waiting for the to_self_delay to expire to ensure
you're not cheating.
The way that it works is by separating the flow of channels funds, from
the control flow. So instead of managing the channel via a single utxo,
we instead manage it via 3 utxos: F (the channel funds), InA (control
flow for a unilateral close by A), InB (control flow for a unilateral
close by B).
For each update to a new state "i", which has "k" HTLCs, we create 4 primary
txs, and 8k HTLC claims.
StAi which spends InA, and has k+1 outputs. The first output is used
for controlling broadcast of the commitment tx, the remaining k are for
controlling the resolution of each HTLC.
ComAi is the commitment for the state. It spends the funding output
F, and the first output of StAi. In order to spend StAi, it requires
a to_self_delay (and signature by A), giving B time to object that i
is a revoked state. If B does object, he is able to immediately spend
the first output of StAi directly using the revocation information,
and these funds form the penalty. It has k+2 outputs, one for the
balance of each participant, and one for each HTLC.
For each of the k HTLCs, we construct two success and two timeout
transactions: (HAi-j-s, HAi-j-p); (HAi-j-t, HAi-j-r). HAi-j-s and
HAi-j-t both spend the jth output of StAi, conditional either on a
preimage reveal or a timeout respectively; HAi-j-p and HAi-j-r spend
the output of HAi-j-s and HAi-j-t respectively, as well as the output
of ComAi. (s=success commitment, t=timeout commitment, p=payment on
success, r=refund)
And Bob has similar versions of all of these.
So if Alice is honest, the process is:
* Alice publishes StAi
* Alice publishes HAi-j-{s,t} for any HTLCs she is able to resolve
immediately; as does Bob.
* Alice waits for to_self_delay to complete
* Alice publishes ComAi, and any HAi-j-{r,p} transactions she is able
to, and if desired consolidates her funds.
* As any remaining HTLCs resolve, those are also claimed.
* Bob's InB output is available to do whatever he wants with.
If Alice is dishonest, the process is:
* Alice publishes StAi, and perhaps publishes some HAi-j-{s,t}
transactions.
* Bob spends the first output of StAi unilaterally claiming the
* penalty, meaning ComAi can now never be confirmed.
* Bob publishes StBi', and continues with the honest protocol.
Bob only needs the usual O(log(n)) state in order to be able to
reconstruct the key to spend the first output of revoked StAi txs.
Because that prevents the corresponding ComAi from ever being published,
no revoked HTLC-related state can make it on chain in any way that Bob
needs to care about.
If both Alice and Bob are dishonest (Alice tries to cheat, but Bob
restored from an old backup and also publishes a revoked state) then
both the StAi and StBi' may have their first output claimed by the other
party, in which case the channels funds are lost (unless Alice and Bob
manage to agree to a cooperative close somehow, even after all the
attempts to cheat each other).
While 4+8k transactions per state is a lot, I think you only actually
need 2+4k signatures in advance (StAi and HAi-j-{s,t} only need to be
signed when they're broadcast). Perhaps using ANYPREVOUT would let you
reduce the number of HTLC states?
Step 2: Efficient Factories for Lightning Channels
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003827.html
https://github.com/JohnLaw2/ln-efficient-factories
This generalizes the tunable penalties setup for more than two
participants.
The first part of this is a straightforward generalisation, and
doesn't cover HTLCs. Where we had 2(2+4k) transactions previously, we
presumably would now have P(2+4k) transactions, where P is the number
of participants.
The second part of this aims to avoid that factor P. It does this by
introducing Trigger and Mold transactions.
To do this, we first establish the number of states that the factory
will support; perhaps 2**40. In that case, the trigger transaction will
spend the
Re: [Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
Hi John,
Thank you for another innovative application of your tunable penalties.
I see two key benefits being described by your paper[1]:
- **Offchain channel resizes:** in state 0, Alice and Bob share control
over an offchain UTXO valued at x satoshis; in state 1, the value of
the offchain UTXO is y satoshis.
- **Liquidity multiplexing:** Alice, Bob, Carol, and Dan each rightfully
own some portion of a UTXO. Alice and Bob expect to always be
available; Carol and Dan may sometimes be unavailable. The proposal
allows Carol and Dan to spend/receive in combination with Alice and
Bob, but also ensures Alice and Bob can spend back and forth the
entirety their portions of the UTXO even if Carol, Dan, or both of
them are unavailable.
For the Offchain Channel Resizes, I don't see how your proposal
functionally differs from a classic channel factory. In section 3, you
show the set {A, B, C, D} with the subset {A,B} where A reduces its
balance in {A,B} by transfering it to {C,D} via an HTLC to another of
its
nodes (A').
Your description uses hierarchical channels (which may have >2
participants per channel). In a classic pair-producing channel factory,
each channel only has two participants, e.g. the factory {A, B, C, D}
produces the channels,
{A,B}
{A,C}
{A,D}
{B,C}
{B,D}
{C,D}
However, the same thing is possible, A as part of {A,B} can pay through
{B,C} out of the factory to A'. After the HTLCs are settled, the
offchain channel setup transactions inside the factory can be
regenerated with the cooperation of all {A, B, C, D}.
Am I missing something, or is this first key benefit something that was
already possible (in theory) with pair-producing channel factories?
For the Liquidity Multiplexing, this does feel like a significant
advance. In a pair-producing channel factory, any funds A has in {A, C}
or {A, D} can't be spent when C or D are unavailable. In your proposal,
{A, B} form one half of {{A,B},C} and {{A,B},D}, allowing {A,B} to
redistribute their portion of the funds when C and D are unavailable.
That's not an advantage of multiparty channels that I've seen described
before, and not something I've been able to think how to functionally
reproduce with pair-producing channel factories.
Given that it took me a while to understand the Liquidity Multiplexing,
I wanted to double check to see if I had missed something about the
Offchain Channel Resizes?
Thanks again,
-Dave
[1] https://github.com/JohnLaw2/ln-hierarchical-channels
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Resizing Lightning Channels Off-Chain With Hierarchical Channels
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
