📅 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.
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 18:06:05
in reply to nevent1q…rvhz
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 18:06:05Event JSON
{
"id": "0bb0b1ede92a21697bd7b495d6d2c94a6a9e735d752bcf1a9a523b52aaf44e89",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686161165,
"kind": 1,
"tags": [
[
"e",
"5b6b527cea5144e7ff0ce68595e52fc472c9b15e83188a0b6a74bd11f42185fe",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2017-09-15\n📝 Original message:The Wallet Import Format (WIF) currently appends a 0x01 byte after the\nraw private key, when that key needs to be used in conjunction with a\ncompressed public key. This allows wallets to associate a single Bitcoin\naddress to a WIF key.\n\nIt would be useful to extend the semantics of that byte, to signal for\nsegwit scripts, because these scripts result in different addresses.\nThat way, a WIF private key can still be associated to a single Bitcoin\naddress.\n\nWhat WIF currently does is:\n\nNothing -\u003e uncompressed pubkey\n0x01 -\u003e compressed pubkeys, non-segwit (can be used in P2PKH or P2SH)\n\nWe could extend it as follows:\n\n0x02 -\u003e segwit script embedded in P2SH (P2WPKH or P2WSH)\n0x03 -\u003e native segwit script (P2WKH or P2WSH)\n\n\nNote 1: This is similar to my {x,y,z}{pub,prv} proposal for bip32\nextended keys. (see other thread)\n\nNote 2: It is probably not useful to use distinct bytes for P2WKH and\nP2WSH, because the P2SH script is not known anyway. We did not do it for\nnon-segwit addresses, I guess we should keep it the way it is.\n\nNote 3: we could also use a bech32 format for the private key, if it is\ngoing to be used with a bech32 address. I am not sure if such a format\nhas been proposed already.\n\nNote 4: my proposal will not result in a user visible change at the\nbeginning of the string, like we have for compressed/uncompressed. This\ncould be improved.",
"sig": "12c08eabe0157eb1016be112f06020dc5cbd31153af873ad63e864e605ed14f628c54196adacc081e329c3a804d298d56216284109ab4ad7874f51ace110d71b"
}