Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de
	designates 212.227.17.21 as permitted sender)
	client-ip=212.227.17.21; envelope-from=thomasv1@gmx.de;
	helo=mout.gmx.net; 
Message-ID: <5358C816.8020707@gmx.de>
Date: Thu, 24 Apr 2014 10:15:18 +0200
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
CC: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>	<CAE-z3OUMp_uO07+_R_x2yRLbSCzK1J5isbVUYEY3KF4Tx16K2Q@mail.gmail.com>	<53581480.5060103@gk2.sk>	<201404231944.14256.luke@dashjr.org>	<5358B51F.8010202@gmx.de>	<CAPg+sBj68d5ZBDZ4uWvQYHMeq=bwTCaMNbwxfWGVL5MPh=7g2g@mail.gmail.com>
	<CAAS2fgS1bsp+T94c2D+uzU4aDsux+BRCSHu5zb0Xaz+LCg0xqA@mail.gmail.com>
In-Reply-To: <CAAS2fgS1bsp+T94c2D+uzU4aDsux+BRCSHu5zb0Xaz+LCg0xqA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list


Le 24/04/2014 09:21, Gregory Maxwell a écrit :
> 
> It doesn't appear to me that reoccurring payments, receive accounts,
> multisig addresses, etc can be used with this proposal, but instead
> you must use a different purpose code and another BIP and are not
> compatible with the draft here.
> 
> Am I misunderstanding it?   Will Electrum be limiting itself in this
> way?  I'd consider it a unfortunate loss of functionality if wallets
> couldn't implement reoccurring payment chains without making users
> generate entirely different wallets (which they couldn't share funds
> across) since addresses for recurring payments was one of the main
> motivations in BIP32.
> 
> 

No, Electrum will not be limiting itself in this way. I believe that we
are only at the beginning of exploring the different possibilities
opened by HD wallets. It will probably take years until we have clear
ideas on what users need, what choices they make, and how to organize
everything. Therefore it is too early to take decisions that might limit
future functionality.

I can see that it is very difficult today to find a consensus on wallet
structure between wallet developers. In addition, I changed my mind
several times on these questions, so I guess I will probably need to
change things again in the future.

This is why I decided to include a version number in Electrum seeds. The
version number will be updated everytime the wallet structure changes. I
know many developers do not follow me on this, but that is something I
am quite sure Electrum needs, despite all the other things I am not sure
about :)

I think it is too early to aim for inter-wallet compatibility today. I
guess we should postpone this goal, and move on with software releases.
As Andreas pointed out, we should just make sure that we do not import
an incompatible seed in another wallet, because not recovering all your
bitcoins would be a terrible user experience; the version number built
in the seed will ensure that for Electrum.