From: Boris Nagaev <bnagaev@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP draft: CISA for Taproot Key Path Spends
Date: Wed, 5 Aug 2026 16:26:25 -0700 (PDT) [thread overview]
Message-ID: <bc77e7a7-fb5a-4563-90bf-e6a3f98ed351n@googlegroups.com> (raw)
In-Reply-To: <IrJGniZYNo7x0fr4wABg7SsdqJoJWs5yozmiFLGzJkxOwtHU01_O8swpJMKVi_uEkdqAfFUTELpOTja53HCrgmBgQBFYup1NQ4LCZHMRcFQ=@proton.me>
[-- Attachment #1.1: Type: text/plain, Size: 7832 bytes --]
Hi Conduition, hi Fabian, hi all!
If we use BIP-459
<https://github.com/fjahr/bips/blob/fullagg/bip-0459.mediawiki> full
aggregation for P2MR or P2TRH, we can recover one of the EC keys of a CISA
group, solving its equation for that EC key. This saves 32 bytes per group.
If a group is small, this actually makes sense.
This is the equation that BIP-459 verifies:
s⋅G = R + Σ c_i⋅P_i
We can solve it for one of the public keys (P_j):
P_j = (c_j^-1 mod n) ⋅ (s⋅G - R - Σ_{i≠j} c_i⋅P_i)
(Here c_j != 0. If c_j ==0, we need to restart the signing session with
freshly generated nonces.)
One thing we have to change in BIP-459 to enable this is how
coefficients c_i are calculated.
Currently BIP-459 produces them based on EC public keys themselves: roughly
c_j = H(L || R || P_j || m_j). This creates a circular dependency at
verification time if we don't know the omitted key (for P2MR or P2TRH).
For P2TRH, we need to replace P_j with scriptPubKey_j in the
formula (something similar to my EC recovery proposal
<https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603>).
Since it commits to P_j, this should remain secure (need a formal proof). L
also depends on public keys in BIP-459 - we need to change it to depend
on scriptPubKeys as well. We need to do it at least for the input whose
public key is recovered, but can also do for all inputs, for uniformity.
For P2MR recoverable EC leaf
<https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603>, scriptPubKey is
not sufficient as a replacement for a pubkey, since there might be multiple
such leaves. To prevent related-key attacks, scriptPubKey must be
accompanied with the control block (or its hash) of the leaf. This must be
done both in c_j and L formulas.
Then we can recover one of the keys instead of putting it into witness. The
natural choice is to recover the key of the input holding
the aggregate signature, since it is already a special input in CISA.
Savings:
- P2TRH-CISA: n + 32n + 64 = 33n + 64
- One-key recovery: n + 32(n-1) + 64 = 33n + 32
(This counts the witness payload above, including one marker byte per
input, but excludes CompactSize framing, annexes, and explicit sighash
bytes.)
Inputs P2TRH-CISA One-key recovery Saved Saving
1 97 bytes 65 bytes 32 32.99%
2 130 bytes 98 bytes 32 24.62%
3 163 bytes 131 bytes 32 19.63%
4 196 bytes 164 bytes 32 16.33%
5 229 bytes 197 bytes 32 13.97%
7 295 bytes 263 bytes 32 10.85%
10 394 bytes 362 bytes 32 8.12%
20 724 bytes 692 bytes 32 4.42%
100 3,364 bytes 3,332 bytes 32 0.95%
One additional nice effect of this is that no separate ordinary mode is
needed for basic single-input spending. A one-input full-aggregation group
has the same 65-byte payload as a marker-based non-CISA single-input spend.
The price is the loss of batch verification across CISA
groups. Inside-group verification efficiency is preserved: EC workload
inside group is almost the same, just one additional scalar inversion.
Best,
Boris
On Saturday, July 18, 2026 at 1:50:35 PM UTC-5 conduition wrote:
Sending this again because I think the first time didn't work.
Thanks Fabian, this is very cool. I haven't read the entire BIP in detail
yet, but first thing I notice on a quick skim is that reserving segwit
version 2 conflicts with BIP-360 which proposes to use the same.
I'm particularly interested in how to dovetail this proposal with PQ
migration efforts. I have two questions:
1. 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)
2. 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
<https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603> 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:
1.
1. 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).
2. 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 <bitco...@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+...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/Qc_VmkfXgE8KHBfUnUB-hdWF1QOYv6zshzI7WEv_hvqJ6O_4zssJ4X2T2Di79I3TqHQvRDXsFtD8os5M44wrbB61M1LD_-GDRGYEagoHsV4%3D%40protonmail.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/bc77e7a7-fb5a-4563-90bf-e6a3f98ed351n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 12124 bytes --]
next prev parent reply other threads:[~2026-08-05 23:36 UTC|newest]
Thread overview: 8+ 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-08-05 23:26 ` Boris Nagaev [this message]
2026-07-22 0:18 ` [bitcoindev] " waxwing/ AdamISZ
2026-07-28 20:18 ` 'Fabian' via Bitcoin Development Mailing List
2026-07-30 0:03 ` waxwing/ AdamISZ
2026-07-31 14:15 ` 'Fabian' via Bitcoin Development Mailing List
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=bc77e7a7-fb5a-4563-90bf-e6a3f98ed351n@googlegroups.com \
--to=bnagaev@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