Nostr notes by jlspc [ARCHIVE]

📅 Original date posted:2023-10-06 🗒️ Summary of this ...

2023-10-18T13:02:07Z

In reply to nevent1q…asvc
_________________________

📅 Original date posted:2023-10-06
🗒️ Summary of this message: Hierarchical channels allow for off-chain channel resizing and transactional scaling of Lightning. Timeout-trees can address liquidity imbalances, but fault-tolerance is a concern. A new version of the paper proposes a solution using fee-penalty outputs. Passive rollovers can eliminate the need for active rollovers.
📝 Original message:
Hi Antoine,

>> "I also think resizing channels can be done fairly effectively off-chain
>with hierarchical channels [1] (and even better with hierarchical channels
>within timeout-trees)".

>Yes, transactional scaling of Lightning (i.e how many transfers can be
>performed off-chain per on-chain transaction) sounds good at first sight,
>though in practice liquidity unbalance due to asymmetries in liquidity
>flows among counterparties is a bottleneck. Note, how the on-chain
>splicing for LSP spec upgrade improves on this dimension and where
>"resizing" or "pool rebalancing" aims to keep this off-chain.

Yes, and note that with hierarchical channels you can use HTLCs to send Lightning channel capacity over the Lightning network [1], thus performing channel resizing off-chain between channels that aren't in the same pool.

>> "With these proposals, it's possible to dramatically limit the
>interactivity".

>Yes, from my rough understanding of timeout-trees and channel resizing, it
>sounds to suffer from the same issue as Jeremy radix-tree's proposal or
>Christian OG channel factory, namely the lack of fault-tolerance when one
>of the casual user or end of tree balance owner aims to go on-chain. The
>fragmentation cost sounds to be borne by all the users located in the tree
>branch. Note fault-tolerance is one of the key payment pool design goals to
>advance over factories.

Actually, in the case of a timeout-tree, the fragmentation costs imposed by a casual user going on-chain are borne exclusively by the dedicated user who funded the timeout-tree.
This makes it easier to address the problem by making the casual user pay the funder for the fragmentation costs.

I think this is an important issue, so I created a new version of the paper that includes a description of how this can be done [2].
The idea is to require casual users to reveal secrets (hash preimages) that only they know in order to put timeout-tree transactions on-chain.
Then, a fee-penalty output is added to each leaf transaction that pays from the casual user to the funding user an amount that depends on which timeout-tree transactions the casual user put on-chain.
The details are given in the new version of the paper ([2], Section 4.10, pp. 25-28).

>> "I propose that if the active drain fails, the casual user should put
>their channel in the old timeout-tree on-chain (so that it won't timeout on
>them). "

>I think there is still some issue there where you need to handle the
>malicious HTLC-withholding case along your multi-hop payment paths and wait
>for the expiration. Then go on-chain to expire the old timeout-tree, which
>might come with a high timevalue cost by default. Not saying keeping
>timevalue cost low is solved for today's Lightning.

This is an excellent point that I hadn't considered.
I think the solution is to perform passive, rather than active, rollovers.
Passive rollovers don't require use of the Lightning network, so they completely eliminate the risk of HTLC-withholding attacks.
I've added this advantage of passive rollovers in the latest version of the paper ([2], Section 4.4, p. 19).

>> "These costs could be large, but hopefully they're rare as they are
>failures by dedicated users that can afford to have highly-available
>hardware and who want to maintain a good reputation".

>Yes, though note as soon as a dedicated user starts to have a lot of
>off-chain tree in the hand, and this is observable by adversaries the
>dedicated user becomes an attack target (e.g for channel jamming or
>time-dilation) which substantially alter the trade-offs.

I believe channel jamming and HTLC-withholding attacks can be eliminated by using passive rollovers, as mentioned above.

>> "However, the paper has a proposal for the use of "short-cut"
>transactions that may be able to eliminate this logarithmic blow-up".

>Yes "cut-through" to reduce on-chain footprint in mass exit cases has been
>discussed since the early days of off-chain constructions and Taproot /
>Grafroot introduction to the best of my knowledge, see:
><a href="https://tokyo2018.scalingbitcoin.org/transcript/tokyo2018/multi-party-channels-in-the-utxo-model-challenges-and-opportunities">https://tokyo2018.scalingbitcoin.org/transcript/tokyo2018/multi-party-channels-in-the-utxo-model-challenges-and-opportunities</a>;

While I see "how do we cut-through to reduce the on-chain footprint in mass exit cases?" listed as an open problem in the above reference, I don't see any specific solutions to that problem in that reference.

The "short-cut" transactions I was referring to are defined in Section 5.4 and pictured in Figure 14 on p. 32 of the revised version of the paper [2].
They are a specific proposal for addressing the logarithmic blow-up of putting a control transaction defined by a covenant tree on-chain.
I agree that this has some similarities to the Graftroot proposal, but I believe it is distinct from proposals for addressing mass exit cases (and in fact it would not work well in those cases).

>Few questions from reading Dave's description of TP protocol here:
><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>;
>.

>In the scenario of multiple parties (e.g Alice, Bob, Caroll) owning a state
>transaction + control output, what prevents Caroll to double-spend Bob's
>revoked state transaction to a destination controlled by her in collusion
>with Bob, at the harm of Alice ?

