Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jonasnick
Copy link
Collaborator

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
Copy link
Contributor

t-bast commented Dec 10, 2021

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

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

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
Copy link

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

@t-bast
Copy link
Contributor

t-bast commented Apr 19, 2022

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants