备份密钥派生路径

在BIP32密钥树中，大约有40亿个一级密钥；每个这些密钥都可以有自己的40亿个子级，而每个子级又可以有自己的40亿个子级，依此类推。钱包应用程序不可能生成BIP32树中的所有可能密钥的一小部分，这意味着从数据丢失中恢复需要知道的不仅仅是恢复码、获取种子的算法（例如，BIP39）和确定性密钥派生算法（例如，BIP32） - 还需要知道您的钱包应用程序用于生成其分发的特定密钥的密钥树中的路径。

已经采用了两种解决方案来解决这个问题。第一种是使用标准路径。每当与钱包应用程序可能想要生成的地址相关的变化发生时，某人都会创建一个BIP，定义要使用的密钥派生路径。例如，BIP44定义了m/44'/0'/0'作为用于P2PKH脚本（传统地址）中的密钥的路径。实现此标准的钱包应用程序在首次启动时和从恢复码进行恢复后都使用该路径中的密钥。我们称这种解决方案为隐式路径。由BIP定义的几个流行的隐式路径如表5-2所示。

表5-2. 由各种BIP定义的隐式脚本路径

标准	脚本	BIP32路径
BIP44	P2PKH	m/44'/0'/0'
BIP49	Nested P2WPKH	m/49'/1'/0'
BIP84	P2WPKH	m/84'/0'/0'
BIP86	P2TR Single-key	m/86'/0'/0'

第二种解决方案是将路径信息与恢复码一起备份，明确指出哪些路径与哪些脚本一起使用。我们称之为显式路径。

隐式路径的优点在于用户无需记录他们使用的路径。如果用户将恢复码输入到他们之前使用的相同版本或更高版本的钱包应用程序中，它将自动为之前使用的相同路径重新生成密钥。

隐式脚本的缺点在于其不灵活性。当输入恢复码时，钱包应用程序必须为其支持的每个路径生成密钥，并且必须扫描区块链以查找涉及这些密钥的交易，否则可能找不到所有用户的交易。对于支持许多具有各自路径的功能的钱包来说，这种做法是浪费的，如果用户只尝试了其中的一些功能。

对于不包含版本号的隐式路径恢复码，如BIP39和SLIP39，新版本的钱包应用程序如果不再支持旧路径，在恢复过程中无法警告用户可能无法找到部分资金。反过来，如果用户将恢复码输入到旧软件中，则无法找到用户可能已经收到资金的新路径。包含版本信息的恢复码，如Electrum v2和Aezeed，可以检测到用户输入的是旧版本还是新版本的恢复码，并引导用户到相应的资源。

隐式路径的最终结果是它们只能包含通用的信息（例如标准化路径）或从种子派生的信息（例如密钥）。某些用户特定的重要非确定性信息无法使用恢复码进行恢复。例如，Alice、Bob和Carol收到的资金只能通过其中两个人的签名来花费。尽管Alice只需要Bob或Carol的签名来花费，但她需要他们两个人的公钥才能在区块链上找到他们的共同资金。这意味着他们每个人都必须备份所有三个人的公钥。随着多重签名和其他高级脚本在比特币上变得更加普遍，隐式路径的不灵活性变得更加重要。

显式路径的优点在于它们可以准确描述应该与何种脚本一起使用的密钥。无需支持过时的脚本，也不会出现向后或向前兼容性的问题，而且任何额外的信息（例如其他用户的公钥）都可以直接包含在内。它们的缺点是它们需要用户将额外信息与恢复码一起备份。这些额外的信息通常不会危及用户的安全性，因此不需要像恢复码那样多的保护，尽管它可能会减少用户的隐私，并且需要一些保护。

几乎所有截至目前为止使用显式路径的钱包应用程序都使用了输出脚本描述符标准（简称描述符），该标准在BIP380、BIP381、BIP382、BIP383、BIP384、BIP385、BIP386和BIP389中指定。描述符描述了一个脚本以及与之一起使用的密钥（或密钥路径）。Bitcoin Core文档中的一些示例描述符如下所示（省略部分）：

Table 5-3. Bitcoin Core文档中的示例描述符（部分省略）

描述符	解释
pkh(02c6…9ee5)	提供的公钥的P2PKH（支付至公钥哈希）脚本
sh(multi(2,022f… 2a01,03ac…ccbe))	需要两个签名与这两个密钥相对应的P2SH（支付至脚本哈希）多重签名
pkh([d34db33f/44'/0'/ 0']xpub6ERA…RcEL/1/*)	BIP32 d34db33f的扩展公钥（xpub）在路径M/44'/0'/0'上的P2PKH脚本，使用该xpub的M/1/*路径上的密钥

长期以来，专为单签名脚本设计的钱包应用程序倾向于使用隐式路径。而为多重签名或其他高级脚本设计的钱包应用程序则越来越多地采用支持描述符的显式路径。同时支持两种方式的应用程序通常会遵循隐式路径的标准，并提供描述符。