path: root/83/6bafb3c094daf1020406e95117afde5f6e1328

Return-Path: <hugo@nunchuk.io>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C11C8C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 12:31:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id B18A9871F1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 12:31:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9Ay6eDB5X+28
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 12:31:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com
 [209.85.217.46])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 300BB871DA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 12:31:37 +0000 (UTC)
Received: by mail-vs1-f46.google.com with SMTP id u127so4688455vsc.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 04:31:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=nunchuk-io.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=raIeCFPpSnEELK1rp7QOUf3hRA1iMp5YLK1n0giIoCg=;
 b=jguLGce7yDoZMjyHy1n/cr2U2Wz6mwUYmqkTWpVNEajXoMTANxw7o631W5rle2EMXn
 JOA+TQCAmXDUXlu2WLZSUC5IoVdmM8o1+hILErHjeuuaHOtiWh0BAIFKJYtDnJYP7D7y
 6GgfyR+69C/JGqSIu8dEkxx5SxHhBtdZyo8KBI35S0GlRLUMRY1+WkCBTwtKnKKR+2ry
 1NwJkNaQuKarzz4XlwgFyoVIjT+DbGcBBhkGnk0Xhuy8O+akO2hHhLcdzzBXKMnTHLwq
 cMQXFilwb39slIWxaNE4OgIWCUbg8ooep0B/3sdpaeTZhAHZm1sV9V1AoduGsV+T7YYL
 N/HQ==
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=raIeCFPpSnEELK1rp7QOUf3hRA1iMp5YLK1n0giIoCg=;
 b=Nbz40iH+Ct1zPCcaG+x5fIbysoHjtQ3FgklExmgdCY13Ddo4ZtDyflFEoTrpA8pPee
 D85WWx6RVhs9I2voxRaJWavlcivYT3HjsVSZQ/EDS0YDcRFHtZMHcqdIUZTtV6YEhwRK
 Fvk3j//JLDVGMFig9yCq9niJGROTjgK6WwI/37BEdV3gg7muKxmvhcaWKJlrgpqOmAo9
 pV3oNXJ5IRj0dGXdQxyOMeJDdse5ZskxznMsojsPrYsYfA0CDwa5yR4xX3iFr6bgCm4i
 5JcQ0MpE4QJ8M1ZtvOzKQMYL+hQNK/7gmFWHoXq4VeYIXI0BKsLAvFrSEdX1Q1CO4WBo
 QwKw==
X-Gm-Message-State: AOAM533fLHA3cKatk9zjs5KhnPW242+dGNtOiVOdASSDYt2uEEKxWm7b
 F6Vox5NIIhqZMs3t6gPNtMpYLTJhtIxifT6qugof90sv+J4pMDmGLdSOlA==
X-Google-Smtp-Source: ABdhPJyqo9ZCcf8AxLVnKXoq5qxnRQoIbzV2RcnLIxL3+c5XQ4j71Ezr793mhBDR+wC+XGD+JMN5qPkH2ZsLkgshkOA=
X-Received: by 2002:a05:6102:7b1:: with SMTP id
 x17mr1109844vsg.41.1613133096061; 
 Fri, 12 Feb 2021 04:31:36 -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>
 <CACrqygAMG67dajktTcq9hgyhfu2u1NRSHzkM345=jc6NLDUsbg@mail.gmail.com>
In-Reply-To: <CACrqygAMG67dajktTcq9hgyhfu2u1NRSHzkM345=jc6NLDUsbg@mail.gmail.com>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Fri, 12 Feb 2021 04:31:24 -0800
Message-ID: <CAPKmR9vpTUna+uVYRqcPxdS28FU5CryMWbybCHcCZEoAOacfUw@mail.gmail.com>
To: Christopher Allen <ChristopherA@lifewithalacrity.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002a9df805bb22d1bc"
X-Mailman-Approved-At: Fri, 12 Feb 2021 12:52:48 +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: Fri, 12 Feb 2021 12:31:38 -0000

--0000000000002a9df805bb22d1bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What Blockchain Commons (and the Airgapped Wallet Community) call a polic=
y
> 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 not=
e,
> 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 th=
e
> /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 the=
n the requesting
> app, knowing that it is different from the PBKDF can know what to do if i=
t
> needs to what to ask for in the future.
>

Thanks Christopher, very interesting ideas... A couple of thoughts:
1/ Generating the path index using the policy is clever. However, I think
it has 2 problems. Number #1 is with the above scheme now you have a hard
dependency on (policy map + note) - losing (policy map + note) means that
you will lose access to PBKDF', and hence the funds permanently. At least
with the current soluttions, you can look up what the most common
derivation paths and indices are to recover funds in the worst case.
2/ Number #2 is that this wouldn't necessarily prevent XPUB reuse. It seems
like the above scheme depends on (a) the Coordinator keeping track
accurately of all the existing PBKDF-ed indices and (b) the Signer
truthfully gives the XPUB at the path that the Coordinator asks for. In
reality, neither of these conditions can be guaranteed. For example, the
Signer could lie about the XPUB at /48'/0'/0'/3'/PBKDF' when it just keeps
reusing the XPUB at /48'/0'/0'/2'
3/ Preventing XPUB reuse is an interesting problem, but IMHO it is beyond
the scope of the current proposal. Maybe worth a separate BIP?

Best,
Hugo



