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

<p>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 <code>secp256k1_musig_coefficient</code> in the secp256k1-zkp implementation as of commit <a href="https://github.com/ElementsProject/secp256k1-zkp/blob/cad7cc8f34d17166da2dabae20188ea6e747ac69/src/modules/musig/main_impl.h#L49" rel="nofollow noreferrer">cad7cc8f34d17166da2dabae20188ea6e747ac69</a>. In the MuSig paper the MuSigTweak is called <code>a_i</code>. The adaptor argument of secp256k1_musig_session_combine_nonces refers to <code>t*G</code> (where <code>G</code> is the base point) in Z-man's description.</p>

<blockquote>
  <p>And has in fact been implemented?</p>
</blockquote>

<p>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 <code>t</code> when creating an adaptor signature. Therefore, the implementation in libsecp256k1-zkp uses the adaptor signature variant that was introduced in the original <a href="https://lists.launchpad.net/mimblewimble/msg00086.html" rel="nofollow noreferrer">Lightning in Scritpless Script</a> mailing list post and in the <a href="https://eprint.iacr.org/2018/472" rel="nofollow noreferrer">Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability</a> paper. If you want to know more about the multi-hop lock protocol, I suggest to have a look at the diagram in the <a href="https://github.com/ElementsProject/scriptless-scripts/blob/master/md/multi-hop-locks.md" rel="nofollow noreferrer">scriptless script repo</a>.</p>

<p>libsecp256k1-zkp <a href="https://github.com/ElementsProject/secp256k1-zkp/blob/cad7cc8f34d17166da2dabae20188ea6e747ac69/src/modules/musig/tests_impl.h#L616" rel="nofollow noreferrer">has a unit test</a> for a scriptless script atomic swap using that technique.</p>

<blockquote>
  <p>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?</p>
</blockquote>

<p>The adaptor point <code>t*G</code> is the per-hop tweaked payment point, not the MuSigTweak.</p>

CC BY-SA 4.0
2020-04-10T08:52:01.523Z
2020-04-10T08:52:01.523Z
nickler
<p>In a <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html" rel="nofollow noreferrer">mailing list post</a> 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 <code>adaptor</code> (last argument of <a href="https://github.com/jonasnick/secp256k1-zkp/blob/schnorrsig-updates-with-musig/src/modules/musig/main_impl.h#L369" rel="nofollow noreferrer"><code>secp256k1_musig_session_combine_nonces</code></a>) in secp256k1-zkp? And has in fact been implemented?</p>

<p>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?</p>

<p>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 <code>adaptor</code> argument because the implementation will treat the adaptor differently depending in the index of the signer?</p>

<lightning-network><schnorr-signatures><musig><point-time-locked-contract>
Is Z-man's PTLC construction implementable using libsecp256k1-zkp?
Janus Troelsen
# Is Z-man's PTLC construction implementable using libsecp256k1-zkp?

(Asked by: username_0 on 2020-04-08)

In a [mailing list post](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html) 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`](https://github.com/jonasnick/secp256k1-zkp/blob/schnorrsig-updates-with-musig/src/modules/musig/main_impl.h#L369)) 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?

**Tags:** lightning-network, schnorr-signatures, musig, point-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2020-04-10. Score: 2 | Accepted answer

> 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](https://github.com/ElementsProject/secp256k1-zkp/blob/cad7cc8f34d17166da2dabae20188ea6e747ac69/src/modules/musig/main_impl.h#L49). 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](https://lists.launchpad.net/mimblewimble/msg00086.html) mailing list post and in the [Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability](https://eprint.iacr.org/2018/472) 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](https://github.com/ElementsProject/scriptless-scripts/blob/master/md/multi-hop-locks.md).

libsecp256k1-zkp [has a unit test](https://github.com/ElementsProject/secp256k1-zkp/blob/cad7cc8f34d17166da2dabae20188ea6e747ac69/src/modules/musig/tests_impl.h#L616) 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.


---

