Message-ID: <54CF9016.5070206@gk2.sk>
Date: Mon, 02 Feb 2015 15:56:22 +0100
From: Pavol Rusnak <stick@gk2.sk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Andreas Schildbach <andreas@schildbach.de>, 
	bitcoin-development@lists.sourceforge.net
References: <CAG86ZOxYh+=rny3sPHeJ0qs6R=5frLXERKmwhVECGHo7tkrz3w@mail.gmail.com>	<CANEZrP3Tuw3mJLSuoOA4iOmg6u9sdh-E5NNm_FgdYs3Mx39znA@mail.gmail.com>	<manr4t$c1a$1@ger.gmane.org>	<54CF74A5.3050304@gk2.sk>
	<mao0u5$gbu$1@ger.gmane.org>
In-Reply-To: <mao0u5$gbu$1@ger.gmane.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [Bitcoin-development] Export format for xpub
Precedence: list

On 02/02/15 15:17, Andreas Schildbach wrote:
> Yes, except that BIP32-hierarchy and BIP44 differ in some requirements
> (e.g. gap limit).

Right.

To me it seems more important to describe how addresses should be
discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G)
instead of how the xpub was created/obtained (bip32 vs bip44).

What do you thing about changing ?h=bip32 to something like

?t=01&g=20

- t=01 meaning that chains 0 and 1 should be scanned (feel free to
change "01" into any other descriptive string)
- g=20 meaning that gap 20 should be used

> Those strings are not meant to be read by humans. YYYYMMDD is more
> complicated than necessary, given that Bitcoin deals with seconds since
> epoch everywhere.

OK :-)

-- 
Best Regards / S pozdravom,

Pavol Rusnak <stick@gk2.sk>