{"type":"rich","version":"1.0","author_name":"npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs","author_url":"https://nostr.ae/npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:\n\u003e On 04/23/2014 09:00 PM, Tier Nolan wrote:\n\u003e \u003e The point is to have a single system that is compatible over a large\n\u003e \u003e number of systems.\n\u003e \n\u003e There is such system and it is called BIP32.\n\u003e \n\u003e On the other hand, in BIP64 we try to put a set of restrictions and\n\u003e rules on top of BIP32. There will always be some special usecases where\n\u003e BIP64 is not a good fit and there's no reason why you cannot use BIP32\n\u003e in a different manner using a different \"purpose\" field.\n\u003e \n\u003e Examples: Electrum does not want to use accounts and they start to use\n\u003e scheme m/65'/change/address (where change = 0 or 1). Or Andreas\n\u003e Schildbach wants to have refunds chain so he uses m/66'/chain/address\n\u003e (where chain = 0, 1 or 2).\n\u003e \n\u003e We wanted to find one good solution that fits all, but unfortunately it\n\u003e turned out everyone wants something a little bit different.\n\nWhy do clients need to use the features in BIP 64? If Electrum doesn't want to \nuse accounts, then it can just use account 0 for everything. Refund chains are \ndefinitely a third case that should be added to the external and \ninternal/change address division... and a wallet not implementing refund \naddresses would simply not use that chain.\n\nLuke"}