自分の Bitcoin ノード。
自分の Lightning チャネル。エンドツーエンドで KYC なし。

決済ルーティングノードと BTCPay フロントエンドには、pruned=550(ディスク上で約 5 GB)で十分です ── LND、CLN、BTCPay は検証とルーティングに UTXO セットと最近のブロック履歴のみが必要です。プルーニングはストレージ要件を約 700 GB から 1 桁 GB へ、IBD と追従のワークロードを「週」から「日」へと下げます。フルアーカイブは、高さ別の履歴ブロックデータアクセスが必要な研究やブロックエクスプローラーのユースケースがある場合にのみ実行してください。それ以外では、プルーニングがあらゆる運用軸で勝ります。

LND は最も多くデプロイされており(公開 Lightning グラフの約 70 %)、最大のツーリングエコシステム(Thunderhub、ride-the-lightning、Balance of Satoshis)と、最も洗練された BTCPay 統合を持っています。Core Lightning(CLN)はより保守的なコードベースで、最もクリーンなプラグインアーキテクチャを持ち、ルーティングビジネスの理由で多くの「オペレーターのオペレーター」が運用しています。Eclair は Scala 実装で、主に ACINQ のウォレットの背後で見られます。最初のノードには、Garrison 上の LND が最も摩擦の少ない経路です。ルーティングパフォーマンスを追求し、プラグインの拡張性を重視するなら CLN が正しい選択です。

Tor のみ(tor.active=true、クリアネットリスナーなし)はプライバシー最大主義のデフォルトです ── ノードは .onion としてのみ到達可能で、IP リークなし、ポートスキャンのフットプリントなし。クリアネット + Tor(デュアルリスナー)は、ノード IP を公開グラフに晒すコストの代わりに、より良いチャネル発見とより低いルーティングレイテンシを提供します。ほとんどのオペレーターは、クリアネットポートを開く運用コストが軽微ではないため(ファイアウォール、ポート 9735、LN 関連ログの慎重な識別)Tor のみで始め、ルーティング手数料の最適化に実際に関心を持つようになるとデュアルに移行します。

Static Channel Backups(SCB)を使用してください ── LND は channel.backup をチャネルが開閉するたびに書き出し、そのファイルだけでオンチェーン資金を回収するのに十分です(対向側からの強制クローズ)が、チャネルを再開するには不十分です。channel.backup を変更ごとにオフボックスに送ってください(暗号化された Backblaze への rclone、または別の VPS にアップロードする小さなスクリプト)。サトシを失う唯一のルール: 古い channel.db を決して復元しないこと。古い状態を復元すると対向側の justice トランザクションが発動し、チャネル資金を失います。SCB が安全な道です。

Lightning ルーティングノードのウォレットは、定義上必然的にホットです ── 鍵はリアルタイムで HTLC コミットメントに署名しなければなりません。規律はサイジングです: 運用するチャネル残高に必要な分のみ保持し、ルーティングノードウォレットを貯蓄ではなくフロートとして扱い、余剰のオンチェーン残高を定期的にコールドストレージへ移します。小規模オペレーターでは、ホットウォレットに $500〜$2,000 が一般的です。本格的なルーティングノードでは、ホット残高はコミットしたチャネル容量を反映します。

Garrison の 4 vCPU / 8 GB / 240 GB NVMe 上のプルーニングノードは、1 Gbps アップリンクで約 24 時間で IBD を完了します ── その大部分は CPU バウンドの署名検証です。Ravelin(8 vCPU / 16 GB / 480 GB NVMe)上のフルアーカイブノードは約 48 時間で完了します。NVMe が重要です: スピニングディスクは IBD を数日間の作業に変えてしまいます。Bitcoin Core の UTXO 書き込みは極めてランダム IO 重負荷だからです。NordBastion はあらゆるティアで NVMe です。

BTCPay Server の docker-compose スタックは、bitcoind + LN 実装 + nbxplorer + BTCPay ウェブティアを想定しています。Ravelin では小規模マーチャント(年間数千件のトランザクション)であれば 1 つのボックスにスタック全体をホストできます。Garrison では nbxplorer インデックスが回り始めると圧迫が現実のものになるため、BTCPay を 2 つ目のティアに分割することを推奨します ── ノードに Garrison、BTCPay には Sentinel を使い、WireGuard 越しにノードへ逆プロキシします。両方のフローはエンドツーエンドで KYC なしです。

Bitcoin の価値提案は許可不要の決済です。ルーティングインフラが顧客を識別し、AML を実施し、カードを登録するホスターで運用される瞬間、チョークポイントを再導入したことになります ── プロトコル層ではなく、インフラ層で。KYC なしの決済インフラのための KYC なしホスティングは絶対主義ではありません。それは「このルーティングノードを誰が運営しているか」の保管チェーンが召喚されうる場所を取り除くことです。プロトコルは許可不要であり、ホスターは少なくとも許可不要にフレンドリーであるべきです。