jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-08 📝 Original message: Hi aj, Thanks for your ...
📅 Original date posted:2023-04-08
📝 Original message:
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
> <a href="https://github.com/JohnLaw2/ln-factory-optimized">https://github.com/JohnLaw2/ln-factory-optimized</a>;
> <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html</a>;
> <a 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</a>;
> 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
> <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html</a>;
> <a href="https://github.com/JohnLaw2/ln-hierarchical-channels">https://github.com/JohnLaw2/ln-hierarchical-channels</a>;
> <a 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</a>;
> 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 activity! Neat!
> But... that was always the point of channel factories? And the specific
> structure of four participants split into a single pair of channels
> doesn't seem particularly compelling? I don't know, I feel like I'm
> missing something here. Or maybe it's just the first three steps were
> amazing, so merely interesting seems pedestrian by comparison?
Thanks!
>From my perspective, this paper makes two contributions (which, to be fair, may only be "interesting" :)
1) it allows dedicated users to resize Lightning channels off-chain by sending channel capacity over the Lightning network, and
2) it allows each casual user to work with a pair of dedicated users in order to let the casual user send and receive payments without forcing the dedicated users to leave any of the channel capacity idle when the casual user is unavailable.
I'll discuss 2) more below.
Regarding 1), I wouldn't say that "that was always the point of channel factories".
While it's true that channel factories allow users to resize two-user channels off-chain, they can only do this subject to the following limitations:
* whatever channel capacity change is being made is exactly offset by one or more other channel capacity changes in the other direction (assuming all factory capacity is in channels),
* the desired change and the offsetting change(s) have to be within a single channel factory, and
* every user in the factory has to be available to sign for the factory update.
The first two limitations make one want to create factories with lots of users (in order to have flexibility in finding offsetting channels), while the third limitation makes one want factories with few users (in order to enable obtaining all of the required signatures).
1) eliminates all of these limitations by allowing channel capacity to be routed over the Lightning Network.
Previously, I hadn't realized this was possible.
As a result, hierarchical channels with just 3 or 4 users seem to be enough for resizing channels off-chain.
> Hmm, looking at Harding's email, I see:
>> **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.
> I guess I'm not entirely enthusiastic about that because in that case
> Alice can only send funds to Carol when Dan (and whoever else is involved
> in the factory) eventually come online to signoff on the factory state
> update. That's still useful for (slow) offchain channel reallocations,
> but it doesn't seem reliable/fast enough for a payment.
I too would not be enthusiastic if a casual user could only send and receive funds when some other casual user is available.
However, by using three-user channels (two of whom are dedicated), a casual user can send and receive without requiring availability from any other casual user (and without stranding funds).
Regards,
John
📝 Original message:
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
> <a href="https://github.com/JohnLaw2/ln-factory-optimized">https://github.com/JohnLaw2/ln-factory-optimized</a>;
> <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html</a>;
> <a 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</a>;
> 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
> <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html</a>;
> <a href="https://github.com/JohnLaw2/ln-hierarchical-channels">https://github.com/JohnLaw2/ln-hierarchical-channels</a>;
> <a 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</a>;
> 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 activity! Neat!
> But... that was always the point of channel factories? And the specific
> structure of four participants split into a single pair of channels
> doesn't seem particularly compelling? I don't know, I feel like I'm
> missing something here. Or maybe it's just the first three steps were
> amazing, so merely interesting seems pedestrian by comparison?
Thanks!
>From my perspective, this paper makes two contributions (which, to be fair, may only be "interesting" :)
1) it allows dedicated users to resize Lightning channels off-chain by sending channel capacity over the Lightning network, and
2) it allows each casual user to work with a pair of dedicated users in order to let the casual user send and receive payments without forcing the dedicated users to leave any of the channel capacity idle when the casual user is unavailable.
I'll discuss 2) more below.
Regarding 1), I wouldn't say that "that was always the point of channel factories".
While it's true that channel factories allow users to resize two-user channels off-chain, they can only do this subject to the following limitations:
* whatever channel capacity change is being made is exactly offset by one or more other channel capacity changes in the other direction (assuming all factory capacity is in channels),
* the desired change and the offsetting change(s) have to be within a single channel factory, and
* every user in the factory has to be available to sign for the factory update.
The first two limitations make one want to create factories with lots of users (in order to have flexibility in finding offsetting channels), while the third limitation makes one want factories with few users (in order to enable obtaining all of the required signatures).
1) eliminates all of these limitations by allowing channel capacity to be routed over the Lightning Network.
Previously, I hadn't realized this was possible.
As a result, hierarchical channels with just 3 or 4 users seem to be enough for resizing channels off-chain.
> Hmm, looking at Harding's email, I see:
>> **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.
> I guess I'm not entirely enthusiastic about that because in that case
> Alice can only send funds to Carol when Dan (and whoever else is involved
> in the factory) eventually come online to signoff on the factory state
> update. That's still useful for (slow) offchain channel reallocations,
> but it doesn't seem reliable/fast enough for a payment.
I too would not be enthusiastic if a casual user could only send and receive funds when some other casual user is available.
However, by using three-user channels (two of whom are dedicated), a casual user can send and receive without requiring availability from any other casual user (and without stranding funds).
Regards,
John