> 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.
Indeed. Imagine forgetting that, couldn't be me :)
> 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.
Indeed I do have a similar memory of earlier discussions/thoughts that: the
finesse is that it only needs to be multisig, which is not the same as it
needing to be musig, or let's say aggregated. The conversation has shifted over
time because a lot of the first ideas (and papers) were pre-BIP340 activation
and included ECDSA variants. A good example of the lack of clarity on this is
the aforementioned Wei Dai paper, in which their base example is a swap without
any multisig, thus ignoring the double spend issue (forgiveable, they are
focused on different things in that paper). It's striking how unclear all this
is (perhaps, just for me!) ...
... so let's see if I have it right:
(1) - single key signature adaptor in isolation is basically useless, in a
Bitcoin context (signature is on a utxo) **
(2) - single key signature adaptor in combination with another locking
condition on the utxo, such as another pubkey lock (e.g.
op_checksigadd/op_checkmultisig), is useful in swapping a signature for a
secret, but it requires using the variant of the primitive in which the
non-secret-owner is the one encrypting (i.e. asymmetric encryption analog), and
the secret owner is giving the decryption.
(3) - most natural scenario, using aggregated signature schemes like MuSig1/2,
can allow the above, but can also allow the variant in which the secret owner
starts by providing the encryption, and then at a later stage of the protocol,
releases the decryption (this option is not available for (2), since the
provision of an adaptor for my own signature does not force me, in that case
to use the same R, and therefore a corresponding signature). (the canonical
description in [1] for any reader who's not familiar, outlines this case).
(the difference between (2) and (3) can maybe best be grokked as the choice
between "I need any signature of yours - I can get one by decrypting it using
my secret key, or you can just give me one" vs "I need a specific signature of
yours, I'll get it when you decrypt, using your own secret, the other
signature" - and here you see that the second one has a requirement that I
can't let you use an alternate for the first signature, because then I get
nothing.)
** But now I'm confused about your earlier reference to DLC implementations
using single signer constructions in the previous mail (your phrase was "using
single signer adaptor signatures as signature encryption in practice for years
for the transaction signatures") - can you link me to something about that? I
couldn't immediately find something in the DLC specs repo, though I'm probably
just missing it. I'm just really interested to know if there's another
functionality I'm missing here, (since you said it wasn't oracle attestation,
that you meant).
[1]
https://github.com/BlockstreamResearch/scriptless-scripts/blob/master/md/atomic-swap.md#atomic-swaps-using-adaptor-signatures
Cheers,
AdamISZ/waxwing
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Thursday, May 11th, 2023 at 12:41, Lloyd Fournier <lloyd.fo...@gmail.com>
wrote:
> On Thu, 11 May 2023 at 13:12, AdamISZ <adam...@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 <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
