ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-06 📝 Original message: Good morning t-bast, Long ...

📅 Original date posted:2021-12-06
📝 Original message:
Good morning t-bast,

Long ago: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002385.html

And I quote:

>> A potential issue with MuSig is the increased number of communication rounds needed to generate signatures.
>
>I think you can reduce this via an alternative script path. In
>particular, if you want a script that the other guy can spend if they
>reveal the discrete log of point X, with musig you do:
>
> P = H(H(A,B),1)*A + H(H(A,B),2)*B
> [exchange H(RA),H(RB),RA,RB]
>
> [send X]
>
> sb = rb + H(RA+RB+X,P,m)*H(H(A,B),2)*b
>
> [wait for sb]
>
> sa = ra + H(RA+RB+X,P,m)*H(H(A,B),1)*a
>
> [store RA+RB+X, sa+sb, supply sa, watch for sig]
>
> sig = (RA+RB+X, sa+sb+x)
>
>So the 1.5 round trips are "I want to do a PTLC for X", "okay here's
>sb", "great, here's sa".
>
>But with taproot you can have a script path as well, so you could have a
>script:
>
> A CHECKSIGVERIFY B CHECKSIG
>
>and supply a partial signature:
>
> R+X,s,X where s = r + H(R+X,A,m)*a
>
>to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete
>log of X, and of course they can sign with B at any time. This is only
>half a round trip, and can be done at the same time as sending the "I
>want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig
>spend. It's an extra signature on the sender's side and an extra verification
>on the receiver's side, but I think it works out fine.

It has been a while since I read that post, so my details may be fuzzy, but it looks possible as a way to reduce roundtrips, maybe?

Basically, if my memory and understanding are accurate, in the above, it is the *PTLC-offerrer* which provides an adaptor signature.
That adaptor signature would be included in the `update_add_ptlc` message.

Does it become more workable that way?

Regards,
ZmnSCPxj