Lightning Network ルーティング ノードに解決されないガベージ トランザクションが供給されるとどうなりますか? つまり、ルーティング ノードにとっては大きな問題となります。 かつてはスムーズでグローバルな決済システムだったものが、精通したスクリプト作成者のちょっとした努力で機能不全に陥る可能性があります。
ルーティング ノードの小さなチームで作業し、実際の資金を使用して攻撃のテストを実行することに成功し、「悲しみ」攻撃について説明 ジュースト・イェーガー。 この攻撃は資金の窃盗ではないため、グリーフアタックと呼ばれますが、被害者のライトニング資金が凍結されるという大混乱を引き起こします。 私たちが発見したのは、ビットコインで収益を得ることを期待している大規模な「ワンボ」チャネルにとって、グリーフィングは深刻な脅威であるということです。しかし、資金は一定期間凍結されるだけです。
これは主に悲しみ攻撃です。資金の損失はありませんが、被害者は高額なチャネル強制閉鎖の費用を支払わされる可能性があります。 これはメインネット Lightning の既知の脆弱性であり、特にビットコインの Lightning ネットワークのこの初期市場段階では、理解して優先順位を付ける必要があります。
このテストに積極的に参加してくれた Clark Burkhardt と Phillip Sheppard、そしてこの脆弱性への注目と優先順位を高めるためのたゆまぬ努力に感謝します。 Jager はデモンストレーションで攻撃者の役割を果たし、Burkhardt と Sheppard は接続された被害者ルーティング ノードとして私に加わりました。
攻撃の仕組み
攻撃者は、確定した支払いとして解決されないハッシュ タイム ロック コントラクト (HTLC) で 483 つ (または複数) のチャネルを飽和させます。 これらは、HODL 請求書として知られる特別な種類の HTLC です。 これらの未解決の HTLC のうち XNUMX 個だけが、方向ごとにチャネルを圧倒するために必要です。 これらの HTLC がチャネルに入ると、そのチャネルを協調的に閉じるトランザクションを含め、同じチャネル方向を使用するトランザクションは不可能になります。
理論的には、攻撃者は（おそらくキー送信メッセージまたは「オニオンブロブ」を通じて）被害者に連絡し、攻撃を止めるために身代金の支払いを要求する可能性があります。 身代金が支払われると、攻撃者は未解決の支払いを削除して攻撃を終了する可能性があります。 攻撃は無期限に継続され、そのチャネルでのすべてのルーティングと支払いアクティビティが停止する可能性があります。 これにより、Lightning チャネルの資金が凍結されます。
インバウンドとアウトバウンドの各方向で 483 個の HTLC を使用することで、チャネル内で両方向の支払いを滞らせることができます。
なぜ攻撃者はこのようなことをするのでしょうか?
最初に思い浮かぶ動機は、身代金を要求することです。 この攻撃は被害者に苦痛を与えるため、攻撃が止まるという保証がなくても、身代金を支払うことは被害者にとって魅力的である可能性があります。 攻撃者にとって被害者に連絡することは危険かもしれませんが、誰かがこれを行う理由は身代金の支払いだけではない可能性があります。
グリーフィング攻撃を開始する XNUMX 番目の動機は、ルーティング競争を妨害することです。 競合他社のルートを妨害すると、攻撃者が所有するルートへの需要が増加する可能性があります。
ベンチマークとして、Lightning Labs のループ ノードには継続的な流動性需要があり、そのために支払い額の 2,500 ppm (ppm) (0.25 パーセント) の手数料率を支払う場合があると考えてください。 私の経験では、彼らは通常、約 16 週間で 5.2 万サット相当の流動性を使い果たしてしまいます (年率 XNUMX%) が、それは競争が存在する場合の話です。
攻撃者がより低い手数料率で競合するルートを無効にできる場合、Loop はより高い手数料率を支払うことをいとわない可能性があります (流動性の供給が減少しているため)。 Loop が 3,000 ppm (0.3 パーセント) を支払うだけでなく、他のチャネルが機能していないため、その流動性をより迅速に使用するとします。 Loop はその流動性を半分の時間、たとえば 15.6 週間で使い切る可能性があります。 この例では、攻撃者は通常の XNUMX 倍以上の APR XNUMX% を達成します。 攻撃者にとっての唯一のコストは、既存のチャネルでスクリプトを実行するコストと、ライトニング ネットワークに不道徳な行為や損害を与える行為による心理的コストです。 単一の攻撃者チャネルを使用すると、悪意のある攻撃者は約 XNUMX つのチャネルを妨害する可能性があります (「 これに関するイェーガー氏のツイート).
この攻撃の被害者は何を経験するでしょうか?
この攻撃の被害者は、保留中の HTLC に対して特別なアラートを設定していない限り、この攻撃が発生していることを実際には知りません。 Thunderhub ユーザー (強く推奨されるツール) の場合、ホーム画面には保留中の HTLC のグラフと、チャネルが保留中の HTLC を 483 個しか保持できないことを示す警告が表示されます。
実際に、私のノードはすぐに信頼性が低くなり、問題を通知する唯一のアプリであった Thunderhub を含むいくつかのアプリのクラッシュが発生しました。 その後、私の「Balance of Takeshis」Telegram ボットのおかげで、チャンネル閉鎖の通知を受け取りました。 攻撃を受けているチャンネルは自動的に強制的に閉じられました。 それは実験の一部であるはずではなかった。 (不随意強制閉鎖に関する技術情報の詳細については、以下の追加強制閉鎖データを参照してください。)
悲しみの攻撃を止めるために被害者は何ができるでしょうか?
攻撃が始まると、被害者は基本的にそれを止めることができません。 進行中の攻撃を止めるために利用できる唯一の選択肢は、攻撃されているチャンネルを強制的に閉鎖することです。これはテロリストの勝利を意味します。
さらに追い打ちをかけるように、チャネルを強制的に閉じると、未解決の支払いがオンチェーンのトランザクション データにプッシュされ、強制終了の開始者に対して二次的なオンチェーン トランザクションがトリガーされます。 50 衛星/バイトと 483 のオンチェーン トランザクションでは、攻撃を受けている 1 つのチャネルを強制的に閉鎖するには、簡単に 368 万衛星の値札になります (現在の価格でチャネル閉鎖手数料は XNUMX ドル)。 複数のオンチェーントランザクションは、出力が最低支払い「ダスト」制限を超えている場合にのみ発生します。 （見る この例 テストネット上で。)
悲嘆攻撃を防ぐ方法
イェーガー氏は、攻撃者を隔離して戦うのに役立つ概念実証プログラムに取り組んでいます。 彼は自分のプログラムを「サーキットブレーカー」 サーキットブレーカーはネットワーク レベルで機能します。これは、残念ながら次のことを意味します。 誰も 効果を発揮するには参加する必要があります。
さらに、より良い解決策を見つけるには、この問題に優先順位を付け、専任のエンジニア/開発者が注意を払う必要があります。 Bitcoin Optech ニュースレター (122 号または 126 号) では、プロトコルの変更に関する良い議論も行われています。
この攻撃は今日から実行可能です。 まだ悪用されていないのが奇跡です。 これは、Lightning がオープンでユニバーサルな決済ネットワークになることを目的として、現在 Lightning を使用している人々に対するインセンティブを反映しています。 実害が生じる前に、この問題を解決するためのさらなる取り組みを奨励し、鼓舞するために、この投稿を適切と思われる場合には共有してください。
非自発的強制終了に関する追加の技術情報
上記の非自発的な強制終了が発生した瞬間の、LND 0.11 を実行しているノードのログは次のとおりです。
2020-11-26 21:24:47.374 [ERR] HSWC: ChannelLink(657759:561:0): failing link: ChannelPoint (c37bec006b18df172698a84739ca47128935e0a8666fecd1a843e49b01db207c:0): received error from peer: chan_id=7c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc3, err=rejected commitment: commit_height=455, invalid_commit_sig=3044022076fd65191eb6305b723fa6012be378413b6326e2786c38db58b4c02e1f3999d202207605ca31de8b4c5b1d9cd20dc1581dfa2383e0b4e06c8ad4f718ab5c434d8cf5, commit_tx=02000000017c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc300000000008a792e8002210d0000000000002200201031cf10a1efef261edd3d0a1a6a953b27bc25bd7150bb2b07afdc69805e02157213000000000000160014de650929042bef58b71783ae1a44834a902a8f2d542ca720, sig_hash=4e0fb804c74376020e4c44a60969b9206eb0aaa9a89b76017d60f23ad5cf63e5 with error: remote error
ログには、LND の既知の問題である「invalid_commit_sig」が表示されます。 おそらく、これは再接続時に発生する可能性があり、チャネル妨害の直接の結果ではありません。 残念なことに、保留中の HTLC の量により、それが発生する可能性が高くなります。 Jager 氏は、チャネルの妨害 –> 無限の支払いループ (バグ) –> ノードのダウン –> 再接続 –> 無効なコミット署名 (バグ) –> チャネルの強制終了というプロセスを説明してくれました。
「無限」ループのバグは、HTLC 制限に達し、追加の HTLC が送信されたときに発生する既知のバグです。 LND は支払い失敗で終了するのではなく、ループで支払いを試行し続けます。 このバグを解決するには、次を参照してください。 LND 問題 #4656.
これは Jstopher によるゲスト投稿です。 表明された意見は完全に彼ら自身のものであり、必ずしも BTC Inc または Bitcoin Magazine.
