Can the framework you use for verifying aggregated sigs be generalized to support future aggregated PQ signatures in the future? (assuming we someday have a PQ sig algorithm that admits aggregation)

How do you see this proposal mixing with BIP360? The major hurdle I see is that your proposed output type puts a bare EC pubkey on-chain in the script-pubkey. Unfortunately Boris' EC recovery trick does not seem to work in this context: Because signatures are aggregated we can't recover pubkeys, so we can't hide them behind a hash. We either have to put them in the SPK, or the witness. So at face value, it seems there are two options:

Couple CISA tightly with P2TRv2. On one hand this would be good because it would provide a concrete incentive for users to migrate to a wallet that supports PQC. This also seems like the easier option from an engineering perspective. However it comes with all the baggage of P2TRv2 (not actually quantum-safe by default, need to solve the Q-day timing problem).
Hide the EC pubkeys behind a hash in the SPK (e.g. P2MR or P2TRH), and attach the EC pubkey in the witness of every aggregated TX input, so that the verifier can run the aggregated sig-verify algorithms. This would be more secure and relaxes the Q-day timing constraints, but we don't get as much relative savings.

Napkin math of the witness weight of an aggregated input, assuming full-aggregation is used:

with P2TRv2:

1 byte for the marker
total: 1 byte

with P2TRH:

1 byte for the marker
32 bytes for the EC pubkey
total: 33 weight units

with P2MR:

1 byte for the marker (witness)
32 bytes for the merkle sibling node (witness)
32 bytes for the EC pubkey (witness)
total: 65 weight units

regards,

conduition

On Saturday, July 18th, 2026 at 7:44 AM, 'Fabian' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> 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/Qc_VmkfXgE8KHBfUnUB-hdWF1QOYv6zshzI7WEv_hvqJ6O_4zssJ4X2T2Di79I3TqHQvRDXsFtD8os5M44wrbB61M1LD_-GDRGYEagoHsV4%3D%40protonmail.com.