From: jlspc <jlspc@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev@lists•linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Lightning With Simple Covenants
Date: Fri, 06 Oct 2023 16:26:33 +0000 [thread overview]
Message-ID: <8rIB8SDRdFLp97JKorrGQ9Rr_v6q9I9-S7mJlWXWineubc_RvfJXhH3nz75DgOpTTwpSo4NEJYpxn2ozEHIVTvajISa03JsVspQWWZWbTzc=@protonmail.com> (raw)
In-Reply-To: <CALZpt+Fv8YO8g=7q-au37uU7iF-Qh2sFq-Q99msrGi==E3+06w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7937 bytes --]
Hi Antoine,
>><i> "I also think resizing channels can be done fairly effectively off-chain
></i>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.
>><i> "With these proposals, it's possible to dramatically limit the
></i>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> "I propose that if the active drain fails, the casual user should put
></i>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).
>><i> "These costs could be large, but hopefully they're rare as they are
></i>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.
>><i> "However, the paper has a proposal for the use of "short-cut"
></i>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 < i and i is the current state number) and Carol spends the first control output of ST_Bh, Bob cannot put COM_Bi on-chain, but Alice can still put ST_Ai and COM_Ai on-chain.
>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.
[-- Attachment #2: Type: text/html, Size: 9083 bytes --]
next prev parent reply other threads:[~2023-10-06 16:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 18:54 jlspc
2023-09-11 0:56 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2023-09-17 0:52 ` jlspc
2023-11-15 19:59 ` jlspc
2023-09-11 2:13 ` [bitcoin-dev] " Rusty Russell
2023-09-17 0:56 ` jlspc
2023-09-11 5:27 ` Antoine Riard
2023-09-17 0:59 ` jlspc
2023-09-26 16:42 ` Antoine Riard
2023-10-06 16:26 ` jlspc [this message]
2023-09-17 11:32 ` Erik Aronesty
2023-09-19 7:44 ` ZmnSCPxj
2023-09-18 4:14 ` ZmnSCPxj
2023-09-28 15:56 ` jlspc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='8rIB8SDRdFLp97JKorrGQ9Rr_v6q9I9-S7mJlWXWineubc_RvfJXhH3nz75DgOpTTwpSo4NEJYpxn2ozEHIVTvajISa03JsVspQWWZWbTzc=@protonmail.com' \
--to=jlspc@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox