On Thu, 11 May 2023 at 13:12, AdamISZ 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 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 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 > > >