Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-12 📝 Original message: Hi Greg, > Feel free to ...
📅 Original date posted:2022-12-12
📝 Original message:
Hi Greg,
> Feel free to assume that we've worked around mempool pinning for all of
> these discussions, otherwise we're pretty hosed regardless. I'm implicitly
> assuming V3+ephemeral anchors, which disallows batched bumps, for example.
> You'll need to give some room for "slippage", but I think
> shared_delay/2*shared_delay is going to end up dominating UX in any
> non-layered scheme.
I think I was making the same assumption of V3+ephemeral anchors, and
effectively disabling batching removes the known case of "commitment
cat-and-mouse" attack, where a counterparty goes to confirm the commitment
one by one to break the validity of the common CPFP. However, I wonder if
there is not another attack case, see my other "update overflow" mail, and
I don't think it qualifies as a pinning here!
> This architecture doesn't suffer from 2*self_delay, and each transition
> aside from Slow/Settle/SX.y has no relative timelock so that relative
> timelock is all that matters. It does introduce a watchtower cycle, so
it's
> not longer a one-shot architecture, or even k-shot exactly, it ends up
> looking like vanilla eltoo for that single path.
Here I think my understanding is aligned, the watchtower cycle ends up
looking more like the update phase of vanilla eltoo.
Antoine
Le jeu. 8 déc. 2022 à 15:28, Greg Sanders <gsanders87 at gmail.com> a écrit :
> Antoine,
>
> > While the 2*to_self_delay sounds the maximum time delay in the state
> publication scenario where the cheating counterparty publishes a old state
> then the honest counterparty publishes the latest one, there could be the
> case where the cheating counterparty broadcast chain of old states, up to
> mempool's `limitancestorcount`. However, this chain of eltoo transactions
> could be replaced by the honest party paying a higher-feerate (assuming
> something like nversion=3). I think there might still be an attack
> triggerable under certain economic conditions, where the attacker overbids
> with the higher-feerate transaction until the HTLC cltv expires. If this
> attack is plausible, it could be even opportun if you're batching against
> multiple channels, where the victims are not able to coordinate response.
>
> Feel free to assume that we've worked around mempool pinning for all of
> these discussions, otherwise we're pretty hosed regardless. I'm implicitly
> assuming V3+ephemeral anchors, which disallows batched bumps, for example.
> You'll need to give some room for "slippage", but I think
> shared_delay/2*shared_delay is going to end up dominating UX in any
> non-layered scheme.
>
> > I wonder if the introduction of watchtower specific transactions doesn't
> break the 2*to_self_delay assumption
>
> This architecture doesn't suffer from 2*self_delay, and each transition
> aside from Slow/Settle/SX.y has no relative timelock so that relative
> timelock is all that matters. It does introduce a watchtower cycle, so it's
> not longer a one-shot architecture, or even k-shot exactly, it ends up
> looking like vanilla eltoo for that single path.
>
> Cheers,
> Greg
>
> On Thu, Dec 8, 2022 at 2:14 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi AJ,
>>
>> The eltoo irc channel is ##eltoo on Libera chat.
>>
>> > - 2022-10-21, eltoo/chia:
>> https://twitter.com/bramcohen/status/1583122833932099585
>>
>> On the eltoo/chia variant, from my (quick) understanding, the main
>> innovation aimed for is the limitation of the publication of eltoo states
>> more than once by a counterparty, by introducing a cryptographic puzzle,
>> where the witness can be produced once and only once ? I would say you
>> might need the inheritance of the updated scriptpubkey across the chain of
>> eltoo states, with a TLUV-like mechanism.
>>
>> > The basic idea is "if it's a two party channel with just Alice and Bob,
>> > then if Alice starts a unilateral close, then she's already had her say,
>> > so it's only Bob's opinion that matters from now on, and he should be
>> > able to act immediately", and once it's only Bob's opinion that matters,
>> > you can simplify a bunch of things.
>>
>> From my understanding, assuming Eltoo paper terminology, Alice can
>> publish an update K transaction, and then after Bob can publish an update
>> transaction K<N or Alice can publish the settlement transaction N, or Bob
>> can publish an update transaction N. The main advantage of this
>> construction I can see is a strict bound on the shared_delay encumbered in
>> the on-chain publication of the channel ?
>>
>> > fast forwards: we might want to allow our channel partner
>> > to immediately rely on a new state we propose without needing a
>> > round-trip delay -- this potentially makes forwarding payments much
>> > faster (though with some risk of locking the funds up, if you do a
>> > fast forward to someone who's gone offline)
>>
>> IIRC, there has already been a "fast-forward" protocol upgrade proposal
>> based on update-turn in the LN-penalty paradigm [0]. I think reducing the
>> latency of HTLC propagation across payment paths would constitute a UX
>> improvement, especially a link-level update mechanism upgrade deployment
>> might be incentivized by routing algorithms starting to penalize routing
>> hops HTLC relay latency. What is unclear is the additional risk of locking
>> the funds up. If you don't receive acknowledgement the fast forward state
>> has been received, you should still be able to exit with the state N-1 ?
>> However, the fast-forward trade-off might sound acceptable, with time you
>> might expect reliable routing hops in the core of the graph, and flappy
>> spokes at the edge.
>>
>> > doubled delays: once we publish the latest state we can, we want to
>> > be able to claim the funds immediately after to_self_delay expires;
>> > however if our counterparty has signatures for a newer state than we
>> > do (which will happen if it was fast forwarded), they could post that
>> > state shortly before to_self_delay expires, potentially increasing
>> > the total delay to 2*to_self_delay.
>>
>> While the 2*to_self_delay sounds the maximum time delay in the state
>> publication scenario where the cheating counterparty publishes a old state
>> then the honest counterparty publishes the latest one, there could be the
>> case where the cheating counterparty broadcast chain of old states, up to
>> mempool's `limitancestorcount`. However, this chain of eltoo transactions
>> could be replaced by the honest party paying a higher-feerate (assuming
>> something like nversion=3). I think there might still be an attack
>> triggerable under certain economic conditions, where the attacker overbids
>> with the higher-feerate transaction until the HTLC cltv expires. If this
>> attack is plausible, it could be even opportun if you're batching against
>> multiple channels, where the victims are not able to coordinate response.
>>
>> > penalties: when you do a unilateral close, attempting to cheat comes
>> > with no cost to you and a possible benefit if you succeed, but
>> > potentially does cost your channel partner (either in forcing them
>> > to spend on-chain fees to update to the correct state, or in the risk
>> > of loss if their node malfunctions occassionally) -- a penalty could
>> > reduce this incentive to cheat
>>
>> I think there has been a proposal in the past to enable penalties on top
>> of symmetric states by leveraging asymmetric witnesses [1]. Further, I
>> wonder if there is a game-theory interest for penalty-on-top-eltoo, it
>> could be an incentive against laziness, where a dysfunctional trusted
>> watchtower broadcasts an old state. On the qualification of the game-theory
>> soundness, I think one would have to run the empirical case study: select
>> channel counterparties randomly (no out-of-band assumptions), one set with
>> eltoo+penalty and the other with vanilla eltoo, observe the broadcast of
>> revoked states over some period.
>>
>> > trustless watchtowers: we may want to consider the possibility of a
>> > watchtower holding onto obsolete states and colluding with an
>> > attacker to attempt to cheat us
>>
>> In terms of pinning and other mempool games, I think honest participant
>> own states leveraged by a colluding watchtower might increase the attack
>> surface, especially post-anchor with the SIGHASH_SINGLE malleability on
>> second-stage HTLC transactions.
>>
>> > (I think for initial eltoo experimentation it doesn't make sense to try
>> to
>> > deal with all (or perhaps any) of those constraints; simple and working
>> > is better than complex and theoretical. But having them written down so
>> > the ideas can be thought about and looked up later still seems useful)
>>
>> I share the belief -- "simple and working" enable shorter iteration
>> cycles and hopefully fasten the protocol design learning curve. Beyond, I
>> think it's also realistic in face of the state of the LN ecosystem,
>> especially on the watchtower issue. AFAICT, there is no even multi trusted
>> watchtower design covering the full execution of the protocol (i.e
>> including HTLC-preimage/ HTLC-timeout claim), and such implementation is
>> far from simple, as from now on you LN's chain backend might have
>> asynchronicity issue to solve between your on-chain monitoring state
>> machine (at least speaking in knowledge of the LDK-architecture).
>>
>> > * WA.n, WB.n : watchtower update to state n
>> > - this is for an untrusted watchtower to correct attempted cheating
>> > by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
>> > (or UA.k/WB.k) respectively, provided k < n.
>>
>> I wonder if the introduction of watchtower specific transactions doesn't
>> break the 2*to_self_delay assumption (iiuc it's a design goal of current
>> protocol) and what is the design rationale. Beyond that, there is a concern
>> with watchtower-specific transactions, it might leak your towers topology
>> (i.e the number of them and the distribution in the p2p network) to an
>> adversary.
>>
>> > * SA.n, SB.n : slowly claim funds according to state n
>> > - this is for Alice to claim her funds if Bob is completely offline
>> > (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
>> > timelock of to_self_delay.
>>
>> If I'm following correctly the description, this is logically equivalent
>> to the sweep of a `to_local`/`to_remote` output on a commitment transaction
>> though instead the waiting delay is eltoo shared_delay. There is no
>> to_self_delay, at the punishment seems only to happen on the update-level,
>> or maybe one should be also able to punish slow fund exit, and another
>> relative locktime should exist on the S* transactions.
>>
>> > * Alice and Bob's watchtower collude, but Bob has many watchtowers:
>> >
>> > F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
>>
>> Could the punishment transactions R* be also delegated to watchtowers,
>> assuming they have been pre-signed to lockdown the exit scriptpubkeys ?
>>
>> > In order to allow fast-forwards, when Alice proposes a new state,
>> > she needs to send her partial signatures to allow Bob to unilaterally
>> > accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
>> > also needs to be able to claim the funds if Bob proposes the new state
>> > and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
>> > achieved with an adaptor signature approach (spelt out a bit more fully
>> > in the gist) or a CTV-like approach, provided that UB.n reveals the
>> > state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
>> >
>> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
>> ).
>>
>> If you would like to have fast forward of chain of transactions, I wonder
>> if there could be also the "sig-in-the-script" trick, where UB.n
>> scriptpubkey (or one of its tapscripts) contains the signature for CB.n,
>> SB.n, RB.n. Though you might have an issue of re-generating the
>> witnessscript in case of state loss.
>>
>> > * how to add fees -- the U/W transactions are 1-in/1-out transactions
>> > that can't be trivially CPFPed by the proposer and need to have
>> > fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
>> > ephemeral output and package relay might be workable); the C/S/R
>> > transactions are 1-in/many-out transactions, but have balance outputs
>> > that can be immediately spent to pay for fees via CPFP if package
>> > relay is available.
>>
>> Assuming something like nversion=3, the SINGLE/ANYONCANPAY could be a
>> viable fee-bumping mechanism, as ancestor-based pinning should be less of a
>> concern. Ephemeral anchor output could be a more efficient direction, if
>> the output value can be cooperatively inflated from the channel value,
>> rather than relying on external fee-bumping reserves. I think even more
>> efficient fee-bumping primitives can be introduced later.
>>
>> > * how to pay watchtowers -- when a watchtower broadcasts a W
>> > transaction, it needs to add fees, and it's not clear (to me) how it
>> > could fairly and reliably ensure it's compensated for those costs,
>> > particularly if multiple W transactions are broadcast for a single
>> > unilateral close attempt, due to one or more watchtowers colluding
>> > with an attacker, or simply having out of date information.
>>
>> I wonder if paying a watchtower, or getting paid as a watchtower isn't a
>> "counterparty risk" similar to what is happening with jamming due to
>> non-covered HTLC forward risk. The watchtower has the risk of not being
>> paid a posteriori and the user has the risk of the tower not acting. There
>> is even a trade-off between tower costs and safety, as the more towers you
>> have, more robust if your Lightning channel (in theory, as you also have a
>> duplication of the key material).
>>
>> > * lack of layered transactions -- while this prevents you having to
>> > wait longer than to_self_delay before you can claim channel funds,
>> > it still means that any htlc that is going to timeout sooner than that
>> > may not be claimable on-chain, meaning you need to set
>> > cltv_expiry_delta >= to_self_delay.
>>
>> From a security perspective, offsetting the cltv_expiry_delta to a value
>> superior to to_self_delay can be considered as an improvement, especially
>> if it gradually does it network-wide. On the other hand, if routing
>> algorithms start to penalize long-cltv-delta payment paths as the timevalue
>> of liquidity is priced in routing fees, this design rationale might not be
>> aligned with long-term LN network incentives (as of today even more
>> loosely-defined than miner incentives).
>>
>> > * extending to multiparty channels -- penalising is hard if there's
>> > more than two parties, fast forwards are probably impossible since
>> > you need multiple round-trips to coordinate signatures anyway, and if
>> > you're doing channels-within-channels to reduce your n-party channel
>> > to an easier to update 2-party channel you're probably forced to have
>> > to_self_delay for each layer of channels. Also, just figuring out how
>> > to coordinate multiparty state updates and even keeping everyone in
>> > a multiparty channel online consistently to generate new signatures
>> > seems potentially hard?
>>
>> I don't know if penalising has been a solved issue for mulit-party, at
>> least in a trustless fashion in the same way we have with 2-party
>> LN-penalty (you could devise weird scheme based on timelock, taproot tree
>> and threshold signatures incentivizing towards the convergence of a
>> "consensus" punishment, still...) Figuring out coordinating multi-party
>> states updates sounds workable with modern consensus algorithms (e.g Raft),
>> though still conserving the fast forward effect is a high bar, it might be
>> better deferred to an uplifted layer of 2-of-2 LN channels. The only reason
>> you might have payments at the multi-party level (with the signature of the
>> N-of-N participants requested) only for privacy or liquidity allocation
>> reason. Though effectively, it sounds like your multiparty
>> channel coordination mechanism should encompass party eviction or
>> partitioning the offline parties. One or two orders of magnitude of
>> complexity beyond the 2-party eltoo channel case, I think.
>>
>> Antoine
>>
>> [0] https://github.com/lightning/bolts/pull/867
>> [1] https://github.com/LLFourn/witness-asymmetric-channel
>>
>> Le mer. 7 déc. 2022 à 00:36, Anthony Towns <aj at erisian.com.au> a écrit :
>>
>>> Hi all,
>>>
>>> On the eltoo irc channel we discussed optimising eltoo for the 2-party
>>> scenario; figured it was probably worth repeating that here.
>>>
>>> This is similar to:
>>>
>>> - 2018-07-18, simplified eltoo:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001363.html
>>> - 2021-09-17, IID 2Stage,
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019470.html
>>> - 2022-09-29, Daric: https://eprint.iacr.org/2022/1295
>>> - 2022-10-21, eltoo/chia:
>>> https://twitter.com/bramcohen/status/1583122833932099585
>>>
>>> The basic idea is "if it's a two party channel with just Alice and Bob,
>>> then if Alice starts a unilateral close, then she's already had her say,
>>> so it's only Bob's opinion that matters from now on, and he should be
>>> able to act immediately", and once it's only Bob's opinion that matters,
>>> you can simplify a bunch of things.
>>>
>>> A "gist" for this idea is
>>> https://gist.github.com/ajtowns/53e0f735f4d5c06a681429d937200aa5 (it
>>> goes into a little more detail in places, though doesn't cover trustless
>>> watchtowers at all).
>>>
>>>
>>>
>>> In particular, there are a few practical constraints that we might like
>>> to consider for 2-party channels with eltoo:
>>>
>>> - fast forwards: we might want to allow our channel partner
>>> to immediately rely on a new state we propose without needing a
>>> round-trip delay -- this potentially makes forwarding payments much
>>> faster (though with some risk of locking the funds up, if you do a
>>> fast forward to someone who's gone offline)
>>>
>>> - doubled delays: once we publish the latest state we can, we want to
>>> be able to claim the funds immediately after to_self_delay expires;
>>> however if our counterparty has signatures for a newer state than we
>>> do (which will happen if it was fast forwarded), they could post that
>>> state shortly before to_self_delay expires, potentially increasing
>>> the total delay to 2*to_self_delay.
>>>
>>> - penalties: when you do a unilateral close, attempting to cheat comes
>>> with no cost to you and a possible benefit if you succeed, but
>>> potentially does cost your channel partner (either in forcing them
>>> to spend on-chain fees to update to the correct state, or in the risk
>>> of loss if their node malfunctions occassionally) -- a penalty could
>>> reduce this incentive to cheat
>>>
>>> - trustless watchtowers: we may want to consider the possibility of a
>>> watchtower holding onto obsolete states and colluding with an
>>> attacker to attempt to cheat us
>>>
>>> What follows is a rough approach for dealing with all those issues for
>>> two-party channels. It's spelled out in a little more detail in the gist.
>>>
>>> (I think for initial eltoo experimentation it doesn't make sense to try
>>> to
>>> deal with all (or perhaps any) of those constraints; simple and working
>>> is better than complex and theoretical. But having them written down so
>>> the ideas can be thought about and looked up later still seems useful)
>>>
>>> In more detail: unilateral closes are handled by each channel participant
>>> maintaining five transactions, which we'll call:
>>>
>>> * UA.n, UB.n : unilaterally propose closing at state n
>>> - this is for Alice or Bob to spend the funding tx for a unilater
>>> close to state n. Spends the funding transaction.
>>>
>>> * WA.n, WB.n : watchtower update to state n
>>> - this is for an untrusted watchtower to correct attempted cheating
>>> by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
>>> (or UA.k/WB.k) respectively, provided k < n.
>>>
>>> * CA.n, CB.n : cooperatively claim funds according to state n
>>> - this is for Alice to confirm Bob's unilateral close (or vice-versa).
>>> Spends UB.k, WA.k (or UA.k/WB.k respectively), provided k <= n
>>>
>>> * SA.n, SB.n : slowly claim funds according to state n
>>> - this is for Alice to claim her funds if Bob is completely offline
>>> (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
>>> timelock of to_self_delay.
>>>
>>> * RA.n, RB.n : claim funds with penalty after unilateral close to
>>> revoked state
>>> - this is for Alice to update the state if Bob attempted to cheat
>>> (or vice-versa). Spends UB.k or WA.k (or UA.k/WB.k respectively)
>>> conditional on k < n - 1; outputs are adjusted to transfer a fixed
>>> penalty of penalty_msat from Bob's balance to Alice's (or
>>> vice-versa)
>>>
>>> Each of these "transactions" requires a pre-signed signature; however
>>> the actual transaction/txid will vary in cases where a transaction has
>>> the possibility of spending different inputs (eg "Spends UB.k or WA.k").
>>> In particular UA.n/UB.n can be constructed with known txids and non-APO
>>> signatures but WA.n/WB.n/CA.n/CB.n/SA.n/SB.n/RA.n/RB.n all require
>>> APO signatures.
>>>
>>> They're named such that Alice can immediately broadcast all the *A.n
>>> transactions (provided a tx that it can spend has been broadcast) and
>>> Bob can likewise immediately broadcast all the *B.n transactions.
>>>
>>> Scenarios where Alice decides to unilaterally close the channel might
>>> look like:
>>>
>>> * if Alice/Bob can't communicate directly, but both are online:
>>>
>>> F -> UA.n -> CB.n -> money
>>>
>>> (balances and htlcs claimed, no delay)
>>>
>>> * if Bob has gone offline entirely:
>>>
>>> F -> UA.n -> (to_self_delay) -> SA.n -> money
>>>
>>> * Alice cheats, Bob punishes:
>>>
>>> F -> UA.k -> RB.n -> money[Alice pays Bob penalty]
>>>
>>> * Bob is offline, Alice cheats, but Bob has a watchtower:
>>>
>>> F -> UA.k -> WB.n -> (to_self_delay) -> SA.n -> money
>>>
>>> * Alice and Bob's watchtower collude, but Bob's not offline:
>>>
>>> F -> UA.k1 -> WB.k2 -> RB.n -> money[Alice pays Bob penalty]
>>>
>>> * Alice and Bob's watchtower collude, but Bob has many watchtowers:
>>>
>>> F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
>>>
>>> For Alice to successfully cheat, she needs Bob to be offline for at least
>>> to_self_delay, and for all Bob's watchtowers to either also be offline,
>>> or colluding.
>>>
>>> This can be simplified somewhat, if you don't care about all the
>>> features:
>>>
>>> * If you don't care about trustless watchtowers you can drop WA.n/WB.n
>>> (and simplify SA.n/SB.n to not require an APO signature)
>>>
>>> * If you don't care about penalties you can set penalty_msat to 0 and
>>> allow RA.n/RB.n to spend k<=n. In this case, you can either drop
>>> CA.n/CB.n entirely, or you can have CA.n/CB.n only be used for
>>> directly
>>> spending of UB.n/UA.n and thus not require APO signatures
>>>
>>> In order to allow fast-forwards, when Alice proposes a new state,
>>> she needs to send her partial signatures to allow Bob to unilaterally
>>> accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
>>> also needs to be able to claim the funds if Bob proposes the new state
>>> and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
>>> achieved with an adaptor signature approach (spelt out a bit more fully
>>> in the gist) or a CTV-like approach, provided that UB.n reveals the
>>> state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
>>>
>>> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
>>> ).
>>>
>>> Note that in this scenario Alice doesn't provide WB.n to Bob
>>> immediately. This is okay, as if Alice proposes UA.(n-1) (her most
>>> recent state), Bob can still immediately claim via CA.n. If Bob did have
>>> WB.n; then if Alice proposed UA.(n-1) Bob could wait for an initial
>>> to_self_delay period and broadcast WB.n, forcing Alice to wait for an
>>> additional to_self_delay before being able to claim her funds via SA.n.
>>>
>>> Note also that this is why RA.n/RB.n require "k < n - 1" -- otherwise
>>> Alice would only be able to broadcast UA.(n-1) and Bob would immediately
>>> be able to penalise by broadcasting RB.n.
>>>
>>> Note that if you're using a watchtower and wish to punish your
>>> counterparty if it attempts to cheat, you should only pass WA.(n-2)
>>> to your watchtowers, not WA.(n-1) or WA.n.
>>>
>>>
>>>
>>> This doesn't address any potential issues from:
>>>
>>> * how to add fees -- the U/W transactions are 1-in/1-out transactions
>>> that can't be trivially CPFPed by the proposer and need to have
>>> fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
>>> ephemeral output and package relay might be workable); the C/S/R
>>> transactions are 1-in/many-out transactions, but have balance outputs
>>> that can be immediately spent to pay for fees via CPFP if package
>>> relay is available.
>>>
>>> * how to pay watchtowers -- when a watchtower broadcasts a W
>>> transaction, it needs to add fees, and it's not clear (to me) how it
>>> could fairly and reliably ensure it's compensated for those costs,
>>> particularly if multiple W transactions are broadcast for a single
>>> unilateral close attempt, due to one or more watchtowers colluding
>>> with an attacker, or simply having out of date information.
>>>
>>> * lack of layered transactions -- while this prevents you having to
>>> wait longer than to_self_delay before you can claim channel funds,
>>> it still means that any htlc that is going to timeout sooner than that
>>> may not be claimable on-chain, meaning you need to set
>>> cltv_expiry_delta >= to_self_delay.
>>>
>>> * extending to multiparty channels -- penalising is hard if there's
>>> more than two parties, fast forwards are probably impossible since
>>> you need multiple round-trips to coordinate signatures anyway, and if
>>> you're doing channels-within-channels to reduce your n-party channel
>>> to an easier to update 2-party channel you're probably forced to have
>>> to_self_delay for each layer of channels. Also, just figuring out how
>>> to coordinate multiparty state updates and even keeping everyone in
>>> a multiparty channel online consistently to generate new signatures
>>> seems potentially hard?
>>>
>>> Cheers,
>>> aj
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221212/a2aadcd6/attachment-0001.html>;
📝 Original message:
Hi Greg,
> Feel free to assume that we've worked around mempool pinning for all of
> these discussions, otherwise we're pretty hosed regardless. I'm implicitly
> assuming V3+ephemeral anchors, which disallows batched bumps, for example.
> You'll need to give some room for "slippage", but I think
> shared_delay/2*shared_delay is going to end up dominating UX in any
> non-layered scheme.
I think I was making the same assumption of V3+ephemeral anchors, and
effectively disabling batching removes the known case of "commitment
cat-and-mouse" attack, where a counterparty goes to confirm the commitment
one by one to break the validity of the common CPFP. However, I wonder if
there is not another attack case, see my other "update overflow" mail, and
I don't think it qualifies as a pinning here!
> This architecture doesn't suffer from 2*self_delay, and each transition
> aside from Slow/Settle/SX.y has no relative timelock so that relative
> timelock is all that matters. It does introduce a watchtower cycle, so
it's
> not longer a one-shot architecture, or even k-shot exactly, it ends up
> looking like vanilla eltoo for that single path.
Here I think my understanding is aligned, the watchtower cycle ends up
looking more like the update phase of vanilla eltoo.
Antoine
Le jeu. 8 déc. 2022 à 15:28, Greg Sanders <gsanders87 at gmail.com> a écrit :
> Antoine,
>
> > While the 2*to_self_delay sounds the maximum time delay in the state
> publication scenario where the cheating counterparty publishes a old state
> then the honest counterparty publishes the latest one, there could be the
> case where the cheating counterparty broadcast chain of old states, up to
> mempool's `limitancestorcount`. However, this chain of eltoo transactions
> could be replaced by the honest party paying a higher-feerate (assuming
> something like nversion=3). I think there might still be an attack
> triggerable under certain economic conditions, where the attacker overbids
> with the higher-feerate transaction until the HTLC cltv expires. If this
> attack is plausible, it could be even opportun if you're batching against
> multiple channels, where the victims are not able to coordinate response.
>
> Feel free to assume that we've worked around mempool pinning for all of
> these discussions, otherwise we're pretty hosed regardless. I'm implicitly
> assuming V3+ephemeral anchors, which disallows batched bumps, for example.
> You'll need to give some room for "slippage", but I think
> shared_delay/2*shared_delay is going to end up dominating UX in any
> non-layered scheme.
>
> > I wonder if the introduction of watchtower specific transactions doesn't
> break the 2*to_self_delay assumption
>
> This architecture doesn't suffer from 2*self_delay, and each transition
> aside from Slow/Settle/SX.y has no relative timelock so that relative
> timelock is all that matters. It does introduce a watchtower cycle, so it's
> not longer a one-shot architecture, or even k-shot exactly, it ends up
> looking like vanilla eltoo for that single path.
>
> Cheers,
> Greg
>
> On Thu, Dec 8, 2022 at 2:14 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi AJ,
>>
>> The eltoo irc channel is ##eltoo on Libera chat.
>>
>> > - 2022-10-21, eltoo/chia:
>> https://twitter.com/bramcohen/status/1583122833932099585
>>
>> On the eltoo/chia variant, from my (quick) understanding, the main
>> innovation aimed for is the limitation of the publication of eltoo states
>> more than once by a counterparty, by introducing a cryptographic puzzle,
>> where the witness can be produced once and only once ? I would say you
>> might need the inheritance of the updated scriptpubkey across the chain of
>> eltoo states, with a TLUV-like mechanism.
>>
>> > The basic idea is "if it's a two party channel with just Alice and Bob,
>> > then if Alice starts a unilateral close, then she's already had her say,
>> > so it's only Bob's opinion that matters from now on, and he should be
>> > able to act immediately", and once it's only Bob's opinion that matters,
>> > you can simplify a bunch of things.
>>
>> From my understanding, assuming Eltoo paper terminology, Alice can
>> publish an update K transaction, and then after Bob can publish an update
>> transaction K<N or Alice can publish the settlement transaction N, or Bob
>> can publish an update transaction N. The main advantage of this
>> construction I can see is a strict bound on the shared_delay encumbered in
>> the on-chain publication of the channel ?
>>
>> > fast forwards: we might want to allow our channel partner
>> > to immediately rely on a new state we propose without needing a
>> > round-trip delay -- this potentially makes forwarding payments much
>> > faster (though with some risk of locking the funds up, if you do a
>> > fast forward to someone who's gone offline)
>>
>> IIRC, there has already been a "fast-forward" protocol upgrade proposal
>> based on update-turn in the LN-penalty paradigm [0]. I think reducing the
>> latency of HTLC propagation across payment paths would constitute a UX
>> improvement, especially a link-level update mechanism upgrade deployment
>> might be incentivized by routing algorithms starting to penalize routing
>> hops HTLC relay latency. What is unclear is the additional risk of locking
>> the funds up. If you don't receive acknowledgement the fast forward state
>> has been received, you should still be able to exit with the state N-1 ?
>> However, the fast-forward trade-off might sound acceptable, with time you
>> might expect reliable routing hops in the core of the graph, and flappy
>> spokes at the edge.
>>
>> > doubled delays: once we publish the latest state we can, we want to
>> > be able to claim the funds immediately after to_self_delay expires;
>> > however if our counterparty has signatures for a newer state than we
>> > do (which will happen if it was fast forwarded), they could post that
>> > state shortly before to_self_delay expires, potentially increasing
>> > the total delay to 2*to_self_delay.
>>
>> While the 2*to_self_delay sounds the maximum time delay in the state
>> publication scenario where the cheating counterparty publishes a old state
>> then the honest counterparty publishes the latest one, there could be the
>> case where the cheating counterparty broadcast chain of old states, up to
>> mempool's `limitancestorcount`. However, this chain of eltoo transactions
>> could be replaced by the honest party paying a higher-feerate (assuming
>> something like nversion=3). I think there might still be an attack
>> triggerable under certain economic conditions, where the attacker overbids
>> with the higher-feerate transaction until the HTLC cltv expires. If this
>> attack is plausible, it could be even opportun if you're batching against
>> multiple channels, where the victims are not able to coordinate response.
>>
>> > penalties: when you do a unilateral close, attempting to cheat comes
>> > with no cost to you and a possible benefit if you succeed, but
>> > potentially does cost your channel partner (either in forcing them
>> > to spend on-chain fees to update to the correct state, or in the risk
>> > of loss if their node malfunctions occassionally) -- a penalty could
>> > reduce this incentive to cheat
>>
>> I think there has been a proposal in the past to enable penalties on top
>> of symmetric states by leveraging asymmetric witnesses [1]. Further, I
>> wonder if there is a game-theory interest for penalty-on-top-eltoo, it
>> could be an incentive against laziness, where a dysfunctional trusted
>> watchtower broadcasts an old state. On the qualification of the game-theory
>> soundness, I think one would have to run the empirical case study: select
>> channel counterparties randomly (no out-of-band assumptions), one set with
>> eltoo+penalty and the other with vanilla eltoo, observe the broadcast of
>> revoked states over some period.
>>
>> > trustless watchtowers: we may want to consider the possibility of a
>> > watchtower holding onto obsolete states and colluding with an
>> > attacker to attempt to cheat us
>>
>> In terms of pinning and other mempool games, I think honest participant
>> own states leveraged by a colluding watchtower might increase the attack
>> surface, especially post-anchor with the SIGHASH_SINGLE malleability on
>> second-stage HTLC transactions.
>>
>> > (I think for initial eltoo experimentation it doesn't make sense to try
>> to
>> > deal with all (or perhaps any) of those constraints; simple and working
>> > is better than complex and theoretical. But having them written down so
>> > the ideas can be thought about and looked up later still seems useful)
>>
>> I share the belief -- "simple and working" enable shorter iteration
>> cycles and hopefully fasten the protocol design learning curve. Beyond, I
>> think it's also realistic in face of the state of the LN ecosystem,
>> especially on the watchtower issue. AFAICT, there is no even multi trusted
>> watchtower design covering the full execution of the protocol (i.e
>> including HTLC-preimage/ HTLC-timeout claim), and such implementation is
>> far from simple, as from now on you LN's chain backend might have
>> asynchronicity issue to solve between your on-chain monitoring state
>> machine (at least speaking in knowledge of the LDK-architecture).
>>
>> > * WA.n, WB.n : watchtower update to state n
>> > - this is for an untrusted watchtower to correct attempted cheating
>> > by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
>> > (or UA.k/WB.k) respectively, provided k < n.
>>
>> I wonder if the introduction of watchtower specific transactions doesn't
>> break the 2*to_self_delay assumption (iiuc it's a design goal of current
>> protocol) and what is the design rationale. Beyond that, there is a concern
>> with watchtower-specific transactions, it might leak your towers topology
>> (i.e the number of them and the distribution in the p2p network) to an
>> adversary.
>>
>> > * SA.n, SB.n : slowly claim funds according to state n
>> > - this is for Alice to claim her funds if Bob is completely offline
>> > (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
>> > timelock of to_self_delay.
>>
>> If I'm following correctly the description, this is logically equivalent
>> to the sweep of a `to_local`/`to_remote` output on a commitment transaction
>> though instead the waiting delay is eltoo shared_delay. There is no
>> to_self_delay, at the punishment seems only to happen on the update-level,
>> or maybe one should be also able to punish slow fund exit, and another
>> relative locktime should exist on the S* transactions.
>>
>> > * Alice and Bob's watchtower collude, but Bob has many watchtowers:
>> >
>> > F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
>>
>> Could the punishment transactions R* be also delegated to watchtowers,
>> assuming they have been pre-signed to lockdown the exit scriptpubkeys ?
>>
>> > In order to allow fast-forwards, when Alice proposes a new state,
>> > she needs to send her partial signatures to allow Bob to unilaterally
>> > accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
>> > also needs to be able to claim the funds if Bob proposes the new state
>> > and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
>> > achieved with an adaptor signature approach (spelt out a bit more fully
>> > in the gist) or a CTV-like approach, provided that UB.n reveals the
>> > state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
>> >
>> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
>> ).
>>
>> If you would like to have fast forward of chain of transactions, I wonder
>> if there could be also the "sig-in-the-script" trick, where UB.n
>> scriptpubkey (or one of its tapscripts) contains the signature for CB.n,
>> SB.n, RB.n. Though you might have an issue of re-generating the
>> witnessscript in case of state loss.
>>
>> > * how to add fees -- the U/W transactions are 1-in/1-out transactions
>> > that can't be trivially CPFPed by the proposer and need to have
>> > fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
>> > ephemeral output and package relay might be workable); the C/S/R
>> > transactions are 1-in/many-out transactions, but have balance outputs
>> > that can be immediately spent to pay for fees via CPFP if package
>> > relay is available.
>>
>> Assuming something like nversion=3, the SINGLE/ANYONCANPAY could be a
>> viable fee-bumping mechanism, as ancestor-based pinning should be less of a
>> concern. Ephemeral anchor output could be a more efficient direction, if
>> the output value can be cooperatively inflated from the channel value,
>> rather than relying on external fee-bumping reserves. I think even more
>> efficient fee-bumping primitives can be introduced later.
>>
>> > * how to pay watchtowers -- when a watchtower broadcasts a W
>> > transaction, it needs to add fees, and it's not clear (to me) how it
>> > could fairly and reliably ensure it's compensated for those costs,
>> > particularly if multiple W transactions are broadcast for a single
>> > unilateral close attempt, due to one or more watchtowers colluding
>> > with an attacker, or simply having out of date information.
>>
>> I wonder if paying a watchtower, or getting paid as a watchtower isn't a
>> "counterparty risk" similar to what is happening with jamming due to
>> non-covered HTLC forward risk. The watchtower has the risk of not being
>> paid a posteriori and the user has the risk of the tower not acting. There
>> is even a trade-off between tower costs and safety, as the more towers you
>> have, more robust if your Lightning channel (in theory, as you also have a
>> duplication of the key material).
>>
>> > * lack of layered transactions -- while this prevents you having to
>> > wait longer than to_self_delay before you can claim channel funds,
>> > it still means that any htlc that is going to timeout sooner than that
>> > may not be claimable on-chain, meaning you need to set
>> > cltv_expiry_delta >= to_self_delay.
>>
>> From a security perspective, offsetting the cltv_expiry_delta to a value
>> superior to to_self_delay can be considered as an improvement, especially
>> if it gradually does it network-wide. On the other hand, if routing
>> algorithms start to penalize long-cltv-delta payment paths as the timevalue
>> of liquidity is priced in routing fees, this design rationale might not be
>> aligned with long-term LN network incentives (as of today even more
>> loosely-defined than miner incentives).
>>
>> > * extending to multiparty channels -- penalising is hard if there's
>> > more than two parties, fast forwards are probably impossible since
>> > you need multiple round-trips to coordinate signatures anyway, and if
>> > you're doing channels-within-channels to reduce your n-party channel
>> > to an easier to update 2-party channel you're probably forced to have
>> > to_self_delay for each layer of channels. Also, just figuring out how
>> > to coordinate multiparty state updates and even keeping everyone in
>> > a multiparty channel online consistently to generate new signatures
>> > seems potentially hard?
>>
>> I don't know if penalising has been a solved issue for mulit-party, at
>> least in a trustless fashion in the same way we have with 2-party
>> LN-penalty (you could devise weird scheme based on timelock, taproot tree
>> and threshold signatures incentivizing towards the convergence of a
>> "consensus" punishment, still...) Figuring out coordinating multi-party
>> states updates sounds workable with modern consensus algorithms (e.g Raft),
>> though still conserving the fast forward effect is a high bar, it might be
>> better deferred to an uplifted layer of 2-of-2 LN channels. The only reason
>> you might have payments at the multi-party level (with the signature of the
>> N-of-N participants requested) only for privacy or liquidity allocation
>> reason. Though effectively, it sounds like your multiparty
>> channel coordination mechanism should encompass party eviction or
>> partitioning the offline parties. One or two orders of magnitude of
>> complexity beyond the 2-party eltoo channel case, I think.
>>
>> Antoine
>>
>> [0] https://github.com/lightning/bolts/pull/867
>> [1] https://github.com/LLFourn/witness-asymmetric-channel
>>
>> Le mer. 7 déc. 2022 à 00:36, Anthony Towns <aj at erisian.com.au> a écrit :
>>
>>> Hi all,
>>>
>>> On the eltoo irc channel we discussed optimising eltoo for the 2-party
>>> scenario; figured it was probably worth repeating that here.
>>>
>>> This is similar to:
>>>
>>> - 2018-07-18, simplified eltoo:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001363.html
>>> - 2021-09-17, IID 2Stage,
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019470.html
>>> - 2022-09-29, Daric: https://eprint.iacr.org/2022/1295
>>> - 2022-10-21, eltoo/chia:
>>> https://twitter.com/bramcohen/status/1583122833932099585
>>>
>>> The basic idea is "if it's a two party channel with just Alice and Bob,
>>> then if Alice starts a unilateral close, then she's already had her say,
>>> so it's only Bob's opinion that matters from now on, and he should be
>>> able to act immediately", and once it's only Bob's opinion that matters,
>>> you can simplify a bunch of things.
>>>
>>> A "gist" for this idea is
>>> https://gist.github.com/ajtowns/53e0f735f4d5c06a681429d937200aa5 (it
>>> goes into a little more detail in places, though doesn't cover trustless
>>> watchtowers at all).
>>>
>>>
>>>
>>> In particular, there are a few practical constraints that we might like
>>> to consider for 2-party channels with eltoo:
>>>
>>> - fast forwards: we might want to allow our channel partner
>>> to immediately rely on a new state we propose without needing a
>>> round-trip delay -- this potentially makes forwarding payments much
>>> faster (though with some risk of locking the funds up, if you do a
>>> fast forward to someone who's gone offline)
>>>
>>> - doubled delays: once we publish the latest state we can, we want to
>>> be able to claim the funds immediately after to_self_delay expires;
>>> however if our counterparty has signatures for a newer state than we
>>> do (which will happen if it was fast forwarded), they could post that
>>> state shortly before to_self_delay expires, potentially increasing
>>> the total delay to 2*to_self_delay.
>>>
>>> - penalties: when you do a unilateral close, attempting to cheat comes
>>> with no cost to you and a possible benefit if you succeed, but
>>> potentially does cost your channel partner (either in forcing them
>>> to spend on-chain fees to update to the correct state, or in the risk
>>> of loss if their node malfunctions occassionally) -- a penalty could
>>> reduce this incentive to cheat
>>>
>>> - trustless watchtowers: we may want to consider the possibility of a
>>> watchtower holding onto obsolete states and colluding with an
>>> attacker to attempt to cheat us
>>>
>>> What follows is a rough approach for dealing with all those issues for
>>> two-party channels. It's spelled out in a little more detail in the gist.
>>>
>>> (I think for initial eltoo experimentation it doesn't make sense to try
>>> to
>>> deal with all (or perhaps any) of those constraints; simple and working
>>> is better than complex and theoretical. But having them written down so
>>> the ideas can be thought about and looked up later still seems useful)
>>>
>>> In more detail: unilateral closes are handled by each channel participant
>>> maintaining five transactions, which we'll call:
>>>
>>> * UA.n, UB.n : unilaterally propose closing at state n
>>> - this is for Alice or Bob to spend the funding tx for a unilater
>>> close to state n. Spends the funding transaction.
>>>
>>> * WA.n, WB.n : watchtower update to state n
>>> - this is for an untrusted watchtower to correct attempted cheating
>>> by Bob on behalf of Alice (or vice-versa). Spends UB.k or WA.k
>>> (or UA.k/WB.k) respectively, provided k < n.
>>>
>>> * CA.n, CB.n : cooperatively claim funds according to state n
>>> - this is for Alice to confirm Bob's unilateral close (or vice-versa).
>>> Spends UB.k, WA.k (or UA.k/WB.k respectively), provided k <= n
>>>
>>> * SA.n, SB.n : slowly claim funds according to state n
>>> - this is for Alice to claim her funds if Bob is completely offline
>>> (or vice-versa). Spends UA.n, UB.n, WA.n or WB.n with relative
>>> timelock of to_self_delay.
>>>
>>> * RA.n, RB.n : claim funds with penalty after unilateral close to
>>> revoked state
>>> - this is for Alice to update the state if Bob attempted to cheat
>>> (or vice-versa). Spends UB.k or WA.k (or UA.k/WB.k respectively)
>>> conditional on k < n - 1; outputs are adjusted to transfer a fixed
>>> penalty of penalty_msat from Bob's balance to Alice's (or
>>> vice-versa)
>>>
>>> Each of these "transactions" requires a pre-signed signature; however
>>> the actual transaction/txid will vary in cases where a transaction has
>>> the possibility of spending different inputs (eg "Spends UB.k or WA.k").
>>> In particular UA.n/UB.n can be constructed with known txids and non-APO
>>> signatures but WA.n/WB.n/CA.n/CB.n/SA.n/SB.n/RA.n/RB.n all require
>>> APO signatures.
>>>
>>> They're named such that Alice can immediately broadcast all the *A.n
>>> transactions (provided a tx that it can spend has been broadcast) and
>>> Bob can likewise immediately broadcast all the *B.n transactions.
>>>
>>> Scenarios where Alice decides to unilaterally close the channel might
>>> look like:
>>>
>>> * if Alice/Bob can't communicate directly, but both are online:
>>>
>>> F -> UA.n -> CB.n -> money
>>>
>>> (balances and htlcs claimed, no delay)
>>>
>>> * if Bob has gone offline entirely:
>>>
>>> F -> UA.n -> (to_self_delay) -> SA.n -> money
>>>
>>> * Alice cheats, Bob punishes:
>>>
>>> F -> UA.k -> RB.n -> money[Alice pays Bob penalty]
>>>
>>> * Bob is offline, Alice cheats, but Bob has a watchtower:
>>>
>>> F -> UA.k -> WB.n -> (to_self_delay) -> SA.n -> money
>>>
>>> * Alice and Bob's watchtower collude, but Bob's not offline:
>>>
>>> F -> UA.k1 -> WB.k2 -> RB.n -> money[Alice pays Bob penalty]
>>>
>>> * Alice and Bob's watchtower collude, but Bob has many watchtowers:
>>>
>>> F -> UA.k1 -> WB.k2 -> WB.n -> (to_self_delay) -> SA.n -> money
>>>
>>> For Alice to successfully cheat, she needs Bob to be offline for at least
>>> to_self_delay, and for all Bob's watchtowers to either also be offline,
>>> or colluding.
>>>
>>> This can be simplified somewhat, if you don't care about all the
>>> features:
>>>
>>> * If you don't care about trustless watchtowers you can drop WA.n/WB.n
>>> (and simplify SA.n/SB.n to not require an APO signature)
>>>
>>> * If you don't care about penalties you can set penalty_msat to 0 and
>>> allow RA.n/RB.n to spend k<=n. In this case, you can either drop
>>> CA.n/CB.n entirely, or you can have CA.n/CB.n only be used for
>>> directly
>>> spending of UB.n/UA.n and thus not require APO signatures
>>>
>>> In order to allow fast-forwards, when Alice proposes a new state,
>>> she needs to send her partial signatures to allow Bob to unilaterally
>>> accept the new state, ie sigs for: UB.n, CB.n, SB.n, RB.n. But she
>>> also needs to be able to claim the funds if Bob proposes the new state
>>> and broadcasts UB.n, she needs to be able broadcast CA.n. This can be
>>> achieved with an adaptor signature approach (spelt out a bit more fully
>>> in the gist) or a CTV-like approach, provided that UB.n reveals the
>>> state needed to calculate the the CTV commitment (see "EXPR_SETTLE" in
>>>
>>> https://github.com/instagibbs/bolts/blob/29fe6d36cbad4101d5ec76c2b19c83c1494ac2fc/XX-eltoo-transactions.md
>>> ).
>>>
>>> Note that in this scenario Alice doesn't provide WB.n to Bob
>>> immediately. This is okay, as if Alice proposes UA.(n-1) (her most
>>> recent state), Bob can still immediately claim via CA.n. If Bob did have
>>> WB.n; then if Alice proposed UA.(n-1) Bob could wait for an initial
>>> to_self_delay period and broadcast WB.n, forcing Alice to wait for an
>>> additional to_self_delay before being able to claim her funds via SA.n.
>>>
>>> Note also that this is why RA.n/RB.n require "k < n - 1" -- otherwise
>>> Alice would only be able to broadcast UA.(n-1) and Bob would immediately
>>> be able to penalise by broadcasting RB.n.
>>>
>>> Note that if you're using a watchtower and wish to punish your
>>> counterparty if it attempts to cheat, you should only pass WA.(n-2)
>>> to your watchtowers, not WA.(n-1) or WA.n.
>>>
>>>
>>>
>>> This doesn't address any potential issues from:
>>>
>>> * how to add fees -- the U/W transactions are 1-in/1-out transactions
>>> that can't be trivially CPFPed by the proposer and need to have
>>> fees added (either SINGLE/ANYONECANPAY signatures or having a 0-sat
>>> ephemeral output and package relay might be workable); the C/S/R
>>> transactions are 1-in/many-out transactions, but have balance outputs
>>> that can be immediately spent to pay for fees via CPFP if package
>>> relay is available.
>>>
>>> * how to pay watchtowers -- when a watchtower broadcasts a W
>>> transaction, it needs to add fees, and it's not clear (to me) how it
>>> could fairly and reliably ensure it's compensated for those costs,
>>> particularly if multiple W transactions are broadcast for a single
>>> unilateral close attempt, due to one or more watchtowers colluding
>>> with an attacker, or simply having out of date information.
>>>
>>> * lack of layered transactions -- while this prevents you having to
>>> wait longer than to_self_delay before you can claim channel funds,
>>> it still means that any htlc that is going to timeout sooner than that
>>> may not be claimable on-chain, meaning you need to set
>>> cltv_expiry_delta >= to_self_delay.
>>>
>>> * extending to multiparty channels -- penalising is hard if there's
>>> more than two parties, fast forwards are probably impossible since
>>> you need multiple round-trips to coordinate signatures anyway, and if
>>> you're doing channels-within-channels to reduce your n-party channel
>>> to an easier to update 2-party channel you're probably forced to have
>>> to_self_delay for each layer of channels. Also, just figuring out how
>>> to coordinate multiparty state updates and even keeping everyone in
>>> a multiparty channel online consistently to generate new signatures
>>> seems potentially hard?
>>>
>>> Cheers,
>>> aj
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221212/a2aadcd6/attachment-0001.html>;