From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 23 Apr 2014 19:44:13 +0000
User-Agent: KMail/1.13.7 (Linux/3.12.6-gentoo; KDE/4.11.5; x86_64; ; )
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
	<CAE-z3OUMp_uO07+_R_x2yRLbSCzK1J5isbVUYEY3KF4Tx16K2Q@mail.gmail.com>
	<53581480.5060103@gk2.sk>
In-Reply-To: <53581480.5060103@gk2.sk>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201404231944.14256.luke@dashjr.org>
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list

On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
> On 04/23/2014 09:00 PM, Tier Nolan wrote:
> > The point is to have a single system that is compatible over a large
> > number of systems.
> 
> There is such system and it is called BIP32.
> 
> On the other hand, in BIP64 we try to put a set of restrictions and
> rules on top of BIP32. There will always be some special usecases where
> BIP64 is not a good fit and there's no reason why you cannot use BIP32
> in a different manner using a different "purpose" field.
> 
> Examples: Electrum does not want to use accounts and they start to use
> scheme m/65'/change/address (where change = 0 or 1). Or Andreas
> Schildbach wants to have refunds chain so he uses m/66'/chain/address
> (where chain = 0, 1 or 2).
> 
> We wanted to find one good solution that fits all, but unfortunately it
> turned out everyone wants something a little bit different.

Why do clients need to use the features in BIP 64? If Electrum doesn't want to 
use accounts, then it can just use account 0 for everything. Refund chains are 
definitely a third case that should be added to the external and 
internal/change address division... and a wallet not implementing refund 
addresses would simply not use that chain.

Luke