From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 19 Jul 2026 15:18:30 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wlZq9-0003VM-5p for bitcoindev@gnusha.org; Sun, 19 Jul 2026 15:18:30 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7e9e54e9cf5sf13346789a34.0 for ; Sun, 19 Jul 2026 15:18:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1784499503; cv=pass; d=google.com; s=arc-20260327; b=GpE0mQ5XQ2Oj6F+ZolSmr6ClekEr5kkpwPK7HMArMFCFtmZxG/RKc68rZwxocPM5eJ 3j4upELai7G+8AAx4M+WfWi6ad4Jgm3ZBO69VoAT2GaRqFMaErYuepSXu8kATuIyRdzG KMMYRL+oQSlwJzupyP3Xh743HawG5/CksIqEiRGHLm7YbeUCVW3rne4g8unXfg0slsvM 9h5l8sbHY1TF9XEukMdexhf07+QlKWmDSH9mSA6YNvj/yPU3vUNH1zsNFFY152t0ZXNu V3hkANtUWMt1zi2+Ey1qhoO49LZSTSpIDVPsamhREEODrEGcIXZ8MgDwduyIRcRFKMVs q7Sw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=BpGg1r9jaCKAUQqnjAKOZkyJ6CYAkDfq0IZMahbsrVg=; fh=DL33KG8Zc4l7qeqhVY+VrfJoyfW79JbjVsDGoq9kCSc=; b=Z54MWM3aFS7ZoZtklNy4KbLmVGIJV3ByK+I5xppQqiuatBYozCIjPYiSerpvN29RzL izg5z4wi8Hf/ft71d1xgQVdNwswyDsftnIS8/E7bI8o/kini+y0AqpY9vYTH5IPUyNPe C7kqVwLA0l0zcPjrQkJBOQtPruhcaMeWct/oeQc6a5SYMxbxgRYCyb5G24O4kIhGIWVo xLG5qk1woRweAaDhSZq7vISunkTxqVZgi8ZQzt5EfVOypffj7XRARbaxqHhbnqmbcOn8 50BF0dao99ekivEnQUUgcczq7p3U0la/yqNj7B1Ts9SgTBjMAvfdcUT3N/c2QYiYdo9b I4BQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=wlQOZloO; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1784499503; x=1785104303; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BpGg1r9jaCKAUQqnjAKOZkyJ6CYAkDfq0IZMahbsrVg=; b=q+AXpgvh98CvSsoFWfVGsYHwcLKOntOCe2qbhogFvtwDgLANG/3gjlExY9QjqsdZt7 qfWKeGjx4gmc0Ygi4pvAXNYmtO9mvZPTSOdKVReOCoej25qN2raoJ4IU4EO0DGQBvBtN CGC+bQcMfTSogeluRwt2fXecC3FUa39aZzBIHeF0jwat4+X5Yg3iqflhzTE/PvqrvP5h sWXd2CQcB/USs9OCKT1395meCXrgSs4O3mV78PoY2pwlkWrU/XZSOl8w3JFdKdeJFhB1 0txNoUninjlyTCBJBj8pUJsuctmRKbdFluUnnt1Y+ab5TEHcC3yfN4xu1IcyFX4XeHc4 ubsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784499503; x=1785104303; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=BpGg1r9jaCKAUQqnjAKOZkyJ6CYAkDfq0IZMahbsrVg=; b=gs9bVdVJEAmdpFLsDszTAZlTuV0UDwO7wqpCX8Z0U9OeXgwK/T0SfBTs4GCFJLRHgD gEb9YqGa74zDwDdplw3Z+VKqid+DkAo/yfPSPCotP+FhNfol39niWiDdRhgtR4H2Ut/9 uTrR/ZxxS1sa1lt1WR7SwVp2m3CN8OIx57NnVbndvDf8Goj1GqHNf6pX+YDFQrEn8n+H X2GseU6mj21+ecCiw5pixJkz76na54VyCCnJAnI5B7JoEb5Lw+Hqk+v0m8axsDDFjFPk z9nvoaHwjEyGABR4O60MAywQwScc0GGF02bSnDM2/1ng1smmqqqOiho0uOb3cw18/TeC bwng== X-Forwarded-Encrypted: i=2; AHgh+RqK4UHBz3zAlbQeNnuLo7vRRL+W/MXqJSuSZc2FLs29s+ig6VGjRh9OqoHxL9JwOFu+j2BpEw7bBsE0@gnusha.org X-Gm-Message-State: AOJu0YxTwjYO/r9HLqUp8DmxIEagBzlsIB51pgLnNW2R5Cj4TkcqHWXo 7eHeaQ70PE+jFXpNjTzZ8qaxjWZ65+13FmwWfRMkjCEmJ9KYzHWQVC/y X-Received: by 2002:a05:6820:1806:b0:6a1:50eb:2110 with SMTP id 006d021491bc7-6a536a9faddmr6090475eaf.69.1784499502864; Sun, 19 Jul 2026 15:18:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPTbbaNeiD6pOylJQzoXAJZqam0/z6FDhgGWINxfMhM2kw==" Received: by 2002:a05:6870:a48a:b0:454:e0fd:4304 with SMTP id 586e51a60fabf-4566a65bf61ls2029198fac.1.-pod-prod-05-us; Sun, 19 Jul 2026 15:18:17 -0700 (PDT) X-Received: by 2002:a05:6808:c3ea:b0:495:feaa:9e39 with SMTP id 5614622812f47-4a4d0292d8dmr6673158b6e.6.1784499497881; Sun, 19 Jul 2026 15:18:17 -0700 (PDT) Received: by 2002:a05:6808:ce:b0:495:e116:a399 with SMTP id 5614622812f47-4a410c7c675msb6e; Sun, 19 Jul 2026 14:57:52 -0700 (PDT) X-Received: by 2002:a05:6a21:4516:b0:3c3:cf9b:fb8b with SMTP id adf61e73a8af0-3c3cf9bfcd0mr6969191637.68.1784498270989; Sun, 19 Jul 2026 14:57:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784498270; cv=none; d=google.com; s=arc-20260327; b=TlG6jVMuTJYSIRIWbmpElEUrBwMPijmrT7wJ71YYIFQ3dRop7vUf9r/gqjbTHnOGKt u2+5zLbz0qSeM7mUfeQZG5tojqDfitjnKFWce+KEdpJhQsdISYtREvjXNfrCeAGNUiHj LLQn/uith9dVIDS58uFN138US5iHbl7XOQ8KF3xP32XVVedv6Bo58jZ81fahQ0x2nTyt 1NIuIrwT0rX0QTb237618qT7O/9YSHug1pJDV4Td9tuxJBSU6jUST2oxj4x0NWKcKqqb o18oJqLdSBiph/r/aA7R/N5VKyuXI/5+XWoPSWYsx66Av6PUt4ddM9W/nakmUd+MpCBw TNdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=5EitrBBHETpKSzFYfHkdhed+ZNH7yEZOISHUZBIszJU=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=XFN4Tjx0gPGch4HaD/r74ealXjqkaQGfTYkV4KWksS6iOsrI0RWeMo+P+kI2NwhOCk bWNmO2VLvUYwXsKIziA8ULLmR3M+JwuFWI4IKvJYYj5DB2ISB33xp4KTd+/wEt6KN6QJ ccx9v/YeVvkWXHRTjI7xhex786k4BrJcO9U5xRpBYP9hdWesp6O/i/hMS6r97JuTSHBB jkdWZFx0/TRAaGZW+VpVlOEXQBZQ+CbX2JrWQqWThZofug3BqAzkKNpykoiYveVsrRFm qcwN8mKyCNhGwLKyhwM46E+7vo+qDbdvVAd7JQV8yh7KhKz+aQ9exMUmlN7ymhDrZ92Y u87Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=wlQOZloO; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-244123.protonmail.ch (mail-244123.protonmail.ch. [109.224.244.123]) by gmr-mx.google.com with ESMTPS id 5a478bee46e88-3142a1af307si304098eec.2.2026.07.19.14.57.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jul 2026 14:57:50 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 as permitted sender) client-ip=109.224.244.123; Date: Sun, 19 Jul 2026 21:57:42 +0000 To: conduition From: "'Fabian' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] BIP draft: CISA for Taproot Key Path Spends Message-ID: In-Reply-To: References: Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 0dd9cb8ea4714913b98966a67bef85df8c2ebb49 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_lU5J5uyI3whev1bzJZzEXecYVTmtsdGlPr7xC14Qdk" X-Original-Sender: fjahr@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=wlQOZloO; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.123 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Fabian Reply-To: Fabian Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_lU5J5uyI3whev1bzJZzEXecYVTmtsdGlPr7xC14Qdk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi conduition, Thanks a lot for checking out the proposal and raising those questions! One caveat up front: I have not spent much time on the PQ side of things yet, so I can not give you a very serious answer on those parts and I do not want to make strong claims here. But I am interested to invest more time there now that the proposal is published and explore how it can be adapted for different PQ scenarios. > reserving segwit version 2 conflicts with BIP-360 which proposes to > use the same. Right, this was pointed out in an inline comment as well, please see my answer there: https://github.com/fjahr/bips/pull/6#discussion_r3609171527 > 1. Can the framework you use for verifying aggregated sigs be > generalized to support future aggregated PQ signatures in the future? I would expect that the transaction-level structure should generalize: the markers, the mode commitment in the signature message, the group formation, and the final input carrying the aggregate should not care which scheme is used (again, take it with a grain of salt since I have not studied any PQ schemes in real depth). We would still need a new witness version but there would be need for a new output type anyway in this scenario, I guess. I certainly hope in any scenario that the framework and related learnings will be useful in a PQ world as well. > 2. How do you see this proposal mixing with BIP360? I do not have a concrete good answer here yet. The trade-off you describe is certainly real: aggregation needs all public keys as input to verificati= on, so hiding them costs 32 bytes per input which halves full-agg savings and makes half-agg ~useless. This proposal deliberately picks the taproot security model, bare keys give us maximum savings. If P2TRv2 materializes as the migration output type, I could see CISA certainly being defined on top of it. The witness rules here should carry over and since script path spending follows BIP 341/342 unchanged, committing PQ fallback leaves would work the same way as proposedthere. Tha= t definitely seems worth exploring. A hash-hidden variant like your option b should be possible within the same framework. This could be specified as its own output type if the ecosystem likes this trade-off and I think that is a very interesting idea = to explore. Both outputs types could coexist and users could pick based on their quantum fear index while the implementation would share most of the logic/code. Even shared aggregation groups seem possible cleanly if we add them to this proposal, but this likely wouldn't be great for CoinJoin privacy guarantees. But I think even the proposal as-is can provide a lot of value in many conceivable scenarios of CRQC arrival and I think you were hinting at this with the migration argument as well. If the network, for example, comes to consensus that CRQCs will arrive in 1-2 years and a PQ scheme is about to be deployed, which will be bigger and more expensive than BIP340, we should see a lot of demand for consolidation and CoinJoins and having CISA availability would provide a nice (though temporary) effect. But of co= urse this is also limited to the coins that have moved already by that time. Best,Fabian On Saturday, July 18th, 2026 at 8:50 PM, 'conduition' via Bitcoin Developme= nt Mailing List 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 ver= sion 2 conflicts with BIP-360 which proposes to use the same. > > I'm particularly interested in how to dovetail this proposal with PQ migr= ation efforts. I have two questions: > > - Can the framework you use for verifying aggregated sigs be generalized = to support future aggregated PQ signatures in the future? (assuming we some= day 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 sc= ript-pubkey. Unfortunately [Boris' EC recovery trick](https://delvingbitcoi= n.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603) does not se= em to work in this context: Because signatures are aggregated we can't reco= ver pubkeys, so we can't hide them behind a hash. We either have to put the= m in the SPK, or the witness. So at face value, it seems there are two opti= ons: > > - 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 tha= t 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 t= he verifier can run the aggregated sig-verify algorithms. This would be mor= e 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-a= ggregation 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 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/cf0d4f2142cd0504b16e86739167b1f7ab9a3= a06/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 Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/Qc_VmkfXgE8KHBfUnUB-hdWF1QOYv6zshzI7WEv_hvqJ6O_4zssJ4X2T2Di79I3TqHQvRDXs= FtD8os5M44wrbB61M1LD_-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/bitcoinde= v/IrJGniZYNo7x0fr4wABg7SsdqJoJWs5yozmiFLGzJkxOwtHU01_O8swpJMKVi_uEkdqAfFUTE= LpOTja53HCrgmBgQBFYup1NQ4LCZHMRcFQ%3D%40proton.me. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= Uk5a8rhAaNaCC8sif05lv1rmZLRYBCedbNVxPwDvHsWAA9Gbm36vGOw4XFvh7XG_MAJtiYBaD6B= SEIr_KYWIxS5Ccm0OhwEIZo2gFeFfXvs%3D%40protonmail.com. --b1=_lU5J5uyI3whev1bzJZzEXecYVTmtsdGlPr7xC14Qdk Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi conduition,