Nothing prevents Bob from putting a revoked State transaction on-chain, and nothing prevents Carol from spending the first control output of that revoked State transaction in any manner she wishes.
Doing so would allow Carol to obtain a tunable penalty (namely, the value of the first control output of Bob's revoked State transaction), but it would not harm Alice in any way.
Spending that output keeps Bob from being able to put his Commitment transaction on-chain.
On the other hand, Alice can still put her Commitment transaction on-chain, and her payment from that Commitment transaction is unchanged, so she has not been harmed in any way.

For example, see Figure 18 on p. 29 of [1].
If Bob puts a revoked ST_Bh on-chain (where h In the scenario of multiple commitment transactions spending the same state
>transaction of an offliner user, what prevents Caroll to fake offliness and
>equivocate at the harm of Alice or another party ?

There is never a case where multiple commitment transactions can spend an output from the same state transaction.
For example, see Figure 18 on p. 29 of [1].
Each user's State transaction can only be spent by the same user's Commitment transaction (e.g., COM_Ai spends an output from ST_Ai, COM_Bi spends an output from ST_Bi, and COM_Ci spends an output fromn ST_Ci).
Furthermore, each Commitment transaction (at the 3-user hierarchical channel level) requires signatures from all 3 users in order to spend the value output from the Funding transaction F, so only the correct Commitment transaction can spend that output.

>Still building my understanding of the TP protocol security model and
>seeing where it converges / diverges w.r.t other off-chain constructions
>trade-offs.

Thanks for doing the deep-dive on these protocols!

Regards,
John

[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Law, "Scaling Lightning With Simple Covenants, version 1.2", https://github.com/JohnLaw2/ln-scaling-covenants

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/20231006/7fda378a/attachment-0001.html>;

📅 Original date posted:2023-09-16 🗒️ Summary of this ...

2023-09-19T10:29:42Z

In reply to nevent1q…t3ze
_________________________

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The author agrees with the tradeoff between trust/safety and capital efficiency and suggests using hierarchical channels to improve efficiency. They also propose a change to Bitcoin consensus rules to address the "thundering herd" problem.
📝 Original message:
Hi aj,

I completely agree with your observation that there's an important trust/safety vs. capital-efficiency tradeoff, and I almost completely agree with your analysis.

> (There are probably ways around this with additional complexity: eg,
> you could peer with a dedicated node, and have the timeout path be
> "you+them+timeout", so that while you could steal from casual users who
> don't rollover, you can't steal from your dedicated peer, so that $4.5B
> could be rolled into a channel with them, and used for routing)

Yes, that would work, but I think it's better to have dedicated user B pair with another dedicated user C such that each leaf of the timeout-tree funds a hierarchical channel [1] of the
form (A_i, (B, C)), where A_i is a casual user.
If A_i performs an active rollover, all funds not owned by A_i can *always* be used by B and C to route payments that are unrelated to the casual users in the timeout-tree (including both before and after A_i's funds are drained).
This idea was described in the "Improving Capital Efficiency" section of the post.

Passive rollovers complicate this, as A_i's funds are neither definitely in the old timeout-tree or in the new timeout-tree during the rollover.
However, if one is willing to take on the complexity, it's possible to use *your* (very cool!) idea of funding an HTLC from one of two possible sources, where one of those sources is guaranteed to eventually be available (but the offerer and offeree of the HTLC don't know which one will be available to them) [2][3].
In this case, B and C could use the funds from the old and the new timeout-trees that are not owned by A_i to route payments.
If A_i puts the leaf in the old timeout-tree on-chain, B and C use funds from the new timeout-tree to fund their HTLC (and vice-versa).

Even if hierarchical channels are used to improve the capital efficiency, I think the "thundering herd" problem is a big concern.
This could play out very poorly in practice, as casual users would gain experience with ever larger timeout-trees and not have any problems.
Then, suddenly, a large number of dedicated users collude by failing to roll-over timeout-trees at the same time, and they create enough congestion on the blockchain that they're able to steal a large fraction of the casual users' funds.

I have a proposed change to the Bitcoin consensus rules that I think could address this problem.
Basically, rather than have timeout-trees expire at a given block height, they should expire only after a sufficient number of low-fee blocks have been added to the blockchain after some given block height.
As a result, if dedicated users colluded and tried to steal funds by not rolling-over a group of timeout-trees, the thundering herd of transactions from casual users would push up the fees enough to prevent the timeout-trees from expiring, thus safeguarding the casual user's funds.
In fact, the impact to the dedicated users (in addition to their loss of reputation) would be that their capital would be unavailable to them for a longer period of time.
Thus, this should be effective in deterring dedicated users from attempting such a theft.
On the other hand, when the dedicated users do roll-over funds correctly, there is no delay in the old timeout-trees' expiries, and thus better capital efficiency.

There are lots of details to the idea and I'm currently in the process of writing a paper and post describing it.
A couple more quick details:
* rather than counting low-fee blocks, time is measured in low-fee windows, where the size of the window is programmable (this makes it much harder for dishonest miners to collude with the dedicated users by creating enough fake low-fee blocks, not containing the casual users' higher-fee timeout-tree transactions, to enabe the theft; it also reduces the compute cost for counting the low-fee windows),
* the threshold for a "low-fee" block is programmable,
* there is a bound on how long one keeps waiting for low-fee windows (in order to bound the storage and compute overheads), and
* a similar technique supports relative, rather than absolute, delays.

I think such a mechanism is likely to be useful in many areas, including HTLCs, but that timeout-trees really highlight the need for something like this.

Regards,
John

[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003913.html
[3] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003917.html

Sent with Proton Mail secure email.

📅 Original date posted:2023-09-16 🗒️ Summary of this ...

2023-09-19T10:29:42Z

In reply to nevent1q…ajrx
_________________________

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The paper presents some interesting ideas, but there are concerns about the increased cost of enforcement. Short-cut transactions could help address this issue. In worst case scenarios, there may be a 2x penalty on the number of on-chain transactions. In cases where the user fails to rollover, relying on legal and custody policies may be preferable.
📝 Original message:
Hi Rusty,

> I've read the start of the paper on my vacation, and am still
> digesting it. But even so far, it presents some delightful
> possibilities.

Great!

> As with some other proposals, it's worth noting that the cost of
> enforcement is dramatically increased. It's no longer one or two txs,
> it's 10+. If the "dedicated user" contributes some part of the expected
> fee, the capital efficiency is reduced (and we're back to "how much is
> enough?").

Yes, this is certainly an issue, and it affects both settling the channel on-chain and resolving HTLCS on-chain.
The paper has a few ideas about how "short-cut" transactions could be used to address the cost of enforcing HTLCs on-chain.
It may be possible to do something similar for the channel itself, but that's more complex because of the value included in the channel and the potential for channels with different capacities in a single timeout-tree.

> But worst case (dramatic dedicated user failure) it's only a 2x penalty
> on number of onchain txs, which seems acceptable if the network is
> sufficiently mature that these failure events are rare.

> Note also that the (surprisingly common!) "user goes away" case where
> the casual user fails to rollover only returns funds to the dedicated
> user; relying on legal and normal custody policies in this case may be
> preferable to an eternal burden on the UTXO set with the current
> approach!

Agreed.

Thanks,
John

> Thankyou!
> Rusty.

Sent with Proton Mail secure email.

📅 Original date posted:2023-09-16 🗒️ Summary of this ...

2023-09-19T10:19:29Z

In reply to nevent1q…6rr4
_________________________

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The paper presents some interesting ideas, but there are concerns about the increased cost of enforcement and the complexity of implementing them.
📝 Original message:
Hi Rusty,

> I've read the start of the paper on my vacation, and am still
> digesting it. But even so far, it presents some delightful
> possibilities.

Great!

> As with some other proposals, it's worth noting that the cost of
> enforcement is dramatically increased. It's no longer one or two txs,
> it's 10+. If the "dedicated user" contributes some part of the expected
> fee, the capital efficiency is reduced (and we're back to "how much is
> enough?").

Yes, this is certainly an issue, and it affects both settling the channel on-chain and resolving HTLCS on-chain.
The paper has a few ideas about how "short-cut" transactions could be used to address the cost of enforcing HTLCs on-chain.
It may be possible to do something similar for the channel itself, but that's more complex because of the value included in the channel and the potential for channels with different capacities in a single timeout-tree.

> But worst case (dramatic dedicated user failure) it's only a 2x penalty
> on number of onchain txs, which seems acceptable if the network is
> sufficiently mature that these failure events are rare.

> Note also that the (surprisingly common!) "user goes away" case where
> the casual user fails to rollover only returns funds to the dedicated
> user; relying on legal and normal custody policies in this case may be
> preferable to an eternal burden on the UTXO set with the current
> approach!

Agreed.

Thanks,
John

> Thankyou!
> Rusty.

Sent with Proton Mail secure email.

📅 Original date posted:2023-09-16 🗒️ Summary of this ...

2023-09-19T10:19:29Z

In reply to nevent1q…fclv
_________________________

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The main point of the conversation is that in order for Bitcoin and Lightning to be widely adopted, they need to cater to casual users who want easy payments. The focus is on onboarding scalability and providing multiple channels to as many users as possible.
📝 Original message:
Hi Antoine,

Thanks for your note. Responses are in-line below:

> Hi John,

> Thanks for the proposal, few feedback after a first look.

> > If Bitcoin and Lightning are to become widely-used, they will have to be adopted by casual users who want to send and receive bitcoin, but > who do not want to go to any effort in order to provide the infrastructure for making payments.
> > Instead, it's reasonable to expect that the Lightning infrastructure will be provided by dedicated users who are far less numerous than
> 
> I don't know if it is that simple to classify expected users in
> "casual"-vs"dedicated" and then design protocols accordingly. In
> practice, if you take today Lightning as an example the trust
> assumptions is more a matrix than a dichotomie, e.g you have the
> choice between full-node vs light client to get block-relay,
> large-sized mempool vs small mempool or no mempool at all for fee
> estimations, routing HTLCs or not, running local watchtower or not...
> without all those choices being necessarily interdependent. Generally,
> I would say "tell me your IO disk/bandwidth/CPU performance/fees
> ressources and level of technical knowledge and I'll tell you what
> level of trust-minimization you can afford".

Fair enough.

I'm sure there are users with a wide range of expertise, resources, and interest in supporting Bitcoin.
My main point is that there's a huge pool of potential users that just want payments to work, and they don't want to devote time or hardware resources to making them work (if they can get away with that).
I also think we should do whatever we can to meet their needs.

> > This difference in numbers implies that the key challenge in scaling Bitcoin and Lightning is providing bitcoin and Lightning to casual
> 
> > users.
> > As a result, the rest of this post will focus on this challenge.
> 
> I think few different scaling notions can be introduced to measure the
> performance of an off-chain construction. Onboarding scaling defining
> how many users can co-exist off-chain, considering throughput limits
> (e.g blocksize, average block interval). Transactional scaling
> defining how many transfers can be performed off-chain per on-chain
> transaction, considering the properties of the off-chain system. Users
> resource scaling defining how much resource a user should mobilize /
> consume (e.g average weight cost for cooperative / non-cooperative
> close) to make a trust-minimized usage of the off-chain construction.
> I think the proposal is mainly considering onboarding scalability, i.e
> maxing out the number of channels that can be owned by a user though
> it is unclear if other scalability dimensions are weighted in.

Yes, exactly.
I've focused on providing multiple channels to as many casual users as possible.

In terms of other scalability dimensions, I think Lightning does a great job of providing a nearly unbounded number of payments per channel, without requiring on-chain transactions (once the channel is created).
I also think resizing channels can be done fairly effectively off-chain with hierarchical channels [1] (and even better with hierarchical channels within timeout-trees).

> In particular, no known protocol that uses the current Bitcoin
> consensus rules allows a large number (e.g., tens-of-thousands to
> millions) of Lightning channels, each co-owned by a casual user, to be
> created from a single on-chain unspent transaction output (UTXO).

> I’m not sure if this statement is 100% accurate. One could create a
> radixpool with replacing CTV usage with Musig2 where the end
> transactions outputs bear Lightning channel:
> <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html.">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html.</a>;

> Of course there is no N-party update mechanism to rebalance the
> channel internally and it’s a nightmare if a subranch of transactions
> with some depth hit the chain, though I think it works with today
> Bitcoin consensus rules.

I agree that it's theoretically possible to use signatures to create Lightning channels for a million casual users that are funded by a single UTXO.
I just don't believe that that is possible in practice, due to the need to get a million casual users to sign a transaction where the transaction specifies the casual users that need to sign it.

> The requirement for casual users to sign transactions that specify the
> exact set of casual users whose signatures are required creates a very
> difficult group coordination problem that's not well-suited to the
> behavior of casual users [9, Section 2.2].

> I think you have two more precise problems designated under this group
> coordination problem. One is the dynamic novation of this group, i.e
> how you add / remove user, if possible in a compact fashion. The
> second the dynamic update of the “account” / channels owned by the
> users of this group, if possible with minimal interactivity.

Yes, changing who pairs with whom and resizing channels are both important problems.

I propose that changing pairings be done only via the creation and expiry of timeout-trees (with users that want to keep pairing with the same dedicated user(s) doing so via passive rollovers).
I propose that channel resizing is mainly done via hierarchical channels, with any resizing that's not possible to do off-chain in that manner being done via creation and expiry of timeout-trees.

With these proposals, it's possible to dramatically limit the interactivity.

For example, if every channel created by a timeout-tree is a hierarchical channel of the form:
* (casual user, (dedicated user, dedicated user)), or
* (dedicated user, (dedicated user, dedicated user)), or
* ((dedicated user, dedicated user), (dedicated user, dedicated user)),
then at most four users ever have to coordinate to update any channel, and at most one of those users is ever a casual user.

> > On the other hand, sometime shortly before E, casual user A_i can use the Lightning Network to send all of their balance in the channel > > (A_i, B) to themselves in some other Lightning channel that is the leaf of some other timeout-tree.
> 
> I think there is an uncertainty in this model as there is no guarantee
> that you have a dedicated user ready to be the gateway to route the
> balance, neither the dedicated user have adequate channel topology
> allowing to send the funds in the part of the network you wish to do
> so. And this is unclear what the casual user is left to do if an
> intermediate hop withhold the HTLC in-flight until the timeout-tree
> mature in favor of the dedicated user, iiuc.

> So I think draining is uncertain in a world where jamming is possible,
> even assuming economic mitigation as one might earn more to jam a
> casual user draining than loosing in jamming upfront fees.

I agree that active draining by the casual user is uncertain.
I propose that if the active drain fails, the casual user should put their channel in the old timeout-tree on-chain (so that it won't timeout on them).
Sorry that wasn't clear.

> > Of course, sometime between E - to_self_delay_i and E, A_i should verify that B has created such a new timeout-tree.
> 
> I think this requirement is altering the design goal introduced at
> first on casual users “performing actions at specific times in the
> future” as from my understanding there is no guarantee B broadcast an
> on-chain transaction triggering the move of A funds to the new
> timeout-tree. This becomes unclear when A should take correction
> actions like broadcasting its own control transaction (?) when B fails
> to dos, especially in a world where you have mempool congestion, and
> earlier you’re better it might in term of fee risk.

Ideally, I'd like casual users to only perform actions when they want to send or receive a payment.
Unfortunately, I don't know how to do that.
As a result, I've been forced to add a requirement that each casual user turns on their wallet software for a few minutes (but at a time of their choosing!) every few months (with the exact number of months being selected by the user) [2].
I agree this isn't ideal, but I think it's much better than having them have to perform some action at a specific time or within a very limited time window (such as a day or a week).

> > Fortunately, timeout-trees can be used to provide casual users with immediately-accessible off-chain bitcoin in addition to bitcoin in
> 
> I think this is unclear what is meant by “immediately-accessible”
> here, if they’re confirmed or not. Pre-signed / pre-committed
> transactions at a fixed feerate might still not propagate on the
> network, due to mempool min fee, and the user might have to take
> actions in consequence like access hot wallet and sign a CPFP.

I agree that the bitcoin may not be obtained if the user hasn't signed and submitted a transaction with sufficient fees.
I tried to address this issue in the "Limitations" section of the post (specifically, Limitationss 2 and 3).

I think that getting a reliable transport mechanism for packages is critical.

Getting fees right could be particularly challenging due to the "thundering herd" problem, as _aj_ pointed out.
As I noted in my response to him, I think an additional change to Bitcoin that allows timing based on fee levels could be very helpful.
I'll try to write up the details and get that out as soon as possible.

> > In reality, their on-chain footprint would be dominated by users who don't follow the protocol due to errors, unavailability, or malicious > intent.
> 
> The fault-tolerance of such off-chain construction is very unclear i.e
> if for any unavailable or erring user the whole off-chain construction
> ends up on-chain. This is one significant defect in my opinion of the
> radixpool or old school apo channel factory (or even coinpool if no
> time-locked kick-out transaction is used), if one user becomes
> unresponsive after a while.

With a timeout-tree, if the dedicated user(s) funding the tree is unavailable (or makes an error) and fails to rollover a given casual user, that casual user should put their channel in the old timeout-tree on-chain.
If the failure applies to all channels in the timeout-tree, the entire timeout-tree will be forced to go on-chain (thus doubling the number of on-chain transactions as compared to just putting the channels on-chain directly, without a timeout-tree).
Sorry this wasn't made clear.

These costs could be large, but hopefully they're rare as they are failures by dedicated users that can afford to have highly-available hardware and who want to maintain a good reputation.

Separately, HTLCs that are not resolved off-chain have to be put on-chain, but doing so does not force the timeout-tree itself to go on-chain.
If the HTLC control transactions are funded via zero-valued covenant trees (as proposed in the post and paper), putting an HTLC transaction on-chain can also require putting its ancestors in the covenant tree on-chain (thus creating a blow-up that is logarithmic in the number of leaves in the covenant tree).
However, the paper has a proposal for the use of "short-cut" transactions that may be able to eliminate this logarithmic blow-up.

Thanks for your thoughtful comments and please let me know if there's anything else that wasn't clear.

Regards,
John

> Best,

> Antoine

[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Law, "Watchtower-Free Lightning Channels For Casual Users", https://github.com/JohnLaw2/ln-watchtower-free

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/20230917/556e2033/attachment-0001.html>;

📅 Original date posted:2023-09-16 🗒️ Summary of this ...

2023-09-19T10:19:28Z

In reply to nevent1q…7ce8
_________________________

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The author agrees with the tradeoff between trust/safety and capital efficiency and suggests using hierarchical channels to improve efficiency. They also propose a change to Bitcoin consensus rules to address the "thundering herd" problem.
📝 Original message:
Hi aj,

I completely agree with your observation that there's an important trust/safety vs. capital-efficiency tradeoff, and I almost completely agree with your analysis.

> (There are probably ways around this with additional complexity: eg,
> you could peer with a dedicated node, and have the timeout path be
> "you+them+timeout", so that while you could steal from casual users who
> don't rollover, you can't steal from your dedicated peer, so that $4.5B
> could be rolled into a channel with them, and used for routing)

Yes, that would work, but I think it's better to have dedicated user B pair with another dedicated user C such that each leaf of the timeout-tree funds a hierarchical channel [1] of the
form (A_i, (B, C)), where A_i is a casual user.
If A_i performs an active rollover, all funds not owned by A_i can *always* be used by B and C to route payments that are unrelated to the casual users in the timeout-tree (including both before and after A_i's funds are drained).
This idea was described in the "Improving Capital Efficiency" section of the post.

Passive rollovers complicate this, as A_i's funds are neither definitely in the old timeout-tree or in the new timeout-tree during the rollover.
However, if one is willing to take on the complexity, it's possible to use *your* (very cool!) idea of funding an HTLC from one of two possible sources, where one of those sources is guaranteed to eventually be available (but the offerer and offeree of the HTLC don't know which one will be available to them) [2][3].
In this case, B and C could use the funds from the old and the new timeout-trees that are not owned by A_i to route payments.
If A_i puts the leaf in the old timeout-tree on-chain, B and C use funds from the new timeout-tree to fund their HTLC (and vice-versa).

Even if hierarchical channels are used to improve the capital efficiency, I think the "thundering herd" problem is a big concern.
This could play out very poorly in practice, as casual users would gain experience with ever larger timeout-trees and not have any problems.
Then, suddenly, a large number of dedicated users collude by failing to roll-over timeout-trees at the same time, and they create enough congestion on the blockchain that they're able to steal a large fraction of the casual users' funds.

I have a proposed change to the Bitcoin consensus rules that I think could address this problem.
Basically, rather than have timeout-trees expire at a given block height, they should expire only after a sufficient number of low-fee blocks have been added to the blockchain after some given block height.
As a result, if dedicated users colluded and tried to steal funds by not rolling-over a group of timeout-trees, the thundering herd of transactions from casual users would push up the fees enough to prevent the timeout-trees from expiring, thus safeguarding the casual user's funds.
In fact, the impact to the dedicated users (in addition to their loss of reputation) would be that their capital would be unavailable to them for a longer period of time.
Thus, this should be effective in deterring dedicated users from attempting such a theft.
On the other hand, when the dedicated users do roll-over funds correctly, there is no delay in the old timeout-trees' expiries, and thus better capital efficiency.

There are lots of details to the idea and I'm currently in the process of writing a paper and post describing it.
A couple more quick details:
* rather than counting low-fee blocks, time is measured in low-fee windows, where the size of the window is programmable (this makes it much harder for dishonest miners to collude with the dedicated users by creating enough fake low-fee blocks, not containing the casual users' higher-fee timeout-tree transactions, to enabe the theft; it also reduces the compute cost for counting the low-fee windows),
* the threshold for a "low-fee" block is programmable,
* there is a bound on how long one keeps waiting for low-fee windows (in order to bound the storage and compute overheads), and
* a similar technique supports relative, rather than absolute, delays.

I think such a mechanism is likely to be useful in many areas, including HTLCs, but that timeout-trees really highlight the need for something like this.

Regards,
John

[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003913.html
[3] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003917.html

Sent with Proton Mail secure email.

📅 Original date posted:2023-09-08 🗒️ Summary of this ...

2023-09-12T08:59:58Z

In reply to nevent1q…f0a0
_________________________

📅 Original date posted:2023-09-08
🗒️ Summary of this message: Adding covenants to Bitcoin's consensus rules, such as CheckTemplateVerify (CTV) and AnyPrevOut (APO), would greatly improve the scalability of Lightning for casual users. These changes would allow for the creation of millions of Lightning channels using a single UTXO, support resizing channels off-chain, provide liquidity to casual users, charge penalties for attempting to put an old state on-chain, and allow casual users to monitor the blockchain without a watchtower service. Implementing these changes would make Lightning a widely-used means of payment.
📝 Original message:
TL;DR
=====
* The key challenge in scaling Lightning in a trust-free manner is the creation of Lightning channels for casual users.
- It appears that signature-based factories are inherently limited to creating at most tens or hundreds of Lightning channels per UTXO.
- In contrast, simple covenants (including those enabled by CTV [1] or APO [2]) would allow a single UTXO to create Lightning channels for millions of casual users.
* The resulting covenant-based protocols also:
- support resizing channels off-chain,
- use the same capital to simultaneously provide in-bound liquidity to casual users and route unrelated payments for other users,
- charge casual users tunable penalties for attempting to put an old state on-chain, and
- allow casual users to monitor the blockchain for just a few minutes every few months without employing a watchtower service.
* As a result, adding CTV and/or APO to Bitcoin's consensus rules would go a long way toward making Lightning a widely-used means of payment.

Overview
========

Many proposed changes to the Bitcoin consensus rules, including CheckTemplateVerify (CTV) [1] and AnyPrevOut (APO) [2], would support covenants.
While covenants have been shown to improve Bitcoin in a number of ways, scalability of Lightning is not typically listed as one of them.
This post argues that any change (including CTV and/or APO) that enables even simple covenants greatly improves Lightning's scalability, while meeting the usability requirements of casual users.
A more complete description, including figures, is given in a paper [3].

The Scalability Problem
=======================

If Bitcoin and Lightning are to become widely-used, they will have to be adopted by casual users who want to send and receive bitcoin, but who do not want to go to any effort in order to provide the infrastructure for making payments.
Instead, it's reasonable to expect that the Lightning infrastructure will be provided by dedicated users who are far less numerous than the casual users.
In fact, there are likely to be tens-of-thousands to millions of casual users per dedicated user.
This difference in numbers implies that the key challenge in scaling Bitcoin and Lightning is providing bitcoin and Lightning to casual users.
As a result, the rest of this post will focus on this challenge.

Known Lightning protocols allow casual users to perform Lightning payments without:
* maintaining high-availability,
* performing actions at specific times in the future, or
* having to trust a third-party (such as a watchtower service) [5][6].

In addition, they support tunable penalties for casual users who attempt to put an old channel state on-chain (for example, due to a crash that causes a loss of state).
As a result, these protocols meet casual users' needs and could become widely-used for payments if they were sufficiently scalable.

The Lightning Network lets users send and receive bitcoin off-chain in a trust-free manner [4].
Furthermore, there are Lightning protocols that allow Lightning channels to be resized off-chain [7].
Therefore, making Lightning payments and resizing Lightning channels are highly scalable operations.

However, providing Lightning channels to casual users is not scalable.
In particular, no known protocol that uses the current Bitcoin consensus rules allows a large number (e.g., tens-of-thousands to millions) of Lightning channels, each co-owned by a casual user, to be created from a single on-chain unspent transaction output (UTXO).
As a result, being able to create (and close) casual users' Lightning channels remains the key bottleneck in scaling Lightning.

Casual Users And Signatures
===========================

Unfortunately, there are good reasons to believe this bottleneck is unavoidable given the current Bitcoin consensus rules.
The problem is that in order for a casual user to co-own a Lightning channel, they must co-own an on-chain UTXO [8].
Therefore, if a large number of casual users are to each co-own a Lightning channel, all of which are funded by a single UTXO, that UTXO must require signatures from all of those casual users.

In practice, the problem is much harder than just getting signatures from a large number of casual users, as the signatures themselves depend on the exact set of casual users whose signatures are required.
For example, if a UTXO requires signatures from a set of 1,000 casual users and if 999 of them sign but one does not, the 999 signatures that were obtained can't be used.
Instead, one has to start all over again, say with a new UTXO that requires signatures from the 999 users that signed the previous time.
However, if not all of those 999 sign, the signatures that were obtained in the second try are also unusable.

The requirement for casual users to sign transactions that specify the exact set of casual users whose signatures are required creates a very difficult group coordination problem that's not well-suited to the behavior of casual users [9, Section 2.2].
As a result, while a channel factory could be used to fund channels for perhaps 10 or even 100 casual users, it's very unlikely that any protocol using the current Bitcoin consensus rules can fund tens-of-thousands to millions of channels from a single UTXO.

Simple Covenants And Timeout-Trees
==================================

On the other hand, if the consensus rules are changed to allow even simple covenants, this scaling bottleneck is eliminated.
The key observation is that with covenants, a casual user can co-own an off-chain Lightning channel without having to sign all (or any) of the transactions on which it depends.
Instead, a UTXO can have a covenant that guarantees the creation of the casual user's channel.
The simplest way to have a single UTXO create channels for a large number of casual users is to put a covenant on the UTXO that forces the creation of a tree of transactions, the leaves of which are the casual users' channels.

While such a covenant tree can create channels for millions of casual users without requiring signatures or solving a difficult group coordination problem, it's not sufficient for scaling.
The problem is that each channel created by a covenant tree has a fixed set of owners, and changing the ownership of a channel created by a covenant tree requires putting the channel on-chain.
Therefore, assuming that all casual users will eventually want to pair with different dedicated users (and vice-versa), the covenant tree doesn't actually provide any long-term scaling benefit.

Fortunately, real long-term scaling can be achieved by adding a deadline after which all non-leaf outputs in the covenant tree can be spent without having to meet the conditions of the covenant.
The resulting covenant tree is called a "timeout-tree" [9, Section 5.3].

Let A_1 ... A_n denote a large number of casual users, let B be a dedicated user, and let E denote some fixed time in the future.
User B creates a timeout-tree with expiry E where:
* leaf i has an output that funds a Lightning channel owned by A_i and B, and
* after time E, each non-leaf output in the covenant tree can also be spent by user B without having to meet the conditions of the covenant.

Thus, any time before E, casual user A_i can put the Lightning channel (A_i, B) on-chain by putting all of its ancestors in the timeout-tree on-chain.
Once (A_i, B) is on-chain, the expiry E has no effect so A_i and B can continue to use the Lightning channel to send and receive payments from and to A_i.

On the other hand, sometime shortly before E, casual user A_i can use the Lightning Network to send all of their balance in the channel (A_i, B) to themselves in some other Lightning channel that is the leaf of some other timeout-tree.
More precisely, casual user A_i should rollover their balance by sending it from a given timeout-tree between time E - to_self_delay_i and time E, where E is the timeout-tree's expiry and to_self_delay_i is A_i's Lightning channel safety parameter.
Note that to_self_delay_i can be in the range of 1 to 3 months if a watchtower-free channel protocol is used [5][6], so performing the drain within this time window does not put an unreasonable availability requirement on A_i.

If all casual users drain their balances from the timeout-tree before E, then after E dedicated user B can create a new timeout-tree, with leaves that create Lightning channels for a new set of casual users, by putting a single transaction on-chain that spends the UTXO which created the expired timeout-tree.
In this case, all n of the old Lightning channels are closed and n new channels are created with a single on-chain transaction.

Of course, it's possible that some casual users will put their Lightning channel in the old timeout-tree on-chain, while others will drain their balance from the timeout-tree before E.
In this case, user B can create a new timeout-tree that's funded by the non-leaf outputs of the old timeout-tree that have been put on-chain.
While this results in a larger on-chain footprint than the case in which all casual users drain their balances from the old timeout-tree, it can still provide substantial scaling as long as the number of leaves put on-chain is small (in particular, well below n/(log n)).
By creating incentives that reward users who drain their balances from the timeout-tree rather than putting their channels on-chain, almost all leaves will stay off-chain and good scalability will be achieved.

Passive Rollovers For Casual Users
==================================

The timeout-trees defined above don't place unreasonable availability requirements on casual users and they allow a very large number of casual users to obtain a Lightning channel with a single on-chain transaction.
However, there are two problems with forcing casual users to drain their balances from an old timeout-tree to a new timeout-tree before the old timeout-tree's expiry:
1) if a casual user fails to perform the required drain before the old timeout-tree's expiry (due to unexpected unavailability), they lose all of their funds in the timeout-tree, and
2) if the dedicated user B is unavailable when a casual user attempts to drain their funds prior to the timeout-tree's expiry, the casual user will put their timeout-tree leaf on-chain (thus increasing the on-chain footprint and limiting scalability).
This second problem matters, as a casual user should only have to devote a short period (e.g., 10 minutes) every few months to performing the drain, so even a short period of unavailability by the dedicated user could force the casual user to go on-chain.

Instead, it would be preferable if the dedicated user could facilitate the rollover of the casual user's funds from a timeout-tree that's about to expire to another one without requiring input from the casual user.
This can be achieved by using a variation of the FFO-WF Lightning channel protocol [6].
The FFO-WF protocol uses control transactions to determine the current state of the Lightning channel and the resolution of any outstanding HTLCs, and these control transactions determine how the channel's value transactions disperse the channel's funds.

As a result, just prior to E - to_self_delay_i, B can create a new timeout-tree that funds a new Lightning channel with casual user A_i where the new channel is controlled by A_i's *same* control transactions (thus allowing A_i to obtain their funds from either the old or new Lightning channel, but not from both).
Therefore, once the old timeout-tree expires, A_i can still access their funds in the new timeout-tree's Lightning channel without having to perform any actions.
Of course, sometime between E - to_self_delay_i and E, A_i should verify that B has created such a new timeout-tree.

In addition, HTLCs can be handled so that rolling over the casual user's funds from one timeout-tree to another does not require any actions from the casual user.
The details are given in the paper [3].

Off-Chain bitcoin
=================

The Lightning Network lets casual users send and receive bitcoin entirely off-chain
However, the casual user has to wait (for a period of time specified by their Lightning partner's to_self_delay parameter) before they can access their Lightning funds on-chain.
This is problematic, as accessing one's Lightning funds on-chain requires paying fees to put transactions on-chain, and those fees cannot be paid using one's Lightning funds (due to the delay mentioned above).
Thus, while Lightning can be used for most of a user's funds, the user must also be able to access some bitcoin (enough to pay transaction fees) without any delays.

Fortunately, timeout-trees can be used to provide casual users with immediately-accessible off-chain bitcoin in addition to bitcoin in Lightning channels.
Furthermore, it's possible to use a control output owned by a casual user to rollover the casual user's immediately-accessible bitcoin from one timeout-tree to the next along with their Lightning funds [3].
In fact, this rollover can also be done without requiring any actions from the casual user and it can be used to rebalance the fraction of the user's funds that are immediately-accessible versus within Lightning [3].

Control UTXOs
=============

The FFO-WF protocol (as adapted for timeout-trees) requires that each casual user own an independent UTXO that is spent by that user's control transactions.
Creating an on-chain UTXO for every casual user could require a significant on-chain footprint, thus limiting scalability.
Instead, each casual user can be given an off-chain UTXO that is created by a leaf of a tree of off-chain transactions defined by covenants [3].

Improving Capital Efficiency
============================

In order to rollover funds from one timeout-tree to another, the dedicated user creating those timeout-trees must fund both the old and new timeout-trees simultaneously, even though they only create one timeout-tree's worth of Lightning channel capacity.
Fortunately, this overhead can be made very small by funding multiple timeout-trees in a staggered fashion, where only one has to be rolled-over at a time [3].

Also, because casual users may send and receive payments infrequently, the dedicated user's capital devoted to timeout-trees may generate few routing fees.
As a result, casual users may have to pay significant fees for the creation of their Lightning channels (and/or for payments to or from those channels).

However, the fees that casual users have to pay could be reduced if the capital in their channels could also be used for routing payments between other users.
This can be accomplished by having the timeout-trees create hierarchical channels, each of which is owned by a single casual user and a pair of dedicated users [7].
By using an idea created by Towns [10][11][3], a single unit of capital in each hierarchical channel can be used to route two independent payments of one unit each.

Scalability
===========

The above protocols can perform the following actions completely off-chain:
* Lightning sends and receives, and
* resizing of Lightning channels.

Assuming:
* 1 million hierarchical Lightning channels per timeout-tree,
* a 1,000-block (about a week) to_self_delay parameter for dedicated users, and
* a 10,000-block (about 69 days) to_self_delay parameter for casual users, and
* 121,000 blocks (about 2.3 years) from the creation of each timeout-tree to its expiry,

a single 1-input/2-output transaction per block provides:
* 11 Lightning channels per casual user to each of 10 billion casual users [3].

Furthermore, given the above assumptions, a single 1-input/2-output transaction per block allows each casual user to:
* close an existing Lightning channel,
* open a new Lightning channel with a new partner, and
* rebalance funds between Lightning and immediately-accessible off-chain bitcoin
once every 10,000 blocks (about 69 days) [3].

Of course, the above calculations don't mean that 10 billion casual Lightning users would create only 1 on-chain transaction per block.
In reality, their on-chain footprint would be dominated by users who don't follow the protocol due to errors, unavailability, or malicious intent.
The rate of such protocol violations is hard to predict, but it's likely that casual users' unavailability would be the most significant problem.

Usability
=========

The above protocols have the following properties for casual users:
* watchtower-freedom (that is, they accommodate months-long unavailability without requiring a watchtower service to secure the user's funds) ([5] Section 3.1),
* one-shot receives (that is, receiving a payment does not require performing actions at multiple blockheights) ([5] Section 3.4),
* asynchronous receives (that is, it's possible to receive a payment when the sender is offline) ([5] Section 3.6), and
* tunable penalties for attempting to put an old state on-chain ([12]).

Limitations
===========

Finally, the above results depend on the following assumptions:
1) the cost of resolving an HTLC on-chain is less than the value of the HTLC,
2) transaction packages are relayed reliably from users to miners, and
3) there is a known upper bound on the delay from when a package is submitted to when it is included in the blockchain.

These limitations, and ideas for how they can be addressed, are discussed further in the paper [3].

Conclusions
===========

With the current Bitcoin consensus rules, there are reasons to believe that the scalability of Lightning is inherently limited.
However, simple covenants and timeout-trees can overcome these scalability limitations.
In particular, CheckTemplateVerify (CTV) and/or AnyPrevOut (APO) could be used to dramatically increase the number of casual users who send and receive bitcoin in a trust-free manner.
As a result, it's hoped that CTV, APO or a similar mechanism that enables simple covenants will be added to Bitcoin's consensus rules in order to allow Lightning to become a widely-used means of payment.

Regards,
John

[1] BIP 119 CHECKTEMPLATEVERIFY, https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[2] BIP 118 SIGHASH_ANYPREVOUT, https://anyprevout.xyz/
[3] Law, "Scaling Lightning With Simple Covenants", https://github.com/JohnLaw2/ln-scaling-covenants
[4] "BOLT (Basis Of Lightning Technology) specifications", https://github.com/lightningnetwork/lightning-rfc
[5] Law, "Watchtower-Free Lightning Channels For Casual Users", https://github.com/JohnLaw2/ln-watchtower-free
[6] Law, "Factory-Optimized Channel Protocols For Lightning", available at https://github.com/JohnLaw2/ln-factory-optimized.
[7] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[8] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Micropayment Channel Networks", http://dx.doi.org/10.1098/rsos.180089
[9] Law, "Scaling Bitcoin With Inherited IDs", https://github.com/JohnLaw2/btc-iids
[10] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003913.html
[11] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003917.html
[12] Law, "Lightning Channels With Tunable Penalties", https://github.com/JohnLaw2/ln-tunable-penalties

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/20230908/90196255/attachment-0001.html>;

📅 Original date posted:2023-04-28 🗒️ Summary of this ...

2023-06-09T13:13:00Z

In reply to nevent1q…t0ld
_________________________

📅 Original date posted:2023-04-28
🗒️ Summary of this message: A discussion on the terminology used in Lightning Network, including the definition of terms such as "node" and "channel", and suggestions for alternative terms like "channel co-op". There is also a suggestion to write a BOLT/BLIP for a single channel backed by multiple on-chain utxos.
📝 Original message:
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
> node) and K (utxos per channel) are probably constant or logarithmic in
> N, so it's probably okay?

Yep, I'd assume C and K are largely independent of N (and constant or nearly so as the network grows), so that shouldn't be a problem.

> 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 storing it anyway,
> so it's probably fine.

It would be possible to have a separate rebalancing network consisting of multi-user parties only and a base network consisting of single-user parties only. However, that both complicates and limits the rebalancing functionality.

Let's say A and B want to decrease the size of their channel (A,B) using the separate rebalancing network.

They make a payment on the rebalancing network:

AB->CD->EF->GH->IJ

However, there are two problems with this approach:

1) A and B have to find another channel (I,J) that wants to increase its capacity by exactly the same amount (minus fees) to offset the decrease in (A,B). In general, the rebalancing network can move capacity from one base channel (a.k.a., two-user channel or channel with single-user parties) to another one, but it can't increase or decrease the overall capacity of the channels in the base network.

2) The payment AB->CD->EF->IJ not only rebalances channels, it also sends bitcoin from the payer in (A,B) to the payee in (I,J). This would have to be offset by making a corresponding payment (using the base network) from the payee in (I,J) (e.g., I) to the payer in (A,B) (e.g., A) and that offsetting payment would have to be atomic with the rebalancing payment. It's possible to make this work by using the same secret for the payments in the base network and the rebalancing network, but it certainly adds complexity.

In addition, there are reasons for wanting to include multi-user parties when making regular LN payments (again, see below).

Connecting the level-2 routing nodes with the level-1 routing nodes requires at least some channels that consist of a multi-user party and a single-user party, such as the channel ((C,D),E). Once that's done, the above problems go away and it's possible to increase or decrease the overall capacity of the two-user channels without going on-chain.

> > Finally, I realize that creating a world without factories doesn't sound like a good solution for scaling Bitcoin. However, I believe hierarchical channels largely solve the problem of resizing channels off-chain.

> I think this is probably a lot harder in practice than in theory? If
> you have an {A,B} channel holding 3 BTC across two hierarchial channels,
> {X:1 BTC, AB:1 BTC} and {Y:1 BTC, AB:2 BTC}, and someone wants to route
> 0.5 BTC through X->AB->Y, then that will look something like:

> {X:1, AB:1} {AB:2, Y:1}

> {X:0.5, XAB:0.5, AB:1} {AB:2, Y:1}

> {X:0.5, XAB:0.5, AB:1} {AB:1.5, ABY:0.5 Y:1}

> and either:

> {X:1, AB:1} {AB:2, Y:1} (on failure)
> or
> {X:0.5, AB:1.5} {AB:1.5, Y:1.5} (on success)

> But what if you're in the middle of routing 2 BTC over the A,B channel
> in the meantime? In that case you need some of the AB payments to be
> conditional on the success path of XAB and the failure path of ABY.

> I *think* that's fine, and doesn't involve a combinatorical blowup in
> the event that you're routing rebalances across multiple off-chain utxos
> -- you just end up splitting your channel across {X+2*Y} utxos where X
> is the number of "physical" channels and "Y" is the number of pending
> rebalances. But it seems like there's a fair chunk of complexity and
> maybe some extra round trips (eg, moving a pending HTLC from being
> purely in the AB:2 output to being split across the {XAB:0.5/success and
> ABY:0.5/timeout} atomically seems tricky?).

Wow, that's a cool idea!

I hadn't considered having an active HTLC (sending 2 BTC from A to B) that's (partially) funded by a pair of active HTLCs (sending 0.5 BTC from X to Y via the path X->AB->Y). I figured that would be too complex, but I hadn't thought through the details.

In contrast, I had considered having an active HTLC that's funded by a resolved (either successful or failed) HTLC. This seems important, as the resolved HTLC requires 3+ signatures in order to merge it into a new Commitment transaction, so it might not be possible to get all the signatures right away. For example, dedicated users A and B want to be able to use their newly-gained capacity in the channel (C,(A,B)) after making a payment from casual user C without having to wait for C to update the state of (C,(A,B)).

The hierarchical channels paper requires that all the funds in an HTLC be provided by a single user, denoted as the "payer". As a result, the capital in a hierarchical channel can only be used for a single active HTLC at a single level at a time. This requires multiplexing the capital between level-1 channel HTLCs and level-2 channel HTLCs, but I figured that was OK as the level-2 channels would mainly be used for rebalancing, which should be far less frequent than level-1 payments (and the rebalancing could wait until a path was available). Thus, one doesn't have to allow an active HTLC to be funded by a pair of active HTLCs in order to have flexible off-chain rebalancing of channels.

However, as you point out, it should be possible to have an active HTLC be funded by a pair of active HTLCs. The thing that's amazing about this is that the *same capital* is used for routing at two different levels in the hierarchy simultaneously! In other words, in addition to routing normal LN payments through single-user parties, it's possible to simultaneously route independent normal LN payments through multi-user parties by re-using the *same capital*.

Sure, the payments through multi-user parties require more signatures, so that could slow them down or complicate them, but the potential to maybe double the routing fees that can be generated from a given unit of capital (in addition to enabling off-chain rebalancing) sounds pretty compelling if the cost of capital is high.

As you noted, making this work atomically is tricky. Let's consider your example again, using slightly modified notation.

Initially, there's an {A,B} channel holding 3 BTC across two hierarchical channels:

State 0:
{X:1 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{A:2 BTC, B:0 BTC}, Y:1 BTC}

First, A initiates a payment of 2 BTC with secret s1 via B in the hierarchical channel with Y:

State 1:
{X:1 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:2 BTC}, Y:1 BTC}

Then, while this payment is pending, X sends 0.5 BTC with secret s2 to Y via the following states:

State 2:
{X:0.5 BTC, X_or_s2_{A_or_s1_B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:2 BTC}, Y:1 BTC}

State 3:
{X:0.5 BTC, X_or_s2_{A_or_s1_B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:1.5 BTC}, {A_or_s1_B:0.5 BTC}_or_s2_Y:0.5 BTC, Y:1 BTC}

>From this point, there are 8 possibilities in terms of whether the HTLCs succeed or fail, and in which order they do so.

For example, if s1 is revealed and then the payment with secret s2 times out, we get:

State 4:
{X:0.5 BTC, X_or_s2_{B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{B:1.5 BTC}, {B:0.5 BTC}_or_s2_Y:0.5 BTC, Y:1 BTC}

State 5:
{X:0.5 BTC, X:0.5 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{B:1.5 BTC}, {B:0.5 BTC}, Y:1 BTC}

State 6:
{X:1.0 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{A:0 BTC, B:2.0 BTC}, Y:1 BTC}

Alternatively, if s2 is revealed and then s1 is revealed, we get:

State 4':
{X:0.5 BTC, {A_or_s1_B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:1.5 BTC}, Y:0.5 BTC, Y:1 BTC}

State 5':
{X:0.5 BTC, {B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{B:1.5 BTC}, Y:0.5 BTC, Y:1 BTC}

State 6':
{X:0.5 BTC, {A:0.5 BTC, B:1 BTC}}
and
{{A:0 BTC, B:1.5 BTC}, Y:1.5 BTC}

The trickiest step is defining State 2. When A and B get the HTCL offered by X with secret s2, A and B figure out what they're going to give up in the hierarchical channel with Y in case the payment from X succeeds. Given that all of A's and B's capital in {{A_or_s1_B:2 BTC}, Y:1 BTC} is in the HTLC with secret s1, they take 0.5 BTC of that HTLC and add it as the payout from secret s2 in the channel with X to obtain State 2. Then, they update the channel with Y to obtain State 3.

This seems to address the atomicity issue. However, there are a couple other details to address in the hierarchical channel protocol.

First, in the adaptation of the FFO protocol to hierarchical channels, the "payee" for an HTLC is the user that must provide the HTLC's secret with an HTLC-kickoff transaction (see Figure 14 in the paper). However, when the HTLC pays to a lower-level HTLC, there is no single "payee" that can be determined. This could be addressed by enabling both users that could be payees to reveal the HTLC's secret with an HTLC-kickoff transaction followed by an HTLC-success transaction (note that this doubles the number of HTLC-payment transactions that are required).

Second, in going from HTLCs to PTLCs, the payee has to create a secret that's subtracted from the secret that's revealed at the payment's next hop. The challenge is how to define a secret that depends on multiple potential payees' secrets. I think it may be possible to solve this by having all potential payees at hop i create their own secret, define the overall secret at hop i as being the sum of the potential payees' secrets (after protecting against key/secret cancellation), and sharing partial signatures between potential payees at hop i such that each potential payee just needs to get hop (i+1)'s secret in order to produce hop (i)'s overall secret, but I haven't worked through the details.

To be clear, the idea of having an active HTLC that's funded by a pair of active HTLCs is your idea, and it's very interesting. We don't need to support this in order to resize channels off-chain, but it does allow a given unit of capital to facilitate two independent payments simultaneously, which is amazing!

> (I figure implementing something eltoo-like via 2-user tunable penalty
> channels and/or ln-symmetry (let alone splicing, taproot funding
> addresses, and ptlcs) is a sufficient sink for all the available
> engineering effort any time soon, but talking about hierarchial/factory
> things well in advance of when they could reasonably be implemented is
> fun too)

That makes sense.

I'm also hoping that a good understanding of what's possible without changing Bitcoin, plus what's enabled with changes like CTV and/or APO, will help inform any future changes to Bitcoin's consensus rules.

Regards,
John

📅 Original date posted:2023-04-18 🗒️ Summary of this ...

2023-06-09T13:12:59Z

In reply to nevent1q…jvt5
_________________________

📅 Original date posted:2023-04-18
🗒️ Summary of this message: To understand routing in Lightning Network, it's important to define terms like user, party, node, physical channel, and logical channel. Hierarchical channels exist without factories.
📝 Original message:
> 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 fees/max_htlc/etc.

In addition to the assumptions and definitions above, we need to use Rusty Russell's idea for channel_update_v2 messages [1].

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 explicitly link "FG" with "F" and "G". "FG", "F" and "G" each have their own identity in the LN's Onion network and each one appears as a separate node in the routing graph, with no explicit linkage between them. Every logical channel in the channel graph is announced with channel_update_v2 messages that provide the channel's current capacity and refer back to an on-chain UTXO. It's possible, but not necessary, that some of the logical channels between "FG" and other nodes, between "F" and other nodes, and between "G" and other nodes, use the same on-chain UTXO for their channel_update_v2 messages.

Q: How do you decide fees?
A: All of the users that own a given logical channel negotiate the routing fees that they want to charge. These routing fees are of two types: 1) a fee for devoting capital (by being the "payer" or "payee" as defined in the paper), and 2) a fee for providing signatures without devoting capital. For example, in order to traverse the logical channel ((A,B),(C,D)) (where A, B, C and D are dedicated users, A is the "payer", and C is the "payee"), C will get a payment for devoting capital and D will get a payment for providing signatures. It's reasonable to assume that the sum of these fees will be larger than the fees charged by most non-hierarchical channels, so it's reasonable to assume that the logical channel ((A,B),(C,D)) will be used more often as the first or last hop in a payment (in order to resize (A,B) or (C,D), but not both of them), rather than as an intermediate hop in a payment.

Q: How do you communicate fees/max_htlc/etc.?
A: Just like you do today, with the only difference being that a specific user within each node should handle the Onion traffic for that node and (and should forward it to the other users within that node, if it's a multi-user node). This user could be called the "leader" for the node. I didn't describe this detail in the paper, but I could add it if you think it would be helpful.

> I think it also implies that channel
> capacity is no longer really something you can gossip very sensibly --

Given the above definitions and assumptions, including the use of channel_update_v2 messages, I think you can gossip channel capacity quite reasonably.

As is shown in the paper, just routing through a logical channel does *not* change its capacity (except for a slight increase due to fees). The only time a channel capacity changes significantly is when it is being resized by being the source or destination of a LN payment. The new capacity will be broadcast in the next weekly channel_update_v2 message. Obviously, there's some potential for an unexpected inability for a channel to route requested payments before the channel_update_v2 message showing a reduced capacity has been received, but nothing actually breaks. Of course, it may be worth sending out a channel_update_v2 message as soon as a channel is resized.

> 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.

First, let's translate this example into one without factories (as that's the world I'm envisioning). Let's assume we have logical channals ((A,B),C), ((A,B),D) and ((A,B),D).

Let's assume that C sends a payment to some other random user/node G that is routed through AB. In this case, the logical channel between A and B does *not* change capacity (except for growing slightly due to fees)! This is shown in Figures 8 and 9 of the paper (with "BC" in those figures playing the role of "AB" described here). That's the beauty of using logical, rather than physical, channels in the channel graph.

It took me a long time to see this and I obviously have not succeeded in explaining it very well. Please let me know if this example isn't clear, in which case I'll try to find a better way of explaining it.

> 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.

I think the above approach solves these problems. Please let me know if I've missed something.

Finally, I realize that creating a world without factories doesn't sound like a good solution for scaling Bitcoin. However, I believe hierarchical channels largely solve the problem of resizing channels off-chain. This still leaves the problem of creating channels off-chain, but I don't think we need factories to solve that problem. The key observation is that we don't need to create a factory with *updatable* state in order to create a huge number of channels off-chain. Instead, we just need something that instantiates all of those off-chain channels in a way that guarantees the off-chain UTXOs creating those factories. I think the solution to this simpler problem is Timeout-Trees, but I still need to write that up. In any case, please consider hierarchical channels as being a partial solution to scaling Bitcoin and wait until I can make the case for Timeout-Trees before evaluating whether or not we need factories.

> 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...

Thanks!

I really appreciate your working through all of these issues.

Regards,
John

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html

📅 Original date posted:2023-04-08 🗒️ Summary of this ...

2023-06-09T13:12:59Z

In reply to nevent1q…wxv3
_________________________

📅 Original date posted:2023-04-08
🗒️ Summary of this message: The proposed Factory Optimized protocols for Lighting aim to improve channels within factories, reducing state compared to the "tunable penalties" approach.
📝 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 date posted:2023-04-08 🗒️ Summary of this ...

2023-06-09T13:12:58Z

In reply to nevent1q…y8qz
_________________________

📅 Original date posted:2023-04-08
🗒️ Summary of this message: A new construction called "tunable penalties" allows for a 2-party lightning channel where cheating doesn't result in losing all funds. It is an improvement on ln-penalty.
📝 Original message:
Comments below:

>> Step 1: Tunable penalties;
>> <a href="https://github.com/JohnLaw2/ln-tunable-penalties">https://github.com/JohnLaw2/ln-tunable-penalties</a>;
>> <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html</a>;

>> 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

📅 Original date posted:2023-04-03 🗒️ Summary of this ...

2023-06-09T13:12:58Z

In reply to nevent1q…ezjj
_________________________

📅 Original date posted:2023-04-03
🗒️ Summary of this message: The proposed tunable penalties offer offchain channel resizes and liquidity multiplexing, but the former can already be achieved with existing techniques using channel factories.
📝 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 date posted:2023-03-17 🗒️ Summary of this ...

2023-06-09T13:12:53Z

In reply to nevent1q…yt3p
_________________________

📅 Original date posted:2023-03-17
🗒️ Summary of this message: Hierarchical channels allow for flexible, off-chain resizing of Lightning channels, solving issues with on-chain resizing and channel factories. No changes to Bitcoin protocol needed.
📝 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 date posted:2023-01-15 🗒️ Summary of this ...

2023-06-09T13:12:32Z

In reply to nevent1q…ge8y
_________________________

📅 Original date posted:2023-01-15
🗒️ Summary of this message: New protocols for Lightning factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions have been presented, which are essential for scaling the Lightning Network. The Tunable-Penalty Factory (TPF) protocol requires P different transactions to instantiate the factory's channels, while the Single-Commitment (SC) protocol uses only a single transaction.
📝 Original message:
TL;DR
=====

* Factories that create and update a large number of Lightning channels efficiently are essential for scaling the Lightning Network.
* This post presents the first known protocol for Lightning factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions.
- If P parties use the protocol, they create P conflicting Commitment transactions, any of which can be used to establish the factory's state.
- As a result, each party must maintain P copies of the state of each channel created by the factory.
- Another factory protocol is presented that eliminates the need to maintain P copies of each channel state (at the expense of requiring more on-chain bytes).
* Both factory protocols are modifications of the Tunable-Penalty Channel protocol and share many of its properties, including:
- tunable penalties for putting old transactions on-chain, and
- watchtowers with storage that's logarithmic in the number of factory states supported (but linear in the number of parties in the factory).

Overview
========

Factories that allow multiple two-party Lightning channels to be created, re-sized and closed with a small number of on-chain transactions are essential to the scalability of Bitcoin [2].
Let P denote the number of parties, C denote tha number of channels created, and S denote the number of factory states supported.
The most efficient previously-known factory, created by Burchert, Decker and Wattenhofer [2], can be closed unilaterally in O(log S) time using O(log S) on-chain transactions and O(C + log S) on-chain bytes.
A single fixed transaction is used to instantiate the factory's channels when it's closed unilaterally, so the parties using the factory can maintain just a one version of each off-chain channel state.
Performing a unilateral close with O(log S) on-chain transactions requires that the party closing the factory interact with the blockchain at O(log S) different blockheights (so a unilateral close is an O(log S)-shot procedure [4]), which could be awkward for some users [8].

This paper presents two protocols for factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions.
The first protocol, called the Tunable-Penalty Factory (TPF) protocol, requires only O(C) on-chain bytes for a unilateral close, but it can use P different transactions to instantiate the factory's channels, thus forcing the parties using the factory to maintain P different versions of each off-chain channel state.
The second protocol, called the Single-Commitment (SC) protocol, requires O(C + log S) on-chain bytes for a unilateral close, but it uses only a single transaction to instantiate the factory's channels, so multiple versions of off-chain channel states aren't required.
The TPF protocol is particularly simple and allows a 2-shot unilateral close (that is, the party closing the channel only has to perform actions at 2 different blockheights).

Both protocols are based on the Tunable-Penalty Channel (TPC) protocol [5] and they share many of its properties, including:
* tunable penalties for putting old transactions on-chain, and
* watchtowers with storage that's logarithmic in the number of factory states supported (but linear in the number of parties in the factory).

No change to the underlying Bitcoin protocol is required.

A more complete description, including a proof of correctness and better figures, is available in a paper [6].

The Tunable-Penalty Factory (TPF) Protocol
==========================================

The TPF protocol is a slight modification of the TPC protocol [5].

Each party using the TPC protocol has their own on-chain Individual transaction, the output of which they spend with their State transaction.
This State transaction is a control transaction and its first output's value is equal to the desired penalty for putting an old State transaction on-chain.
This first output can be spent by the same party's Commitment transaction for the same state, but only after a relative delay equal to the maximum of the parties' to_self_delay parameters.
The relative delay gives the other party time to revoke an old State transaction by spending its first output and thus claiming the penalty.
The State transaction also has an HTLC control output for each HTLC that is active in that state.
The TPC protocol revokes old State transactions with per-commitment keys that can be known to all parties, rather than with revocation keys that cannot be known by the party putting the revocable transaction on-chain [5].

The TPC protocol is modified to create the TPF protocol by:
* eliminating the HTLC control outputs from the State transactions,
* modifying the Commitment transactions to have channel outputs, each of which is owned by two parties in the factory, and
* supporting P > 2 parties by allowing each party to have their own Individual, State and Commitment transactions.

The TPF protocol is shown below:

+-+ A..Z +----+ AD
|F|------+-------------------------| CC |-----
+-+ | | |
| | | BC
| | |-----
| | |
. | | MZ
. | |-----
. +----+
|
| +----+ AD
+-------------------------|C_Ai|-----
| | |
| | | BC
| | |-----
| | |
| tsdAZ & A | | MZ
| +-----------| |-----
| | +----+
| |
| | +----+ AD
+-------------------------|C_Bi|-----
| | | |
| | | | BC
| | | |-----
| | | |
. | tsdAZ & B | | MZ
. +-------------| |-----
. | | +----+
| | |
| | | +----+ AD
+-------------------------|C_Zi|-----
| | | | |
. | | | | BC
. | | | |-----
. | | | |
| | | tsdAZ & Z | | MZ
V +---------------| |-----
| | | +----+
| | |
+----+ A +-----+ | | | pckeyAi
|In_A|----|St_Ai|------+-----------
+----+ | | | |
+-----+ | |
| |
+----+ B +-----+ | | pckeyBi
|In_B|----|St_Bi|----+-------------
+----+ | | |
+-----+ |
. . .
. . .
. . .
|
+----+ Z +-----+ | pckeyZi
|In_Z|----|St_Zi|--+---------------
+----+ | |
+-----+

where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
In_{A..Z} is {A..Z's} Individual transaction,
St_{A..Z}i is {A..Z's} State transaction for state i, and
C_{A..Z}i is {A..Z's} Commitment transaction for state i.

Requirements for output cases are as follows:
{A..Z}: {A..Z}'s signature (a single party's signature),
A..Z: A..Z's signature (every parties' signature),
pairs of capital letters indicate signatures from those two parties,
pckey{A..Z}i: a signature using a per-commitment key for revoking {A..Z}'s state i transaction, and
tsdAZ: a relative delay equal to the maximum of {A..Z}'s to_self_delay parameters.

In order to establish a new factory state, all parties:
* calculate the State and Commitment transactions for the new state (this step includes exchanging per-commitment pubkeys for the new state with each of the other parties),
* exchange partial signatures for the new state's Commitment transactions, and
* exchange per-commitment keys for the old state, thus revoking it.

All parties constantly look for old (revoked) State transactions put on-chain by other parties, and if they find such a transaction they use the corresponding per-commitment key to spend its first output, thus obtaining the penalty funds and revoking the old state.
Once a State transaction has been on-chain for tsdAZ without its first output being spent, the party that put the State transaction on-chain can attempt to put their corresponding Commitment transaction on-chain at any time.
Any party can close the factory unilaterally by putting their current State transaction on-chain, waiting until it has been on-chain for tsdAZ, and then submitting their corresponding Commitment transaction to the blockchain.

As was the case with the TPC protocol, per-commitment keys can use the Lightning protocol's compact storage technique for revocation keys to consume only O(log S) storage to revoke a maximum of S old transactions that could be put on-chain by a single other party [7][5].
Therefore, each party requires O(P*log S) storage to hold the per-commitment keys for all of the P parties.

The Single-Commitment (SC) Factory Protocol
===========================================

Note that the TPF factory protocol uses P conflicting Commitment transactions to establish the factory state and to instantiate the factory's channels.
Therefore, a separate channel state must be maintained and updated for each of the P versions of the channel that could be instantiated, thus increasing the computation, storage, and communication for channels by a factor of P.
The result could be quite expensive if there are a large number of parties in the factory.

The SC protocol eliminates this factor of P blow-up by having all of the parties use a single shared Commitment transaction.
Like the TPF protocol, the SC protocol uses revocable State transactions, each of which spends a single party's Individual transaction output, to ensure that only the current Commitment transaction can be put on-chain.
The challenge is how to use a single shared Commitment transaction that depends on the value of an unrevoked State transaction without actually spending any of the outputs of that State transaction (as spending a State transaction output would make the Commitment transaction's input dependent on which party's State transaction it spends, thus preventing the use of a single shared Commitment transaction).
This challenge is solved by introducing a shared Trigger transaction and a per-user Mold transaction, where the Commitment and Mold transactions compete for the Trigger transaction's outputs.
The Mold transaction is put on-chain prior to the Commitment transaction, and it constrains the Commitment transactions that can be put on-chain somewhat like how a mold shapes a liquid that is poured into it.

Specifically, the Trigger transaction has one value output and log_2(S) control outputs, numbered 0 .. log_2(S) - 1. Commitment transaction i, 0 <= i <= S - 1, spends those Trigger control outputs b, 0 <= b <= log_2(S) - 1, such that bit position b of the binary representation of i is a 0.
Each Mold transaction i, 0 <= i <= S - 1, spends the output of the same party's State i transaction, and Trigger control outputs b, 0 <= b <= log_2(S) - 1, such that bit position b of the binary representation of i is a 1.
This construction guarantees that if a Mold transaction for state i is on-chain, only Commitment transactions for states j >= i can be put on-chain.

States 0 through S - 1 are supported, with the exception of states of the form 2^b where 1 <= b <= log_2(S) - 1.
These exceptions are made to guarantee that it is impossible to put Mold transactions on-chain for two consecutive states (other than states 0 and 1) where they would prevent any current Commitment transaction from being put on-chain.
When state i is supported but state i+1 is not, the next state after i is i+2.

The protocol operation is similar to that of the TPF protocol, except parties closing the channel unilaterally submit the Trigger transaction and their current State transaction to the blockchain, and once their State transaction has been on-chain for tsdAZ, submit their Mold transaction for the same state to the blockchain.
Once the Trigger transaction has been on-chain for 3tsdAZ, they submit to the blockchain the Commitment transaction for the same state as the on-chain Mold transaction.

Also, all parties monitor the blockchain for the Trigger transaction, and if they find it they use the above protocol for closing the factory as soon as possible.

Because only Mold transactions for unrevoked State transactions can be put on-chain, and because only the latest State transactions can be unrevoked, only the latest (and thus current) Commitment transactions can be put on-chain.

A figure for the SC protocol, and a detailed proof of correctness, are in the paper [6].

Related Work
============

The concept of creating a channel factory for Lightning, as well as the most efficient published protocol for such a factory, was presented by Burchert, Decker and Wattenhofer [2].
The protocols presented here differ in only requiring O(1) time and O(1) on-chain transactions for a unilateral factory close.

A number of researchers have proposed changes to Bitcoin in order to support simpler and more efficient factories.
The eltoo factory protocol [3] has a particularly simple structure and it allows the parties to maintain only one version of each off-chain channel state.
It requires O(1) time, O(1) on-chain transactions and O(1) on-chain bytes for a unilateral close.
However, a malicious party could delay the closing of the factory until O(S) transactions are put on-chain, if the malicious party is willing to pay the required fees.
The eltoo protocol differs from the protocols presented here by requiring a change to Bitcoin, namely the support for BIP 118 [1].

The TPF and SC protocols are based on the TPC protocol presented by Law [5].

Conclusions
===========

This post presents new factory protocols that require O(1) time and O(1) on-chain transactions for a unilateral close.
They are the first factory protocols known that achieve those bounds with the existing Bitcoin protocol.

The ability to unilaterally close a factory with just two or three submissions to the blockchain, with a fixed delay between them, is quite a bit simpler than closing previously-published factories [2].
As a result, it's hoped that TPF and SC factories will lead to the increased use of factories in practice, thus improving the scalability of Bitcoin and Lightning.

Regards,
John

References
==========
[1] "BIP 118: SIGHASH_ANYPREVOUT", available at https://anyprevout.xyz/ and https://github.com/bitcoin/bips/pull/943.
[2] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Micropayment Channel Networks", available at http://dx.doi.org/10.1098/rsos.180089.
[3] Decker, Russell and Osuntokun. eltoo: A Simple Layer2 Protocol for Bitcoin. Available at https://blockstream.com/eltoo.pdf.
[4] Law, "Watchtower-Free Lightning Channels For Casual Users", available at https://github.com/JohnLaw2/ln-watchtower-free.
[5] Law, "Lightning Channels With Tunable Penalties", available at https://github.com/JohnLaw2/ln-tunable-penalties.
[6] Law, "Efficient Factories For Lightning Channels", available at https://github.com/JohnLaw2/ln-efficient-factories.
[7] Russell, "Efficient Per-Commitment Secret Storage", available at https://github.com/lightning/bolts/blob/master/03-transactions.md#efficient-per-commitment-secret-storage.
[8] ZmnSCPxj, "Channel Eviction From Channel Factories By New Covenant Operations", available at https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.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/20230115/1c24b7f0/attachment-0001.html>;

📅 Original date posted:2023-04-28 📝 Original message: ...

2023-06-09T13:08:28Z

In reply to nevent1q…yk9a
_________________________

📅 Original date posted:2023-04-28
📝 Original message:
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
> node) and K (utxos per channel) are probably constant or logarithmic in
> N, so it's probably okay?

Yep, I'd assume C and K are largely independent of N (and constant or nearly so as the network grows), so that shouldn't be a problem.

> 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 storing it anyway,
> so it's probably fine.

It would be possible to have a separate rebalancing network consisting of multi-user parties only and a base network consisting of single-user parties only. However, that both complicates and limits the rebalancing functionality.

Let's say A and B want to decrease the size of their channel (A,B) using the separate rebalancing network.

They make a payment on the rebalancing network:

AB->CD->EF->GH->IJ

However, there are two problems with this approach:

1) A and B have to find another channel (I,J) that wants to increase its capacity by exactly the same amount (minus fees) to offset the decrease in (A,B). In general, the rebalancing network can move capacity from one base channel (a.k.a., two-user channel or channel with single-user parties) to another one, but it can't increase or decrease the overall capacity of the channels in the base network.

2) The payment AB->CD->EF->IJ not only rebalances channels, it also sends bitcoin from the payer in (A,B) to the payee in (I,J). This would have to be offset by making a corresponding payment (using the base network) from the payee in (I,J) (e.g., I) to the payer in (A,B) (e.g., A) and that offsetting payment would have to be atomic with the rebalancing payment. It's possible to make this work by using the same secret for the payments in the base network and the rebalancing network, but it certainly adds complexity.

In addition, there are reasons for wanting to include multi-user parties when making regular LN payments (again, see below).

Connecting the level-2 routing nodes with the level-1 routing nodes requires at least some channels that consist of a multi-user party and a single-user party, such as the channel ((C,D),E). Once that's done, the above problems go away and it's possible to increase or decrease the overall capacity of the two-user channels without going on-chain.

> > Finally, I realize that creating a world without factories doesn't sound like a good solution for scaling Bitcoin. However, I believe hierarchical channels largely solve the problem of resizing channels off-chain.

> I think this is probably a lot harder in practice than in theory? If
> you have an {A,B} channel holding 3 BTC across two hierarchial channels,
> {X:1 BTC, AB:1 BTC} and {Y:1 BTC, AB:2 BTC}, and someone wants to route
> 0.5 BTC through X->AB->Y, then that will look something like:

> {X:1, AB:1} {AB:2, Y:1}

> {X:0.5, XAB:0.5, AB:1} {AB:2, Y:1}

> {X:0.5, XAB:0.5, AB:1} {AB:1.5, ABY:0.5 Y:1}

> and either:

> {X:1, AB:1} {AB:2, Y:1} (on failure)
> or
> {X:0.5, AB:1.5} {AB:1.5, Y:1.5} (on success)

> But what if you're in the middle of routing 2 BTC over the A,B channel
> in the meantime? In that case you need some of the AB payments to be
> conditional on the success path of XAB and the failure path of ABY.

> I *think* that's fine, and doesn't involve a combinatorical blowup in
> the event that you're routing rebalances across multiple off-chain utxos
> -- you just end up splitting your channel across {X+2*Y} utxos where X
> is the number of "physical" channels and "Y" is the number of pending
> rebalances. But it seems like there's a fair chunk of complexity and
> maybe some extra round trips (eg, moving a pending HTLC from being
> purely in the AB:2 output to being split across the {XAB:0.5/success and
> ABY:0.5/timeout} atomically seems tricky?).

Wow, that's a cool idea!

I hadn't considered having an active HTLC (sending 2 BTC from A to B) that's (partially) funded by a pair of active HTLCs (sending 0.5 BTC from X to Y via the path X->AB->Y). I figured that would be too complex, but I hadn't thought through the details.

In contrast, I had considered having an active HTLC that's funded by a resolved (either successful or failed) HTLC. This seems important, as the resolved HTLC requires 3+ signatures in order to merge it into a new Commitment transaction, so it might not be possible to get all the signatures right away. For example, dedicated users A and B want to be able to use their newly-gained capacity in the channel (C,(A,B)) after making a payment from casual user C without having to wait for C to update the state of (C,(A,B)).

The hierarchical channels paper requires that all the funds in an HTLC be provided by a single user, denoted as the "payer". As a result, the capital in a hierarchical channel can only be used for a single active HTLC at a single level at a time. This requires multiplexing the capital between level-1 channel HTLCs and level-2 channel HTLCs, but I figured that was OK as the level-2 channels would mainly be used for rebalancing, which should be far less frequent than level-1 payments (and the rebalancing could wait until a path was available). Thus, one doesn't have to allow an active HTLC to be funded by a pair of active HTLCs in order to have flexible off-chain rebalancing of channels.

However, as you point out, it should be possible to have an active HTLC be funded by a pair of active HTLCs. The thing that's amazing about this is that the *same capital* is used for routing at two different levels in the hierarchy simultaneously! In other words, in addition to routing normal LN payments through single-user parties, it's possible to simultaneously route independent normal LN payments through multi-user parties by re-using the *same capital*.

Sure, the payments through multi-user parties require more signatures, so that could slow them down or complicate them, but the potential to maybe double the routing fees that can be generated from a given unit of capital (in addition to enabling off-chain rebalancing) sounds pretty compelling if the cost of capital is high.

As you noted, making this work atomically is tricky. Let's consider your example again, using slightly modified notation.

Initially, there's an {A,B} channel holding 3 BTC across two hierarchical channels:

State 0:
{X:1 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{A:2 BTC, B:0 BTC}, Y:1 BTC}

First, A initiates a payment of 2 BTC with secret s1 via B in the hierarchical channel with Y:

State 1:
{X:1 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:2 BTC}, Y:1 BTC}

Then, while this payment is pending, X sends 0.5 BTC with secret s2 to Y via the following states:

State 2:
{X:0.5 BTC, X_or_s2_{A_or_s1_B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:2 BTC}, Y:1 BTC}

State 3:
{X:0.5 BTC, X_or_s2_{A_or_s1_B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:1.5 BTC}, {A_or_s1_B:0.5 BTC}_or_s2_Y:0.5 BTC, Y:1 BTC}

>From this point, there are 8 possibilities in terms of whether the HTLCs succeed or fail, and in which order they do so.

For example, if s1 is revealed and then the payment with secret s2 times out, we get:

State 4:
{X:0.5 BTC, X_or_s2_{B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{B:1.5 BTC}, {B:0.5 BTC}_or_s2_Y:0.5 BTC, Y:1 BTC}

State 5:
{X:0.5 BTC, X:0.5 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{B:1.5 BTC}, {B:0.5 BTC}, Y:1 BTC}

State 6:
{X:1.0 BTC, {A:0.5 BTC, B:0.5 BTC}}
and
{{A:0 BTC, B:2.0 BTC}, Y:1 BTC}

Alternatively, if s2 is revealed and then s1 is revealed, we get:

State 4':
{X:0.5 BTC, {A_or_s1_B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{A_or_s1_B:1.5 BTC}, Y:0.5 BTC, Y:1 BTC}

State 5':
{X:0.5 BTC, {B:0.5 BTC}, {A:0.5 BTC, B:0.5 BTC}}
and
{{B:1.5 BTC}, Y:0.5 BTC, Y:1 BTC}

State 6':
{X:0.5 BTC, {A:0.5 BTC, B:1 BTC}}
and
{{A:0 BTC, B:1.5 BTC}, Y:1.5 BTC}

The trickiest step is defining State 2. When A and B get the HTCL offered by X with secret s2, A and B figure out what they're going to give up in the hierarchical channel with Y in case the payment from X succeeds. Given that all of A's and B's capital in {{A_or_s1_B:2 BTC}, Y:1 BTC} is in the HTLC with secret s1, they take 0.5 BTC of that HTLC and add it as the payout from secret s2 in the channel with X to obtain State 2. Then, they update the channel with Y to obtain State 3.

This seems to address the atomicity issue. However, there are a couple other details to address in the hierarchical channel protocol.

First, in the adaptation of the FFO protocol to hierarchical channels, the "payee" for an HTLC is the user that must provide the HTLC's secret with an HTLC-kickoff transaction (see Figure 14 in the paper). However, when the HTLC pays to a lower-level HTLC, there is no single "payee" that can be determined. This could be addressed by enabling both users that could be payees to reveal the HTLC's secret with an HTLC-kickoff transaction followed by an HTLC-success transaction (note that this doubles the number of HTLC-payment transactions that are required).

Second, in going from HTLCs to PTLCs, the payee has to create a secret that's subtracted from the secret that's revealed at the payment's next hop. The challenge is how to define a secret that depends on multiple potential payees' secrets. I think it may be possible to solve this by having all potential payees at hop i create their own secret, define the overall secret at hop i as being the sum of the potential payees' secrets (after protecting against key/secret cancellation), and sharing partial signatures between potential payees at hop i such that each potential payee just needs to get hop (i+1)'s secret in order to produce hop (i)'s overall secret, but I haven't worked through the details.

To be clear, the idea of having an active HTLC that's funded by a pair of active HTLCs is your idea, and it's very interesting. We don't need to support this in order to resize channels off-chain, but it does allow a given unit of capital to facilitate two independent payments simultaneously, which is amazing!

> (I figure implementing something eltoo-like via 2-user tunable penalty
> channels and/or ln-symmetry (let alone splicing, taproot funding
> addresses, and ptlcs) is a sufficient sink for all the available
> engineering effort any time soon, but talking about hierarchial/factory
> things well in advance of when they could reasonably be implemented is
> fun too)

That makes sense.

I'm also hoping that a good understanding of what's possible without changing Bitcoin, plus what's enabled with changes like CTV and/or APO, will help inform any future changes to Bitcoin's consensus rules.

Regards,
John

📅 Original date posted:2023-04-08 📝 Original message: Hi ...

2023-06-09T13:08:27Z

In reply to nevent1q…zf8k
_________________________

📅 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 date posted:2023-04-18 📝 Original message: > ...

2023-06-09T13:08:27Z

In reply to nevent1q…udzl
_________________________

📅 Original date posted:2023-04-18
📝 Original message:
> 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 fees/max_htlc/etc.

In addition to the assumptions and definitions above, we need to use Rusty Russell's idea for channel_update_v2 messages [1].

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 explicitly link "FG" with "F" and "G". "FG", "F" and "G" each have their own identity in the LN's Onion network and each one appears as a separate node in the routing graph, with no explicit linkage between them. Every logical channel in the channel graph is announced with channel_update_v2 messages that provide the channel's current capacity and refer back to an on-chain UTXO. It's possible, but not necessary, that some of the logical channels between "FG" and other nodes, between "F" and other nodes, and between "G" and other nodes, use the same on-chain UTXO for their channel_update_v2 messages.

Q: How do you decide fees?
A: All of the users that own a given logical channel negotiate the routing fees that they want to charge. These routing fees are of two types: 1) a fee for devoting capital (by being the "payer" or "payee" as defined in the paper), and 2) a fee for providing signatures without devoting capital. For example, in order to traverse the logical channel ((A,B),(C,D)) (where A, B, C and D are dedicated users, A is the "payer", and C is the "payee"), C will get a payment for devoting capital and D will get a payment for providing signatures. It's reasonable to assume that the sum of these fees will be larger than the fees charged by most non-hierarchical channels, so it's reasonable to assume that the logical channel ((A,B),(C,D)) will be used more often as the first or last hop in a payment (in order to resize (A,B) or (C,D), but not both of them), rather than as an intermediate hop in a payment.

Q: How do you communicate fees/max_htlc/etc.?
A: Just like you do today, with the only difference being that a specific user within each node should handle the Onion traffic for that node and (and should forward it to the other users within that node, if it's a multi-user node). This user could be called the "leader" for the node. I didn't describe this detail in the paper, but I could add it if you think it would be helpful.

> I think it also implies that channel
> capacity is no longer really something you can gossip very sensibly --

Given the above definitions and assumptions, including the use of channel_update_v2 messages, I think you can gossip channel capacity quite reasonably.

As is shown in the paper, just routing through a logical channel does *not* change its capacity (except for a slight increase due to fees). The only time a channel capacity changes significantly is when it is being resized by being the source or destination of a LN payment. The new capacity will be broadcast in the next weekly channel_update_v2 message. Obviously, there's some potential for an unexpected inability for a channel to route requested payments before the channel_update_v2 message showing a reduced capacity has been received, but nothing actually breaks. Of course, it may be worth sending out a channel_update_v2 message as soon as a channel is resized.

> 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.

First, let's translate this example into one without factories (as that's the world I'm envisioning). Let's assume we have logical channals ((A,B),C), ((A,B),D) and ((A,B),D).

Let's assume that C sends a payment to some other random user/node G that is routed through AB. In this case, the logical channel between A and B does *not* change capacity (except for growing slightly due to fees)! This is shown in Figures 8 and 9 of the paper (with "BC" in those figures playing the role of "AB" described here). That's the beauty of using logical, rather than physical, channels in the channel graph.

It took me a long time to see this and I obviously have not succeeded in explaining it very well. Please let me know if this example isn't clear, in which case I'll try to find a better way of explaining it.

> 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.

I think the above approach solves these problems. Please let me know if I've missed something.

Finally, I realize that creating a world without factories doesn't sound like a good solution for scaling Bitcoin. However, I believe hierarchical channels largely solve the problem of resizing channels off-chain. This still leaves the problem of creating channels off-chain, but I don't think we need factories to solve that problem. The key observation is that we don't need to create a factory with *updatable* state in order to create a huge number of channels off-chain. Instead, we just need something that instantiates all of those off-chain channels in a way that guarantees the off-chain UTXOs creating those factories. I think the solution to this simpler problem is Timeout-Trees, but I still need to write that up. In any case, please consider hierarchical channels as being a partial solution to scaling Bitcoin and wait until I can make the case for Timeout-Trees before evaluating whether or not we need factories.

> 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...

Thanks!

I really appreciate your working through all of these issues.

Regards,
John

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html

📅 Original date posted:2023-04-03 📝 Original message: Hi ...

2023-06-09T13:08:26Z

In reply to nevent1q…cert
_________________________

📅 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 date posted:2023-04-08 📝 Original message: ...

2023-06-09T13:08:26Z

In reply to nevent1q…rkdm
_________________________

📅 Original date posted:2023-04-08
📝 Original message:
Comments below:

>> Step 1: Tunable penalties;
>> <a href="https://github.com/JohnLaw2/ln-tunable-penalties">https://github.com/JohnLaw2/ln-tunable-penalties</a>;
>> <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html</a>;

>> 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

📅 Original date posted:2023-03-17 📝 Original message: TL;DR ...

2023-06-09T13:08:20Z

In reply to nevent1q…0ved
_________________________

📅 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 date posted:2023-01-15 📝 Original message: TL;DR ...

2023-06-09T13:07:55Z

In reply to nevent1q…488h
_________________________

📅 Original date posted:2023-01-15
📝 Original message:
TL;DR
=====

* Factories that create and update a large number of Lightning channels efficiently are essential for scaling the Lightning Network.
* This post presents the first known protocol for Lightning factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions.
- If P parties use the protocol, they create P conflicting Commitment transactions, any of which can be used to establish the factory's state.
- As a result, each party must maintain P copies of the state of each channel created by the factory.
- Another factory protocol is presented that eliminates the need to maintain P copies of each channel state (at the expense of requiring more on-chain bytes).
* Both factory protocols are modifications of the Tunable-Penalty Channel protocol and share many of its properties, including:
- tunable penalties for putting old transactions on-chain, and
- watchtowers with storage that's logarithmic in the number of factory states supported (but linear in the number of parties in the factory).

Overview
========

Factories that allow multiple two-party Lightning channels to be created, re-sized and closed with a small number of on-chain transactions are essential to the scalability of Bitcoin [2].
Let P denote the number of parties, C denote tha number of channels created, and S denote the number of factory states supported.
The most efficient previously-known factory, created by Burchert, Decker and Wattenhofer [2], can be closed unilaterally in O(log S) time using O(log S) on-chain transactions and O(C + log S) on-chain bytes.
A single fixed transaction is used to instantiate the factory's channels when it's closed unilaterally, so the parties using the factory can maintain just a one version of each off-chain channel state.
Performing a unilateral close with O(log S) on-chain transactions requires that the party closing the factory interact with the blockchain at O(log S) different blockheights (so a unilateral close is an O(log S)-shot procedure [4]), which could be awkward for some users [8].

This paper presents two protocols for factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions.
The first protocol, called the Tunable-Penalty Factory (TPF) protocol, requires only O(C) on-chain bytes for a unilateral close, but it can use P different transactions to instantiate the factory's channels, thus forcing the parties using the factory to maintain P different versions of each off-chain channel state.
The second protocol, called the Single-Commitment (SC) protocol, requires O(C + log S) on-chain bytes for a unilateral close, but it uses only a single transaction to instantiate the factory's channels, so multiple versions of off-chain channel states aren't required.
The TPF protocol is particularly simple and allows a 2-shot unilateral close (that is, the party closing the channel only has to perform actions at 2 different blockheights).

Both protocols are based on the Tunable-Penalty Channel (TPC) protocol [5] and they share many of its properties, including:
* tunable penalties for putting old transactions on-chain, and
* watchtowers with storage that's logarithmic in the number of factory states supported (but linear in the number of parties in the factory).

No change to the underlying Bitcoin protocol is required.

A more complete description, including a proof of correctness and better figures, is available in a paper [6].

The Tunable-Penalty Factory (TPF) Protocol
==========================================

The TPF protocol is a slight modification of the TPC protocol [5].

Each party using the TPC protocol has their own on-chain Individual transaction, the output of which they spend with their State transaction.
This State transaction is a control transaction and its first output's value is equal to the desired penalty for putting an old State transaction on-chain.
This first output can be spent by the same party's Commitment transaction for the same state, but only after a relative delay equal to the maximum of the parties' to_self_delay parameters.
The relative delay gives the other party time to revoke an old State transaction by spending its first output and thus claiming the penalty.
The State transaction also has an HTLC control output for each HTLC that is active in that state.
The TPC protocol revokes old State transactions with per-commitment keys that can be known to all parties, rather than with revocation keys that cannot be known by the party putting the revocable transaction on-chain [5].

The TPC protocol is modified to create the TPF protocol by:
* eliminating the HTLC control outputs from the State transactions,
* modifying the Commitment transactions to have channel outputs, each of which is owned by two parties in the factory, and
* supporting P > 2 parties by allowing each party to have their own Individual, State and Commitment transactions.

The TPF protocol is shown below:

+-+ A..Z +----+ AD
|F|------+-------------------------| CC |-----
+-+ | | |
| | | BC
| | |-----
| | |
. | | MZ
. | |-----
. +----+
|
| +----+ AD
+-------------------------|C_Ai|-----
| | |
| | | BC
| | |-----
| | |
| tsdAZ & A | | MZ
| +-----------| |-----
| | +----+
| |
| | +----+ AD
+-------------------------|C_Bi|-----
| | | |
| | | | BC
| | | |-----
| | | |
. | tsdAZ & B | | MZ
. +-------------| |-----
. | | +----+
| | |
| | | +----+ AD
+-------------------------|C_Zi|-----
| | | | |
. | | | | BC
. | | | |-----
. | | | |
| | | tsdAZ & Z | | MZ
V +---------------| |-----
| | | +----+
| | |
+----+ A +-----+ | | | pckeyAi
|In_A|----|St_Ai|------+-----------
+----+ | | | |
+-----+ | |
| |
+----+ B +-----+ | | pckeyBi
|In_B|----|St_Bi|----+-------------
+----+ | | |
+-----+ |
. . .
. . .
. . .
|
+----+ Z +-----+ | pckeyZi
|In_Z|----|St_Zi|--+---------------
+----+ | |
+-----+

where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
In_{A..Z} is {A..Z's} Individual transaction,
St_{A..Z}i is {A..Z's} State transaction for state i, and
C_{A..Z}i is {A..Z's} Commitment transaction for state i.

Requirements for output cases are as follows:
{A..Z}: {A..Z}'s signature (a single party's signature),
A..Z: A..Z's signature (every parties' signature),
pairs of capital letters indicate signatures from those two parties,
pckey{A..Z}i: a signature using a per-commitment key for revoking {A..Z}'s state i transaction, and
tsdAZ: a relative delay equal to the maximum of {A..Z}'s to_self_delay parameters.

In order to establish a new factory state, all parties:
* calculate the State and Commitment transactions for the new state (this step includes exchanging per-commitment pubkeys for the new state with each of the other parties),
* exchange partial signatures for the new state's Commitment transactions, and
* exchange per-commitment keys for the old state, thus revoking it.

All parties constantly look for old (revoked) State transactions put on-chain by other parties, and if they find such a transaction they use the corresponding per-commitment key to spend its first output, thus obtaining the penalty funds and revoking the old state.
Once a State transaction has been on-chain for tsdAZ without its first output being spent, the party that put the State transaction on-chain can attempt to put their corresponding Commitment transaction on-chain at any time.
Any party can close the factory unilaterally by putting their current State transaction on-chain, waiting until it has been on-chain for tsdAZ, and then submitting their corresponding Commitment transaction to the blockchain.

As was the case with the TPC protocol, per-commitment keys can use the Lightning protocol's compact storage technique for revocation keys to consume only O(log S) storage to revoke a maximum of S old transactions that could be put on-chain by a single other party [7][5].
Therefore, each party requires O(P*log S) storage to hold the per-commitment keys for all of the P parties.

The Single-Commitment (SC) Factory Protocol
===========================================

Note that the TPF factory protocol uses P conflicting Commitment transactions to establish the factory state and to instantiate the factory's channels.
Therefore, a separate channel state must be maintained and updated for each of the P versions of the channel that could be instantiated, thus increasing the computation, storage, and communication for channels by a factor of P.
The result could be quite expensive if there are a large number of parties in the factory.

The SC protocol eliminates this factor of P blow-up by having all of the parties use a single shared Commitment transaction.
Like the TPF protocol, the SC protocol uses revocable State transactions, each of which spends a single party's Individual transaction output, to ensure that only the current Commitment transaction can be put on-chain.
The challenge is how to use a single shared Commitment transaction that depends on the value of an unrevoked State transaction without actually spending any of the outputs of that State transaction (as spending a State transaction output would make the Commitment transaction's input dependent on which party's State transaction it spends, thus preventing the use of a single shared Commitment transaction).
This challenge is solved by introducing a shared Trigger transaction and a per-user Mold transaction, where the Commitment and Mold transactions compete for the Trigger transaction's outputs.
The Mold transaction is put on-chain prior to the Commitment transaction, and it constrains the Commitment transactions that can be put on-chain somewhat like how a mold shapes a liquid that is poured into it.

Specifically, the Trigger transaction has one value output and log_2(S) control outputs, numbered 0 .. log_2(S) - 1. Commitment transaction i, 0 <= i <= S - 1, spends those Trigger control outputs b, 0 <= b <= log_2(S) - 1, such that bit position b of the binary representation of i is a 0.
Each Mold transaction i, 0 <= i <= S - 1, spends the output of the same party's State i transaction, and Trigger control outputs b, 0 <= b <= log_2(S) - 1, such that bit position b of the binary representation of i is a 1.
This construction guarantees that if a Mold transaction for state i is on-chain, only Commitment transactions for states j >= i can be put on-chain.

States 0 through S - 1 are supported, with the exception of states of the form 2^b where 1 <= b <= log_2(S) - 1.
These exceptions are made to guarantee that it is impossible to put Mold transactions on-chain for two consecutive states (other than states 0 and 1) where they would prevent any current Commitment transaction from being put on-chain.
When state i is supported but state i+1 is not, the next state after i is i+2.

The protocol operation is similar to that of the TPF protocol, except parties closing the channel unilaterally submit the Trigger transaction and their current State transaction to the blockchain, and once their State transaction has been on-chain for tsdAZ, submit their Mold transaction for the same state to the blockchain.
Once the Trigger transaction has been on-chain for 3tsdAZ, they submit to the blockchain the Commitment transaction for the same state as the on-chain Mold transaction.

Also, all parties monitor the blockchain for the Trigger transaction, and if they find it they use the above protocol for closing the factory as soon as possible.

Because only Mold transactions for unrevoked State transactions can be put on-chain, and because only the latest State transactions can be unrevoked, only the latest (and thus current) Commitment transactions can be put on-chain.

A figure for the SC protocol, and a detailed proof of correctness, are in the paper [6].

Related Work
============

The concept of creating a channel factory for Lightning, as well as the most efficient published protocol for such a factory, was presented by Burchert, Decker and Wattenhofer [2].
The protocols presented here differ in only requiring O(1) time and O(1) on-chain transactions for a unilateral factory close.

A number of researchers have proposed changes to Bitcoin in order to support simpler and more efficient factories.
The eltoo factory protocol [3] has a particularly simple structure and it allows the parties to maintain only one version of each off-chain channel state.
It requires O(1) time, O(1) on-chain transactions and O(1) on-chain bytes for a unilateral close.
However, a malicious party could delay the closing of the factory until O(S) transactions are put on-chain, if the malicious party is willing to pay the required fees.
The eltoo protocol differs from the protocols presented here by requiring a change to Bitcoin, namely the support for BIP 118 [1].

The TPF and SC protocols are based on the TPC protocol presented by Law [5].

Conclusions
===========

This post presents new factory protocols that require O(1) time and O(1) on-chain transactions for a unilateral close.
They are the first factory protocols known that achieve those bounds with the existing Bitcoin protocol.

The ability to unilaterally close a factory with just two or three submissions to the blockchain, with a fixed delay between them, is quite a bit simpler than closing previously-published factories [2].
As a result, it's hoped that TPF and SC factories will lead to the increased use of factories in practice, thus improving the scalability of Bitcoin and Lightning.

Regards,
John

References
==========
[1] "BIP 118: SIGHASH_ANYPREVOUT", available at https://anyprevout.xyz/ and https://github.com/bitcoin/bips/pull/943.
[2] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Micropayment Channel Networks", available at http://dx.doi.org/10.1098/rsos.180089.
[3] Decker, Russell and Osuntokun. eltoo: A Simple Layer2 Protocol for Bitcoin. Available at https://blockstream.com/eltoo.pdf.
[4] Law, "Watchtower-Free Lightning Channels For Casual Users", available at https://github.com/JohnLaw2/ln-watchtower-free.
[5] Law, "Lightning Channels With Tunable Penalties", available at https://github.com/JohnLaw2/ln-tunable-penalties.
[6] Law, "Efficient Factories For Lightning Channels", available at https://github.com/JohnLaw2/ln-efficient-factories.
[7] Russell, "Efficient Per-Commitment Secret Storage", available at https://github.com/lightning/bolts/blob/master/03-transactions.md#efficient-per-commitment-secret-storage.
[8] ZmnSCPxj, "Channel Eviction From Channel Factories By New Covenant Operations", available at https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.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/20230115/1c24b7f0/attachment-0001.html>;

📅 Original date posted:2022-12-02 📝 Original message: TL;DR ...

2023-06-09T13:07:35Z

In reply to nevent1q…w69e
_________________________

📅 Original date posted:2022-12-02
📝 Original message:
TL;DR
=====
* This post presents a channel protocol that's optimized for use within channel factories.
* The protocol allows HTLCs to be resolved on-chain:
* without making the expiry of the HTLC depend on the time to close the factory, and
* without closing the factory.
* The key ides is the use of separate value and control transactions like those used in the Tunable Penalties protocol.
* A version of the protocol that provides watchtower-freedom and one-shot receives for casual users is also given.

Overview
========

While the Lightning Network greatly improves Bitcoin's scalability, factories that allow multiple two-party channels to be created and closed with a small number of on-chain transactions are essential if Bitcoin is to be widely used in a trust-free manner [2].
Unfortunately, the existing channel protocols aren't optimized for use within factories, thus limiting the efficiency of both the channels and the factories.

The Lightning Network uses Hash Time-Locked Contracts (HTLCs) to implement payments across multiple channels.
If one of the parties to an HTLC is unresponsive, the other party must resolve the HTLC on-chain.
This creates two problems.

First, the HTLC's expiry must be delayed by the time required to close the factory and put the channel containing the HTLC on-chain.
The most efficient known factory [2] can be closed in O(log S) time using O(log S) on-chain transactions, assuming the factory supports S states.
If all the hops in a multi-hop payment use channels that are implemented with factories, the sum of the delays for closing all of those factories must be included in the HTLC expiry of the first hop.
As a result, this delay could become very large, thus leading to inefficient use of the channels' capital and long waits to obtain payment receipts.

Second, the requirement to close a factory due to the need to resolve an HTLC on-chain means that a single unresponsive party can force the closure of an entire factory, thus limiting the factory's ability to scale Bitcoin.

This post presents factory-optimized channel protocols that solve both of these problems.
The first protocol, called the Partially-Factory-Optimized (PFO) protocol, solves the first problem, while the second protocol, called the Fully-Factory-Optimized (FFO) protocol, solves both problems.
Both protocols are slight modifications of the Tunable-Penalties (TP) protocol [5] and they share many of its properties, including:
* tunable penalties for putting old transactions on-chain, and
* efficient watchtowers with O(log S) storage for supporting O(S) channel states.

In addition, a version of the FFO protocol, called the Fully-Factory-Optimized-Watchtower-Free (FFO-WF) protocol is presented that supports watchtower-freedom and one-shot receives for casual users [4].
No change to the underlying Bitcoin protocol is required.

A paper with a more complete description of the protocols, including figures, values for the timing parameters, and proofs of correctness, is available [6].

The Partially-Factory-Optimized (PFO) Protocol
==============================================

The PFO protocol is a slight modification of the TP protocol [5].
In the TP protocol, each party has their own on-chain Individual transaction, the output of which they spend with their State transaction.
This State transaction is a control transaction that establishes the channel's state and has an HTLC control output corresponding to each HTLC outstanding in the channel in that state.
Each HTLC control output is used to resolve an HTLC by spending the output with either an HTLC-success or an HTLC-timeout transaction.
Critically, the State, HTLC-success and HTLC-timeout transactions can be put on-chain without spending any of the channel's funds.
Therefore, the TP protocol almost solves the problem of resolving a channel's HTLCs without waiting for the Funding transaction to be put on-chain.

Unfortunately, there's one problem in trying to use the TP protocol to resolve the HTLCs of a factory-created channel before the factory is closed and its Funding transaction is on-chain.
The correctness of the TP protocol depends on the ability to put the current Commitment transaction (spending the output of the channel's Funding transaction) on-chain as soon as possible once the relative delay between it and its corresponding State transaction has been met.
This relative delay is set to tsdAB, which is the maximum of the two parties' to_self_delay parameters.
The problem is that the latency to close the factory and put the channel's Funding transaction on-chain could exceed tsdAB.
As a result, the TP protocol can't be used in such a factory.

The PFO protocol fixes this by simply setting the relative delay between the State transaction and its associated Commitment transaction to the maximum of the factory-close latency and tsdAB.

The Fully-Factory-Optimized (FFO) Protocol
==========================================

While the PFO protocol separates the latency to close the factory from the setting of the HTLCs' expiries, it still requires that the factory be closed in order to guarantee that the HTLCs have been resolved correctly.

The FFO protocol makes several changes to the PFO protocol in order to resolve HTLCs without requiring the closure of the factory.
Consider an HTLC offered by Alice to Bob.

First, in the FFO protocol only Bob's State transaction has an HTLC control output that determines the resolution of this HTLC, regardless of which party's Commitment transaction is put on-chain.
As a result, there's no race to put one's Commitment transaction on-chain, and thus no need to close the factory in order to resolve HTLCs.
As another result, it eliminates the possibility of this HTLC being resolved with Alice's State and associated HTLC-timeout transactions being put on-chain late relative to the HTLC's expiry.

Second, because the HTLC is always resolved based on an HTLC control output in Bob's State transaction, Bob has to be incentivized to put his correct State transaction on-chain (or else he could prevent the HTLC from timing out by not putting his State transaction on-chain).
This is solved by requiring Bob's State and HTLC-success transactions in order to pay the HTLC, and to refund the HTLC to Alice (after a suitable relative delay) if Bob's State and HTLC-success transactions are not on-chain.

Third, Bob is prevented from putting his State transaction on-chain late relative to the HTLC's expiry by adding a relative delay of tsdA (Alice's to_self_delay parameter) before he can put his HTLC-success transaction on-chain.
This guarantees that Alice will have time to respond with a conflicting transaction that prevents Bob's HTLC-success transaction from being put on-chain late relative to the HTLC's expiry.

Finally, if the HTLC's secret were not revealed until the HTLC-success transaction is put on-chain, the worst-case latency for obtaining a secret from a successful HTLC would depend on tsdA, which would greatly increase Bob's cltv_expiry_delta parameter, in turn increasing the cost of capital reserved for the HTLC and the delay for obtaining a payment receipt.
This problem is solved by introducing a new transaction, called an HTLC-kickoff transaction, that spends the HTLC control output in Bob's State transaction and reveals the HTLC's secret, with the HTLC-success transaction spending the HTLC-kickoff transaction's output.
Thus,the revelation of the HTLC's secret is performed first, followed by the resolution of the HTLC approximately tsdA later.

The FFO protocol is shown below:

+-+ AB +----+ A
|F|----+-----------------------------| CC |----
+-+ | | |
. | | B
. | |----
. +----+
| +----+ A
+-----------------------------|C_Ai|----
| | |
| | | B
| | |----
| tsdB & A | | tsdAB & A
| +---------------| |-----+------------
| | +----+ |
| | | AB +-----+ B
| | +--------------|Hp_Bi|----
| | | |
| | +--| |
| | | +-----+
| | +----+ A |
+-----------------------------|C_Bi|---- |
| | | | |
. | | | B |
. | | |---- |
. | tsdA & B | | tsdAB & A |
| +-----------------| |-----+--------------
V | | +----+ | |
| | | AB | +-----+ B
+----+ A +-----+ | | pckeyAi +--------------|Hp_Bi|----
|In_A|----|St_Ai|----+---------- | | |
+----+ | | | +--| |
| | | | +-----+
| | | |
+-----+ | |
| (eAB+tsdA) & A |
+----+ B +-----+ | pckeyBi +----------------- |
|In_B|----|St_Bi|--+------------ | |
+----+ | | | |
| | hp(X) & B +-----+ | tsdA & B +-----+ B |
| |------------|Hk_Bi|-+-----------|Hs_Bi|----+
+-----+ +-----+ +-----+

where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
In_{A|B} is {Alice's|Bob's} Individual transaction,
St_{A|B}i is {Alice's|Bob's} State transaction for state i,
C_{A|B}i is {Alice's|Bob's} Commitment transaction for state i,
Hk_Bi is Bob's HTLC-kickoff transaction for state i,
Hs_Bi is Bob's HTLC-success transaction for state i, and
Hp_Bi is Bob's HTLC-payment transaction for state i.

Requirements for output cases are as follows:
A: Alice's signature,
B: Bob's signature,
AB: Alice's and Bob's signatures,
pckey{A|B}i: a signature using a per-commitment key for revoking
{Alice's|Bob's} state i transaction,
hp(X): the hash preimage of X,
tsd{A|B}: a relative delay equal to {Alice's|Bob's} to_self_delay
parameter,
tsdAB: a relative delay equal to max(tsdA, tsdB), and
eAB: an absolute timelock equal to the expiry of the HTLC in this hop.

Extensions
==========

If a party accidentally puts on old State transaction on-chain, they only lose the penalty amount that is the output of that transaction (and potentially some of the minimal values of that transaction's HTLC control outputs).
However, once their State transaction has been revoked, they've lost the ability to force a unilateral close of the channel after the Funding transaction is on-chain.
To address this, it's possible to add a Trigger [2] transaction that spends the output of the Funding transaction.
After the Trigger transaction has been on-chain for 3tsdAB (in order to allow the other party to put their Commitment transaction on-chain), the Decker-Wattenhofer protocol [3] can be used to settle the channel.

The FFO protocol shows how a channel's HTLCs can be resolved on-chain without putting its Funding transaction on-chain, and thus without closing the channel factory.
The party that went on-chain can settle the channel and its HTLCs correctly, even if their partner is malicious.
However, the most likely reason a party goes on-chain is that their partner is unintentionally unavailable, rather than malicious.
When the unavailable partner becomes available again, the two parties could choose to re-start operating the channel, and that's possible because the channel's funds haven't been distributed.
In particular, the party that went on-chain can use the unspent first output of their State transaction to play the role of their Individiual transaction's output as they resume operating the channel.
This output has slightly less value, as it's sized for the penalty amount and doesn't have additional funds for HTLC control outputs, but it seems reasonable to reduce the penalty amount that they will have to pay, given that it was the other party's unavailability that forced them to go on-chain.

Watchtower-Freedom And One-Shot Receives For Casual Users
=========================================================

The WF protocol modified the current Lightning protocol to allow casual users to operate without watchtowers and to perform one-shot receives.
A similar approach can be used to modify the FFO protocol to achieve the same goals, resulting in the FFO-WF protocol.

Consider a casual user Alice and her dedicated channel partner Bob.
Like the WF protocol, the FFO-WF protocol adds a relative delay before Alice can time out an HTLC offered to Bob, allowing Bob to stay off-chain after the HTLC's expiry, thus tolerating Alice's intentional unavailability.
As in the FFO protocol, in the FFO-WF protocol only one of the two parties' State transactions has an HTLC control output for each HTLC that is outstanding.
However, unlike the FFO protocol, Alice's State transaction has the HTLC control outputs for all HTLCs, even those offered to Bob.
The control of the HTLCs offered to Bob is moved to Alice's State transaction in order to allow Alice to force Bob to produce a receipt (or to not receive payment) by putting her State transaction on-chain.
While this solves the problem of forcing receipts, it creates a risk that Alice will never put her State transaction on-chain, thus preventing Bob from receiving payment for HTLCs offered to him.
This risk is solved by modifying Bob's Commitment transaction to ignore the HTLC control results and to pay all HTLC amounts (both those offered by him and those offered to him) to Bob, but delaying Bob's State and Commitment transactions enough that Alice can always get her State and Commitment transactions on-chain, thus resolving the HTLCs correctly (as she is incentivized to do, given Bob's Commitment transaction).

In order to support one-shot receives for Alice, she is able to submit her State and HTLC-success transactions as a single package, without any relative delay between them.
This creates a risk that she will submit them well after the HTLC's expiry, thus allowing her to receive payment without meeting the terms of the HTLC.
This risk is solved by requiring Alice's HTLC-success transaction to also spend a new control output in Bob's Individual transaction, and allowing Bob to spend that new control output with an HTLC-timeout transaction after the HTLC's expiry (thus blocking Alice's HTLC-success transaction).
This design creates another issue, namely the possibility of Bob using an old HTLC-timeout transaction (or any other transaction) to spend the new control output and block Alice's HTLC-success transaction before the HTLC's expiry.
This final issue is solved by having each HTLC output in Alice's Commitment transaction default (after a sufficient relative delay) to paying her for the HTLC offered to her unless Bob's corresponding HTLC-timeout transaction is on-chain.

The FFO-WF protocol, with a single HTLC outstanding from dedicated user Bob to casual user Alice, is shown below:

+-+ AB +----+ A
|F|----+-----------------------------| CC |----
+-+ | | |
. | | B
. | |----
. +----+
| tsdB & AB +----+ A
+-----------------------------|C_Ai|----
| | |
| | | B
| | |----
| tsdB & A | | tsdAB & A
| +-----------------| |-----+------------
| | +----+ |
| | | AB +-----+ B
| | +-----------|Hr_Bi|----
| | | |
| | B | |
| | +--| |
| | | +-----+
| tA+B & AB | +----+ A |
+-----------------------------|C_Bi|---- |
| | | | |
. | | | B |
. | | |---- |
. | tA+B & B | | |
| | +-------------| | |
V | | +----+ |
| | |
+----+ A +-----+ | | pckeyAi |
|In_A|----|St_Ai|--+-------------- |
+----+ | | | |
| | | hp(X) & A +-----+ A |
| | ---------------------|Hs_Ai|---- |
+-----+ | | | |
| B | | |
| +--| | |
| | +-----+ |
+----+ (Li)&B +-----+ | pckeyBi | |
|In_B|---------|St_Bi|-+---------- | |
| | +-----+ | |
| | | (eAB) & B +-----+ |
| |------------------------------+------------|Ht_Bi|-+
+----+ +-----+

where notation matches the figure above, plus:
Hs_Ai is Alice's HTLC-success transaction for state i,
Ht_Bi is Bob's HTLC-timeout transaction for state i,
Hr_Bi is Bob's HTLC-refund transaction for state i,
tA+B equals tsdA + tsdB, and
Li is an absolute locktime that is tsdA in the future when state i is
created.

Related Work
============

The protocols presented here are designed to make efficient use of channel factories for Lightning.
The concept of channel factories and the most efficient published protocol for a channel factory were created by Burchert, Decker and Wattenhofer [2].

Towns proposed adding a new opcode to Bitcoin, called TAPLEAF_UPDATE_VERIFY (TLUV), that would support (among other things) the ability to remove one party from a CoinPool without having to close the CoinPool [7], and ZmnSCPxj noted that this opcode could also be used to remove one channel from a factory without closing the factory [8].
Those proposals differ from the protocols presented here in that they require a change to Bitcoin.

The protocols presented here use HTLC-timeout and HTLC-success transactions to resolve HTLCs before the channel's Funding transaction has been put on-chain, thus reducing the expiry of those HTLCs.
This idea is analogous to, and inspired by, the Lightning protocol's use of HTLC-timeout and HTLC-success transactions to resolve HTLCs before their associated Commitment transaction has been verified to be unrevoked [1].

The PFO, FFO and FFO-WF protocols are based on the TP protocol presented by Law [5].
The techniques for supporting watchtower-freedom and one-shot receives in the FFO-WF protocol are based on those presented by Law in [4] and [5].

Conclusions
===========

This post presents channel protocols that are optimized for use within channel factories.
The protocols make the resolution of HTLCs in the channels independent of the latency to close the channel factory.
The FFO and FFO-WF protocols also allows HTLCs to be resolved on-chain without closing the channel factory.

If the FFO protocol is used in channels owned by pairs of dedicated users and the FFO-WF protocol is used in channels with a casual user:
* casual users do not require watchtowers,
* casual users can use one-shot receives,
* dedicated users can use watchtowers with logarithmic storage,
* all users can have tunable penalties,
* all channels can have HTLCs with expiries that are independent of the latency of closing the factory that created them, and
* all channels can resolve their HTLCs without closing the factories that created them.

It's hoped that these factory-optimized protocols will allow channel factories to become commonly-used, thus improving Bitcoin's scalability.

Regards,
John

References
==========

[1] BOLT specifications, available at https://github.com/lightningnetwork/lightning-rfc.
[2] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Micropayment Channel Networks", available at http://dx.doi.org/10.1098/rsos.180089.
[3] Decker and Wattenhofer, "A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels", available at https://tik-old.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf.
[4] Law, "Watchtower-Free Lightning Channels For Casual Users", available at https://github.com/JohnLaw2/ln-watchtower-free.
[5] Law, "Lightning Channels With Tunable Penalties", available at https://github.com/JohnLaw2/ln-tunable-penalties.
[6] Law, "Factory-Optimized Channel Protocols For Lightning", available at https://github.com/JohnLaw2/ln-factory-optimized.
[7] Towns, "TAPLEAF_UPDATE_VERIFY covenant opcode", available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html.
[8] ZmnSCPxj, "Channel Eviction From Channel Factories By New Covenant Operations", available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/003479.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/20221202/9a91c6d0/attachment-0001.html>;

📅 Original date posted:2022-12-26 📝 Original message: ...

2023-06-09T13:07:35Z

In reply to nevent1q…54lz
_________________________

📅 Original date posted:2022-12-26
📝 Original message:
I'd like to make two corrections to this post:

1) The link for reference [8] should be: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html (thanks to David A. Harding for this correction).

2) An extension of the FFO protocol was described in which the parties in a channel could continue to operate the channel after one party put their State transaction on-chain by having the first output of that State transaction play the role of the same party's Individiual transaction's output. This doesn't work, because that party would have to reveal the per-commitment key to invalidate the previous channel state, and once revealed the other party could then spend that output. This problem can be fixed by having the party that put their State transaction on-chain put a new Individual transaction on-chain that spends the first output of their State transaction.

Regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221226/fd9d9147/attachment.html>;

📅 Original date posted:2022-10-30 📝 Original message: TL:DR ...

2023-06-09T13:07:11Z

In reply to nevent1q…s5ma
_________________________

📅 Original date posted:2022-10-30
📝 Original message:
TL:DR

=====
* It's possible to modify the Lightning channel protocol to impose tunable penalties for putting old transactions on-chain.
* The key idea is the use of separate value transactions and control transactions.
* The Tunable-Penalty (TP) protocol also allows a watchtower to use storage that is logarithmic (vs. linear) in the number of channel states.
* The TP protocol is not suitable for casual users, as it can require that users perform actions at specific times weeks or months after the expiry of an HTLC.

Overview
========

In the current Lightning channel protocol [1][2], if a party accidentally puts an old transaction on-chain (for example, due to loss of state caused by a crash or loss of a cell phone), they risk losing all their funds in the channel (this has been called the "toxic-waste" problem) [7]. This post presents a new channel protocol, the Tunable-Penalty (TP) protocol, that supports a tunable penalty for putting old transactions on-chain, thus discouraging the use of old transactions while avoiding the risk of losing all channel funds [9][11]. In addition, the TP protocol allows watchtowers to use storage that is logarithmic, rather than linear, in the number of channel states supported. No change to the underlying Bitcoin protocol is required.

A paper with a more complete description of the protocol, including figures, is available [6].

The Challenge
=============

In order to motivate the TP protocol, first consider a straightforward approach to tuning penalties in a Lightning channel by charging the errant party the desired penalty and then dividing the remaining funds according to the channel's current state. Consider the case where Alice put an old state i Commitment transaction on-chain, where the current channel state is j > i. In order to assess the penalty and correctly divide the remaining funds, Bob must be able to spend that transaction's to_self output (which pays to Alice) with a Penalty_Bij transaction that splits its input value into the correct state j values (after assessing the penalty). Alice must approve of this division of funds when she agrees to make state j the current state. Therefore, Alice must sign a separate Penalty_Bij transaction for each pair of states i and j, where i < j, so she must sign a total of O(S^2) penalty transactions and Bob must store O(S) signatures for the current state, where S is the number of channel states [3]. The current Lightning protocol only requires O(S) signatures and O(log S) storage for each party [10], so this approach would be quite expensive.

The Solution
============

The TP protocol avoids this problem by using separate value and control transactions. In addition to an on-chain Funding transaction that provides the channel's funds, each party in the TP protocol has an on-chain Individual transaction that they use to control how the channel's funds are distributed. Each Individual transaction has a single output with a value slightly larger than the desired penalty amount. Before either party can put their Commitment transaction on-chain, they must first put their State transaction on-chain that spends the output of their Individual transaction. The State transaction encodes the channel's state number in its nLocktime and nSequence fields, just like the Commitment transaction encodes the state number in the Lightning protocol. The first output of the State transaction has a value equal to the desired penalty amount. After a relative delay equal to the maximum of the parties' to_self_delay parameters, this output can be spent by the same party's Commitment transaction for the same state. However, if the State transaction is for an old state, it can be revoked by the other party (thus taking the penalty amount) before it can be used as an input to the Commitment transaction. If one party's State transaction is revoked, the other party can still put their correct State transaction on-chain, as the two parties' State transactions spend outputs from different Individual transactions, and thus don't conflict. Because old State transactions are revoked before they can affect the distribution of the channel's funds, the problem with O(S^2) penalty transactions and signatures described above is avoided.

The Protocol
============

The TP protocol is shown below:

+-+ AB +----+ A
|F|----+-------------------------| CC |----
+-+ | | |
. | | B
. | |----
. +----+
| +----+ A
+-------------------------|C_Ai|----
| | |
| | | B
| | |----
| | |
| tsdAB & A | | AB +-----+ A
| +-----------| |-----+------------|Hr_Ai|----
| | +----+ | +---------| |
| | | | +-----+
| | | | +-----+ B
| | +------------|Hp_Bi|----
| | | +-------| |
| | | | +-----+
| | +----+ A | |
+-------------------------|C_Bi|---- | |
| | | | | |
. | | | B | |
. | | |---- | |
. | | | | |
| | tsdAB & B | | AB | | +-----+ A
V +-------------| |-----+------------|Hr_Ai|----
| | +----+ | | | +----| |
| | | | | | +-----+
| | | | | | +-----+ B
+----+ A +-----+ | | pckeyAi +------------|Hp_Bi|----
|In_A|----|St_Ai|----+----------- | | | +--| |
+----+ | | | | | | | +-----+
| | | eAB & A +-----+ A | | | |
| |----+-----------|Ht_Ai|-------+ | | |
+-----+ | | +-----+ | | |
| | hp(X) & A +-----+ B | | |
| +-----------|Hs_Bi|---------+ | |
| +-----+ | |
+----+ B +-----+ | pckeyBi | |
|In_B|----|St_Bi|--+------------- | |
+----+ | | | |
| | eAB & A +-----+ A | |
| |--+-------------|Ht_Ai|------------+ |
+-----+ | +-----+ |
| hp(X) & A +-----+ B |
+-------------|Hs_Bi|--------------+
+-----+

where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
In_{A|B} is {Alice's|Bob's} Individual transaction,
St_{A|B}i is {Alice's|Bob's} State transaction for state i,
C_{A|B}i is {Alice's|Bob's} Commitment transaction for state i,
Ht_Ai is Alice's HTLC-timeout transaction for state i,
Hs_Bi is Bob's HTLC-success transaction for state i,
Hr_Ai is Alice's HTLC-refund transaction for state i, and
Hp_Bi is Bob's HTLC-payment transaction for state i.

The F, In_A and In_B transactions are on-chain, while the remaining transactions are off-chain during normal protocol operation. The output of the Ht_Ai and Hs_Bi transactions, and the second output of the St_Ai and St_Bi transactions, have the minimal allowed value, as they are used for control.

Requirements for output cases are as follows:
A: Alice's signature,
B: Bob's signature,
AB: Alice's and Bob's signatures,
pckey{A|B}i: a signature using a per-commitment key for revoking {Alice's|Bob's} state i transaction,
hp(X): the hash preimage of X,
tsdAB: a relative delay equal to the maximum of Alice's and Bob's to_self_delay parameters, and
eAB: an absolute timelock equal to the expiry of the HTLC in this hop.

In order to establish a new channel state, both parties:
* calculate the State, Commitment, HTLC-timeout, HTLC-success, HTLC-refund and HTLC-payment transactions for the new state,
* exchange partial signatures for the new state's HTLC-refund, HTLC-payment and Commitment transactions (in that order), and
* exchange per-commitment pubkeys for the old state, thus revoking it.

Consider the case of an HTLC offered by Alice to Bob (as shown in the figure above). When Bob receives the secret for the HTLC, he shares it with Alice and attempts to update the channel state off-chain. If he's unable to update the state off-chain before his fulfillment_deadline prior to the HTLC's expiry, he puts his State and associated HTLC-success transactions on-chain. If Alice hasn't received the HTLC's secret by her timeout_deadline *prior* to the HTLC's expiry, she puts her State and associated HTLC-timeout transactions on-chain.

Both parties constantly look for an old (revoked) State transaction put on-chain by their partner, and if they find such a transaction they use the corresponding per-commitment key to spend its first output, thus obtaining the penalty funds and revoking the old state. Whenever a current State transaction is put on-chain, both parties attempt to resolve its HTLC control output(s) by putting their HTLC-timeout and HTLC-success transactions on-chain. If the first output of a State transaction has not been spent within tsdAB, the party that put the State transaction on-chain attempts to put their corresponding Commitment transaction on-chain. Once a Commitment transaction is on-chain, each party puts its HTLC-refund and HTLC-payment transactions that spend its HTLC outputs on-chain (as determined by whether the corresponding HTLC-timeout or HTLC-success transaction is on-chain).

Two-Input Transactions
======================

All transactions in the current Lightning protocol have a single input, while the Commitment, HTLC-refund and HTLC-payment transactions in the TP protocol each have two inputs. The first input is a value input that carries channel funds and requires both parties' signatures (using the SIGHASH_ALL flag). The second input is a control input that only requires one party's signature. These two-input transactions are quite different from the Lightning protocol's one-input transactions, so it's worth examining them in detail.

First, because the first input requires both parties' signatures, only two-input transactions that have been signed by both parties can be used. Second, because signatures for the first input use the SIGHASH_ALL flag, they force the source of the second input to have the specified transaction ID. Third, because each transaction's ID is a function of the transaction IDs of all of its parents (and indirectly, of all of its ancestors), all of the ancestors of the two-input transactions must have the specified transaction IDs. For example, Alice's partial signature on the first input of Bob's Commitment transaction forces its second input to spend the first output of Bob's State transaction for the same state, and indirectly requires Bob's State transaction for the same state to spend the output of his Individual transaction. Therefore, while Bob could spend the output of his Individual transaction in any way he chooses, spending it with anything other than the correct State transaction will prevent him from ever putting his correct Commitment transaction on-chain. Similarly, if the first output of Bob's State transaction is spent by anything other than his corresponding Commitment transaction, that Commitment transaction can never be put on-chain.

Per-Commitment Keys
===================

In this way, Bob's Commitment transaction for state i, and the HTLC-refund and HTLC-payment transactions that spend the HTLC outputs from his Commitment transaction for state i, all require that the first output of Bob's State transaction for state i be spent by his Commitment transaction for state i. Therefore, revoking an old State transaction by spending its first output also revokes all of the same party's Commitment transactions (for all states) and their associated HTLC-refund and HTLC-payment transactions. This is why there's no need to separately revoke any of the outputs from the Commitment, HTLC-refund, HTLC-payment, HTLC-timeout or HTLC-success transactions.

These dependent revocations also allow the TP protocol to use a different type of key for revoking old states. In the Lightning protocol the party that puts an old transaction on-chain cannot know the key for revoking that transaction. This is necessary in Lightning because if that party did know the revocation key, they could intentionally put an old Commitment transaction on-chain and then "revoke" the outputs of that transaction, thus taking the value for themselves. In contrast, in the TP protocol, if a party puts an old State transaction on-chain and then revokes it by spending its first output with a transaction other than its associated Commitment transaction, that party is actually blocking its ability to ever put a Commitment transaction on-chain. Furthermore, the funds that party obtains by spending the State transaction's first output are the same penalty funds that they provided from their Individual transaction. As a result, it's safe in the TP protocol to allow a party to revoke its own State transaction. This allows the TP protocol to use per-commitment keys (which are exactly the private keys of the per-commitment points used by the Lightning protocol [10]) to revoke transactions.

Watchtowers
===========

Because these per-commitment keys are known to the party putting the revocable transactions on-chain, they can also be shared with an untrusted watchtower. The watchtower can use the Lightning protocol's compact storage technique for revocation keys to consume only O(log S) storage to revoke a maximum of S old transactions [10]. Conveniently, the watchtower can also take the penalty amount as payment for the service it provided. The watchtower must be given the UTXO of the partner's Individual transaction's output in order to detect a revoked transaction, but the watchtower will see no association between that UTXO and the Funding transaction or any other channel state.

Correctness
===========

Each party is prevented from putting an old Commitment transaction for state i on-chain by the other party spending the first output of the corresponding State transaction for state i. Therefore, only the correct Commitment transaction can appear on-chain.

While having separate, non-conflicting State transactions enables tunable penalties, it makes HTLC resolution more complex. As can be seen in the figure above, the parties' Commitment transactions conflict and the party whose Commitment transaction appears on-chain (called the winning party) also put on-chain the State transaction with the HTLC control outputs that determine whether HTLCs succeed or time out.

For example, consider an HTLC offered by Alice to Bob. Bob could fulfill the HTLC by putting his State and associated HTLC-success transactions on-chain before its expiry, but if Alice is the winning party and she puts her State and associated HTLC-timeout transactions on-chain far after its expiry, Bob will not be paid by the HTLC depite having met its terms. Similary, Alice could time out the HTLC by putting her State and HTLC-timeout transactions on-chain after its expiry, but if Bob is the winning party and he puts his State and associated HTLC-success transactions on-chain far later, Bob will be paid by the HTLC despite having failed to meet its terms.

Note that both problems require the second party to put their State transaction on-chain late relative to the HTLC's expiry, and yet be the winning party. These problems can't occur in the TP protocol because both parties race to put their Commitment transactions on-chain and the relative delays from State transactions to Commitment transactions match. Therefore, the winning party's State transaction can't be put on-chain much later than the other party's State transaction. In the TP protocol, each party guarantees that the winning party's State transaction is on-chain early enough relative to the HTLC's expiry by putting their own State transaction on-chain early. Then, even if the other party is the winning party, the other party's transaction must still be on-chain early enough relative to the HTLC's expiry, thus guaranteeing its correct resolution.

This argument is formalized in the paper [6].

Related Work
============

The protocol presented here makes extensive use of previously-published work, namely the Poon-Dryja Lightning channel protocol [1] and the BOLT specifications [2]. The compact storage technique for per-commitment keys comes from the compact storage technique for revocation keys created by Russell [10].

Riard, ZmnSCPxj and Decker examined the idea of adding penalties to the eltoo protocol [7], but the techniques used there were different, as they did not use separate value and control transactions.

Rubin (who also credited nullc and sipa) [8] showed how a two-input transaction with separate value and control inputs can be used to delegate the control of a UTXO (the value input) to another UTXO (the control input). This two-input transaction is similar to the TP protocol's Commitment, HTLC-refund and HTLC-payment transactions, but differs in that its value input does not require a multi-sig, so the delegation can be revoked by the delegator via a double-spend.

The idea of using separate value and control transactions was presented by Law in the update-forest and challenge-and-response protocols [4], but those protocols were for channel factories as opposed to channels, and they assumed a change to the underlying Bitcoin protocol.

Conclusions
===========

This paper presents a new channel protocol that allows one to select the penalty for putting an old transaction on-chain. In addition, it reduces the storage costs for untrusted watchtowers from O(S) to O(log S), where S is the number of channel states supported. A recent paper presented a channel protocol that is watchtower-free for casual users [5] and similar techniques could be used to make the TP protocol watchtower-free for such users. However, the TP protocol is not suitable for them as it can require that users submit their Commitment transaction at a specific time weeks or months after the expiry of an HTLC.

The TP protocol achieves tunable penalties and logarithmic storage for watchtowers by using separate value and control transactions. As will be shown in the next posts, protocols that use separate value and control transaction and have a structure similar to the TP protocol can also be used to create factory-optimized channels and efficient channel factories.

Regards,
John

References
==========

[1] Poon and Dryja, "The Bitcoin Lightning Network", available at https://lightning.network/lightning-network-paper.pdf.
[2] BOLT specifications, available at https://github.com/lightningnetwork/lightning-rfc.
[3] Decker, "Re: Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo), available at https://www.mail-archive.com/lightning-dev@lists.linuxfoundation.org/msg02046.html.
[4] Law, "Scaling Bitcoin With Inherited IDs", available at https://github.com/JohnLaw2/btc-iids.
[5] Law, "Watchtower-Free Lightning Channels For Casual Users", available at https://github.com/JohnLaw2/ln-watchtower-free.
[6] Law, "Lightning Channels With Tunable Penalties", available at https://github.com/JohnLaw2/ln-tunable-penalties.
[7] Riard, "Using Per-Update Credential to enable Eltoo-Penalty" and subsequent posts in the thread starting at: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002064.html
[8] Rubin, "Delegated signatures in Bitcoin within existing rules, no fork required" available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018615.html.
[9] Rubin, "Re: 'OP_EVICT': An Alternative to 'OP_TAPLEAFUPDATEVERIFY'", available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019945.html.
[10]Russell, "Efficient Per-Commitment Secret Storage", available at https://github.com/lightning/bolts/blob/master/03-transactions.md#efficient-per-commitment-secret-storage
[11]Sanders, "Re: 'OP_EVICT': An Alternative to 'OP_TAPLEAFUPDATEVERIFY'", available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019947.

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/20221030/b97aa76e/attachment-0001.html>;

📅 Original date posted:2022-10-30 📝 Original message: Hi ...

2023-06-09T13:07:01Z

In reply to nevent1q…us8v
_________________________

📅 Original date posted:2022-10-30
📝 Original message:
Hi Bastien,

Thanks for your detailed response.

I see how the use of a pre-signed "splice" transaction that allows the dedicated user to obtain some of their capital creates an inherent trade-off between the dedicated user's capital efficiency and the casual user's ability to be offline for an extended period of time.

In order for the use of a pre-signed splice transaction to be safe, the casual user has to check the blockchain and see the splice transaction before it can be spent by the dedicated user (in order to revoke it if needed). As a result, once the dedicated user decides to splice out some channel funds, the dedicated user cannot access those funds until some time *after* the casual user has been online (provided the protocol is trust-free).

Given this observation, what if the protocol were changed so that, instead of pre-signing a splice transaction, the casual user always checks in with the dedicated user whenever they check the blockchain? At such a check-in, if the dedicated user wants to splice out some channel funds, they send the casual user a splice transaction which splices out some of the funds to the dedicated user without requiring a to_self delay. The casual user then signs the splice transaction and returns the signature as part of the check-in.

This approach has a couple potential advantages:
1) It allows the dedicated user to splice out funds as soon as the casual user comes online (rather than sometime after the casual user comes online, as shown above). Therefore, the use of capital is made more efficient.
2) It allows the splice transaction to pay fees based on the current fee rate, rather than a pre-calculated fee rate.

It does have some potential disadvantages:
1) It requires the casual user to stay online long enough to complete the roundtrip of sending a check-in message to the dedicated user, getting the splice message to sign, signing it, and sending the signature back to the dedicated user.
2) It assumes that the casual user checks the blockchain themselves, rather than using a watchtower service.
3) It requires the dedicated user to decide at the time of the check-in whether or not to perform the splice, as the splice transaction cannot be revoked.

