BIP32 "wallet structure" in use? Remove it? [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2014-04-26T16:03:31+00:00


Summary:

The email conversation between Gregory Maxwell and Jim discusses the possibility of creating a lowest common denominator for wallet interoperability in Bitcoin. Jim is concerned about losing intra-client HD compatibility for BIP32 wallets, which could result in vendor lock-in for users. Gregory argues that achieving interoperability at this level is not possible in general, except as an explicit compatibility feature. He points out that the structure of the derivation defines and constrains functionality, so wallets cannot be structure compatible unless they have the same features and behavior with respect to key management.Gregory suggests that supporting a compatibility mode where a wallet has just a subset of features that work when loaded into different systems could be possible but doubts that it would be widely used. He believes that heavily constraining functionality to achieve interoperability is too high a price to pay. He also argues that calling it "vendor lock-in" is overblown because users can transfer their funds if they want to change wallets. The discussion also involves Jeff Garzik, a Bitcoin core developer and open-source evangelist.In another email conversation between Pavol Rusnak and Tier Nolan, the topic of importing an unknown wallet is discussed. Tier Nolan suggests having a defined way to import such wallets, but Pavol Rusnak dismisses it as impossible due to the lack of knowledge about the wallet's structure. Pieter, who is part of the conversation, proposes a solution by defining something like "BIP44 import-compatible" to guarantee not losing any funds when importing even if the application doesn't support all BIP44 features.In a discussion thread from 2014, Tier Nolan suggests that having a defined way to import an unknown wallet could be a solution. However, another participant disagrees and states that there is no way to import a wallet if its structure is not known. They explain that it may be possible to find all the addresses for a root seed given a blockchain, but this would not work if the keyspace is almost infinite due to the potential variability of the wallet hierarchy.Tamas Blummer responds to Tier Nolan's suggestion and states that it is possible to discover any funds associated with a seed, provided there are set limits to the gap of address use, depth of hierarchy, and gap in use of parallel branches. He recommends using limits of 20, 6, and 0 respectively. Tamas notes that there is already a gap in parallel branches that fails with BIP64 as it starts with m/64'/... without having m/63'.In another email conversation between Tamas Blummer and Tier Nolan, they discuss the possibility of discovering any funds associated with a seed. Blummer suggests that this is possible given set limits including gap of address use, depth of hierarchy, and gap in use of parallel branches. Nolan suggests having a defined way to import an unknown wallet and defining gap space and search ordering. They agree that given a blockchain and a root seed, it should be possible to find all the addresses for that root seed regardless of the wallet hierarchy used.The conversation between Bitcoin developers Gregory Maxwell and Thomas Voegtlin revolves around the idea of wallet interoperability. Maxwell argues that achieving full wallet interoperability is not possible without heavily constraining functionality, which would hinder progress and innovation in developing new features. He suggests that a compatibility mode where a wallet has a subset of features could be supported. Voegtlin agrees with Maxwell's stance, stating that the cost of interoperability is too high and partial compatibility could result in users being unable to recover all their funds when using another wallet. The challenges involved in making a wallet portable between systems, including key management and metadata handling, are also discussed.A comment is made on Github regarding the BIP43 pull request, which aims to add a "purpose" of 0' for single account wallets. This will allow for backwards compatibility and interoperability for existing single account BIP32 implementations. However, it would require a new BIP and wouldn't follow the BIP43 recommendation unless BIP0 is obtained. Mike Hearn questions the future popularity of cloning wallets between devices and suggests that people may want to use different UIs to access the same wallets, which would require sharing key trees. However, full-blown wallet metadata sync would also be needed, resulting in a complex compatibility matrix.The discussion revolves around the potential popularity of cloning wallets between devices in the future. Currently, there is no provision for sharing a wallet between different platforms, and users have to choose one or manually split their funds. However, many people would prefer using different UIs to access the same wallets, which can be achieved by sharing key trees and full-blown wallet metadata sync. A complex compatibility matrix may emerge as a result.In an email exchange, Jim expresses concern over the potential loss of intra-client HD compatibility for BIP32 wallets, which could affect millions of users in the next year.


Updated on: 2023-08-01T09:00:19.965295+00:00