From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E041DE15 for ; Sat, 27 Jan 2018 17:23:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2AE2319 for ; Sat, 27 Jan 2018 17:23:17 +0000 (UTC) Received: from [30.217.169.144] (66-87-119-144.pools.spcsdns.net [66.87.119.144]) by mail.bluematt.me (Postfix) with ESMTPSA id E38761A0D47; Sat, 27 Jan 2018 17:23:15 +0000 (UTC) Date: Sat, 27 Jan 2018 17:23:12 +0000 In-Reply-To: References: <20180123064419.GA1296@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Russell O'Connor , Bitcoin Protocol Discussion , Russell O'Connor via bitcoin-dev , Anthony Towns From: Matt Corallo Message-ID: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 17:23:19 -0000 Gah, please no=2E I see no material reason why cross-input signature aggreg= ation shouldn't have the signatures in the first n-1 inputs replaced with s= omething like a single-byte push where a signature is required to indicate = aggregation, and the combined signature in the last input at whatever posit= ion the signature is required=2E On January 27, 2018 5:07:25 PM UTC, Russell O'Connor via bitcoin-dev wrote: -snip- >Cross-input signature aggregation probably requires a new field to be >added >to the P2P transaction structure to hold the aggregated signature, >since >there isn't really a good place to put it in the existing structure >(there >are games you can play to make it fit, but I think it is worthwhile)=2E= =20 >The >obvious way add block commitments to a new tx field is via the witness >reserved value mechanism present in BIP 141=2E At this point I think >there >will be some leeway to adjust the discount on the weight of this new >aggregated signature tx field so that even a single input taproot using >the >aggregated signature system (here an aggregation of 1 signature) ends >up no >more expensive than a single input segwit P2WPKH=2E