path: root/c8/641258eb4fcb2c46f2d3368d8b536156a8e120

Return-Path: <christophera@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E52B5C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 18:46:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id D4D0F4049B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 18:46:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=lifewithalacrity-com.20150623.gappssmtp.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 9u4rYCs3pH0j
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 18:46:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com
 [IPv6:2607:f8b0:4864:20::a2d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 57FD540485
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 18:46:06 +0000 (UTC)
Received: by mail-vk1-xa2d.google.com with SMTP id o17so3088322vko.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 11:46:06 -0700 (PDT)
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=KWIBD5P0Ih1xYTaaZ2ZSvtuAoIoQBQECkqh4dkZl4oI=;
 b=AgNOyZ5BvJXDJOVsnEnwKOEDmj74TwR8eE41VlSLn5zxfojHa3/goSkIzFj7GhcAya
 jcW7lphMryAEmSASbWEvccu3+WMFNTE1BtXsomSx6IHTaP76qquBSs+7PNUlYYy/g3cW
 CQu6nR5ONa2h4kymPNPgDQwUC6pax/MBJ4/hEqxaxNvWqOUlU9rHW2MjDVXxTxPFZQg2
 d2A8eyZC8BDrRoRObfsXHY5TblWIUOQiqI4SdRLUjgYhKXmL/8JEcORSkBFETekXFx+0
 l3UCpeOWe12SENgTOTgu0XxWywVXa1QZ4JiOvMkQ2PSwoEHQ2z3+/k2UXinCMdb125WZ
 JNUg==
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=KWIBD5P0Ih1xYTaaZ2ZSvtuAoIoQBQECkqh4dkZl4oI=;
 b=A6EiUnsrbNkpgpAEJxISwCuWkrgTcdfKEYM0+H9hitTehgwJrkM4Fgor20e16uJh4C
 6231y8HUZ6mC464a36QHi9sOmBaKTm9kv7tTGCZYzXGlLXYdI5EwQcAcJwviFwX46g69
 6nok9eM9nHwqOT1tqodnk5ixSJd0PV7mNahYrMIRhpEkoTL0d2sMI24kIEAhcs48v4ia
 fF+vg5lMmHY4GhTeMO1LgT7QcRFzPzGtLmOsXnQpHCtl07nuLkAkSAAq139mrXVApP+E
 Lotl2rYGahIDZG3sevM65Jr/kjAWm0GWP7UaZZdOwwB1Uxaa2melX8ZrKtFA5xz7HHRN
 n3qw==
X-Gm-Message-State: AOAM5318qixpLLBNQwERnRSM0GJAchAU5IrCdTKfedYyBmCilNo8HX0p
 3aXbn4Ha1FcpCxrSB/frV7qJXMr1a5MD7PF0RhburRXcO81wtg==
X-Google-Smtp-Source: ABdhPJxUNbe6S2hNNK+A/H0d/CfNVzfDdaTNaChZGAS/Jd1MYh0R0xfE18q7+s5Zxy3EQUzR/iPDg54VV4XvJGMiiwE=
X-Received: by 2002:a1f:4c45:: with SMTP id z66mr21106442vka.5.1618253164616; 
 Mon, 12 Apr 2021 11:46:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
 <CAPKmR9v=RK7byF0z0hKiLiA=Zm3ZZKbu3vEiuBuzQSXFwa+izw@mail.gmail.com>
 <s7sT6UplllXDfiCyf2HWJvEdz-1Gp9D5bvpwtAcmXEq2sRYm99FZZXJEFs-fDuhLKyxpgEvMrKa3P5OIRznxHLUqMjMIaUs-s5CGsx7zO_Q=@protonmail.com>
 <CAPKmR9v7xX7ASXAUkNXwjM5ExEF8xs5ihKw6MiY=RXk6o5s2Ng@mail.gmail.com>
 <CAMhCMoGWGFOuPA4iTacCP3HVudg80L+-xmjzvcGjohMhwnzVtA@mail.gmail.com>
In-Reply-To: <CAMhCMoGWGFOuPA4iTacCP3HVudg80L+-xmjzvcGjohMhwnzVtA@mail.gmail.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Mon, 12 Apr 2021 11:45:27 -0700
Message-ID: <CACrqygBgPtNtHS31emSRM3FBzAjNyi6x6EhbHqYVBxmoXsG8+g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000008a0dc05bfcaedf0"
X-Mailman-Approved-At: Mon, 12 Apr 2021 18:51:01 +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: Mon, 12 Apr 2021 18:46:08 -0000

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

Though I am ACK on that we need to solve the problem of xpub privacy and
reuse, I'm NACK on this solution. It is currently too complex and doesn't
really solve the problem.

I believe that the ultimate solution will be some form of multi-round
cryptographic commitment scheme, and as musig threshold signatures with
Taproot/Schnoor also require multi-round scheme, we should start thinking
now about how maybe we can leverage that work to address this problem as
well. However, I'm not a cryptographer and don't have a specific solution
in this area to offer.

In the meantime, there are some possible measures we can take as new best
practices. This is not a formal list, and I'm open to other suggestions,
but each are currently relatively easy and are functional with some
existing wallets that CAN support state. Let us get it right with stateful
wallets, then we can return back to better best practices for stateless
wallets like Trezor, Ledger, etc.

A) We should accept that users must to backup their multisig account maps
(descriptor with only xpubs) along with their cosigner key material to be
able to recover funds. In the Airgap Community we make this very easy with
a simple UR code that works efficiently as a QR. I personally keep multiple
copies of this account map in multiple locations, as it is less of a risk
(mostly privacy) if one of the locations is compromised.

