From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Jul 2026 13:25:21 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wooMZ-0004vq-QS for bitcoindev@gnusha.org; Tue, 28 Jul 2026 13:25:20 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-6a516afd714sf363293eaf.3 for ; Tue, 28 Jul 2026 13:25:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1785270314; cv=pass; d=google.com; s=arc-20260327; b=mcEa6Sha/rRVvHgcBX1/OopOg2ujjgPd6CYZB+6I00a7FN3xDEMgOGZmJYBq9yYU8L H3T1qobAmmFWdKpIKOMHLSJiclsDZqwovk82DnKy2gitAb/fShdyEUFP7cbwKEFR3yBU PBLKI0Oc0UHRk7WFWLYByI0Mwj4yogmyubXDDdNMa0Ga/Te8W2nSNSiYr3NAETXceouA Ox7ClwCjq7IqSGrU+xd90yNwihC7Li9iYGm/kYM9gQaMWhq0qoWKnysS2NqQPsfoFFtO 0sN8fx9/8HmQt6YfVMoInQNxhCWZHih9r9GkNYQiX5iAMQHYEFKidyGrVuxQiDfhjpxR uCJw== 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=N8pYwEKqZqZDogE9ZFWd3tsOIg+ksthp/50qHk/6XGc=; fh=VLblhNCidZ+xzD0p7u1eVG5z/0bkOB1gvNV/DinHmIM=; b=IEGXgukyM0IlEJJlmbIq0Ct7ZH4JML7i+vP5pF0nriExNjnwDKNfLGAbwU2s7SZO3U ftJCCFqBYuTOSov0CJHmtirruaqFqHqzM28GQN+NcGJPa93Xar8dwYyRCIUo9GV66OES piC8wDmyQNdQ+5+iZ5b7BDL+6ckFf1mHjKLUwKiVV5UoCsTLEi9vHogAmdi+Nlu+Sjre ya0vjRHN9l4561IkUv0e7g1EjafyIFjPzjPihCqvkaHtc6Pgve2ukxi/MPCP2OscyHGB NBQ/q4trQehglkL/L3pbf9vjr2lbV8ZdoLThH9t5JuxD54lQwpRqI8fR9aSA2NTtMZms l1xg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=l5Zmm3AA; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 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=1785270314; x=1785875114; 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=N8pYwEKqZqZDogE9ZFWd3tsOIg+ksthp/50qHk/6XGc=; b=sDDGpd4yP+zCtnol5LnlRxabM/uzNC9uIPUHa/L5S2lYU45mLJbJ4NPf4f+/BumnIG ZvB3bQQPZ31hHQJ3ORhUPWupw5w0d5YdkvZxGe7eckfNYhlGZcTP45E3hH9znCQ1CXg1 lk67TKrb9QSznq0koXiOiub6864B4+aAqDuiGarzKGNYzW6EIWe1nWk9PRENg70CRo4B PPA8eEhxeE5MnNFP/yPePoCewHrkam89SecjQG1gNFEO7WUYhi+zlMGzUkC92dFAioc3 KUYZ5KjxxBvebwY344nlzXKs737MyEz4+kBJi6QeTHF5/f2b8cI6gi6OqA389eWlfJfL 0n1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785270314; x=1785875114; 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=N8pYwEKqZqZDogE9ZFWd3tsOIg+ksthp/50qHk/6XGc=; b=cb5qIB6O23xgbBz5ulGCSVnRbFRyqqDI8Yiu+lF+rgKA7PcIpc4w+c5sMi07JbD7VG hz5TI2lYUEgbEdL+jYlxktgUNC5wmfpSb06c29kTAd4Xz1p3A7PJafdd5GCUYjP/W/ZF cvef7zFL0mylTCNnZxZFu9yEAXpAEX8c13m/ADHzFplL1VprS2G116MwugAX5nSXhiIZ ImFFUH/vETmY+veNy50GvOl0xEi8mjam+XtvFZ6OA+pqVbUvaF7gs/RInwPmb2AD6idr RheDMmrSX9GQmLO9eRovXe1AuRq5DYM2n7OZr2tQTOhgbQ3ogfklTUX4e0P/JGn5MUsv eHLA== X-Forwarded-Encrypted: i=2; AHgh+Ro20sJTAB1uul8YtHaU6sYdT+5235fj4Lvam7yGuazwMpezvTzALvrskWda4Vf6z/eMKIwqqpBaPYdH@gnusha.org X-Gm-Message-State: AOJu0YyJSk6xk6WoH9rKbpLPY62yvoVRfnRTLmUT3nd9iXus5oonYHdq xAo7sk5xNGuQ//rZPajzsfIyOvVe5uwNqa8dXN84YonlVjEDmgpd1k/G X-Received: by 2002:a05:6820:7082:10b0:6a3:7e5d:3e26 with SMTP id 006d021491bc7-6ac96c49795mr1556902eaf.46.1785270313632; Tue, 28 Jul 2026 13:25:13 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPSxzp46EeF3CxUYI37lsAyT+y+VoIX9G9xzWEhd6mFmSA==" Received: by 2002:a05:6870:b50d:b0:456:be08:f0b2 with SMTP id 586e51a60fabf-4579d56fbccls4155049fac.0.-pod-prod-07-us; Tue, 28 Jul 2026 13:25:06 -0700 (PDT) X-Received: by 2002:a05:6808:2396:b0:496:a36:b5e5 with SMTP id 5614622812f47-4ad5b85c58dmr2182903b6e.17.1785270306533; Tue, 28 Jul 2026 13:25:06 -0700 (PDT) Received: by 2002:a05:6402:501a:b0:69c:20b8:fa6f with SMTP id 4fb4d7f45d1cf-69f8f2a6afamsa12; Tue, 28 Jul 2026 13:18:25 -0700 (PDT) X-Received: by 2002:a17:907:97c4:b0:c16:88ec:358 with SMTP id a640c23a62f3a-c1f720f7781mr212645666b.39.1785269903776; Tue, 28 Jul 2026 13:18:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785269903; cv=none; d=google.com; s=arc-20260327; b=GfCsXtihYhPXbMENrVGve4l+rN6UPo/hMK5gsp8464481VtbEnvyieTsER4XzKeL0i 0uWJTgSeHAnMEXS/TOf8URCFEipA2EmCa1id8JePv23xqBBVcvk29UWF+ajFl/+sgIpn o1A0GqXffEkXU4Q8d7YPt46byh7xhDDUgVYV3coT3n6rrw4v7EtfFJZC8+Gf0xAJo7T/ YHs7324S1geT5WyUumJLGbOzxjbd3oIhHZ0N1nJTy2nMZ1Lrg7VDio7JEHJpMZlGQ1jE vlLJ+M5YfwVR8rtMXDNIjqu755cdbu/Ur87L365y+Ipqac8eoPUSK48HZwGLrbMHu+Er yNBA== 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=HZIWfgO0fw+8N7unwnvR92d/u7LvI7yqtOJ2ly3Fwiw=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=V7mL+UqwN76vBdWx3LVP7ZnRxthqh3KUhA/0ozkYoBlowhY6HBBl8hB79sLBxxO5oc 3zasxTG89I3sTs9k60UndMOnBaER8EgfsXsQgeJLv5cCpRtZWTUh0HpX3bxGYgYIAPgA jbZZkYLUi38bry1Ocgxs2kX1LexZgXh1ml8Qb+DvPbMfx1cWu5aS3HKwGqkfj/iWbS6J Ni7eK6itCH/XlQIH25sJrmnl9yErL5gkQlzLzyBuQbGScy+7SmYjYf0R0dvh0DzjAw2p fhk/d3q0y5SXDLefh7PAOCQmB0sfOXX02AX7R0WifGCFArLuJu3ZZ9gH0FCVzi9VGpN6 xuqw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=l5Zmm3AA; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-c1f83c0e8fbsi914366b.1.2026.07.28.13.18.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 13:18:23 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22; Date: Tue, 28 Jul 2026 20:18:18 +0000 To: waxwing/ AdamISZ From: "'Fabian' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: BIP draft: CISA for Taproot Key Path Spends Message-ID: <-xmuFTwytNGFB-4IxZbIsQ02dLSKDNXTtJr9AVPdIIII5kmIppZpYqYvGv4ZRgVkJpY4PJzAjzRJfSOrcT9utM-KDdCT-a_6XCy8d80K9e8=@protonmail.com> In-Reply-To: <74cecbeb-94d1-4181-9caa-3f60c54d6b08n@googlegroups.com> References: <74cecbeb-94d1-4181-9caa-3f60c54d6b08n@googlegroups.com> Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 83f17dd195824fafbf75b5ea92d30781e473119d MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_teiQJuE5FnhJAVQu323dd5PZ1qyeSUaRrk1HdWU1c" 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=l5Zmm3AA; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 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: -0.3 (/) --b1=_teiQJuE5FnhJAVQu323dd5PZ1qyeSUaRrk1HdWU1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 reje= cted because no concrete use case justified the additional validation compl= exity." > > Say a bunch of people want maximally weight-minimising transaction (for t= heir consolidation), but don't want to run a collaborative scheme between e= ach other because it's technically hard to do safely (constrained hardware/= software, nonce state handling, etc.). Each of them just want to full agg t= heir 10 inputs, each. > > Not saying it's some super-common-in-practice scenario, but it seems subo= ptimal that you can't do it. So ... I guess it depends on whether "the addi= tional validation complexity" is really bad compared with the utility of th= at specific use case. > > More specifically, though, why couldn't a 'group ID' be folded into the m= arker byte. In your draft you say "The chosen values fall into the range 0x= bb to 0xfe, which is unassigned in legacy script and corresponds to OP_SUCC= ESS 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 gues= s 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 relev= ant for fullagg, not halfagg). Is this just out of consideration for some o= ther reason that (hardly surprising) I'm not aware of? > (I don't believe this suggestion changes anything functionally as describ= ed in the 'Common Signature Message' section; I mean it literally changes t= he 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=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/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 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/74cecbeb-94d1-4181-9caa-3f60c54d6b08n%40googlegroups.com. --=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/= -xmuFTwytNGFB-4IxZbIsQ02dLSKDNXTtJr9AVPdIIII5kmIppZpYqYvGv4ZRgVkJpY4PJzAjzR= JfSOrcT9utM-KDdCT-a_6XCy8d80K9e8%3D%40protonmail.com. --b1=_teiQJuE5FnhJAVQu323dd5PZ1qyeSUaRrk1HdWU1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi wa= xwing,

