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: <jonasdnick@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id BC3B9C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 May 2022 15:30:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A4A19846B8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 May 2022 15:30:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.216
X-Spam-Level:
X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
NICE_REPLY_A=-0.117, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id u5GaZGpwV4ff
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 May 2022 15:30:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
[IPv6:2a00:1450:4864:20::62a])
by smtp1.osuosl.org (Postfix) with ESMTPS id 60AD4846BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 May 2022 15:30:21 +0000 (UTC)
Received: by mail-ej1-x62a.google.com with SMTP id n10so3716561ejk.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 May 2022 08:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=from:message-id:date:mime-version:user-agent:content-language:to
:references:subject:in-reply-to:content-transfer-encoding;
bh=a+ZwfqIeDi1GSoymfJXjONwffhK6nIvAIJvHYr8cCrM=;
b=T26d9gdHnz7LFTWq6z1L56s4Bfb9gxpeRh395Xu0i6HvIBjEWdzI6yGs+HsWGPjyM2
A1zBWvAk7kcCYwETDuuRxpyyhHxjRc8itolkKWbe+blSU5Wqd0qDpAAVfEZ+zkLIqxz9
Cybp3tgesq0BcrMK2xpGeWEqPvIbYiNEPMyiiUj80CBb7UTf3WxXd2KRunS7EIPOXzfm
mDhv/6Fs6dsB9XtpJABNG35dv99lCpxRp8EM8Q1/3bxv8aPEBzIz6j5jKwkYKuC985Kg
SgP2YsVixVul0UWuDz4xXCVqTYdfhDva+2CRT/5iPJ6BLFRlCPCP3IPRIK7RMfT9/gjP
Z6nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:message-id:date:mime-version:user-agent
:content-language:to:references:subject:in-reply-to
:content-transfer-encoding;
bh=a+ZwfqIeDi1GSoymfJXjONwffhK6nIvAIJvHYr8cCrM=;
b=7sCK9LrkI5Pobu9n29Pj9AFTye+mI/vF+QXya2cBBV6MNtLdPg4WawQGYstfKDQrmu
dgtM8fa4Z+lQUWh9g76g4gzr6XYyTFydC7TCYBs7n8kpGaKImAlvtmE8ogLa2N9j56Yb
HbDMg2FpSC6tJ+xAgJtZ3/dMm/08hKCqxC1yb3N5gl6ECsx+SqyIGb2WJ5Jb/lC0AOdd
nX8/f1rrdW0Vng6mRxoWdHWWzfBZho2gO8juHvZRpcgbnH04juwUEXOdQvpFjhkYtX+W
YbgxuxUpulj4pm6pjk36dpwnnefQnMHeIBVbSqzlosX9Da6CJDfVmK9CasRHAxe4pGtM
pI4Q==
X-Gm-Message-State: AOAM531Rh549fZcnJFcMIzEaTWZhsFyZ+Ji4x5hxK3j6gD7IUF9xll60
/7jaZz/jpuOICFiPGfv57+NTKk50mPkKPBCb
X-Google-Smtp-Source: ABdhPJw1iVfK+MO1+6xLy4mhe2d+jEQSpQuv9QxQKEy59DvLALo3yW6i5FUqexrrkjRcb0Rv7mE8bQ==
X-Received: by 2002:a17:907:a406:b0:6ff:29ea:5e3 with SMTP id
sg6-20020a170907a40600b006ff29ea05e3mr2306976ejc.161.1653579019357;
Thu, 26 May 2022 08:30:19 -0700 (PDT)
Received: from [10.12.10.3] (190-2-132-141.hosted-by-worldstream.net.
[190.2.132.141]) by smtp.googlemail.com with ESMTPSA id
g9-20020a170906394900b006febeb51cd5sm614065eje.174.2022.05.26.08.30.18
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 26 May 2022 08:30:18 -0700 (PDT)
From: Jonas Nick <jonasdnick@gmail.com>
X-Google-Original-From: Jonas Nick <jonasd.nick@gmail.com>
Message-ID: <7c4395b0-9bc9-78e6-5a46-dc3eddb8e97f@gmail.com>
Date: Thu, 26 May 2022 15:32:33 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Content-Language: en-US-large
To: AdamISZ <AdamISZ@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>
<yitwgERAsaofLM5dheUZUYyFp0ncU8xyN98xTym3MkCxTch83DkweZN5JYyovVcfxA2Mo7DjTbv1Iku3wBApYiPG_cMwznTytKFpcjYa1O0=@protonmail.com>
<c2a9b488-8d29-d1c6-b2c3-bc17d12b7d65@gmail.com>
<HPRdBVSvEmkPyHkS-175ZYEYyL-ULZAgmhSPh3uwVtfryFOKZUFKUM5QXnSXjwZy3b10sV55f9lhOkZ-ILShaWSWJ7GMN0JmKNweKY6kfLg=@protonmail.com>
<XRFIZf_z1dKNoKvgFJmrgThHcIE_B0JW9mmJL7mE2B2afcgwZn7NuJaK_vXUAvVwWSZ2Nijwz9yhiwYpty6iI3mrJyivdLxL_CtWlEaAhMY=@protonmail.com>
In-Reply-To: <XRFIZf_z1dKNoKvgFJmrgThHcIE_B0JW9mmJL7mE2B2afcgwZn7NuJaK_vXUAvVwWSZ2Nijwz9yhiwYpty6iI3mrJyivdLxL_CtWlEaAhMY=@protonmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 26 May 2022 15:42:05 +0000
Subject: Re: [bitcoin-dev] MuSig2 BIP
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: Thu, 26 May 2022 15:30:22 -0000
Thanks for the detailed feedback. Let me try to summarize your argument: Key
aggregation should fail if there are duplicate keys because this is likely a bug
and continuing might be dangerous. If it is not a bug but a dishonest signer
trying to disrupt, then resuming the protocol and trying to identify the
dishonest signer does not work because partial signatures are not real
signatures.
I disagree that identifying dishonest signers is useless. But if I try hard, I
can see your point that honest signers should not continue in order to protect
terribly broken implementations. Broken could mean that signers reuse nonces,
output their secret key instead of a partial signature, etc. However, terribly
broken implementations are terribly broken. It seems very unlikely that they're
nice enough to truthfully indicate their brokenness by copying someone elses
public key. Perhaps they use the sum of every other key, actually create a
proper public key, or do something entirely different. So I think in practice,
it is implausible to find a single instance of an implementation that doesn't
survive partial signature creation by looking at duplicate public keys.
However, your suggestion to abort in KeyAgg when encountering duplicate public
keys is compatible with the MuSig2 BIP draft. No one can force a signer to
accept an arbitrary set of public keys for the multi-signature, so signers are
always fine to abort at the key aggregation stage to try to protect terribly
broken co-signers. In that sense, the BIP draft takes a more general and
flexible approach. I doubt that identifying duplicate public keys is less
complex. The only consequence of allowing duplicate public keys is that the
`GetSecondKey` is required to loop over the public keys. Aborting when
encountering duplicate public keys also has the added complexity of giving users
the unspecific instruction to "debug signers X and Y" versus "there's something
definitely wrong with signer Z".
As mentioned above, I don't follow your argument that identifying signers
claiming the public key of other signers is useless. I do think the "persistent"
case is interesting. It's easy to imagine persistent identities not tied to
secp256k1 curve points. Only for creating BIP-340 multi-signatures do they use
secp256k1 public keys. These keys can be fresh, or if they are persistent, the
participants may want to rotate them from time to time. So there are plenty of
opportunities for an attacker to overtake a participant and try to disrupt the
protocol. You mention that duplicating keys would require "a Sybil at two
indices", but actually a single malicious signer that copies some public key is
sufficient.
Your analysis of the "spontaneous" case misses that partial signature
verification identifies at least one of the dishonest signers and therefore
allows to make progress. This closes the DoS vector as far as the MuSig protocol
is concerned. If there are multiple disruptive signers, they may not all be
identified in a single round but require multiple signing attempts. Of course,
applications that use MuSig and replace disruptive signers with just some other
arbitrary nym may be so unlucky that it always has disruptive signers. But
that's a problem of the application layer, and it's easy to conceive smarter
peer selection.
I agree that the claim "any signer who prevents a signing session from
completing successfully by sending incorrect contributions in the session can be
identified" is incorrect. We can identify at least one, and that means
applications can make progress. I opened a PR to fix the wording [0].
[0] https://github.com/jonasnick/bips/pull/25
|
