Inbound Liquidity

Remote balance は相手に属し、受取余地の候補を表します。local balance は自分の側です。支払いを受け取ると価値がリモート側からローカル側へ移ります。受取能力を買うことは、ビットコインを贈られることでも既に売上を得たことでもありません。 [Lightning Labs — Managing liquidity]

単純化した 1000000 sat のチャネルで local balance が 800000 sat、remote balance が 200000 sat なら、総受取余地は 200000 sat であり百万ではありません。この例は準備金、手数料、未決の HTLC を省略しています。初期送金なしで単独出資すると主に送金余地が生まれ、開設の承認だけで方向は逆転しません。 [Lightning Labs — Managing liquidity] [BOLT 2 — Channel management]

BOLT 2 は準備金、最低額、同時 HTLC 数、未決総額によって HTLC の追加を制限します。処理中の支払いが一時的に資金を拘束することもあります。各チャネルの利用可能額と制限を確認し、全残高の合計から一律の準備金を引く計算はしないでください。 [BOLT 2 — Channel management]

BOLT 7 は手数料や htlc_maximum_msat など方向別の channel_update パラメーターを公開し、経路全体の確実な最新残高を公開するわけではありません。相手のオフラインや途中のボトルネックで支払いは止まります。リモート残高の合計は、特定の送信者から同額を受け取れる保証ではありません。 [BOLT 7 — Routing gossip]

Lightning の送金は使用したチャネルの local balance を減らし、remote balance を増やします。Loop Out は Lightning の価値をオンチェーン出力に移し、受取余地を空けられます。Loop In は逆に送金用資金を補充します。ビットコインは生まれないため、経路、スワップ、オンチェーンの費用と操作結果を考慮してください。 [Lightning Labs — Managing liquidity] [Lightning Loop — Direction and channel balances]

相手は自分に向けたチャネルに出資できます。Lightning Pool では bid が期間限定の流動性を買い、ask が提供します。リース期間はブロックで表します。プレミアムや他の費用を払っても、リモート残高全体が自分の所有になるわけではなく、契約後の永久利用も保証されません。 [Lightning Labs — Managing liquidity] [Lightning Pool — Orders and leases]

Circular rebalancing は自分の一つのチャネルから送り、ネットワーク経由で別のチャネルから受け取ります。送信側チャネルは受取余地を得て、受信側は消費します。新たな資本は生まれず経路手数料がかかります。利用可能な経路が必要で、全リモート側に資金がないノードの問題を単独では解決できません。 [Lightning Labs — Managing liquidity]

売上を受け取るとリモート残高がローカル残高へ変わり続け、追加の受取余地が尽きることがあります。使えるチャネル、処理中の支払い、補充費用、予定額を監視します。失敗した試行が受取ノードに見えない場合もあり、発行済み請求書や古い容量表示は支払い確認ではありません。 [Lightning Labs — Merchant liquidity]