Thanks again for sharing your feedba= ck! The idea of
incrementing the marker byte with a = group ID is clever
and I agree that it works technic= ally. This triggered
me to spend some more time to t= hink about what that
might look like which is fun bu= t I am still not
fully convinced this is worth addin= g.

> Say a bunch of people want ma= ximally weight-minimising
> transaction (for thei= r consolidation), but don't want to
> run a colla= borative scheme between each other because
> it's= technically hard to do safely (constrained
> har= dware/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 co= mplete 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 signi= ng session isn't. It
would require some kind of comm= unication and holding of
state as well. Please let m= e know if you think
differently here. I am not sure = what your assumptions
are around up-front coordinati= on capabilities.

I also looked into d= ecoupling the parties further but
it does not really= work in my opinion. SINGLE with
ANYONECANPAY only f= its 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
<= span>separate transactions can omit the byte by using the
= default.

> Not saying it's s= ome super-common-in-practice scenario,
> but it s= eems 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<= /div>
within the shared transaction, but probably better for a
scenario as you outline, each party just broadcasts it= s
own transaction with its own full-aggregation grou= p. The
latter has about 10 vbytes of transaction ove= rhead and
both alternatives lose all the coordinatio= n requirements.

However, we could tak= e the multi-full-agg-group concept
to the next level= and half-agg the full-agg signatures
of the differe= nt groups for another round of savings (as
well as a= dditional complexity of course).

