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
159
160
161
162
163
164
|
Return-Path: <brandonblack@bitgo.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 24C02C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 15:33:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 0C565404C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 15:33:55 +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, HTML_MESSAGE=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 (1024-bit key) header.d=bitgo.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 D2eDMCTEJyaz
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 15:33:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com
[IPv6:2607:f8b0:4864:20::52e])
by smtp2.osuosl.org (Postfix) with ESMTPS id 49D6740374
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 15:33:54 +0000 (UTC)
Received: by mail-pg1-x52e.google.com with SMTP id 7so389419pga.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Apr 2022 08:33:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitgo.com; s=google;
h=mime-version:from:date:message-id:subject:to:cc;
bh=jyPj+k0Xwrg2WVfX+94cE2ujPd++2VlBY6YeO9mhMEM=;
b=aEhSJnZuyjVNDlDcrRnLTfGGV4FqkNy6W+a6QtYmsnG652QVE9tmt1poPaPVqOo46I
8xy5uzru9xPwgh4x+ueMUAd4cXJxCFDDTXcYzZ867riPekxwBB10irHzy4X5/vUd2KQQ
EhwV6ZrddvhHgdFUJepdns1Cp1YT6AR5J9mSs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
bh=jyPj+k0Xwrg2WVfX+94cE2ujPd++2VlBY6YeO9mhMEM=;
b=mlh+Jcr3aIbbkz52IkSVKHVH9sTBK2sfm0h/bq0pmU/4j2LkKn1DXPcQfDJzLAPOaB
WDOvFBx4k7w/rzn3pofC7q1FgdjrIDWtD6wi71m9UtqJ+ZJXJyAR0QWuZEOfjLE/W9uQ
CfPsprRZW6fU7PW5owOx77KQpyHgweiq2eiG6XLHhZ6ZDFa9ESwSK2T9K2s+XVCatJ6T
5mY9zFyb5zQlJdcyLgAc5qmU/IkR3UYQr83AytV09xqxTrgYJUePmvjHPrXRZpTn/LFC
G7fasuIgr9b7UAQLZfR1goj1ueDyvrqAVcwNuSSlDUUJuq2xo0+ZvgGk8jsN217ySmF5
cGew==
X-Gm-Message-State: AOAM531EbllShwMgQLBi0JZP7rhvTn/g4814SCrfogXs8af2shgWKqpq
stCZL4AemG9vmNvgIDfTKHXwQy/zd8Kit+ef0NyIm+j4Igg=
X-Google-Smtp-Source: ABdhPJy+xSh3ayzLAooAn4mfkoW47OFrv4q9ZEr+xwDFNaLpPiZeRAAH4qfXW9CnEsbOYMv5dYMbbQ0renf9lLMhEcQ=
X-Received: by 2002:a63:105:0:b0:3ab:e98:5844 with SMTP id
5-20020a630105000000b003ab0e985844mr21407744pgb.218.1651160033392;
Thu, 28 Apr 2022 08:33:53 -0700 (PDT)
MIME-Version: 1.0
From: Brandon Black <brandonblack@bitgo.com>
Date: Thu, 28 Apr 2022 08:33:42 -0700
Message-ID: <CAANCDjPSWzi=-+gvTgCFDUpZb-pmdHxD7Jy5fgKtJoZneCdm1Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000042137805ddb8a723"
X-Mailman-Approved-At: Thu, 28 Apr 2022 15:37:41 +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 15:33:55 -0000
--00000000000042137805ddb8a723
Content-Type: text/plain; charset="UTF-8"
Hi Laolu,
> Finally, can you elaborate a bit on this fragment of the BIP that
describes
> a "short cut" when a specific signers is meant to send their nonces last:
>
> > Second, if there is a unique signer who is supposed to send the pubnonce
> > last, it is possible to modify nonce generation for this single signer
to
> > not require high-quality randomness
>
> My reading here is that if there's a signer that will always send their
> nonce last (possibly the responder to an LN funding attempt or a server
for
> a non-custodial service like Loop), then they don't actually need to
> generate real randomness, and can just fully specify all the new optional
> arguments? If so then this may end up really simplifying the
implementation
> of certain protocols since that last party doesn't (?) need to worry about
> their nonces as long as all the other (?) parties are using strong
> randomness?
I believe this was added in response to an email that a co-worker and I
sent to Jonas. The idea originated because one of our signers would have a
difficult time tracking, restoring, and securely deleting secret nonces
across a signing session, so what was important was that the signer not
have to retain state, rather than that they not have to provide their own
randomness. The result is that the signer also doesn't need to provide
randomness though.
The important property of the last signer's nonce is that any variation in
any other party's nonce, or other values that contribute to the challenge,
must uniformly randomize the last signer's nonce. The sentences following
the one you quote describe exactly how achieve this, particularly:
* Optional arguments become required
* extra_in argument must be composed of all other parties' nonces
These modifications ensure that if and only if the partial signature will
be exactly equal will the same nonce be used in a subsequent signing
session.
Best,
--Brandon
--00000000000042137805ddb8a723
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Laolu,<div><br></div><div>> Finally, can you elabora=
te a bit on this fragment of the BIP that describes<br>> a "short c=
ut" when a specific signers is meant to send their nonces last:<br>>=
; <br>> > Second, if there is a unique signer who is supposed to send=
the pubnonce<br>> > last, it is possible to modify nonce generation =
for this single signer to<br>> > not require high-quality randomness<=
br>> <br>> My reading here is that if there's a signer that will =
always send their<br>> nonce last (possibly the responder to an LN fundi=
ng attempt or a server for<br>> a non-custodial service like Loop), then=
they don't actually need to<br>> generate real randomness, and can =
just fully specify all the new optional<br>> arguments? If so then this =
may end up really simplifying the implementation<br>> of certain protoco=
ls since that last party doesn't (?) need to worry about<br>> their =
nonces as long as all the other (?) parties are using strong<br>> random=
ness?<br></div><div><br></div><div>I believe this was added in response to =
an email that a co-worker and I sent to Jonas. The idea originated because =
one of our signers would have a difficult time tracking, restoring, and sec=
urely deleting secret nonces across a signing session, so what was importan=
t was that the signer not have to retain state, rather than that they not h=
ave to provide their own randomness. The result is that the signer also doe=
sn't need to provide randomness though.</div><div><br></div><div>The im=
portant property of the last signer's nonce is that any variation in an=
y other party's nonce, or other values that contribute to the challenge=
, must uniformly randomize the last signer's nonce. The sentences follo=
wing the one you quote describe exactly how achieve this, particularly:</di=
v><div><br>* Optional arguments become required</div><div>* extra_in argume=
nt must be composed of all other parties' nonces</div><div><br></div><d=
iv>These modifications ensure that if and only if the partial signature wil=
l be exactly equal will the same nonce be used in a subsequent signing sess=
ion.</div><div><br></div><div>Best,</div><div><br></div><div>--Brandon</div=
></div>
--00000000000042137805ddb8a723--
|