In any case, using a check-in and a non-revokable splice transaction appears to have some advantages in terms of capital efficiency. It's also somewhat more compatible with the WF protocol, as the delay for the dedicated user to obtain spliced-out funds is dependent on the actual time until the casual user next comes online, rather than the worst-case delay until the casual user comes online. This could be a big difference if the casual user is typically online every day, but doesn't want the burden of having to be online every day (or every week). I'm interested in your thoughts on this.

Finally, I understand that the ability to quickly splice out channel funds to improve capital efficiency is critical in the current environment. However, if we eventually get to the point where the blockchain is highly-contested and fees are high, it may no longer be worth paying the fees to put a splice transaction on-chain unless a large amount of capital is at stake for a long period of time.

Regards,
John

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Monday, October 24th, 2022 at 2:50 AM, Bastien TEINTURIER <bastien at acinq.fr> wrote:

> Hi John,
>
>> My understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct?
>>
>> If it is, then when a dedicated user (DLU) partners with a casual user (CLU), the DLU can only move liquidity to another Lightning channel by either:
>> 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
>> 2) putting a non-cooperative close transaction on-chain and waiting approximately 2 weeks (based on the to_self_delay parameter set by the CLU) before moving the liquidity.
>
> That's correct, but that's something we intend to change to let LSPs
> re-allocate their liquidity more frequently and more efficiently.
>
> We don't have a fully specified proposal yet, but by leveraging a
> mechanism similar to splicing [1], mobile users would pre-sign a
> transaction that keeps the channel open, but lets the LSP get their
> balance (or part of it) out non-interactively. This would be used by
> LSPs if the user isn't using their channel actively enough and the LSP
> is low on available liquidity for other, more active users.
>
> This transaction would need to be revokable and must be delayed, since
> we still need the user to be able to punish malicious LSPs, but ideally
> (from the LSP's point of view) that delay should be at most 1 week, which
> forces users to regularly check the blockchain (which isn't ideal).
>
> It really is a trade-off to be able to lower the fees LSPs make users
> pay for liquidity, because LSPs know they can move it cheaply when it
> becomes necessary. I can see a future where users chose their trade-off:
> pay more to be able to go offline for longer periods or pay less but
> check the blockchain regularly. The same LSP could offer both features,
> if they're able to price them correctly (which isn't trivial).
>
>> My intuition is that in the long run, the cost of bitcoin capital will be very low, as it is an inherently deflationary monetary unit (and thus its value should increase with time). If this is correct, the long term cost-of-capital charges should be very low.
>
> I'm not convinced by that...even though the value of capital increases
> with time, liquidity providers will compete to earn more return on their
> locked capital. If one liquidity provider is able to use their capital
> more efficiently than another, they will be able to offer lower prices
> to their customers to a point that isn't economically viable for the
> other, less efficient liquidity provider?
>
> Since lightning doesn't allow any form of fractional reserve, the total
> available capital needs to be split between all existing users of the
> system, which is very inconvenient when trying to onboard a high number
> of new users.
>
> This is very theoretical though, I have absolutely no idea how those
> dynamics will actually play out, but it will be interesting to watch it
> unfold.
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/863
>
> Le mer. 12 oct. 2022 à 02:11, jlspc <jlspc at protonmail.com> a écrit :
>
>> Hey Bastien,
>>
>> Thanks for your reply.
>>
>> Responses are in-line below:
>>
>>> Hey John,
>>>
>>> Thanks for sharing, this is very interesting.
>>>
>>> There is a good insight here that we can remove the intermediate
>>> HTLC-timeout transaction for outgoing payments because we are the
>>> origin of that payment (and thus don't need to quickly claim the
>>> HTLC on-chain to then relay that failure to a matching incoming HTLC).
>>>
>>> More generally, you have perfectly identified that most of the
>>> complexity of today's transactions come from the need to ensure that
>>> a failing/malicious downstream channel doesn't negatively impact
>>> honest upstream channels when relaying payments, and that some of this
>>> complexity can be lifted when nodes don't relay payments.
>>
>> Thanks!
>>
>>> However, my main criticism of your proposal is that liquidity isn't free.
>>> While your improvements are great from the CLU's point of view, I'm not
>>> sure they're acceptable for the DLU. The main (probably only) job of an
>>> LSP (DLU in your terminology) is to efficiently allocate their liquidity.
>>> In order to do so, they must be able to quickly move liquidity from where
>>> it's unused to where it may be better used. That means closely watching
>>> the demand for block space and doing on-chain transactions when fees are
>>> low (to open/close channels, splice funds in/out [1], make peer swaps [2],
>>> etc). With your proposal, DLUs won't be able to quickly move liquidity
>>> around, so the only way to make up for this is to charge the CLU for the
>>> loss of expected revenue. I'm afraid that the amount DLUs would need to
>>> charge CLUs will be prohibitively expensive for most CLUs.
>>>
>>> I'm curious to get your feedback on that point.
>>
>> I really appreciate your insight here. I'm just an interested observer who doesn't have experience with creating and deploying Lightning nodes, so I'm sure you have a better understanding of the current costs and trade-offs than I do.
>>
>> My understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct?
>>
>> If it is, then when a dedicated user (DLU) partners with a casual user (CLU), the DLU can only move liquidity to another Lightning channel by either:
>> 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
>> 2) putting a non-cooperative close transaction on-chain and waiting approximately 2 weeks (based on the to_self_delay parameter set by the CLU) before moving the liquidity.
>>
>> In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:
>> 1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or
>> 2) putting a non-cooperative close transaction on-chain and waiting approximately 1-3 months (based on the I_L parameter set by the CLU) before moving the liquidity.
>> In case 1), it would make sense for the DLU to refund the remaining portion of CLU's cost-of-capital pre-payment to the CLU, as that capital is now being made available to the DLU. This was not proposed in the paper, but it should probably be added.
>>
>> With this change (namely refunding the remainder of the cost-of-capital pre-payment), it seems like the only disadvantage of the WF protocol to the DLU is the larger delay (1-3 months vs. 2 weeks). Do you feel increasing the delay from 2 weeks to 1 month is prohibitive?
>>
>> My intuition is that in the long run, the cost of bitcoin capital will be very low, as it is an inherently deflationary monetary unit (and thus its value should increase with time). If this is correct, the long term cost-of-capital charges should be very low.
>>
>> What are your thoughts on this?
>>
>> Thanks,
>> John
>>
>>> Thanks again for sharing, and for the inherited IDs [3] proposal as well!
>>>
>>> Bastien
>>>
>>> [1] <a href="
>> https://github.com/lightning/bolts/pull/863
>> ">
>> https://github.com/lightning/bolts/pull/863
>> </a>
>>> [2] <a href="
>> https://www.peerswap.dev/
>> ">
>> https://www.peerswap.dev/
>> </a>
>>> [3] <a href="
>> https://github.com/JohnLaw2/btc-iids
>> ">
>> https://github.com/JohnLaw2/btc-iids
>> </a>
>>
>> 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/20221031/06378968/attachment-0001.html>;

