Re: [bitcoindev] Re: BIP draft: CISA for Taproot Key Path Spends

[waxwing/ AdamISZ <ekaggata@gmail.com>]

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

> 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 
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 because 
you say this like it's a known thing; is it?

I agree with your analysis; the biggest counterpoint being that 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 
lightning channel with a bunch of consolidated utxos' are too 
artificial/obscure 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 extra complexity, not worth it.

Cheers,
waxwing/AdamISZ

On Tuesday, July 28, 2026 at 2:25:13 PM 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, 
> 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+...@googlegroups.com.
>
> To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/74cecbeb-94d1-4181-9caa-3f60c54d6b08n%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/0a59ffec-6960-4919-80a6-9ca45203d858n%40googlegroups.com.

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