把退路写进出生证明
闪电通道的体面退场是双方合签一笔关闭交易，资金去向各自指定。这里留着一个攻击面：一方设备被入侵后，劫持者可以在关单协商时临时指定一个新脚本，把本应回自家金库的那份资金引去攻击者地址。upfront shutdown script 就是给这条路加的封条——双方在 open_channel 阶段就用 shutdown_scriptpubkey 字段预先承诺未来互撤时的资金出口。规范对这条封条的定位写得很诚实：它是一种”弱承诺”（恶意实现本来就容易无视规范），但提供了渐进的安全提升——想改这个出口，需要接收方的配合。能力协商靠特性位 option_upfront_shutdown_script（位对 4/5）：当双方都宣告支持时，规范要求 MUST 在开单时携带该字段，内容要么是一段合法的关闭脚本、要么显式给零长度（0x0000）表示不预设；只有一方支持时则是 MAY。此后发起 shutdown 的一方，若此前给过非零承诺，MUST 在关闭消息里发送同一个值；对端发现两者不等时 MAY 发 warning 并 MUST 断开连接。
合法出口脚本本身也有清单：默认允许的是隔离见证零版本的付款 pubkey 哈希输出（20 字节）与付款脚本哈希输出（32 字节）；只有当双方另谈成 option_shutdown_anysegwit 特性时，才允许见证版本一至十六的程序。把出口指向清单之外的形态，在协商阶段就会被拒。
灵活性与迁移代价
选零长度的运维含义是：这笔通道的关闭出口不受出生证明约束，靠临场协商。对流动性服务商给终端用户开单的场景，多数实现倾向预设脚本，让”服务端被黑”不等于”用户资金可被关单卷走”；而自建对等互联的两台自家节点往往留空换灵活。
另一面是锁定成本：一旦承诺，节点在这个通道的生命周期里只能把关闭资金送回承诺的那类地址。若你日后想把整套节点迁到新的密钥或新的输出格式，旧通道上的旧承诺不会跟着你搬家——想换遗嘱只能关通道重开。理性的做法是把”预设脚本的种类”当作与容量、费率并列的建通道决策项，在容量规划阶段就为出口脚本的格式寿命留出余量。
关单现场的字节账
顺着这条机制再看一眼互撤交易本身，能把”遗嘱”的边界看得更清。协商完成的产物是一笔普通比特币交易：出资输出被花掉，双方各领一份输出，费率由发起关闭的一方垫付并须达到可中继标准。规范为此给了发起方一条行为线——先对当前状态做一次无 HTLC 的承诺签署，确认双方对齐后才进入关闭协商，避免”带着未清算支付谈分手”的错位。整个流程对链上观察者完全像一笔普通的双入双出转账，这也符合闪电一贯的隐私叙事：链上看不出这是一次分手还是一次普通消费。
对照之下，upfront 承诺保护的对象就变得精确：它保护的是”互撤路径上的输出目的地”，既不约束单方广播路径（那由承诺交易模板与延迟机制决定），也不约束对端那一份输出的去向（那是人家的遗嘱）。所以看一条通道的安全姿态，值得分别问四个问题：双方有没有预设遗嘱、单方模板用哪套（锚定与否、延迟时长）、预设脚本指向什么格式的出口、这些答案在你下一次的密钥轮换或格式迁移之后还成立吗。四个问题都有明确答案时，才能说这条通道的资金流在”平时、故障、被黑、分手”四种天气下都有可验证的去处。
快速问答
问：预设脚本后我就不能改关单地址了？ 答：该通道的 cooperative close 输出口被锁定；改用途要走整条通道重开，或通过 splice 重建出资再议。
问：劫持者不用 cooperative close 怎么办？ 答：那会落到单方承诺广播路径，惩罚与延迟机制接管——upfront 脚本只防体面退场这条路被劫持。
问：零长度承诺安全吗？ 答：它等于放弃这层保护换协商灵活；两者都是规范允许的策略，风险敞口由运维自己选择。
风险提示：通道资金操作不可逆，预设脚本选择影响未来退出路径，请在小额测试后使用；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。