On Thu, Dec 08, 2022 at 02:14:06PM -0500, Antoine Riard wrote: > > - 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
I'd say the main innovation aimed for is just doing something like lightning over the top of chia (rather than bitcoin, liquid, ethereum etc), and making it simple enough to be easily implemented. > 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. Chia uses different terminology to bitcoin; "puzzle" is just what we call "scriptPubKey" in bitcoin, more or less. Since its scripting capabilities are pretty powerful, you can rig up a TLUV/OP_EVICT like mechanism, but for a two-party setup, in practice I think that mostly just means you can encode the logic directly as script, and when updating the state you then only need to exchange CHECKSIGFROMSTACK-like signatures along the lines of "state N implies outputs of A,B,C,... -- Alice", rather than signing multiple transactions. > > 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 ? If you have fully symmetric transactions, then you could have the situation where Alice broadcasts update K, then attacks Bob and when he attempts to post update N, she instead does a pinning attack by broadcasting update K+1 (spending update K), which then forces Bob to generate a new version update N, which she then blocks with update K+2, etc. An attack like that is presumably pretty difficult to pull off in practice, but it makes it pretty hard to reason about many of the limits. A simple advantage to breaking the symmetry is that if A does a unilateral close, then B can immediately confirm that closure releasing all funds for both parties. Without breaking the symmetry, you can't distinguish that case from B attempting to confirm his own unilateral close, which would allow B to cheat. > > 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 ? Yes, you can unilaterally close the channel with state N-1; but even then they might respond by bumping to state N anyway. If that happens, then the funds can remain locked up until the timeout, as you can no longer time the htlc out off-chain. Still, if it's one hung per htlc for the channel's entire lifetime (because you close it "immediately" when it happens), that's probably not going to cause problems frequently... > > 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). With the asymmetric transactions proposed here, you'd need to have your watchtowers collude with the attacker for this to happen. I think you could prevent chains from building up in the mempool by requiring a relative timelock of perhaps 2 or 3 blocks for a WA.n/WB.n tx to be valid (giving you time to post RA.n/RB.n in the meantime). > > * 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 The to_self_delay applies to whoever initiated the unilateral close, and provided they actually posted the most recent state, no watchtower tx is a valid spend. ie, if Alice is honest and n is the latest state, then the only possible spends of UA.n are SA.n (after a delay) or CB.n, and as soon as either of those are on chain, she gets access to her funds. No version of WB.k or RB.k (or WA.k, CA.k, RA.k) are valid if k<=n and UA.n is confirmed. If Alice is dishonest, and posts a very old state (n-x), then Bob could post up to x watchtower txs (WB.(n-x+1) .. WB.n) causing Alice to be unable to access her funds for up to (x+1)*to_self_delay blocks. But that's just a reason for her to not be dishonest in the first place. > (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. If you have a watchtower and it takes action, I don't think you can expect to retain privacy over the fact that you have a watchtower, and how effective it is against an attacker with extensive monitoring of the p2p network... > > * 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. I'm just using "to_self_delay" as the X in "if you attempt to cheat, I'll definitely notice and take action within X blocks". If you post UA.n then post SA.n after X blocks (due to SA.n's relative time lock) then you've already proven you didn't cheat, because that was enough time for B to notice and take action. > > * 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 ? No -- the RB.n transactions immediately release A's funds after applying the penalty, so if the watchtower colludes with A and has an old RB.y transaction, Alice can steal funds by posting UA.x and RB.y, provided that her balance now is sufficiently less than her balance then (ie bal.n < bal.y - penalty). In this model, Bob shouldn't be signing RB.n or CB.n txs until Alice has already started a unilateral close and posted UA.n/UA.k. > > 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. Broadcasting UB.n will only reveal signatures by B; so that would only potentially help with CA.n or RA.n; and if UB.n is on-chain, then RA.n isn't valid (since it would require "n < n"). The EXPR_SETTLE stuff in the github link describes how to do the trick via a CTV-ish approach (including an APO signature in a tapscript in the scriptPubKey of UA.n here; and including data in the annex so that you can recalculate thinks if an old UA.n is broadcast after you've forgotten n's state details). > > * 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. Actually, perhaps you could "yo dawg" it: if you give the watchtower a pre-signed transaction WA.n: input 1: UA.k/WA.k (ANYPREVOUTANYSCRIPT, SINGLE) input 2: my funds (SINGLE, ALL) output 1: WA.n output 2: new lightning channel between me and watchtower output 3: ephemeral OP_TRUE output then you could have the "new lightning channel" be setup with an initial capacity of "my funds", and off-chain update the state of that channel so that the watchtower's balance is how much you're willing to contribute in fees if the watchtower does its job. If you set things up so that you're always able to claim a penalty via WA.n->RA.n if the watchtower acts, then you can give up to that penalty to the watchtower and still end up making a profit. Doesn't generalise to redundant untrusted watchtowers though, but presumably nothing does. (You could use the same utxo across multiple watchtowers, but a rogue watchtower could just post an old WA.k tx and claim your funds, preventing some honest watchtower from helping) (Yo dawg, I heard you liked closing lightning channels, so we put a lightning channel in your watchtower, so you can close a channel while you're closing a channel. Alternatively: "when god closes one channel, he opens another") Cheers, aj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
