## 附录：攻击面分析——为何 xpub 替换是多签特有的风险？
### 单签钱包是否存在 xpub 替换攻击？
**答案：否。**
在单签钱包结构中（如 BIP32/BIP39 衍生的标准钱包）：
- 钱包只依赖一个 `xpub`，并且这个 `xpub` 是从用户私钥派生而来；
- Coldcard、Trezor 等硬件钱包会自动根据本地 seed 派生地址，无需输入外部 `xpub`；
- 用户可以通过设备显示屏确认“这是我派生出来的地址”，不存在外部注入路径。
**因此：xpub 替换在单签钱包中不存在攻击面，攻击路径被封死。**
---
### 多签钱包为什么引入了 xpub 攻击面？
多签钱包（如 2-of-3、3-of-5）需要以下信息来生成地址：
1. 所有参与者的 `xpub`；
2. 公钥排序规则（如 BIP67）；
3. 多签脚本模板（如 `OP_2
4. 每个 key 的派生路径（如 `m/48'/0'/0'/2'/0/1`）；
这就意味着，用户必须**信任这些输入的 `xpub` 是来自真正的签名方**。如果攻击者悄悄将其中某一份换成自己控制的 `xpub`，那他就自动成为地址共管人，甚至是单签人。
#### Coldcard 攻击案例回顾：
- 用户通过 PSBT 模板或 JSON 导入多签配置；
- 攻击者在其中替换了某一参与者的 `xpub`；
- Coldcard 在旧版本中未提示或验证该替换；
- 用户生成地址、发送资金，攻击者即可随时提取。
---
### 攻击面比较表
- **单签钱包**
- 不接收外部 xpub，派生路径完全由设备掌控；
- 地址来源明确、签名单一；
- **xpub 替换攻击无效**。
- **多签钱包**
- 依赖多个外部 `xpub` 合成结构；
- 用户很难手动验证每一条 xpub 与 fingerprint；
- **xpub 替换为高危攻击点**。
---
### Taproot 是否规避了 xpub 替换问题？
**部分规避，但引入了新的验证难题。**
Taproot + MuSig2 等结构通过将多个 pubkey 合成为一个点：
P = H(P1 + P2 + P3)
这确实可以隐藏合约结构，提升隐私，但也导致：
- 用户无法从地址还原参与者是谁；
- 如果其中一个公钥被攻击者替换，生成的地址仍然合法；
- 用户在链上看不到任何异常，但攻击者已取得合约控制权。
**因此：Taproot 并未从根本上消除 xpub 替换的攻击面，反而**因为其不可还原性使得**攻击更加隐蔽**。
---
### 总结
> 多签钱包之所以引入新的攻击面，不是因为它“更复杂”，而是因为它**必须信任外部结构**。一旦你的钱包要“与他人协作生成地址”，你就必须验证“这些人是谁”、“这些地址是怎么来的”——这就是攻击的入口。
**单签保护的是私钥，
多签则要求你保护你的伙伴。**