3

In a mailing list post Z-man details a PTLC construction which he claims is "is almost entirely a MuSig ritual". My question is whether this MusigTweak is what is called the adaptor (last argument of secp256k1_musig_session_combine_nonces) in secp256k1-zkp? And has in fact been implemented?

How is MusigTweak computed? Is it the per-hop tweaked payment point, which means it will be the payment point for the hop connecting to the payer?

In a way, that wouldn't make sense since MusigTweak takes three arguments, and the payment point is the same for both channel partners. But on the other hand, maybe Z-man is describing how the tweaking works internally in libsecp256k1-zkp, and I can safely just use the tweaked payment point for both peers for the adaptor argument because the implementation will treat the adaptor differently depending in the index of the signer?

Murch
  • 71,155
  • 33
  • 180
  • 600
Janus Troelsen
  • 899
  • 8
  • 26

1 Answers1

2

My question is whether this MusigTweak is what is called the adaptor (last argument of secp256k1_musig_session_combine_nonces) in secp256k1-zkp?

No, what "Z-man" refers to as MusigTweak is not called the adaptor in secp256k1-zkp. The difference between the normal MuSig ritual and the "almost entirely MuSig" ritual is not the MuSigTweak. The MuSigTweak just determines how keys are aggregated and is called secp256k1_musig_coefficient in the secp256k1-zkp implementation as of commit cad7cc8f34d17166da2dabae20188ea6e747ac69. In the MuSig paper the MuSigTweak is called a_i. The adaptor argument of secp256k1_musig_session_combine_nonces refers to t*G (where G is the base point) in Z-man's description.

And has in fact been implemented?

Yes, almost. What Z-man is describing here is the original adaptor signature scheme. It's not well suited for multi-hop locks (aka Lightning with payment points), because the creating party must know the t when creating an adaptor signature. Therefore, the implementation in libsecp256k1-zkp uses the adaptor signature variant that was introduced in the original Lightning in Scritpless Script mailing list post and in the Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability paper. If you want to know more about the multi-hop lock protocol, I suggest to have a look at the diagram in the scriptless script repo.

libsecp256k1-zkp has a unit test for a scriptless script atomic swap using that technique.

How is MusigTweak computed? Is it the per-hop tweaked payment point, which means it will be the payment point for the hop connecting to the payer?

The adaptor point t*G is the per-hop tweaked payment point, not the MuSigTweak.

nickler
  • 776
  • 6
  • 11