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
|
Return-Path: <jonasdnick@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C8711C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 19:16:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id A7EB940C57
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 19:16:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 FiamFjEL_xIv
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 19:16:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
[IPv6:2a00:1450:4864:20::530])
by smtp2.osuosl.org (Postfix) with ESMTPS id AA6DA4017E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 19:16:34 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id p4so6685525edx.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 12:16:34 -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:subject
:content-language:to:references:in-reply-to
:content-transfer-encoding;
bh=YXMdYbcA6V3EZ1TJ/GhVzqxzxZ6+ASh3KKB7JhkzYF4=;
b=iRz3GyIuTH1C1txxsmeyYPH5vpUIwAs0Uk7MJw8kYhhPvXioXVKlUjfLXMnRDpO16A
5m8Zl6u1zpkiE39ItiIgQg/rJFxGvUKNcS8tOYb6WaloROHeMuiqxFZlN+Vx3WyriqTZ
8M7Flhlw980T/Vxnj5brPEtaV6lTHVECWnKuCKzPhkzqdkfES+sFGSo8cpyutxPWtWYi
EIrAhYRsmRzdQdhvKbs3iZ5u6r3h99GGXD8X9rdCDwu6RA09SbboJl0cubz8fhnqBtee
RgUOMuX7eu6KiW1xH5Ym8OeVBA6bIo39iLbamdDCqxBkE/WrmAwMy+N3FKyqflQMwFwe
BYKQ==
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
:subject:content-language:to:references:in-reply-to
:content-transfer-encoding;
bh=YXMdYbcA6V3EZ1TJ/GhVzqxzxZ6+ASh3KKB7JhkzYF4=;
b=vChxF+V+6P6CaYIlkynUFBvQzRsPJOaLq+uFCHd4qsnai4CqHduL1vu/il3r42nHzh
akZCrXRytQYniegywi3HYNwxFaU8y0WXf1DsMV1qd6IouQd5JfiQq/K1abnEixopjvmg
2AIJyjnqm7nsbbWmYUdplQw730qRLYJatGpJCjfbHZuyoVjosknHDQEWYxYwHYA7UvL2
aZTdf+kMmKF7KvqKFw2giuOLB8PoRXnFba0wdhVVbO18uVcbTXGogowMcdCeg35Xy/oT
JGDkn4+nV6+tZC73/Uw0Tg38dYSDeNvs17Frp5pjJEsX+zYGrevDqroSmvrxyUAD5lbJ
IwZg==
X-Gm-Message-State: AOAM531pjVzRcRvGNPCbjI99i1A2d20wIpQR7XegdUhqyFekWiE9yK4k
RSk/gS5lT6AfomRosxWWvHs=
X-Google-Smtp-Source: ABdhPJxhU0Z/Szm0xbp6MYQx0Iwgua/OW7e1pSqTMjU1ReWebzQugRd5ZXPKzAIm4tBHbFp9Onllfw==
X-Received: by 2002:a05:6402:2945:b0:41d:aad:c824 with SMTP id
ed5-20020a056402294500b0041d0aadc824mr37300504edb.364.1651173392768;
Thu, 28 Apr 2022 12:16:32 -0700 (PDT)
Received: from [192.168.1.12] (188-22-200-58.adsl.highway.telekom.at.
[188.22.200.58]) by smtp.googlemail.com with ESMTPSA id
r20-20020aa7da14000000b0042617ba63cdsm1987654eds.87.2022.04.28.12.16.30
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 28 Apr 2022 12:16:31 -0700 (PDT)
From: Jonas Nick <jonasdnick@gmail.com>
X-Google-Original-From: Jonas Nick <jonasd.nick@gmail.com>
Message-ID: <ca43c9b6-4219-9f6b-866a-ed7efcf17857@gmail.com>
Date: Thu, 28 Apr 2022 19:18:34 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Content-Language: en-US-large
To: Olaoluwa Osuntokun <laolu32@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>
<CAO3Pvs9t0H_TpqihPLeknHX30dmtzUgoA+-7uV4UOnrmacsAtQ@mail.gmail.com>
<CAO3Pvs9sCU+zV9UPdrQ4xcF08vLy5zoA_4PUC6F5QjaHNo8uYA@mail.gmail.com>
In-Reply-To: <CAO3Pvs9sCU+zV9UPdrQ4xcF08vLy5zoA_4PUC6F5QjaHNo8uYA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 28 Apr 2022 20:40:22 +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, 28 Apr 2022 19:16:35 -0000
Happy to hear that the BIP draft is already useful and thank you, Laolu, for
extracting the test vectors.
> an implementation must make the _pre tweaked_ combined key available to the caller
To apply the Taproot tweak with the key aggregation algorithm as specified you
would have to do the following (slightly simplified):
P := KeyAgg(pk_1, ..., pk_n, tweaks = [])
t := hash_TapTweak(P, root)
Q := KeyAgg(pk_1, ..., pk_n, tweaks = [t])
This unnecessarily recomputes the pre-tweaked key aggregate. In the BIP, there
are more places where the specified algorithms unnecessarily recompute certain
values. I believe this is justified if it makes the spec significantly easier to
understand. In this case, however, it's clear that calling KeyAgg multiple times
for the same set of public keys is not intuitive at all. This is something I had
not fully considered before. Thanks for bringing it up.
The approach you're taking in btcd makes a lot of sense to me. But in the
specification, we want to avoid specifying how exactly the tweaks are derived.
In the libsecp256k1-zkp implementation, key aggregation and tweaking are
separated into different functions. But this requires keeping state between key
aggregation and tweaking, which is why we had not chosen this approach for the
BIP. I will investigate how in the BIP, we can also split key aggregation and
tweaking and minimize complexity.
> My reading here is that [...] last party doesn't (?) need to worry about their
> nonces
Your reading is mostly right. Brandon describes correctly how and why to modify
the nonce generation algorithm. I opened a PR that replaces the description of
this signing mode with a precise specification. Indeed, the result is that the
last party doesn't need to worry about their nonce (even if the other parties
use bad randomness).
[0] https://github.com/jonasnick/bips/pull/11
|
