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 9E685F3A for ; Tue, 30 Jan 2018 23:26:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 175562F6 for ; Tue, 30 Jan 2018 23:26:17 +0000 (UTC) Received: by mail-io0-f172.google.com with SMTP id m11so13370329iob.2 for ; Tue, 30 Jan 2018 15:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wfWAgsq1ce8BFucjkDx/N4BHc4ywDx39tnTuCpJcxag=; b=XAfAEB3Lq323O5eNIoTnNfujI2UwRBJhCCpxlgBipVI4NLC/srgnvGRIlIshOG3lXr pNpqLfGLyL9+0SxD81lZS3BTvDrjcDxnEIPe9MJ7zQQpD3RoNPs98bFrWVW3UuwpurKh 1aXz/tfZKjtmccCH/TBsUTRynHZj9Yk1JPijk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wfWAgsq1ce8BFucjkDx/N4BHc4ywDx39tnTuCpJcxag=; b=nH1vSGmmWDc/J3sEd0JJMHvLqf5+FW2kh333PfcEGfmqaCgS78SxRNo2nyLKvz24in n6+prWA3vkCUQcY8J9HtkzG364mHKFkPwwfffqoK7MGSJmxZ7WrIO/TUphM5rMyh+Afd ylbZPcyvnGnvNo0N6NnhISv1GnDmClZ3wlh5qWEl96tGtMIsDTm9tf32i0fy+xxCpDd+ KL53M0aPTbXtXCxbSPCOEy5u5/aTTL9Y5aQBTekzQB/Y+crOv0z/zK4AxEPLM85xn5kb I/YvsS34DNSWR7XcBp16USvgNgqRqA0aGMwT8KivFFKq+HyO7APNn5UpoTudPvdmMZEl Q7Hg== X-Gm-Message-State: AKwxyteo13R1P2uW139NiNf14lk907c+TH1/HSm0jM6/aMUd3nM7OmvZ TOssfEPVQl1bY8rTFQ3/sBEA4tni6voJgkLMehIpsw== X-Google-Smtp-Source: AH8x224P5KwzgKrCRcO88slP4nC/ZzdbymPjoQs8a5d/ZSklArNuzQntaZGGQhCbrNmwgFbMkGWfIFsGThTivcTgDT0= X-Received: by 10.107.82.15 with SMTP id g15mr34649243iob.157.1517354776308; Tue, 30 Jan 2018 15:26:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.120.10 with HTTP; Tue, 30 Jan 2018 15:25:55 -0800 (PST) In-Reply-To: References: From: "Russell O'Connor" Date: Tue, 30 Jan 2018 18:25:55 -0500 Message-ID: To: Matt Corallo , "Russell O'Connor via bitcoin-dev" Content-Type: multipart/alternative; boundary="089e08265de870ec05056406b00a" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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] Design approaches for Signature Aggregation 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: Tue, 30 Jan 2018 23:26:17 -0000 --089e08265de870ec05056406b00a Content-Type: text/plain; charset="UTF-8" On Tue, Jan 30, 2018 at 2:12 PM, Russell O'Connor wrote: > > and there are probably other designs for signature aggregation beyond the > two designs I'm discussing here. > For example, in private communication Pieter suggested putting the aggregate signature data into the top of the first segwit v1+ input witness (and pop it off before evaluation of the input script) whether or not that input is participating in the aggregation or not. This makes this canonical choice of position independent of the runtime behaviour of other scripts and also prevents the script from accessing the aggregate signature data itself, while still fitting it into the existing witness data structure. (It doesn't let us toy with the weights of aggregated signature, but I hope people will still be motivated to use taproot solely over P2WPKH based on having the option to perform aggregation.) Being able to allow aggregation to be compatible with future script or opcode upgrades is still very difficult to design. --089e08265de870ec05056406b00a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 30, 2018 at 2:12 PM, Russell O'Connor <roconnor@blockstr= eam.io> wrote:

and the= re are probably other designs for signature aggregation beyond the two desi= gns I'm discussing here.=

= For example, in private communication Pieter suggested putting the aggregat= e signature data into the top of the first segwit v1+ input witness (and po= p it off before evaluation of the input script) whether or not that input i= s participating in the aggregation or not.=C2=A0 This makes this canonical = choice of position independent of the runtime behaviour of other scripts an= d also prevents the script from accessing the aggregate signature data itse= lf, while still fitting it into the existing witness data structure. (It do= esn't let us toy with the weights of aggregated signature, but I hope p= eople will still be motivated to use taproot solely over P2WPKH based on ha= ving the option to perform aggregation.)

Being abl= e to allow aggregation to be compatible with future script or opcode upgrad= es is still very difficult to design.
--089e08265de870ec05056406b00a--