Published on: 2017-09-07T19:02:17+00:00
On September 5th, 2017, a discussion took place on the Bitcoin-dev forum regarding the serialization format of HD seeds. Kabuto Samourai addressed a possible miscommunication between Luke and Thomas regarding the encoding of {x,y,z}{pub,prv} distinctions when exporting a root master HD seed. They argued that this encoding is unnecessary as the root seed should derive all paths for all coins. However, they suggested that changing the serialization version bytes is appropriate and essential when exporting/importing an account-level seed for watch-only and receive address generation to avoid loss of funds. Luke proposed revisiting a proposal he made in March that handles not only simple HD seeds but also multisig HD and similar cases.Pavol Rusnak, the CTO of SatoshiLabs, suggested using a child number field instead of a fingerprint in the serialization format. He believed that it would be desirable to use the same seed for all different script formats. If he were designing the format today, he would drop the fingerprint and expand the child number to the full BIP32 path. The benefit of this proposal is that the depth already exists, so it is known how long the BIP32 path would be. The proposal included using 4 byte version bytes, 1 byte depth, depth * 4 bytes bip32 path, 32 bytes, and 33 bytes.The email thread also discussed expanding the number of version prefixes to eliminate ambiguity regarding P2SH scripts. Thomas Voegtlin expressed concerns about reaching consensus and the need for extra safeguards if this change were to be implemented. He proposed the "xyz" proposal as a simpler solution that would require minimal changes to existing software. However, Kabuto argued that separating P2SH from P2PKH may not have strong benefits due to the infinite possibilities of P2SH scripts.Another proposal was made to develop a new standard based on Bech32 for including the key or wallet birthdate. Thomas Voegtlin suggested using additional version bytes to indicate the type of output script used with the public keys. He recommended that this change should be visible to users, and he proposed prefixes such as xpub/xprv for P2PKH or P2SH, ypub/yprv for (P2WPKH or P2WSH) nested in P2SH, and zpub/zprv for P2WPKH or P2WSH. It was argued that xpub/xprv serialization should not be used to encode how these keys are used, but the existence of version bytes used to signal whether keys will be used on testnet or mainnet goes against this argument. Without signaling the script type in the version bytes, developers might resort to using "dirtier tricks" such as the bip32 child number field in combination with bip43/bip44/bip49.In the ongoing debates within the Bitcoin development community, Luke Dashjr suggested using the same seed for all different script formats, while Thomas Voegtlin disagreed with this view. Voegtlin argued that wallets must implement all script formats to ensure users can recover their funds from their mnemonic seed. He also disagreed with Dashjr's statement that xpub/xprv are already being used for both P2PKH and P2SH, highlighting that this has resulted in users receiving coins on addresses they do not control.The discussion also touched upon the use of xpub/xprv serialization to encode how keys are used. Voegtlin argued that this should be done instead of just considering it a format for keys. Dashjr, on the other hand, suggested using the child number field instead of version bytes for signaling the script type. The conversation shed light on the ongoing debates regarding key management and storage practices within the Bitcoin development community.In a forum post, Thomas Voegtlin provided a table of different prefixes and their corresponding descriptions related to P2PKH or P2SH and (P2WPKH or P2WSH) nested in P2SH. Pavol Rusnak, as the CTO of SatoshiLabs, responded to an argument regarding xpub/xprv serialization, stating that he was fine with it, but it is unclear which specific proposal he was referring to.The recommendation for BIP32 extended public/private keys is to use version bytes that indicate the user-visible xpub/xprv prefix. Different version bytes are suggested for other networks, such as tpub/tprv for testnet. The proposed changes aim to inform the receiving utility about the exact derivation method used for pubkeys, ensuring that third parties handling xpubs do not require additional information from users. The ongoing discussions reflect efforts to improve key management and storage practices while considering the challenges faced by wallet implementations and the need for consensus within the Bitcoin development community.
Updated on: 2023-08-01T21:44:44.550021+00:00