Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-09 📝 Original message: On Thu, Dec 08, 2022 at ...
📅 Original date posted:2022-12-09
📝 Original message:
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
📝 Original message:
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