From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Jul 2026 07:29:56 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1whplC-0007gs-Ra for bitcoindev@gnusha.org; Thu, 09 Jul 2026 07:29:56 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-448d51840c4sf1033531fac.1 for ; Thu, 09 Jul 2026 07:29:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1783607389; cv=pass; d=google.com; s=arc-20260327; b=Vb/KL6fTLLlWaTP++qGHhGHN72eUx8yNJ4ev1+ySAshcZOn+EAfK7w8thIpT8nydcg TVPMmORtk72qPdfXOa5f3u52IjEdxOIPmKZMTJV88nbZzfwgGeiedohFU5pMq5vLnXL8 SffpWabJ9PqYmesDmtxag1DOfxCyJarkdGcQVWbyO0RUXYdPODp42aHfANOI3Ve+9i7o ujcXm/bmYNE6MzpVK/BSM55qiihxIadOcGuQ/LbwVM2QzeEHjI5m6ybHmCC0WuxUXG2h m+wla/scPBB7dJ3BsOX1xCLbO+desB+gpmU/X1mUBRmUPml8pLhtHt36bm3Z5nWKRrVK ILdg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:from:to:date :dkim-signature; bh=7GzS/uoXZyn4JxRc0VqKZkyH1pw+7PD2n5OXI9tan0g=; fh=W2NS6wlrHuBrbPPcKrC3BVvFtSAW+AzgH/OlJ9bsyrw=; b=kau1pIlMXg3ttyZtJAKxDS16rVBiJLeXLEj16UgorXto6BTz93eOnGJEhFEMvRT9lJ Dilojmstmv+vsi7Pv5DMxDV4I39zVKRP85gvy2yDh+sriRwi5M9pl0xYuOhiRhg0BINw jgbLP8sOavdKnvZzW+gPobw8jdEe+JkcSgQellWMqKaDQB1T+nJTQ5ee1aHFCcPJJ68q 40AQy4bUzOPhs8agp5zovZa4yVCsXaLNhNhOhCJZS3s0SMhQgsFni3CDmizHsjhR8uCV pNpHYFuVTSPkh0zw/CoUGOnXIYrjPUJMN4g8pH8VOm8yGDS5xsv1AuGb5X4Ts0AgTZ2Q N9lg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=qujmViSL; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1783607389; x=1784212189; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7GzS/uoXZyn4JxRc0VqKZkyH1pw+7PD2n5OXI9tan0g=; b=RS3SFCvGkXno/QbTW1tamGAFOotxhERXzmP4aZWkKzFRlwIOZ88Cfo0/Gqd764VdM0 Sg3KQ9Zpi4HWOpWpo6tp3V1VFo7k6O6umPWv/MzAmQ1xSLmbivX8+GOmX4LMd4ASzW3V EH+BqS03fLoUVW3fEWE5sEX1KLWyTJ2TmrP4sJgp1dHRpqum75BLl2TzaylXW2nvNaJz M/Kplzq8iPa2+NSStovEbSveom8FXruibCLmUCWh5RZ/8fmMbrB/ZQDpQ5innuSNLFQ9 duFXSkZ+rCMZ7or/aJw9VTfcSp5J3okqvFXK46XB2oJO7SbcY1rqGgBQaf1Wu37ROJWy uLgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783607389; x=1784212189; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7GzS/uoXZyn4JxRc0VqKZkyH1pw+7PD2n5OXI9tan0g=; b=N6MU1F2zke38rhSL8+mcuwovsnDDmaWSLzBs0rSoWnOkyW1iyMx0UO/B3Ekb8hEaL0 0+WVVrxdh85jSZ9MNgCvKmwC1CQz8aJpmRJAKUED1HBb9d3HVI6SyTonIpakU9KQGIFI CUNOPelTiOcBBqxmdaQInorK0JyBtVO1mep4uDM/zqhk1HOGhgTrrkAK/CosI6K+/rft g1qwMFRKvZYEj/s6iUcWQz17LdsmOmRGssSGAxvgJdRxpusY5jb+jYKZ+C2oNgQTrETt rjvAS3PrruEZhnMynYZBhu5NTMhk7FfN4I3MjUSWkZFWlY2uB6HZrnBKHvWxOSmOFCwi 8nsw== X-Forwarded-Encrypted: i=2; AHgh+Rpc+F5XB0jng4CMpMqBRT6zDkvldw3SMOUL/RkAXnnso34IpDd8ZQc7d/gA/c/TRspQjqnG+DNZjZaY@gnusha.org X-Gm-Message-State: AOJu0YyxwCtbvDLGAOnkDPR6zOunWoZkKtbWxE42nNFObkVGaJRpNz5j EoQHeQarJXDNMDNa4GrkV3x4qNRdR/vg6J6TfxkiMZSsp7KeYVsLoq45 X-Received: by 2002:a05:6870:ebc7:b0:447:9966:4ec6 with SMTP id 586e51a60fabf-45163ce5264mr4120994fac.30.1783607388667; Thu, 09 Jul 2026 07:29:48 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUd72yVbOJ4GB4DnD/Gj70i0VmoVen6aS2HRIU7CxW4OLQ==" Received: by 2002:a05:6871:4d0:b0:448:71b7:7e07 with SMTP id 586e51a60fabf-45148adbdc1ls1057278fac.0.-pod-prod-06-us; Thu, 09 Jul 2026 07:29:43 -0700 (PDT) X-Received: by 2002:a05:6808:6f89:b0:496:1e4:1f0c with SMTP id 5614622812f47-4a2026500b5mr5661787b6e.16.1783607383654; Thu, 09 Jul 2026 07:29:43 -0700 (PDT) Received: by 2002:a05:6808:50d3:10b0:495:e116:a399 with SMTP id 5614622812f47-4a1af8f2796msb6e; Thu, 9 Jul 2026 07:17:24 -0700 (PDT) X-Received: by 2002:a05:6808:124d:b0:496:3a1:e44f with SMTP id 5614622812f47-4a201c02743mr4715861b6e.6.1783606642883; Thu, 09 Jul 2026 07:17:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783606642; cv=none; d=google.com; s=arc-20260327; b=QDRH4PJnOkWfIa3g326RV6NQRhJzNUpTpTHbKrgohUJpWClyl34oip21lOfLGt8b69 MG2023TrrimVd2mitbEofEL7OyFnpds84UXKEjK7AnhtuEuKpQ5RGTxi0M7AUuE0TR6L zEp1ymzHdmOLvbEpv54lHExkzKf8mt5qNZb/1X47b20+iJli9fPhGRgZGrSFDURZWfY/ ExHQ8cbwgzasy7YShaP4qqGwJNOXU0p3r7tVFYlq4zKNw0WKU1wgHdHtYW8Ffh+G9WRD vRRo+kW0Xuc1Y24W/MC5WynbPsNdp0nomqo0lYJJS6krg4nSNa20t4OEk4HQwkpy3ySA e01A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:dkim-signature; bh=z+dCqH5dS56QNWnm5q0hnnltNJLsFlGzAiZKIKqBgrk=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=F2v0DvOGsfduCU5P81ZPyKYowAsMuBU/MXmo8PT1mdny8+223RksLvvvu7QaL0/o67 PIS/wqerBRXyzcPhmCNx2cOdPper1eCrMSHT4Ng8pqLbM/5zlrd6lWi0+vfGLivyTU5k 6l+i8+DjpCuDwDVbuiYJp+6mqGKuI5LPKLDCxufdTZPg2/EfCMX8bdpdnRXR5bqY+0ZI 3Bph8100SZcMV/F+ZALZbxzM8w/ewWc3kEXxnke3ORpb5tYTN2sGTCdJqlW6Hf0A04cK e6+RPTdGgy30jV0wIChUJXP8gaKzW8wWN0PXqrCNfoSkfLfdxXvzXM+GBrHXMsu1jejA mj/g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=qujmViSL; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch. [109.224.244.18]) by gmr-mx.google.com with ESMTPS id 5614622812f47-4a1a9ffbf89si259779b6e.0.2026.07.09.07.17.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 07:17:22 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) client-ip=109.224.244.18; Date: Thu, 09 Jul 2026 14:17:15 +0000 To: Bitcoin Development Mailing List From: "'Fabian' via Bitcoin Development Mailing List" Subject: Re: [bitcoindev] Re: BIP draft: Full-Aggregation of BIP 340 Signatures Message-ID: In-Reply-To: References: <75t3ixAqup9wRTr9PyKDXNBQHHN3MnIMiDBHKhrzo_B9gGUH0gsa8Ni8tXrjDdhWf2UDsL7Jh3iRsCQ0A7fLU0NhttxFsaqQBi17zU89iYQ=@protonmail.com> <2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n@googlegroups.com> Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 1aac164a91fb273e8af2a91877bd25d6abbef037 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_zeqvyGcTp3OLLhVmlih4uoNeY7Mwce37JK8yp2racqA" X-Original-Sender: fjahr@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=qujmViSL; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Fabian Reply-To: Fabian Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_zeqvyGcTp3OLLhVmlih4uoNeY7Mwce37JK8yp2racqA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi waxwing, Thanks again for the valuable feedback! I pushed another commit with my changes in response to your comments again: https://github.com/fjahr/bips/pull/4/commits/a68f47ab34ff956d575b7a7= 79761f1a35767476e > On list ordering, I was tempted to write "why not include a default > ordering algorithm", but ... I can see why that's not worth bothering > with This line of thinking didn't really occur to me to be honest but I think yo= u are right that the untrusted coordinator means nothing of the ordering is security relevant. So I made no change here. > I think it's reasonable to briefly describe the security claim > somewhere, and what its kind of "ancestry" is. The security section already had some of this but I have added the same additional detail that BIP 327 has on AOMDL. I didn't address the post-quantum note since I don't think readers could understand this to be quantum secure and it opens a pretty big can of worms to start mentioning things that a BIP is not. I think this is more of a broad question where, if there is agreement for this to be warranted, all BIPs that discuss ECC stuff that are not quantum safe could get a flag or something that highlights this. For co-EUF-CMA I added a footnote as briefly as possible but usually I think readers should probably better go and read the paper if they want to dive this deep into it. I hope the footnote just encourages that. > why do you link to [the MuSig-DN post] in the section where you're > saying "don't use deterministic nonce generation"? I agree this isn't ideal. I took the link from BIP 327, where the context for the attack description is much more fitting while here it could be confusing. I didn't find a better place to link to so instead I have replaced the link with a footnote that describes the attack directly. > I'm just wondering, why does this not apply to BIP327 also? I think it does. BIP 327's Nonce Generation section describes this as well and the BIP even specifies this within DeterministicSign: https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki#deterministi= c-and-stateless-signing-for-a-single-signer I omitted specifying something similar since DahLIAS doesn't talk about it and it may require further analysis similar to the single signer optimization from your first email. Best,Fabian On Wednesday, July 8th, 2026 at 9:29 PM, waxwing/ AdamISZ wrote: > A couple of other minor comments: > > On list ordering, I was tempted to write "why not include a default order= ing algorithm", but ... I can see why that's not worth bothering with, sinc= e the design includes the untrusted coordinator role, so in that sense it r= eally doesn't matter. > > *Edit; leaving this paragraph in, but, it's not worth much; you already h= ave a description that covers most everything I mention here: > > Security argument: the paper's security claim is a reduction to the algeb= raic variant of the one-more-discrete-log assumption under the random oracl= e model for the hash_sig (AOMDL under ROM). Obviously there's only so much = to be written there, but following on from BIP340 and BIP327 I think it's r= easonable to briefly describe the security claim somewhere, and what its ki= nd of "ancestry" is. As there, pointing out that AOMDL is a weaker (better)= assumption is probably worth mentioning. You could also add a note, though= it's unlikely any BIP reader would be confused about this point, that the = scheme is *not* intended to be post-quantum secure. > > (Is it worth mentioning the co-EUF-CMA definition here? Perhaps in a foot= note? While it's both in the weeds, and also has no direct implication for = implementation, it nicely shows why the technical problem to solve here is = different from what the paper calls "IMS" vs "IAS".) > > About nonce gen: this is obviously a tricky but hugely important point, j= ust as it was for BIP327. The first comment I want to make is, why do you l= ink to https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with= -verifiably-deterministic-nonces-27424b5df9d6#e3b6 in the section where you= 're saying "don't use deterministic nonce generation"? The main point of th= at blog post is to show a way that that *can* done in MuSig2, even though, = by default, it's insecure. But aren't you mainly trying to point out that, = as in BIP327, in this BIP, we don't have security with deterministic nonces= ? (rather than making a Musig-DN recommendation)? > > (Hmm, I guess you used that link because it nicely describes the attack? = If so maybe another link's better as it could be misleading perhaps). > > Separately you do point out the statelessness requirement can be dropped = for one signer, which is a nice detail. ... I'm just wondering, why does th= is not apply to BIP327 also? (I guess in some general sense it does, but ma= ybe it was not interesting there for some reason? Is it just because the 's= pecial last signer deterministic' subcase subsumes it?) > > Cheers, > AdamISZ/waxwing > > On Tuesday, July 7, 2026 at 4:49:39=E2=80=AFPM UTC-3 waxwing/ AdamISZ wro= te: > >> Hi Fabian, >> >> Great! Thanks for the progress on this. >> >> Can I suggest one addition: in the Sign algo, you have "Index lookup and= uniqueness check: Find the unique index j in 0..u-1 such that pubnoncej[33= :66] =3D cbytes(R2). Fail if no such index exists or if more than one such = index exists." (and then the pubkey and message check after). Perhaps add a= footnote warning, as per the paper, that these 2 checks are *not* equivale= nt to checking that the tuple (pubkey, message, R_2) is unique. I mean it's= not technically needed but seems like a very good idea, since as per the p= aper there is an attack there, and it would not be an unanticipatable imple= mentation footgun. >> >> You have the checks in the reference.py implementation, obviously; but p= utting that "tripwire" in the test vectors seems very advisable, though (I = admit my check of your generated test vectors was not thorough but I think = it's not there yet?) >> >> Second point goes from the ultra-specific to the ultra-general: I'm prob= ably being dumb here, but it seems a little strange to have a BIP that spec= ifies the algo but not the consensus change at all? Hmm, as I write this ..= . I guess this is mirroring BIP340 vs BIP341? That the former just formaliz= es the exact algo of the signature scheme and a later BIP specifies the lat= ter? It is a bit different though; taproot was a whole new scripting scheme= , this will just (I guess?) have basically a new OP_CODE (or rather, redefi= nition) or similar? >> >> About motivation: >> >>> CISA with full-aggregation can even create an economic incentive for pr= ivacy since using CoinJoin and PayJoin transactions can become cheaper than= sending individual transactions. >> >> It's a can of worms, since there are so many nuances, but I think the te= ndency to assume that this incentivization is real is a *little* misleading= : CISA does *not* incentivize batching payments in a way that creates priva= cy; it only incentivizes consolidation and batching (amongst many spenders = as well as for one spender). What is undeniable is that *if* you're doing a= coinjoin of some flavor, you are incentivized to switch to CISA. Anyway, d= on't take this as a big criticism particularly, because *whatever* you writ= e here will be arguable. My personal intuition is that CISA *does* aid priv= acy but more via second and third order effects than via first order. But, = meh, not simple :) >> >> I'd also like to repeat a request on the earlier discussion on this mail= ing list [1] on this topic: >> >> (Quoting Jonas' answer to me here: ) >>>> The side note also raises this point: would it be a good idea to expli= citly >>>> write down ways in which the usage of the scheme/structure can, and ca= nnot, >>>> be optimised for the single-party case? >>> >>>This is a very interesting point, probably out of scope for the paper. A >>>single-party signer, given secret keys xi, ..., xn for public keys X1, .= .., Xn >>>can draw r at random, compute R :=3D r*G and then set s :=3D r + c1*x1 += ... + >>>cn*xn. So this would only require a single group multiplication. >> >> .. but, I relegate this to a "comment" here, because I don't know if the= re is a written down "optimization for single signer" apart from what Jonas= said there. If it doesn't exist, you can't put it in the BIP :) What I thi= nk would really be worth avoiding is : there's a folklore optimization for = coding the use of DahLIAS in a single wallet that is not properly analyzed = by the people here who know what they're talking about -- because, "minefie= ld" etc etc. >> >> Cheers, >> waxwing/AdamISZ >> >> [1] https://groups.google.com/g/bitcoindev/c/eothFkxAvK0/m/gfGZ8NxXEQAJ = and surrounding conversation >> On Monday, July 6, 2026 at 2:10:57=E2=80=AFPM UTC-3 Fabian wrote: >> >>> Hi list, >>> >>> I would like to share a BIP draft for full-aggregation of BIP 340 >>> signatures, a standard for the DahLIAS interactive aggregate signature >>> scheme by Jonas Nick, Tim Ruffing, and Yannick Seurin: >>> https://eprint.iacr.org/2025/692 >>> >>> Full-aggregation allows a group of signers to produce a single 64-byte >>> signature for a list of public key and message pairs in a two-round >>> signing protocol very similar to MuSig2/BIP327. The primary application >>> in Bitcoin would be CISA (cross-input signature aggregation). >>> >>> The BIP draft text can be found here: >>> https://github.com/fjahr/bips/blob/4b34e86d0040edad6cba3f7518b33472a11e= beaf/bip-XXXX.mediawiki >>> >>> For inline comments, I have opened a mock pull request on my BIPs repo = fork: >>> https://github.com/fjahr/bips/pull/4 >>> >>> Feedback of any kind is much appreciated. >>> >>> Best, >>> Fabian > > -- > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/dc07a3e4-0bc7-44fe-9136-1ece837747efn%40googlegroups.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= tSYH-B4F91BsIzpl_FqPIhxO2xkoDmzbqz097XD41wJGmeHM7Cbt5JP0uqic9aicjM7Hhhr5F_4= WEORFyHKYHowqemy0yeVr9p_vnaQhYYM%3D%40protonmail.com. --b1=_zeqvyGcTp3OLLhVmlih4uoNeY7Mwce37JK8yp2racqA Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi wa= xwing,

