From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 21 Jul 2026 17:21:16 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wmKi4-0008Pj-5F for bitcoindev@gnusha.org; Tue, 21 Jul 2026 17:21:16 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-44ce386fe90sf9636337fac.2 for ; Tue, 21 Jul 2026 17:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1784679670; x=1785284470; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=7D+SYDUBI3gdzPybMsyasKD+C8V4NHt8hlypel9sIv0=; b=bR9z08VnGTMct6m559oKEzg6ox9eBywSezv9GdlBKBW84tAXttcJG+ekqa+MDEJBCk fK7SmQ+d6+WO7xM2T2uwyoJ5w7SzETLECEpQr1D/43e+7cTxTh4fBfqdPiF/YHPcQnpu Ng9g9HiC+5APxyYkozpuD+3aPBzgHwlZgUYLG8VS9VKPHCY61H9skDyRAmLDVJw8bhg/ BXvB9jK/uBzgQjI+J/Wd22hEKHJS7HRUpDWSWeyZ1IjHK4Ba+R3RMKOn+u+Qhna6tgrI J9j1mtru+gCg4sRYSotYw5nMioRBhqqoxvCRIAjDlwzzdG9uoaAZU0ddVn7/708VSdN3 VEOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784679670; x=1785284470; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=7D+SYDUBI3gdzPybMsyasKD+C8V4NHt8hlypel9sIv0=; b=f2AWylgBou5xOJFUHo00j7tWncuTIz8/Q5O1K+mc6IJZjHg5GJbKyUrntLuNGY0rEF vQD6I15cHFp6IGYOQMG3HiaZ2Pi4pDQn87FfTm6OLbmekZjtCXzO0AVIDZzPELc+WXQm B9a3Gi7/NEovRNGM//kBNSP7/VOMBoXYTzplAs+drUOJ5QEBBRR43xBXZS3pVqjARVZ+ 7hGkZWXGZOBLJ+EyyKDMOjykjqKx5Yb0raA7Gq/FEH8c8tDzg5zXuU5TPBTvv9z+PYiW pYXsAOrJrtNdtrYfQwuosHp5nj4w0ZKS11dGx7rgXsrscygg4p9D/RZN+Xvvuvt/ob0j ZiVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784679670; x=1785284470; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7D+SYDUBI3gdzPybMsyasKD+C8V4NHt8hlypel9sIv0=; b=QZuQ47opv7f0D24JjsFo8Sv208i7QmHGLmeuuoSXzmrsoqYl2aTgXF+zT202cp80H6 VQrYMK/xDVXf189WoMg4dB9RzbybMa/vId8NSmPSQMwi4oCKmZq5IeaIIjPPx15p2Lgf ulqCwXxfHXxsV4Y8uBx67T+NkaMWe3IOoZm6S+Zbe5osezKWmjuRAKxRgUrkW5c8XiyG OKbmsLbVBIiOxtOUHbRk9u8ZZ58dA0cT5llZVGOFTtUCMGWnEbEt8p2JAyq/mS0lSBLN Y7d82Tvu8Mu0YAT7RgixzIhwVajOCdbYoT51tFNutJhR1PkALyRXy8GAf1IFnqQrCA55 QE5A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+Ro7JgL9afd6+d1WtY/8UC+nbpAQQXJp55X0e4JhU0g6ts/vSD6NUSqbjWwW5I/Rqj5VVdnXqjgK5pGZ@gnusha.org X-Gm-Message-State: AOJu0YwNJC+Ypl9i2NDY/lFQt7cb4I//3Ey8x3luD63RyBK0TGJBCWz9 kSxJ81F+6Q/nHiLM9WUvQUF8k7trACxciv2x99T26NzWcKOqRUfQruSi X-Received: by 2002:a05:6870:93cd:b0:456:8f0d:4fb3 with SMTP id 586e51a60fabf-456901a109fmr10386632fac.12.1784679669683; Tue, 21 Jul 2026 17:21:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPSly5jbqeYUj3WKXVFU5e1M4OUiSZlulo6iZCPsfW6wrg==" Received: by 2002:a05:6870:a48a:b0:454:e0fd:4304 with SMTP id 586e51a60fabf-4566a65bf61ls3560589fac.1.-pod-prod-05-us; Tue, 21 Jul 2026 17:21:05 -0700 (PDT) X-Received: by 2002:a05:6808:1904:b0:492:f15e:3626 with SMTP id 5614622812f47-4a4d0559a95mr11218077b6e.40.1784679665163; Tue, 21 Jul 2026 17:21:05 -0700 (PDT) Received: by 2002:a05:690c:dd6:b0:81e:ee9e:9148 with SMTP id 00721157ae682-81f01c7ecefms7b3; Tue, 21 Jul 2026 17:18:39 -0700 (PDT) X-Received: by 2002:a05:690c:d06:b0:81e:7a60:68c5 with SMTP id 00721157ae682-81ef26119e3mr65732367b3.46.1784679519399; Tue, 21 Jul 2026 17:18:39 -0700 (PDT) Date: Tue, 21 Jul 2026 17:18:38 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <74cecbeb-94d1-4181-9caa-3f60c54d6b08n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: BIP draft: CISA for Taproot Key Path Spends MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_52138_1545487905.1784679518986" X-Original-Sender: ekaggata@gmail.com 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: -0.5 (/) ------=_Part_52138_1545487905.1784679518986 Content-Type: multipart/alternative; boundary="----=_Part_52139_991047990.1784679518986" ------=_Part_52139_991047990.1784679518986 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabian, Thanks again for the draft. "A more flexible alternative with multiple aggregation groups per scheme,= =20 similar to the bucket concept from early aggregation discussions, was=20 rejected because no concrete use case justified the additional validation= =20 complexity." Say a bunch of people want maximally weight-minimising transaction (for=20 their consolidation), but don't want to run a collaborative scheme between= =20 each other because it's technically hard to do safely (constrained=20 hardware/software, nonce state handling, etc.). Each of them just want to= =20 full agg their 10 inputs, each. Not saying it's some super-common-in-practice scenario, but it seems=20 suboptimal that you can't do it. So ... I guess it depends on whether "the= =20 additional validation complexity" is really bad compared with the utility= =20 of that specific use case. More specifically, though, why couldn't a 'group ID' be folded into the=20 marker byte. In your draft you say "The chosen values fall into the range= =20 0xbb to 0xfe, which is unassigned in legacy script and corresponds to=20 OP_SUCCESS opcodes in tapscript, so they do not collide with opcodes=20 commonly seen in scripts." - but there are a lot of values between 0xbd and= =20 0xfe. I guess this is not a case for bitflags, but just different markers = =20 where you add a groupID to 0xbd (and with the understanding - this clearly= =20 is only relevant for fullagg, not halfagg). Is this just out of=20 consideration for some other reason that (hardly surprising) I'm not aware= =20 of? (I don't believe this suggestion changes anything functionally as described= =20 in the 'Common Signature Message' section; I mean it literally changes the= =20 byte, but, functionally). A negative (for privacy specifically) would be that you tag the different= =20 groups in the input list. While that as a proposal may or may not be a good one, I feel like: this is= =20 worth mentioning at this time because (IIUC) it cannot be retrofitted in=20 after. Cheers, AdamISZ/waxwing On Saturday, July 18, 2026 at 11:44:33=E2=80=AFAM 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/cf0d4f2142cd0504b16e86739167b1f7ab9a3a= 06/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 > --=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/= 74cecbeb-94d1-4181-9caa-3f60c54d6b08n%40googlegroups.com. ------=_Part_52139_991047990.1784679518986 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabian,

