Understood. Performance aside, the other downside is new people will ask "Why are they using a MuSig API over a single key?" and some old wizard will have to recall the folklore about the particular APIs that libsecp256k1 had at the time and the weird trick they came up with.
LL On Thu, 21 Sept 2023 at 11:56, Anthony Towns <a...@erisian.com.au> wrote: > On 21 September 2023 11:44:47 am AEST, Lloyd Fournier < > lloyd.fo...@gmail.com> wrote: > >Hi AJ, > > > >On Wed, 20 Sept 2023 at 17:19, Anthony Towns <a...@erisian.com.au> wrote: > > > >> > >> I think: > >> > >> https://github.com/BlockstreamResearch/scriptless-scripts/pull/24 > >> > >> describes (w/ proof sketch) how to do a single-signer adaptor with > musig2; > >> might need some updates, to match the final musig2 API, but I think it's > >> fundamentally okay: ie, you get the "single-sig adaptor" approach, but > >> can just use the musig2 api, so best of both worlds. > >> > >> > > Can you explain the distinction here? What is a MuSig2 adaptor signature > >vs single-singer adaptor with MuSig2. > > > >Cheers, > > > >LL > > You can do ptlcs scriptlessly by having a 2-of-2 musig pubkey that the > payer signs with an adaptor signature - this can be done via the key path, > but then requires nonce exchanges leading to extra communication rounds. > Alternatively, you can do them via the script path, replacing "hash160 > equalverify b checksig" with "a checksigverify b checksig" where Alice > gives Bob an adaptor sig which Bob completes when claiming the output. The > question is how to do this latter approach, and I think it works fine to > have Alice do a "single party musig2" calculation for it, rather than > needing a separate api. > > Cheers, > aj > > > -- > Sent from my phone. >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
