Lightning流动性

Anna 和 Pavel 有一个容量为 1,000,000 sat 的支付通道，也就是一百万聪；聪是 Bitcoin 链上的最小单位。先看一个简化情形：Anna 拥有 800,000 sat，Pavel 拥有 200,000 sat。为了看清原理，我们暂时忽略准备金、手续费和待完成支付。Anna 向 Pavel 付款时使用自己这一侧的资金；从 Pavel 收款则要用到他那一侧的资金。因此，即使通道总容量达到一百万，Pavel 也无法通过它向 Anna 支付 300,000 sat。钱没有消失，只是当前的分布无法支持这笔支付。 [1] [3]

出站流动性是可用于从你这里向外付款的金额。在例子中，它以 Anna 的 800,000 sat 余额为基础，但由于准备金、手续费和待完成支付，实际可发送的上限通常更低。如果 Anna 向 Pavel 之外的人付款，第一步仍然要经过她自己的某个通道。节点是管理通道并处理 Lightning 支付的程序。后续节点则要用各自的资金完成接下来的转发。持有通道之外的 bitcoin，并不会自动增加她的出站流动性；钱包需要通过合适的方式把这部分价值转入 Lightning。 [1] [3]

入站流动性是对方能够向你发送的金额。如果 Anna 打开一个通道，里面几乎所有资金都属于她，那么她适合向外付款，却没有多少收款空间。创建新的收款请求不会改变这个分布。她需要一个对方拥有可用余额的通道。有些钱包会通过服务商安排这件事，把复杂过程隐藏起来，往往会收取费用。入站容量不是 Anna 已经拥有的额外财富，而是接收未来支付的能力。 [1] [3] [5]

现在 Anna 向 Pavel 支付 100,000 sat。在简化例子中，双方余额变成 Anna 的 700,000 sat 和 Pavel 的 300,000 sat。通道容量仍是 1,000,000 sat。Anna 能发送的变少了，能收回的却变多了；Pavel 则相反。如果钱包有多个通道，发生变化的是这笔支付实际经过的通道。所以方向始终重要，早晨看到的流动性数值，不一定代表晚上仍能发送的金额。 [1] [3]

发给远端收款人的支付需要经过一连串通道。每一段都必须在正确方向拥有足够的可用流动性，还要包含后续转发所需的手续费。如果其中一步无法通过，即使其他通道容量很大，这条路径仍会失败。钱包可以尝试另一条路径，或在支持的情况下把支付拆成多部分。但这些做法不会凭空产生缺少的资金。除了金额，还要检查时间条件。HTLC 是一种条件支付，可以通过证明知道某个秘密来完成。与 CLTV 相关的规则用区块确定期限；各段期限之间留出的间隔，让中间节点在转发受阻时仍有时间在 Bitcoin 链上结算。 [1] [2]

中间节点必须能通过一个通道收款，再通过另一个通道发送与之关联的支付。所有余额加起来很多，并不足够。如果资金位于不适合这条路径的通道中，即使属于该节点，也可能无法用于这次转发。它需要第一个通道的入站流动性，以及第二个通道的出站流动性。两步由 HTLC 条件关联起来：支付的完成取决于某个秘密的揭示和时间规则。因此，中间节点不只是相信前一位参与者以后会付款的口头承诺。 [1] [3]

收款和付款会自然改变流动性。管理多个通道的人还可以进行环形再平衡：从自己出发沿一条路径付款，再沿另一条路径收回来，从而在自己的通道之间调整余额。Swap 可以将链上资金换成 Lightning 资金，或反向交换。Splicing 可以调整支持该功能的通道的注资，而不必按通常流程关闭后重新打开。也可以另开一个通道。这些方法在费用、耗时、链上记录、信任要求和失败风险上各不相同。它们都不会创造新的钱；应根据需要发送、接收，还是兼顾两者来选择。 [1] [4]

先分清问题是发送还是接收，并检查钱包和对方节点是否在线。使用自己的节点时，逐个比较通道的本地与远端余额、准备金、待完成支付和手续费。若钱包由服务商管理，要确认它显示的可用金额究竟表示什么。一笔支付失败，本身不能证明钱已丢失；原因可能是某一段缺少流动性、受到限额约束，或出现暂时故障。小额试付只能验证当时的那笔金额，不能保证以后所有支付都能通过。 [1] [3] [4]

节点运营者需要区分几种限制。交易输出规定了一笔金额以及花费它必须满足的条件。channel_reserve_satoshis 表示必须保留的准备金。部分资金还可能被待完成的 HTLC 占用，也就是尚未结算的条件支付。以下限制针对另一位参与者提出的 HTLC。max_htlc_value_in_flight_msat 限制这些支付的总金额，max_accepted_htlcs 限制它们的数量；msat 是千分之一聪，用于 Lightning 内部计量。根据通道类型，还要考虑用于关闭通道的 commitment transaction 的手续费，以及可能存在的 anchor outputs；这些特殊输出可供后续交易使用，以提高整个交易包的确认手续费。Dust 规则决定哪些输出太小，不能放进该交易。因此，应按具体实现和通道类型计算真正可用的上限，而不是统一减去某个固定准备金。 [1] [6]

BOLT #7 描述了通道公告和支付转发规则。对于已公告的通道，可以在链上找到它的注资输出及容量，但这不能揭示双方当前如何分配余额。发送者依靠自己的信息、以往结果和支付尝试选择路径，而不是查询一份完整公开的实时余额表。因此，网络浏览器可以显示一个容量很大的通道，却不能据此确认你的金额此刻能沿正确方向通过。 [2]