Lightning流动性

通道容量是锁定在资金输出中的比特币。流动性只是当前可向一个方向使用的部分；因此，容量为1,000,000 sats的通道可能几乎全部余额都在一侧，无法向相反方向传递大额付款。 [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

出站流动性是本地节点在扣除协议储备、commitment交易的费用义务和待处理HTLC后，可以经通道发送的金额。向外付款或转发时它会减少，从对等节点收到价值时则会增加。 [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

入站流动性是对等节点能够向本地节点发送的金额。通过该通道收款需要它，但修改付款请求不会创造它；它必须存在于远端余额中，或由流动性管理操作提供。 [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

路由付款只有在每个选定跳点都具备正确方向的足够可用流动性，并按其费用规则、最小和最大金额以及CLTV时间限制接受HTLC时才会成功。一个耗尽的通道就可能阻断一条其他方面连接良好的路线。 [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]

channel_reserve_satoshis、commitment交易费用、anchor outputs、dust规则、max_htlc_value_in_flight_msat、max_accepted_htlcs以及已有的待处理HTLC，都可能减少新付款可用的金额。因此，钱包余额、通道容量和当前可路由金额是三个不同的数值。 [BOLT #2 — Peer Protocol for Channel Management]

BOLT #7允许公布通道及其转发规则。容量可以从链上确定的资金输出中获得；这并不公开私有的余额分配。发送方根据自身信息、过去结果和付款尝试来估计路线。公开区块浏览器无法确认选定路线此刻能传递某一具体金额。 [BOLT #7 — P2P Node and Channel Discovery]

已结算付款会移动其所用每个通道的余额：发送侧的出站流动性下降、入站流动性上升，另一端则相反。付款重新分配已有容量，不会增加总容量。 [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

转发节点为同一个HTLC，需要一个通道的入站流动性和下一个通道的出站流动性。如果sats位于错误的通道或错误的一侧，即使总量很大也不够。 [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

收到付款、循环再平衡、开启或关闭通道、交换和splicing都可以移动流动性。它们在费用、链上足迹、时间、对交易对手的信任和失败风险方面各不相同；没有任何方法能免费创造流动性。多部分付款可以组合多条路线，但仍需足够的总方向性容量。 [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]

在自己的节点上检查各通道的本地和远端余额、储备、待处理HTLC及费用缓冲，然后测试计划发送的金额。记录方向、金额、时间和实现：流动性会在每次付款后变化，并不是整个网络永久不变的单一评分。 [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]