Bitcoin Wiki - User contributions [en]

Wallet import format

2021-10-28T22:04:42Z

Pseudo geek: Add "References" subtitle

{{sample}}
A '''wallet import format''' ('''WIF''', also known as a '''wallet export format''') is a way of encoding a private ECDSA key so as to make it easier to copy.

A testing suite is available for encoding and decoding of WIF at:

http://gobittest.appspot.com/PrivateKey

==Private key to WIF==
1. Take a private key.
0C28FCA386C7A227600B2FE50B7CAE{{taggant private key}}11EC86D3BF1FBE471BE89827E19D72AA1D
2. Add a <code>0x80</code> byte in front of it for mainnet addresses or <code>0xef</code> for testnet addresses. Also add a <code>0x01</code> byte at the end if the private key will correspond to a compressed public key.
800C28FCA386C7A227600B2FE50B7C{{taggant private key}}AE11EC86D3BF1FBE471BE89827E19D72AA1D
3. Perform SHA-256 hash on the extended key.
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4. Perform SHA-256 hash on result of SHA-256 hash.
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5. Take the first 4 bytes of the second SHA-256 hash; this is the checksum.
507A5B8D
6. Add the 4 checksum bytes from point 5 at the end of the extended key from point 2.
800C28FCA386C7A227600B2FE50B7CAE11EC8{{taggant private key}}6D3BF1FBE471BE89827E19D72AA1D507A5B8D
7. Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the wallet import format (WIF).
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

