From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: BIP draft: CISA for Taproot Key Path Spends
Date: Tue, 21 Jul 2026 17:18:38 -0700 (PDT) [thread overview]
Message-ID: <74cecbeb-94d1-4181-9caa-3f60c54d6b08n@googlegroups.com> (raw)
In-Reply-To: <Qc_VmkfXgE8KHBfUnUB-hdWF1QOYv6zshzI7WEv_hvqJ6O_4zssJ4X2T2Di79I3TqHQvRDXsFtD8os5M44wrbB61M1LD_-GDRGYEagoHsV4=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3401 bytes --]
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:
>
> https://github.com/fjahr/bips/blob/cf0d4f2142cd0504b16e86739167b1f7ab9a3a06/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
>
--
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.
[-- Attachment #1.2: Type: text/html, Size: 5674 bytes --]
prev parent reply other threads:[~2026-07-22 0:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 12:39 [bitcoindev] BIP draft: CISA for Taproot Key Path Spends 'Fabian' via Bitcoin Development Mailing List
2026-07-18 18:45 ` 'conduition' via Bitcoin Development Mailing List
2026-07-19 21:57 ` 'Fabian' via Bitcoin Development Mailing List
2026-07-22 0:18 ` waxwing/ AdamISZ [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74cecbeb-94d1-4181-9caa-3f60c54d6b08n@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox