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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
