public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pavol Rusnak <stick@satoshilabs.com>
To: Andrew Chow <achow101-lists@achow101.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor
Date: Tue, 26 Jul 2022 23:56:10 +0200	[thread overview]
Message-ID: <CAF90AvmdfzpE2TrXHMD4=DJZcq2U1muCcBZndMiRQLw1p57kYQ@mail.gmail.com> (raw)
In-Reply-To: <d97c9d44-730e-cbb4-ce8b-19bdf1ea1e2d@achow101.com>

[-- Attachment #1: Type: text/plain, Size: 6112 bytes --]

Thanks Andrew for this BIP. We've been already using this for quite some
time for Trezor in production.

Just one clarification: Should <NUM;NUM;NUM>, <NUM;NUM;NUM;NUM>, ... also
work or we only aim to support only tuples of exactly two values?

On Tue, 26 Jul 2022 at 23:51, Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi All,
>
> I would like to propose a BIP that de-duplicates and simplifies how we
> represent descriptors for receiving and change addresses. Under the
> existing BIPs, this requires two descriptors, where the vast majority of
> the descriptors are the same, except for a single derivation path
> element. This proposal allows descriptors to have a single derivation
> path element that can specify a pair of indexes. Parsers would then
> expand these into two almost identical descriptors with the difference
> being that the first uses the first of the pair of indexes, and the
> second uses the second.
>
> The proposed notation is `<a;b>`. As an example,
> `wpkh(xpub.../0/<0;1>/*)` would be expanded into `wpkh(xpub.../0/0/*)`
> and `wpkh(xpub.../0/1/*)`.
>
> This also works for descriptors involving multiple keys - the first
> element in every pair is used for the first descriptor, and the second
> element of each pair in the second descriptor.
>
> The full text of the BIP can be found at
>
> https://github.com/achow101/bips/blob/bip-multipath-descs/bip-multipath-descs.mediawiki
> and also copied below. An implementation of it to Bitcoin Core is
> available at https://github.com/bitcoin/bitcoin/pull/22838.
>
> Any feedback on this would be appreciated.
>
> Thanks,
> Andrew Chow
>
> ---
>
> <pre>
>    BIP: multipath-descs
>    Layer: Applications
>    Title: Multipath Descriptor Key Expressions
>    Author: Andrew Chow <andrew@achow101.com>
>    Comments-Summary: No comments yet.
>    Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-multipath-descs
>    Status: Draft
>    Type: Informational
>    Created: 2022-07-26
>    License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This document specifies a modification to Key Expressions of Descriptors
> that are described in BIP 380.
> This modification allows Key Expressions to indicate BIP 32 derivation
> path steps that can have multiple values.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Descriptors can describe the scripts that are used in a wallet, but
> wallets often require at least two descriptors for all of the scripts
> that they watch for.
> Wallets typically have one descriptor for producing receiving addresses,
> and the other for change addresses.
> These descriptors are often extremely similar - they produce the same
> types of scripts, derive keys from the same master key, and use
> derivation paths that are almost identical.
> The only differences are in the derivation path where one of the steps
> will be different between the descriptors.
> Thus it is useful to have a notation to represent both descriptors as a
> single descriptor where one of the derivation steps is a pair of values.
>
> ==Specification==
>
> For extended keys and their derivations paths in a Key Expression, BIP
> 380 states:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> This is modifed to state:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Followed by zero or one <tt>/<NUM;NUM></tt> (<tt>NUM</tt> may be
> followed by <tt>h</tt> to indicated a hardened step)  path element
> indicating a pair of BIP 32 derivation steps to be taken after the given
> extended key.
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> When a <tt>/<NUM;NUM></tt> is encountered, parsers should produce two
> descriptors where the first descriptor uses the first <tt>NUM</tt>, and
> a second descriptor uses the second <tt>NUM</tt>.
>
> The common use case for this is to represent descriptors for producing
> receiving and change addresses.
> When interpreting for this use case, wallets should use the first
> descriptor for producing receiving addresses, and the second descriptor
> for producing change addresses.
> For this use case, the element will commonly be the value <tt>/<0;1></tt>
>
> ==Test Vectors==
>
> TBD
>
> ==Backwards Compatibility==
>
> This is an addition to the Key Expressions defined in BIP 380.
> Key Expressions using the format described in BIP 380 are compatible
> with this modification and parsers that implement this will still be
> able to parse such descriptors.
> However as this is an addition to Key Expressions, older parsers will
> not be able to understand such descriptors.
>
> This modification to Key Expressions uses two new characters: <tt><</tt>
> and <tt>;</tt>.
> These are part of the descriptor character set and so are covered by the
> checksum algorithm.
> As these are previously unused characters, old parsers will not
> accidentally mistake them for indicating something else.
>
> ==Reference Implementation==
>
> https://github.com/bitcoin/bitcoin/pull/22838
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs

[-- Attachment #2: Type: text/html, Size: 8131 bytes --]

  reply	other threads:[~2022-07-26 21:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-26 21:41 [bitcoin-dev] BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor Andrew Chow
2022-07-26 21:56 ` Pavol Rusnak [this message]
2022-07-27  7:57 ` Craig Raw
2022-07-26 22:27 Andrew Chow
2022-07-27  8:44 ` Pavol Rusnak
2022-07-27 14:58 Andrew Chow
2022-07-28  9:40 ` Dmitry Petukhov
2022-08-04  1:16   ` Billy Tetrud
2022-08-04  7:09     ` 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='CAF90AvmdfzpE2TrXHMD4=DJZcq2U1muCcBZndMiRQLw1p57kYQ@mail.gmail.com' \
    --to=stick@satoshilabs.com \
    --cc=achow101-lists@achow101.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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