@jonasnick told me to post this for visibility. Invented originally by @ajtowns because he was chagrined by my current solution to the problem at hand.

First, a bit of motivation.

In ln-symmetry(eltoo) channels I have sketched out and implemented as well as other channel constructions, there is a desire to keep channel updates at least in the two party case to half a round trip. Alice sends an update with a signature, and Bob can immediately forward any HTLCs required without delay. This improves latency, and simplifies the channel state machine.

These types of channels have two stages of presigned transactions, in the ln-symmetry case, we have two symmetric transactions per channel update:

1. update transaction, which are posted during the contention period
2. settlement transaction, which is posted after a relative timeout when update transactions cease to be posted

If Alice wants to send an update to Bob, she cannot send both a signature for the update and settlement transactions, since Bob could take the update transaction to chain, and withhold a signature for the follow-up settlement transaction. The safe course is to send the settlement signature first, wait for Bob to hand his update signature, then respond with her update signature, increasing the RTT to 1.5 instead of 0.5 RTT.

Here's an alternative approach using adaptor signatures that I believe achieves the original goal:

1. Update transaction has a 2-of-2 OP_CSA script, one key for Alice, one for Bob
2. Settlement transaction has a 2-party MuSig key
3. Nonces are preshared always
4. Alice generates a channel state update, generating unsigned update and settlement transactions
5. Alice calls secp256k1_musig_partial_simulate on the settlement transaction, which allows Alice to "simulate" partial signing routine for any public key in the session, outputting s*G rather than s since that can be computed for any party.
6. Alice then uses s*G as the adaptor for her update transaction's signature (1-of-1 MuSig session?)
7. Alice sends channel update along with her partial sig and presignature to Bob
8. If Bob goes to chain with the update transaction, he leaks his s, allowing Alice to complete the settlement transaction.

TL;DR: the adapter signature is a fair exchange of Alice's update signature and Bob's settlement partial signature.