Thanks a lot for checking o= ut the proposal and raising those
questions!<= /div>

One caveat up front: I have not spent much t= ime on the PQ side of
things yet, so I can not give = you a very serious answer on those parts
and I do no= t want to make strong claims here. But I am interested to
invest more time there now= that the proposal is published and explore
how it can be adapted for different PQ s= cenarios.

> reserving segwit version 2 conflicts with BIP-360 which proposes to=
> use the same.

Right, this was pointe= d out in an inline comment as well, please see my
answer there:<= /span>
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0,= 0, 0); background-color: rgb(255, 255, 255);">
&= gt; 1. Can the framework you use for verifying aggregated sigs be> generalized to support future aggregated PQ signatures in the f= uture?

I would expect that= the transaction-level structure should generalize:
the markers, the mode commitment in= the signature message, the group
formation, and the final input carrying the aggregate should no= t care
which scheme is= used (again, take it with a grain of salt since I have not
studied any PQ schemes in real depth)= . We would still need a new witness
version but there would be need for a new output type anyway = in this
scenario, I gu= ess. I certainly hope in any scenario that the framework
and related learnings will be useful in = a PQ world as well.
> 2. How d= o you see this proposal mixing with BIP360?

I do not have a concrete good answer here yet. The trade-off you describe<= /span>
is certainly real: aggregation needs all public keys=  as input to verification,
so hiding them costs 32 by= tes per input which halves full-agg savings
and makes half-agg ~u= seless. This proposal deliberately picks the
taproot securi= ty model, bare keys give us maximum savings. If
P2TRv2 materializes as the migration output type, I could see CISA
certainly being defined on top of it. T= he witness rules here should carry
over and since script path spe= nding follows BIP 341/342 unchanged,
committing = PQ fallback leaves would work the same way as proposed
th= ere. That definitely seems worth exploring.
<= span>
A hash-hidden variant l= ike your option b should be possible within the
same framework. T= his could be specified as its own output type if the<= /div>
Both outputs typ= es could coexist and users could pick based on
their quantum fear= index while the implementation would share most of
the logic/cod= e. Even shared aggregation groups seem possible cleanly
if we add= them to this proposal, but this likely wouldn't be great for
Coi= nJoin privacy guarantees. 

