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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 33427C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 11:16:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id F3475408B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 11:16:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org F3475408B2
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=vq7X+mM/
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xi9-7ysX7uM5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 11:16:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 02BA640139
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
by smtp2.osuosl.org (Postfix) with ESMTPS id 02BA640139
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 11:16:48 +0000 (UTC)
Date: Wed, 20 Jul 2022 11:16:40 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1658315806; x=1658575006;
bh=S9JkBgot1fCe81ZS9gcCIr/atwdod3UtFsPr8AhAek0=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=vq7X+mM/6LysSbnE79R/qfqAUaUVU5komkLAW/AJHDs0vlIfQEwI0TI1X/V+s8DAL
BrgNpalXJ840xMbq5xIhamMjEnwIWkAICSy3L9ndzBwF4lYSiodt1JuURGlEpfTvdM
FGJNu4UPoFEoC23M8Vi8SOcF0nZ9GDtuezJWkvF9fqB3NFsgfi5xenv/DtOfH/Iwf0
PsC+NFWXUSa9qXMcnByOXlWeObJbDJ0avm3u9YqI32MXcvDXbPcUxAjcdgujBGHpZ7
P8RDr4EjiRf5raeCKCuPCm23DFuj9tCPwOsVfpBqJFNc9a48eXK9Rv2Hm57nnqM/tY
nUfMLObdyWcug==
To: Jonas Nick <jonasdnick@gmail.com>
From: Michael Folkson <michaelfolkson@protonmail.com>
Reply-To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <_B_M5x2e1pkA8CmR-EY7NaMHZwBFJ3ST3GrEHzfL4P68CVsCgNKLb4OycJM7JSp625jnh7R5LSQXuRY1Ve0-kr0FKVrBdWnMh149YTNk78M=@protonmail.com>
In-Reply-To: <2f511890-23a7-882a-332c-85cda02fba7a@gmail.com>
References: <33f275c2-06b1-4b4a-2a75-cafe36836503@gmail.com>
<uxodWlVSmJqvVHDuGevdDbsc5lXiyV6zONlNJtj6gDylkTXQzkPPokLXKJAVULMwPbduJJ7Fb-s0ZYKpduvIZ-LkCsfXClkDH5WhOFsTHts=@protonmail.com>
<2f511890-23a7-882a-332c-85cda02fba7a@gmail.com>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 20 Jul 2022 11:33:20 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 20 Jul 2022 11:16:50 -0000
So this half aggregation BIP draft could potentially play the role that BIP=
340 did for BIP341/342 but it is too premature to start formalizing what th=
e equivalent of BIP341/342 for this draft BIP would look like. And given th=
ere are use cases for this half aggregation BIP that can be worked on today=
(e.g. Lightning gossip [0], Lightning gossip seems to be a very interestin=
g research area at the moment with a number of possible upgrades) it makes =
sense to focus on those first.
There is a section[1] in the CISA repo which I missed originally that descr=
ibes some of the challenges of implementing CISA/CISHA as a consensus chang=
e. A couple of things that stand out to me if this was attempted in the lon=
g term. One is that there would almost need to be two tiers of verification=
: verification for single signature key path spends where CISA, CISHA could=
be applied and verification for Taproot script paths where CISA, CISHA cou=
ldn't be applied. It could even be the case that a new output type is defin=
ed specifically for the CISA, CISHA use case where there is no access to a =
script path at all (i.e. where users don't have a need for anything other t=
han a single signature spend path). With SegWit v0 (and today with SegWit v=
1) the intention is to get the entire community to move to the new output t=
ype. But there could be a long term future where you pick an output type de=
pending on your use case. I recall that Mimblewimble only worked if scripti=
ng was ditched entirely and every spend was assumed to be a single signatur=
e spend.
Anyway...thanks for indulging me on the long term stuff :)
[0]: https://github.com/ElementsProject/cross-input-aggregation#sigagg-case=
-study-ln-channel-announcements
[1]: https://github.com/ElementsProject/cross-input-aggregation#integration=
-into-the-bitcoin-protocol
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, July 17th, 2022 at 21:45, Jonas Nick <jonasdnick@gmail.com> wrot=
e:
> To be clear, whether "half aggregation needs a new output type or not" do=
es not
> become clear in the draft BIP because it is out of scope. Half-aggregatio=
n has a
> few possible applications. The draft only specifies the cryptographic sch=
eme.
>
> The StackExchange post you link to argues that CISA requires a new output=
type.
> The same argument applies to half aggregating signatures across transacti=
on
> inputs (CISHA, if you will). The only difference to "full aggregation" is=
that
> the transaction signature is a single half-aggregate signature instead of=
a
> 64-byte signature. You're right that it's possible to do batch verificati=
on of
> Taproot output key spends (Schnorr signatures) and script spends (key twe=
aks).
|