B) Cosigner wallets and transaction coordinator services should not share
the master xpub, only the derived co-signer xpubs required for that
specific account. Currently too many libraries, wallets and coordinators
only function if they get the master xpub =E2=80=94 these should be updated=
 to not
require them.

C) In many current wallets, the master xpub fingerprint is required =E2=80=
=94 that
master fingerprint is also a privacy risk and should not be used. For
instance, the current practice of offering what the Airgap Community calls
a `crypto-hdkey` [604b93f2/48'/1'/0'/2'] with the master fingerprint root,
could instead be to only offer a single parent fingerprint [f93749a7/2']
from that grandparent master key. Thus different fingerprints can be
offered for each account, and only the signer knows the actual master
fingerprint and its children.

D) Given C, when creating a new multisig account, a transaction coordinator
may request a specific master fingerprint and/or a fixed 48' derivation
xpub from a cosigner wallet, but these are only hints. If it gets back a
different fingerprint or derivation, it should accept it. In the case of
the Airgap Community's specifications, in our "crypto-request" we actually
specifically allow for wildcard requests which makes this easy and
explicit. Yes, only stateful signers can know to return an xpub something
other than the fingerprint  and m/48'/1'/0'/2' default, but a transaction
coordinator should accept it if it receives it.

E) Transaction coordinators should send the cosigner "policy" (basically
the multisign descriptor without any keys in it) along with any request to
derive a new xpub for that new account. Stateful wallets can use this
policy to know later if they are asked to sign a PSBT that does not match
this policy.

F) Transaction coordinators should also send the final "account map" to all
the cosigner wallets as a best practice as well. This would replace the
temporary "policy" in D. If a PSBT request to sign using a key doesn't
match the original account map, the cosigner wallet can reject it.

These best practices don't solve the problem with stateless wallets like
Trezor, but they are possible now with the new generation of multisig
hardware and software wallets, such as Foundation Devices, CoboVault,
Sparrow, Bluwallet and my Gordian reference wallet tools. We have available
NOW working interoperable specifications, reference code, and example apps
that support these best practices, and some are already supported by
multiple wallets in the Airgapped Wallet Community hosted by Blockchain
Commons at https://github.com/blockchainCommons/airgapped-Wallet-Community.

I've put a copy of this rough proposal in our Airgapped Wallet Community
discussion area if you have suggestions or alternative best practices.

[Initial proposal for best practice to avoid XPUB reuse in multisig account
creation](
https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions=
/53
)

-- Christopher Allen, Blockchain Commons

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Thou=
gh I am ACK=C2=A0on that we need to solve the problem of xpub privacy and r=
euse, I&#39;m NACK=C2=A0on this solution. It is currently too complex and d=
oesn&#39;t really solve the problem.<div><br></div><div>I believe that the =
ultimate solution will be some form of multi-round cryptographic commitment=
 scheme, and as musig threshold signatures with Taproot/Schnoor also requir=
