From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Jul 2026 17:14:01 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wpEPP-00017B-Tn for bitcoindev@gnusha.org; Wed, 29 Jul 2026 17:14:01 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-448bb8bd2efsf2959168fac.0 for ; Wed, 29 Jul 2026 17:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1785370434; x=1785975234; 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=WfnHIubDckpjbqgBU6eSDrJBSXkYBp4RDTvADXwYmrc=; b=wjQOfvsgXFeDo9Z4aCeBZ6RiSpmqecIC6D543kjtS1xExIajUOhW+Dg8obUiM+FrGT yKeMdV/tFScpmCd37IUk3a+7QK/B+zRlGBEITsTNhSlALEEASStSOzdjuMnwNvnuU+A2 oRiPl8q5B5shGRXhRgU85Pz2NBxDEwbmQ0cIrB4/c7OtaeKnOp1h/XH1pXMdMM4s0xUK LOXFc201+RX5L11DvpqKxnV0qF584jIkOtLVlK6lsWGmGR4SBQDFQX15nlVrkMzdpbLW Lng2zRsKx+bpD+Y5gq9dk7uKOFPrmkHU1ZrRobK3kbMSGYGpQYy5AVayeM/kLvSe0W8h ZyLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785370434; x=1785975234; 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=WfnHIubDckpjbqgBU6eSDrJBSXkYBp4RDTvADXwYmrc=; b=NFei+7gCawXUf0fkCRoWiLBqMeyp7JndNck/JTk7ejJjeSxaIl74zrjJShKD5D5Q1O l5ircWLBujURGpVMhUdloFOAJg9YAJfqmSdkdR2X2bs3Yg5f5+LXiTa6inbu977ABu0G 2iTXMSE1py7N016TkDgdkCLcE/It54NSKIK7ffDOBDuuKvzuszYFNvJGm7asJytpaYfk CI3YawOlyq9am/+c9jNQlAb9cVvzvqYJO2b3n7rIdh+Pac3l9ON4OSV/Pa/YPnV+ybnN BknCH39ni94hbmWMthIQS0W6xlq5DRhvnJLXjpMdgaZ3T/UKn5NYJGR7/IzrSHVZ/V4S CWNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785370434; x=1785975234; 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=WfnHIubDckpjbqgBU6eSDrJBSXkYBp4RDTvADXwYmrc=; b=UliAhFZogJX5fxXYqKqgkZC+64hXd7uHTl1EfDJg5EcrarZIW5VkEITNL+wToWDeQ4 5jcyh88hRq18cT+C1D1yqdHiux1SxU6/kOsgEAyHmxf/Ua+uJQaOHuKPF+lutQqtydAG 6DUrs9lLJYxgBoBOXKwOKhDEva23t9AnLd+lJCDcWRNa/fzYvIOagYE9OH2hO6CGdpsn f4wQJsuI9OEZzyK0TgGc0lYezjpxLFzrzzPR0XCBU1wM7QfZaFVBKWycLYTw4Zf3qSuf IoL4hAx7PAZknLOC0yJDT2s+fCNSBrxYDBU5SYyocuBi2MFJom8Kw2Bbn3E2JYPtd6U6 xrqg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+RqXPEUelWmhkH6wJJWHwXj34x+75jECxgGISP3S4JswzERfba+zuiDe5/7JFdEwIEGZaQTcOp44aE/5@gnusha.org X-Gm-Message-State: AOJu0Yw2jSyivgUUh7UihsX850PcK8DmvY4tR21760Lym2uI/3hOpfa6 ksFHIVBxbt/m1/PTgdwfOZiSlpuzkMkxhJ1SYN64xFmmwkHzTD/c+rl/ X-Received: by 2002:a05:6870:1685:b0:448:bf71:d13 with SMTP id 586e51a60fabf-458c11c7e32mr283322fac.27.1785370433734; Wed, 29 Jul 2026 17:13:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPSZJRgn2Uu7jmdLUHzVXQkg2Ob4/ZugmSVZ68QRVDhugw==" Received: by 2002:a05:6871:787:b0:456:5850:365e with SMTP id 586e51a60fabf-458b8cfc133ls169661fac.0.-pod-prod-04-us; Wed, 29 Jul 2026 17:13:48 -0700 (PDT) X-Received: by 2002:a05:6808:f14:b0:496:2b3:ae71 with SMTP id 5614622812f47-4ad8775789dmr355973b6e.18.1785370428689; Wed, 29 Jul 2026 17:13:48 -0700 (PDT) Received: by 2002:a05:690c:c04e:b0:81e:11b4:1172 with SMTP id 00721157ae682-81fb134ae24ms7b3; Wed, 29 Jul 2026 17:03:15 -0700 (PDT) X-Received: by 2002:a05:690c:6b85:b0:81e:ba92:b255 with SMTP id 00721157ae682-81fb8b5bb61mr2001127b3.68.1785369790323; Wed, 29 Jul 2026 17:03:10 -0700 (PDT) Date: Wed, 29 Jul 2026 17:03:09 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <0a59ffec-6960-4919-80a6-9ca45203d858n@googlegroups.com> In-Reply-To: <-xmuFTwytNGFB-4IxZbIsQ02dLSKDNXTtJr9AVPdIIII5kmIppZpYqYvGv4ZRgVkJpY4PJzAjzRJfSOrcT9utM-KDdCT-a_6XCy8d80K9e8=@protonmail.com> References: <74cecbeb-94d1-4181-9caa-3f60c54d6b08n@googlegroups.com> <-xmuFTwytNGFB-4IxZbIsQ02dLSKDNXTtJr9AVPdIIII5kmIppZpYqYvGv4ZRgVkJpY4PJzAjzRJfSOrcT9utM-KDdCT-a_6XCy8d80K9e8=@protonmail.com> Subject: Re: [bitcoindev] Re: BIP draft: CISA for Taproot Key Path Spends MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16798_922256193.1785369789976" 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.2 (/) ------=_Part_16798_922256193.1785369789976 Content-Type: multipart/alternative; boundary="----=_Part_16799_1139993572.1785369789976" ------=_Part_16799_1139993572.1785369789976 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > However, we could take the multi-full-agg-group concept to the next level and half-agg the full-agg signatures of the different groups for another round of savings (as well as additional complexity of course). Can I just check I understood you: you're saying do the half-agg trick as= =20 per BIP458 but with the DahLIAS signatures? It certainly *looks* like it=20 would generalize (multi scalar multiplication with randomizers) but I think= =20 it'd need some justification (a reduction, etc.)? I was confused because=20 you say this like it's a known thing; is it? I agree with your analysis; the biggest counterpoint being that you don't= =20 lose too much in simply broadcasting separate transactions. The use case=20 for coinjoin doesn't work, which would be the obvious objection=20 (fingerprinting), and other objections like 'we both want to dual fund a=20 lightning channel with a bunch of consolidated utxos' are too=20 artificial/obscure to be a big deal. In all this, I'm nodding to the fact= =20 that gains would be extremely minor for smaller groups of utxo (2-4 let's= =20 say). Given the extra complexity, not worth it. Cheers, waxwing/AdamISZ On Tuesday, July 28, 2026 at 2:25:13=E2=80=AFPM UTC-6 Fabian wrote: > Hi waxwing, > > Thanks again for sharing your feedback! The idea of > incrementing the marker byte with a group ID is clever > and I agree that it works technically. This triggered > me to spend some more time to think about what that > might look like which is fun but I am still not > fully convinced this is worth adding. > > > Say a bunch of people want maximally weight-minimising > > transaction (for their consolidation), but don't want to > > run a collaborative scheme between each other because > > it's technically hard to do safely (constrained > > hardware/software, nonce state handling, etc.). Each of > > them just want to full agg their 10 inputs, each. > > You may have already had this in mind but to make sure > we are on the same page: In this scenario the parties do > not become fully independent of each other. With sighash > default (or all) every signature commits to all outputs, > so all parties have to agree on the complete output list > of the transaction before anyone can sign. Only the > signing session itself is avoided. It is hard for me to > imagine a scenario where that kind of up-front > coordination is fine but the signing session isn't. It > would require some kind of communication and holding of > state as well. Please let me know if you think > differently here. I am not sure what your assumptions > are around up-front coordination capabilities. > > I also looked into decoupling the parties further but > it does not really work in my opinion. SINGLE with > ANYONECANPAY only fits parties with one input and one > output each, the consolidation example has no outputs that > the other 9 inputs could safely commit to. When this does > fit, it reveals which input pays which output, and since > nothing commits to the other groups, anyone can split the > merged transaction apart. The explicit sighash bytes > also cost one extra weight unit per input, while > separate transactions can omit the byte by using the > default. > > > Not saying it's some super-common-in-practice scenario, > > but it seems suboptimal that you can't do it. So ... I > > guess it depends on whether "the additional validation > > complexity" is really bad compared with the utility of > > that specific use case. > > The utility seems limited because of the minor additional > savings they gain from this. They can use half-aggregation > within the shared transaction, but probably better for a > scenario as you outline, each party just broadcasts its > own transaction with its own full-aggregation group. The > latter has about 10 vbytes of transaction overhead and > both alternatives lose all the coordination requirements. > > However, we could take the multi-full-agg-group concept > to the next level and half-agg the full-agg signatures > of the different groups for another round of savings (as > well as additional complexity of course). > > So, back of the envelope multi-full-agg-group steelman > calculation for your scenario: 10 participants each > consolidating 10 inputs into 1 output. > > Each in their own tx: > > 10 x input skeleton 1640 WU > 9 placeholders + 1 final (27 + 67) 94 WU > 1 output 172 WU > tx skeleton 42 WU > total 1948 WU (487 vb) > > All in one shared tx with half-agg on top: > > 10 x input skeleton 1640 WU > 9 placeholders + 1 R-only final (27 + 35) 62 WU > 1 output 172 WU > share of combined s (32 / 10) 3.2 WU > share of tx skeleton (42 / 10) 4.2 WU > total 1881 WU (470 vb) > > So this takes it up to 17 vbytes, or 3.4% savings per > participant/group. I didn't fully sketch this out but > I think it should be possible without introducing > additional overhead. > > I start to warm up to it because it's clever but I am > not sure if that is a good thing ;) > > > More specifically, though, why couldn't a 'group ID' be > > folded into the marker byte. > [...] > > Is this just out of consideration for some other reason > > that (hardly surprising) I'm not aware of? > > Yepp, this works just like you describe. The reason is > only that I do not see a real use case justifying it and > I even feel like the sighash constraints make reasonable > use-cases hard to imagine. > > > A negative (for privacy specifically) would be that you > > tag the different groups in the input list. > > Right, the group numbers would reveal which inputs > belong together. But for your consolidation scenario this > seems like a minor issue and it's not that different from > potential finger printing issues resulting from unique > mixing of different aggregation types in a transaction. > I already have some fingerprinting warnings in the BIP to > make people aware of this. > > > While that as a proposal may or may not be a good one, I > > feel like: this is worth mentioning at this time because > > (IIUC) it cannot be retrofitted in after. > > Yes, undefined marker values cannot become valid through > a soft fork, I thought about something like this early on > trying to find potential upgrade paths. But this doesn't > seem possible and it's good to have this conversation now. > > Thank you again for raising this. I have expanded the > rationale section in the BIP with my reasoning so > that the decision is better documented. I am also > still open to think about other potentially interesting > use-cases for the multi-group-full-agg feature or to > reconsider if you or other reviewers think we should rather > be maximimally flexible in this regard even without a clear > use-case. But unless there is interest being signalled > I will err on the side of simplicity. > > Best, > Fabian > On Wednesday, July 22nd, 2026 at 2:21 AM, waxwing/ AdamISZ < > ekag...@gmail.com> wrote: > > Hi Fabian, > > Thanks again for the draft. > > "A more flexible alternative with multiple aggregation groups per scheme,= =20 > similar to the bucket concept from early aggregation discussions, was=20 > rejected because no concrete use case justified the additional validation= =20 > complexity." > > Say a bunch of people want maximally weight-minimising transaction (for= =20 > their consolidation), but don't want to run a collaborative scheme betwee= n=20 > each other because it's technically hard to do safely (constrained=20 > hardware/software, nonce state handling, etc.). Each of them just want to= =20 > full agg their 10 inputs, each. > > Not saying it's some super-common-in-practice scenario, but it seems=20 > suboptimal that you can't do it. So ... I guess it depends on whether "th= e=20 > additional validation complexity" is really bad compared with the utility= =20 > of that specific use case. > > More specifically, though, why couldn't a 'group ID' be folded into the= =20 > marker byte. In your draft you say "The chosen values fall into the range= =20 > 0xbb to 0xfe, which is unassigned in legacy script and corresponds to=20 > OP_SUCCESS opcodes in tapscript, so they do not collide with opcodes=20 > commonly seen in scripts." - but there are a lot of values between 0xbd a= nd=20 > 0xfe. I guess this is not a case for bitflags, but just different markers= =20 > where you add a groupID to 0xbd (and with the understanding - this clearl= y=20 > is only relevant for fullagg, not halfagg). Is this just out of=20 > consideration for some other reason that (hardly surprising) I'm not awar= e=20 > of? > (I don't believe this suggestion changes anything functionally as=20 > described in the 'Common Signature Message' section; I mean it literally= =20 > changes the byte, but, functionally). > > A negative (for privacy specifically) would be that you tag the different= =20 > groups in the input list. > > While that as a proposal may or may not be a good one, I feel like: this= =20 > is worth mentioning at this time because (IIUC) it cannot be retrofitted = in=20 > after. > > Cheers, > AdamISZ/waxwing > > On Saturday, July 18, 2026 at 11:44:33=E2=80=AFAM UTC-3 Fabian wrote: > >> Hi list, >> >> I would like to share a BIP draft for transaction-wide cross-input >> signature aggregation (CISA). It introduces a new witness version, >> which enables Taproot-style key path spending where inputs can >> aggregate their signatures. >> >> Each input chooses between half-aggregation, full-aggregation, or an >> explicit opt-out via a marker byte in its witness. >> The aggregation schemes themselves are specified in the previously >> shared BIP 458 (half-aggregation) and BIP 459 (full-aggregation) >> drafts. Script path spending follows BIP 341/342 unchanged. >> >> The BIP draft text can be found here: >> >> https://github.com/fjahr/bips/blob/cf0d4f2142cd0504b16e86739167b1f7ab9a3= a06/bip-XXXX.mediawiki >> >> For inline comments, I have opened a mock pull request on my BIPs >> repo fork: >> https://github.com/fjahr/bips/pull/6 >> >> Feedback of any kind is much appreciated. >> >> Best, >> Fabian >> > --=20 > > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/74cecbeb-94d1-4181-9caa-3f60= c54d6b08n%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/= 0a59ffec-6960-4919-80a6-9ca45203d858n%40googlegroups.com. ------=_Part_16799_1139993572.1785369789976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0However, we could= take the multi-full-agg-group concept
to the next level and half-agg the full-agg signatures
of the different groups fo= r another round of savings (as
well as additional complexity of course).

