From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <DDAD27D6-57F5-4B39-AADB-B28E04E36D29@sprovoost.nl>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_E50F94D3-8B43-4AA9-9C00-2BBAE6512ED3";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Fri, 9 Apr 2021 14:07:05 +0200
In-Reply-To: <CAPKmR9v=RK7byF0z0hKiLiA=Zm3ZZKbu3vEiuBuzQSXFwa+izw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
 <CAPKmR9v=RK7byF0z0hKiLiA=Zm3ZZKbu3vEiuBuzQSXFwa+izw@mail.gmail.com>
Cc: marko@shiftcrypto.ch, aarondongchen@gmail.com, peter@coinkite.com
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Precedence: list


--Apple-Mail=_E50F94D3-8B43-4AA9-9C00-2BBAE6512ED3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,

First of all thanks for your continued work on standardising multisig =
setup.

The use case I personally find most interesting is not a multi-party =
setup, but rather just combining a bunch of my own devices. Those might =
even be in the same room during the setup, only to be moved to my moon =
base later.

This means I've paid less attention to the encryption scheme, so I might =
set TOKEN=3D0, but nevertheless I am skeptical about it. The first step =
is for the Coordinator to generate a TOKEN, presumably using its own =
entropy. But IIUC anyone who intercepts that token can decrypt any =
future step in the setup process. This suggests a chicken-egg problem =
where you need some pre-existing secure communications channel.

To the list of concerns at the top of the BIP, I would add one: losing =
multisig setup context. E.g. in the event of a fire where you only =
recover your steel engraved mnemonic(s), but no longer have the wallet =
descriptors.

If you still have all devices and know (or guess) the threshold then =
BIP48 and sorted_multi descriptors will save you. But if you have a =
2-of-3 setup and lost 1 device then without the metadata your coins are =
lost. In a future with musig(?) and miniscript increasingly the setup =
data is just as critical as the seeds.

A future standard (or extension of this one) should recommend an =
encryption convention for the descriptor data, ideally such that with =
*any* of the seeds you can decrypt a file that contains the full setup. =
That file could then just float redundantly around the internet and =
pieces of paper in various locations, without compromising privacy.

The proposed encryption system doesn't help with that though, because =
it's based on entropy from the Coordinator, rather than from the =
signers.


Smaller suggestions:
* link to this new mail thread in the BIP
* use magic bytes so .bsms so operating systems like Android / iOs can =
open the right app for them
* don't use separate file extensions for encrypted vs unencrypted =
content, just indicate somehow that a given field is encrypted
* although plain text files are handy for debugging, I think a binary =
format like PSBT is much powerful. Any device that can parse and write =
binary PSBT should be able to implement a similar parser / writer for a =
binary .bsms format.
* BIP48 and sorted_multi descriptors are useful in a loss-of-metadata =
scenario. The BIP uses both in the examples, but doesn't explictly =
endorse these derivations. It also contradicts them: "If the Signer =
chooses the path, it should try to avoid reusing XPUBs for different =
wallets.". Maybe this is out of scope.
   * one way to resolve xpub reuse would be to make the "BIP48" path a =
function of the co-signer fingerprints and wallet threshold, but this =
requires an extra communication round
* there should be a way for signers to communicate their capabilities, =
perhaps with a different xpub for each potential scheme. E.g. there's =
m/48' native SegWit now, MuSig and/or or Tapleaf based multisig in the =
future, or even generic Miniscript support.
* the idea of only storing the receive descriptor, not the change =
descriptor, is fine by me, though I'd prefer an extension to the =
descriptor format to deal with this

Sjors

> Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> Hi all,
>=20
> Please find below the complete draft of the Bitcoin Secure Multisig =
Setup (BSMS) BIP. The spec has gone through a number of important =
updates in the last month or so. Thanks everyone who has participated in =
the review process.
>=20
> As a PR: https://github.com/bitcoin/bips/pull/1097


--Apple-Mail=_E50F94D3-8B43-4AA9-9C00-2BBAE6512ED3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAmBwQ2kACgkQV/+b28ww
EAndkw/8CNnHz9xlN0bA7fMrIouBW5vfHf0SP7ecVUNE5NUpj6Q7eQhlJt+6/U9o
cGtzEre2luU8j7BTBlhfMhs5KXYcHQLec8spWb6y2yFvAjFfFo1GE+qjPa0sXsme
xU4D3Srq9X5cp+enviX4O7uv6X7Ebdg1NfmCKavp83Z5T+JVJnQv6bWE0f5rX5d3
sm0h8eqjvviHzmlvHg18agSpONq754wJm7J+oTiKRltqvxhhfHqEgE2ESyET2C3U
2mnjTpezd2ja4qTrT3WwyLrZWxBw+E3+hzdeVEq4exh45jVl+8lIEhkmDpEZG7nB
/DCEo/cDXI+JmvzKVokPjLGONn7jyaKpm0jSuhPHGo9u01OsMgGb9pr3csQGYS12
AuYDI8S+/uV1kg1jZRY8+avLyG6t2djjuN7sZS3aEjzJDGIFWtI2rgPF9GRSZe25
RRIGxj5wNb9vcHW8yPmB7d5ydJCC5nd/DG53jE90zq+rA9hpjpJB2XCI0zmfbRvk
bhlijhBGn3OMf2jZV87jyNsOwtPFq4rl9iDT7tKsY70z2XFQHwO3RY/pPyBW59m6
XOigdK3BYX5UPygFFj+yZkRQ1zFDUs3riDTlTPoUnGrtbYFlwLT7ji1Q9j/1WYnU
r3QsScTCA31VUSPj0L+frQPGBAqoLZg7gJk+212QEkBEDmV8I8w=
=Y6Rn
-----END PGP SIGNATURE-----

--Apple-Mail=_E50F94D3-8B43-4AA9-9C00-2BBAE6512ED3--