Lightning routing node の運用は テクニカル × 経済学的判断の連続。channel 選定、fee policy 設定、rebalancing、incident recovery などの実務トピックを、 アルゴリズム解説（routing_visualizer.html）とは異なる 運用者の視点から整理する。LND / CLN / LDK で動作する代表的ツールも横断比較。
LND (シェア最大、ecosystem 豊富) / CLN (plugin 設計、Bitcoin Core 派) / LDK (mobile / lib として埋め込み) / Eclair (BOLT 12 早期対応)
Self-hosted (RaspiBlitz / Umbrel / Start9) / VPS (Voltage / BTCPay Server) / Hosted (Voltage / Lightning Labs)。可用性・コスト・privacy のトレードオフ。
routing node profitable には目安 0.1–1 BTC の自己資金 + 同等の inbound liquidity。少額では fee 収入 < 機会費用。
routing 目的なら public 必須（gossip で発見される）。商用 wallet bind なら private channel + zero-conf も選択肢。
Static Channel Backup (SCB) を 定期的に複数バックアップ。channel.db の整合性を保つ snapshot 設計。
外部 watchtower への登録（lnd Altruist / 自社 / TEE）。force-close 中の breach 防止。
routing node の収益は「適切な peer との適切な capacity」で決まる。Channel 数を増やすほど経費（on-chain fee, monitoring cost）も増えるため、少数の高品質 channelが原則。
| 基準 | 意味 | 確認方法 |
|---|---|---|
| Centrality | betweenness centrality が高い → routing 経路の一部になりやすい | Amboss / 1ml で確認 |
| Channel age | 長期運営の peer はサヨナラリスク低い | node_announcement の timestamp |
| Active channel ratio | peer の channel 中、active 比率高 → 健全運用 | graph snapshot 解析 |
| Fee policy | peer の fee policy が安定 → routing の予測性 | channel_update の頻度 |
| Capacity distribution | 大口だけでなく中規模も持つ → diversity | graph 解析 |
| Geographic / network | 異なる地域 / Tor / clearnet | node IP / address |
Lightning fee = base_fee_msat + amount × fee_rate_ppm / 1_000_000。base は固定額、ppm は比例額。
| 戦略 | base_fee | fee_rate (ppm) | 狙い |
|---|---|---|---|
| Aggressive (高利益) | 1000 msat (1 sat) | 500–2000 | 収益最大化 |
| Balanced | 1000 msat | 200–500 | routing 量と利益のバランス |
| Cheap (高 throughput) | 0 msat | 50–200 | routing 量最大化 |
| 0-base (Pickhardt 推奨) | 0 | variable | MCF routing で選ばれやすい |
| One-side flow drain | 0 msat | 1 (片方向) / 5000 (反対) | 意図的な balance shift |
2021+ の主要 wallet は Pickhardt MCF (min-cost flow) を使い、−log(P_success) の逆数を min-cost に組み込む。
これにより fee より success probability を重視するため、
"安い fee なら通る" という旧モデルが崩れた。
→現代の routing node は balanced + 健全な liquidityが利益源。
Channel が片方向に流れると capacity の片側が枯渇し、routing できなくなる。rebalancing でこれを修正する。
自分の node を経由する 循環 payment で balance を移動。bos rebalance / rebalance-lnd。最も基本的。fee コスト発生。
on-chain 経由で balance 調整。channel close 不要。Loop Out で outbound 増、Loop In で outbound 減。
2024+ で実装が広がった新手段。capacity を変えずに splice-rebalance で balance shift。最低コスト。
片方向の fee を高く、反対方向を 1 sat にして 自然 traffic で rebalance。ROI 良いが時間かかる。
| Tool | 用途 | 対応 | メンテ状況 |
|---|---|---|---|
| charge-lnd | fee policy 自動更新 | LND | active |
| bos (Balance of Satoshi) | rebalancing / fee / report | LND | active |
| rebalance-lnd | circular rebalancing 専用 | LND | active |
| lnnode | fee + rebalance daemon | LND | active |
| RTL (Ride The Lightning) | Web UI | LND/CLN | active |
| ThunderHub | Web UI + analytics | LND | active |
| Amboss / Magma | analytics + liquidity market | any | commercial |
| 1ml.com | graph snapshot / analytics | any | active |
| plugin 系 (CLN) | summary / clboss / poncho | CLN | active |
| Lightning Terminal | Loop / Pool / Faraday GUI | LND | Lightning Labs |
※ 簡略試算。実際は rebalancing cost / on-chain fee / hosting cost / time value 等を考慮要。多くの個人 routing node は "BTC 蓄積を目的に APR 1–3% を許容"するモデル。
peer の不調・自身の force-close で channel が on-chain 解決。HTLC sweep を CLTV 期限内に完了する必要。Anchor outputs / CPFP 必須。
peer が unresponsive で HTLC が pending のまま。lncli closeallchannels --force 等で channel 強制 close、HTLC を on-chain 解決。
Static Channel Backup から復元 → SCB-restore → peers が cooperative close を支援。ベストプラクティスは定期 backup。
2023+ の attack family。各実装が patch 投入済。Anchor outputs 有効化必須。詳細
BTC mempool 混雑時の force-close は dangerous（CLTV expiry までに confirm されない可能性）。事前に mempool monitor して回避。
peer が古い commitment 放送 → justice TX を即提出。Watchtower 登録は必須。