📅 Original date posted:2018-04-04
📝 Original message:I took the liberty of turning this into a BIP proposal -- the
formatted version can be seen here:
https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki
<pre>
BIP: XXX
Layer: Applications
Title: Typed Private Keys
Author: Karl-Johan Alm <karljohan-alm at garage.co.jp>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
Status: Draft
Type: Standards Track
Created: 2018-04-04
License: CC0-1.0
</pre>
== Abstract ==
An extension to the private key (WIF) format to specify what kind of
public key the private key corresponds to.
== Motivation ==
There are several types of public keys which can all be associated
with a given private key: P2PKH (legacy <code>1...</code> format),
P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc.
While private keys have a 1-byte suffix indicating whether the
corresponding public key is compressed (<code>0x01</code>) or not
(<code>0x00</code>), there is no way of knowing what kind of public
keys were associated with the private key. As a result, when importing
a private key, the wallet has to assume all kinds, and keep track of
each possible alternative.
By extending the suffix, we can specify what kind of public key was
associated with the given private key.
== Specification ==
Currently, private keys are stored as a uint256 (private key data)
followed by a uint8 (compressed flag). The latter is extended to
specify the public key types:
{|class="wikitable" style="text-align: center;"
|-
!Value
!Type
!Compr
!Clarification
|-
|<code>0x00</code>||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public
key. Unknown public key format
|-
|<code>0x01</code>||P2PKH_COMPRESSED||Yes||Compressed legacy public
key. Unknown public key format
|-
|<code>0x80</code>||P2PKH||Yes||Compressed legacy public key. Legacy
public key format (<code>1...</code>)
|-
|<code>0x81</code>||P2WPKH||Yes||Bech32 format (native Segwit)
|-
|<code>0x82</code>||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH
(<code>3...</code>)
|-
|<code>0x85</code>||P2SH|| — ||Non-Segwit BIP16 P2SH (<code>3...</code>)
|-
|<code>0x86</code>||P2WSH|| — ||Native Segwit P2SH
|-
|<code>0x87</code>||P2WSH_P2SH|| — ||Native Segwit P2SH nested
in BIP16 P2SH
|}
When a wallet imports a private key, it will have two outcomes:
* the key is using one of the legacy types, in which case all types
must be accounted for
* the key is using one of the extended types, in which case the wallet
need only track the specific corresponding public key
== Rationale ==
TODO
== Compatibility ==
This proposal is not backwards compatible, in that software that does
not recognize the new types will not understand the compressed flag.
It would be trivial to change this, by keeping the 'uncompressed'
state as it is (0) and changing 'compressed' to be 'anything not 0',
as opposed to 'the value 1'.
The proposal *is* backwards compatible in that new wallet software
will always understand the old WIF format, however. It will, as it
does today, assume that any kind of public key is possible, and will
have to track all of them, as it has to today.
== Acknowledgements ==
This BIP is based on the initial proposal by Thomas Voegtlin
<thomasv at electrum.org> on the Bitcoin Dev mailing
list<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html</ref>;
and the Electrum 3.0
implementation<ref>https://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108</ref>;
== Reference implementation ==
There is a partial implementation which adds, but does not use, the
types described in this BIP here:
https://github.com/bitcoin/bitcoin/pull/12869
== References ==
<references/>
== Copyright ==
This document is licensed under the Creative Commons CC0 1.0 Universal license.
On Mon, Sep 18, 2017 at 12:36 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bech32 and WIF payload format are mostly orthogonal issues. You can design a
> new wallet import format now and later switch it to Bech32.
>
> On Sep 17, 2017, at 7:42 AM, AJ West via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi I have a small interjection about the point on error correction (excuse
> me if it seems elementary). Isn't there an argument to be made where a
> wallet software should never attempt to figure out the 'correct' address, or
> in this case private key? I don't think it's crazy to suggest somebody could
> import a slightly erroneous WIF, the software gracefully error-corrects any
> problem, but then the user copies that error onward such as in their backup
> processes like a paper wallet. I always hate to advocate against a feature,
> I'm just worried too much error correcting removes the burden of exactitude
> and attention of the user (eg. "I know I can have up to 4 errors").
>
> I'm pretty sure I read those arguments somewhere in a documentation or issue
> tracker/forum post. Maybe I'm misunderstanding the bigger picture in this
> particular case, but I was just reminded of that concept (even if it only
> applies generally).
>
> Thanks,
> AJ West
>
> On Sun, Sep 17, 2017 at 4:10 AM, Thomas Voegtlin via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On 17.09.2017 04:29, Pieter Wuille wrote:
>> >
>> > This has been a low-priority thing for me, though, and the computation
>> > work
>> > to find a good checksum is significant.
>> >
>>
>> Thanks for the info. I guess this means that a bech32 format for private
>> keys is not going to happen soon. Even if such a format was available,
>> the issue would remain for segwit-in-p2sh addresses, which use base58.
>>
>> The ambiguity of the WIF format is currently holding me from releasing a
>> segwit-capable version of Electrum. I believe it is not acceptable to
>> use the current WIF format with segwit scripts; that would just create
>> technological debt, forcing wallets to try all possible scripts. There
>> is a good reason why WIF adds a 0x01 byte for compressed pubkeys; it
>> makes it unambiguous.
>>
>> I see only two options:
>> 1. Disable private keys export in Electrum Segwit wallets, until a
>> common WIF extension has been agreed on.
>> 2. Define my own WIF extension for Electrum, and go ahead with it.
>>
>> Defining my own format does make sense for the xpub/xprv format, because
>> Electrum users need to share master public keys across Electrum wallets.
>> It makes much less sense for WIF, though, because WIF is mostly used to
>> import/sweep keys from other wallets.
>>
>> I would love to know what other wallet developers are going to do,
>> especially Core. Are you going to export private keys used in segwit
>> scripts in the current WIF format?
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Karl Johan Alm [ARCHIVE] /
npub1e7…fg307
2023-06-07 18:11:31
in reply to nevent1q…wya8
Author Public Key
npub1e7vdq905zr4xjr5nxuz58l9jcvffxq728ysl6m2xxgr024mjy5vq4fg307Published at
2023-06-07 18:11:31Event JSON
{
"id": "29d4939b70cd49239c06253cda2a185ac0062a7af63a1935cfbd17cab9b2ad75",
"pubkey": "cf98d015f410ea690e93370543fcb2c3129303ca3921fd6d463206f557722518",
"created_at": 1686161491,
"kind": 1,
"tags": [
[
"e",
"33a5582baca12d3929026e7e062a550a9139f88e50605ff591e84fc560a5393b",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-04-04\n📝 Original message:I took the liberty of turning this into a BIP proposal -- the\nformatted version can be seen here:\nhttps://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki\n\n\u003cpre\u003e\n BIP: XXX\n Layer: Applications\n Title: Typed Private Keys\n Author: Karl-Johan Alm \u003ckarljohan-alm at garage.co.jp\u003e\n Comments-Summary: No comments yet.\n Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX\n Status: Draft\n Type: Standards Track\n Created: 2018-04-04\n License: CC0-1.0\n\u003c/pre\u003e\n\n== Abstract ==\n\nAn extension to the private key (WIF) format to specify what kind of\npublic key the private key corresponds to.\n\n== Motivation ==\n\nThere are several types of public keys which can all be associated\nwith a given private key: P2PKH (legacy \u003ccode\u003e1...\u003c/code\u003e format),\nP2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc.\n\nWhile private keys have a 1-byte suffix indicating whether the\ncorresponding public key is compressed (\u003ccode\u003e0x01\u003c/code\u003e) or not\n(\u003ccode\u003e0x00\u003c/code\u003e), there is no way of knowing what kind of public\nkeys were associated with the private key. As a result, when importing\na private key, the wallet has to assume all kinds, and keep track of\neach possible alternative.\n\nBy extending the suffix, we can specify what kind of public key was\nassociated with the given private key.\n\n== Specification ==\n\nCurrently, private keys are stored as a uint256 (private key data)\nfollowed by a uint8 (compressed flag). The latter is extended to\nspecify the public key types:\n\n{|class=\"wikitable\" style=\"text-align: center;\"\n|-\n!Value\n!Type\n!Compr\n!Clarification\n|-\n|\u003ccode\u003e0x00\u003c/code\u003e||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public\nkey. Unknown public key format\n|-\n|\u003ccode\u003e0x01\u003c/code\u003e||P2PKH_COMPRESSED||Yes||Compressed legacy public\nkey. Unknown public key format\n|-\n|\u003ccode\u003e0x80\u003c/code\u003e||P2PKH||Yes||Compressed legacy public key. Legacy\npublic key format (\u003ccode\u003e1...\u003c/code\u003e)\n|-\n|\u003ccode\u003e0x81\u003c/code\u003e||P2WPKH||Yes||Bech32 format (native Segwit)\n|-\n|\u003ccode\u003e0x82\u003c/code\u003e||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH\n(\u003ccode\u003e3...\u003c/code\u003e)\n|-\n|\u003ccode\u003e0x85\u003c/code\u003e||P2SH|| \u0026mdash; ||Non-Segwit BIP16 P2SH (\u003ccode\u003e3...\u003c/code\u003e)\n|-\n|\u003ccode\u003e0x86\u003c/code\u003e||P2WSH|| \u0026mdash; ||Native Segwit P2SH\n|-\n|\u003ccode\u003e0x87\u003c/code\u003e||P2WSH_P2SH|| \u0026mdash; ||Native Segwit P2SH nested\nin BIP16 P2SH\n|}\n\nWhen a wallet imports a private key, it will have two outcomes:\n\n* the key is using one of the legacy types, in which case all types\nmust be accounted for\n* the key is using one of the extended types, in which case the wallet\nneed only track the specific corresponding public key\n\n== Rationale ==\n\nTODO\n\n== Compatibility ==\n\nThis proposal is not backwards compatible, in that software that does\nnot recognize the new types will not understand the compressed flag.\nIt would be trivial to change this, by keeping the 'uncompressed'\nstate as it is (0) and changing 'compressed' to be 'anything not 0',\nas opposed to 'the value 1'.\n\nThe proposal *is* backwards compatible in that new wallet software\nwill always understand the old WIF format, however. It will, as it\ndoes today, assume that any kind of public key is possible, and will\nhave to track all of them, as it has to today.\n\n== Acknowledgements ==\n\nThis BIP is based on the initial proposal by Thomas Voegtlin\n\u003cthomasv at electrum.org\u003e on the Bitcoin Dev mailing\nlist\u003cref\u003ehttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html\u003c/ref\u003e\nand the Electrum 3.0\nimplementation\u003cref\u003ehttps://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108\u003c/ref\u003e\n\n== Reference implementation ==\n\nThere is a partial implementation which adds, but does not use, the\ntypes described in this BIP here:\nhttps://github.com/bitcoin/bitcoin/pull/12869\n\n== References ==\n\n\u003creferences/\u003e\n\n== Copyright ==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.\n\nOn Mon, Sep 18, 2017 at 12:36 AM, Mark Friedenbach via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Bech32 and WIF payload format are mostly orthogonal issues. You can design a\n\u003e new wallet import format now and later switch it to Bech32.\n\u003e\n\u003e On Sep 17, 2017, at 7:42 AM, AJ West via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi I have a small interjection about the point on error correction (excuse\n\u003e me if it seems elementary). Isn't there an argument to be made where a\n\u003e wallet software should never attempt to figure out the 'correct' address, or\n\u003e in this case private key? I don't think it's crazy to suggest somebody could\n\u003e import a slightly erroneous WIF, the software gracefully error-corrects any\n\u003e problem, but then the user copies that error onward such as in their backup\n\u003e processes like a paper wallet. I always hate to advocate against a feature,\n\u003e I'm just worried too much error correcting removes the burden of exactitude\n\u003e and attention of the user (eg. \"I know I can have up to 4 errors\").\n\u003e\n\u003e I'm pretty sure I read those arguments somewhere in a documentation or issue\n\u003e tracker/forum post. Maybe I'm misunderstanding the bigger picture in this\n\u003e particular case, but I was just reminded of that concept (even if it only\n\u003e applies generally).\n\u003e\n\u003e Thanks,\n\u003e AJ West\n\u003e\n\u003e On Sun, Sep 17, 2017 at 4:10 AM, Thomas Voegtlin via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e On 17.09.2017 04:29, Pieter Wuille wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e This has been a low-priority thing for me, though, and the computation\n\u003e\u003e \u003e work\n\u003e\u003e \u003e to find a good checksum is significant.\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e Thanks for the info. I guess this means that a bech32 format for private\n\u003e\u003e keys is not going to happen soon. Even if such a format was available,\n\u003e\u003e the issue would remain for segwit-in-p2sh addresses, which use base58.\n\u003e\u003e\n\u003e\u003e The ambiguity of the WIF format is currently holding me from releasing a\n\u003e\u003e segwit-capable version of Electrum. I believe it is not acceptable to\n\u003e\u003e use the current WIF format with segwit scripts; that would just create\n\u003e\u003e technological debt, forcing wallets to try all possible scripts. There\n\u003e\u003e is a good reason why WIF adds a 0x01 byte for compressed pubkeys; it\n\u003e\u003e makes it unambiguous.\n\u003e\u003e\n\u003e\u003e I see only two options:\n\u003e\u003e 1. Disable private keys export in Electrum Segwit wallets, until a\n\u003e\u003e common WIF extension has been agreed on.\n\u003e\u003e 2. Define my own WIF extension for Electrum, and go ahead with it.\n\u003e\u003e\n\u003e\u003e Defining my own format does make sense for the xpub/xprv format, because\n\u003e\u003e Electrum users need to share master public keys across Electrum wallets.\n\u003e\u003e It makes much less sense for WIF, though, because WIF is mostly used to\n\u003e\u003e import/sweep keys from other wallets.\n\u003e\u003e\n\u003e\u003e I would love to know what other wallet developers are going to do,\n\u003e\u003e especially Core. Are you going to export private keys used in segwit\n\u003e\u003e scripts in the current WIF format?\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "1025fa4e6de1d4f0777bbba4a8065719108eb8cff029377b0aad921c48bfcfadf2851e50811cb4023ecdf3f68909e9f811a10208e92d7bdc463b1278df07260b"
}