Author: Jeremy Spilman 2013-06-20 03:54:18
Published on: 2013-06-20T03:54:18+00:00
The BIP 32 specifies how to use the first three tree levels: M/i/j/k, i~wallet, j~Internal/External, k~address. The first level is type-1 derived and thus creating new wallets without pre-computing them from the offline wallet is not free. To generate new receive chains from a watch-only wallet, we can keep a cache of PubKey/ChainCode for unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j]. It might be helpful to add to the 'Compatibility' section some minimum expectations about how a wallet should be 'probed' when imported. These extra wallet chains could behave as different wallets, or sub-wallets but they don't necessarily need to. A single-wallet implementation treats this merely as an address-generation algorithm and does not expose any hierarchy to the user interface. While it is possible to support separate ledgers, balances, etc., it is certainly not required, and you get all the benefits either way.To generate and receive payments into BIP32-style addresses, similar underlying wallet code is needed. If there is a benefit to using the same parent pubkey across multiple services, as a form of identity, we could make the data structure { ParentPubKey, Addend, ChainCode }.Fundamentally, if one is designing for persistent long-term relationships, a mechanism for generating address chains can be built in so that no further communication after the initial exchange is required and it need not complicate the wallet.
Updated on: 2023-06-06T18:54:00.695693+00:00