But I think e= ven the proposal as-is can provide a lot of value in many
conceiv= able scenarios of CRQC arrival and I think you were hinting at this
with the migration argument as well. If the network, for example, comes<= /div>
to consensus that CRQCs will arrive in 1-2 years and a PQ scheme = is about
to be deployed, which will be bigger and more expensive = than BIP340, we
should see a lot of demand for consolidation and = CoinJoins and having
CISA availability would provide a nice (thou= gh temporary) effect. But of course
this is also limited to the c= oins that have moved already by that time.

= Best,
Fabian
On Saturday, July 18th, 2026 at 8:50 PM, 'conduition' via Bitcoin D= evelopment Mailing List <bitcoindev@googlegroups.com> wrote:
Sending this a= gain because I think the first time didn't work.
Thanks Fabian, this is very cool. I haven't read t= he entire BIP in detail yet, but first thing I notice on a quick skim is th= at reserving segwit version 2 conflicts with BIP-360 which proposes to use = the same.

I'm particularly interested in ho= w 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 futu= re? (assuming we someday have a PQ sig algorithm that admits aggregation)&n= bsp;

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

    1. Couple CISA tightly with P2TRv2. On one hand this wou= ld be good because it would provide a concrete incentive for users to migra= te to a wallet that supports PQC. This also seems like the easier option fr= om an engineering perspective. However it comes with all the baggage of P2T= Rv2 (not actually quantum-safe by default, need to solve the Q-day timing p= roblem).
    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 aggr= egated TX input, so that the verifier can run the aggregated sig-verify alg= orithms. 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 byt= es 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 Devel= opment Mailing List <bitcoindev@googlegroups.com> wrote= :
