Standardize the term adaptor signature

[jonasnick]

Currently the term adaptor signature is defined as a triplet (s', R, T) satisfying

s'G = T + R + H(P || R || m)P

However, multi hop locks as described in the paper and in @apoelstra's original mailing list post use adaptor signatures (s', R + T, -T), so

s'G = R + H(P || R + T || m)P

The point is that the party creating these does not need to know the secret adaptor t such that T = t*G. Both documents don't call these things adaptor signatures and don't use a different name for them.

The current multi-hop-locks.md document and the libsecp-zkp MuSig PR don't call these things adaptor signatures because functionally they are opposite in the sense that they don't include the adaptor. Instead they call Schnorr signatures (s + T, R + T) adaptor signatures because creating them requires knowing the adaptor and they provide the adaptor.

For adaptor signatures (s', R + T, -T) I'd suggest using the term ~~adaptorless signatures~~ partial signatures.

Now there are the following options

1. Don't introduce adaptorless signatures and rewrite multi-hop-locks.md and the libsecp-zkp MuSig PR to use adaptor signature for adaptorless signatures.
2. Introduce the term adaptorless signature for the triple and rewrite multi-hop-locks.md and the libsecp-zkp MuSig PR. As a consequence they would not require adaptor signatures, only regular Schnorr sigs and adaptorless sigs.
3. ~~Introduce the term adaptorless signature~~Use the term partial signature and redefine adaptor signatures to mean partial signature + adaptor. That requires rewriting atomic-swap.md, blind-swap.md and pedersen-swap.md to match the terminology.

I ~~thought adaptorless signatures~~ think partial signatures are strictly more general than adaptor signatures because they don't require knowing the secret adaptor. So I went for option 3 with this PR. ~~However, when you want to reveal multiple secret adaptors with a single signature as in the Pedersen Swap, you need to use the same public nonce and adaptorless signatures don't support that unless you use them in the non-intuitive way. So I'm torn now. Thoughts?~~

[ajtowns]

FWIW, I think of s = x + H(R,P,m)*q (where either P != q*G or R != x*G or both) as a "partial signature", so "partial validation" takes a tuple (s,R,X,Q) instead of just (s,R) and checks s*G = X+H(R,P,m)*Q. (I think that works okay for MuSig as well, since you just fold the multiplier for each individual key into Q)

So I'd describe (s+t, R+T) as being an "adaptor signature" for P, m calculated from the "partial signature" (s, R+T, R, P) and the secret t.

[jonasnick]

@ajtowns Thanks, I think this is the most reasonable terminology at this point. It's also how it's handled in libsecp, because every "adaptorless sig" is also a "partial sig" in the conventional, MuSig sense (missing the other parties secret key), so the term adaptorless is never needed. It's not ideal because sometimes we want to highlight the fact that the adaptor is missing. But easier to explain that in a few more words than the ugly "adaptorless".

[jonasnick]

Rebased and renamed adaptorless to partial signatures. Removed WIP from PR.

[ysangkok]

Is the language in this PR compatible with https://eprint.iacr.org/2020/476.pdf ?