Contract-level Relative Timelock (CLRT) UTXO for Eltoo

clrt.md

Contract-level Relative Timelock (CLRT) UTXO for Eltoo

Eltoo constructs such as ln-symmetry suffer from an issue where every time an update transaction is confirmed on the blockchain, the relative timelock is reset. This causes further funds lockup, and further extends HTLC expiry in the LN use-case, potentially reducing network utility.

How can we have a "contract" level relative timelock? By dedicating a specific utxo that doesn't move until the the challenge period is over.

ln-symmetry has:

funding->update->settle

For this extension we change it to include a slightly different update transaction we will call "kickoff":

funding->kickoff->update->settle

Kickoff transactions have an additional CLRT output that commits to a relative delay for the eltoo challenge period before the settlement transaction can be confirmed.

The output is dust-level, and commits to being spent concurrently with an eltoo state output. To do this, you need a recursive proof that links back to an update transcation's state output. In other words, the recursive proof needs to demonstrate that another input has an ancestry that includes the kickoff transaction itself.

Update transactions pre-commit to both the state output(s) and the CLRT output to enforce that if the state output is spent, so is the CLRT output.

This makes mutual spending of a state output and CLRT a requirement for settlement.

How could the CLRT ancestry proof work?

1. Introspect "current" input's prevout, this must be matched in ancestry proof
2. Proof contains first update transaction with matching kickoff prevout, computes txid, checks that second update transaction in proof spends that utxo, etc, until proof connects with the settlement transaction

Problems:

1. Kickoff transaction and additional utxo costs extra vbytes, complexity
2. Proofs are vbytes-expensive and allow counterparty to penalize honest partner by doing additional updates. ZK magic constant size proof fixes this?
3. Even more worryingly, counter-party can make it consensus-invalid to actually spend the CLRT by inflating the proof beyond consensus limits. Either need a mechanism for fixed number of updates and constant sized updates, or ZK magic to compress the proof to constant size?

Make the problem simpler?

If we accept the case where we are just doing "onchain" eltoo with normal SIGHASH_DEFAULT, this becomes a lot simpler due to txid stability of the eltoo chain. The CLRT output becomes a connector output that is "re-attached" via consensus signatures of channel participants, and a simple CSV of the "shared_delay". Essentially a connector output that enforces a relative locktime.

With Chia's coinid, I think this gets pretty simple, but is still linear in update history:

reminder that CoinID = SHA256(parent_coin_id || puzzle_hash || amount)

Assuming the signature being used is functionally equivalent to SIGHASH_ALL and there is some sort of simplistic P2A like output for fees, that means there will be two types of outputs in each update: a contract output, and a static P2A-like puzzle we can filter for.

For witness data you are given a series of 32WU puzzle_hashes, none of which can be the P2A-equivalent. You take CRLT's parent coin id, and repeatedly hash it with the static amount and series of puzzle hashes. At the end, the coinids should match expected.

At 32WU per update, a standard relayable transaction could include a proof up to 12,500 levels, minus overhead.