From: Dmitry Petukhov <dp@simplexum•com>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP draft: BIP32 Path Templates
Date: Fri, 3 Jul 2020 21:53:44 +0500 [thread overview]
Message-ID: <20200703215344.349376cd@simplexum.com> (raw)
In-Reply-To: <20200703143945.kvuczb7z4vr6ehwr@ganymede>
[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]
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.
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.
В Fri, 3 Jul 2020 10:39:45 -0400
"David A. Harding" <dave@dtrt•org> 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.
> >
> > I present a BIP draft that specifies "path templates" for BIP32
> > paths:
> >
> > https://github.com/dgpv/bip32_template_parse_tplaplus_spec/blob/master/bip-path-templates.mediawiki
> >
>
> Hi Dmitry,
>
> How do path templates compare to key origin identification[1] in
> output script descriptors?
>
> 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?
>
> Thanks,
>
> -Dave
>
> [1]
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#key-origin-identification
> (See earlier in the doc for examples)
[-- Attachment #2: Ð¦Ð¸Ñ„Ñ€Ð¾Ð²Ð°Ñ Ð¿Ð¾Ð´Ð¿Ð¸ÑÑŒ OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-07-03 16:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 16:28 Dmitry Petukhov
2020-07-03 14:39 ` David A. Harding
2020-07-03 16:53 ` Dmitry Petukhov [this message]
2020-07-03 19:10 ` Dmitry Petukhov
2020-07-06 15:24 ` Dmitry Petukhov
2020-10-26 13:04 ` Dmitry Petukhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200703215344.349376cd@simplexum.com \
--to=dp@simplexum$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox