diff options
| author | Russell O'Connor <roconnor@blockstream.io> | 2018-01-30 18:25:55 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-01-30 23:26:17 +0000 |
| commit | 2e4e1cf0b92bc79c157125750623d8f4f50834e8 (patch) | |
| tree | 108d03f0d3c4efd5e3898ce7029bce03ed99a34e | |
| parent | efbda90ad1314ea6ff5ac7350f72fa57cad33455 (diff) | |
| download | pi-bitcoindev-2e4e1cf0b92bc79c157125750623d8f4f50834e8.tar.gz pi-bitcoindev-2e4e1cf0b92bc79c157125750623d8f4f50834e8.zip | |
Re: [bitcoin-dev] Design approaches for Signature Aggregation
| -rw-r--r-- | b6/09a9d1215a42452b9dfbb9bc74e68be1a441f0 | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/b6/09a9d1215a42452b9dfbb9bc74e68be1a441f0 b/b6/09a9d1215a42452b9dfbb9bc74e68be1a441f0 new file mode 100644 index 000000000..40bd0de85 --- /dev/null +++ b/b6/09a9d1215a42452b9dfbb9bc74e68be1a441f0 @@ -0,0 +1,120 @@ +Return-Path: <roconnor@blockstream.io> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 9E685F3A + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 30 Jan 2018 23:26:17 +0000 (UTC) +Received: by mail-io0-f172.google.com with SMTP id m11so13370329iob.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAMZUoK=A0CXVw81TeKhRSwPOp39qwqwyQ0_zoKLq8kONko14Ng@mail.gmail.com> +References: <CAMZUoK=A0CXVw81TeKhRSwPOp39qwqwyQ0_zoKLq8kONko14Ng@mail.gmail.com> +From: "Russell O'Connor" <roconnor@blockstream.io> +Date: Tue, 30 Jan 2018 18:25:55 -0500 +Message-ID: <CAMZUoKk4n_2=GZE1rsRPtGFg6FMpvSbxNhj8o5tLVDcOWmoGCw@mail.gmail.com> +To: Matt Corallo <lf-lists@mattcorallo.com>, + "Russell O'Connor via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <roconnor@blockstream.io> +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 + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= +ue, Jan 30, 2018 at 2:12 PM, Russell O'Connor <span dir=3D"ltr"><<a = +href=3D"mailto:roconnor@blockstream.io" target=3D"_blank">roconnor@blockstr= +eam.io</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= +margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"= +ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>and the= +re are probably other designs for signature aggregation beyond the two desi= +gns I'm discussing here.<span class=3D"HOEnZb"><font color=3D"#888888">= +<br></font></span></div></div></div></div></blockquote><div><br></div><div>= +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.)</div><div><br></div><div>Being abl= +e to allow aggregation to be compatible with future script or opcode upgrad= +es is still very difficult to design.<br></div></div></div></div> + +--089e08265de870ec05056406b00a-- + |