[bitcoindev] BIP draft: Full-Aggregation of BIP 340 Signatures

[bitcoindev] BIP draft: Full-Aggregation of BIP 340 Signatures

['Fabian' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

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/4b34e86d0040edad6cba3f7518b33472a11ebeaf/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/bitcoindev/75t3ixAqup9wRTr9PyKDXNBQHHN3MnIMiDBHKhrzo_B9gGUH0gsa8Ni8tXrjDdhWf2UDsL7Jh3iRsCQ0A7fLU0NhttxFsaqQBi17zU89iYQ%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 2723 bytes --]

[bitcoindev] Re: BIP draft: Full-Aggregation of BIP 340 Signatures

[waxwing/ AdamISZ]

[-- Attachment #1.1: Type: text/plain, Size: 5034 bytes --]

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] 
= 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 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 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 
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 BIP 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_CODE (or rather, 
redefinition) or similar?

About motivation:

> CISA with full-aggregation 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 assume 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 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, 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 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 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 := r*G and then set s := 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 "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 
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 -- because, 
"minefield" 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 PM 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/4b34e86d0040edad6cba3f7518b33472a11ebeaf/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/bitcoindev/2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 7371 bytes --]

[bitcoindev] Re: BIP draft: Full-Aggregation of BIP 340 Signatures

[waxwing/ AdamISZ]

[-- Attachment #1.1: Type: text/plain, Size: 7876 bytes --]

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 paragraph in, but, it's not worth much; you already 
have a description that covers most everything I mention here:

Security argument: 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/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 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 PM 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 
> uniqueness check*: Find the unique index *j* in *0..u-1* such that *pubnoncej[33:66] 
> = 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 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 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 
> 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 BIP 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_CODE (or rather, 
> redefinition) or similar?
>
> About motivation:
>
> > CISA with full-aggregation 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 assume 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 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, 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 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 
> 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 := r*G and then set s := 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 "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 
> 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 -- because, 
> "minefield" 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 PM 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/4b34e86d0040edad6cba3f7518b33472a11ebeaf/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/bitcoindev/dc07a3e4-0bc7-44fe-9136-1ece837747efn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 11008 bytes --]

Re: [bitcoindev] Re: BIP draft: Full-Aggregation of BIP 340 Signatures

['Fabian' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 10627 bytes --]

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/a68f47ab34ff956d575b7a779761f1a35767476e

> 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 you
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#deterministic-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 <ekaggata@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 paragraph in, but, it's not worth much; you already have a description that covers most everything I mention here:
>
> Security argument: 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/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 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 PM 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 uniqueness check: Find the unique index j in 0..u-1 such that pubnoncej[33:66] = 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 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 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 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 BIP 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_CODE (or rather, redefinition) or similar?
>>
>> About motivation:
>>
>>> CISA with full-aggregation 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 assume 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 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, 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 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 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 := r*G and then set s := 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 "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 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 -- because, "minefield" 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 PM 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/4b34e86d0040edad6cba3f7518b33472a11ebeaf/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/bitcoindev/dc07a3e4-0bc7-44fe-9136-1ece837747efn%40googlegroups.com.

-- 
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/bitcoindev/tSYH-B4F91BsIzpl_FqPIhxO2xkoDmzbqz097XD41wJGmeHM7Cbt5JP0uqic9aicjM7Hhhr5F_4WEORFyHKYHowqemy0yeVr9p_vnaQhYYM%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 15943 bytes --]

Re: [bitcoindev] Re: BIP draft: Full-Aggregation of BIP 340 Signatures

['Fabian' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 8046 bytes --]

(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/fe13eb6bda6e40bb47207dff9a74ddfdf305ebe5

> 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 <ekaggata@gmail.com> 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] = 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 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 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 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 BIP 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_CODE (or rather, redefinition) or similar?
>
> About motivation:
>
>> CISA with full-aggregation 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 assume 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 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, 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 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 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 := r*G and then set s := 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 "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 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 -- because, "minefield" 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 PM 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/4b34e86d0040edad6cba3f7518b33472a11ebeaf/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/bitcoindev/2d582d3b-46b1-4ba4-b7fc-b223e9e26f88n%40googlegroups.com.

-- 
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/bitcoindev/aWoAH3lQNC7QB9mtzNmgfyQObhMjux-Xm73KO4KD75filNkLZcDgeH6lnXI-6uyhGC7iR0OQCbUrEuUjQXxp7QuIOaEWMHaXGWvAOSpqX-Y%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 12706 bytes --]