Thomas Voegtlin [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-15 📝 Original message:The Wallet Import Format ...
📅 Original date posted:2017-09-15
📝 Original message:The Wallet Import Format (WIF) currently appends a 0x01 byte after the
raw private key, when that key needs to be used in conjunction with a
compressed public key. This allows wallets to associate a single Bitcoin
address to a WIF key.
It would be useful to extend the semantics of that byte, to signal for
segwit scripts, because these scripts result in different addresses.
That way, a WIF private key can still be associated to a single Bitcoin
address.
What WIF currently does is:
Nothing -> uncompressed pubkey
0x01 -> compressed pubkeys, non-segwit (can be used in P2PKH or P2SH)
We could extend it as follows:
0x02 -> segwit script embedded in P2SH (P2WPKH or P2WSH)
0x03 -> native segwit script (P2WKH or P2WSH)
Note 1: This is similar to my {x,y,z}{pub,prv} proposal for bip32
extended keys. (see other thread)
Note 2: It is probably not useful to use distinct bytes for P2WKH and
P2WSH, because the P2SH script is not known anyway. We did not do it for
non-segwit addresses, I guess we should keep it the way it is.
Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.
Note 4: my proposal will not result in a user visible change at the
beginning of the string, like we have for compressed/uncompressed. This
could be improved.
📝 Original message:The Wallet Import Format (WIF) currently appends a 0x01 byte after the
raw private key, when that key needs to be used in conjunction with a
compressed public key. This allows wallets to associate a single Bitcoin
address to a WIF key.
It would be useful to extend the semantics of that byte, to signal for
segwit scripts, because these scripts result in different addresses.
That way, a WIF private key can still be associated to a single Bitcoin
address.
What WIF currently does is:
Nothing -> uncompressed pubkey
0x01 -> compressed pubkeys, non-segwit (can be used in P2PKH or P2SH)
We could extend it as follows:
0x02 -> segwit script embedded in P2SH (P2WPKH or P2WSH)
0x03 -> native segwit script (P2WKH or P2WSH)
Note 1: This is similar to my {x,y,z}{pub,prv} proposal for bip32
extended keys. (see other thread)
Note 2: It is probably not useful to use distinct bytes for P2WKH and
P2WSH, because the P2SH script is not known anyway. We did not do it for
non-segwit addresses, I guess we should keep it the way it is.
Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.
Note 4: my proposal will not result in a user visible change at the
beginning of the string, like we have for compressed/uncompressed. This
could be improved.