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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
Return-Path: <christophera@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7DD92C013A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 22:30:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 6264B86EEE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 22:30:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id bD_MMfA0oYva
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 22:30:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com
[209.85.222.48])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 7791F86EEB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 22:30:24 +0000 (UTC)
Received: by mail-ua1-f48.google.com with SMTP id c8so2278865uae.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 14:30:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lifewithalacrity-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=SqOyOnvvFNcgx+WdXWYLEPQenPtWYJk13Jynq1HuLBU=;
b=imfiOuOrOgG8erAs2A4ASwColtFS+K+WkxRSwRDsTxtEWnvT2jxCeUbV+rfl0GAO1W
pc9lNtueRtTsNbfW9qTYarV6cLSbhODC4RkA6WgHM5I+HBl6zlZ6VHfA4mB+eaRSemeG
2ZZ2b4myHE8HJkE9mxWLsIlrIFcfXbd6T9Hg+Se7058FGq2xdwQoppNnl4lQq7m9+RBb
T5shxjPdlPZHu8Hl4ZyySnuHw+5L7rLC77rO7/2tggYlktJpDfxXFa37Ly8LeQN1OeNT
+vo7OSm5m4R/rtDRQyzwi6DuEErk9QBtSgdU02kS5wjVhmvP92z0ruje9fW7pG5bI1ZF
tRZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=SqOyOnvvFNcgx+WdXWYLEPQenPtWYJk13Jynq1HuLBU=;
b=bGtrm0Of00d4YGqbwFUrbFKQhgMc+zOpz9mMc9r7HeZb+Px6TCBgto5ZvRw4EjNCgm
ylrcMrqJWzYeOQcI4yQlTjqloo6iJC2mZ4JV//weHNfUOwrruXhwEsGGJUGJYCgAYMU0
EsM9XFDQf54FbAfUzkmtASA640zhGNdyt63f4zJJTTNGHRTsR11CyPk5TJGCZUNa9qxj
uuVc6pvXS1/OWZLnDKiIlTIHlfTHK/dWJWdnO4RJrnc15Bh/D6kQUsMevH24+33y6shh
428f+N9R6v4VkDvklfHdnMw7+NuICFnLsFaqsUiGf4ICEi4FeDW6pF654wSr49mkIXgx
1lUA==
X-Gm-Message-State: AOAM532ar5NEc7qhaUH+fzxAMVeeLNiO12O+B7i2nRXVyoTaEq/vf1tD
qoo02ClR6z4pmiSQV3rRsZ1yo6bevC4bO5JRgdbpkrX7PlI=
X-Google-Smtp-Source: ABdhPJzFuy9mo6YnqWra6H2kS/Osq1XGicUOotwL2TTPf6Ve+cZywaglnAJeGtkmPnewj6Ho9wImqK/+TG44ZAXfMLA=
X-Received: by 2002:ab0:4244:: with SMTP id i62mr146509uai.37.1613082623080;
Thu, 11 Feb 2021 14:30:23 -0800 (PST)
MIME-Version: 1.0
References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
<CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
<CAPKmR9tcR7gBfJ=EqJ60J=XvsreZgByL+HEfR0_YvwadJRWNhg@mail.gmail.com>
<CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com>
<CAPKmR9sUFJqsxKQS_x9rYZzkEO7hXr6vwAyPnysQPzA91TDjMA@mail.gmail.com>
<CAF90AvkeG53o5H2dZsdsG_c4PxxooMgx-Fv47RWpNNwm_su-hg@mail.gmail.com>
<CAPKmR9vg1BMDQWNDk41N4i4cJ8J6K9GuqSpstFpMFwyiVBYw-w@mail.gmail.com>
<20210211172910.3b550706@simplexum.com>
<CAPKmR9udiK+2gC2qUueAfKm7VBf8csM-3WOz1+-bMNR0iVeGew@mail.gmail.com>
<CAPKmR9t0hta0n4tAqp1SwH4gJ_5cswh-pg4DDAJ=qMhZjtUgYw@mail.gmail.com>
In-Reply-To: <CAPKmR9t0hta0n4tAqp1SwH4gJ_5cswh-pg4DDAJ=qMhZjtUgYw@mail.gmail.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Thu, 11 Feb 2021 14:29:46 -0800
Message-ID: <CACrqygAMG67dajktTcq9hgyhfu2u1NRSHzkM345=jc6NLDUsbg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bdfdae05bb17107d"
X-Mailman-Approved-At: Thu, 11 Feb 2021 23:04:37 +0000
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
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, 11 Feb 2021 22:30:25 -0000
--000000000000bdfdae05bb17107d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I think the key issue here is avoiding xpub key reuse in multisig. Not only
in the future with Schnorr, but we need it today!
Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
for segwit multsig ( e.g.
[90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSw=
yCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
) is the only one used for ALL multisigs offered by that hardware wallet.
As Pieter said, leveraging a HD path parameters can help, but we need a
better, less reusable path for the index.
I personally suggest a simpler solution, which is to create an index using
a PBKDF of the Account Policy (a descriptor with all xpubs and keys
removed), plus optional notes. (BTW, I think double sha256 or HMAC is
overkill).
Example: for the reference bit descriptor that might result in:
```
wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUap=
SCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KS=
RgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZ=
b7ap6r1D3tgFxHmwMkQTPH/0/0/*))
```
What Blockchain Commons (and the Airgapped Wallet Community) call a policy
map would be
```
wsh(sortedmulti(1,,,))
```
A PBKDF of that as would be unique for all 2 of 3 segwig transactions. With
the addition of the addition of the Policy Map creators optional note, it
would be truly unique. The Policy Map and/or PBKDF are small and could
easily added to existing APIs.
So for legacy hardware, we can use existing 48' subtree, but 3' as the
format for this form (2' is segwit), then the desktop can just ask for the
/48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
More sophisticated Airgapped apps you can send
"wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
optionally allow it return something different in a full keyset (i.e.
"[90081696/48'/0'/0'/3'/af3948cg=E2=80=A6'/]xpub6DYLEk=E2=80=A6", and then =
the requesting
app, knowing that it is different from the PBKDF can know what to do if it
needs to what to ask for in the future.
The other advantage of this technique is that the cosigner app can know
what policy it is participating in, before the descriptor is completed. It
may decide it doesn't want to participate in some funky 4:9 with a weird
script, and not return an xpub at all.
Long term I think a commitment scheme should be used, so that you don't
reveal what xpub you offered until all the parties xpubs are shared, but as
Pieter said, we can do that at the same time we do the musig. But we need
to prevent xpub reuse NOW, and I think my proposal easy and could the job.
-- Christopher Allen, Blockchain Commons
--000000000000bdfdae05bb17107d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think the key issue here is avoiding xpub key reuse in m=
ultisig. Not only in the future with Schnorr, but we need it today!<br><br>=
Current common practice by hardware wallets is the 48'/0'/0'/2&=
#39; derivation for segwit multsig ( e.g. [90081696/48'/0'/0'/2=
']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6=
T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b ) is the only one used for ALL m=
ultisigs offered by that hardware wallet.<br><br>As Pieter said, leveraging=
a HD path parameters can help, but we need a better, less reusable path fo=
r the index.<br><br>I personally suggest a simpler solution, which is to cr=
eate an index using a PBKDF of the Account Policy (a descriptor with all xp=
ubs and keys removed), plus optional notes. (BTW, I think double sha256 or =
HMAC is overkill).<br><br>Example: for the reference bit descriptor that mi=
ght result in:<br><br>```<br>wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc=
5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB=
7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmX=
UbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))<br>```<br><br>W=
hat Blockchain Commons (and the Airgapped Wallet Community) call a policy m=
ap would be<br><br>```<br>wsh(sortedmulti(1,,,))<br>```<br><br>A PBKDF of t=
hat as would be unique for all 2 of 3 segwig transactions. With the additio=
n of the addition of the Policy Map creators optional note, it would be tru=
ly unique. The Policy Map and/or PBKDF are small and could easily added to =
existing APIs.<br><br>So for legacy hardware, we can use existing 48' s=
ubtree, but 3' as the format for this form (2' is segwit), then the=
desktop can just ask for the /48'/0'/0'/3'/PBKDF' when=
it requests a new xpub from the hardware token. More sophisticated Airgapp=
ed apps you can send "wsh(sortedmulti(1,,,))"+label and let the c=
osigner app do the PBKDF, and optionally allow it return something differen=
t in a full keyset (i.e. "[90081696/48'/0'/0'/3'/af394=
8cg=E2=80=A6'/]xpub6DYLEk=E2=80=A6", and then the requesting app, =
knowing that it is different from the PBKDF can know what to do if it needs=
to what to ask for in the future.<br><br>The other advantage of this techn=
ique is that the cosigner app can know what policy it is participating in, =
before the descriptor is completed. It may decide it doesn't want to pa=
rticipate in some funky 4:9 with a weird script, and not return an xpub at =
all.<div><br></div><div>Long term I think a commitment scheme should be use=
d, so that you don't reveal what xpub you offered until all the parties=
xpubs are shared, but as Pieter said, we can do that at the same time we d=
o the musig. But we need to prevent xpub reuse NOW, and I think my proposal=
easy and could the job.<br><br>-- Christopher Allen, Blockchain Commons<br=
></div></div>
--000000000000bdfdae05bb17107d--
|
