CH04::private key formats: move-only

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. <<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