AdamISZ [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-11 🗒️ Summary of this message: The usefulness ...
📅 Original date posted:2023-05-11
🗒️ Summary of this message: The usefulness of single signer adaptors is not limited to creating enforcement for revealing a secret. If a signature adaptor is created with an encryption key Y for message m and no further signatures are created, any signature on m that is published reveals the secret on Y to the creator. This has been used for years in production by DLCs.
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> Hi Waxwing,
>
> On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230511/8d136b60/attachment-0001.html>;
🗒️ Summary of this message: The usefulness of single signer adaptors is not limited to creating enforcement for revealing a secret. If a signature adaptor is created with an encryption key Y for message m and no further signatures are created, any signature on m that is published reveals the secret on Y to the creator. This has been used for years in production by DLCs.
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> Hi Waxwing,
>
> On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230511/8d136b60/attachment-0001.html>;