开通道为什么半天没反应：从 open_channel 到 channel_ready 的排障地图

从 open_channel 到 channel_ready 的握手脚本

闪电网络开通道在链上只是一笔两签输出，真正的重头戏是链下那段一问一答的消息流水。把这条流水线的顺序和每一步的条件讲清楚，你就能判断自己的通道到底在哪一步、卡在哪一步。

第一回合：谈参数

开通方先选一个临时通道标识，在 open_channel 里把出资额、尘埃上限、保留金、HTLC 最小值、初始费率、延迟值和一整套密钥基点一次发出；接收方回 accept_channel，附上自己的对应参数，并给出 minimum_depth——出资交易要等多少确认才算可用。双方都协商了预付关闭脚本特性时，双方还要在阶段消息里承诺将来互关时资金必须去哪个脚本，防的是关账那一刻收款地址被偷换。

第二回合：定身份

接下来开通方给出出资交易的 Outpoint，即哪笔交易的哪个输出，同时用你的资金公钥和对方的第一承诺点算出最终的 channel_id；对方回 funding_signed，交出它对第一笔承诺交易的签名。到这里，两条承诺交易都齐了签名，但还不能动用。

第三回合：开门

双方各自盯着主链，直到出资交易的确认数达到 minimum_depth 要求，然后向对方发 channel_ready（这条消息早期叫 funding_locked，不少老日志里仍是旧名）。它可能携带一个第二个承诺点，用于把首笔承诺交易的对方密钥从已知的状态里剥出来，这是闪电密钥推导的常规操作。只有双方都发过 channel_ready，通道才进入正常经营阶段。需要等零确认的即时开通场景在规范里有专门类型：带零确认特性的通道里，接收方在这一步必须把 minimum_depth 置 0 直接放行，同时规范也警告这类信任要求把风险留给了接受方自己评估。

排障视角

钱包显示开通中很久，最常见的是卡在确认数：出资费率给低了，minimum_depth 迟迟不满，通道地址存在却付不进去。此时应当看节点日志里是否已经发出 funding_signed、双方 channel_ready 差几条确认，再决定要不要用出资交易的 RBF 能力提费；规范明确在零确认协商下禁用这类出资加急，因为会形成自我双花的危险。对普通用户，理解这条流水线的价值在于：开通道不是瞬间事件，任何一步缺消息，钱都还完整留在链上 UTXO 里，不存在中间态丢失。字段定义以 BOLT 2 当前文本为准，本文不构成投资建议。

消息没跑完时钱在哪里

逐个故障点检查账本位置：open_channel 之前，资金全在你自己的链上 UTXO；发完出资交易还没收到 funding_signed 前，交易在内存池或链上排队，承诺交易尚未齐签，双方都花不了那笔输出，重开或原样重连即可；出资已确认、双方 channel_ready 未齐时，钱锁在两签输出里，通道逻辑上未激活，但资金安全且可协商关闭；已 channel_ready 之后出现余额分歧，才进入状态更新与惩罚逻辑的范畴。换句话说，这条流水线的前三段全部有一个共同保命符：链上输出没进入可执行状态之前，损失面基本为零。

一个常被忽略的对称性

规范里双方都要发 channel_ready，很多人误以为只是开通方的确认回执。实际是各自独立观察出资确认数后各发各的，缺任何一侧通道都停在等待态。排障时让两端节点同时查日志里这条消息的收发时间，比盯着钱包转圈进度条有效得多。出资加急方面，普通通道类型下可用出资交易自身的 RBF 提费，带零确认协商的通道则被明确禁用该操作，动手前先确认通道类型。