On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin <thoma...@gmx.de> 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. ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
