From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdEoZ-0003zn-3f for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 08:15:27 +0000 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; Received: from mout.gmx.net ([212.227.17.21]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WdEoX-0004Gk-OA for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 08:15:27 +0000 Received: from [192.168.1.27] ([86.73.30.202]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MU1MP-1WUgFy1CTp-00QhwO for ; Thu, 24 Apr 2014 10:15:19 +0200 Message-ID: <5358C816.8020707@gmx.de> Date: Thu, 24 Apr 2014 10:15:18 +0200 From: Thomas Voegtlin 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 References: <53581480.5060103@gk2.sk> <201404231944.14256.luke@dashjr.org> <5358B51F.8010202@gmx.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:6La/201e0x2MVwUMRVSM/OVVa/fS+aIValm8x5P2i7HvywdCloA Hvu2ZkbwZDpxetlDGODTPpMB9wv3JGi2+6gVKzosc2Qg1I6i3xYb65O40tASu9XkRd4KtQF DN66NmdVrEKXi4CpQPAtxuh3dS+ywuHAk4LWdUw84verugLU3hq60ZCTg83l12K7CKNB9I0 chHzZnbumuRKHf3v2qsag== X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (thomasv1[at]gmx.de) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.21 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (thomasv1[at]gmx.de) 1.2 MISSING_HEADERS Missing To: header X-Headers-End: 1WdEoX-0004Gk-OA Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:15:27 -0000 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.