1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 605BB1366
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Mar 2018 23:28:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8E65E5E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Mar 2018 23:28:12 +0000 (UTC)
Date: Wed, 21 Mar 2018 19:28:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1521674890;
bh=uFolGca8oWqVYSI18KbElCnRcLUBmE2SR5xLW0F9BGY=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=Obz86RFu7oo6F/HHQyDvX8fYjrfc6ha3Op1WOvzuzDg4d+Oxfz0UGT+BL8YyJe6tB
E1Ev+03KzfmhU+zQb/cp47Zb3lBc1KwRN+JwcexfaWV9lTX6Uht5luXqdpX9C1XRHt
ODZr9oY0t8PNJt4eaN1k/519y2mIY+jfVxSAMOJ0=
To: Anthony Towns <aj@erisian.com.au>
From: ZmnSCPxj@protonmail.com
Reply-To: ZmnSCPxj@protonmail.com
Message-ID: <OKn7sFgvccsvoIDlGE_fFQ8a2EnGkfiWLvzBWs1vI2LdrWdQaO4ufySwLj1GDrykFrT5GI6-gLHDwuiKQOnvUEBe9oHLT3gu0jJJx7gw_xM=@protonmail.com>
In-Reply-To: <20180321112119.GA6588@erisian.com.au>
References: <20180321040618.GA4494@erisian.com.au>
<d_OOMciZ--WI6X8V1PWVCcPGyEFo7AWcNcXls8uUK8itK8pkoUJLRsekBYUdXTRYg_pOinoBQliMFKfzWW48kd3isE6DbkIVoI5frIxOBFo=@protonmail.com>
<20180321112119.GA6588@erisian.com.au>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 22 Mar 2018 01:45:31 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Soft-forks and schnorr 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: Wed, 21 Mar 2018 23:28:13 -0000
Good morning aj,
=E2=80=8BSent with ProtonMail Secure Email.=E2=80=8B
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On March 21, 2018 7:21 PM, Anthony Towns <aj@erisian.com.au> wrote:
> On Wed, Mar 21, 2018 at 03:53:59AM -0400, ZmnSCPxj wrote:
>=20
> > Good morning aj,
>=20
> Good evening Zeeman!
>=20
> [pulled from the bottom of your mail]
>=20
> > This way, rather than gathering signatures, we gather public keys for a=
ggregate signature checking.
>=20
> Sorry, I probably didn't explain it well (or at all): during the script,
>=20
> you're collecting public keys and messages (ie, BIP 143 style digests)
>=20
> which then go into the signing/verification algorithm to produce/check
>=20
> the signature.
Yes, I think this is indeed what OP_CHECK_AGG_SIG really does.
What I propose is that we have two places where we aggregate public keys: o=
ne at the script level, and one at the transaction level. OP_ADD_AGG_PUBKE=
Y adds to the script-level aggregate, then OP_CHECK_AGG_SIG adds the script=
-level aggregate to the transaction-level aggregate.
Unfortunately it will not work since transaction-level aggregate (which is =
actually what gets checked) is different between pre-fork and post-fork nod=
es.
It looks like signature aggregation is difficult to reconcile with script..=
.
Regards,
ZmnSCPxj
|
