Lightning Network ルーティング ノードがゴミでいっぱいになるとどうなりますか?つまり、これはルーティングノードにとって多くの問題を引き起こします。かつてはスムーズでグローバルな決済システムであったものが、精通したスクリプターの手に少しの労力で固定されるようになります。

少数のルーティング ノードのグループで、資金を使った攻撃のテストに成功し、Joost Jager が説明した「Griefing」攻撃を実証しました。この攻撃は資金の窃盗ではなかったため「悲しみ」攻撃と呼ばれたが、結果的に被害者のフラッシュファンドが凍結されるという大きな恐怖をもたらした。グリーフ攻撃は、ビットコインで収益を上げようとしている大規模な「ワンボ」チャンネルにとって深刻な脅威であることがわかりましたが、一定期間凍結されました。

これは主に「悲しい」攻撃です。資金は失われませんが、被害者は高額なチャネル電力閉鎖の費用を支払わされる可能性があります。これはメインネットの既知の Lightning 脆弱性であり、特にビットコイン ライトニング ネットワークの初期段階では、理解して優先順位を付ける必要があります。

このテストに積極的に参加してくれた Clark Burkhardt と Phillip Sheppard、そしてこの問題に注目と重要性をもたらすためのたゆまぬ努力をしてくれた Jager に感謝します。私たちのデモでは、Jager が攻撃者の役割を果たし、Burkhardt と Sheppard が接続された被害者ルーティング ノードとして仲間入りしました。

攻撃作戦をどのように実行するか?

攻撃者は、最終的な支払いとして決済できないハッシュ化されたタイムロック契約 (HTLC) でチャネルを飽和させます。これらは、HODL 請求書と呼ばれる特別な種類の HTLC です。各方向でチャネルを圧倒するには、これらの未解決の HTLC のうち 483 個だけが必要です。これらの HTLC がチャネルに入ると、そのチャネルを閉じるために協力するトランザクションも含め、同じチャネル方向を使用するトランザクションは不可能になります。

理論的には、攻撃者は被害者に連絡し（キーを介してメッセージまたは「オニオンリング」を送信する可能性があります）、攻撃を止めるために身代金の支払いを要求する可能性があります。身代金が支払われると、攻撃者は未払いの支払いを削除し、攻撃を終了できます。攻撃は無制限に継続し、チャネル内のすべてのルーティングと支払いアクティビティが停止する可能性があります。これにより、ライトニング チャネルの資金が凍結されます。

各方向 (インバウンドとアウトバウンド) で 483 個の HTLC を使用することにより、1 つのチャネルで 2 つの支払い方向を停止できます。

なぜ攻撃者はこのようなことをするのでしょうか?

最初に思い浮かぶ動機は身代金を要求することです。このような攻撃は被害者に苦痛を与え、たとえ攻撃が止まる保証がないとしても、身代金を支払うことは被害者にとって魅力的である可能性があります。攻撃者にとって被害者に連絡することは危険を伴う可能性がありますが、攻撃者が連絡を取る理由は身代金の支払いだけではない可能性があります。

グリーフアタックを開始する 2 番目の動機は、ルーティングの競合を解消することです。競合他社のルートをブロックすると、攻撃者が所有するルートへの需要が高まる可能性があります。

ベンチマークとして、Lightning Labs のループ ノードには常に流動性が必要であり、場合によっては 2,500 ppm (100 万分の 1) の支払レート (0.25%) が支払われることを考慮してください。私の経験では、彼らは通常約 2 週間で 1,600 万サテュロスの流動性を使い果たします (年間成長率 5.2%) が、競争は存在します。

攻撃者がより低い手数料率で競合するルートを無効にできる場合、Loop はより高い手数料率を喜んで支払う可能性があります (流動性の供給が減少しているため)。 Loop が 3,000 ppm (0.3%) を支払うとします。また、他のチャネルが利用されていないため、この流動性はより早く消費される可能性があります。 Loop はその流動性を半分、たとえば 1 週間に使用する可能性があります。この例では、攻撃者の通常の収益率は 2 倍の 15.6% になります。攻撃者にとっての唯一のコストは、既存のチャネルでスクリプトを実行するコストと、ライトニング ネットワーク上で非倫理的/破壊的な行為を行うことによる心理的コストです。悪意のある攻撃者は、単一の攻撃者チャネルを使用して、約 9 つのチャネルをブロックする可能性があります。

この攻撃の被害者は何を経験するでしょうか?

この攻撃の被害者は、保留中の HTLC に対して特別なアラートを設定しない限り、この攻撃が発生しているかどうかを実際には知りません。 Thunderhub ユーザー (強く推奨されるツール) の場合、メイン画面には保留中の HTLC のグラフが表示され、チャネルには 483 個の保留中の HTLC しか保持できないという警告が表示されます。

