术语表 /开发者参考
描述符校验和
- 描述符校验和是什么？
- 描述符校验和是输出描述符中井号之后的八个字符代码，属于 BCH 码，可在钱包导入错误密钥之前发现键入和复制错误。
规定于 BIP-380。
该代码位于描述符末尾，紧跟一个井号，使用与 bech32 相同的32字符字母表。BIP-380保证，在长度不超过49,154个字符的描述符中，任何涉及三个或更少符号的错误都会被发现，而随机错误大约每一万亿次才会漏检一次。没有这项检查，多重签名备份中只要错一个字符，您监控的就会是不含任何资金的地址。
运作方式
描述符校验和是针对描述符文本计算的 BCH 码，而不是该文本的哈希，其纠错保证正是由此而来。BIP-380规定了一个包含95个字符的输入字母表，并将其分为三组，把自身没有保护的字符放入第一组：数字、括号、斜杠、通配符星号和小写字母 a 至 h，十六进制编码的密钥和派生路径中的字符多落在这里。规范正文称之为三组各32个，但其参考代码实际为32、32和31个。
每个字符贡献一个符号，即它在所属组内的位置，每三个符号之后会插入第四个符号，其中合并了这三个字符的组编号，因此三个字符扩展为四个符号。只在组内移动字符位置，或只改变字符所在组的修改，恰好扰动一个符号。因此大小写错误恰好算作一个符号错误，单个字符误用大写也总会被发现。
随着字符串变长，保证逐级降低。一个符号错误总会被发现；两个或三个符号错误在长度不超过49,154个字符时总会被发现，四个符号错误在不超过507个字符时总会被发现，五个符号错误在不超过77个字符时总会被发现，该代码经过调优，可使长度至387个字符时未被发现的五符号错误降到最少。Bitcoin Core 的 descriptors.md 将四符号错误的界限写为501个字符而不是507个，并将残余风险定为大约一万亿分之一。该文档中的单密钥描述符长140个字符，处于所有界限之内；其2-of-3多路径示例长439个字符，超出五符号的范围，但仍在四符号的范围之内。
扩展密钥本身已有防护。BIP-380指出，xpub 超出了第一组，并带有自己的校验机制，因此密钥表达式受到双重保护。
在哪里会遇到它
观察描述符校验和如何发挥作用，BIP-380的测试向量是最简短的方式。有效字符串为 raw(deadbeef)#89f8spxm，规范拒绝的近似错误情形包括：没有校验和、只有一个井号、九个字符的校验和、七个字符的校验和、保留旧校验和不变的 raw(deedbeef)，以及使用输入字母表之外字符的载荷。
Bitcoin Core 在输出时打印校验和，在输入时要求提供校验和。每个返回描述符的 RPC 都会附上这八个字符，而只有部分 RPC 在输入时要求提供，其中包括 deriveaddresses 和 importdescriptors。对于手动键入或编辑的一行描述符，getdescriptorinfo 会返回正确的校验和。
在解析时校验和仍是可选的，BIP-380允许应用程序拒绝不带校验和的描述符。在协调器、备用设备和纸质记录之间转移多重签名配置时，请预期会遇到它：这八个字符是唯一能确认其余内容完整无误的部分。
描述符校验和 vs bech32
bech32 校验和保护的是地址，描述符校验和保护的是钱包定义，二者涉及的长度不同，这解释了设计上的差异。BIP-173将 bech32 字符串限制为90个字符，并在数据部分的最后六个字符上放置校验和，使用相同的32符号字母表。描述符没有这样的长度上限，还必须覆盖括号、逗号、引号和空格，因此 BIP-380把文本扩展为位置符号并交错插入组符号，校验和占八个字符。
两者都用同一个字母表书写结果，即 qpzry9x8gf2tvdw0s3jn54khce6mua7l，混淆正是由此开始。出错的后果则不同。校验和未通过的 bech32 地址无法用于付款；校验和未通过的描述符则是一个无法恢复的钱包。