📅 Original date posted:2022-10-11 📝 Original message: Hey ...

2023-06-09T13:07:00Z

In reply to nevent1q…k85c
_________________________

📅 Original date posted:2022-10-11
📝 Original message:
Hey Bastien,

Thanks for your reply.

Responses are in-line below:

> Hey John,
>
> Thanks for sharing, this is very interesting.
>
> There is a good insight here that we can remove the intermediate
> HTLC-timeout transaction for outgoing payments because we are the
> origin of that payment (and thus don't need to quickly claim the
> HTLC on-chain to then relay that failure to a matching incoming HTLC).
>
> More generally, you have perfectly identified that most of the
> complexity of today's transactions come from the need to ensure that
> a failing/malicious downstream channel doesn't negatively impact
> honest upstream channels when relaying payments, and that some of this
> complexity can be lifted when nodes don't relay payments.

Thanks!

> However, my main criticism of your proposal is that liquidity isn't free.
> While your improvements are great from the CLU's point of view, I'm not
> sure they're acceptable for the DLU. The main (probably only) job of an
> LSP (DLU in your terminology) is to efficiently allocate their liquidity.
> In order to do so, they must be able to quickly move liquidity from where
> it's unused to where it may be better used. That means closely watching
> the demand for block space and doing on-chain transactions when fees are
> low (to open/close channels, splice funds in/out [1], make peer swaps [2],
> etc). With your proposal, DLUs won't be able to quickly move liquidity
> around, so the only way to make up for this is to charge the CLU for the
> loss of expected revenue. I'm afraid that the amount DLUs would need to
> charge CLUs will be prohibitively expensive for most CLUs.
>
> I'm curious to get your feedback on that point.

