From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 07 Jul 2026 12:49:47 -0700 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1whBne-000798-8I for bitcoindev@gnusha.org; Tue, 07 Jul 2026 12:49:46 -0700 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-6a153a05578sf5871621eaf.0 for ; Tue, 07 Jul 2026 12:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1783453780; x=1784058580; 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=Gn2ORs+CS7i++JtHXXwWQOaZPphHRfsiehh8zzyfHAM=; b=RSoVYY3Jd32KWxpbEgDAC+o0C2a8E4ijbReMzNblKRXXN/9vwNombJY5zAJaNzE8/d DaJmNEVBz1tzd9oUxjWIPuiNPvBVeC+TfPFrth7lN8CiUGPNYg5tSXbELO/oY0Wm6ekh aPFnJlwP3w7KyHt54eIo7T77t1HX+tqFfx8o05936452nk4wtHqB4c9ISWOR9EFIOcgp UMZXAqOUSemVT9OvDYMGc/OLntvSvUzvwuJX2x6Jy8oylvKYudBbBwK7K1DqpKzXNJ4L PqjkBPhDE3a1qumHh2iJ4EIBB0+janTIB0XFoen25x9C4n4JsDCKBc5W4TEKpdWzU4of hZBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783453780; x=1784058580; 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=Gn2ORs+CS7i++JtHXXwWQOaZPphHRfsiehh8zzyfHAM=; b=dRX9fuerz5FFeS4j+OpcRLLDBLt93txqaHUGKuzVc3oiV+KeR21oY1DeuoW3H+1ivN peno70zYqNXrSRpVB/r4+wbSEQZt0qBmgTx6fW9CnHs8/d5R/1GXeixee5fEPtjMIg3J qy6Ug9I+ej6zxzsmoOYK/1BbiB3BZkyryzuEf5NaeJRWHZ0vQ3VaAGDeKgqf69evaerc CX8j8watjXwORqfjLHZrHK+wEUfgpiqEWqDIzY0Cy4dgNeWVemUakOLodFJWJICNDo0X M0JIzV7gHKjWAjee8Uvg/JtF/WZKB8kcUi/RniFByg4MGjXtT8a5+lHzodCepR5xBPVo tQPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783453780; x=1784058580; 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=Gn2ORs+CS7i++JtHXXwWQOaZPphHRfsiehh8zzyfHAM=; b=mPLuOXVub2knqgZPxL4+ZKVpimKTR/FKdt1cAMnIAX2+GsMWQ5JqYWIjbmNPeIz9pI LkZCgLt2a1BDn9gwzPwJgZZHMUamEDRjqU/Zn7cipS+4kYohM1l1MTnOEkhoB+uQsUaD 5nJojK0yOkjfDTPui6I7tZetfFgCicO4Ny+SPKzYSV+NMYqMbvJ1Ixq+cYRS465v//pc HVE/MLmlmYd179oTqc7Ao8rhp2QQSqsEqNx0wweBCzmfEaTZMDgGc+982iUWe5qfYFzx TF7bqSjNCIaFGIRp44CS3KcNJ1kHURGubvs3X7TGZ6h2NN/YK7uDzu9II+m5wSCQliPo SEyA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9H1W2etOjCbZlS+VclMDdgMRdTxqqJGbsj0T3vqcKIBVkSkQe8jwgjyopWKsB0hYz/QYDkMmy266FN@gnusha.org X-Gm-Message-State: AOJu0YzdkWsLbikdSbdrlVTk4iMtFOGoNZu4mblvG6Yj9A9U621lP14R 48tsh+jgWfo1Vyz+we/v3Bqn5qoew827inoppdsT23OP1FO4t0O8qua1 X-Received: by 2002:a05:6820:2009:b0:6a3:1c46:c75f with SMTP id 006d021491bc7-6a35534485amr4439535eaf.1.1783453779584; Tue, 07 Jul 2026 12:49:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdiuBuWIeaVRq+apxqFUZ3DlIV3bcVPWRDW/wwndnchJA==" Received: by 2002:a05:6820:f006:b0:6a1:33c1:af25 with SMTP id 006d021491bc7-6a36a699449ls124803eaf.1.-pod-prod-07-us; Tue, 07 Jul 2026 12:49:35 -0700 (PDT) X-Received: by 2002:a05:6808:5384:b0:496:a36:b5e5 with SMTP id 5614622812f47-49fdcb879e1mr4738958b6e.17.1783453774989; Tue, 07 Jul 2026 12:49:34 -0700 (PDT) Received: by 2002:a05:690c:6e10:b0:809:cfd1:4c3a with SMTP id 00721157ae682-81d765785eams7b3; Tue, 7 Jul 2026 12:14:17 -0700 (PDT) X-Received: by 2002:a05:690c:67c4:b0:814:4ac5:cc51 with SMTP id 00721157ae682-81bddc89f4emr55229977b3.0.1783451655104; Tue, 07 Jul 2026 12:14:15 -0700 (PDT) Date: Tue, 7 Jul 2026 12:14:14 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n@googlegroups.com> In-Reply-To: <75t3ixAqup9wRTr9PyKDXNBQHHN3MnIMiDBHKhrzo_B9gGUH0gsa8Ni8tXrjDdhWf2UDsL7Jh3iRsCQ0A7fLU0NhttxFsaqQBi17zU89iYQ=@protonmail.com> References: <75t3ixAqup9wRTr9PyKDXNBQHHN3MnIMiDBHKhrzo_B9gGUH0gsa8Ni8tXrjDdhWf2UDsL7Jh3iRsCQ0A7fLU0NhttxFsaqQBi17zU89iYQ=@protonmail.com> Subject: [bitcoindev] Re: BIP draft: Full-Aggregation of BIP 340 Signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_484820_1185138175.1783451654687" 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_484820_1185138175.1783451654687 Content-Type: multipart/alternative; boundary="----=_Part_484821_1466673354.1783451654687" ------=_Part_484821_1466673354.1783451654687 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 *pubnonc= ej[33:66]=20 =3D cbytes(R2)*. Fail if no such index exists or if more than one such inde= x=20 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 as= =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 think= =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 that= =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 specifies= =20 the latter? It is a bit different though; taproot was a whole new scripting= =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 mailing= =20 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 >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 there= =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 -- because,= =20 "minefield" etc etc. Cheers, waxwing/AdamISZ [1] https://groups.google.com/g/bitcoindev/c/eothFkxAvK0/m/gfGZ8NxXEQAJ and= =20 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/4b34e86d0040edad6cba3f7518b33472a11ebe= af/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/= 2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n%40googlegroups.com. ------=_Part_484821_1466673354.1783451654687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabian,

