From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Jul 2026 07:29:32 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1whpko-0007gZ-Tq for bitcoindev@gnusha.org; Thu, 09 Jul 2026 07:29:31 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-6a37ba82959sf164773eaf.1 for ; Thu, 09 Jul 2026 07:29:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1783607365; cv=pass; d=google.com; s=arc-20260327; b=IpgSq6BfUvJ1eGZApgOqlLrdb5PfNiLEem9RZybKts5Rs5f8SXO/WYwH3/4TsmKEkY lK8WvsaJLKXsrXdQt8vIROOp5NpeLslQdRtfhhRz9O9calk/ASDlgn8zkV+LdO/ATmg+ Qg4clQ4xVEy/CB9iTu1gHi45imgqTvmb0Z85IHAwXsQPl5e7z31Cj3VSaGoXzsvD6o9S PmMHQaYNRB+TIBkqdbm7zmE3OFJyzq3HeSEcC2WIDvrP3Rl5Lx+5+42WI9OV2KkmkO6Y 3ONLjn3nNxzPuuNWFzOCMVvhLSxXGWd/4Mjq/z5GUa5bB2u9jAJVzXh5b7FuEj9y0UJY z/TQ== 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=Oacu6Z3h+0pwwlAm37HvQEtoCPOJICCOYtmh3n0aIDQ=; fh=GcUseIElNGNM7iM6Ag4BV3vvG9Ibn/ywLSOQW+wAsNI=; b=mFciz43u2y6kRE7ZKc9z1YloUmD0EQLc7d/NO2An6vLVgbB3U46xn+pO9/x9cSrAhf pssxUcJkMquQsZ456NEORXLQvgALvniquYAAGBeEqTCG8hzIfYJohyB8CH2lo2AxtMRw trNR24wigsMU+naSaVMEh2BG/+I2V6ZjjafMPCInphPNnhmM3uAO3d1FKoBfbbyLhadv 8IJWjsK3C+4UMhZpR7VTMrKRev5mfA0MpF4XoyrrbtimY5n+dMd+yC+YW+Aydt6+rvlF OqKli3SNRZQfHIYxMaEPq9fy7hGsuuzf5nSAMQuSMB6szPBfzUb6T4OmJz0kN5iYJw+/ JO5g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=nCcSaJub; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 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=1783607365; x=1784212165; 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=Oacu6Z3h+0pwwlAm37HvQEtoCPOJICCOYtmh3n0aIDQ=; b=TpD2IJyFlvwCQ0JNyjuZvmpTDJKwcdz4qe0R4v0OJ7JroZXiLyUxYTiqsPfTcAYru5 2QzG0TiOZKLKsxr1IEBwSMfVu0j4qQoNalYT7A5RuLq6vuRnOp97d2ybuSiqvdYErScZ SGWpnhJ8vFo3xnshvJdRUAKB1zSV2TcF7jNzGvCWv8DsIW1qXbCU1USELcH6kVfBFLsB ex2qQguMKlPKSWfdCR8+qRH1cMRTUfOxETeZIRbaIfJw/hGKezAOzIlUUopPndFktHnW HfisGGx0bJYHiQzNUn8rrOdicHKnskskShky2l1BtMFGIXSASF5AD3BHmel2GTUwifqJ k97Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783607365; x=1784212165; 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=Oacu6Z3h+0pwwlAm37HvQEtoCPOJICCOYtmh3n0aIDQ=; b=QJBgkrXSZsNg+V492Ay+y7eykwVbzQ41LC6shSlyYBcDe1nJXneyiOP3oP+sNjVUiK /ZEK1PbaRRXXKVZCagFz6KHdERPBilbTXoY59PZ0prHlWFiQmTaGBFPQTF3oVclty0uc QkpKHSCjO7f5OTFRyo+CnjYpFEq7yTIOVZz3glRTFVHytYgAYH2PNijdVeAplc8N7c0v kTSzfijXwVnE2DgijUO/qWu3/YT2Bt2RHZhS8hqagkYuZ7ktBoq4mJz+Ag73hmU3gm9m cdRXDmKXF7cqyBl9sluvPcIqNBUnRDAUMXCJB4O+pVsY7f7lgoCG6WsznNK4xPdtAjDn 0ICw== X-Forwarded-Encrypted: i=2; AFNElJ8QhUZF/lAUmo7+EdiyfCD6fNerBa+XMU6OWSTgUU+maFcKEyy1zZMRsm2CSvuuVQ+PlWlxWfJTPcuS@gnusha.org X-Gm-Message-State: AOJu0YyidofS8SOwBPijkNpHmyj8XZzlkqlTJ7y3rza/pFoU5t5fknDx IA1c15nksePBx4MUpWHh/MandAQ4xBj83ZVnVMe3WS0c+vBDAdi1OD/+ X-Received: by 2002:a05:6820:1519:b0:6a3:2b61:61b4 with SMTP id 006d021491bc7-6a36da3e06amr5404415eaf.56.1783607364323; Thu, 09 Jul 2026 07:29:24 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUchzJv6jsuzA0LJjRM895FLuDEb6pybF09sYXLXWxkP5w==" Received: by 2002:a05:6820:81c9:b0:6a1:33f8:11fc with SMTP id 006d021491bc7-6a36a78acb1ls1160590eaf.2.-pod-prod-06-us; Thu, 09 Jul 2026 07:29:19 -0700 (PDT) X-Received: by 2002:a05:6808:250f:b0:491:bee4:d722 with SMTP id 5614622812f47-4a203fc8701mr5882247b6e.23.1783607359285; Thu, 09 Jul 2026 07:29:19 -0700 (PDT) Received: by 2002:a05:6809:14:10b0:495:f457:d35e with SMTP id 5614622812f47-4a1afff0712msb6e; Thu, 9 Jul 2026 05:57:40 -0700 (PDT) X-Received: by 2002:a17:90b:314c:b0:37e:1609:b304 with SMTP id 98e67ed59e1d1-3894014c5d9mr6074778a91.1.1783601858900; Thu, 09 Jul 2026 05:57:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783601858; cv=none; d=google.com; s=arc-20260327; b=j0vm5zdw6rh1s2rX5j6Rv/0Lidg29/K7aHxEdhTzSU3GVlYMWUDabKj5NtPE/da08+ G9Fu4g/xRmUwGlGiH9m1mJxZAX4BxXM2NTj0wbbokuzs3JtHAu6J7rLyqcSCYhBSStph rXZss+2gMu4rXbCog4JYMxUxnQzT3wJ7kBxDt8RpeD1xco+K12afy1HWveFmSAdLOARV O+kgE/SgqiMnWEpO6O6FNufGZk4dGhoQrVWlH/UVLiTvyNYBk5tlYY8CfiQUkbgRGJWO OsFLkpBYHdfC4O0dr1GBqfipbms1ZttGGyNONpAe3rKCg876lMfb559JUZ+vIVcKi/z4 WIgQ== 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=oDtcN0o4AiHAUceh7uPmE7/finkq613y8pNoBndV5mo=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=LgpDfFWpREPo2OaMPJ//bDh3zq2/4SybeG+2HLWaDwExVBgTPTPOzl6LBdEj3x7bSq jg5VD2BmV7MKfydOK7ZyG2gzFhy5MvETQO/dUW2Kg4n8zOSL3HiP3UUpsLNvUpHCBKKu 5D6ABGOHOqMy6AM5aK3ZbE63bSIQK9rfeGy34RochkxZ1Hs/M343W1Y77D6+HIwDLFOH 2ohnNjpt1UgIrB8mmH1dw5urxYT0wx3qH9h0dXeoZ4HlXCNX3iuFuaPwo0ZFfgVV6dYY tGzAhKotfKz9u+jXmYhf4F/UhcSQkSLkL5O0blwJQU3cApmPFzeIUdsE0eYYjN1ZKouu RG4w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=nCcSaJub; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-244123.protonmail.ch (mail-244123.protonmail.ch. [109.224.244.123]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-388fd7ab36bsi138152a91.1.2026.07.09.05.57.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 05:57:38 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 as permitted sender) client-ip=109.224.244.123; Date: Thu, 09 Jul 2026 12:57:31 +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: <2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n@googlegroups.com> References: <75t3ixAqup9wRTr9PyKDXNBQHHN3MnIMiDBHKhrzo_B9gGUH0gsa8Ni8tXrjDdhWf2UDsL7Jh3iRsCQ0A7fLU0NhttxFsaqQBi17zU89iYQ=@protonmail.com> <2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n@googlegroups.com> Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 8a2e292412f57fd05cbbad655abfc7dd76da93d9 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_GbUwCtqw9TTd6JwYfnaH1WP84iP60wJQasCehles" 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=nCcSaJub; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 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=_GbUwCtqw9TTd6JwYfnaH1WP84iP60wJQasCehles Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (I addressed your comments before I had seen your second message, I will reply to it separately) Hi waxwing, Thanks a lot for taking a look! I have pushed a new commit addressing your comments to the branch: https://github.com/fjahr/bips/pull/4/commits/fe13eb6bda6e40bb47207dff9a74dd= fdf305ebe5 > Perhaps add a footnote warning, as per the paper, that these 2 checks > are *not* equivalent to checking that the tuple (pubkey, message, R_2) > is unique. Sounds good to me. I have added such a footnote and point to the section 4.2 of the paper for the attack explicitly. > putting 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?) Right, these cases were not covered yet. I have added more test vectors for Sign that should exercise the checks that were not covered yet. > it seems a little strange to have a BIP that specifies the algo but > not the consensus change at all? ... I guess this is mirroring BIP340 > vs BIP341? Exactly, the split is intentional and mirrors BIP 340. Full-aggregation (just like half-aggregation) is useful independently of how CISA could be deployed and there are potentially several possible designs for the consensus side that may be considered side by side. So I would like to leave that to a separate proposal which I plan to publish soon as well. But I have added a bit more to the motivation section to make this more clear. > I think the tendency to assume that this incentivization is real is a > *little* misleading I guess that's a fair point. I have reworded the sentence slightly to say that full-aggregation can reduce the cost of privacy rather than it creates an incentive for it. I hope you agree that's fair then. > What I think 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 Right, since there is no full analysis of this yet, the BIP cannot specify = it as an optimization. To avoid the folklore scenario I have added a note to the rationale section that states that a single party can simply run the protocol locally. I am referencing Jonas' message from the ML and add that it would need additional security analysis. If someone works on an analysis, I would be happy to incorporate it. Best,Fabian On Tuesday, July 7th, 2026 at 9:49 PM, 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 = 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 i= ndex exists." (and then the pubkey and message check after). Perhaps add a = footnote warning, as per the paper, that these 2 checks are *not* equivalen= t 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 pa= per there is an attack there, and it would not be an unanticipatable implem= entation footgun. > > You have the checks in the reference.py implementation, obviously; but pu= tting that "tripwire" in the test vectors seems very advisable, though (I a= dmit my check of your generated test vectors was not thorough but I think i= t's not there yet?) > > Second point goes from the ultra-specific to the ultra-general: I'm proba= bly being dumb here, but it seems a little strange to have a BIP that speci= fies 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 formalize= s the exact algo of the signature scheme and a later BIP specifies the latt= er? 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, redefin= ition) or similar? > > About motivation: > >> CISA with full-aggregation can even create an economic incentive for pri= vacy 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 ten= dency to assume that this incentivization is real is a *little* misleading:= CISA does *not* incentivize batching payments in a way that creates privac= y; it only incentivizes consolidation and batching (amongst many spenders a= s 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, do= n't take this as a big criticism particularly, because *whatever* you write= here will be arguable. My personal intuition is that CISA *does* aid priva= cy but more via second and third order effects than via first order. But, m= eh, not simple :) > > I'd also like to repeat a request on the earlier discussion on this maili= ng 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 explic= itly >>> write down ways in which the usage of the scheme/structure can, and can= not, >>> 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 ther= e 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 thin= k would really be worth avoiding is : there's a folklore optimization for c= oding the use of DahLIAS in a single wallet that is not properly analyzed b= y the people here who know what they're talking about -- because, "minefiel= d" etc etc. > > Cheers, > waxwing/AdamISZ > > [1] https://groups.google.com/g/bitcoindev/c/eothFkxAvK0/m/gfGZ8NxXEQAJ a= nd 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 f= ork: >> 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/2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n%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/= aWoAH3lQNC7QB9mtzNmgfyQObhMjux-Xm73KO4KD75filNkLZcDgeH6lnXI-6uyhGC7iR0OQCbU= rEuUjQXxp7QuIOaEWMHaXGWvAOSpqX-Y%3D%40protonmail.com. --b1=_GbUwCtqw9TTd6JwYfnaH1WP84iP60wJQasCehles Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(I ad= dressed your comments before I had seen your second message,
I will r= eply to it separately)