I really appreciate your insight here. I'm just an interested observer who doesn't have experience with creating and deploying Lightning nodes, so I'm sure you have a better understanding of the current costs and trade-offs than I do.

My understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct?

If it is, then when a dedicated user (DLU) partners with a casual user (CLU), the DLU can only move liquidity to another Lightning channel by either:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
2) putting a non-cooperative close transaction on-chain and waiting approximately 2 weeks (based on the to_self_delay parameter set by the CLU) before moving the liquidity.

In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or
2) putting a non-cooperative close transaction on-chain and waiting approximately 1-3 months (based on the I_L parameter set by the CLU) before moving the liquidity.
In case 1), it would make sense for the DLU to refund the remaining portion of CLU's cost-of-capital pre-payment to the CLU, as that capital is now being made available to the DLU. This was not proposed in the paper, but it should probably be added.

With this change (namely refunding the remainder of the cost-of-capital pre-payment), it seems like the only disadvantage of the WF protocol to the DLU is the larger delay (1-3 months vs. 2 weeks). Do you feel increasing the delay from 2 weeks to 1 month is prohibitive?

My intuition is that in the long run, the cost of bitcoin capital will be very low, as it is an inherently deflationary monetary unit (and thus its value should increase with time). If this is correct, the long term cost-of-capital charges should be very low.

