From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 08 Jul 2026 12:29:41 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1whXxk-0004Al-Ph for bitcoindev@gnusha.org; Wed, 08 Jul 2026 12:29:41 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-44aed65b026sf233098fac.1 for ; Wed, 08 Jul 2026 12:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1783538974; x=1784143774; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=zVP0CSEnyIJ6iD7EdjTw6AiC9e+7vsbJ60Z9sPaWyyk=; b=HSE8qekGuXa5Ea9UNyVNNMKrf3pKk593IGcdy7i5iUBzZuLyhksbKO21un0J0POqhl As3B2BTksU0XOTrmjtxk9iuGVA5q1vfY50TRyqvMTdssbmCFTvQarCF7eR+iAwp5IDqS 2lCZ21zh0IBwQWsfTXcyrFBe7FTv9a1ulELpqlgJUgQiFZTET/Top9od+ovcRamsOesl ZLIuohxmI5/FDEUL2iwmRl2v7nSgLpLhbqHQwiz1y0SvH0jOLr7DhSo1kM0gO0gtBFu9 xAftkudyUd0QaE/ggoJS5LPZyztk6pL6X7oxwhyhoYYpPFyVufCREo3m16b3VdQ7KIvE uKHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783538974; x=1784143774; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=zVP0CSEnyIJ6iD7EdjTw6AiC9e+7vsbJ60Z9sPaWyyk=; b=dLzVZ9uvkqQqWBOAtwo5XCJVoQwhbHEvGyeXAgbJFiio5lPu0MtV45IPqJ+x8MU2F6 UpzG1+T+c05tNGL00WqIJMUF8+hNHX0GWwb5Cv8tjOt/blNZPEWB4m5vCna54WFPczjd W1z+JURP4qHcLYgZsKkCyYE573gh9+Y4+xBgwZy7TxC5/EdBPky7upqTy6T9q358GE1s zLQVHobgq8dVNNoNp7GgbezCV4ElxuLZLsaBjmL5LJEzohAbykF692cOutbFL21DGDoK EiU3jI3jIz3jfgLgSHyS3EFvCwSFzjprQgQrRJ1gsRTrAUVytfpfcVykZHNOSGOBeevz NPxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783538974; x=1784143774; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=zVP0CSEnyIJ6iD7EdjTw6AiC9e+7vsbJ60Z9sPaWyyk=; b=bO5KRFU/FVxBa5vyIqYSbNAaPAaocMalVBO6qMeDkH7IeZg8gpipfqk4vPovKuFRDU VNE+H+c2wfCUB+na3x2SIOwKDtC7p5y04Qgs8x04ouTNGh+Ydy4mrKiK+UT/Le+qn6VG eriWNjsRB+sRJEqvEio06SG0LQ+6HDXv8ye6H65Mk1kMT4uK7XBXStJq0j/Uh5lmLklX PgMDJCp0T8XK01gw3lVJZJkijCbwBlin2vAzR73hf17QgUP5JVLZf0ipS3HluGVM8UGG wLhh/4HG30OIswfbNp2wKJ+Bq1l2GO0SKdcR/XsnnUf5Er/ryK0zHcAc42drp8gkvu3j 4wQA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8O+gCgWzy+qQHuLt1ko5dO1APxRjDN/OKBdK6yhIN9WLVGxUJck0Byi97yfKrGRZYTR7qDAijgR8Ks@gnusha.org X-Gm-Message-State: AOJu0Yz8Q5/Uzi2f7TJNOqpCcE/GMsa3QDQ2kDXUz1YwyBvREE1ogWje 1MmMczZQ32HfXkKllX7SLn3ovac/gIU/Y67yYq2BoFbNepry6LGidttd X-Received: by 2002:a05:6820:1621:b0:6a1:7897:5b04 with SMTP id 006d021491bc7-6a35c2a6b75mr5316434eaf.1.1783538974555; Wed, 08 Jul 2026 12:29:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUehjHdoxhOmbd7HDv1fpYnLotfeAn6WKqSaOZSLb3axMQ==" Received: by 2002:a05:6870:a188:b0:447:9143:3d45 with SMTP id 586e51a60fabf-4514ac25837ls792869fac.1.-pod-prod-03-us; Wed, 08 Jul 2026 12:29:29 -0700 (PDT) X-Received: by 2002:a05:6808:120b:b0:4a1:296:adec with SMTP id 5614622812f47-4a20200866emr2772296b6e.15.1783538969492; Wed, 08 Jul 2026 12:29:29 -0700 (PDT) Received: by 2002:a05:690c:a64b:b0:80b:2194:fea2 with SMTP id 00721157ae682-81d742cc834ms7b3; Wed, 8 Jul 2026 12:14:06 -0700 (PDT) X-Received: by 2002:a05:690c:600d:b0:80b:9f4e:a88 with SMTP id 00721157ae682-81dbcc2fb1emr31777537b3.21.1783538045133; Wed, 08 Jul 2026 12:14:05 -0700 (PDT) Date: Wed, 8 Jul 2026 12:14:04 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n@googlegroups.com> References: <75t3ixAqup9wRTr9PyKDXNBQHHN3MnIMiDBHKhrzo_B9gGUH0gsa8Ni8tXrjDdhWf2UDsL7Jh3iRsCQ0A7fLU0NhttxFsaqQBi17zU89iYQ=@protonmail.com> <2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n@googlegroups.com> Subject: [bitcoindev] Re: BIP draft: Full-Aggregation of BIP 340 Signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_377676_375490975.1783538044666" X-Original-Sender: ekaggata@gmail.com 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: -0.5 (/) ------=_Part_377676_375490975.1783538044666 Content-Type: multipart/alternative; boundary="----=_Part_377677_634924858.1783538044666" ------=_Part_377677_634924858.1783538044666 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A couple of other minor comments: On list ordering, I was tempted to write "why not include a default=20 ordering algorithm", but ... I can see why that's not worth bothering with,= =20 since the design includes the untrusted coordinator role, so in that sense= =20 it really doesn't matter. *Edit; leaving this paragraph in, but, it's not worth much; you already=20 have a description that covers most everything I mention here: Security argument: the paper's security claim is a reduction to the=20 algebraic variant of the one-more-discrete-log assumption under the random= =20 oracle model for the hash_sig (AOMDL under ROM). Obviously there's only so= =20 much to be written there, but following on from BIP340 and BIP327 I think= =20 it's reasonable to briefly describe the security claim somewhere, and what= =20 its kind of "ancestry" is. As there, pointing out that AOMDL is a weaker=20 (better) assumption is probably worth mentioning. You could also add a=20 note, though it's unlikely any BIP reader would be confused about this=20 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=20 footnote? While it's both in the weeds, and also has no direct implication= =20 for implementation, it nicely shows why the technical problem to solve here= =20 is different from what the paper calls "IMS" vs "IAS".) About nonce gen: this is obviously a tricky but hugely important point,=20 just as it was for BIP327. The first comment I want to make is, why do you= =20 link to=20 https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifi= ably-deterministic-nonces-27424b5df9d6#e3b6=20 in the section where you're saying "don't use deterministic nonce=20 generation"? The main point of that blog post is to show a way that that=20 *can* done in MuSig2, even though, by default, it's insecure. But aren't=20 you mainly trying to point out that, as in BIP327, in this BIP, we don't=20 have security with deterministic nonces? (rather than making a Musig-DN=20 recommendation)? (Hmm, I guess you used that link because it nicely describes the attack? If= =20 so maybe another link's better as it could be misleading perhaps). Separately you do point out the statelessness requirement can be dropped=20 for one signer, which is a nice detail. ... I'm just wondering, why does=20 this not apply to BIP327 also? (I guess in some general sense it does, but= =20 maybe it was not interesting there for some reason? Is it just because the= =20 '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 one addition: in the Sign algo, you have "*Index lookup and= =20 > uniqueness check*: Find the unique index *j* in *0..u-1* such that *pubno= ncej[33:66]=20 > =3D cbytes(R2)*. Fail if no such index exists or if more than one such=20 > index exists." (and then the pubkey and message check after). Perhaps add= a=20 > footnote warning, as per the paper, that these 2 checks are *not*=20 > equivalent to checking that the tuple (pubkey, message, R_2) is unique. I= =20 > mean it's not technically needed but seems like a very good idea, since a= s=20 > per the paper there is an attack there, and it would not be an=20 > unanticipatable implementation footgun. > > You have the checks in the reference.py implementation, obviously; but=20 > putting that "tripwire" in the test vectors seems very advisable, though = (I=20 > admit my check of your generated test vectors was not thorough but I thin= k=20 > it's not there yet?) > > Second point goes from the ultra-specific to the ultra-general: I'm=20 > probably being dumb here, but it seems a little strange to have a BIP tha= t=20 > specifies the algo but not the consensus change at all? Hmm, as I write= =20 > this ... I guess this is mirroring BIP340 vs BIP341? That the former just= =20 > formalizes the exact algo of the signature scheme and a later BIP specifi= es=20 > the latter? It is a bit different though; taproot was a whole new scripti= ng=20 > scheme, this will just (I guess?) have basically a new OP_CODE (or rather= ,=20 > redefinition) or similar? > > About motivation: > > > CISA with full-aggregation can even create an economic incentive for=20 > privacy since using CoinJoin and PayJoin transactions can become cheaper= =20 > than sending individual transactions. > > It's a can of worms, since there are so many nuances, but I think the=20 > tendency to assume that this incentivization is real is a *little*=20 > misleading: CISA does *not* incentivize batching payments in a way that= =20 > creates privacy; it only incentivizes consolidation and batching (amongst= =20 > many spenders as well as for one spender). What is undeniable is that *if= *=20 > you're doing a coinjoin of some flavor, you are incentivized to switch to= =20 > CISA. Anyway, don't take this as a big criticism particularly, because=20 > *whatever* you write here will be arguable. My personal intuition is that= =20 > CISA *does* aid privacy but more via second and third order effects than= =20 > via first order. But, meh, not simple :) > > I'd also like to repeat a request on the earlier discussion on this=20 > 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=20 > explicitly=20 > >> write down ways in which the usage of the scheme/structure can, and=20 > cannot,=20 > >> be optimised for the single-party case?=20 > > > >This is a very interesting point, probably out of scope for the paper. A= =20 > >single-party signer, given secret keys xi, ..., xn for public keys X1,= =20 > ..., Xn=20 > >can draw r at random, compute R :=3D r*G and then set s :=3D r + c1*x1 += ...=20 > +=20 > >cn*xn. So this would only require a single group multiplication.=20 > > .. but, I relegate this to a "comment" here, because I don't know if ther= e=20 > is a written down "optimization for single signer" apart from what Jonas= =20 > said there. If it doesn't exist, you can't put it in the BIP :) What I=20 > think would really be worth avoiding is : there's a folklore optimization= =20 > for coding the use of DahLIAS in a single wallet that is not properly=20 > analyzed by the people here who know what they're talking about -- becaus= e,=20 > "minefield" etc etc. > > Cheers, > waxwing/AdamISZ > > [1] https://groups.google.com/g/bitcoindev/c/eothFkxAvK0/m/gfGZ8NxXEQAJ= =20 > 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/4b34e86d0040edad6cba3f7518b33472a11eb= eaf/bip-XXXX.mediawiki >> >> For inline comments, I have opened a mock pull request on my BIPs repo= =20 >> fork: >> https://github.com/fjahr/bips/pull/4 >> >> Feedback of any kind is much appreciated. >> >> Best, >> Fabian >> > --=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/= dc07a3e4-0bc7-44fe-9136-1ece837747efn%40googlegroups.com. ------=_Part_377677_634924858.1783538044666 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A couple of other minor comments:

