如何在 BlueWallet 中查看闪电支付状态

了解闪电支付生命周期

1. 当发送者构建包含支付哈希、金额和到期时间的发票时，闪电支付就会启动。

2. 发送方节点通过一个或多个中间通道路由支付，直至到达接收方节点。

3. 成功接收后，接收者的节点显示原像，该原像沿着相同的路线传播回来以确认结算。

4. 若沿途任何通道流动性不足或验证失败，支付立即失败，且不锁定资金。

5. 与链上 Bitcoin 交易不同，闪电支付不会出现在区块浏览器中——必须从钱包内部事件推断状态。

BlueWallet 的内置状态指示器

1. 发起付款后，BlueWallet 会显示实时状态徽章： “待处理” 、 “已确认”或“失败” 。

2. 点击事务行将打开详细视图，显示路由尝试、逐跳延迟和最终错误代码（如果适用）。

3. 对于出站付款，“已发送”选项卡显示发票生成、首次路由尝试和原像确认的时间戳。

4. 只有在验证原像并更新余额后，入站付款才会显示在“已收到”下 - 不会显示未确认的条目。

5. BlueWallet不显示“0-conf”或中间状态；它会在更新 UI 状态之前等待完整的加密确认。

通过通道状态手动验证

1. 前往“设置”→“闪电”→“查看通道”，查看本地通道余额和承诺交易ID。

2. 使用兼容的区块浏览器（如 1ML 或 Amboss）交叉引用支付哈希与通道的最新承诺交易。

3. 如果哈希出现在承诺输出脚本中，则付款以加密方式绑定到该通道状态。

4. 使用“导出日志”功能检索原始 HTLC 记录，包括 cltv_expiry、amt_to_forward 和 custom_records。

5. 将日志中的 payment_hash 字段与原始发票哈希进行比较，以排除哈希冲突或错误路由。

实践中观察到的常见故障触发因素

1.过期不匹配：发票过期设置太低会导致节点在到达目的地之前拒绝转发。

2.通道余额不足：中间节点缺乏足够的出站容量来中继请求的金额。

3. CLTV 增量错位：发送方的 cltv_expiry 和节点策略之间的不匹配会导致第一跳立即拒绝。

4.网络分区：即使在成功传送后，节点之间暂时失去连接也会阻止原像传播。

5.发票重复使用：尝试两次支付同一张发票会触发合规闪电实施的自动拒绝。

常见问题解答

问：在解决之前，我可以在 BlueWallet 中查看待处理的 HTLC 吗？答：不会。BlueWallet 故意隐藏未经确认的 HTLC，以防止用户混淆。只有完全结算或明确失败的付款才会出现在用户界面中。

问：BlueWallet 支付成功后是否会在本地存储原像？答：是的。原像经过加密并存储在设备的安全区域中。它们永远不会传输到服务器或暴露在导出日志中。

问：为什么付款显示“已确认”，但没有反映在我的链上余额中？答：闪电余额是链下的。确认意味着 HTLC 在通道图中结算，而不是 BTC 在链上移动。

问：我可以手动强制关闭通道以从卡住的付款中恢复资金吗？答：强制关闭会启动 144 个区块的争议窗口。它不会加速 HTLC 解析，如果滥用可能会导致费用损失。