Thanks again for the valuable feedba= ck!

I pushed another com= mit with my changes in response to your comments

> On list ordering, I was tempted t= o write "why not include a default
> ordering alg= orithm", but ... I can see why that's not worth bothering
= > with

This line of thinking= didn't really occur to me to be honest but I think you
ar= e right that the untrusted coordinator means nothing of the ordering
<= div>is security relevant. So I made no change here.

> I think it's reasonable to briefly describe the security claim=
> somewhere, and what its kind of "ancestry" is.=

The security section already had som= e of this but I have added the
same additional detai= l that BIP 327 has on AOMDL.

<= span>I didn't address the post-quantum note since I don't think= readers
could understand this to be quantum secure and it opens = a pretty
big can of worms to start mentioning things that a BIP i= s not. I think
this is more of a broad question where, if there i= s agreement for this
to be warranted, all BIPs that discuss ECC s= tuff that are not quantum
safe could get a flag or something that= highlights this.

For co-EUF-CMA I added a footnot= e as briefly as possible but usually
I think readers should proba= bly better go and read the paper if they
want to dive this deep i= nto it. I hope the footnote just encourages that.

= > why do you link to [the MuSig-DN post] in the section where you'= re
> saying "don't use deterministic nonce genera= tion"?

I agree this isn't ideal. I to= ok the link from BIP 327, where the context
for the attack= description is much more fitting while here it could be
confusin= g. I didn't find a better place to link to so instead I have
repl= aced the link with a footnote that describes the attack directly.

