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