Can I just check I understood you: you're saying do the half-agg= trick as per BIP458 but with the DahLIAS signatures? It certainly *looks* = like it would generalize (multi scalar multiplication with randomizers) but= I think it'd need some justification (a reduction, etc.)? I was confused b= ecause you say this like it's a known thing; is it?

I agree with your analysis; the biggest counterpoint being tha= t you don't lose too much in simply broadcasting separate transactions. The= use case for coinjoin doesn't work, which would be the obvious objection (= fingerprinting), and other objections like 'we both want to dual fund a lig= htning channel with a bunch of consolidated utxos' are too artificial/obscu= re to be a big deal. In all this, I'm nodding to the fact that gains would = be extremely minor for smaller groups of utxo (2-4 let's say). Given the ex= tra complexity, not worth it.

Cheers,
waxwing/Ada= mISZ

On Tuesday, July 28, 2026 at 2:25:13=E2=80=AFPM UTC-6 Fab= ian wrote:
Hi waxwing,<= /span>

Thanks again for sharing your feedback! The= idea of
incrementing the marker byte with a group I= D is clever
and I agree that it works technically. T= his triggered
me to spend some more time to think ab= out what that
might look like which is fun but I am = still not
fully convinced this is worth adding.

> Say a bunch of people want maximally weight-mi= nimising
> transaction (for their consolidation),= but don't want to
> run a collaborative sche= me between each other because
> it's technica= lly hard to do safely (constrained
> hardware/sof= tware, nonce state handling, etc.). Each of
> the= m just want to full agg their 10 inputs, each.