On list= =20 ordering, I was tempted to write "why not include a default ordering=20 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 para= graph in, but, it's not worth much; you already have a description that cov= ers most everything I mention here:

Security arg= ument: the=20 paper's security claim is a reduction to the algebraic variant of the=20 one-more-discrete-log assumption under the random oracle model for the=20 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=20 to briefly describe the security claim somewhere, and what its kind of=20 "ancestry" is. As there, pointing out that AOMDL is a weaker (better)=20 assumption is probably worth mentioning. You could also add a note,=20 though it's unlikely any BIP reader would be confused about this point,=20 that the scheme is *not* intended to be post-quantum secure.

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

About nonce gen: this is obviously a=20 tricky but hugely important point, just as it was for BIP327. The first=20 comment I want to make is, why do you link to=C2=A0https://= medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-det= erministic-nonces-27424b5df9d6#e3b6 in the section where you're saying "don't use deterministic nonce=20 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=20 aren't you mainly trying to point out that, as in BIP327, in this BIP,=20 we don't have security with deterministic nonces? (rather than making a=20 Musig-DN recommendation)?

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

<= /div>
Separately you do point out the statelessness requirement can be dropped for one=20 signer, which is a nice detail. ... I'm just wondering, why does this=20 not apply to BIP327 also? (I guess in some general sense it does, but=20 maybe it was not interesting there for some reason? Is it just because=20 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 sug= gest one addition: in the Sign algo, you have "Index lookup and uni= queness check: Find the unique index j in 0..u-1 such tha= t pubnoncej[33:66] =3D cbytes(R2). Fail if no = such index exists or if more than one such index exists." (and then th= e pubkey and message check after). Perhaps add a footnote warning, as per t= he paper, that these 2 checks are *not* equivalent to checking that the tup= le (pubkey, message, R_2) is unique. I mean it's not technically needed= but seems like a very 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 putting that "tripwire" in the test vectors seem= s very advisable, though (I admit my check of your generated test vectors w= as 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 consensus change at all? Hmm, as I write thi= s ... I guess this is mirroring BIP340 vs BIP341? That the former just form= alizes 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 sc= heme, this will just (I guess?) have basically a new OP_CODE (or rather, re= definition) or similar?

About motivation:

>=C2=A0CISA with full-aggregation can even create an ec= onomic incentive for=20 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 = assume that this incentivization is real is a *little* misleading: CISA doe= s *not* incentivize batching payments in a way that creates privacy; it onl= y incentivizes consolidation and batching (amongst many spenders as well as= for one spender). What is undeniable is that *if* you're doing a coinj= oin of some 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 privac= y but more via second and third order effects than via first order. But, me= h, not simple :)

I'd also like to repeat a req= uest on the earlier 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 expl= icitly
>> 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, because I don't know if there is a written down "optimizatio= n for single signer" apart from what Jonas said there. If it doesn'= ;t exist, you can't put it in the BIP :) What I think would really be w= orth avoiding is : there's a folklore optimization for coding the use o= f DahLIAS in a single wallet that is not properly analyzed by the people he= re who know what they're talking about -- because, "minefield"= ; etc etc.

Cheers,
waxwing/AdamISZ
=

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

I would like to share a BIP draft for full-aggregation of BIP 3= 40
signatures, a standard for the DahLIAS interactiv= e aggregate signature
scheme by Jonas Nick, Tim Ruff= ing, and Yannick Seurin:

<= /div>
Full-aggregation allows a group of signers to produce a sin= gle 64-byte
signature for a list of public key and m= essage pairs in a two-round
signing protocol very si= milar to MuSig2/BIP327. The primary application
in B= itcoin would be CISA (cross-input signature aggregation).
=
The BIP draft text can be found here:
https://github.com/fjahr/bi= ps/blob/4b34e86d0040edad6cba3f7518b33472a11ebeaf/bip-XXXX.mediawiki

For inline comments, I have opene= d 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 &= 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/bitcoind= ev/dc07a3e4-0bc7-44fe-9136-1ece837747efn%40googlegroups.com.
------=_Part_377677_634924858.1783538044666-- ------=_Part_377676_375490975.1783538044666--