From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 57124C0733 for ; Fri, 3 Jul 2020 16:51:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 44E7188D23 for ; Fri, 3 Jul 2020 16:51:04 +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 rdvDabeO29lN for ; Fri, 3 Jul 2020 16:51:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248]) by whitealder.osuosl.org (Postfix) with ESMTPS id 5BE0A88CBC for ; Fri, 3 Jul 2020 16:51:03 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 95203260023D; Fri, 3 Jul 2020 16:51:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1593795060; bh=q7aFwWQ63Dnz5D7Ltn9+FIzMthD04FdNdCar02U72a8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=L6HKWaMthsXGpAXfW8wjq7FRQEb8zG8PBO+LkblyfJSLX0FJKEu3k3fvY3UXPeKX1 bIu5OjV8wNRt6OBOfSvUQmh/mhNDzH+VrArj07Zzzw8mhB0RLZGLUnKrrMAV66d5+h 6oHP0aCX22uycH+/ggt2aMqYnTbKzTdE1k1bqfns= Date: Fri, 3 Jul 2020 21:53:44 +0500 From: Dmitry Petukhov To: "David A. Harding" Message-ID: <20200703215344.349376cd@simplexum.com> In-Reply-To: <20200703143945.kvuczb7z4vr6ehwr@ganymede> References: <20200702212839.2d59e435@simplexum.com> <20200703143945.kvuczb7z4vr6ehwr@ganymede> Organization: simplexum.com MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/HXmLHZjzU6M/AXmc5nSWkJp"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Mailman-Approved-At: Fri, 03 Jul 2020 17:05:35 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP draft: BIP32 Path Templates 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, 03 Jul 2020 16:51:04 -0000 --Sig_/HXmLHZjzU6M/AXmc5nSWkJp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IIUC, key origin identification specify chains of addresses, with relation to specific keys. As the name suggests, they are for identidication. Path templates specify application-specific constraints for the derivation paths. They are for imposing restrictions. You could use path templates for identification, too, and in fact the "path" part of the key origin identification would be a valid path template. Path templates have potential to identify multiple chains of addresses though, and I cannot say how useful it can be, if at all. When a hardware wallet or some other type of autonomous signer signs a transaction, there are two points where HD derivation can occur: 1) when signing an input 2) when checking if the output is the change output The second case is occurs more often, I think (determining actual amount sent), but the first case can have uses, too -- when an autonomous signer can impose restrictions on derivation path based on the identity of the user that request the signing, for example.=20 In both of these points an application-specific or usecase-specific signing scheme might require that only certain whitelisted derivation paths are used (sending change to the known key, but using derivation path unknown to the sender allows an attacker to hold the change amount for ransom, for example) An autonomous signer might not be aware of the restrictions used in particular scheme, because it might be developed by different vendor than the implementor of the particular scheme. Or it might be difficult to update the firmware of autonomous signer when the checks of the path constraints are hard-coded in the program code. Having constraints specified as data would allow to place them in configuration of the signer. One particular example of this being a problem is how hardware wallet vendors seem to be inclined to decide to just restrict the derivation paths allowed for the change addresses to the set of "well-known" paths. Such restrictions, on one hand, break custom schemes used by various software solutions that rely on the ability of hardware wallet to sign custom paths, and on the other hand, such hardcoded restrictions might happen to be too relaxed, if the set of "well-known" path grows, or the user or software vendor knows for sure that they won't use addresses past index 1000, for example. The format for the path templates described in the presented BIP draft aims to provide a building block for interoperability between various hardware and software vendors in regard to this particular task of specifying derivation path restrictions. Adopting a common format for specifying restictions is a flexible alternative to everyone adopting a rigid set of "well-known" paths. Such a set will inevitably grow, and those who really need custom paths and do not have resources to push for standardization of their custom paths will be at a disadvantage. My hope is that having a clear specification and (possibly, in the future) permissibly licensed quality implementations would make adopting such format easier for vendors. =D0=92 Fri, 3 Jul 2020 10:39:45 -0400 "David A. Harding" wrote: > On Thu, Jul 02, 2020 at 09:28:39PM +0500, Dmitry Petukhov via > bitcoin-dev wrote: > > I think there should be standard format to describe constraints for > > BIP32 paths. > >=20 > > I present a BIP draft that specifies "path templates" for BIP32 > > paths: > >=20 > > https://github.com/dgpv/bip32_template_parse_tplaplus_spec/blob/master/= bip-path-templates.mediawiki > > =20 >=20 > Hi Dmitry, >=20 > How do path templates compare to key origin identification[1] in > output script descriptors? >=20 > Could you maybe give a specfic example of how path templates might be > used? Are they for backups? Multisig wallet coordination? Managing > data between software transaction construction and hardware device > signing? >=20 > Thanks, >=20 > -Dave >=20 > [1] > https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#key-ori= gin-identification > (See earlier in the doc for examples) --Sig_/HXmLHZjzU6M/AXmc5nSWkJp Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEsXo1u6GHOVeE4qazIwHSa9wVFg0FAl7/YpgACgkQIwHSa9wV Fg24SQ/8DtgCmY3lHGJblUyYyguhhRHwKRvaWOwnrk53gWJpYJiVje5/zUU54Xk9 cYm0rt80UVgA1tjlDgwpLBYqHjq9u1UA71xGwIlu9Yh+3LADK6XvkvEvbZsR6zT6 HUtE47xIPWTrrjHMI1ZVKcDKTfqPb+eiv20Rj/oqvmkkuKNeR1MegWnlVD73kaQk VzQn2wK9zEse15kxYJGBKsC5kwtsLCo45pP70TA/sOgJVT2vrv2AUkz8u7J+rZ0i /ZYWkyEPTdNMJvBbsr0pEpytmloSndKM/yREKRcjhkCzxxhxy6n+fAh1wWgzJ8K+ ROpvI4jgSGm0ab/E5eIH/R1/WqLWy3aN4ym+IZmh5vZLxwcUW4A11oePtSTkbV1n DCvFz/EKzMcwxYMOKKsfFr9rXgOTdxb+LPV3RwxQUX7MAn089VW8eaQHLBDtE8VI goYyDXN+8xmXlJ3RoDUcSnmFiK3TXZCIxh6Cz8z3RDASBXWkNfbYtp7OS1OCQieN sdriDbmtprVRh34RS1sBC8lrJUsitV6kGMXI10kbQ2t6asxx43zFuy5eaMgy3ctR QgvJ7ytGptzzG2CdD+ZE+jShf8w1jeupKSMvh+jARbBqK1nIBQqmRloP8wgsG47g hcM8yc35he0Ybx8dfUib1iSMjoYC4XZj+SJb+f/PaRqFp6Cz8Bo= =kx6N -----END PGP SIGNATURE----- --Sig_/HXmLHZjzU6M/AXmc5nSWkJp--