出典: サンダーハブ

実際、私のノードはすぐに不安定になり、問題を私に通知した唯一のアプリだった Thunderhub を含むいくつかのアプリのクラッシュが発生しました。その後、「サトシスのバランス」電報ボットのおかげで、チャンネル閉鎖の通知が届きました。攻撃を受けているチャネルは自動的に閉じられます。これは実験の一部であるべきではありませんでした (非自発的強制協力に関する技術情報の詳細については、以下の追加の強制力データを参照してください)。

Burkhardt (salmiak) チャネルを使用したテスト支払いは、攻撃により失敗しました。この警告は、Burkhardt のノードがオンラインであってもオフラインであることを報告します。出典: サンダーハブ。

被害者が暴行を止めるためにできること？

攻撃が開始されると、基本的に、被害者がそれを止めるためにできることは何もありません。進行中の攻撃を止める唯一の選択肢は、攻撃されているチャンネルを強制的に閉じることです。これはテロリストの勝利を意味します。

さらに追い打ちをかけるように、チャネルを強制的に閉じると、未解決の支払いがオンチェーンのトランザクション データにプッシュされ、2 番目のオンチェーン トランザクションがトリガーされて、発信者を強制的に閉じることになります。 50 sat/vbyte と 483 のオンチェーン トランザクションでは、攻撃を受けているチャネルを強制的にシャットダウンするには、これは簡単に 100 万サットの価格に相当します (現在の価格でチャネル閉鎖手数料 368 ドル)。複数のオンチェーントランザクションは、出力が最低支払い「ダスト」制限を超えた場合にのみ発生します。 (テストネットの例を参照してください。)

Lightning チャネルの開始者は、クロージング料金を支払います。

文章

 https://t.co/z6mAGZxvrC. 終値はどんどん高くなっています。

攻撃を防ぐ方法

Jager は、攻撃者を隔離して撃破するための概念実証プログラムに取り組んでいます。彼は自分のプログラムを「サーキットブレーカー」と名付けました。サーキット ブレーカーはネットワーク レベルで機能するため、残念ながらこれを効果的にするには全員が参加する必要があります。

それとは別に、より良い解決策を見つけるために、この問題に優先順位を付け、専任のエンジニア/開発者の注意を引く必要があります。 Bitcoin Optech ニュースレター (No. 122 または 126) にも、プロトコルの変更に関する優れた議論があります。

この攻撃は今日から実行可能です。まだ悪用されていない奇跡。これは、Lightning をオープンでユニバーサルな決済ネットワークにしたいという今日のユーザーの熱意を反映しています。実際に損害が発生する前に、この問題に対処するためのさらなる取り組みを奨励し、鼓舞するために、この記事を必要に応じて共有してください。

非自発的閉鎖力に関する追加の技術情報

上記の強制シャットダウンが発生したときの、LND 0.11 を実行しているノードからのログは次のとおりです。

2020-11-26 21:24:47.374 [ERR] HSWC: ChannelLink(657759:561:0): リンクなし: ChannelPoint(c37bec006b18df172698a84739ca47128935e0a8666fecd1a843e49b01db207c: 0): からエラーを受信しましたピア: chan_id=7c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc3、ERR= 拒否されたコミット: commit_height= 455、invalid_commit_sig=3044022076fd65191eb6305b723fa6012be378413b6326e2786c38db58b4c02e1f3999d202207605ca31de8b4c5b1d9cd20dc1 581dfa2383e0b4e 06c8ad4f718ab5c434d8cf5、commit_tx = 02000000017c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc300000000008 a792e8002210d00000 00000002200201031cf10a1efef261edd3d0a1a6a953b27bc25bd7150bb2b07afdc69805e02157213000000000000160014de650929042be f58b71783ae1a44834a902 a8f2d542ca720、sig_hash=4e0fb804c74376020e4c44a60969b9206eb0aaa9a89b76017d60f23ad5cf63e5、エラー: リモート エラー

ログには、LND の既知の問題である「invalid_commit_sig」が表示されます。おそらく、これは再接続時に発生したものであり、チャネルのスタッタリングの直接的な結果ではない可能性があります。残念ながら、保留中の HTLC の数を考慮すると、その可能性が高くなります。 Jager 氏は、チャネルのブロック –> 無限支払いループ (バグ) –> ノードのシャットダウン –> 再接続 –> 無効なコミット信号 (バグ) –> チャネルの強制終了というプロセスの説明を手助けしました。

「エンドレス」ループ エラーは、HTLC 制限に達し、追加の HTLC が送信されたときに発生する既知のバグです。 LND は、支払い失敗を終わらせるのではなく、継続的な支払いを試み続けます。このバグを回避するには、LND 問題 #4656 を参照してください。