==WIF to private key==
1. Take a wallet import format (WIF) string.
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2. Convert it to a byte string using [[Base58Check encoding]].
800C28FCA386C7A227600B2FE50B7CAE11EC{{taggant private key}}86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3. Drop the last 4 checksum bytes from the byte string.
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
4. Drop the first byte (it should be <code>0x80</code>, however legacy Electrum<ref name="electrum-300-wif">[https://github.com/spesmilo/electrum/blob/3.0.0/RELEASE-NOTES#L42]</ref><ref name="electrum-310-wif">[https://github.com/spesmilo/electrum/blob/3.1.0/RELEASE-NOTES#L58]</ref> or some SegWit vanity address generators<ref name="segvan-wif">[https://github.com/nym-zone/segvan/blob/388b157c68c3b45f7c3200cc62a2fea6ffcb5555/segvan.c#L88]</ref> may use <code>0x81-0x87</code>). If the private key corresponded to a compressed public key, also drop the last byte (it should be <code>0x01</code>). If it corresponded to a compressed public key, the WIF string will have started with K or L (or M, if it's exported from legacy Electrum<ref name="electrum-300-wif" /><ref name="electrum-310-wif" /> etc<ref name="segvan-wif" />) instead of 5 (or c instead of 9 on testnet). This is the private key.
0C28FCA386C7A227600B2FE50B7CAE1{{taggant private key}}1EC86D3BF1FBE471BE89827E19D72AA1D

==WIF checksum checking==
1. Take the wallet import format (WIF) string.
5HueCGU8rMjxEXxiPuD5BD{{taggant private key}}ku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2. Convert it to a byte string using [[Base58Check encoding]].
800C28FCA386C7A227600B2FE50B7CAE11E{{taggant private key}}C86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3. Drop the last 4 checksum bytes from the byte string.
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
4. Perform SHA-256 hash on the shortened string.
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
5. Perform SHA-256 hash on result of SHA-256 hash.
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
6. Take the first 4 bytes of the second SHA-256 hash; this is the checksum.
507A5B8D
7. Make sure it is the same as the last 4 bytes from point 2.
507A5B8D
8. If they are, and the byte string from point 2 starts with <code>0x80</code> (<code>0xef</code> for testnet addresses), then there is no error.

== References ==
<references />

{{Stub}}
{{Bitcoin Core documentation}}

Base58Check encoding

2021-10-28T22:03:36Z

Pseudo geek: Add "References" subtitle

A modified Base 58 [http://en.wikipedia.org/wiki/Binary-to-text_encoding binary-to-text encoding] known as '''Base58Check''' is used for encoding [[Bitcoin address|Bitcoin addresses]].

More generically, Base58Check encoding is used for encoding byte arrays in Bitcoin into human-typable strings.

==Background==
The original Bitcoin client source code explains the reasoning behind base58 encoding:

base58.h:
// Why base-58 instead of standard base-64 encoding?
// - Don't want 0OIl characters that look the same in some fonts and
// could be used to create visually identical looking account numbers.
// - A string with non-alphanumeric characters is not as easily accepted as an account number.
// - E-mail usually won't line-break if there's no punctuation to break at.
// - Doubleclicking selects the whole number as one word if it's all alphanumeric.

==Features of Base58Check==
Base58Check has the following features:
* An arbitrarily sized payload.
* A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)
* One byte of version/application information. Bitcoin addresses use 0x00 for this byte (future ones may use 0x05).
* Four bytes (32 bits) of SHA256-based error checking code. This code can be used to automatically detect and possibly correct typographical errors.
* An extra step for preservation of leading zeroes in the data.

==Creating a Base58Check string==
A Base58Check string is created from a version/application byte and payload as follows.
# Take the version byte and payload bytes, and concatenate them together (bytewise).
# Take the first four bytes of SHA256(SHA256(results of step 1))
# Concatenate the results of step 1 and the results of step 2 together (bytewise).
# Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character '1').
# The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero '''byte''', as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.
# Concatenate the 1's from step 5 with the results of step 4. '''This is the Base58Check result.'''
A more detailed example is provided on the page describing the [[Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address | technical background]] of the bitcoin address.

==Encoding a Bitcoin address==
Bitcoin addresses are implemented using the Base58Check encoding of the hash of either:
* Pay-to-script-hash (p2sh): payload is: <code>[[RIPEMD160]]([[SHA256]]('''redeemScript'''))</code> where '''redeemScript''' is a script the wallet knows how to spend; version <code>0x05</code> (these addresses begin with the digit '3')
* Pay-to-pubkey-hash (p2pkh): payload is <code>[[RIPEMD160]]([[SHA256]]('''ECDSA_publicKey'''))</code> where '''ECDSA_publicKey''' is a public key the wallet knows the private key for; version <code>0x00</code> (these addresses begin with the digit '1')

The resulting hash in both of these cases is always exactly 20 bytes.
These are big-endian (most significant byte first). (Beware of [[bignumber]] implementations that clip leading 0x00 bytes, or prepend extra 0x00 bytes to indicate sign - your code must handle these cases properly or else you may generate valid-looking addresses which can be sent to, but cannot be spent from - which would lead to the permanent loss of coins.)

==Encoding a private key==
Base58Check encoding is also used for encoding [[private key|ECDSA private keys]] in the [[wallet import format]].
This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer).
For private keys associated with an uncompressed public key, such encodings will always yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'.

==Base58 symbol chart==
The Base58 symbol chart used in Bitcoin is specific to the Bitcoin project and is not intended to be the same as any other Base58 implementation used outside the context of Bitcoin (the characters excluded are: 0, O, I, and l).
{| class="wikitable"
|-
!Value
!Character
!Value
!Character
!Value
!Character
!Value
!Character
|-
|0
|1
|1
|2
|2
|3
|3
|4
|-
|4
|5
|5
|6
|6
|7
|7
|8
|-
|8
|9
|9
|A
|10
|B
|11
|C
|-
|12
|D
|13
|E
|14
|F
|15
|G
|-
|16
|H
|17
|J
|18
|K
|19
|L
|-
|20
|M
|21
|N
|22
|P
|23
|Q
|-
|24
|R
|25
|S
|26
|T
|27
|U
|-
|28
|V
|29
|W
|30
|X
|31
|Y
|-
|32
|Z
|33
|a
|34
|b
|35
|c
|-
|36
|d
|37
|e
|38
|f
|39
|g
|-
|40
|h
|41
|i
|42
|j
|43
|k
|-
|44
|m
|45
|n
|46
|o
|47
|p
|-
|48
|q
|49
|r
|50
|s
|51
|t
|-
|52
|u
|53
|v
|54
|w
|55
|x
|-
|56
|y
|57
|z
|}

The algorithm for encoding address_byte_string (consisting of 1-byte_version + hash_or_other_data + 4-byte_check_code) is

code_string = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
x = convert_bytes_to_big_integer(hash_result)

output_string = ""

while(x > 0)
{
(x, remainder) = divide(x, 58)
output_string.append(code_string[remainder])
}

repeat(number_of_leading_zero_bytes_in_hash)
{
output_string.append(code_string[0]);
}

output_string.reverse();

==Version bytes==
Here are some common version bytes:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
|-
|0
|1
|Bitcoin pubkey hash
|-
|5
|3
|Bitcoin script hash
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|-
|52
|M or N
|Namecoin pubkey hash
|-
|128
|5
|Private key (uncompressed pubkey)
|-
|128
|K or L
|Private key (compressed pubkey)
|-
|129-135
|5, K, L, or M
|Private key (Electrum-defined<ref name="electrum-300-wif">[https://github.com/spesmilo/electrum/blob/3.0.0/RELEASE-NOTES#L42]</ref> and now deprecated<ref name="electrum-310-wif">[https://github.com/spesmilo/electrum/blob/3.1.0/RELEASE-NOTES#L58]</ref>)
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|-
|196
|2
|Bitcoin testnet script hash
|}
[[List of address prefixes]] is a more complete list.

== See Also ==
* [http://lenschulwitz.com/base58 Online Base58 Decoder, Encoder, and Validator]

== Source code ==
* [https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp "Satoshi" C++ codebase (decode and encode, no external libraries needed)]
* [https://github.com/luke-jr/libbase58 libbase58 C code (decode and encode, no external libraries needed)]
* [http://lenschulwitz.com/b58/base58perl.txt Base58 Decode, Encode, and Validate in Perl]

== References ==
<references />

[[Category:Technical]]

[[es:Codificación Base58Check]]

Base58Check encoding

2021-10-28T22:00:29Z

Pseudo geek: Add electrum-defined and deprecated WIF version numbers; distinguish between compressed and uncompressed pubkey

A modified Base 58 [http://en.wikipedia.org/wiki/Binary-to-text_encoding binary-to-text encoding] known as '''Base58Check''' is used for encoding [[Bitcoin address|Bitcoin addresses]].

More generically, Base58Check encoding is used for encoding byte arrays in Bitcoin into human-typable strings.

==Background==
The original Bitcoin client source code explains the reasoning behind base58 encoding:

base58.h:
// Why base-58 instead of standard base-64 encoding?
// - Don't want 0OIl characters that look the same in some fonts and
// could be used to create visually identical looking account numbers.
// - A string with non-alphanumeric characters is not as easily accepted as an account number.
// - E-mail usually won't line-break if there's no punctuation to break at.
// - Doubleclicking selects the whole number as one word if it's all alphanumeric.

==Features of Base58Check==
Base58Check has the following features:
* An arbitrarily sized payload.
* A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)
* One byte of version/application information. Bitcoin addresses use 0x00 for this byte (future ones may use 0x05).
* Four bytes (32 bits) of SHA256-based error checking code. This code can be used to automatically detect and possibly correct typographical errors.
* An extra step for preservation of leading zeroes in the data.

==Creating a Base58Check string==
A Base58Check string is created from a version/application byte and payload as follows.
# Take the version byte and payload bytes, and concatenate them together (bytewise).
# Take the first four bytes of SHA256(SHA256(results of step 1))
# Concatenate the results of step 1 and the results of step 2 together (bytewise).
# Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character '1').
# The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero '''byte''', as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.
# Concatenate the 1's from step 5 with the results of step 4. '''This is the Base58Check result.'''
A more detailed example is provided on the page describing the [[Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address | technical background]] of the bitcoin address.

==Encoding a Bitcoin address==
Bitcoin addresses are implemented using the Base58Check encoding of the hash of either:
* Pay-to-script-hash (p2sh): payload is: <code>[[RIPEMD160]]([[SHA256]]('''redeemScript'''))</code> where '''redeemScript''' is a script the wallet knows how to spend; version <code>0x05</code> (these addresses begin with the digit '3')
* Pay-to-pubkey-hash (p2pkh): payload is <code>[[RIPEMD160]]([[SHA256]]('''ECDSA_publicKey'''))</code> where '''ECDSA_publicKey''' is a public key the wallet knows the private key for; version <code>0x00</code> (these addresses begin with the digit '1')

The resulting hash in both of these cases is always exactly 20 bytes.
These are big-endian (most significant byte first). (Beware of [[bignumber]] implementations that clip leading 0x00 bytes, or prepend extra 0x00 bytes to indicate sign - your code must handle these cases properly or else you may generate valid-looking addresses which can be sent to, but cannot be spent from - which would lead to the permanent loss of coins.)

==Encoding a private key==
Base58Check encoding is also used for encoding [[private key|ECDSA private keys]] in the [[wallet import format]].
This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer).
For private keys associated with an uncompressed public key, such encodings will always yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'.

==Base58 symbol chart==
The Base58 symbol chart used in Bitcoin is specific to the Bitcoin project and is not intended to be the same as any other Base58 implementation used outside the context of Bitcoin (the characters excluded are: 0, O, I, and l).
{| class="wikitable"
|-
!Value
!Character
!Value
!Character
!Value
!Character
!Value
!Character
|-
|0
|1
|1
|2
|2
|3
|3
|4
|-
|4
|5
|5
|6
|6
|7
|7
|8
|-
|8
|9
|9
|A
|10
|B
|11
|C
|-
|12
|D
|13
|E
|14
|F
|15
|G
|-
|16
|H
|17
|J
|18
|K
|19
|L
|-
|20
|M
|21
|N
|22
|P
|23
|Q
|-
|24
|R
|25
|S
|26
|T
|27
|U
|-
|28
|V
|29
|W
|30
|X
|31
|Y
|-
|32
|Z
|33
|a
|34
|b
|35
|c
|-
|36
|d
|37
|e
|38
|f
|39
|g
|-
|40
|h
|41
|i
|42
|j
|43
|k
|-
|44
|m
|45
|n
|46
|o
|47
|p
|-
|48
|q
|49
|r
|50
|s
|51
|t
|-
|52
|u
|53
|v
|54
|w
|55
|x
|-
|56
|y
|57
|z
|}

The algorithm for encoding address_byte_string (consisting of 1-byte_version + hash_or_other_data + 4-byte_check_code) is

code_string = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
x = convert_bytes_to_big_integer(hash_result)

output_string = ""

while(x > 0)
{
(x, remainder) = divide(x, 58)
output_string.append(code_string[remainder])
}

repeat(number_of_leading_zero_bytes_in_hash)
{
output_string.append(code_string[0]);
}

output_string.reverse();

==Version bytes==
Here are some common version bytes:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
|-
|0
|1
|Bitcoin pubkey hash
|-
|5
|3
|Bitcoin script hash
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|-
|52
|M or N
|Namecoin pubkey hash
|-
|128
|5
|Private key (uncompressed pubkey)
|-
|128
|K or L
|Private key (compressed pubkey)
|-
|129-135
|5, K, L, or M
|Private key (Electrum-defined<ref name="electrum-300-wif">[https://github.com/spesmilo/electrum/blob/3.0.0/RELEASE-NOTES#L42]</ref> and now deprecated<ref name="electrum-310-wif">[https://github.com/spesmilo/electrum/blob/3.1.0/RELEASE-NOTES#L58]</ref>)
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|-
|196
|2
|Bitcoin testnet script hash
|}
[[List of address prefixes]] is a more complete list.

== See Also ==
* [http://lenschulwitz.com/base58 Online Base58 Decoder, Encoder, and Validator]

== Source code ==
* [https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp "Satoshi" C++ codebase (decode and encode, no external libraries needed)]
* [https://github.com/luke-jr/libbase58 libbase58 C code (decode and encode, no external libraries needed)]
* [http://lenschulwitz.com/b58/base58perl.txt Base58 Decode, Encode, and Validate in Perl]

[[Category:Technical]]

[[es:Codificación Base58Check]]

Wallet import format

2021-10-28T21:53:03Z

Pseudo geek: Remind about electrum-defined and deprecated WIF version numbers

List of address prefixes

2021-10-28T21:35:30Z

Pseudo geek: Add electrum-defined and deprecated WIF version numbers; mark "WIF" text as link

Blockchain-based currencies use encoded strings, which are in a [[Base58Check encoding]] with the exception of [[Bech32]] encodings. The encoding includes a prefix (traditionally a single ''version byte''), which affects the leading symbol(s) in the encoded result. The following is a list of some prefixes which are in use in the reference Bitcoin codebase.<ref>https://github.com/bitcoin/bitcoin/blob/0.14/src/chainparams.cpp#L129-L131</ref><ref>https://github.com/bitcoin/bitcoin/blob/0.14/src/chainparams.cpp#L229-L231</ref><ref>https://github.com/bitcoin/bitcoin/blob/0.14/src/chainparams.cpp#L325-L327</ref>

{| class="wikitable"
|-
!Decimal prefix
!Hex
!Example use
!Leading symbol(s)
!Example
|-
|0
|00
|Pubkey hash ([[Transaction#Pay-to-PubkeyHash|P2PKH address]])
|1
|<tt>17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem</tt>
|-
|5
|05
|Script hash ([[Pay to script hash|P2SH address]])
|3
| <tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|128
|80
|Private key ([[Wallet import format|WIF]], uncompressed pubkey)
|5
|<tt>5Hwgr3u458GLafKBgxtssHSPqJnYoGrSzgQsPwLFhLNYskDPyyA</tt>
|-
|133
|80
|Private key ([[Wallet import format|WIF]], uncompressed pubkey, Electrum-defined<ref name="electrum-300-wif">[https://github.com/spesmilo/electrum/blob/3.0.0/RELEASE-NOTES#L42]</ref> and now deprecated<ref name="electrum-310-wif">[https://github.com/spesmilo/electrum/blob/3.1.0/RELEASE-NOTES#L58]</ref>)
|5
|<tt>5TfQjD9DLFeUFmDiDrzsdtSGQss93o4pvsmQcgmjfcQVLsEgAoM</tt>
|-
|128
|80
|Private key ([[Wallet import format|WIF]], compressed pubkey)
|K ''or'' L
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|129-134
|80
|Private key ([[Wallet import format|WIF]], compressed pubkey, Electrum-defined<ref name="electrum-300-wif" /> and now deprecated<ref name="electrum-310-wif" />)
|L
|<tt>LkUevPi661korFvRdQQUkEX35rA484oAwzsT93383q6mUqVe5cw2</tt>
|-
|135
|80
|Private key ([[Wallet import format|WIF]], compressed pubkey, Electrum-defined<ref name="electrum-300-wif" /> and now deprecated<ref name="electrum-310-wif" />)
|L ''or'' M
|<tt>M3dv4iRtSKb5oHwxjZCGLai1aiZMnuLdGt7iFwjK2ncC3Vu7tRwP</tt>
|-
|4 136 178 30
|0488B21E
|[[BIP 0032|BIP32]] pubkey
|xpub
|<tt>xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3
zgtU6LBpB85b3D2yc8sfvZU521AAwdZafEz7mnzBBsz4wKY5e4cp9LB</tt>
|-
|4 136 173 228
|0488ADE4
|BIP32 private key
|xprv
|<tt>xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63o
StZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21Teqt1VvEHx</tt>
|-
|111
|6F
|Testnet pubkey hash
|m ''or'' n
|<tt>mipcBbFg9gMiCh81Kj8tqqdgoZub1ZJRfn</tt>
|-
|196
|C4
|Testnet script hash
|2
|<tt>2MzQwSSnBHWHqSAqtTVQ6v47XtaisrJa1Vc</tt>
|-
|239
|EF
|Testnet Private key ([[Wallet import format|WIF]], uncompressed pubkey)
|9
|<tt>92Pg46rUhgTT7romnV7iGW6W1gbGdeezqdbJCzShkCsYNzyyNcc</tt>
|-
|239
|EF
|Testnet Private key ([[Wallet import format|WIF]], compressed pubkey)
|c
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|-
|4 53 135 207
|043587CF
|Testnet BIP32 pubkey
|tpub
|<tt>tpubD6NzVbkrYhZ4WLczPJWReQycCJdd6YVWXubbVUFnJ5KgU5MDQrD9
98ZJLNGbhd2pq7ZtDiPYTfJ7iBenLVQpYgSQqPjUsQeJXH8VQ8xA67D</tt>
|-
|4 53 131 148
|04358394
|Testnet BIP32 private key
|tprv
|<tt>tprv8ZgxMBicQKsPcsbCVeqqF1KVdH7gwDJbxbzpCxDUsoXHdb6SnTPY
xdwSAKDC6KKJzv7khnNWRAJQsRA8BBQyiSfYnRt6zuu4vZQGKjeW4YF</tt>
|-
|
|
|Bech32 pubkey hash or script hash
|bc1
|<tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4</tt>
|-
|
|
|Bech32 testnet pubkey hash or script hash
|tb1
|<tt>tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx</tt>
|}

Note that private keys for compressed and uncompressed bitcoin public keys use the same version byte. The reason for the compressed form starting with a different character is because a 0x01 byte is appended to the private key before base58 encoding.

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

== References ==
<references />

{{Bitcoin Core documentation}}