From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 33427C002D for ; Wed, 20 Jul 2022 11:16:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id F3475408B2 for ; Wed, 20 Jul 2022 11:16:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org F3475408B2 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=vq7X+mM/ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi9-7ysX7uM5 for ; Wed, 20 Jul 2022 11:16:49 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 02BA640139 Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by smtp2.osuosl.org (Postfix) with ESMTPS id 02BA640139 for ; Wed, 20 Jul 2022 11:16:48 +0000 (UTC) Date: Wed, 20 Jul 2022 11:16:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1658315806; x=1658575006; bh=S9JkBgot1fCe81ZS9gcCIr/atwdod3UtFsPr8AhAek0=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=vq7X+mM/6LysSbnE79R/qfqAUaUVU5komkLAW/AJHDs0vlIfQEwI0TI1X/V+s8DAL BrgNpalXJ840xMbq5xIhamMjEnwIWkAICSy3L9ndzBwF4lYSiodt1JuURGlEpfTvdM FGJNu4UPoFEoC23M8Vi8SOcF0nZ9GDtuezJWkvF9fqB3NFsgfi5xenv/DtOfH/Iwf0 PsC+NFWXUSa9qXMcnByOXlWeObJbDJ0avm3u9YqI32MXcvDXbPcUxAjcdgujBGHpZ7 P8RDr4EjiRf5raeCKCuPCm23DFuj9tCPwOsVfpBqJFNc9a48eXK9Rv2Hm57nnqM/tY nUfMLObdyWcug== To: Jonas Nick From: Michael Folkson Reply-To: Michael Folkson Message-ID: <_B_M5x2e1pkA8CmR-EY7NaMHZwBFJ3ST3GrEHzfL4P68CVsCgNKLb4OycJM7JSp625jnh7R5LSQXuRY1Ve0-kr0FKVrBdWnMh149YTNk78M=@protonmail.com> In-Reply-To: <2f511890-23a7-882a-332c-85cda02fba7a@gmail.com> References: <33f275c2-06b1-4b4a-2a75-cafe36836503@gmail.com> <2f511890-23a7-882a-332c-85cda02fba7a@gmail.com> Feedback-ID: 27732268:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 20 Jul 2022 11:33:20 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2022 11:16:50 -0000 So this half aggregation BIP draft could potentially play the role that BIP= 340 did for BIP341/342 but it is too premature to start formalizing what th= e equivalent of BIP341/342 for this draft BIP would look like. And given th= ere are use cases for this half aggregation BIP that can be worked on today= (e.g. Lightning gossip [0], Lightning gossip seems to be a very interestin= g research area at the moment with a number of possible upgrades) it makes = sense to focus on those first. There is a section[1] in the CISA repo which I missed originally that descr= ibes some of the challenges of implementing CISA/CISHA as a consensus chang= e. A couple of things that stand out to me if this was attempted in the lon= g term. One is that there would almost need to be two tiers of verification= : verification for single signature key path spends where CISA, CISHA could= be applied and verification for Taproot script paths where CISA, CISHA cou= ldn't be applied. It could even be the case that a new output type is defin= ed specifically for the CISA, CISHA use case where there is no access to a = script path at all (i.e. where users don't have a need for anything other t= han a single signature spend path). With SegWit v0 (and today with SegWit v= 1) the intention is to get the entire community to move to the new output t= ype. But there could be a long term future where you pick an output type de= pending on your use case. I recall that Mimblewimble only worked if scripti= ng was ditched entirely and every spend was assumed to be a single signatur= e spend. Anyway...thanks for indulging me on the long term stuff :) [0]: https://github.com/ElementsProject/cross-input-aggregation#sigagg-case= -study-ln-channel-announcements [1]: https://github.com/ElementsProject/cross-input-aggregation#integration= -into-the-bitcoin-protocol -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ------- Original Message ------- On Sunday, July 17th, 2022 at 21:45, Jonas Nick wrot= e: > To be clear, whether "half aggregation needs a new output type or not" do= es not > become clear in the draft BIP because it is out of scope. Half-aggregatio= n has a > few possible applications. The draft only specifies the cryptographic sch= eme. > > The StackExchange post you link to argues that CISA requires a new output= type. > The same argument applies to half aggregating signatures across transacti= on > inputs (CISHA, if you will). The only difference to "full aggregation" is= that > the transaction signature is a single half-aggregate signature instead of= a > 64-byte signature. You're right that it's possible to do batch verificati= on of > Taproot output key spends (Schnorr signatures) and script spends (key twe= aks).