Published on: 2022-08-04T07:09:33+00:00
A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor.
Updated on: 2023-08-02T07:12:45.744421+00:00