Great! Thanks for the progress o= n this.

Can I suggest one addition: in the Sign = algo, you have "Index lookup and uniqueness check: Find the unique i= ndex j in 0..u-1 such that pubnoncej[33:66] =3D= cbytes(R2). Fail if no such index exists or if more than on= e such index exists." (and then the pubkey and message check after). Perhap= s add a footnote warning, as per the paper, that these 2 checks are *not* e= quivalent to checking that the tuple (pubkey, message, R_2) is unique. I me= an it's not technically needed but seems like a very good idea, since as pe= r the paper there is an attack there, and it would not be an unanticipatabl= e implementation footgun.

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

Second point goes from the ultra-specific to the ult= ra-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 this ... I guess this is mirroring BIP340 vs BIP341? That the = former just formalizes the exact algo of the signature scheme and a later B= IP specifies the latter? It is a bit different though; taproot was a whole = new scripting scheme, this will just (I guess?) have basically a new OP_COD= E (or rather, redefinition) or similar?

About mo= tivation:

>=C2=A0CISA with full-aggregation c= an even create an economic incentive for=20 privacy since using CoinJoin and PayJoin transactions can become cheaper than sending individual transactions.

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

I'd also like to repeat a request 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 explicitly
>> write down ways in which the usage of the scheme/structure c= an, 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 key= s 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, be= cause I don't know if there is a written down "optimization for single sign= er" 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 worth avoiding is : there's a f= olklore 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 a= bout -- because, "minefield" etc etc.

Cheers,
waxwing/AdamISZ

[1]=C2=A0https://groups.= google.com/g/bitcoindev/c/eothFkxAvK0/m/gfGZ8NxXEQAJ and surrounding conver= sation
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 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/2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n%40googlegroups.com.
------=_Part_484821_1466673354.1783451654687-- ------=_Part_484820_1185138175.1783451654687--