Published on: 2015-02-03T10:44:43+00:00
In an email conversation on March 2, 2015, Andreas Schildbach and Pavol Rusnak discussed the use of keys on multiple blockchains. Initially, Schildbach stated that it is possible, but later clarified that according to BIP32, keys cannot be used on multiple blockchains. However, this issue was addressed in BIP43, which fixed the problem.Rusnak suggested using the block number as an option, but it was argued that this may not be the best choice as keys can be used on multiple blockchains. The conversation also touched on QR codes, with a suggestion for more descriptive parameters. However, it was noted that QR codes are size sensitive and saving data is a primary concern.Another discussion on March 2, 2015, involved Rusnak inquiring about the appropriate gap limit for wallets using h=bip32. The response he received was that the wallet should follow the spec, which currently has limited information on gap limits within the BIP32-hierarchy. This lack of information may lead to wallets transitioning to a more comprehensive standard in the future. Rusnak also asked about the h value for his myTREZOR wallets, and the response he received was that if it follows BIP32, h=bip32 is sufficient.Levin Keller proposed a bitcoin-pub-export protocol in an email, including parameters such as the "path" parameter. However, no specific use case was identified for it. Keller also discussed the "subchains" parameter and whether a wallet should generate receiving addresses for multiple external chains. It was concluded that using just the first chain as the external one would suffice. Keller also shared his preference for Unix timestamps or block numbers for the creation date parameter.The author of the email thread questioned the need for specific HD schemes like BIP32 or BIP44 and proposed a more general export scheme. The required parameter is the gap limit, while optional parameters include which node of the derivation chain is exported, subnodes used for external and internal purposes, and creation date. A proposed export scheme was bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]&path=[path in derivation tree]&subchains=[numbers]&creationdate=[unixtimestamp]. The author also discussed gap limits and h values for wallets.In an email exchange on February 3, 2015, Schildbach and Rusnak discussed parameterizing wallets with regards to BIPs. Schildbach stated that it would not be effective as it is impossible to predict future BIPs. Rusnak inquired about the gap limit for wallets encountering h=bip32 and the appropriate h value for myTREZOR wallets. He specified that myTREZOR wallets are essentially BIP44 wallets that produce h=bip32 xpubs with a gap limit of 20.On February 2, 2015, Rusnak proposed a change to address discovery in BIP32 and BIP44. He suggested scanning xpub/0/i and xpub/1/j chains using a gap limit G, replacing ?h=bip32 with ?t=01&g=20. However, doubts were expressed about parameterizing the process in this way, and it was suggested to use the BIP number directly.In a discussion thread on February 2, 2015, a user suggested using a human-readable date format YYYYMMDD in Bitcoin strings, but another user argued that it is unnecessary as Bitcoin deals with seconds since epoch. The user advocating for human-readable timestamps argued that it saves storage space. Suggestions were made for using an eight-character timestamp or a date format that saves two characters.Schildbach and Rusnak had a discussion on February 2, 2015, about the differences between BIP32-hierarchy and BIP44 in address discovery. Schildbach believed it was more important to describe how addresses should be discovered, while Rusnak preferred a human-readable format for creation dates.In another discussion on February 2, 2015, Schildbach stated that Bitcoin strings are not meant to be read by humans, so human-readable timestamps are unnecessary. However, Rusnak argued that having a transparent, human-readable option is beneficial and saves space in QR codes.A conversation between Rusnak and an unknown individual discussed the h=bip32 hierarchy and its application to BIP44 generated xpubs. They also discussed the creation date of wallets and the preference for a human-readable format like YYYYMMDD.Schildbach and Rusnak discussed the "h=bip32" hierarchy and its relation to xpub/0/i and xpub/1/j chains. They also mentioned that this hierarchy applies to BIP44 generated xpubs.
Updated on: 2023-08-01T11:21:15.115585+00:00