What are your thoughts on this?

Thanks,
John

> Thanks again for sharing, and for the inherited IDs [3] proposal as well!
>
> Bastien
>
> [1] <a href="https://github.com/lightning/bolts/pull/863">https://github.com/lightning/bolts/pull/863</a>;
> [2] <a href="https://www.peerswap.dev/">https://www.peerswap.dev/</a>;
> [3] <a href="https://github.com/JohnLaw2/btc-iids">https://github.com/JohnLaw2/btc-iids</a>;

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/20221012/f0ea0daa/attachment-0001.html>;

📅 Original date posted:2022-10-11 📝 Original message: Hi ...

2023-06-09T13:06:59Z

In reply to nevent1q…ah68
_________________________

📅 Original date posted:2022-10-11
📝 Original message:
Hi Dave,

Thanks for reading and for doing a better job of explaining the ideas than I did!

Responses are in-line below:

> Hi John,
>
> I had difficulty understanding your proposal description here and in
> your paper[1]. I wonder if others are having the same the same
> difficulty, so I've tried to reduce it down to just the essential idea
> so you can tell me if I'm understanding correctly and others can
> evaluate it more quickly. Here I go:
>
> In a traditional HTLC, the agreement is essentially:
>
> - Setup: Alice has x BTC, an unpublished value y, and the hash digest z
> which is hash(y)
> - HTLC success: Alice offers Bob the x BTC, which he can claim at any
> time if he publishes y satisfying the equation hash(y) == z
> - HTLC failure: Alice can spend the x BTC back to her wallet after some
> time t has elapsed
>
> If I understand your modified protocol correctly, the essential modified
> agreement is:
>
> - [Setup the same]
> - [HTLC success the same]
> - HTLC failure: Alice can spend the x BTC back to her wallet by first
> getting a trigger[2] transaction confirmed onchain, waiting b blocks,
> then getting the actual spend-back-to-wallet transaction confirmed
>
> Because the trigger transaction needs to be confirmed for b blocks
> before Alice can can spend the money back to her wallet, Bob doesn't
> need to take any action to lock-in an HTLC Success unless he sees the
> trigger transaction appear onchain or he expects to be offline for more
> than b blocks. This allows Alice to stay offline for as long as Bob can
> tolerate (which goes towards your point of Alice prepaying Bob for that
> tolerance).

