Published on: 2018-04-10T02:54:08+00:00
The proposed Bitcoin Improvement Proposal (BIP XXX) aims to extend the private key format in order to specify the type of public key it corresponds to. Currently, when importing a private key, the wallet has to assume all possible types of public keys, resulting in the need to track each alternative. The proposal suggests adding new values to the table to indicate the type of public key associated with the private key, such as P2PKH, P2WPKH, and P2SH. This extension would allow wallets to track only the specific corresponding public key when importing a private key.The motivation behind this proposal is the presence of various types of public keys that can be associated with a given private key, such as legacy formats and SegWit formats. The existing private key format lacks the ability to specify which type of public key was used, leading to ambiguity and the need for wallets to try all possible scripts. The proposed extension seeks to address this issue by providing a clear indication of the type of public key associated with a private key.The compatibility of the Bech32 and Wallet Import Format (WIF) payload format is discussed in the Bitcoin-dev mailing list. The ambiguity of the current WIF format is causing obstacles for the release of a SegWit-capable version of Electrum. Two options are presented: either disable private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or define a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Other wallet developers are asked about their plans for exporting private keys used in SegWit scripts in the current WIF format.In the discussion, user AJ West raises concerns about whether wallet software should attempt to error-correct private keys. Thomas Voegtlin, the developer of Electrum, responds to Pieter Wuille's comment on checksum computation for the Bech32 format, stating that the ambiguity in the WIF format is holding him back from releasing a SegWit-capable version of Electrum. Voegtlin believes it is unacceptable to use the current WIF format with SegWit scripts and suggests either disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon or defining his own WIF extension for Electrum. He seeks input from other wallet developers, particularly Core.Pieter Wuille, a Bitcoin Core developer, expresses concerns about the ambiguity of the Wallet Import Format (WIF) when used with Segregated Witness (SegWit) scripts. He argues that the current WIF format is not suitable for use with SegWit scripts and could create technological debt by requiring wallets to try all possible scripts. He suggests two options: disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or defining a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Wuille seeks information on the plans of other wallet developers, especially Core.Thomas Voegtlin proposes using a bech32 format for private keys if they are to be used with a bech32 address. However, he is unsure if such a format has already been proposed. Meanwhile, Pieter has been working on an "extended bech32" format with a stronger checksum protection compared to the normal bech32 format. This extended format is particularly useful for private keys since there is no option to ask the receiver for a corrected version. Although this task is low priority, significant computation work is required to find a good checksum.The Wallet Import Format (WIF) is a representation of private keys for Bitcoin. The current WIF format appends a 0x01 byte after the raw private key when used with a compressed public key, allowing wallets to associate a single Bitcoin address with a WIF key. However, extending the semantics of that byte to signal segwit scripts would be useful, as these scripts result in different addresses. Proposals suggest adding new bytes to WIF for segwit script embedded in P2SH and native segwit script. It is not necessary to use distinct bytes for certain types as the P2SH script is not known anyway. Additionally, a bech32 format can be used for private keys intended for use with a bech32 address. It is important to note that this proposal will not result in a visible change at the beginning of the string, similar to the compressed/uncompressed indicator. However, improvements to this aspect may be made in the future.
Updated on: 2023-08-01T21:53:22.351002+00:00