rich1.0npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrshttps://nostr.ae/npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsnjumphttps://nostr.ae📅 Original date posted:2014-04-23 📝 Original message: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