Lightningチャネルには二つの残高があり、その合計はチャネル容量によって制限されます。利用可能なローカル残高が送信流動性、リモート残高が受信流動性になります。準備金、commitmentトランザクションの手数料、保留中のHTLC、チャネルの規則、各ホップの利用可能容量によって、特定の金額が実際に経路を通過できるかが決まります。
チャネル容量は資金供給出力にロックされたビットコインです。流動性は、現在一方向に使える部分にすぎません。そのため、容量が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]
理解を深めるには、この項目とあわせて次もお読みください Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. 次の項目からも参照されています Payment Channel, Lightning Routing, ボラティリティ, 時価総額.