multi-hop-locks: switch to single signer adaptors to save 0.5 RT

[jonasnick]

Need to update rest of the multi-hop-locks text before undrafting this and also mention how taproot plays into this.

I wonder if there are situations where you'd really prefer 2-of-2 adaptors over single signer adaptors in multi-hop locks.

CC @t-bast

[t-bast]

Here are the advantages and drawbacks I see for each solution:

• Using a musig2 output:
  • Less costly to spend (keypath) :+1:
  • Hides the fact that there are multiple participants and their individual public keys :+1:
  • But requires receiving a signature from the remote peer before sending our own :-1:
• Using a <A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG output:
  • Saves half a round-trip :+1:
  • More costly to spend (script path) :-1:
  • Reveals participants :-1:

I guess it depends on the rest of the protocol using it. If the upper layer protocol requires a message from right to left anyway, the musig2 output doesn't add any latency, so it should be preferred. With the current lightning protocol, it would add 0.5 RTT, but who knows what the next lightning protocol update will do?

My preferred general-purpose solution is probably to add both outputs, and share the musig2 partial signatures later in the protocol. That way participants can forward the PTLCs very quickly (they don't need to wait for the musig2 output to be spendable), and later they can also forget about the script path once they have signatures for the key path. The drawback is that this uses more bandwidth, but if it saves on on-chain fees and helps privacy, I'd say it can be worth it?

[instagibbs]

@t-bast can you recall where you got 0.5 RTT from? Eyeballing the chart it looks like 1 RTT to me

[t-bast]

@instagibbs IIRC the way I envisioned this was that update_add_htlc would contain the sender's musig2 nonce, so we're only missing one message from the receiver to the sender before the sender can send commitment_signed. That's why I claimed it would only add 0.5 RTT.

I've gone further though, and slightly re-worked the channel messages to better accommodate taproot, you can see the latest results here: https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md

It's really not in spec format yet, but it does contain enough details to make sure that it should work and be easy to specify (hopefully).