Published on: 2014-04-24T08:15:18+00:00
In a series of email exchanges among Bitcoin developers, discussions and debates took place regarding the implementation and compatibility of BIP64 with BIP32. Pavol Rusnak argued that clients should be able to specify which subwallet they are accessing to ensure compatibility. However, he stated that calling these clients BIP64 compatible would be inaccurate if they cannot distinguish between subwallets and keep coins apart. There were differing views on the restrictiveness of BIP64, with some developers asserting that most end users do not need subwallet support.Developers also discussed the behavior of software that scans all accounts specified by BIP64 without providing user interface options to distinguish them or keep the coins apart. Marek explained that mixing funds across accounts is not compliant with the spec, and the wallet should never mix coins across different accounts. Pieter Wuille questioned the need for mixing funds between accounts, as it was seen as a niche requirement.Furthermore, conversations revolved around storing wallet birth time and importing clients. Tamas Blummer suggested appending key birth to key serialization in xprv, while modifying the serialization format was considered a potential solution. The goal was to find a solution that fit all requirements, but developers had differing opinions.Discussions also touched on the standardization of wallet structures, the importance of compatibility, and the challenges of achieving a single system that is compatible across multiple platforms. Developers emphasized the need for a standard structure for sharing wallets, with debates about the best way to store seeds and master nodes. There were disagreements on specific aspects of implementation, but the overall goal was to improve functionality and meet the needs of different users.There were suggestions to use one seed across different chains with separate master nodes derived by replacing "Bitcoin seed" with something chain-specific. Another suggestion was to have each encoded node, including master nodes, with a chain-specific serialization magic. It was debated whether using "cointype" in the bip32 path was necessary, but it was seen as an elegant solution for a single backup that can handle all coins with one master.The discussions also addressed the need for compatibility and standardization among wallet software. The importance of having a single system compatible over a large number of systems was emphasized. However, there were disagreements on implementing BIP64 fully or not at all, as using only a subset of the specification could confuse users.In conclusion, the conversations among Bitcoin developers revolved around the implementation and compatibility of BIP64 with BIP32, the need for standard structures in sharing wallets, and the challenges of achieving compatibility across multiple platforms. There were differing views on various aspects, such as the restrictiveness of BIP64 and the necessity of multiple subwallets. The discussions highlighted the ongoing efforts to find the best solutions and improve the functionality of Bitcoin wallets.During discussions in March 2014, Bitcoin developers focused on improving the structure of Bitcoin Improvement Proposal (BIP) and Bitcoin wallets. One suggestion was to increase the number of unused addresses available in lightweight or server-based wallets and count the number of unused addresses since the beginning instead of using a "gap limit." Bandwidth issues for Electrum and Mycelium were also addressed, with proposals to pre-generate a larger lookahead region and request more data at once.The topic of altcoins was brought up, with Testnet being highlighted as an important one. Different methods of identifying altcoins were discussed, such as using a hash of certain words or maintaining a directory of magic numbers. The purpose of the "reserved" feature in Bitcoin was questioned, and it was confirmed that it was intended for multisig addresses.Andreas Schildbach initiated a discussion on finding a better structure for Bitcoin wallets, emphasizing the need for interoperability and addressing bandwidth limitations. Distinguishing between merchant and regular user accounts was proposed, and a BIP32 wallet structure (/m/cointype/reserved'/account'/change/n) was suggested by Mike Hearn. Interoperability between wallets was deemed important, although metadata might be necessary alongside the hierarchical structure.At the Inside Bitcoin Conference in Berlin, developers debated the standardization of BIP32 wallet structures. They discussed the use of hierarchy and suggested using a hash of certain words instead of a directory of magic numbers. Armory Technologies announced plans to implement multi-sig/linked wallets, allowing users to switch to new apps without losing their coin history. Discouraging the use of a common root keychain for multiple keys in the same P2SH address was recommended.Discussions continued in March 2014 to create a compatible BIP32 wallet structure for different wallets. Mike Hearn proposed a new structure (/m/cointype/reserved'/account'/change/n) that was agreed upon by Thomas V and Marek. The structure aimed to meet users' needs while allowing flexibility.
Updated on: 2023-08-01T08:08:37.970792+00:00