> I'm just wondering, why does this not apply to B= IP327 also?

I think it does. BIP 327'= s Nonce Generation section describes this
as well and= the BIP even specifies this within DeterministicSign:
I omitted specifyin= g something similar since DahLIAS doesn't talk
about it and it ma= y require further analysis similar to the single
signer optimizat= ion from your first email.

Best,Fabian
On Wednesday, July 8th, 2026 at 9:29 PM, waxwing/ AdamISZ <ekagg= ata@gmail.com> wrote:
A couple of other minor comments:

On list ordering, I was tempted to write "why not include a default ordering algorithm", but ... I can see why that's not worth bothering with, since the design includes the untrusted coordinator role, so in that sense it really doesn't matter.

*Edit; leaving this paragr= aph in, but, it's not worth much; you already have a description that cover= s most everything I mention here:

Security argumen= t: the paper's security claim is a reduction to the algebraic variant of the one-more-discrete-log assumption under the random oracle model for the hash_sig (AOMDL under ROM). Obviously there's only so much to be written there, but following on from BIP340 and BIP327 I think it's reasonable to briefly describe the security claim somewhere, and what its kind of "ancestry" is. As there, pointing out that AOMDL is a weaker (better) assumption is probably worth mentioning. You could also add a note, though it's unlikely any BIP reader would be confused about this point, that the scheme is *not* intended to be post-quantum secure.