<= /div>
= You may have already had this in mind but to make sure
we are on the same page: In this scenario the parties do
not become fully independent of each other. With sighash
default (or all) every signature commits to all outputs,
so all parties have to agree on the complete output list<= /span>
of the transaction before anyone can sign. Only the<= /span>
signing session itself is avoided. It is hard for me= to
imagine a scenario where that kind of up-front
coordination is fine but the signing session isn'= t. It
would require some kind of communication and h= olding of
state as well. Please let me know if you t= hink
differently here. I am not sure what your assum= ptions
are around up-front coordination capabilities= .

I also looked into decoupling the p= arties further but
it does not really work in my opi= nion. SINGLE with
ANYONECANPAY only fits parties wit= h one input and one
output each, the consolidation e= xample has no outputs that
the other 9 inputs could = safely commit to. When this does
fit, it reveals whi= ch input pays which output, and since
nothing commit= s to the other groups, anyone can split the
merged t= ransaction apart. The explicit sighash bytes
also co= st one extra weight unit per input, while
separate t= ransactions can omit the byte by using the
default.<= /span>

> Not saying it's some super-common-in-p= ractice scenario,
> but it seems suboptimal that = you can't do it. So ... I
> guess it depends = on whether "the additional validation
> comp= lexity" is really bad compared with the utility of
> that specific use case.