On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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' derivatio=
n
> for segwit multsig ( e.g.
> [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWk=
SwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
> ) 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 usin=
g
> 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,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRU=
apSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8=
KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezp=
bZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
> ```
>
> What Blockchain Commons (and the Airgapped Wallet Community) call a polic=
y
> 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 not=
e,
> 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 th=
e
> /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 the=
n the requesting
> app, knowing that it is different from the PBKDF can know what to do if i=
t
> 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. I=
t
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000002a9df805bb22d1bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Feb 11, 2021 at 3:05 PM Christoph=
er Allen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr">What Blockchain Commons (and the Airgapped Wallet Communit=
y) call a policy map would be<br><br>```<br>wsh(sortedmulti(1,,,))<br>```<b=
r><br>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 not=
e, it would be truly unique. The Policy Map and/or PBKDF are small and coul=
d easily added to existing APIs.<br><br>So for legacy hardware, we can use =
existing 48&#39; subtree, but 3&#39; as the format for this form (2&#39; is=
 segwit), then the desktop can just ask for the /48&#39;/0&#39;/0&#39;/3&#3=
9;/PBKDF&#39; when it requests a new xpub from the hardware token. More sop=
histicated Airgapped apps you can send &quot;wsh(sortedmulti(1,,,))&quot;+l=
abel and let the cosigner app do the PBKDF, and optionally allow it return =
something different in a full keyset (i.e. &quot;[90081696/48&#39;/0&#39;/0=
&#39;/3&#39;/af3948cg=E2=80=A6&#39;/]xpub6DYLEk=E2=80=A6&quot;, and then th=
e 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></div></blockquote>=
<div><br></div><div>Thanks Christopher, very interesting ideas... A couple =
of thoughts:<br>1/ Generating the path index using the policy is clever. Ho=
wever, I think it has 2 problems. Number #1 is with the above scheme now yo=
u have a hard dependency on (policy map=C2=A0+ note) - losing (policy map +=
 note) means that you will lose access to PBKDF&#39;, and hence the funds p=
ermanently. At least with the current soluttions, you can look up what the =
most common derivation paths and indices are to recover funds in the worst =
case.=C2=A0<br>2/ Number #2 is that this wouldn&#39;t necessarily prevent X=
PUB reuse. It seems like the above scheme depends on (a) the Coordinator ke=
eping track accurately of all the existing PBKDF-ed indices and (b) the Sig=
ner truthfully gives the XPUB at the path that the Coordinator asks for. In=
 reality, neither of these conditions can be guaranteed. For example, the S=
igner could lie about the XPUB at=C2=A0/48&#39;/0&#39;/0&#39;/3&#39;/PBKDF&=
#39; when it just keeps reusing the XPUB at=C2=A0/48&#39;/0&#39;/0&#39;/2&#=
39;<br>3/ Preventing XPUB reuse is an interesting problem, but IMHO it is b=
eyond the scope of the current proposal. Maybe worth a separate BIP?<br><br=
>Best,<br>Hugo<br><br>=C2=A0</div></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 11, 2021 at 3:05 PM Chr=
istopher Allen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I th=
ink the key issue here is avoiding xpub key reuse in multisig. Not only in =
the future with Schnorr, but we need it today!<br><br>Current common practi=
ce by hardware wallets is the 48&#39;/0&#39;/0&#39;/2&#39; derivation for s=
egwit multsig ( e.g. [90081696/48&#39;/0&#39;/0&#39;/2&#39;]xpub6DYLEkDfCdH=
zh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB=
95nSaFEDhFMK6zSV6D49b ) is the only one used for ALL multisigs offered by t=
hat hardware wallet.<br><br>As Pieter said, leveraging a HD path parameters=
 can help, but we need a better, less reusable path for the index.<br><br>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).<br=
><br>Example: for the reference bit descriptor that might result in:<br><br=
>```<br>wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8=
syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69=
H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmm=
DznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))<br>```<br><br>What Blockchain Common=
s (and the Airgapped Wallet Community) call a policy map would be<br><br>``=
`<br>wsh(sortedmulti(1,,,))<br>```<br><br>A PBKDF of that as would be uniqu=
e 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.<br><br=
>So for legacy hardware, we can use existing 48&#39; subtree, but 3&#39; as=
 the format for this form (2&#39; is segwit), then the desktop can just ask=
 for the /48&#39;/0&#39;/0&#39;/3&#39;/PBKDF&#39; when it requests a new xp=
ub from the hardware token. More sophisticated Airgapped apps you can send =
&quot;wsh(sortedmulti(1,,,))&quot;+label and let the cosigner app do the PB=
KDF, and optionally allow it return something different in a full keyset (i=
.e. &quot;[90081696/48&#39;/0&#39;/0&#39;/3&#39;/af3948cg=E2=80=A6&#39;/]xp=
ub6DYLEk=E2=80=A6&quot;, and then the requesting app, knowing that it is di=
fferent from the PBKDF can know what to do if it needs to what to ask for i=
n the future.<br><br>The other advantage of this technique is that the cosi=
gner app can know what policy it is participating in, before the descriptor=
 is completed. It may decide it doesn&#39;t want to participate in some fun=
ky 4:9 with a weird script, and not return an xpub at all.<div><br></div><d=
iv>Long term I think a commitment scheme should be used, so that you don&#3=
9;t reveal what xpub you offered until all the parties xpubs are shared, bu=
t as Pieter said, we can do that at the same time we do the musig. But we n=
eed to prevent xpub reuse NOW, and I think my proposal easy and could the j=
ob.<br><br>-- Christopher Allen, Blockchain Commons<br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000002a9df805bb22d1bc--