术语表 /地址与密钥
强化派生
又称 Hardened derivation、硬化派生。
- 强化派生是什么？
- 强化派生会把父私钥输入每一次子密钥的计算，因此即使扩展公钥泄露，也无法据此推出其下的整个分支。
规定于 BIP-32。
BIP-32树中的每个节点都可以生成4,294,967,296个子节点，而这一范围的上半部分行为不同。从2,147,483,648起的索引属于强化索引，用撇号或字母 h 表示，任何公钥都无法派生它们。这一限制正是其设计目的，而不是缺陷。
运作方式
强化派生与普通派生的区别，只在于同一个哈希的一项输入。两者都把父密钥的链码和子索引输入 HMAC-SHA512。普通派生加入的是父公钥，而任何持有扩展公钥的人本来就拥有它。强化派生加入的则是父私钥，并在前面加一个零字节，因此没有这个秘密就无法完成计算。
原因在于 BIP-32在其安全说明中指出的一个具体弱点：知道父扩展公钥，再加上由它派生的任何一个非强化私钥，就等同于知道父扩展私钥，也就等于知道该节点以下的所有密钥。其中的算术并不复杂。普通子私钥等于父私钥加上一个由公开信息算出的值，所以减去这个值就能还原出父私钥。
强化索引堵住了这条路径。它们没有公开的派生函数，因此扩展公钥在这一边界就此止步。某个账户的 xpub 泄露，只会暴露该账户的历史记录，不会暴露其上层或同级的任何内容。
在哪里会遇到它
强化体现为派生路径中的撇号，而撇号出现在哪些位置，是经过刻意设计的。
标准的原生 SegWit 路径是 m/84'/0'/0'/0/0。前三个层级，即用途、币种类型和账户，是强化的。后两个层级，即链和地址索引，则不是。正是这样的划分，使观察钱包得以实现：账户扩展公钥可以生成其下所有的收款地址和找零地址，而取得同一个 xpub 的攻击者既无法向上推到主密钥，也无法横向进入 m/84'/0'/1'。
写法可能不同，但实质不变。BIP-32写作0'，许多工具接受0h，而 Bitcoin Core 在其导出的描述符中写作 h，因为在 JSON 中撇号需要转义。把路径从 Sparrow 复制到 Core 后，会被改写成 h 的形式，这会让人第一次见到时感到不安，但纯粹是外观上的差异。
实用规则很简单。把直到账户的每一层都强化，让其下的两个层级保持非强化，以便观察工具继续可用；任何提供导出单个非强化子私钥的软件，都应视为隐患而不是便利，因为这样的导出再加上您的 xpub，就等于整个分支。
强化派生 vs 密码短语
强化派生是自动完成的；BIP-39密码短语则是您自己选择的秘密。两者常被归为加固钱包的方法，但解决的是互不相干的问题。强化派生保护密钥树，防止扩展公钥泄露造成的后果，所有标准钱包都已自动应用，无需您操作。密码短语则是在构建密钥树之前就混入种子的额外输入，会用同样的十二个或二十四个单词生成一个完全独立的钱包。忘记密码短语，资金就无法取回，因为任何地方都没有记录它。忽略强化派生，则什么也不会发生，因为这从来不是由您决定的。