The utility se= ems limited because of the minor additional
savings = they gain from this. They can use half-aggregation
w= ithin the shared transaction, but probably better for a
scenario as you outline, each party just broadcasts its
own transaction with its own full-aggregation group. The
latter has about 10 vbytes of transaction overhead and<= /div>
both alternatives lose all the coordination requirements.

However, we could take the multi-full-= agg-group concept
to the next level and half-agg the= full-agg signatures
of the different groups for ano= ther round of savings (as
well as additional complex= ity of course).

So, back of the envel= ope multi-full-agg-group steelman
calculation for yo= ur scenario: 10 participants each
consolidating 10 i= nputs into 1 output.

Each in their ow= n tx:

=C2=A0 10 x input skeleton =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01640 WU
=C2=A0 9 placeholders + 1 final (27 + = 67) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 94 WU
=C2=A0 = 1 output =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0172 WU
=C2=A0 tx skeleton =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A042 WU
=C2=A0 total =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1948 = WU (487 vb)

All in one shared tx with= half-agg on top:

=C2=A0 10 x input s= keleton =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A01640 WU
=C2=A0 9 placeholders + 1 R= -only final (27 + 35) =C2=A0 =C2=A062 WU
=C2=A0 1 ou= tput =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0172 WU
<= div>=C2=A0 share of combined s (32 / 10) =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 3.2 WU
=C2=A0 share of tx skele= ton (42 / 10) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04.2 WU=
=C2=A0 total =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1881 WU (470 vb)