=
(Is it worth mentioning the co-EUF-CMA definition here? Perhaps in a footnote? While it's both in the weeds, and also has no direct implication for implementation, it nicely shows why the technical problem to solve here is different from what the paper calls "IMS" vs "IAS".)

About nonce gen: this is obviously a tricky but hugely important point, just as it was for BIP327. The first comment I want to make is, why do you link to https://medium.com/blockstream/mus= ig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5d= f9d6#e3b6 in the section where you're saying "don't use deterministic nonce generation"? The main point of that blog post is to show a way that that *can* done in MuSig2, even though, by default, it's insecure. But aren't you mainly trying to point out that, as in BIP327, in this BIP, we don't have security with deterministic nonces? (rather than making a Musig-DN recommendation)?

(Hmm, I guess you used that link because it nicely describes the attack? If so maybe another link's better as it could be misleading perhaps).

Separately you do point out the statelessness requirement can be dropped for one signer, which is a nice detail. ... I'm just wondering, why does this not apply to BIP327 also? (I guess in some general sense it does, but maybe it was not interesting there for some reason? Is it just because the 'special last signer deterministic' subcase subsumes it?)

Cheers,
AdamISZ/waxwing


=
On Tuesday, July 7, 2026 at 4:49:39= =E2=80=AFPM UTC-3 waxwing/ AdamISZ wrote:
Hi Fabian,

Great!= Thanks for the progress on this.

Can I suggest on= e addition: in the Sign algo, you have "Index lookup and uniqueness chec= k: Find the unique index j in 0..u-1 such that pubnonc= ej[33:66] =3D cbytes(R2). Fail if no such index e= xists or if more than one such index exists." (and then the pubkey and mess= age check after). Perhaps add a footnote warning, as per the paper, that th= ese 2 checks are *not* equivalent to checking that the tuple (pubkey, messa= ge, R_2) is unique. I mean it's not technically needed but seems like a ver= y good idea, since as per the paper there is an attack there, and it would = not be an unanticipatable implementation footgun.

= You have the checks in the reference.py implementation, obviously; but putt= ing that "tripwire" in the test vectors seems very advisable, though (I adm= it my check of your generated test vectors was not thorough but I think it'= s not there yet?)

Second point goes from the ultra= -specific to the ultra-general: I'm probably being dumb here, but it seems = a little strange to have a BIP that specifies the algo but not the consensu= s change at all? Hmm, as I write this ... I guess this is mirroring BIP340 = vs BIP341? That the former just formalizes the exact algo of the signature = scheme and a later BIP specifies the latter? It is a bit different though; = taproot was a whole new scripting scheme, this will just (I guess?) have ba= sically a new OP_CODE (or rather, redefinition) or similar?

<= /div>
About motivation:

> CISA with full-ag= gregation can even create an economic incentive for privacy since using CoinJoin and PayJoin transactions can become cheaper than sending individual transactions.

It's a can = of worms, since there are so many nuances, but I think the tendency to assu= me that this incentivization is real is a *little* misleading: CISA does *n= ot* incentivize batching payments in a way that creates privacy; it only in= centivizes consolidation and batching (amongst many spenders as well as for= one spender). What is undeniable is that *if* you're doing a coinjoin of s= ome flavor, you are incentivized to switch to CISA. Anyway, don't take this= as a big criticism particularly, because *whatever* you write here will be= arguable. My personal intuition is that CISA *does* aid privacy but more v= ia second and third order effects than via first order. But, meh, not simpl= e :)

I'd also like to repeat a request on the earl= ier discussion on this mailing list [1] on this topic:

=
(Quoting Jonas' answer to me here: )
>> The side note = also raises this point: would it be a good idea to explicitly
>> write down ways in which the usage of the scheme/structure can= , and cannot,
>> be optimised for the single-party case?
>
>This is a very interesting point, probably out of scope for= the paper. A
>single-party signer, given secret keys xi, ..., xn for public keys = X1, ..., Xn
>can draw r at random, compute R :=3D r*G and then set s :=3D r + c1= *x1 + ... +
>cn*xn. So this would only require a single group multiplication.

.. but, I relegate this to a "comment" here, beca= use I don't know if there is a written down "optimization for single signer= " apart from what Jonas said there. If it doesn't exist, you can't put it i= n the BIP :) What I think would really be worth avoiding is : there's a fol= klore optimization for coding the use of DahLIAS in a single wallet that is= not properly analyzed by the people here who know what they're talking abo= ut -- because, "minefield" etc etc.

Cheers,
<= div>waxwing/AdamISZ

On Monday, July 6, 2026 at 2:10:57=E2=80=AFPM UTC-3 Fabian wrote= :
Hi list,

=
I would like to share a BIP draft for full-aggregation of BIP 34= 0
signatures, a standard for the DahLIAS interactive= aggregate signature
scheme by Jonas Nick, Tim Ruffi= ng, and Yannick Seurin:

Full-aggregation allows a group = of signers to produce a single 64-byte
signature for= a list of public key and message pairs in a two-round
signing protocol very similar to MuSig2/BIP327. The primary application<= /span>
in Bitcoin would be CISA (cross-input signature aggr= egation).

The BIP draft text can be f= ound here:
Feedback of any kind is much appreciated.

Best,
Fabian

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/dc07a3e4-0bc7-44fe-913= 6-1ece837747efn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= tSYH-B4F91BsIzpl_FqPIhxO2xkoDmzbqz097XD41wJGmeHM7Cbt5JP0uqic9aicjM7Hhhr5F_4= WEORFyHKYHowqemy0yeVr9p_vnaQhYYM%3D%40protonmail.com.
--b1=_zeqvyGcTp3OLLhVmlih4uoNeY7Mwce37JK8yp2racqA--