Hi Fabian,
Thanks again for the draft.
"A more flexible alternative with multiple 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 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.
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.
More specifically, though, why couldn't a 'group 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 seen 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 only 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 described in the 'Common Signature Message' section; I mean it literally changes the byte, but, functionally).
A negative (for privacy specifically) would be that you tag the different groups in the 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 because (IIUC) it cannot be retrofitted in after.
Cheers,
AdamISZ/waxwing
On Saturday, July 18, 2026 at 11:44:33 AM 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:
For inline comments, I have opened a mock pull request on my BIPs
repo fork:
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/74cecbeb-94d1-4181-9caa-3f60c54d6b08n%40googlegroups.com.