Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 08 Apr 2014 17:58:03 +0200
Message-ID: <li16ac$q0k$1@ger.gmane.org>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>	<F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>	<CAJHLa0PPAsBLgsy0vgPpUp=UzeR_fWUEzFb5+xtmODEk4MGPVQ@mail.gmail.com>	<CAJfRnm7V6fgcj=TMfa2ZTYWOKtE5aoUT1xnVtKUSyriB=6cagQ@mail.gmail.com>	<CAPg+sBjwf1TcK1CGKVKFzYbV-78j8t-pav7=PEgG7Yqi6-yE7A@mail.gmail.com>	<53344FF8.7030204@gk2.sk>	<CAPg+sBhbx5vy_hewAkFPaiXHzSMNH0qLhEYGjPmQMjR5StP-tw@mail.gmail.com>	<CAJna-Hi0JnrF2_rUx0rGkdnsuCoaD01e3Gobpn+QqbL=D1Uivg@mail.gmail.com>	<CAJna-HirtsGLfAhfUf9dAYEGWo6g=o=eAU187c2pdW8vDFGkPw@mail.gmail.com>	<li12a7$i8o$1@ger.gmane.org>
	<CAJna-HgVs1ahhNKswaKPudwc1AvrBGgdfbZwNCvUPHFzHbh1WA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
In-Reply-To: <CAJna-HgVs1ahhNKswaKPudwc1AvrBGgdfbZwNCvUPHFzHbh1WA@mail.gmail.com>
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list

On 04/08/2014 05:46 PM, slush wrote:

>     I understand each client will implement things a little bit different,
>     for example the current plan is bitcoinj will hold all keys in memory
>     and start reusing keys on low resources. Electrum uses a chain for their
>     private purpose. Etc.
> 
> It still doesn't mean that bitcoinj or Electrum cannot share the bare
> minimum of BIP XX. Of course if somebody will use Electrum for 2to3
> transactions and then move wallet to client which does not offer such
> feature, it won't work. But I don't see that as a problem.

There is no "bare minimum". Either you implement the "BIP" fully or not.
There is no inbetween. Likewise, the standard cannot be extended unless
you create a new standard that is based on the old (without re-using the
path, of course).

We're lightyears away from a BIP. Lets first create implementations and
see if they are compatible in all possible combinations and situations.
The moment any two apps have a different view on their wallets generated
from the same seed, they're incompatible. In this case they should
either fix the issue or intentionally choose incompatible paths, so that
they don't see and spend "subsets" of each other.