公钥和私钥的都可以有多种编码格式。一个密钥被不同的格式编码后，虽然结果看起来可能不同，但是密钥所编码数字并没有改变。这些不同的编码格式主要是用来方便人们无误地使用和识别密钥。

私钥的格式

私钥可以以许多不同的格式表示，所有这些都对应于相同的 256 位的数字。。

私钥表示法（编码格式）

种类版本描 述

Hex None64 hexadecimal digits

Base58Check encoding: Base58 with version

WIF 5

prefix of 128 and 32-bit checksum

WIF-compressedK or LAs above, with added suffix 0x01 before encoding 表 4-3 展示了用这三种格式所生成的私钥。

同样的私钥，不同的格式格式私钥

1E99423A4ED27608A15A2616A2B0E9E52CED330AC530ED

Hex

WIF

WIF-compr essed

CC32C8FFC6A526AEDD

5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB 1Jcn KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGW ZgawvrtJ

这些表示法都是用来表示相同的数字、相同的私钥的不同方法。虽然编码后的字符串看起来不同，但不同的格式彼此之间可以很容易地相互转换。

将 Base58Check 编码解码为十六进制sx工具包（参见"Libbitcoin 和 sx Tools"）可用来编写一些操作比特币密钥、地址及交易的 shell 脚本和命令行"管道"。你也可以使用 sx 工具从命令行对 Base58Check 格式进行解码。

我们使用的命令是 base58check-decode：

$sxbase58check-decode5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a 526aedd 128

所得结果是十六进制的密钥，紧接着是钱包导入格式（Wallet Import Format,WIF）的版本前缀 128。

将十六进制转换为 Base58Check 编码要转换成 Base58Check 编码（和之前的命令正好相反），我们需提供十六进制的私钥和钱包导入格式（Wallet Import Format，WIF）的版本号前缀 128：

$sx base58check-encode 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a 526aedd 128

5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn

将十六进制（压缩格式密钥）转换为 Base58Check 编码

要将压缩格式的私钥编码为 Base58Check（参见"压缩格式私钥"一节），我们需在十六进制私钥的后面添加后缀 01，然后使用跟上面一样的方法：

$ sx base58check-encode 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a 526aedd01 128 KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ

生成的 WIF 压缩格式的私钥以字母"K"开头，用以表明被编码的私钥有一个后缀"01"，且该私钥只能被用于生成压缩格式的公钥（参见"压缩格式公钥"一节）。

公钥的格式

公钥也可以用多种不同格式来表示，最重要的是它们分为非压缩格式或压缩格式公钥这两种形式。

我们从前文可知，公钥是在椭圆曲线上的一个点，由一对坐标（x，y）组成。公钥通常表示为前缀 04 紧接着两个 256 比特的数字。其中一个 256 比特 数字是公钥的 x 坐标，另一个 256 比特数字是 y 坐标。前缀 04 是用来区分非压缩格式公钥，压缩格式公钥是以 02 或者 03 开头。

下面是由前文中的私钥所生成的公钥，其坐标 x 和 y 如下：

x = F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF57 9DC341A

y = 07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2 E505BDB

下面是同样的公钥以 520 比特的数字（130 个十六进制数字）来表达。这个 520

比特的数字以前缀 04 开头，紧接着是 x 及 y 坐标，组成格式为 04 x y：

K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF

579DC341A07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328

AE52DDFE2E505BDB

压缩格式公钥

引入压缩格式公钥是为了减少比特币交易的字节数，从而可以节省那些运行区块链数据库的节点磁盘空间。大部分比特币交易包含了公钥，用于验证用户的凭据和支付比特币。每个公钥有520比特（包括前缀，x 坐标，y 坐标）。如果每个区块有数百个交易，每天有成千上万的交易发生，区块链里就会被写入大量的数据。

正如我们在"公钥"一节所见，一个公钥是一个椭圆曲线上的点(x, y)。而椭圆曲线实际是一个数学方程，曲线上的点实际是该方程的一个解。因此，如果我们知道了公钥的 x 坐标，就可以通过解方程y2mod p = (x3 + 7) mod p 得到 y 坐标。这种方案可以让我们只存储公钥的 x 坐标，略去 y 坐标，从而将公钥的大小和存储空间减少了 256 比特。每个交易所需要的字节数减少了近一半， 随着时间推移，就大大节省了很多数据传输和存储。

未压缩格式公钥使用 04 作为前缀，而压缩格式公钥是以 02 或 03 作为前缀。需要这两种不同前缀的原因是：因为椭圆曲线加密的公式的左边是 y2 ，也就是说 y 的解是来自于一个平方根，可能是正值也可能是负值。更形象地说，y 坐标可能在 x 坐标轴的上面或者下面。从图的椭圆曲线图中可以看出，曲线是对称的，从 x 轴看就像对称的镜子两面。因此，如果我们略去 y 坐标，就必须储存 y 的符号（正值或者负值）。换句话说，对于给定的 x 值，我们需要知道 y值 在 x 轴的上面还是下面，因为它们代表椭圆曲线上不同的点，即不同的公钥。当我们在素数 p 阶的有限域上使用二进制算术计算椭圆曲线的时候，y 坐标可能是奇数 或者偶数，分别对应前面所讲的 y 值的正负符号。因此，为了区分 y 坐标的两种可能值，我们在生成压缩格式公钥时，如果 y 是偶数，则使用 02 作为前缀；如果 y 是奇数，则使用 03 作为前缀。这样就可以根据公钥中给定的 x 值， 正确推导出对应的 y 坐标，从而将公钥解压缩为在椭圆曲线上的完整的点坐标。下图阐释了公钥 压缩：

