path: root/83/ee822e47041602cb90f6d5cb3eee9777d35aee

Return-Path: <peter@coinkite.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1263FC013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 13:56:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id F3DB886DF8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 13:56:45 +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 Rj3oapHBWK94
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 13:56:44 +0000 (UTC)
X-Greylist: delayed 00:08:26 by SQLgrey-1.7.6
Received: from smtp72.iad3a.emailsrvr.com (smtp72.iad3a.emailsrvr.com
 [173.203.187.72])
 by whitealder.osuosl.org (Postfix) with ESMTPS id B6C8686E97
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 13:56:44 +0000 (UTC)
X-Auth-ID: peter@coinkite.com
Received: by smtp18.relay.iad3a.emailsrvr.com (Authenticated sender:
 peter-AT-coinkite.com) with ESMTPSA id 8C6DA20D35; 
 Fri, 12 Feb 2021 08:48:17 -0500 (EST)
Date: Fri, 12 Feb 2021 08:48:16 -0500
From: "Peter D. Gray" <peter@coinkite.com>
To: Christopher Allen <ChristopherA@lifewithalacrity.com>
Message-ID: <20210212134816.GM47135@coinkite.com>
Reply-To: Peter Gray <peter@coinkite.com>
References: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="w/fW4OhQtzSNeJ+1"
Content-Disposition: inline
In-Reply-To: <CACrqygAMG67dajktTcq9hgyhfu2u1NRSHzkM345=jc6NLDUsbg@mail.gmail.com>
Organization: Coinkite Inc. (www.coinkite.com)
X-Classification-ID: 4a4a76e6-21d2-4b87-a74f-306f447ea628-1-1
X-Mailman-Approved-At: Fri, 12 Feb 2021 14:58:28 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 13:56:46 -0000


--w/fW4OhQtzSNeJ+1
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hard no to this idea:

On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed:
=2E..
> /48'/0'/0'/3'/PBKDF(complex string)'

As someone who has helped people find UTXO at key paths they didn't
know/want, this is a terrible idea. Key derivation paths should be
small, sequential integers, so they can be searched in reasonable time.

Of course when things are working it doesn't matter, but the stakes
can be very high when they stop working.

This is true for multisig and single signer.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31B=
AD 5A2A5B10

On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen wrote:
> I think the key issue here is avoiding xpub key reuse in multisig. Not on=
ly
> in the future with Schnorr, but we need it today!
>=20
> Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
> 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.
>=20
> As Pieter said, leveraging a HD path parameters can help, but we need a
> better, less reusable path for the index.
>=20
> 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).
>=20
> Example: for the reference bit descriptor that might result in:
>=20
> ```
> wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRU=
apSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8=
KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezp=
bZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
> ```
>=20
> What Blockchain Commons (and the Airgapped Wallet Community) call a policy
> map would be
>=20
> ```
> wsh(sortedmulti(1,,,))
> ```
>=20
> A PBKDF of that as would be unique for all 2 of 3 segwig transactions. Wi=
th
> 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.
>=20
> 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 the=
n 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.
>=20
> 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.
>=20
> 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.
>=20
> -- Christopher Allen, Blockchain Commons



--w/fW4OhQtzSNeJ+1
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAABCgAdFiEERYl3mt/BTzMnU06oo6MbrVoqWxAFAmAmhx8ACgkQo6MbrVoq
WxCzHQgApHCIABx+PElC9VWAMVllnheXanxC0XNyVnotvEjMoCHKT6oUnf3JIGrY
M7CHcrzeo5/JVs/3z2nHsw6es2Mx0/4BNLk73Hm4YexmOOpfeRiCoSNkD/+aA+XO
6OOm7PSTk0L5SyT3VyBj8RN553hHBOuhjAYkHs1YU1gz3c1px2Vmsz/VRcap1hci
XNCRg0sSYrlDYDn1wRbGJBOt5Xt+Kjpb6QHnvvmIROEciTZJ+xgkNN4duS4yGKI2
XCt3FYbAaDOtO0IIDzzqL+5m+yS88CsrTcK5XmTg/6OHigRcTH6rlh+AbA04swnH
lmNaWCK4arnQz0diKtWLb5gjZlXbFw==
=XyGH
-----END PGP SIGNATURE-----

--w/fW4OhQtzSNeJ+1--