So this takes it up to 17 vbytes, or 3.4% = savings per
participant/group. I didn't fully sk= etch this out but
I think it should be possible with= out introducing
additional overhead.

I start to warm up to it because it's clever but= I am
not sure if that is a good thing ;)
> More specifically, though, why couldn't a 'g= roup ID' be
> folded into the marker byte.
=
[...]
> Is this just out of consideration for so= me other reason
> that (hardly surprising) I'= m not aware of?

Yepp, this works just like you = describe. The reason is
only that I do not see a rea= l use case justifying it and
I even feel like the si= ghash constraints make reasonable
use-cases hard to = imagine.

> A negative (for privacy specifica= lly) would be that you
> tag the different groups= in the input list.

Right, the group numbers wo= uld reveal which inputs
belong together. But for you= r consolidation scenario this
seems like a minor iss= ue and it's not that different from
potential fi= nger printing issues resulting from unique
mixing of= different aggregation types in a transaction.
I alr= eady have some fingerprinting warnings in the BIP to
make people aware of this.

> While that as = a proposal may or may not be a good one, I
> feel= like: this is worth mentioning at this time because
> (IIUC) it cannot be retrofitted in after.

=
Yes, undefined marker values cannot become valid through
= a soft fork, I thought about something like this early on
trying to find potential upgrade paths. But this doesn't
seem possible and it's good to have this conversat= ion now.

