闪电通道的协商关闭看起来像一场双拼转账：一条 shutdown 消息里写着自己想要的收款脚本，对面回一条同样格式，两边脚本拼成一笔链上交易。但”想写到哪就写到哪”并不成立——BOLT 2 规范给 shutdown 的 scriptpubkey 划了一份封闭清单，绝大多数地址类型都在名单外。本文按规范原文列清单、讲两个解锁名单的协商开关，再说明这份白名单背后的安全取舍。
一、名单基础项。规范用 MUST 写明 shutdown 的 scriptpubkey 必须取以下形式之一：OP_0 加 20 字节推送（P2WPKH）、OP_0 加 32 字节推送（P2WSH）——这两项无条件允许。名单外的默认收款地址（比如裸 P2PKH、P2SH）在通道关闭里不被接受，这与”通道本身就是一个 2-of-2 P2WSH”同构：规范把关闭输出限制在隔离见证的紧凑形式内，保证关闭交易体积小、费率行为可预期。
二、第一个开关：option_shutdown_anysegwit。功能位 26/27 协商成功后，名单追加一项：OP_1 到 OP_16 任一指定期别、后跟 2 到 40 字节推送——也就是未来隔离见证版本的输出都能作为关闭地址。没协商到这一位的实现收到这类脚本只能按名单外处理。Taproot（P2TR，指定 1）地址作为关闭收款点，正是靠这一位进入合法名单的。
三、第二个开关：option_simple_close。功能位 60/61 协商成功后（规范标注它以 anysegwit 为前提），名单再追加 OP_RETURN 输出，允许把关闭交易做成”几乎无输出的极简关单”——一方甚至可以选择只留对方的输出，把自己的份额按规则处理（规范在 simple close 的报价条款里对 dust 与 closer_output_only 有逐项规定）。注意依赖链：没协商 anysegwit 的实现，simple close 也视为无效声明，不能单独打开。
四、预锁定与改口的合作义务。若双方都宣告了 option_upfront_shutdown_script 且本端开通道时给过非零长度的预提交脚本，那么 shutdown 里的 scriptpubkey MUST 与之完全一致。收到不符值的一侧的处理规范也写死了：MAY 发一条 warning 说明原因，随后 MUST fail the connection——没有”带病继续关”的中间态。预提交把”关去哪儿”锁死在开通道那一刻，想改出口只能炸掉通道重开。规范的 Rationale 段自己承认这是个”弱承诺”——恶意实现可以无视规范——但它把改口的成本从”单方静默替换”抬高到”必然当场撕破脸”，增量防御的意义就写在这段注释里。
五、名单外怎么办与排障读法。收到不符合名单的 shutdown：本端 MUST NOT 配合关单；日志里关闭谈判卡住、对端反复改脚本又重连，多半是对方钱包在尝试把关闭地址指向升级后的新型地址却没有正确协商功能位——解法是把通道用支持对应功能位的实现重开，而不是在聊天里问”为什么关闭一直失败”。另一侧的读法：你的收款地址是 P2TR 而关闭一直被拒，先查这条通道的功能位存档里 anysegwit 是否在列。关闭输出的白名单是闪电”链上痕迹越小越好”哲学的极端体现：连体面散伙这件事，规范也只留了几扇门。
六、OP_RETURN 分支的编码细节。simple close 放行的 OP_RETURN 并非任意数据：规范要求其后只跟单条推送——短形式用 6 到 75 的推送操作码后紧跟恰好该字节数的数据，长形式用 76 再跟 76 到 80 之间的操作码与对应数据，超出这个推送编码形状的输出仍然按名单外处理。同时别忘了发送侧的时序纪律：shutdown 一条通道只许发一次、有未锁定的拼接交易在飞时不得发、发出之后不得再提新 HTLC，并且应当拒绝对该通道后续新增的 HTLC 做路由。白名单管能写到哪，这几条时序规则管什么时候才许说，两组规则合起来才把一个简单的散伙消息变成状态机里不可回退的一步。
风险提示：本文内容为技术机制科普，不构成任何投资建议、收益承诺或买卖时机判断。涉及协议规则与软件行为的描述以对应软件版本（文中已标注）的官方源码与规范为准。涉及资金操作的，请先在测试网或小额环境验证。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。