From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 31 Jul 2026 07:19:39 -0700 Received: from mail-ot1-f63.google.com ([209.85.210.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wpo5J-0004zh-TJ for bitcoindev@gnusha.org; Fri, 31 Jul 2026 07:19:39 -0700 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-7ee50225cc7sf1427926a34.1 for ; Fri, 31 Jul 2026 07:19:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1785507572; cv=pass; d=google.com; s=arc-20260327; b=XDMjszrgurCLECo2KqfnDyt0mOJV5s4PF0HRXQaqya33h0J2fge519A/nIXKLDuPO+ TgMutvgXKEutSOkhdsrR7Vv5A09FMJp/xt5fT4k0Vypikih/oIQGrWr7vyQKWs0zZRg2 kxLPJNV5mqh1sIZ5OflEvrCcH79r2H05CFZNkLP4qNCl1CJk+3F2mIh/uPPOQu3Jfyxt q7yh10LOTiuTrk5Sb5KNW7Fq60xhh5yB1cH5m10C9fCtS3ILQo2PV7iN3V48wOf52A34 t7YHSdXkccHkiCkfLRdrBxOQBvQ8VYmEuAwFTpImkn8d2qFwuwRrwAZnPxpQlMLSaJAU +4jg== 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=8msh9hiSWGcN+Su/9hiNuEDrOlzJzktsuIDz4/00mVY=; fh=sbUUOHno1AMph9rBkjYRmelvjeH3akBhDjmPUhQUtGw=; b=UgSRLu5/xR+gMp9i7AbscDI3qNQj4JpphTEGEqOzpal3wz1ql4zBWaDYl44YK2lF9b VWPAJD9ClABVuk01D3pE9Ewq7RQXs1ubCEYYorwIe+e5UTar9e7oGx1S7FfmWlxGR8fB DZFLYdc8g6ot7Gcdnq5wEOQdIj6I7RylYP3Diu9H6MsXvBAbXfeHZe3xVOlelILaFngL fct3hBD8w/0W9hpv5ZSz6lMQ4whWZRsCJpfV7Hefrfod+ZnP1PpSFNVeAGWeP6YTbwt+ JaVpnt4Px1eTxzsmy9TxrorsIhqFSqRVpFp4/2EsVTfx5E7fh4E4rY1d08i5n+z9//qO O6XA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=GN0tRKPc; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.102 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=1785507572; x=1786112372; 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=8msh9hiSWGcN+Su/9hiNuEDrOlzJzktsuIDz4/00mVY=; b=iQBtvRYmWLKP4/hI7bFOCT/7jBbYESkvqbooJ9LB+dNZYE4U3AM+zVxq3DFzuy9Hkj UcKsk8YYHAwkJuV675v8sZfP4h6cuZb0tOzMGGVHUNcXT7Db/1VzdUSMkFzVkGloiFDP EkxyrgPmyAe3im2rsTOz+mPhzIP/nDqY7sI47CnRfwFm15Sn6RdxFH6CsiqJMJRqe3y1 WiN7Bthi9HC4IVCHhI9fOaV8LzSS0rR4A2c1TVQcIiuCGdVFbGM6LtnW1f3BmatNKQVb Ie/osMtxzRVnBDbuoNV1QKndCR8tZ2PgWQ/BPsjSE7/vuBJ/aTmrsTFoyY/jK2hmMfO/ k0Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785507572; x=1786112372; 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=8msh9hiSWGcN+Su/9hiNuEDrOlzJzktsuIDz4/00mVY=; b=PElMPTxzdoFN+oZcQE5cJf3mIvg3oSDvv+XrmFkqOzwjaBn+DoRr3V8D1V7g0k+HWl K69/iLnQwaRH3d4edD6+mcNmkitNZPAdPXkPVk+FiMpc0p8IGT+HePt+F8yT+K51y153 lifSUZyuFKvnb7DxY7XNqSQkr8/rJAvzeUvf3FGu/lxl5J5kx8yht8ssgXUozv/NTd3P SwxRzPF0RKrcDmGXKtHwb4SsMK2E85K1s44j8gFKpj1utiPaizsWPmJu7ndlU8VOS25S 7mTnG1Xb9m79Ul5GynfC7bA6QAaa/RdDrpGbI7rw1IKpJ19pjvVvJGu3tTBT86cAhRB7 Gnzg== X-Forwarded-Encrypted: i=2; AHgh+Rox14kt0plkAxCsKmDnFdD4h4qnrVE4i2KUNKqKVByVnpsr/SpHJghITCHLEiHuPDoER01mH48zHVKf@gnusha.org X-Gm-Message-State: AOJu0YwZEBEmWgsApNNwXe9IqY0Ci7PLboj7h9GEerJP1l2YPuVdIrn+ KTYK758OcXgwJLo+swUSU3SvyCvjCagbLy6DgD3kequEmMjg88Bd8ZDO X-Received: by 2002:a05:6820:16a4:b0:6ac:a994:8794 with SMTP id 006d021491bc7-6ae4317b7f1mr543095eaf.7.1785507571522; Fri, 31 Jul 2026 07:19:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPReJDbTjJ6ZThe0wQbbmeiS2rojwClSqinHebYSowjLbg==" Received: by 2002:a05:6870:5154:b0:454:e0fd:42f0 with SMTP id 586e51a60fabf-458b934d0e0ls1551600fac.2.-pod-prod-01-us; Fri, 31 Jul 2026 07:19:26 -0700 (PDT) X-Received: by 2002:a05:6808:148a:b0:492:3ed0:9073 with SMTP id 5614622812f47-4af5dfd1573mr217134b6e.4.1785507566072; Fri, 31 Jul 2026 07:19:26 -0700 (PDT) Received: by 2002:a05:600c:e556:20b0:495:453b:241b with SMTP id 5b1f17b1804b1-4980582e772ms5e9; Fri, 31 Jul 2026 07:15:30 -0700 (PDT) X-Received: by 2002:a05:6000:471e:b0:47f:943a:fb28 with SMTP id ffacd0b85a97d-47fd2b44bfemr4980549f8f.38.1785507328373; Fri, 31 Jul 2026 07:15:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785507328; cv=none; d=google.com; s=arc-20260327; b=J6LNUasBVKvmuFxvEedP2AGtQoWBoi2TrgbPEsZ9TiLySIAyhBuqSGu7yn1/BWG2Be Wu6MIxafVjlRQJDxdrUBu0u89c7ziFaEDiRAFlUuiBtkUHgoTP1in6smvd2VfKHfupnr zviVmyf6mVoQb3Da+BLMYoRyBEmKYGt55PR+bIE3sz5FDUs204Wvez5owdX+pEBP7Bfw s9d5BvkJTAsXWOuNQTUaaIfP7duKo6zkeUDjZtcVcXfxu4IAwkQJbiIsekCBBYphyQuZ UzTRQ6PlnPJDN7S9tUT0R0dGp6Xm0pA0lzZYA8VPng/Op3HMfAe65Ydpym5u/PPAaVY0 m1/Q== 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=Re8wpjugUc+OQfw62BZ8BIMq5UNMUHX4fjqrj//JhBw=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=WjuGGHjcqywr3aZ5G7589mLC6ZZv1XrfdEJAVuHXymvC6K6Esaszg37e0ASC0s6GN/ k0lexmtiRWTKlLmy/w5ZXJeQRwOyaZi8x8e2hLWCfYkil6/XyQJn9NXsaay3A67i/J9G wiT7s+1BP6SfYmHWCrkb5b5UWfXswyYErR5cucre7Xq/ege1Ww5gC+RhjeVRszHrHAk0 aC/CkVcsRBsmb2MWnu3buufCNmJILPkwRsr/E2J7u5TPS1VMvdYcAzxOZslwUWHUoBVQ OoS/xzB/j4JtQlaW1g0j1eSVJFiW1TSgQ4rb4KLVTkjVQYTyJySUR4e9LBwDKzT7ft1b +l0w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=GN0tRKPc; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.102 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-43102.protonmail.ch (mail-43102.protonmail.ch. [185.70.43.102]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-47fd43ed685si32332f8f.2.2026.07.31.07.15.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 07:15:28 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.102 as permitted sender) client-ip=185.70.43.102; Date: Fri, 31 Jul 2026 14:15:21 +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: In-Reply-To: <0a59ffec-6960-4919-80a6-9ca45203d858n@googlegroups.com> References: <74cecbeb-94d1-4181-9caa-3f60c54d6b08n@googlegroups.com> <-xmuFTwytNGFB-4IxZbIsQ02dLSKDNXTtJr9AVPdIIII5kmIppZpYqYvGv4ZRgVkJpY4PJzAjzRJfSOrcT9utM-KDdCT-a_6XCy8d80K9e8=@protonmail.com> <0a59ffec-6960-4919-80a6-9ca45203d858n@googlegroups.com> Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 379be731cd474cf58d0cbc90160ebac5ba8cf3fb MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_r2T5yFgw6x7XPaU58epiGGEcx4YkWmXIvsT9lX4NOc" 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=GN0tRKPc; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.102 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.0 (/) --b1=_r2T5yFgw6x7XPaU58epiGGEcx4YkWmXIvsT9lX4NOc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi waxwing, > Can I just check I understood you: you're saying do > the half-agg trick as per BIP458 but with the DahLIAS > signatures? It certainly *looks* like it would > generalize (multi scalar multiplication with > randomizers) but I think it'd need some justification > (a reduction, etc.)? I was confused because you say > this like it's a known thing; is it? Yes, that is what I meant. Sorry, the recipe itself has been floated before, but probably not detailed enough that I should have formulated it with as much confidence as I did. There is also no reduction that has been published and reviewed as far as I know. The concept has been mostly talked about in the context of Block-wide aggregation and other use-cases, not in the context of tx-wide CISA. I think the first mention of it is in the Blockstream Research repo where it is described as part of the LN channel announcement use-case [1]. I typically mention it in my presentations when I have enough time to discuss the block-wide use-case in a bit more detail and I mention it in the HRF industry paper [2] section 3.2. I had a longer conversation with Claude about the reduction and I am mostly convinced that this is secure, but, of course, I am not a cryptographer. I let Claude write a sketch of the reduction [3] and I am happy to invest more time into it and flesh it out if other reviewers have convincing evidence that the multi-group-full-agg concept is worthwhile to be included in the final CISA proposal. Thanks for pushing me on making this part more concrete! Best, Fabian [1] https://github.com/BlockstreamResearch/cross-input-aggregation#sigagg-c= ase-study-ln-channel-announcements [2] https://hrf.org/latest/cisa-research-paper/ [3] https://gist.github.com/fjahr/8b193c82c547b241eb682bea1686b390 On Thursday, July 30th, 2026 at 2:13 AM, waxwing/ AdamISZ wrote: >> 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). > > Can I just check I understood you: you're saying do the half-agg trick as= per BIP458 but with the DahLIAS signatures? It certainly *looks* like it w= ould generalize (multi scalar multiplication with randomizers) but I think = it'd need some justification (a reduction, etc.)? I was confused because yo= u say this like it's a known thing; is it? > > I agree with your analysis; the biggest counterpoint being that you don't= lose too much in simply broadcasting separate transactions. The use case f= or coinjoin doesn't work, which would be the obvious objection (fingerprint= ing), and other objections like 'we both want to dual fund a lightning chan= nel with a bunch of consolidated utxos' are too artificial/obscure to be a = big deal. In all this, I'm nodding to the fact that gains would be extremel= y minor for smaller groups of utxo (2-4 let's say). Given the extra complex= ity, not worth it. > > Cheers, > waxwing/AdamISZ > > On Tuesday, July 28, 2026 at 2:25:13=E2=80=AFPM UTC-6 Fabian wrote: > >> 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 schem= e, similar to the bucket concept from early aggregation discussions, was re= jected because no concrete use case justified the additional validation com= plexity." >>> >>> 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 hardwar= e/software, nonce state 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 su= boptimal that you can't do it. So ... I guess it depends on whether "the ad= ditional validation complexity" is really bad compared with the utility of = that specific use case. >>> >>> More specifically, 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 corresponds to OP_SU= CCESS opcodes in tapscript, so they do not collide with opcodes commonly se= en in scripts." - but there are a lot of values between 0xbd and 0xfe. I gu= ess this is not a case for bitflags, but just different markers where you a= dd a groupID to 0xbd (and with the understanding - this clearly is only rel= evant for fullagg, not halfagg). Is this just out of consideration for some= other reason that (hardly surprising) I'm not aware of? >>> (I don't believe this suggestion changes anything functionally as descr= ibed 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 differe= nt groups in the input list. >>> >>> While that as a proposal may or may not be a good one, I feel like: thi= s 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/cf0d4f2142cd0504b16e86739167b1f7ab9= a3a06/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 Grou= ps "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/bitcoin= dev/74cecbeb-94d1-4181-9caa-3f60c54d6b08n%40googlegroups.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/0a59ffec-6960-4919-80a6-9ca45203d858n%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/= WwTIo2TK4GMzl9tDrkf1MWag8LiZghpjWpBEgSzZ_JG2kl12SNjR_sUhhcAwNmaxjwnfe3mCyAE= uTIsLgKoQIXs5aSadnMUgq5f1-xzM2Wk%3D%40protonmail.com. --b1=_r2T5yFgw6x7XPaU58epiGGEcx4YkWmXIvsT9lX4NOc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Hi waxwing,

> Can I just che= ck I understood you: you're saying do
> the half-= agg trick as per BIP458 but with the DahLIAS
> si= gnatures? It certainly *looks* like it would
> ge= neralize (multi scalar multiplication with
> rand= omizers) but I think it'd need some justification
&g= t; (a reduction, etc.)? I was confused because you say
> this like it's a known thing; is it?

Yes, that is what I meant. Sorry, the recipe itself has been=
floated before, but probably not detailed enough that I
should have= formulated it with as much confidence as I did. 
There is also no reduction tha= t has been published and
reviewed as far as I know. The concept has been mostly
talked about in the context of Block-= wide aggregation and
o= ther use-cases, not in the context of tx-wide CISA. I think
the first mention of it is in the = Blockstream Research
repo where it is described as part of the LN channel
announcement use-case [1]= . I typically mention it
in my presentations when I have enough time to
discuss the block-wide use-case in a = bit more detail
a= nd I mention it in the HRF industry paper [2] section
3.2. 

I had a longer conversation with Claude about the=
reduction <= span style=3D"font-family: system-ui, sans-serif; font-size: 0.875rem;">and= I am mostly convinced that this is secure,
but, of course, I am not a cryptograph= er. I let Claude
= write a sketch of the reduction [3] and I am happy to
invest more <= /span>time into it and flesh it out if other reviewers
=
have convincing evidence that= the multi-group-full-agg
concept is worthwhile to be included= in the final CISA
proposal.

Thanks = for pushing me on making this part more
concret= e!

Best,
Fabian

[3] https://gist.github= .com/fjahr/8b193c82c547b241eb682bea1686b390
On Thursday, July 30th, 2026 at 2:13 AM, waxwing/ AdamISZ <ekagg= ata@gmail.com> wrote:
> However, w= e could take the multi-full-agg-group concept
to the next level and half-agg the full-agg signatu= res
of the different gr= oups for another round of savings (as
well as additional complexity of course).

Can I just check I understood you: you're saying do the hal= f-agg trick as per BIP458 but with the DahLIAS signatures? It certainly *lo= oks* like it would generalize (multi scalar multiplication with randomizers= ) but I think it'd need some justification (a reduction, etc.)? I was confu= sed because you say this like it's a known thing; is it?

I agree with your analysis; the biggest counterpoint being = that you don't lose too much in simply broadcasting separate transactions. = The use case for coinjoin doesn't work, which would be the obvious objectio= n (fingerprinting), and other objections like 'we both want to dual fund a = lightning channel with a bunch of consolidated utxos' are too artificial/ob= scure to be a big deal. In all this, I'm nodding to the fact that gains wou= ld be extremely minor for smaller groups of utxo (2-4 let's say). Given the= extra complexity, not worth it.

Cheers,
waxwing/Ad= amISZ

On Tuesday, July 28, 2026 at 2:25:13=E2=80=AFPM UTC-6 Fabi= an wrote:
Hi waxwing,

Thanks again for sharing your feedback! The i= dea of
incrementing the marker byte with a group ID = is clever
and I agree that it works technically. Thi= s triggered
me to spend some more time to think abou= t what that
might look like which is fun but I am st= ill not
fully convinced this is worth adding.=

> Say a bunch of people want maximally weight-mini= mising
> transaction (for their consolidation), b= ut don't want to
> run a collaborative scheme bet= ween each other because
> it's technically hard t= o do safely (constrained
> hardware/software, non= ce state handling, etc.). Each of
> them just wan= t to full agg their 10 inputs, each.

