jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-03 📝 Original message: Hi Dave, Thank you for ...
📅 Original date posted:2023-04-03
📝 Original message:
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 a 3-user hierarchical
channel (namely the one owned by C, D and E in Figure 1) that
transitions from HTLCs that swap capacity between pairs of 2-user
channels to HTLCs that swap balances between users within a 2-user
channel. This benefit is even stronger than the previous one, as
no channel that wants to make an offsetting capacity change has
to be found at all.
I hope these two explicitly-stated benefits demonstrate that
hierarchical channels *do* provide new capabilities that did not
exist previously, and that these new capabilities are very
important in practice.
Please let me know if any of this doesn't make sense.
Thanks again,
John
📝 Original message:
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 a 3-user hierarchical
channel (namely the one owned by C, D and E in Figure 1) that
transitions from HTLCs that swap capacity between pairs of 2-user
channels to HTLCs that swap balances between users within a 2-user
channel. This benefit is even stronger than the previous one, as
no channel that wants to make an offsetting capacity change has
to be found at all.
I hope these two explicitly-stated benefits demonstrate that
hierarchical channels *do* provide new capabilities that did not
exist previously, and that these new capabilities are very
important in practice.
Please let me know if any of this doesn't make sense.
Thanks again,
John