下面是前述章节所生成的公钥，使用了 264 比特（66 个十六进制数字）的压缩格式公钥格式，其中前缀 03 表示 y 坐标是一个奇数：

K = 03F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF

579DC341A

这个压缩格式公钥对应着同样的一个私钥，这意味它是由同样的私钥所生成。但是压缩格式公钥和非压缩格式公钥差别很大。更 重要的是，如果我们使用双哈希函数(RIPEMD160(SHA256(K)))将压缩格式公钥转化成比特币地址，得到的地址将会不同于由非压缩格式公钥 产生的地址。这种结果会让人迷惑，因为一个私钥可以生成两种不同格式的公钥——压缩格式和非压缩格式，而这两种格式的公钥可以生成两个不同的比特币地址。 但是，这两个不同的比特币地址的私钥是一样的。

压缩格式公钥渐渐成为了各种不同的比特币客户端的默认格式，它可以大大减少交易所需的字节数，同时也让存储区块链所需的磁盘空间变小。然而，并非所有的客户端都支持压缩格式公钥，于是那些较新的支持压缩格式公钥的客户端就不得不考虑如何处理那些来自较老的不支持压缩格式公钥的客户端的交易。

这在钱包 应用导入另一个钱包应用的私钥的时候就会变得尤其重要，因为新钱包需要扫描区块链并找到所有与这些被导入私钥相关的交易。比特币钱包应该扫描哪个比特币地 址呢？新客户端不知道应该使用哪个公钥：因为不论是通过压缩的公钥产生的比特币地址，还是通过非压缩的公钥产生的地址，两个都是合法的比特币地址，都可以 被私钥正确签名，但是他们是完全不同的比特币地址。为了解决这个问题，当私钥从钱包中被导出时，较新的比特币客户端将使用一种不同的钱包导入格式（Wallet Import Format）。这种新的钱包导入格式可以用来表明该私钥已经被用来生成压缩的公钥，同时生成的比特币地址也是基于该压缩的公钥。这个方案可以解决导入私 钥来自于老钱包还是新钱包的问题，同时也解决了通过公钥生成的比特币地址是来自于压缩格式公钥还是非压缩格式公钥的问题。最后新钱包在扫描区块链时，就可 以使用对应的比特币地址去查找该比特币地址在区块链里所发生的交易。我们将在下一节详细解释这种机制是如何工作的。

压缩格式私钥

实际上"压缩格式私钥"是一种名称上的误导，因为当一个私钥被使用 WIF 压缩格式导出时，不但没有压缩，而且比"非压缩格式"私钥长出一个字节。这 个多出来的一个字节是私钥被加了后缀 01，用以表明该私钥是来自于一个较新的钱包，只能被用来生成压缩的公钥。私钥是非压缩的，也不能被压缩。"压缩的私 钥"实际上只是表示"用于生成压缩格式公钥的私钥"，而"非压缩格式私钥"用来表明"用于生成非压缩格式公钥的私钥"。为避免更多误解，应该只可以说导出 格式是"WIF 压缩格式"或者"WIF"，而不能说这个私钥是"压缩"的。

要注意的是，这些格式并不是可互换使用的。在较新的实现了压缩格式公钥的钱包中，私钥只能且永远被导出为 WIF 压缩格式（以 K 或 L 为前缀）。对于较老的没有实现压缩格式公钥的钱包，私钥将只能被导出为 WIF 格式（以 5 为前缀）导出。这样做的目的就是为了给导入这些私钥的钱包一个信号：到底是使用压缩 格式公钥和比特币地址去扫描区块链，还是使用非压缩格式公钥和比特币地址。

如果一个比特币钱包实现了压缩格式公钥，那么它将会在所有交易中使用该压格式缩公钥。钱包中的私钥将会被用来生成压缩格式公钥，压缩格式公钥然后被 用来生成交易中的比特币地址。当从一个实现了压缩格式公钥的比特币钱包导出私钥时，钱包导入格式（WIF）将会被修改为 WIF 压缩格式，该格式将会在私钥 的后面附加一个字节大小的后缀 01。最终的 Base58Check 编码格式的私钥被称作 WIF（"压缩"）私钥，以字母"K"或"L"开头。而以"5"开 头的是从较老的钱包中以 WIF（非压缩）格式导出的私钥。

Hex WIF

1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDC C32C8FFC6A526AEDD

5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1 Jcn

格式 私钥

Hex-compr 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDC

essed C32C8FFC6A526AEDD01

WIF-compr KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGW

essed ZgawvrtJ

"压缩格式私钥"是一个不当用词！私钥不是压缩的。WIF 压缩格式的私钥只是用来表明他们只能被生成压缩的公钥和对应的比特币地址。相反地，"WIF 压 缩"编码的私钥还多出一个字节，因为这种私钥多了后缀"01"。该后缀是用来区分"非压缩格式"私钥和"压缩格式"私钥。