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