Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-11 🗒️ Summary of this message: Two developers ...
📅 Original date posted:2023-05-11
🗒️ Summary of this message: Two developers discuss the usefulness of single signer adaptors in Bitcoin transactions, with one arguing they can be useful for revealing secrets in certain situations.
📝 Original message:On Thu, 11 May 2023 at 13:12, AdamISZ <AdamISZ at protonmail.com> wrote:
>
> 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?
>
I think the problem is that Alice can still move the funds even if Bob
decrypts and broadcasts by revealing s if she gets confirmed first. I think
you always need a multisig in these kinds of situations but it need not be
a key aggregated multisig like MuSig -- this was the point I wanted to make
(in retrospect clumsily). I don't think I can name a useful use of a single
signer adaptor signature in Bitcoin at least not without some kind of other
spending constraint. So your intuitive point holds in practice most of the
time.
LL
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/d9dce7e2/attachment-0001.html>;
🗒️ Summary of this message: Two developers discuss the usefulness of single signer adaptors in Bitcoin transactions, with one arguing they can be useful for revealing secrets in certain situations.
📝 Original message:On Thu, 11 May 2023 at 13:12, AdamISZ <AdamISZ at protonmail.com> wrote:
>
> 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?
>
I think the problem is that Alice can still move the funds even if Bob
decrypts and broadcasts by revealing s if she gets confirmed first. I think
you always need a multisig in these kinds of situations but it need not be
a key aggregated multisig like MuSig -- this was the point I wanted to make
(in retrospect clumsily). I don't think I can name a useful use of a single
signer adaptor signature in Bitcoin at least not without some kind of other
spending constraint. So your intuitive point holds in practice most of the
time.
LL
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/d9dce7e2/attachment-0001.html>;