Published on: 2016-05-15T17:36:54+00:00
In an email conversation, Daniel Weigl and Aaron Voisine discussed the idea of using 0x40000000 as the next available number to specify witness addresses. Weigl expressed concern that every BIP-compatible wallet in the future would have to implement all legacy derivation and transaction schemes. Voisine agreed that old derivations would still need to be supported for many decades, but suggested using a new BIP43 purpose number for segwit only wallets. He also proposed specifying 0x40000000/1 for the change/receive index to maintain compatibility with other schemes for upgrading existing wallets.Another discussion focused on implementing a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between normal and witness accounts. However, this approach would require all Bip-compatible wallets in the future to implement all legacy derivation and transaction schemes and could result in non-deterministic failures when importing seeds or xPriv/xPub across different capable wallets. The solution proposed was to use 0x40000000 as the bit field flag to specify witness addresses, compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives.Jonas Schnelli raised the issue of the lack of BIP39 import support in wallets such as Schildbachs android wallet, Electrum, and Breadwallet. It was confirmed that these wallets are not BIP44 compatible, and there were concerns about the security risks involved in importing a bip39 mnemonic into a hardware wallet. Despite the potential risks, it was recommended to send all coins to the new seed.Electrum's developer explained that they do not support Bip39 import due to the lack of a version number in BIP39 seed phrases, which is needed for maintaining backward compatibility. As Electrum allocated a new version number for seed phrases derived to segwit addresses, BIP39 designers would need to change the semantics of their checksum bits to encode a version number for segwit.There were discussions about the challenges of moving funds to a new wallet, potential loss of funds if the old wallet has used more than 1000 addresses, and the need for wallets to implement BIP32 HD. Importing a wallet, especially cross-wallet imports, was considered a tricky step that may require expertise and further improvements.BIP43 and BIP44 were discussed, with BIP43 defining how balance retrieval works and BIP44 based on this idea. The goal was to ensure that the same balance is always seen on wallets that use the same BIP and seed.Opinions differed on whether importing a BIP32 wallet is still an expert job. Some argued that it is not, as reasonable wallets now use BIP39 mnemonic for this purpose. However, concerns were raised about cross-wallet imports using BIP39 and the potential problems associated with it.The email thread also touched on the topic of recovering funds from a wallet conforming to BIPXX, which requires wallet software to handle BIPXX. Importing a bip32 wallet was still considered an expert job, and there were discussions on how to improve the process.A proposed scheme involved using the chain index instead of the account index to indicate the type of address, but it created confusion regarding wallet compatibility with segwit. It was suggested to have another BIP specifically for segwit to clarify compatibility.In a discussion about the default BIP32 wallet layout, Aaron Voisine suggested using a bit field flag to specify the type of address. He proposed using 0x40000000 as the flag since 0x80000000 is already used for hardened derivation. However, Pavol Rusnak questioned the advantages of this optimization and noted that the discussion was off-topic as they were discussing multiple-accounts per wallet layout, not one-account-per-wallet design.The idea of specifying the type of address as a bit field flag is liked because it avoids checking multiple address types for each key. The suggestion was to use 0x40000000 as the flag, which would be compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives. Another option proposed was to define a new derivation path parallel to Bip44, allowing users to choose between a "Normal account" and a "Witness account". Pavol Rusnak from SatoshiLabs.com suggested that option #2 is better and they plan to implement it in myTREZOR. There are plans for BIP44 compliant wallets, but no visible results yet.Daniel Weigl suggested two options for improving the wallet experience. The second option involves defining a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between a "normal" or "witness" account. The team agreed that option #2 would be better and plans to implement it in myTREZOR.
Updated on: 2023-08-01T18:21:28.595777+00:00