Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-05 🗒️ Summary of this message: The article ...
📅 Original date posted:2023-01-05
🗒️ Summary of this message: The article discusses the use of Chia's scripting capabilities in multi-party setups and breaking symmetry to prevent cheating in unilateral channel closures.
📝 Original message:
Hi AJ,
> 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.
In the multi-party setup, encoding more of the unrolling logic directly as
script could be a witness space gain, I guess. To express a channel
factory/payment pool withdrawal, at the minimum I think you need an
amount/exit scriptPubKey committed by the signature. Or maybe the output
value could be a spent input amount distribution among a set of signers, if
you would like some non-interactive pre-funded scheme.
> 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.
Yes, IIUC the proposed flow is UA.n -> CB.n -> money, and in this
optimistic case, there is only one CLTV delay to respect the spend of the
UA. In terms of timevalue cost to redeem all the funds, I think this is
making the cost equivalent for all the parties. With today's LN-penalty,
the broadcaster balance is encumbered by the CSV delay, not the
counterparty one.
(Note on the gist, the UA state description includes a Pa or tapscript "IF
CODESEP n OP_CLTV DROP ENDIF 1 CHECKSIG" as spendable paths and the CA.n
state description nSequence = 0, so I'm not sure how the update/justice
delay is enforced)
> 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...
I think here the issue can be corrected by selecting conservatively your
implementation channel breakout timers, you should go to chain with the
state N-1 with X buffer of block and ensure your CLTV delta are always
bigger than X, where X=delay * 2. That way even if your counterparty is
broadcasting state N at X-1, your htlc-timeout should be safe, I guess.
> 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.
So I think there still is the case of Bob broadcasting a very old state and
Alice's watchtowers colluding to prevent Alice's honest funds access,
potentially preventing the HTLC-timeout, IIUC. I don't know if we're not
introducing some changes in the trust assumptions towards watchtowers where
with vanilla eltoo a single compromised watchtower can be corrected by the
honest channel holder or another watchtower, iirc.
> 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.
So the penalty transactions should not be delegated to untrusted
watchtowers. In case of RB.n signing key compromise, the whole channel
funds might be lost.
> 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)
So you could have a channel balance between the watchtower and yourself,
where the tower balance is the payment for the WA.n broadcast, and there is
an assumption the balance is cooperatively updated to adjust for on-chain
fees. For sure, I'm not sure either how it would generalize to an untrusted
watchtower, where interactions might be even bounded to avoid leak of the
client identity.
Still, I think eltoo channels would simplify the implementation of
distributed towers by Lightning implementation, notably handling concurrent
broadcast w.r.t chain asynchronicity issues, and hopefully removing the
concern of commitment transaction key duplication by tower [0].
Best,
Antoine
[0] https://github.com/lightningdevkit/rust-lightning/pull/679
Le ven. 9 déc. 2022 à 01:55, Anthony Towns <aj at erisian.com.au> a écrit :
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230105/a6627adb/attachment-0001.html>;
🗒️ Summary of this message: The article discusses the use of Chia's scripting capabilities in multi-party setups and breaking symmetry to prevent cheating in unilateral channel closures.
📝 Original message:
Hi AJ,
> 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.
In the multi-party setup, encoding more of the unrolling logic directly as
script could be a witness space gain, I guess. To express a channel
factory/payment pool withdrawal, at the minimum I think you need an
amount/exit scriptPubKey committed by the signature. Or maybe the output
value could be a spent input amount distribution among a set of signers, if
you would like some non-interactive pre-funded scheme.
> 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.
Yes, IIUC the proposed flow is UA.n -> CB.n -> money, and in this
optimistic case, there is only one CLTV delay to respect the spend of the
UA. In terms of timevalue cost to redeem all the funds, I think this is
making the cost equivalent for all the parties. With today's LN-penalty,
the broadcaster balance is encumbered by the CSV delay, not the
counterparty one.
(Note on the gist, the UA state description includes a Pa or tapscript "IF
CODESEP n OP_CLTV DROP ENDIF 1 CHECKSIG" as spendable paths and the CA.n
state description nSequence = 0, so I'm not sure how the update/justice
delay is enforced)
> 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...
I think here the issue can be corrected by selecting conservatively your
implementation channel breakout timers, you should go to chain with the
state N-1 with X buffer of block and ensure your CLTV delta are always
bigger than X, where X=delay * 2. That way even if your counterparty is
broadcasting state N at X-1, your htlc-timeout should be safe, I guess.
> 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.
So I think there still is the case of Bob broadcasting a very old state and
Alice's watchtowers colluding to prevent Alice's honest funds access,
potentially preventing the HTLC-timeout, IIUC. I don't know if we're not
introducing some changes in the trust assumptions towards watchtowers where
with vanilla eltoo a single compromised watchtower can be corrected by the
honest channel holder or another watchtower, iirc.
> 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.
So the penalty transactions should not be delegated to untrusted
watchtowers. In case of RB.n signing key compromise, the whole channel
funds might be lost.
> 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)
So you could have a channel balance between the watchtower and yourself,
where the tower balance is the payment for the WA.n broadcast, and there is
an assumption the balance is cooperatively updated to adjust for on-chain
fees. For sure, I'm not sure either how it would generalize to an untrusted
watchtower, where interactions might be even bounded to avoid leak of the
client identity.
Still, I think eltoo channels would simplify the implementation of
distributed towers by Lightning implementation, notably handling concurrent
broadcast w.r.t chain asynchronicity issues, and hopefully removing the
concern of commitment transaction key duplication by tower [0].
Best,
Antoine
[0] https://github.com/lightningdevkit/rust-lightning/pull/679
Le ven. 9 déc. 2022 à 01:55, Anthony Towns <aj at erisian.com.au> a écrit :
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230105/a6627adb/attachment-0001.html>;