Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-06 🗒️ Summary of this message: The proposed ...

📅 Original date posted:2023-01-06
🗒️ Summary of this message: The proposed lightning network update breaks symmetry to prevent cheating and allow for immediate confirmation of closure, but there are still potential vulnerabilities.
📝 Original message:
On Thu, Jan 05, 2023 at 06:59:42PM -0500, Antoine Riard wrote:
> > 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.

The only delay in the UA.n/CB.n case is if someone's trying to redeem
an HTLC that times out in the future, in which case you might have UA.n,
CB.n, (CB.n -> A's balance), (CB.n -> B's balance), (CB.n -> A claiming
HTLC x with preimage x') all in the same block, but (CB.n -> A claiming
HTLC y at timeout) happening 100 blocks later, when y times out.

> (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)

(Note that the CLTV here is just for eltoo state ratcheting, and is
always in the past so doesn't imply an actual delay)

CA.n is only able to spend UB.n, not UA.n. (Or it can spend WA.n, but
WA.n can only spend UB.k or prior WA.k, so it means much the same
thing).

That's achievable by having the CA.n signature use ANYPREVOUT rather than
ANYPREVOUTANYSCRIPT (thus committing to UB.n/WA.n's shared scriptPubKey)
and having different scriptPubKey's between UA.n and UB.n (which breaks
the symmetry).

SA.n spends UA.n or WB.n in the same way, except also sets nSequence to
force a relative timelock.

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

Alice was the dishonest one here, so it'd be Alice broadcasting an old
state, preventing Bob from accessing funds.

If you're not online and have no honest watchtowers, then Alice can just
broadcast an old state, wait for the delay, and confirm the old state
(UA.k -> SA.k), and steal as much as she wants.

If you are online, or have honest watchtowers, then your honest CB.n
or WB.n can be confirmed in the same block as 2000 dishonest WB.(k+1),
WA.(k+2) txs. The point of having a watchtower helping you out is that the
watchtower can do fancier things than your lightning node on your phone,
like observe the mempool and potentially have direct relationships with
mining pools to overcome things like the 25 tx ancestor/descendant limit.

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

The same scenario applies in traditional eltoo, except in that case
Alice doesn't need to compromise any of Bob's watchtowers, she can
just broadcast multiple states herself -- since the txs are symmetric,
there's no difference between Alice.1 -> Alice.2 and Alice.1 -> Bob.2;
so you can't allow the latter while preventing the former (and there's
likewise no difference between those and Alice.1 -> Watchtower.2).

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

Yes.

> In case of RB.n signing key compromise, the whole channel
> funds might be lost.

Compromise of pretty much any of the signing keys allows all the channel
funds to be lost; this is always true of the key used for signing
cooperative closes, for instance.

If you do want to delegate punishment, you could probably have an
alternative setup where every watchtower transaction implies punishment.

(I assume watchtower punishment needs to be all or nothing, otherwise a
compromised watchtower would just rbf any attempts to punish, switching
them over to non-punishment, which then encourages attackers to compromise
watchtowers (and prioritise attacking people who use their compromised
watchtowers), and you'd end up with "nothing" anyway...)

Something like:

no-punishment:
UA.n -> delay -> SA.n (keypath)
UA.k -> CB.n (k <= n)

punishment of Alice:
UA.k -> RB.n (k < n - X)
UA.k -> WB.n (k < n)
WB.k -> WB.n (k < n)
WB.k -> RB.n (k <= n)
WB.n -> delay -> TA.n

where A only signs WB.n when the state has already updated to n+X,
and TA.n/RB.n transfers the punishment amount from A's balance to B's
balance compared to SA.n/CB.n.

That introduces an extra signature per state for TA.n, and probably an
additional one given the different constraints for RB.n when spending
UA.k vs WB.k.

Cheers,
aj