You may ha= ve already had this in mind but to make sure
we are = on the same page: In this scenario the parties do
no= t 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<= /div>
are around up-front coordination capabilities.
=

I also looked into decoupling the parties further= but
it does not really work in my opinion. SINGLE w= ith
ANYONECANPAY only fits parties with one input an= d 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 apa= rt. The explicit sighash bytes
also cost one extra w= eight unit per input, while
separate transactions ca= n omit the byte by using the
default.

> Not saying it's some super-common-in-practice scenario,<= /span>
> but it seems suboptimal that you can't do it. S= o ... I
> guess it depends on whether "the additi= onal validation
> complexity" is really bad compa= red with the utility of
> that specific use case.=

The utility seems limited because of the minor= additional
savings they gain from this. They can us= e half-aggregation
within the shared transaction, bu= t probably better for a
scenario as you outline, eac= h party just broadcasts its
own transaction with its= own full-aggregation group. The
latter has about 10= vbytes of transaction overhead and
both alternative= s lose all the coordination requirements.

<= span>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 steelma= n
calculation for your scenario: 10 participants eac= h
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<= /div>
total 1948 WU (487 vb)=

All in one shared tx with half-agg on top:<= /span>

10 x input skeleton = 1640 WU
9 placeholders + 1 R-only final (2= 7 + 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/gr= oup. I didn't fully sketch this out but
I think it s= hould be possible without introducing
additional ove= rhead.

I start to warm up to it becau= se it's clever but I am
not sure if that is a good t= hing ;)