Yes, that's exactly right.

I'd note that the transaction that plays the role of the "trigger" transaction is actually just Alice's Commitment transaction, so no new transaction is required.

I'd also note that the parameter "b" is exactly Bob's to_self_delay parameter and he has already committed himself to being able to respond to Alice's on-chain transactions within a window of b blocks, so the protocol doesn't put any additional requirements on his monitoring of the blockchain.

>
> [1]
> <a href="https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf">https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf</a>;
> [2] "Trigger" transaction is the name given to that type of transaction
> in section 4.2 of the Eltoo paper: <a href="https://blockstream.com/eltoo.pdf">https://blockstream.com/eltoo.pdf</a>;
>
> > One-Shot Receives
> > =================
> >
> I understand the essence of this idea to be simply encumbering dedicated
> user Bob's commitment transaction with a timelock so that he can't
> publish it until near the time when any HTLCs in it would expire.
> Alice's version of commitment would be unencumbered, so she could
> publish it any time.

Yes, that's correct.

In particular, dedicated user Bob can't publish his current Commitment transaction until Alice has put her conflicting current Commitment transaction on-chain (assuming she follows the protocol) or both parties have updated the state off-chain. As a result, Alice doesn't have to worry about the case where she submits her current Commitment and HTLC-success transactions only to later discover that Bob's current Commitment transaction has won the race, thus forcing Alice to then submit her transaction (which is like an HTLC-success transaction but isn't actually called that in the protocol) which reveals the hash preimage and takes payment of the HTLC. Forcing Alice to wait around to see who's current Commitment transaction has won the race seems like an inconvenient requirement for a casual user.

Is my understanding of this issue correct, or can Alice submit her transaction spending the HTLC output of Bob's current Commitment transaction even before he has submitted his current Commitment transaction? I realize this part of the protocol depends on node relay behavior, so it's harder to nail down and reason about than the consensus portion of the protocol. I may not have the correct understanding here, and if my understanding isn't correct, I'd really like to fix it.

> Although your proposal may address this in the normal case, I think it
> doesn't address the pathological case where honest casual user Alice
> broadcasts the latest commitment transaction but her channel partner,
> malicious dedicated user Mallory, broadcasts an older revoked commitment
> transaction. Because Mallory's revoked commitment transaction is older,
> its timelock has expired, so it can win the race against Alice's latest
> commitment transaction.
>
> To become aware of this situation and to broadcast a penalty transaction
> within the necessary time limit, Alice still needs to monitor the block
> chain. If Alice still needs to monitor the block chain in any case,
> this proposed change doesn't eliminate the underlying problem of onerous
> monitoring as far as I can tell.

You're right that Bob (or Mallory) could still broadcast an older revoked transaction, and if that happens, Alice needs to broadcast a penalty transaction within her long interval (I_L) safety parameter which I was suggesting she could set to something like 1-3 months. I felt that being able to shut off her phone and not worry about the Lightning app for all but a short time (say 10 minutes) every few months wasn't overly onerous. Do you feel that casual users wouldn't see it that way?

The issue of how often Alice needs to monitor the blockchain is based on her setting of her I_L parameter and is really independent of her ability to perform one-shot receives. My understanding is that in the current Lightning protocol, if Alice is receiving a payment and she gives the payment's secret to her partner Bob, and if Bob fails to update the channel state to reflect the payment, Alice has to 1) submit her Commitment and HTLC-success transactions, 2) wait to see if her current Commitment transaction or Bob's current Commitment transaction won the race, and if Bob's current Commitment transaction won, 3) submit her transaction spending Bob's current Commitment transaction's HTLC output. The protocol that supports one-shot receives eliminates steps 2) and 3) above, which seems like a better user interface.

Does that make sense?

Many thanks,
John

Sent with Proton Mail secure email.

📅 Original date posted:2022-10-03 📝 Original message: This ...

2023-06-09T13:06:58Z

In reply to nevent1q…07fc
_________________________

📅 Original date posted:2022-10-03
📝 Original message:
This is the first in a series of posts on ideas to improve the usability
and scalability of the Lightning Network. This post presents a new channel
protocol that allows casual users to send and receive Lightning payments
without having to meet onerous availability requirements or use a
watchtower service. This new Watchtower-Free (WF) protocol can also be
used to simplify the reception of Lightning payments for casual users. No
change to the underlying Bitcoin protocol is required.

A paper with a more complete description of the protocol, including
figures, is available [5].

Properties
==========

The user-visible properties of the WF protocol can be expressed using
two parameters:
* I_S: a short time interval (e.g., 10 minutes) for communicating with
peers, checking the blockchain, and submitting transactions to the
blockchain, and
* I_L: a long time interval (e.g., 1-3 months).

The casual user must be online for up to:
* I_S every I_L (e.g., 10 minutes every 1-3 months) to safeguard the funds
in their Lightning channel.

With the WF protocol, the latency for payments is unchanged from the
current protocol, but the latency for getting a payment receipt from an
uncooperative channel partner is increased. In addition, the casual user
may have to pay their channel partner for the partner's cost of capital
(which depends on I_L). If the casual user and their channel partner
follow the protocol, the channel can remain off-chain arbitrarily long.

First Attempt: Use The Current Lightning Protocol
=================================================

In order to motivate the new protocol, first consider what would happen if
a casual user attempted to achieve the above properties with the current
Lightning channel protocol. The casual user would set their
"to_self_delay" (which controls how quickly their channel partner can
receive funds from a transaction they put on-chain) and
"cltv_expiry_delta" (which controls the staggering of timeouts between
successive hops) parameters to values approaching I_L (because the casual
user could be unavailable for nearly that long). This would create three
problems:

* Problem 1: The casual user's proposed channel partner would likely
reject the creation of the channel due to the excessive "to_self_delay"
value.

* Problem 2: If a channel were created with these parameters, Lightning
payments would not be routed through it due to the excessive
"cltv_expiry_delta" value.

* Problem 3: If a channel were created with these parameters and if the
casual user sent a payment on that channel, their partner could have to
go on-chain in order to pull the payment from the casual user. In
particular, the casual user could be offline for nearly I_L (e.g., 1-3
months) when their partner receives the receipt, thus forcing their
partner to go on-chain to receive payment before the expiry of the
associated HTLC.

The WF Protocol
===============

The WF protocol solves these problems by modifying the Lightning protocol
as follows:

* Problem 1 is solved by having the casual user pre-pay their channel
partner for the cost of the partner's capital that's tied up in the
channel due to the very large "to_self_delay" value. This pre-payment is
included in the initial channel state and is updated at least once every
I_L to reflect the additional cost of capital due to the partner not yet
going on-chain.

* Problem 2 is solved by allowing casual users to designate themselves as
Casual-Lightning-Users (CLUs), while the remaining users are
Dedicated-Lightning-Users (DLUs). CLUs can only partner with DLUs to
open channels, such channels must be unannounced, and CLUs must not
route (as opposed to send or receive) payments. These constraints fit
naturally with the desires of casual users who want to send and receive
their Lightning payments, but not route payments for others. Support for
CLUs is analogous to support for SPV (Simplified-Payment-Verification)
nodes in Bitcoin.

* Problem 3 is solved by modifying both users' Commitment transactions in
the channel that sends the payment so the CLU can be offline for nearly
I_L without forcing their DLU partner to go on-chain. A simple approach
would be to delay the expiry of the HTLC for each payment in the sending
channel by I_L. This approach works, but it has the downside of delaying
(by I_L) the CLU's ability to force production of a payment receipt. A
better approach is to add a relative delay before the CLU can time out
the HTLC output of a Commitment transaction, thus enabling the DLU to
safely stay off-chain even after the expiry of the HTLC. That's the
approach taken here.

Let Alice be a CLU who shares a channel with DLU Bob. Bob sets his channel
parameters as he would in the current Lightning protocol, while Alice sets
her "to_self_delay" parameter (controlling Bob's payments to himself) to
I_L greater than it would be in the current Lightning protocol. Consider
the case where Alice sends a Lightning payment on the channel she shares
with Bob.

Let:
- eAB denote the expiry for this payment in the channel shared by Alice
and Bob,
- tsdA denote the "to_self_delay" parameter set by Alice, and
- tsdB denote the "to_self_delay" parameter set by Bob.

Three changes are made relative to the current Lightning protocol:
- a relative delay of tsdB is enforced before Alice can spend the HTLC
output for this payment in either Commitment transaction,
- after eAB, only Alice's (rather than both parties') signature is
required to spend the HTLC output in Alice's Commitment transaction,
and that output doesn't need to be spent using an HTLC-timeout
transaction that can be revoked (because the relative delay added
above guarantees Bob can prevent Alice from spending the HTLC output
in a revoked Commitment transaction that she puts on-chain), and
- both parties update the channel state off-chain at least once every
I_L to reflect Bob's cost of capital, as described above.

The resulting protocol, with a single payment from Alice outstanding, is
shown below:

+-+ AB +----+ A
|F|----+--->| CC |--->
+-+ | | |
. | | B
. | |--->
. +----+
|
|
| revkeyBi
| +---------->
| |
| +----+ | tsdB & A
+--->|C_Ai|--+---------->
| | |
| | | B
| | |------------->
| | |
| | | revkeyBi
| | | +---------->
| | | |
| | | | tsdB & (eAB) & A
| | |--+------------------->
| +----+ |
| | Preimage(X) & B
| +------------------->
|
|
|
| revkeyAi
| +---------->
| |
| +----+ | tsdA & B
+--->|C_Bi|--+---------->
| | |
| | | A
| | |------------->
| | |
| | | revkeyAi
| | | +---------->
. | | |
. | | | tsdB & (eAB) & A revkeyAi
. | |--+-------------------> +---------->
| +----+ | |
| | Preimage(X) & AB +-----+ | tsdA & B
V +------------------->|Hs_Bi|--+---------->
+-----+

where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
C_Ai is Alice's Commitment transaction for state i,
C_Bi is Bob's Commitment transaction for state i, and
Hs_Bi is Bob's HTLC-success transaction for state i.

The F transaction is on-chain, while the remaining transactions are
off-chain during normal protocol operation.

Requirements for output cases are as follows:
A: Alice's signature,
B: Bob's signature,
AB: Alice's and Bob's signatures,
revkeyAi: a signature using a revocation key that Alice can use to revoke
Bob's state i transaction,
revkeyBi: a signature using a revocation key that Bob can use to revoke
Alice's state i transaction,
tsdA: a relative delay equal to Alice's to_self_delay parameter,
tsdB: a relative delay equal to Bob's to_self_delay parameter,
(eAB): an absolute timelock equal to the expiry of the outstanding HTLC
offered by Alice, and
Preimage(X): the hash preimage of X.

Once Bob knows Preimage(X), he sends Preimage(X) to Alice and attempts to
update both parties' Commitment transactions to show payment of the HTLC.
If he has spent I_L time unsuccessfully trying to update those Commitment
transactions, he can submit his Commitment and HTLC-success transactions
to the blockchain. If at any point he sees Alice's Commitment transaction
on-chain, he stops trying to update the Commitment transactions off-chain
and he puts his transaction that reveals Preimage(X) and spends the HTLC
output in her Commitment transaction on-chain as soon as possible.

Alice implements the WF channel protocol as she would the current
Lightning channel protocol, except:
- she can choose to be intentionally unavailable, provided she is
available (or at least not intentionally unavailable) for at least I_S
every I_L (to update her pre-payment for Bob's cost of capital and to
revoke any old transactions put on-chain by Bob), and
- she does not put her Commitment transaction on-chain until she has
been available (or at least not intentionally unavailable) for at least
a grace period of G following the expiry of her offered HTLC (where G
is the same grace period as is used in the current Lightning protocol
and G <= I_S).

Correctness
===========

When Alice sends a payment on the channel she shares with Bob, the WF
protocol matches the Lightning protocol except the parties stay off-chain
longer with the WF protocol (to accommodate Alice's intentional
unavailability). Staying off-chain longer is safe for Alice, as she
originated the payment and thus does not have to time out the HTLC at any
specific time in order receive payment in an earlier hop. Staying
off-chain longer is also safe for Bob, because whenever Alice's (or Bob's)
Commitment transaction is put on-chain, the tsdB relative delay before
Alice can time out the HTLC output is long enough to allow Bob to put his
transaction on-chain that takes payment for the HTLC.

Finally, the WF protocol requires that Alice and Bob stay off-chain long
enough to guarantee that Alice will be available (or at least not
intentionally unavailable) for at least G, which is sufficient for both
parties to update the channel state off-chain. As a result, if both
parties follow the protocol, the channel will remain off-chain despite
Alice's intentional unavailability.

A more detailed proof of correctness is given in the paper [5].

One-Shot Receives
=================

While eliminating watchtowers is helpful for casual users, the protocol
for receiving Lightning payments could still be awkward for such users.
With the current Lightning protocol, when a user receives a payment and
their channel partner is unresponsive, the user must submit their
Commitment and HTLC-success transactions to the blockchain. However, if
their partner's conflicting Commitment transaction wins the race and is
included in the blockchain, the user then has to submit a different
transaction that reveals the HTLC's secret and spends the HTLC output in
their partner's Commitment transaction. The requirement to wait and check
the blockchain for the winning Commitment transaction (which might not be
determined until multiple blocks have been added to the blockchain) is
awkward for a casual user. It would be far preferable if the casual user
could always receive a payment by performing a sequence of off-chain
message exchanges and at most one submission to the blockchain. A protocol
that has this property will be said to support "one-shot receives".

The WF protocol can be made to support one-short receives (and to simplify
the process of getting a receipt) for CLU Alice by making the following
change whenever a new Commitment transaction for DLU Bob is signed by
Alice:
- if Bob has one or more outstanding HTLCs offered to Alice, the
nLocktime field of Bob's Commitment transaction is set to the expiry of
the earliest such HTLC,
- otherwise, the nLocktime field of Bob's Commitment transaction is set
to I_L in the future (relative to when Bob's Commitment transaction is
signed by Alice).

