Lightning Netoworkには大きく分けて２つの技術が使われており、それはペイメントチャネルによる双方向送金とHTLCによるマルチホップペイメントです。その中でも後者のHTLCには、その仕組みを逆手に取った攻撃手法がいくつか存在しており、今回はその中でもグリーフィング攻撃という攻撃について紹介したいと思います。

グリーフィング攻撃とは

• マルチホップペイメントで、中継者がペイメントを故意に遅延させること。
• 直感的にはこのような行為は中継者にとってメリットがないように思われる。それは瞬時にペイメントを中継することで、以下のメリットがあるから。
  
  • 手数料が稼げる。
  • 中継時に一時的にロックされた資金が解放され、流動性が良くなる。

グリーフィング（Griefing）とは英語で「悲しませる」という意味で、単に相手を嫌がらせるような攻撃で、Dos攻撃に似たものとして以前からLightning Networkへの攻撃手法として存在していました。ただ上記の理由から、この攻撃をするインセンティブがないということで、そこまで問題視されていませんでした。

しかし、中継者が特定のペイメントをする場合に限り、グリーフィング攻撃に動機付けがされるという内容が2020年4月1日付けLNメーリングリストに投稿されました。

競合者の排除

では、どのような場合にグリーフィング攻撃にインセンティブが付くのでしょうか？それは、セルフペイメントにおける送金の遅延によって他者の資金をロックさせ流動性を低下させる場合です。他者の流動性を低下させることで、送金の中継者となるための競合から排除することが可能になります。以下の例を見てみましょう。

AからCへ送金する場合、A -> B -> C と A -> E -> C の２つの経路が考えられます。この場合、BとEは互いに競合者となります。では、EがBよりもかなり大きな流動性を持っていたいとします。例えば、A-EとE-Cの間にはそれぞれ100mBTC、A-BとB-Cの間にはそれぞれ10mBTCのペイメントチャネルがあるとしてみましょう。

ここで、Eが5mBTCをセルフペイメントとして以下の経路で2回行います。

• E -> A -> B -> C -> E
• E -> C -> B -> A -> E

この時、最終受取り者であるEはそのペイメントの受取りを遅延させます。そうなるとBのもつ中継可能な資金はゼロとなってしまいます（Bがもつ送金可能な資金はA-BとB-C間でそれぞれ5mBTCだから）。この場合、AからCへ送金する場合、A -> B -> C の経路では送金ができないことが分かります。よって、Eはセルフペイメントによる受取り遅延をしている間は、Bを中継者としての競合から排除することができるのです。

以上から、グリーフィング攻撃は中継者が他の中継者に対して、流動性を低下させ、競争から排除するために動機付けされる可能性があることが考えられるのです。

解決案

Proof-Of-Closure という手法が提案されており、これについては次回解説したいと思います。ただ、この解決案の実装にはLNのメッセージプロトコルの変更・更新が必要となります。今回見たペイメントの中継者をその競争から排除させるためにグリーフィング攻撃に動機付けがされることが現実的であれば、やっかいな話です。しかし、今のところそのような行為が存在しないので、グリーフィング攻撃に対する実践的なインセンティブは少ないように思われます。

(2020-07-09 追記)

通常の支払いに使われるインボイスとは異なるHodl invoiceと言われるインボイス・支払い方法があります。これは支払人がペイメントを実行してもすぐに完了せず、受取人による受取り許可／拒否の意思確認が必要なタイプの支払い方法です。受取人によるアクションが必要なため、それまでペイメントは保留（遅延）している状態であり、これは上記で解説したグリーフィング攻撃と本質的には同じ状態です。Hodl invoiceにはいくつかのユースケースがありますが、多用しすぎるとネットワークへ負荷をかける可能性があることに注意が必要です（参考情報はこちら）。