共管地址的哈希下限：P2SH多签的碰撞威胁与隔离见证的修正

一个只存在于共管场景的威胁

比特币核心团队2016年发布的隔离见证收益文档里，有一节标题就叫多签脚本可能发生哈希碰撞。攻击场景是：若干人共同生成一个P2SH多签地址，比如人人持一把钥匙的两-of-三结构，其中某个心怀不轨的参与者一边陪你走正常流程，一边悄悄寻找一个脚本，它的内容与约定完全不同——比如把全部资金直接转给自己——但哈希值恰好与你们约定的地址一模一样。一旦找到，他在暗处保管恶意脚本，明面上给你一个看起来无懈可击的合法多签合约；将来资金进地址，只有他知道那个平行的解锁后门。关键在于，这个攻击不需要破解任何人的私钥，他只需要两个脚本哈希相等，而这属于生日攻击的范畴：面对160位的哈希函数，碰撞搜索的成本是二的八十次方量级，而不是二的六十次方那样高不可攀。隔离见证文档的原文对比很扎眼——以每秒一艾哈的算力持续运转，比特币挖矿网络每两周就能完成八十比特的搜索量，这个成本已经被认为处于资源极充足的攻击者可及范围之内。

为什么单钥匙地址没这个问题

同样的碰撞搜索对普通地址完全无效，原因在脚本结构里。单签地址的锁定脚本自带验签指令：网络会把你提交的任意数据先当作公钥或签名去验证，攻击者找不到一个哈希相等却无需合法签名就能花钱的脚本，因为哈希相等的脚本必然仍然要求对应私钥的签名。换句话说，哈希保护层外面那层验签逻辑封死了后门；P2SH多签之所以中招，是因为被哈希保护的那段脚本本身就是全部花费条件，没有额外的验签兜底。隔离见证文档强调，正因为如此，它选择继续用160位哈希保护单键场景，同时把脚本哈希升级为256位。

隔离见证给出的两处修正

第一处，原生隔离见证的多签花费改用P2WSH：脚本先以SHA-256做256位哈希，生日攻击的成本被抬到二的128次方量级，与比特币整体安全目标一致，短中期内不可行。第二处，隔离见证的脚本结构让见证数据不计入旧脚本哈希的路径，使旧式攻击面整体退役。需要澄清的是：P2SH多签并没有一夜消失，今天仍大量存量地址在用它，对存量的正确姿势是认清其威胁模型后做行为防御，而不是幻想哈希算法本身变强。

行为层的防御：让谁最后按下生成键

社区讨论里有一条成本最低的自保守则：在共建共管地址时，坚持让不信任的一方先交出公钥，最后由自己这边的设备完成地址生成。规则背后是对生日攻击的釜底抽薪——碰撞搜索要求攻击者能往脚本里注入足够多的自由度（比如最后一个可替换的参数），谁掌握最后一次编辑权，谁才可能种后门；反过来，若你是自己与两位合伙人共建地址，你的钥匙最后导入，那么恶意合伙人的搜索空间就被压成了零。再配合两条常识：把最终地址对应的完整赎回脚本用文本形式留档并交叉核验哈希；大额共管优先选择输出256位脚本哈希的隔离见证或多签服务。哈希强度是协议给的，协作安全是流程给的，两者都不可省。本文不构成投资建议。

存量地址的现实处置姿势

对已经存在于P2SH地址里的资金，正确动作是把信任模型讲清楚而不是换一句安慰话。如果地址由你完全控制的密钥共建——例如自家三把钥匙生成两-of-三——攻击面趋近于零，因为不存在能注入自由度的恶意共建者；风险只集中在密钥与脚本的生成过程由他人主导的场合，比如来历不明的共管服务或二手模板脚本。因此审计一个多签方案时，把问题问到脚本层面：赎回脚本由谁在哪个环节生成、各方是否核验过最终脚本的哈希与内容、密钥导入顺序如何约定。能把这三个问题答清楚的方案，即便落在160位哈希的旧框架里，残余风险也远小于流程含糊的漂亮新方案。安全从来是参数与流程的乘积，任何一边归零，另一边再大也无意义。