Skip to content

Commit 6255dc5

Browse files
authored
Merge pull request bitcoin#673 from kallewoof/bip-typed-wif
BIP 178: Version Extended WIF
2 parents 562a604 + f667e7a commit 6255dc5

File tree

2 files changed

+82
-0
lines changed

2 files changed

+82
-0
lines changed

README.mediawiki

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -792,6 +792,13 @@ Those proposing changes should consider that ultimately consent may rest with th
792792
| Informational
793793
| Draft
794794
|-
795+
| [[bip-0178.mediawiki|178]]
796+
| Applications
797+
| Version Extended WIF
798+
| Karl-Johan Alm
799+
| Standard
800+
| Draft
801+
|-
795802
| [[bip-0180.mediawiki|180]]
796803
| Peer Services
797804
| Block size/weight fraud proof

bip-0178.mediawiki

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
<pre>
2+
BIP: 178
3+
Layer: Applications
4+
Title: Version Extended WIF
5+
Author: Karl-Johan Alm <[email protected]>
6+
Comments-Summary: No comments yet.
7+
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0178
8+
Status: Draft
9+
Type: Standards Track
10+
Created: 2018-04-04
11+
License: CC0-1.0
12+
</pre>
13+
14+
== Abstract ==
15+
16+
An extension to the Wallet Import Format (WIF) to specify what kind of public key the private key corresponds to.
17+
18+
== Motivation ==
19+
20+
There are several types of bitcoin addresses 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.
21+
22+
While private keys have a 1-byte suffix indicating whether the corresponding public key is compressed (<code>0x01</code>) or not (through suffix absence), there is no way of knowing what kind of bitcoin address 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.
23+
24+
By extending the suffix, we can specify what kind of bitcoin address was associated with a given private key.
25+
26+
== Specification ==
27+
28+
Currently, private keys are stored as a uint256 (private key data) followed by an optional uint8 (compressed flag). The latter is extended to specify the address types:
29+
30+
{|class="wikitable" style="text-align: center;"
31+
|-
32+
!Value
33+
!Type
34+
!Compr
35+
!Clarification
36+
|-
37+
|No suffix||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public key. Unknown public key format
38+
|-
39+
|<code>0x01</code>||P2PKH_COMPRESSED||Yes||Compressed legacy public key. Unknown public key format
40+
|-
41+
|<code>0x10</code>||P2PKH||Yes||Compressed legacy public key. Legacy public key format (<code>1...</code>)
42+
|-
43+
|<code>0x11</code>||P2WPKH||Yes||Bech32 format (native Segwit)
44+
|-
45+
|<code>0x12</code>||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH (<code>3...</code>)
46+
|}
47+
48+
When a wallet imports a private key, it will have two outcomes:
49+
50+
* the key is using one of the legacy types, in which case all types must be accounted for
51+
* the key is using one of the extended types, in which case the wallet need only track the specific corresponding address
52+
53+
Note: the difference between `0x01` and `0x10` is that the former can correspond to any of the types above, whereas the latter *only* corresponds to a P2PKH (legacy non-segwit).
54+
55+
== Compatibility ==
56+
57+
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 (no suffix) and changing 'compressed' to be 'anything not 0', as opposed to 'the value 1'.
58+
59+
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 bitcoin address is possible, and will have to track all of them, as it has to today.
60+
61+
== Acknowledgements ==
62+
63+
This BIP is based on the initial proposal by Thomas Voegtlin (thomasv at electrum dot 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>
64+
65+
== Reference implementation ==
66+
67+
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
68+
69+
== References ==
70+
71+
<references/>
72+
73+
== Copyright ==
74+
75+
This document is licensed under the Creative Commons CC0 1.0 Universal license.

0 commit comments

Comments
 (0)