Miniscript：把多签策略写成可验证的清单

裸脚本的表达困境

比特币脚本图灵不完备，这是安全设计，但代价是复杂策略的表达全靠操作码堆叠。以家庭共管为例：常规分支要两名守护者共同签名，若主密钥失联超过半年，持有人可凭时间锁单独取回。直觉结构是“OR( AND(双人签), AND(单人签, 时间锁) )”，翻成裸脚本却是栈、操作码与分支跳转的手工编排——正确性靠肉眼，体积靠运气，签名方还各自需要理解分支结构。裸脚本的多签与时间锁基础见 OP_CHECKSEQUENCEVERIFY 相对时间锁：延迟从何时起算。

Miniscript 的解法：策略的代数

Miniscript 给出一套描述支出条件的结构化语言：与、或、阈值、时间锁、签名检查都是可组合的组合子，程序可以静态分析每个表达式的性质——是否恒定输出布尔、是否可兑现、花费脚本与见证的字节成本、可互换性（malleability）安全性。工具链能自动生成满足条件的脚本、给出体积与满足方案，并保证生成脚本在规范子集内可验证。于是策略评审从“读脚本汇编”变成“读清单文本”，审计成本发生量级变化。

与描述符钱包的合流

Miniscript 并非独立协议，它与描述符体系天然互补：描述符定义“钱锁成什么形状”，Miniscript 填充形状内部的策略表达，钱包端的支持随版本推进（多签描述符与恢复流程逐步标准化）。家庭多签的托管模板可以表达为一个可迁移的描述符文本，冷设备之间传递这份文本即可完成配置对齐，观察端导入同款文本即可监控，见 观察钱包怎么搭建：监控余额但不暴露私钥 与 listdescriptors如何安全审计？。

Taproot 多签：更省的那条路

多人共管在 Taproot 语境下有另一重身份：密钥聚合路径下，多签在链上表现得和单人转账无法区分，脚本路径仅作兜底，见 Schnorr 签名与 ECDSA 有何不同：从字节数到批量验证。Miniscript 的编译目标之一正是把策略映射进 Taproot 的脚本树：常用分支（比如聚合密钥路径）优先，兜底分支（时间锁恢复）进树，链上足迹随使用路径最小化。对“三人 2/3 共管加紧急恢复”这类家庭方案，Taproot 加脚本树是当前体积与隐私最优解方向，规范口径以 BIP341 与项目文档为准。

什么时候不该用它

第一，简单场景别加戏：单人 P2WPKH 或纯 2-of-3 裸多签已足够，Miniscript 的边际价值随策略复杂度上升。第二，签名方生态要先检查：参与设备的固件与钱包若不支持对应脚本模式，再优雅的策略也只是单边愿景——多方协作前的能力矩阵核对清单应当作为验收单写进部署文档。第三，静态分析不覆盖你的密钥管理：脚本能证明“满足条件者可花”，永远证明不了“密钥持有人不会被钓鱼”，安全边界的另一半在人，见 硬件钱包漏洞公告后该怎么处置？。

小结与风险提示

Miniscript 把比特币脚本从汇编时代推进到清单时代：策略可读、可审、可验证体积。它降低的是复杂度风险，不消除密钥与流程风险；托管方案落地前，请在测试网演练所有分支与恢复路径并核对参与设备兼容性，本文不构成投资建议。

读一个例子建立手感

以“2 人 2-of-2 共同花费，或 365 天后持有人独自花费”为例，策略文本可以表达为 or( and(pk(A), pk(B)), and(pk(C), after(365天)) ) 的形状：两个签名谓词与一个相对时间谓词的组合，编译器据此给出体积估算、满足方案清单与安全性提示（例如哪个分支的签名可延展、时间锁用块单位还是时间单位）。对照裸脚本，同一逻辑需要手写操作码序列、分支跳转与 DROP 清理，审读者必须逐指令推演栈状态。策略层面的时间参数最终仍落在 CSV 语义上，见 OP_CHECKSEQUENCEVERIFY 相对时间锁：延迟从何时起算。这份“可读性红利”在双人共管里也许微不足道，在多机构代管与继承场景里就是审计能不能做、多久做完的分水岭。