e multi-round scheme, we should start thinking now about how maybe we can l=
everage that work to address this problem as well. However, I&#39;m not a c=
ryptographer and don&#39;t have a specific solution in this area to offer.<=
/div><div><br></div><div>In the meantime, there are some possible measures =
we can take as new best practices. This is not a formal list, and I&#39;m o=
pen to other suggestions, but each are currently relatively easy and are fu=
nctional with some existing wallets that CAN support state. Let us get it r=
ight with stateful wallets, then we can return back to better best practice=
s for stateless wallets like Trezor, Ledger, etc.</div><div><br></div><div =
style=3D"color:rgb(0,0,0)">A) We should accept that users must to backup th=
eir multisig account=C2=A0maps (descriptor with only xpubs) along with thei=
r cosigner key material to be able to recover funds. In the Airgap Communit=
y we make this very easy with a simple UR code that works efficiently as a =
QR. I personally keep multiple copies of this account map in multiple locat=
ions, as it is less of a risk (mostly privacy) if one of the locations is c=
ompromised.</div><div style=3D"color:rgb(0,0,0)"><br></div><div>B) Cosigner=
 wallets and transaction coordinator services should not share the master x=
pub, only the derived=C2=A0co-signer xpubs required for that specific accou=
nt. Currently too many libraries, wallets and coordinators only function if=
 they get the master xpub =E2=80=94 these should be updated to not require =
them.</div><div><br></div><div>C) In many current wallets, the master xpub =
fingerprint is required =E2=80=94 that master fingerprint is also a privacy=
 risk and should not be used. For instance, the current practice of offerin=
g what the Airgap Community calls a `crypto-hdkey`=C2=A0[604b93f2/48&#39;/1=
&#39;/0&#39;/2&#39;] with the master fingerprint root, could instead be to =
only offer a single parent fingerprint [f93749a7/2&#39;] from that grandpar=
ent master key. Thus different fingerprints can be offered for each account=
, and only the signer knows the actual master fingerprint and its children.=
<br></div><div><br></div><div>D) Given C, when creating a new multisig acco=
unt, a transaction coordinator may request a specific master fingerprint an=
d/or a fixed 48&#39; derivation xpub from a cosigner wallet, but these are =
only hints. If it gets back a different fingerprint or derivation, it shoul=
d accept it. In the case of the Airgap Community&#39;s=C2=A0specifications,=
 in our &quot;crypto-request&quot; we actually specifically allow for wildc=
ard requests which makes this easy and explicit. Yes, only stateful signers=
 can know to return an xpub something other than the fingerprint =C2=A0and =
m/48&#39;/1&#39;/0&#39;/2&#39;=C2=A0default, but a transaction coordinator =
should accept it if it receives it.<br></div><div><br></div><div>E) Transac=
tion coordinators should send the cosigner &quot;policy&quot; (basically th=
e multisign descriptor without any keys in it) along with any request to de=
rive a new xpub for that new account. Stateful wallets can use this policy =
to know later if they are asked to sign a PSBT that does not match this pol=
icy.</div><div><br></div><div>F) Transaction coordinators should also send =
the final &quot;account map&quot; to all the cosigner wallets as a best pra=
ctice as well. This would replace the temporary &quot;policy&quot; in D. If=
 a PSBT request to sign using a key doesn&#39;t match the original account =
map, the cosigner wallet can reject it.</div><div><br></div><div>These best=
 practices don&#39;t solve the problem with stateless wallets like Trezor, =
but they are possible now with the new generation of multisig hardware and =
software wallets, such as Foundation Devices, CoboVault, Sparrow, Bluwallet=
 and my Gordian reference wallet tools. We have available NOW working inter=
operable specifications, reference code, and example apps that support thes=
e best practices, and some are already supported by multiple wallets in the=
 Airgapped Wallet Community hosted by Blockchain Commons at=C2=A0<a href=3D=
"https://github.com/blockchainCommons/airgapped-Wallet-Community">https://g=
ithub.com/blockchainCommons/airgapped-Wallet-Community</a>.</div><div><br><=
/div><div>I&#39;ve put a copy of this rough proposal in our Airgapped Walle=
t Community discussion area if you have suggestions or alternative best pra=
ctices.</div><div><br></div><div>[Initial proposal for best practice to avo=
id XPUB reuse in multisig account creation](<a href=3D"https://github.com/B=
lockchainCommons/Airgapped-Wallet-Community/discussions/53">https://github.=
com/BlockchainCommons/Airgapped-Wallet-Community/discussions/53</a>)</div><=
div><br></div><div>-- Christopher Allen, Blockchain Commons</div><div><br><=
/div><div><br></div><div></div><div><br></div><div></div></div></div></div>=
</div></div></div></div></div></div></div></div></div></div>

--00000000000008a0dc05bfcaedf0--