> More specifically, though, why cou= ldn't a 'group ID' be
> folded into the marker by= te.
[...]
> Is this just out of consideration = for some other reason
> that (hardly surprising) = I'm not aware of?

Yepp, this works just like yo= u describe. The reason is
only that I do not see a r= eal use case justifying it and
I even feel like the = sighash constraints make reasonable
use-cases hard t= o imagine.

> A negative (for privacy specifi= cally) would be that you
> tag the different grou= ps in the input list.

Right, the group numbers = would reveal which inputs
belong together. But for y= our consolidation scenario this
seems like a minor i= ssue and it's not that different from
potential fing= er printing issues resulting from unique
mixing of d= ifferent aggregation types in a transaction.
I alrea= dy have some fingerprinting warnings in the BIP to
m= ake people aware of this.

> While that as a = proposal may or may not be a good one, I
> feel l= ike: this is worth mentioning at this time because
&= gt; (IIUC) it cannot be retrofitted in after.

Y= es, undefined marker values cannot become valid through
a soft fork, I thought about something like this early on
<= div>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 ha= ve 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 potentia= lly interesting
use-cases for the multi-group-full-a= gg feature or to
reconsider if you or other reviewer= s think we should rather
be maximimally flexi= ble in this regard even without a clear
use-case. But unles= s 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 <ekag...@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 ag= gregation (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 a= n
explicit opt-out via a marker byte in its witness<= /span>.
The aggre= gation 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 unchang= ed.

The BIP draft text can be found h= ere:

=
For inline comments, I have opened a mock pull request on my BIP= s
repo fork:
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+..= .@googlegroups.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 https://groups.google.com/d/msgid/bitcoindev/0a59ffec-6960-4919-80a= 6-9ca45203d858n%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/= WwTIo2TK4GMzl9tDrkf1MWag8LiZghpjWpBEgSzZ_JG2kl12SNjR_sUhhcAwNmaxjwnfe3mCyAE= uTIsLgKoQIXs5aSadnMUgq5f1-xzM2Wk%3D%40protonmail.com.
--b1=_r2T5yFgw6x7XPaU58epiGGEcx4YkWmXIvsT9lX4NOc--