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

[instagibbs]

@salvatoshi

Once you remove the ‘token’ parts, I think the singleton is precisely what’s left - and indeed, constant-size proof of ancestry was the goal.

That’s interesting! To make sure I’m understanding correctly: We essentially want an NFT (singleton) for the “contract” identity, because that allows us to make the ancestry proof recursive bounded to one introspection step.

f.e. in ln-symmetry this would mean update transactions would the same require introspection logic, in addition to the settlement transaction. Each update knows about the kickoff txid and makes assertions on the update step. You’re adding additional overhead per submitted update, paid for by the submitter, rather than paid for by the honest participant at settlement time.

This seems to make it safe for relay/consensus as well, since you have a clear bound on the size of the witness-stripped update transactions.

Without a whole lot of thought that sounds right.

@ajtowns

Making the singleton be a 1-in/2-out tx where you use the first output holds the singleton, and the second output is a pay-to-anchor address whose spender can use the singleton might work though.

I think this is the most sensible construction yes.