arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-12-23 07:08:13 +00:00
Code Issues Releases Wiki Activity

CH04::private key formats: move-only

Browse Source
This commit is contained in:
David A. Harding 2023-02-07 14:49:59 -10:00
parent 1ddec1538e
commit bdf31e90af
1 changed files with 61 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

118
ch04.asciidoc
View File

@ -779,63 +779,6 @@ version prefixes and the resulting Base58 characters are shown in
==== Key Formats
((("keys and addresses", "Bitcoin addresses", "key formats")))Both
private and public keys can be represented in a number of different
formats. These representations all encode the same number, even though
they look different. These formats are primarily used to make it easy
for people to read and transcribe keys without introducing errors.
[[priv_formats]]
===== Private key formats
((("public and private keys", "private key formats")))The private key
can be represented in a number of different formats, all of which
correspond to the same 256-bit number. <<table_4-2>> shows three common
formats used to represent private keys. Different formats are used in
different circumstances. Hexadecimal and raw binary formats are used
internally in software and rarely shown to users. The WIF is used for
import/export of keys between wallets and often used in QR code
(barcode) representations of private keys.
[[table_4-2]]
.Private key representations (encoding formats)
[options="header"]
|=======
|Type|Prefix|Description
| Raw | None | 32 bytes
| Hex | None | 64 hexadecimal digits
| WIF | 5 | Base58Check encoding: Base58 with version prefix of 128- and 32-bit checksum
| WIF-compressed | K or L | As above, with added suffix 0x01 before encoding
|=======
<<table_4-3>> shows the private key generated in these three formats.
[[table_4-3]]
.Example: Same key, different formats
[options="header"]
|=======
|Format | Private key
| Hex | 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
|=======
All of these representations are different ways of showing the same
number, the same private key. They look different, but any one format
can easily be converted to any other format. Note that the "raw binary"
is not shown in <<table_4-3>> as any encoding for display here would, by
definition, not be raw binary data.
We use the +wif-to-ec+ command from Bitcoin Explorer (see <<appdx_bx>>)
to show that both WIF keys represent the same private key:
----
$ bx wif-to-ec 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
$ bx wif-to-ec KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
----
[[pubkey_to_address]]
.Public key to Bitcoin address: conversion of a public key into a Bitcoin address
image::images/mbc2_0405.png["pubkey_to_address"]
@ -983,6 +926,67 @@ represent them is implemented slightly differently in newer Bitcoin
wallets, to indicate that these private keys have been used to produce
compressed public keys.
==== Key Formats
((("keys and addresses", "Bitcoin addresses", "key formats")))Both
private and public keys can be represented in a number of different
formats. These representations all encode the same number, even though
they look different. These formats are primarily used to make it easy
for people to read and transcribe keys without introducing errors.
[[priv_formats]]
===== Private key formats
((("public and private keys", "private key formats")))The private key
can be represented in a number of different formats, all of which
correspond to the same 256-bit number. <<table_4-2>> shows three common
formats used to represent private keys. Different formats are used in
different circumstances. Hexadecimal and raw binary formats are used
internally in software and rarely shown to users. The WIF is used for
import/export of keys between wallets and often used in QR code
(barcode) representations of private keys.
[[table_4-2]]
.Private key representations (encoding formats)
[options="header"]
|=======
|Type|Prefix|Description
| Raw | None | 32 bytes
| Hex | None | 64 hexadecimal digits
| WIF | 5 | Base58Check encoding: Base58 with version prefix of 128- and 32-bit checksum
| WIF-compressed | K or L | As above, with added suffix 0x01 before encoding
|=======
<<table_4-3>> shows the private key generated in these three formats.
[[table_4-3]]
.Example: Same key, different formats
[options="header"]
|=======
|Format | Private key
| Hex | 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
|=======
All of these representations are different ways of showing the same
number, the same private key. They look different, but any one format
can easily be converted to any other format. Note that the "raw binary"
is not shown in <<table_4-3>> as any encoding for display here would, by
definition, not be raw binary data.
We use the +wif-to-ec+ command from Bitcoin Explorer (see <<appdx_bx>>)
to show that both WIF keys represent the same private key:
----
$ bx wif-to-ec 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
$ bx wif-to-ec KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
----
[[comp_priv]]
===== Compressed private keys