Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7BAD2C000A for ; Fri, 9 Apr 2021 12:16:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5CB94848FB for ; Fri, 9 Apr 2021 12:16:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=sprovoost.nl header.b="UjY6Dsuq"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="PStIUgJK" Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRq7I-nbfcfk for ; Fri, 9 Apr 2021 12:16:11 +0000 (UTC) X-Greylist: delayed 00:08:54 by SQLgrey-1.8.0 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4CCEE84A2B for ; Fri, 9 Apr 2021 12:16:07 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 418515C00B5; Fri, 9 Apr 2021 08:07:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 09 Apr 2021 08:07:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=B87e+CoS6J80aFO1oH72afs nj1Jp49OP+giWmoZz0uk=; b=UjY6DsuqeWn46xF/ioQ35y17ijUiSVITmnEr77a qG5lsZs2t9G7sGj99FI6ZUFJEPHsCWzrw8jp5B9Evfy0/bwMO2q8SQb2OZfIXoAs 8urRJObSvQGYo387qncX+fYH7Jy58Kmzcr2ipte0/y/I3PGz1Z34KXrWXp3qmxfE gCfL5F9C3mH7CAyiX+V0ABrMYh9UqwovoE4NeQhvPx7/vnpZOzMEIdnjcxpEulM7 7Wxo79Zfc1KQyBOcdEvhzl3xRs5W/nV84fusurpy3ruG7U+OC6AUryIspa+DUH6h kdAGs9+q9lh7iiODdJV4uZgFPiw2sd+0j4dm7Vxsic/J5LQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=B87e+C oS6J80aFO1oH72afsnj1Jp49OP+giWmoZz0uk=; b=PStIUgJKRibsSyigOXXnhz O1fJnTIzYdmVsdRoMne66b5JvAkz5xcUQTRKtQEgaBb9qRo8evd0YnVDW1XtJitI mmrAdzfBiJZPBF0Q6OYd0URun57ctbx8p9muOntvZ14l+RzoNFn2M2Vo7RjOvyOW TEz9zVgQMPsJW9iyJHWmCQAdStOHpCaJIVukIQNwwg55oeWA4FbdzXzKqxgZ++7Q mtMp69tM4mZ1VRfkvvHEKWK7EFl+fZifSY4LNznp+AoFm2uyLY40NdX49cOSHdfd UvXAEtID/w5x4O1MfJV7EhrqKsJEx/jJBDyUCj3fAwWhHbn86l1flB9w5ksoM6jA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekuddggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosehgtdhmrehhtddvnecuhfhrohhmpefujhhorhhs ucfrrhhovhhoohhsthcuoehsjhhorhhssehsphhrohhvohhoshhtrdhnlheqnecuggftrf grthhtvghrnhepfeeuudfgkedtveejffeiuedvvdetffekjedtgeejudetkeekjedvgeek geeggfdtnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepkeeirdekvddrvd dugedrudefgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehsjhhorhhssehsphhrohhvohhoshhtrdhnlh X-ME-Proxy: Received: from [192.168.2.15] (86-82-214-134.fixed.kpn.net [86.82.214.134]) by mail.messagingengine.com (Postfix) with ESMTPA id 09A691080067; Fri, 9 Apr 2021 08:07:07 -0400 (EDT) From: Sjors Provoost Message-Id: 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: To: Bitcoin Dev References: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Mailman-Approved-At: Fri, 09 Apr 2021 13:32:15 +0000 Cc: marko@shiftcrypto.ch, aarondongchen@gmail.com, peter@coinkite.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 12:16:13 -0000 --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 = 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--