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 signatureUse 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 ?