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

The discussion focuses on the potential for immediate settlement in an @ademan channel, specifically concerning the last allowed update. It is pointed out that the format for this final update currently aligns with those preceding it. However, there's a suggestion to integrate the settlement transaction directly into this last update for efficiency. This approach, especially noted for scenarios where N=2, bears a resemblance to Daric, suggesting that this similarity may not be coincidental. The strategy under consideration could optimize the process by reducing the delay to (N - 1) * shared_delay, acknowledging that each party must still have the opportunity to make an update in the worst-case scenario. This implies a significant improvement in the settlement times within the channel by streamlining the final steps of the transaction process.