Before examining how this change supports one-shot receives, it's
important to resolve a technical issue. In the current Lightning protocol,
the nLocktime field in the Commitment transaction provides 24 bits of the
channel's state number in order to allow efficient revocation of old
on-chain Commitments (with the remaining 24 bits being provided by the
nSequence field of the Commitment transaction's sole input). Because we're
now using the nLocktime field to enforce an absolute timelock, those 24
bits of state number can no longer be encoded in the nLocktime field.
There are two solutions to this problem:
- add a second input to Bob's Commitment transaction that spends a UTXO
owned by Bob (the value of which is arbitrary and is refunded to Bob in
the Commitment transaction) and use the nSequence field of that input
to encode 24 bits of state number, or
- support only 24-bit state numbers, as 16 million channel states are
likely sufficient for most casual users.

In addition, the following constraints are added in order to guarantee
one-shot receives:
1. Whenever a new HTLC is offered to Alice, its expiry is set to exactly
her min_final_cltv_expiry parameter in the future. This constraint
guarantees that new HTLCs have expiries that are monotonically
nondecreasing.
2. Whenever Alice gives Bob a secret for an HTLC, that HTLC has the
earliest expiry of all the HTLCs in Alice's current Commitment
transaction.
3. Whenever a new channel state i+1 is created, Alice's partial signature
for Bob's Commitment transaction for state i+1 is given to Bob, and the
revocation key for Bob's Commitment transaction for state i is given to
Alice, before Bob's partial signature for Alice's Commitment
transaction for state i+1 is given to Alice.

Given these constraints and the setting of the nLocktime field in Bob's
Commitment transaction, Alice can always put her Commitment transaction
on-chain before Bob can put a conflicting current Commitment transaction
on-chain, thus providing one-shot receives. The details are provided in
the paper [5].

Finally, it's important to verify that the delay of Bob's Commitment
transaction (caused by the setting of its nLocktime field) does not create
any problems for Bob. First, for HTLCs offered to Alice (that is, payments
received by Alice), the current Lightning protocol requires that Bob wait
until after the expiry of his offered HTLC before he goes on-chain with
his Commitment and HTLC-timeout transactions. Therefore, the nLocktime
field has no impact on Bob's actions regarding HTLCs offered to Alice.
Second, for HTLCs offered by Alice (that is, payments sent by Alice), the
WF protocol does not force Bob to put his Commitment and associated
HTLC-success transactions on-chain before any specific time in order
guarantee the success of any HTLCs. As a result, Bob's ability to force
payment for HTLCs offered by Alice is unaffected by the nLocktime field in
his Commitment transactions. Note that the Lightning protocol does
require Bob to put his Commitment and associated HTLC-success transactions
on-chain by a specific time, which is why the changes described here
cannot be made to the Lightning protocol to support one-shot receives.

Getting A Payment Receipt
=========================

Consider again the case where casual user Alice has offered an HTLC to
Bob. At any time after the expiry of the HTLC, if Alice needs to get a
payment receipt and Bob is uncooperative, Alice can put her Commitment
transaction on-chain and then attempt to spend the HTLC output of her
Commitment transaction tsdB later. As was shown above, she is guaranteed
to win the race in putting her Commitment transaction on-chain due to the
nLocktime field in Bob's Commitment transaction. Therefore, she will
either get her receipt before she is able to spend the HTLC output or she
will not have to make her payment (because she succeeded in spending the
HTLC output). This procedure for getting a payment receipt isn't one-shot
and may be awkward for casual users. Fortunately, it's only required when
there's both a payment dispute (or other need to get a receipt quickly)
and an uncooperative channel partner.

Asynchronous Payments
=====================

The WF protocol gives significant flexibility to when CLUs have to be
online, but it still requires that the sender and receiver are both online
simultaneously. This requirement can be eliminated by keeping the relative
delay but removing the absolute delay in Alice's transaction that times
out an HTLC for a payment that she initiates. The details are given in the
paper [5].

Related Work
============

The protocol presented here is based extensively on previously-published
work, namely the Poon-Dryja Lightning channel protocol [1] and the BOLT
specifications [2]. The asynchronous payments protocol is based on
Corallo's proposal for sending tips to an offline receiver [3], but
differs by using only a relative delay in the sender's HTLC.

The idea of eliminating watchtowers for a casual user by delaying their
partner's ability to put transactions on-chain was described by Law [4],
but the interaction of that delay with HTLCs was not analyzed and that
paper assumed modifications to the underlying Bitcoin protocol.

Conclusions
===========

This post presents the idea of dividing users into Casual-Lightning-Users
(CLUs) that only send and receive payments, and Dedicated-Lightning-Users
(DLUs) that can also route payments. It gives a new protocol that allows
casual users to send and receive Lightning payments in a trust-free manner
without requiring a watchtower service. It also allows CLUs to receive
payments in a one-shot manner (that is, without having to wait for blocks
to be added to the blockchain). No changes to the Bitcoin protocol are
required.

The new protocol does have some disadvantages, such as increasing the cost
of capital for DLUs that partner with CLUs and increasing the latency for
CLUs to get payment receipts from uncooperative partners. Hopefully, the
elimination of watchtowers for casual users, and their ability to do
one-shot receives, will more than make up for these drawbacks.

I'm not an expert in the area, so I might have missed something.

Corrections and comments are greatly appreciated.

Regards,
John

References
==========

[1] Poon and Dryja, The Bitcoin Lightning Network, available at
https://lightning.network/lightning-network-paper.pdf.
[2] BOLT specifications, available at
https://github.com/lightningnetwork/lightning-rfc.
[3] Corallo, A Mobile Lightning User Goes to Pay a Mobile Lightning
User..., available at https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html.
[4] Law, Section 3.6 of Scaling Bitcoin With Inherited IDs, available at
https://github.com/JohnLaw2/btc-iids.
[5] Law, Watchtower-Free Lightning Channels For Casual Users, available at
https://github.com/JohnLaw2/ln-watchtower-free.

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/20221003/ee49228d/attachment-0001.html>;

📅 Original date posted:2021-10-10 📝 Original message: ...

2023-06-09T13:04:11Z

In reply to nevent1q…8vjj
_________________________

📅 Original date posted:2021-10-10
📝 Original message:
Response to email from Anthony Towns sent on 20210918 at 11:37:40 UTC
==============================================
aj,

Thanks for taking the time to go through my paper on inherited IDs (IIDs). Also, thanks for your concise and accurate description of the IID proposal and the 2Stage channel protocol. I'm glad you feel the 2Stage protocol might be better than eltoo for a two-party channel.

I want to address other parts of the paper that were obviously not as clear, as they led to two important misunderstandings.

First, there is the issue of the use of an operator in the "timeout trees", "update-forest" and "challenge-and-response" factory protocols. While those protocols do include a party that is designated as the "operator", the operator is in no way a trusted party. While it's true that one would prefer an operator that follows the protocol fully and promptly, as that would allow one to keep the protocol off-chain, the operator can never take funds or prevent others from obtaining the funds that are due to them. In fact, this is exactly analogous to the selection of the party with whom one shares a two-party lightning channel. If one views lightning as being trust-free, then one will also view "timeout trees", "update-forest" and "challenge-and-response" to be trust-free.

Second, there is the question of whether or not IIDs can be simulated with anyprevout. I don't believe that they can. Consider for example the case where Alice has an on-chain funding transaction F1 with output F1:0 that will be spent by a (currently off-chain) transaction F2 with output F2:0 that will be spent by a settlement transaction S. Assume further that there is an on-chain control transaction C1 with output C1:0 owned by untrusted operator O, where C1:0 will be spent by a (currently off-chain) transaction C2 with output C2:0 that may, in certain cases, also be spent by S. In particular, assume F1 puts a covenant on F2 such that F2 puts a covenant on S, where the covenant on S can be met by either: A) waiting a CSV delay of one time unit (defined to be long enough to allow a party with a competing transaction to put that competing transaction on-chain first) and then spending only F2:0 (where F2:0 is referenced via IID) and giving ownership of S:0 to Alice, or B) waiting until a CLV reaches time T_lock and then spending both F2:0 and C2:0 (where F2:0 and C2:0 are referenced via IIDs).

Assume that after Alice put F1 on-chain she wants to transfer ownership of the output S:0 to Bob without having to put F2 or S on-chain. She can do this with IIDs as follows. First, Alice asks the untrusted operator O to put C2 on-chain where C2 puts a covenant on S that forces S to spend both F2:0 and C2:0 (where F2:0 and C2:0 are referenced via IIDs) and to give ownership of S:0 to Bob (by making it spendable using Bob's public key).

There are two cases. First, if O promptly puts the desired C2 on-chain, then Alice and Bob can wait until T_lock (while putting nothing else on-chain), at which point Bob can be assured that he owns S:0 (as any attempt by Alice to spend S:0 by meetiing the covenant using case A above can be thwarted by Bob putting S on-chain first using case B above). Second, if O puts a different C2 on-chain, or fails to put any C2 on-chain promptly, Alice can reclaim her funds by putting F2 on-chain, waiting one time window, and then putting S on-chain using case A above.

Thus, IIDs provide a trust-free means for Alice to transfer funds from F1 to a party that is unknown to Alice when she puts F1 on-chain. I see two problems in tryinig to use anyprevout to achieve the same result. First, I don't know of any mechanism by which Alice can create a covenant that F2 puts on S which implements case B above. In some other settings, I can understand how one could use unique single-use keys in place of IID outputs. However, in this setting I don't see how to define a covenant that F2 puts on S that in case B forces the other input to spend C2:0, as signatures that are evaluated in spending F2:0 don't commit to the output scripts of other inputs to S. Second, and more fundamentally, even if one could define a covenant that F2 puts on S in case B forcing the other input to be signed by a single-use key owned by O, that still wouldn't unconditionally transfer ownership to Bob (without putting F2 and S on-chain). That's because in order to have single-use keys play the role of IIDs, they have to truly be single-use and there is no way Bob can know that O won't just sign some other S' that competes with S and sends S':0 to O, thus stealing the funds. Please let me know if I've missed something here.

The example above isn't very useful, as it doesn't cut down on the number of on-chain transactions required to transfer ownership from Alice to Bob. However, it does capture the core functionality that IIDs provide that (I believe) anyprevout does not provide. This functionality is exactly what enables "update-forest" and "challenge-and-response" to allow a single on-chain transaction to transfer ownership of thousands or millions of channels in a trust-free manner, thus accomplishing with one on-chain transaction what would have required thousands or millions of anyprevout transactions (at least as far as I can tell). This is exactly the power of IIDs that I was referring to, and I found surprising that this power was actually the result of restricting how a signed transaction can be used (as compared to a signed transaction that uses anyprevout).

I hope clearing up these two misunderstandings is enough to pique your interest in reading the "timeout trees", "update-forest" and "challenge-and-response" protocols in more detail, as I'd be interested in your expert opinion on them.

My remaining comments are minor compared to the previous ones.
* Regarding the worst-case delay for eltoo-2party vs. 2Stage, I agree that there is no single agreed upon model for analyzing this and opinions may differ. In any case, I think that if one had a nearly-expired HTLC (or if one is setting the lock time for an HTLC) and one could choose between eltoo-2party, where the other party could have thousands or millions of transactions competing with your settlement transaction, and 2Stage, where the other party can have at most one competing transaction, some would prefer 2Stage.
* In comparing eltoo-2party and 2Stage, I was surprised that you didn't consider 2Stage's elimination of watchtowers for one or both parties as being an advantage. I had through that would be a big win in practice.
* Regarding footnote 13's description of OP_CODESEPARATOR, I realize that that footnote does not capture the change made in taproot. I addressed that issue on p. 54 (and explained it in footnote 43), as footnote 13 was designed to explain OP_CODESEPARATOR to those not already familiar with it, while p. 54 was designed for the experts.
* Regarding the new address type for floating transactions mentioned in the paper, thanks for the correction. I'll remove this from the next version.

In summary, the paper shows that:
1) IIDs can be used to eliminate watchtowers for one or both parties in a two-party channel (2Stage),
2) IIDs can be used to create factories that allow very large numbers of new users to obtain bitcoin in a watchtower-free and trust-free manner (timeout trees),
3) IIDs support trust-free factories with unbounded numbers of parties (and channels) that allow the channels to be bought and sold by anyone, including parties not originally in the factory, with a single on-chain transaction, and
4) IIDs achieve these results while using a more constrained, and thus safer, change to Bitcoin than the support for floating transactions.

Are these results of interest?

Thanks,
John

Sent with [ProtonMail](https://protonmail.com/) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211010/ef8682ee/attachment-0001.html>;

📅 Original date posted:2023-03-17 🗒️ Summary of this ...

2023-06-07T23:20:19Z

In reply to nevent1q…7kgm
_________________________

📅 Original date posted:2023-03-17
🗒️ Summary of this message: The post discusses the liveliness/interactivity requirements of updating balance distribution in pools and the design of Lightning Network for always-online participants. The author suggests a trust-minimized solution for non-interactive, off-chain updates of the pool/factory. The post also discusses the double-spend issue and proposes solutions based on prophylactic or corrective security models.
📝 Original message:Hi Antoine,

Thanks for your insightful post on the interactivity issue.

Some thoughts are inline below.

> However, those constructions require all the users to be online and
> exchange rounds of signatures to update the balance distribution. Those
> liveliness/interactivity requirements are increasing with the number of
> users, as there are higher odds of *one* lazzy/buggy/offline user stalling
> the pool/factory updates.

> In echo, the design of LN was envisioned for a network of
> always-online/self-hosted participants, the early deployment of LN showed
> the resort to delegated channel hosting solutions, relieving users from the
> liveliness requirement. While the trust trade-offs of those solutions are
> significant, they answer the reality of a world made of unreliable networks
> and mobile devices.

Agreed that signing updates and monitoring the blockchain both create always-online requirements that are not compatible with casual users' desires.
I think it's helpful to separate these two cases, as they affect different parties and their solutions differ.
In particular, limited availability to sign updates affects one's partners and can be addressed by having fewer partners, not partnering with casual users, evicting unresponsive users, etc.
Limited availability to monitor the blockchain affects the security of one's own funds and can be addressed by increasing one's safety parameters (such as the to_self_delay parameter in Lightning).

> Ideally, I think we would like a trust-minimized solution enabling
> non-interactive, off-chain updates of the pool/factory, with no or minimal
> consumption of blockspace.

I would argue that we want a completely trust-free solution, if at all possible, while respecting users' actual availability.
We should only consider solutions that require trust if we can't find a trust-free solution that meets all other requirements.

> For the remainder of this post, only the pool use-case will be mentioned.
> Though, I think the observations/implications can be extended to factories
> as well.

> Of course, the double-spend issue is already addressed on the Bitcoin
> base-layer due to nodes consensus convergence on the most-proof-of-work
> accumulated valid chain of blocks. While reorg can happen, a UTXO cannot be
> spent twice on the same chain. This security model can be said to be
> prophylactic, i.e an invalid block cannot be applied to a node's state and
> should be rejected.

> The double-spend issue is also solved in its own way in payment channels.
> If a transaction is published, of which the correctness has been revoked
> w.r.t negotiated, private channel state, the wronged channel users must
> react in consequence. This security model can be said to be corrective,
> states updates are applied first on the global ledger then eventually
> corrected.

> A solution to the pool partition equivocation issue appears as either based
> on a prophylactic one or a corrective security model.

Actually, there's a third class of solutions that are possible, namely ones that use separate control transactions and value transactions (where the value transactions "spend", and therefore depend on, the control transactions).
If an invalid control transaction is put on-chain, it can be blocked by another user by spending its output(s) before the output(s) can affect the value transaction.
Thus, control transactions can be viewed as proposals for state updates, and those proposals are blocked if they aren't valid.

These solutions differ from prophylactic solutions, as they allow incorrect transactions to be put on-chain and require another user to block them.
They also differ from your definition of a corrective security model, as they never allow the state update to be applied to the value in the channel or pool, so there's nothing to be corrected.
An example of this third class of solutions is the Tunable-Penalty Factory protocol [1].
Of course, this example was not available when you noted that solutions are either prophylactic or corrective.

> E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
> Alice contacts Bob to form a first partition, then Caroll to form a second
> one, then Dave to form a last one. If she is successful in that
> equivocation trick, she can *triple*-spend her balance against any goods or
> out-of-pool payments.

> However, correction can only
> be limited to the equivocated balance. Therefore, it appears that
> corrective security models in the context of multi-party are always
> producing an economic disequilibrium.

On the other hand, protocols that use separate control and value transactions do not have this limitation.
For example, the Tunable-Penalty Factory protocol is a multi-party protocol in which every dishonest party is penalized and there is no economic disequilibrium.

> I think that leveraging covenants a revocation mechanism could be attached
> on any equivocating branch of transactions, allowing in the above case a
> single honest user to punish the publication. While a revocation mechanism
> does not work in case of multiple defrauded users, I believe the existence
> of a revocation mechanism makes the formation of malicious coalitions
> unsafe for their conjurers.

> Indeed, any user entering in the coalition is not guaranteed to be blinded
> to other equivocating branches generated by the partition initiator.
> Therefore, the publication of a partition statement by everyone is
> holistically optimal to discover any equivocating candidate among the pool
> users.

If I understand this correctly, I think a penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.
Consider the case where Alice is an honest user who joins a partition with Bob, where Bob and Carol are in a malicious coalition.
Alice believes she has pooled her funds with Bob's and so she is able to work with Bob to implement an off-line update of their balances, with Alice believing that she has gained ownership over some of Bob's funds.
However, when the partitioning Update transaction that joins Alice's and Bob's funds is put on-chain, Carol pretends to have been "wronged" by Bob and uses the penalty mechanism to seize Bob's funds.
In this case, Alice won't be able to get the funds that she thought she had obtained from Bob.

Does that make sense?

Regards,
John

[1] Law, "Efficient Factories For Lightning Channels", available at https://github.com/JohnLaw2/ln-efficient-factories.

Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230317/04bc8655/attachment.html>;

📅 Original date posted:2021-10-10 📝 Original ...

2023-06-07T22:59:59Z

In reply to nevent1q…4ha0
_________________________

📅 Original date posted:2021-10-10
📝 Original message:Response to email from Anthony Towns sent on 20210918 at 11:37:40 UTC
==============================================
aj,

Thanks for taking the time to go through my paper on inherited IDs (IIDs). Also, thanks for your concise and accurate description of the IID proposal and the 2Stage channel protocol. I'm glad you feel the 2Stage protocol might be better than eltoo for a two-party channel.

I want to address other parts of the paper that were obviously not as clear, as they led to two important misunderstandings.

First, there is the issue of the use of an operator in the "timeout trees", "update-forest" and "challenge-and-response" factory protocols. While those protocols do include a party that is designated as the "operator", the operator is in no way a trusted party. While it's true that one would prefer an operator that follows the protocol fully and promptly, as that would allow one to keep the protocol off-chain, the operator can never take funds or prevent others from obtaining the funds that are due to them. In fact, this is exactly analogous to the selection of the party with whom one shares a two-party lightning channel. If one views lightning as being trust-free, then one will also view "timeout trees", "update-forest" and "challenge-and-response" to be trust-free.

Second, there is the question of whether or not IIDs can be simulated with anyprevout. I don't believe that they can. Consider for example the case where Alice has an on-chain funding transaction F1 with output F1:0 that will be spent by a (currently off-chain) transaction F2 with output F2:0 that will be spent by a settlement transaction S. Assume further that there is an on-chain control transaction C1 with output C1:0 owned by untrusted operator O, where C1:0 will be spent by a (currently off-chain) transaction C2 with output C2:0 that may, in certain cases, also be spent by S. In particular, assume F1 puts a covenant on F2 such that F2 puts a covenant on S, where the covenant on S can be met by either: A) waiting a CSV delay of one time unit (defined to be long enough to allow a party with a competing transaction to put that competing transaction on-chain first) and then spending only F2:0 (where F2:0 is referenced via IID) and giving ownership of S:0 to Alice, or B) waiting until a CLV reaches time T_lock and then spending both F2:0 and C2:0 (where F2:0 and C2:0 are referenced via IIDs).

Assume that after Alice put F1 on-chain she wants to transfer ownership of the output S:0 to Bob without having to put F2 or S on-chain. She can do this with IIDs as follows. First, Alice asks the untrusted operator O to put C2 on-chain where C2 puts a covenant on S that forces S to spend both F2:0 and C2:0 (where F2:0 and C2:0 are referenced via IIDs) and to give ownership of S:0 to Bob (by making it spendable using Bob's public key).

There are two cases. First, if O promptly puts the desired C2 on-chain, then Alice and Bob can wait until T_lock (while putting nothing else on-chain), at which point Bob can be assured that he owns S:0 (as any attempt by Alice to spend S:0 by meetiing the covenant using case A above can be thwarted by Bob putting S on-chain first using case B above). Second, if O puts a different C2 on-chain, or fails to put any C2 on-chain promptly, Alice can reclaim her funds by putting F2 on-chain, waiting one time window, and then putting S on-chain using case A above.

Thus, IIDs provide a trust-free means for Alice to transfer funds from F1 to a party that is unknown to Alice when she puts F1 on-chain. I see two problems in tryinig to use anyprevout to achieve the same result. First, I don't know of any mechanism by which Alice can create a covenant that F2 puts on S which implements case B above. In some other settings, I can understand how one could use unique single-use keys in place of IID outputs. However, in this setting I don't see how to define a covenant that F2 puts on S that in case B forces the other input to spend C2:0, as signatures that are evaluated in spending F2:0 don't commit to the output scripts of other inputs to S. Second, and more fundamentally, even if one could define a covenant that F2 puts on S in case B forcing the other input to be signed by a single-use key owned by O, that still wouldn't unconditionally transfer ownership to Bob (without putting F2 and S on-chain). That's because in order to have single-use keys play the role of IIDs, they have to truly be single-use and there is no way Bob can know that O won't just sign some other S' that competes with S and sends S':0 to O, thus stealing the funds. Please let me know if I've missed something here.

The example above isn't very useful, as it doesn't cut down on the number of on-chain transactions required to transfer ownership from Alice to Bob. However, it does capture the core functionality that IIDs provide that (I believe) anyprevout does not provide. This functionality is exactly what enables "update-forest" and "challenge-and-response" to allow a single on-chain transaction to transfer ownership of thousands or millions of channels in a trust-free manner, thus accomplishing with one on-chain transaction what would have required thousands or millions of anyprevout transactions (at least as far as I can tell). This is exactly the power of IIDs that I was referring to, and I found surprising that this power was actually the result of restricting how a signed transaction can be used (as compared to a signed transaction that uses anyprevout).

I hope clearing up these two misunderstandings is enough to pique your interest in reading the "timeout trees", "update-forest" and "challenge-and-response" protocols in more detail, as I'd be interested in your expert opinion on them.

My remaining comments are minor compared to the previous ones.
* Regarding the worst-case delay for eltoo-2party vs. 2Stage, I agree that there is no single agreed upon model for analyzing this and opinions may differ. In any case, I think that if one had a nearly-expired HTLC (or if one is setting the lock time for an HTLC) and one could choose between eltoo-2party, where the other party could have thousands or millions of transactions competing with your settlement transaction, and 2Stage, where the other party can have at most one competing transaction, some would prefer 2Stage.
* In comparing eltoo-2party and 2Stage, I was surprised that you didn't consider 2Stage's elimination of watchtowers for one or both parties as being an advantage. I had through that would be a big win in practice.
* Regarding footnote 13's description of OP_CODESEPARATOR, I realize that that footnote does not capture the change made in taproot. I addressed that issue on p. 54 (and explained it in footnote 43), as footnote 13 was designed to explain OP_CODESEPARATOR to those not already familiar with it, while p. 54 was designed for the experts.
* Regarding the new address type for floating transactions mentioned in the paper, thanks for the correction. I'll remove this from the next version.

In summary, the paper shows that:
1) IIDs can be used to eliminate watchtowers for one or both parties in a two-party channel (2Stage),
2) IIDs can be used to create factories that allow very large numbers of new users to obtain bitcoin in a watchtower-free and trust-free manner (timeout trees),
3) IIDs support trust-free factories with unbounded numbers of parties (and channels) that allow the channels to be bought and sold by anyone, including parties not originally in the factory, with a single on-chain transaction, and
4) IIDs achieve these results while using a more constrained, and thus safer, change to Bitcoin than the support for floating transactions.

Are these results of interest?

Thanks,
John

Sent with [ProtonMail](https://protonmail.com/) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211010/ef8682ee/attachment.html>;