Hi Lloyd,
> Yes but suppose you do *not* create another signature adaptor or otherwise on
> m. Since you've only generated one adaptor signature on m and no other
> signatures on m there is no possibility that a signature on m that appears
> under your key would not reveal y to you. This is an useful property in
> theory and in practice.
Ah yes, this is a pretty big error on my part! Thanks for walking it through.
It's where this is analogous to asymmetric encryption. I remember you framing
it like that, in terms of asymmetric encryption (but with the one-time, a bit
like symmetric, twist), in your paper. I should have re-read it a lot more
thoroughly! :)
I must have had this misconception floating around in my head about adaptors
for years.
It's interesting that it didn't help choosing the framing : s' = k - t
+H(R|P|m)x instead of s' = k + H(R+T|P|m)x although, as I noted there, they're
equivalent (indeed, the former framing was also used in e.g. the description of
the atomic swap in the scriptless-scripts writeups repo). But in the latter
framing it's much more obvious that you can do this, given that you can just
plug T into the hash directly.
A sidebar, but it immediately brings it to mind: the canonical adaptor based
swap, you can do it with only one half being multisig like this, right? Alice
can encrypt the single-key signature for her payment to Bob, with the
encryption key being T= sG, where s is the partial signature of Bob, on the
payout from a multisig, to Alice. That way Bob only gets his money in the
single sig (A->B) tx, if he reveals his partial sig on the multisig. I don't
think it's of practical interest (1 multisig instead of 2? meh), but .. I don't
see anywhere that potential variant being written down? Is there some obvious
flaw with that?
Cheers,
waxwing/AdamISZ
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Waxwing,
>
> On Tue, 2 May 2023 at 02:37, AdamISZ <adam...@protonmail.com> wrote:
>
>> Hi Lloyd,
>> thanks for taking a look.
>>
>>> I think your view of the uselessness of single signer adaptors is too
>>> pessimistic. The claim you make is that they "don't provide a way to create
>>> enforcement that the publication of signature on a pre-defined message will
>>> reveal a secret'' and so are useless. I think this is wrong. If I hold a
>>> secret key for X and create a signature adaptor with some encryption key Y
>>> with message m and do not create any further signatures (adaptor or
>>> otherwise) on m, then any signature on m that is published necessarily
>>> reveals the secret on Y to me. This is very useful and has already been
>>> used for years by DLCs in production.
>>
>> I'm struggling with this one - say I hold privkey x for pubkey X. And I
>> publish adaptor for a point Y (DL y) for message m, like: s' = k - y +
>> H(R|X|m)x with k the nonce and R the nonce point.
>>
>> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of
>> course the secret y is revealed.
>>
>> What do you mean in saying "any signature on m that is published reveals y"?
>> Clearly you don't mean any signature on any key (i.e. not the key X). But I
>> also can't parse it if you mean "any signature on m using key X", because if
>> I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no algebraic
>> relationship to the adaptor s' as defined above, right?
>
> Yes but suppose you do *not* create another signature adaptor or otherwise on
> m. Since you've only generated one adaptor signature on m and no other
> signatures on m there is no possibility that a signature on m that appears
> under your key would not reveal y to you. This is an useful property in
> theory and in practice.
>
>> I think the point of confusion is maybe about the DLC construct? I
>> referenced that in Section 4.2, parenthetically, because it's analogous in
>> one sense - in MuSig(2) you're fixing R via a negotiation, whereas in
>> Dryja's construct you're fixing R "by definition". When I was talking about
>> single key Schnorr, I was saying that's what's missing, and thereby making
>> them useless.
>
> I was not referencing the DLC oracle attestation protocol - I am pointing out
> that DLC client implementations have been using single signer adaptor
> signatures as signature encryption in practice for years for the transaction
> signatures. There are even channel implementations using them as well as
> atomic swaps doing this iirc. It's a pretty useful thing!
>
> Cheers,
>
> LL
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
