先别动，有要紧事：闪电通道的静默模式 stfu 与它的六十秒

给通道按下暂停键

闪电通道上同时跑着许多事：新增支付、结算支付、调整费率。而有些操作——规范原文点名的”根本性变更，尤其是协议升级”——在两边承诺交易完全对齐、且没有在途更新时最容易做。为此 BOLT 2 定义了通道静默（Channel Quiescence）机制，核心是一条叫 stfu 的消息（类型 2，payload 里带 channel_id 和 initiator 标记）。名字略带玩笑，功能很严肃：一方发起静默请求，另一方确认后，通道进入静默态（quiescent），常规的 HTLC 增删与费率更新在这期间全部暂停，双方腾出一个干净窗口去做调额（splice）这类大手术。

规则有明确的先后。发起方 MUST NOT 在自己或对方还有未决的 HTLC 添加、移除或费率更新时发送 stfu；也不得连发两次。发起者用 initiator 为 1 宣告主权，回应者把它置 0。握手完成后通道被视为静默；反之，任何一方再发确认消息，通道就恢复常态。最有画面感的一条是倒计时：若静默状态下 HTLC 仍未清空，节点 MUST 在六十秒后断开连接——带着在途支付强行静默是不被允许的，超时就把桌子掀了重来。

它和通道调额的关系

静默不是独立产品，它是 splice 类流程的前置协议：调额要重建出资交易、更换承诺模板，任何一条在途 HTLC 都可能让新旧状态纠缠不清，所以规范先让双方把水管关阀排空（静默），动完手术再开阀（解除静默）。特性协商上，这条消息依赖 option_quiesce（特性位对 34/35，要求类型 2 的 odd 声明）：没谈成这个位，stfu 根本不允许出现。对普通用户，感知它的最常见场景是手机钱包做通道替换或升级操作时的那几秒”通道暂不可用”。

谁在什么时候按暂停键

静默机制的适用边界比它的名字更值得记住。它服务的是”改变通道持久结构”的操作：调额动出资交易、旧式脚本模板升级成新式模板，这类操作要求两边的承诺交易在同一时刻完全对齐；若一边还挂着未结算的 HTLC 或没送达的费率更新，手术刀落下去切到的就是两本不同的账。stfu 把”确认账本对齐”这件事从隐式默契变成显式握手：发起者确认自己与对方都没有在途更新，发送 initiator 为 1 的静默请求；回应者核对后回 initiator 为 0，通道进入静默，此间双方都不许发更新消息，直到一方用新的确认消息解除状态。

对依赖通道做收付的商户与流动性运营，运维含义是排期艺术：调额窗口天然是一段”这条边暂时停业”的服务中断，时长取决于两件事——在途支付清空的快慢，以及对手端实现是否按规范在六十秒计时器到期时果断断链重来。成熟的做法是把静默安排进流量低谷、提前通知依赖方、并准备回退路径（调额失败时旧通道继续营业）；若静默后迟迟无法解除，第一时间查的不是手术本身，而是握手是否因残留更新被对方拒绝——顺序永远是先清场、再动土。

还有一个实现层的边角值得记录：静默握手本身不带资金操作，也不上链，失败可以无损重来；它消耗的是时间与服务可用性，而非任何链上成本。这解释了为什么调额被设计成”可反复尝试”的过程——卡住了断开重来，比强行带着脏状态继续安全的代价低得多。

快速问答

问：静默期间我能付款吗？ 答：不能。静默的定义就是暂停常规 HTLC 更新，这条通道在窗口内不进新支付。

问：静默会泄露什么隐私？ 答：stfu 只在通道对端之间传递，网络上的其他节点看不到；它们最多观察到这条边短暂不转发。

问：静默卡住了怎么办？ 答：协议自带解药——在途 HTLC 清不完就先断链，重连后双方重新协商；手动操作则等当前支付结算完再重新发起。

风险提示：通道结构变更期间支付将中断，操作不当可能导致资金延迟回收；本文不构成投资建议。