Hi list,

I would like to share a BIP draft for transaction-wide cross-input
signature a new witness&nb= sp;version,
which enables Taproot-style key path spe= nding where inputs can
aggregate their signatur= es.

Each input chooses between half-a= ggregation, full-aggregation, or an
explicit opt-out= via a marker byte in its witnesshttps://github.com/fjahr/bips/blob/cf0= d4f2142cd0504b16e86739167b1f7ab9a3a06/bip-XXXX.mediawiki

For inline comments, I have opened a mock pull = request on my BIPs
repo fork:

Fee= dback 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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Qc_VmkfXgE8KHBfUnUB-hdWF1Q= OYv6zshzI7WEv_hvqJ6O_4zssJ4X2T2Di79I3TqHQvRDXsFtD8os5M44wrbB61M1LD_-GDRGYEa= goHsV4%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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/IrJGniZYNo7x0fr4wABg7SsdqJoJWs5= yozmiFLGzJkxOwtHU01_O8swpJMKVi_uEkdqAfFUTELpOTja53HCrgmBgQBFYup1NQ4LCZHMRcF= Q%3D%40proton.me.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= Uk5a8rhAaNaCC8sif05lv1rmZLRYBCedbNVxPwDvHsWAA9Gbm36vGOw4XFvh7XG_MAJtiYBaD6B= SEIr_KYWIxS5Ccm0OhwEIZo2gFeFfXvs%3D%40protonmail.com.
--b1=_lU5J5uyI3whev1bzJZzEXecYVTmtsdGlPr7xC14Qdk--