<oembed><type>rich</type><version>1.0</version><title>ZmnSCPxj [ARCHIVE] wrote</title><author_name>ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)</author_name><author_url>https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2021-12-06&#xA;📝 Original message:&#xA;Good morning t-bast,&#xA;&#xA;Long ago: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002385.html&#xA;&#xA;And I quote:&#xA;&#xA;&gt;&gt; A potential issue with MuSig is the increased number of communication rounds needed to generate signatures.&#xA;&gt;&#xA;&gt;I think you can reduce this via an alternative script path. In&#xA;&gt;particular, if you want a script that the other guy can spend if they&#xA;&gt;reveal the discrete log of point X, with musig you do:&#xA;&gt;&#xA;&gt;   P = H(H(A,B),1)*A + H(H(A,B),2)*B&#xA;&gt;   [exchange H(RA),H(RB),RA,RB]&#xA;&gt;&#xA;&gt;   [send X]&#xA;&gt;&#xA;&gt;   sb = rb + H(RA+RB+X,P,m)*H(H(A,B),2)*b&#xA;&gt;&#xA;&gt;   [wait for sb]&#xA;&gt;&#xA;&gt;   sa = ra + H(RA+RB+X,P,m)*H(H(A,B),1)*a&#xA;&gt;&#xA;&gt;   [store RA+RB+X, sa+sb, supply sa, watch for sig]&#xA;&gt;&#xA;&gt;   sig = (RA+RB+X, sa+sb+x)&#xA;&gt;&#xA;&gt;So the 1.5 round trips are &#34;I want to do a PTLC for X&#34;, &#34;okay here&#39;s&#xA;&gt;sb&#34;, &#34;great, here&#39;s sa&#34;.&#xA;&gt;&#xA;&gt;But with taproot you can have a script path as well, so you could have a&#xA;&gt;script:&#xA;&gt;&#xA;&gt;   A CHECKSIGVERIFY B CHECKSIG&#xA;&gt;&#xA;&gt;and supply a partial signature:&#xA;&gt;&#xA;&gt;   R+X,s,X where s = r + H(R+X,A,m)*a&#xA;&gt;&#xA;&gt;to allow them to satisfy &#34;A CHECKSIGVERIFY&#34; if they know the discrete&#xA;&gt;log of X, and of course they can sign with B at any time. This is only&#xA;&gt;half a round trip, and can be done at the same time as sending the &#34;I&#xA;&gt;want to do a PTLC for X&#34; message to setup the (ultimately cheaper) MuSig&#xA;&gt;spend. It&#39;s an extra signature on the sender&#39;s side and an extra verification&#xA;&gt;on the receiver&#39;s side, but I think it works out fine.&#xA;&#xA;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?&#xA;&#xA;Basically, if my memory and understanding are accurate, in the above, it is the *PTLC-offerrer* which provides an adaptor signature.&#xA;That adaptor signature would be included in the `update_add_ptlc` message.&#xA;&#xA;Does it become more workable that way?&#xA;&#xA;Regards,&#xA;ZmnSCPxj</html></oembed>