Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdDyU-0004iH-QY for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 07:21:38 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.178 as permitted sender) client-ip=209.85.217.178; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f178.google.com; Received: from mail-lb0-f178.google.com ([209.85.217.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdDyQ-0008J1-Vg for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 07:21:38 +0000 Received: by mail-lb0-f178.google.com with SMTP id s7so1661993lbd.37 for ; Thu, 24 Apr 2014 00:21:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.201.42 with SMTP id jx10mr29334lbc.91.1398324088310; Thu, 24 Apr 2014 00:21:28 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Thu, 24 Apr 2014 00:21:28 -0700 (PDT) In-Reply-To: References: <53581480.5060103@gk2.sk> <201404231944.14256.luke@dashjr.org> <5358B51F.8010202@gmx.de> Date: Thu, 24 Apr 2014 00:21:28 -0700 Message-ID: From: Gregory Maxwell To: Pieter Wuille Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WdDyQ-0008J1-Vg Cc: Bitcoin Dev 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 07:21:39 -0000 On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille wrote: > On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin wrote: >>> Why do clients need to use the features in BIP 64? If Electrum doesn't want to >>> use accounts, [...] >> >> To clarify: >> Electrum plans to have bip32 accounts; Multibit will not, afaik. > > To clarify: > BIP64 has a much stricter definition for accounts than BIP32. > > In BIP32, it is not well specified what accounts are used for. They > can be used for "subwallets", "receive accounts" (as in bitcoind's > account feature), "recurring payments", part of a chain used as > multisig addresses, ... determined individually for each index. > > In BIP64, they are strictly used for subwallets, and can't be used by > anything else. 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.