From bdf31e90afea8209ea596d92d9c1c4681e473533 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 7 Feb 2023 14:49:59 -1000 Subject: [PATCH] CH04::private key formats: move-only --- ch04.asciidoc | 118 ++++++++++++++++++++++++++------------------------ 1 file changed, 61 insertions(+), 57 deletions(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 616969ef..1fef6ee5 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -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. <> 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 -|======= - -<> 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 <> 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 <>) -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. <> 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 +|======= + +<> 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 <> 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 <>) +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