Hi waxwing,

Thanks a lot for taking a look!
I have pushed a new commit addressing your comments to th= e branch:
> Perhaps add a footnote warning, as per the paper, th= at these 2 checks
> are *not* equivalent to check= ing that the tuple (pubkey, message, R_2)
> is un= ique.

Sounds good to me. I have added= such a footnote and point to the
section 4.2 of the= paper for the attack explicitly.

>= ; putting that "tripwire" in the test vectors seems very advisable,<= /div>
> though (I admit my check of your generated test vector= s was not
> thorough but I think it's not there y= et?)

Right, these cases were not cove= red yet. I have added more test vectors
for Sign tha= t should exercise the checks that were not covered yet.
> it seems a little strange to have a BIP that specif= ies the algo but
> not the consensus change at al= l? ... I guess this is mirroring BIP340
> vs BIP3= 41?

Exactly, the split is intentional= and mirrors BIP 340. Full-aggregation
(just like ha= lf-aggregation) is useful independently of how CISA could be
deployed and there are potentially several possible designs for th= e
consensus side that may be considered side by side= . So I would like to
leave that to a separate propos= al which I plan to publish soon as
well. But I have = added a bit more to the motivation section to
make t= his more clear.

> I think the tend= ency to assume that this incentivization is real is a
> *little* misleading

I guess th= at's a fair point. I have reworded the sentence slightly to
say that full-aggregation can reduce the cost of privacy rather tha= n
it creates an incentive for it. I hope you agree t= hat's fair then.

> What I think wo= uld 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 k= now what they're talking
> about

Right, since there is no full analysis of this yet, t= he BIP cannot specify it as
an optimizat= ion. To avoid the folklore scenario I have added a
note to = the rationale section that states that a single party
can simply run the protocol locally. I am referencing Jonas' message
from the ML and add that it would need additional securi= ty analysis. If
someone works on an analysis, I would be h= appy to incorporate it.

Best,
Fabian
On Tuesday, July 7th, 2026 at 9:49 PM, waxwing/ AdamISZ <ekaggat= a@gmail.com> wrote:
Hi Fabian,

Great! Thanks for the = progress on this.

Can I suggest one addition: in t= he 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* equivalent to checking that the tuple (pubkey, message, R_2) is uniq= ue. I mean it's not technically needed but seems like a very good idea, sin= ce as per the paper there is an attack there, and it would not be an unanti= cipatable implementation footgun.

You have the che= cks in the reference.py implementation, obviously; but putting that "tripwi= re" in the test vectors seems very advisable, though (I admit my check of y= our 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 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 lat= er BIP specifies the latter? It is a bit different though; taproot was a wh= ole new scripting scheme, this will just (I guess?) have basically a new OP= _CODE (or rather, redefinition) or similar?

About = motivation:

> CISA with full-aggregation can ev= en 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-aggregat= ion of BIP 340
signatures, a standard for the DahLIA= S interactive aggregate signature
scheme by Jonas Ni= ck, Tim Ruffing, and Yannick Seurin:

Full-aggregatio= n 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 pri= mary application
in Bitcoin would be CISA (cross-inp= ut signature aggregation).

The BIP dr= aft text can be found here:

For inline comments, I have op= ened a mock pull request on my BIPs repo fork:

Feedback of any kind is much apprec= iated.

Best,
Fabian<= /div>

--
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/2d582d3b-46b1-4ba4-b7f= c-b223e9e26f88n%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/= aWoAH3lQNC7QB9mtzNmgfyQObhMjux-Xm73KO4KD75filNkLZcDgeH6lnXI-6uyhGC7iR0OQCbU= rEuUjQXxp7QuIOaEWMHaXGWvAOSpqX-Y%3D%40protonmail.com.
--b1=_GbUwCtqw9TTd6JwYfnaH1WP84iP60wJQasCehles--