Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
I'm not sure I understand your question about the need to store paths in the wallet database -- there's no way to infer the path of an address inside an HD wallet from the address alone (short of an exhaustive search), and HD wallets need to store either the paths, addresses, or both that have been previously derived/used to monitor the blockchain usefully, but those facts aren't new or specific to this path format. The motivation for this path structure over standard bip44 is that it separates the concept of network (or which blockchain I'm using) and coin_type (or what kind of thing I'm sending over that blockchain). This is useful, for example, if I want to import a wallet into my application and I know that an account was in use at m/##'/0'/99'/0' where 99 is the identifier for, say, counterparty - I only need to check the addresses derived below that path for balances against counterpartyd. It may be worth pointing out that I expect multisig HD wallet imports to require master keys and a list of account paths – not a list of addresses, as it's very possible that a new address could be derived between the time when the wallet data was exported and when it will be imported. This use case might be very specific to our model, but the reason I figured we should request a BIP # for this is that to start using it, we need to pick a number for the purpose field and don't want to do it arbitrarily (and risk having to change it later) or overload 44 (which would be misleading). Did I either a) answer or b) misunderstand your questions? -- Matt Smith | Gem https://gem.co | GH: @thedoctor On 6/19/15 2:25 PM, Matt @ Envrin Group wrote: Hi Matt, I think your best bet is probably just push it out privately via blog post / Github, and see if it gains any traction with other developers. I'm a little uncertain as to the relevance though. All those variables (purpose, network, asset_type, account, change, index) need to be stored internally within the wallet database, as there's no way to retrieve the path used from just the address, correct? In that case, what's the meaning of that exact path structure when a) it can't be retrieved from just the address, and b) the values will be stored internally within the wallet when you lookup the address. Matt signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
m/##'/0'/99'/0' where 99 is the identifier for, say, counterparty What is stopping you from using m/44'/9'/a'/c/i as descibed here: http://doc.satoshilabs.com/slips/slip-0044.html to avoid having an internal mapping from 9'- 0' to find out what blockchain to query, this sounds like it should be trivial for any wallet. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
Say you generate a child key using the path m/6'/4'/7'/99'/0/196, which is what your proposed path structure would be, and it results in the address 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w. When the wallet notices a transaction in the blockchain that has 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w as an output, it's going to have to lookup the address within its database to get the values 6/4/7/99/0/196, as there's no way to retrieve them from just the address. So technically, you might as well just use m/account'/change/index if using hardened child keys, or m/change/index if not, as recommended, because the wallet will still function the exact same way. Matt On 06/20/2015 06:31 AM, Matt Smith wrote: I'm not sure I understand your question about the need to store paths in the wallet database -- there's no way to infer the path of an address inside an HD wallet from the address alone (short of an exhaustive search), and HD wallets need to store either the paths, addresses, or both that have been previously derived/used to monitor the blockchain usefully, but those facts aren't new or specific to this path format. The motivation for this path structure over standard bip44 is that it separates the concept of network (or which blockchain I'm using) and coin_type (or what kind of thing I'm sending over that blockchain). This is useful, for example, if I want to import a wallet into my application and I know that an account was in use at m/##'/0'/99'/0' where 99 is the identifier for, say, counterparty - I only need to check the addresses derived below that path for balances against counterpartyd. It may be worth pointing out that I expect multisig HD wallet imports to require master keys and a list of account paths – not a list of addresses, as it's very possible that a new address could be derived between the time when the wallet data was exported and when it will be imported. This use case might be very specific to our model, but the reason I figured we should request a BIP # for this is that to start using it, we need to pick a number for the purpose field and don't want to do it arbitrarily (and risk having to change it later) or overload 44 (which would be misleading). Did I either a) answer or b) misunderstand your questions? -- Matt Smith | Gem https://gem.co | GH: @thedoctor On 6/19/15 2:25 PM, Matt @ Envrin Group wrote: Hi Matt, I think your best bet is probably just push it out privately via blog post / Github, and see if it gains any traction with other developers. I'm a little uncertain as to the relevance though. All those variables (purpose, network, asset_type, account, change, index) need to be stored internally within the wallet database, as there's no way to retrieve the path used from just the address, correct? In that case, what's the meaning of that exact path structure when a) it can't be retrieved from just the address, and b) the values will be stored internally within the wallet when you lookup the address. Matt -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