Thank you again for raising = this. I have expanded the
rationale section in the B= IP with my reasoning so
that the decision is better = documented. I am also
still open to think about othe= r potentially interesting
use-cases for the multi-gr= oup-full-agg feature or to
reconsider if you or othe= r reviewers think we should rather
be=C2=A0ma= ximimally flexible in this regard even without a clear
use-= case. But unless there is interest being signalled
I will e= rr on the side of simplicity.

Bes= t,
Fabian
On Wednesday, July 22nd, 2026 at 2:21 AM, waxwing/ AdamISZ <ekag...@gmail.com> wrote:
Hi Fabian,

Thanks again for the d= raft.

"A more flexible alternative with multi= ple aggregation groups per scheme, similar to the bucket concept from early aggregation discussions, was rejected because no concrete use case justified the additional validation complexity."

Say a bunch of peopl= e want maximally weight-minimising transaction (for their consolidation), b= ut don't want to run a collaborative scheme between each other because = it's technically hard to do safely (constrained hardware/software, nonc= e state handling, etc.). Each of them just want to full agg their 10 inputs= , each.

Not saying it's some super-common-in-p= ractice scenario, but it seems suboptimal that you can't do it. So ... = I guess it depends on whether "the additional validation complexity&qu= ot; is really bad compared with the utility of that specific use case.

More specifically, though, why couldn't a 'gro= up ID' be folded into the marker byte. In your draft you say "The= chosen values fall into the range 0xbb to 0xfe, = which is unassigned in legacy script and corresponds to OP_SUCCESS opcodes in tapscript, so they do not collide with opcodes commonly see= n in scripts." - but there are a lot of values between 0xbd and 0xfe. = I guess this is not a case for bitflags, but just different markers where = you add a groupID to 0xbd (and with the understanding - this clearly is onl= y relevant for fullagg, not halfagg). Is this just out of consideration for= some other reason that (hardly surprising) I'm not aware of?
(I don't believe this suggestion changes anything functionally as desc= ribed in the 'Common Signature Message' section; I mean it literall= y changes the byte, but, functionally).

A negative= (for privacy specifically) would be that you tag the different groups in t= he input list.

While that as a proposal may or may= not be a good one, I feel like: this is worth mentioning at this time beca= use (IIUC) it cannot be retrofitted in after.

Chee= rs,
AdamISZ/waxwing

On Saturday, July 18, 2026 at 11:4= 4:33=E2=80=AFAM UTC-3 Fabian wrote:
Hi list,

= I would like to share a BIP draft for transaction-wide cross-input
signature aggregat= ion (CISA). It introduces a new <= /span>witness version,
which enables Taproot-style key path spending where inputs can
aggregate their signatures.

= Each input chooses between half-aggregation, full-aggregation, or an=
explicit opt-out via a marker byte in its witness.
The aggregation s= chemes themselves are specified in the previously
sh= ared BIP 458 (half-aggregation) and BIP 459 (full-aggregation)
=
drafts. Script path spending follows BIP 341/342 unchanged.

The BIP draft text can be found here:

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

<= div>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 bitcoindev+...@googlegroups.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/bitcoind= ev/0a59ffec-6960-4919-80a6-9ca45203d858n%40googlegroups.com.
------=_Part_16799_1139993572.1785369789976-- ------=_Part_16798_922256193.1785369789976--