Contract-level Relative Timelocks (or, let's talk about ancestry proofs and singletons)

[instagibbs]

@cguida

What is the precise vulnerability the CLRT is trying to mitigate?

CLRT is mitigating the amount of time liquidity is locked up in protocols.

@cguida

The only time I can see the delay taking longer than 2x the delay is if both parties publish a state they know is not the newest state, which would be kind of silly, wouldn’t it?

The 2 times shared_delay is when, f.e., ln-symmetry already has a shared_delay for the channel’s settlement transaction via nsequence. Alice adds an incoming HTLC to an otherwise quiet channel at channel update T-1. Alice sends a signature for the newest state T to Bob. Bob simply doesn’t respond with his signature. Alice needs to claim the incoming HTLC, so she goes to chain with her latest state, T-1. shared_delay-1 blocks pass, and Bob then gets T mined. Another shared_delay must pass.

Both of these shared_delays must be built into the HTLC expiry delta for safety.

CLRT output would drop this to a single shared_delay for ln-symmetry.

@moonsettler

CLRT does not really mitigate this afaik, in fact makes it more dangerous.

It means you have to pick your shared_delay as something you deem secure, as its a liveliness security parameter. With or without CLRT if an adversary outbids you shared_delay times, your funds can be at risk for HTLC theft.

Also, it does not preclude someone developing a modification to eltoo that bounds the number of updates. This is meant to be a modular piece usable in any context desired. It’s not practical yet anyways, but this is why I opened the thread!