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.ri...@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 <a...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