So, = back of the envelope multi-full-agg-group steelman
c= alculation for your scenario: 10 participants each
c= onsolidating 10 inputs into 1 output.

Each in their own tx:

  10 x in= put skeleton                  =      1640 WU
  9 placeholders += 1 final (27 + 67)           94 WU
  1 output               &n= bsp;                    1= 72 WU
  tx skeleton        =                     &nbs= p;    42 WU
  total     &nb= sp;                     &= nbsp; 1948 WU (487 vb)

All in one sha= red tx with half-agg on top:

  1= 0 x input skeleton                 =        1640 WU
  9 placehol= ders + 1 R-only final (27 + 35)    62 WU
&= nbsp; 1 output                 &nbs= p;                  172 WU
  share of combined s (32 / 10)     &nbs= p;         3.2 WU
  share o= f 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 fu= lly sketch this out but
I think it should be possibl= e without introducing
additional overhead.

I start to warm up to it because it's clever b= ut 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 (hardl= y surprising) I'm not aware of?

Yepp,= this works just like you describe. The reason is
on= ly 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.

&g= t; 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 differen= t from
potential finger printing issues resulting fr= om unique
mixing of different aggregation types in a= transaction.
I already have some fingerprinting war= nings in the BIP to
make people aware of this.

> While that as a proposal may or may n= ot be a good one, I
> feel like: this is worth me= ntioning at this time because
> (IIUC) it cannot = be retrofitted in after.

