MIME-Version: 1.0
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"
Subject: Re: [bitcoin-dev] Design approaches for Signature Aggregation
Precedence: list

--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&#39;Connor <span dir=3D"ltr">&lt;<a =
href=3D"mailto:roconnor@blockstream.io" target=3D"_blank">roconnor@blockstr=
eam.io</a>&gt;</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&#39;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&#39;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--