Thanks again for the draft.

"A more flexible alternative with multiple aggregati= on groups per scheme, similar to the bucket concept from early aggregation discussions, was=20 rejected because no concrete use case justified the additional=20 validation complexity."

Say=C2=A0 a bunch of peo= ple 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 stat= e 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 d= epends on whether "the additional validation complexity" is really bad comp= ared with the utility of that specific use case.

More specifically, though, why couldn't a 'group ID' be folded into the ma= rker byte. In your draft you say=C2=A0 "The chosen values fall into the ran= ge 0xbb to 0xfe, which is unassigned in legacy sc= ript and corresponds to OP_SUCCESS opcodes in tapscript, so th= ey 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 bitfla= gs, but just different markers=C2=A0 where you add a groupID to 0xbd (and w= ith the understanding - this clearly is only relevant for fullagg, not half= agg). Is this just out of consideration for some other reason that (hardly = surprising) I'm not aware of?
(I don't believe this suggestion ch= anges 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.

Whil= e that as a proposal may or may not be a good one, I feel like: this is wor= th mentioning at this time because (IIUC) it cannot be retrofitted in after= .

Cheers,
AdamISZ/waxwing
On Saturday, July 18, 2026 at 11:44:33=E2=80=AFAM UTC-3 Fabian wrote:
=
Hi list,

I would like to share a BIP dra= ft for transaction-wide cross-input
signature=C2=A0<= /span>aggregation (CISA). It introduces= =C2=A0a new=C2=A0witness=C2=A0version,
which en= ables Taproot-style key path spending where=C2=A0inputs 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 scheme= s 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:

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

<= /div>
Feedback of any kind is much appreciated.
=
Best,
Fabian

--
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/bitcoind= ev/74cecbeb-94d1-4181-9caa-3f60c54d6b08n%40googlegroups.com.
------=_Part_52139_991047990.1784679518986-- ------=_Part_52138_1545487905.1784679518986--