Yes, undefin= ed marker values cannot become valid through
a soft = fork, I thought about something like this early on
t= rying 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 interes= ting
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 ther= e is interest being signalled
I will err on the side of sim= plicity.

Best,
= Fabian
On Wednesday, July 22nd, 2026 at 2:21 AM, waxwing/ AdamISZ <ekag= gata@gmail.com> wrote:
Hi Fabian,

Thanks again for the d= raft.

"A more flexible alternative with multiple a= ggregation 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 wan= t maximally weight-minimising transaction (for their consolidation), but do= n't want to run a collaborative scheme between each other because it's tech= nically hard to do safely (constrained hardware/software, nonce state handl= ing, 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 speci= fically, 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 corresp= onds to OP_SUCCESS opcodes in tapscript, so they do not collid= e with opcodes commonly seen in scripts." - but there are a lot of values b= etween 0xbd and 0xfe. I guess this is not a case for bitflags, but just dif= ferent markers where you add a groupID to 0xbd (and with the understanding= - this clearly is only relevant for fullagg, not halfagg). Is this just ou= t of consideration for some other reason that (hardly surprising) I'm not a= ware of?
(I don't believe this suggestion changes anything functi= onally as described in the 'Common Signature Message' section; I mean it li= terally changes the byte, but, functionally).

A ne= gative (for privacy specifically) would be that you tag the different group= s 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 tim= e because (IIUC) it cannot be retrofitted in after.

Cheers,
AdamISZ/waxwing

On Saturday, July 18, 2026 a= t 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-aggregatio= n, or an
explicit opt-out via a marker byte in its w= itness.
Th= e aggregation schemes themselves are specified in the previously
shared BIP 458 (half-aggregation) and BIP 459 (full-aggregatio= n)
drafts. Script path spending follows BIP 341/342 = unchanged.

The BIP draft text can be = found here:
<= br>
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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/74cecbeb-94d1-4181-9ca= a-3f60c54d6b08n%40googlegroups.com.

--
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/= -xmuFTwytNGFB-4IxZbIsQ02dLSKDNXTtJr9AVPdIIII5kmIppZpYqYvGv4ZRgVkJpY4PJzAjzR= JfSOrcT9utM-KDdCT-a_6XCy8d80K9e8%3D%40protonmail.com.
--b1=_teiQJuE5FnhJAVQu323dd5PZ1qyeSUaRrk1HdWU1c--