From: Lloyd Fournier <lloyd.fourn@gmail•com>
To: AdamISZ <AdamISZ@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On adaptor security (in protocols)
Date: Thu, 11 May 2023 19:41:14 +0800 [thread overview]
Message-ID: <CAH5Bsr30dtyCNrkKc4UNecKspetJY_jFTXtZtp2NTXPXM12jQg@mail.gmail.com> (raw)
In-Reply-To: <BQClOoj6CuBhYCAaLFZyoUvmKuiueRtp6Jv0y1GU85uP4WJyH6acQwceQpGFOSpihR135pTJx5aLFtr-EDA8LQWfkAmo9RS6UCJj5-H8cX8=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 4102 bytes --]
On Thu, 11 May 2023 at 13:12, AdamISZ <AdamISZ@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@lists•linuxfoundation.org> wrote:
>
> Hi Waxwing,
>
> On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ@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
>
>
>
[-- Attachment #2: Type: text/html, Size: 6269 bytes --]
next prev parent reply other threads:[~2023-05-11 11:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 18:13 AdamISZ
2023-05-01 4:23 ` Lloyd Fournier
2023-05-01 18:37 ` AdamISZ
2023-05-03 12:58 ` AdamISZ
2023-05-08 4:37 ` Lloyd Fournier
2023-05-11 5:12 ` AdamISZ
2023-05-11 11:41 ` Lloyd Fournier [this message]
2023-05-14 8:37 ` AdamISZ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH5Bsr30dtyCNrkKc4UNecKspetJY_jFTXtZtp2NTXPXM12jQg@mail.gmail.com \
--to=lloyd.fourn@gmail$(echo .)com \
--cc=AdamISZ@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox