Published on: 2015-06-20T10:11:41+00:00
The author of the message expresses concerns regarding HD chain standards like Bip43/44, stating that while they are designed to allow users to use different wallets with the same seed/wordlist, there can be risks and potential loss of coins when re-importing or re-creating a wallet. The author argues that a user's non-blockchain metadata cannot be recovered through HD seed recovery, as it is only intended for disaster recovery purposes. Reimporting an HD seed is considered an expert feature that requires manual configuration. The author also suggests that creating deep level chains in HD wallets requires more CPU power and may cause delays when signing or deriving on hardware wallets like Trezor or Digitalbitbox.The author questions whether the current standards of HD chain structures lead users and developers in the right direction, pointing out examples of wallets like Electrum and Breadwallet that do not follow the Bip39 standard or support Bip44. To provide further information, the message includes links to Bitcointalk.org and Github.com.In another discussion, the implementation of a new token layer on an existing blockchain is being discussed. The use of HD wallets to generate new token addresses is seen as a straightforward task, but maintaining them could be challenging. However, using this method allows older HD wallet software to understand which blockchain to query for utxos and generate valid addresses without updates, even if it doesn't know about the specific token. This approach is particularly useful when developing against platforms where client updates cannot be enforced. It is clarified that this is not a general-purpose successor to BIP44. Another member suggests using a different path, m/44'/9'/a'/c/i, instead of relying on internal mappings.In an email exchange between two individuals named Matt, the use of a proposed path structure in HD wallets is discussed. The proposed structure separates the concepts of network and coin type, which would be valuable when importing a wallet into an application and checking addresses derived below a specific path for balances against a specific blockchain. However, concerns are raised about the relevance of storing all variables of the path structure in the wallet database, as there is no way to retrieve the path used from just the address. It is suggested that using m/account'/change/index or m/change/index, depending on whether hardened child keys are used, would be more appropriate. Multisig HD wallet imports may require master keys and a list of account paths instead of addresses due to the possibility of new addresses being derived between exporting and importing wallet data.Another context provided discusses the use of the identifier "99" to identify a counterparty in the blockchain system. Concerns are raised about the use of this identifier, and alternatives are suggested. One proposal is to use m/44'/9'/a'/c/i, as described in the documentation for slip-0044, to avoid the need for internal mappings. Considering these suggestions could improve the efficiency and accuracy of the blockchain system.Matt Smith from Gem discusses the need to store paths in the wallet database. He explains that there is no way to infer the path of an address inside an HD wallet from the address alone. Therefore, it is necessary to store either the paths, addresses, or both that have been previously derived or used to monitor the blockchain effectively. The motivation for the proposed path structure is that it separates the concepts of network and coin type, which is useful when importing a wallet into an application and knowing that an account was in use at a specific path. Matt also mentions that multisig HD wallet imports may require master keys and a list of account paths rather than just addresses. He concludes by stating that this use case might be specific to their model and requests a BIP number to start using it.Gem, a company offering wallets for multiple cryptocurrencies, is considering a new HD wallet path structure. This structure aims to validate address formats, select appropriate daemons for scanning tokenized assets, and choose multiple blockchain data sources by utilizing information in the HDNode's path without maintaining explicit mappings. The proposed path structure separates the coin_type field into network and asset_type and is m/purpose'/network'/asset_type'/account'/change/index. However, there are concerns about storing all the variables of the path structure in the wallet database, as there is no way to retrieve the path from just the address. Gem is considering publishing this information in a blog post or requesting a BIP number for further development. They are also seeking feedback and suggestions from the community.Overall, these discussions highlight the challenges, risks, and possible improvements related to HD chain standards, token layer implementation, identifier usage, and HD wallet path structures in the blockchain system.
Updated on: 2023-08-01T13:26:57.817120+00:00