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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 41A0DC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 17:50:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 0F7DB60EF9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 17:50:25 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0F7DB60EF9
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=mail.wpsoftware.net
header.i=@mail.wpsoftware.net header.a=rsa-sha256 header.s=default
header.b=XHEVdmMt
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 20_pYW-zgpPc
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 17:50:24 +0000 (UTC)
X-Greylist: delayed 595 seconds by postgrey-1.37 at util1.osuosl.org;
Wed, 26 Jul 2023 17:50:23 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D331060EE1
Received: from mail.wpsoftware.net (unknown [66.183.0.205])
by smtp3.osuosl.org (Postfix) with ESMTP id D331060EE1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 17:50:23 +0000 (UTC)
Received: from camus (camus-andrew.lan [192.168.0.190])
by mail.wpsoftware.net (Postfix) with ESMTPSA id EF232400C4;
Wed, 26 Jul 2023 17:40:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net;
s=default; t=1690393228;
bh=2lO7oCf5QXl75TSSO3EUfHwT9ZM8GPiuXzyKTzg4aj0=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=XHEVdmMthKx23WU/cdP3CgZD/mIXAU2GnBnbhpyoqCD7Yz/ua8iZFMacKR2ZzqKVE
2sjRL0WiLYy/U6hXzEFSeowWfPmULQrM+CITPJQYq56r/jJg0Qy8LlBKSSBauA8i9d
kqhBIEjpnvh/hB5o42gpDTGpx162vyzb1clk3FvCqwHuIRznvEp7qX54b9ZOAOHC10
xUOQ9r8JLPDG5z35zn2Pu7x5jKE1CMTdu5cQHqZJuzLfA9ZAIns4wLf43srE26JibF
oUbqiS8xYksima4invPnOOVzWm/bs+uwa9AXXf2WVByQj2io/3iP5tuXs+ySjtQ0SN
Wsy8tqOIuzIeQ==
Date: Wed, 26 Jul 2023 17:40:26 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZMFaioPPIx3w+HlP@camus>
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
<ca674cee-6fe9-f325-7e09-f3efda082b6b@gmail.com>
<YwMiFAEImHAJfAHHU7WbN1C1JuHjh0vC18Hn61QplFOlY5mEgKmjsAlj2geV1-28E36_wgfL9_QHTRJsbtOLt73o9C4JfoVt8scvYGzKHOI=@protonmail.com>
<CAJowKgJ61nWBHMfNVx7J+C1QwZZMQ9zUaFQnAw1roXiPfi5O6A@mail.gmail.com>
<CAJvkSsdAVFf44XXXXhXqV7JcnmV796vttHEtNEp=v-zxehUofw@mail.gmail.com>
<CAJowKgJFHzXEtJij4K0SR_KvatTZMDfUEU40noMzR2ubj8OSvA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="9i61HOpSYhxQer3V"
Content-Disposition: inline
In-Reply-To: <CAJowKgJFHzXEtJij4K0SR_KvatTZMDfUEU40noMzR2ubj8OSvA@mail.gmail.com>
Cc: Tom Trevethan <tom@commerceblock.com>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
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, 26 Jul 2023 17:50:25 -0000
--9i61HOpSYhxQer3V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wro=
te:
> personally, i think *any* time a public key is transmitted, it should come
> with a "proof of secret key". it should be baked-in to low level
> protocols so that people don't accidentally create vulns. alt discussion
> link: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf1404=
06
>
POSK is not a panacea. For example, if you were to try to eliminate
rogue key attacks in MuSig by using POSK rather than by rerandomizing
the keys, the last person to contribute a key could add a Taproot
commitment to their key, thereby modifying the final key to have a
Taproot spending path that other participants don't know about. If they
did this, they'd have no problem producing a POSK since Taproot
commitments don't affect knowledge of the secret key.
POSKs are also logistically difficult to produce in many contexts. They
essentially require an interactive challege-response (otherwise somebody
could just copy a POSK from some other source), meaning that all
participants need to be online and have secret key access at key setup
time.
In some contexts maybe it's sufficient to have a static POSK. Aside from
the complexity of determining this, you then need a key serialization
format that includes the POSK. There are standard key formats for all
widely used EC keys but none have a facility for this. If you are trying
to use already-published keys that do not have a POSK attached, you are
out of luck.
If your protocol requires POSKs to be provably published, you also run
into difficulties because they don't make sense to embed on-chain (since
blockchain validators don't care about them, and they're twice as big as
the keys themselves) so you need to establish some other publication
medium.
If you want to support nested multisignatures, you need to jointly
produce POSKs, which requires its own protocol complexity.
The MuSig and MuSig2 papers say essentially the same thing as the above;
it's why we put so much effort into developing a scheme which was
provably secure in the plain public key model, which means that POSKs
are superfluous and you don't need to deal with all these logistical
hurdles.
--=20
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--9i61HOpSYhxQer3V
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmTBWogACgkQxYjWPOQb
l8H3yAf+NgXBr9/jUkDzf4780qlV3Z8ecO1nICVwdvE8Id3DhDHbptsW3QXQ9Yxo
6YDcMFI3AXd3ZfdjmBN2k/PFSvE4R2TxU2SKCpP1MqJcV5FTurkJOnPJ62LS9odv
eZqdVqH8E4U+IDFtgmG1amPyxqtiNicsAw3jQD+Y6AJjtxP8j7ovG+rgf9V+mmjg
kgeg21ohImyasQBraCR7rCBmvj3TpoGEj1NpNSBx8RYv5dv/atv4wMIWP7voEOWZ
v7w/q7IsQnykzr7eZHNPolm5mz67EcGO6fWyakSsiGdv2egL6iV2hWyvvVq/ONvA
/OLIsCPV/pkKMiEeVqeMFo/zRDaM1A==
=ptxZ
-----END PGP SIGNATURE-----
--9i61HOpSYhxQer3V--
|
