去年の1月、本稿でライトニングネットワークにおける「Inbound Routing Fee」をめぐる論争について取り上げました：
難ありなInbound Fees実装をLndが強行突破で導入する思惑にライトニング開発者らが反発
今週の論争で際立ったのは、ライトニングでInbound Feesを実現する方法をめぐり、明確に最適な提案がいない状況で、ロールアウトや後方互換性の面で懸念が残る実装方法をLndが強行突破で導入しようとしていることと、それに対する反発でした。 今日はどのような実装方法が議論に上がっているのか、それぞれの特徴と欠点、そして論争の内容をまとめました。 Inbound Feesでライトニング上の資金の流れを効率化 ライトニングにおけるルーティングノードは送金を中継する際に自らが中継先に送る金額について手数料を徴収することができます。その一方で、送金元に近いノードから自身が受け取る送金については送金元に近いノードが手数料を設定することになります。 ルーティングノードはチャネルの手数料を設定する際に自身の都合も考慮して設定します。例えば、これ以上残高がリモート側に流れてほしくないチャネルについては手数料を高くすることで中継の対価を高く設定でき、逆に残高がローカル側に偏ってしまったチャネルについては手数料を下げることでより中継に使用されやすくすることができます。ただし、自分が設定した手数料
加藤 規新
重要な背景知識となるため、今回の記事と合わせてご覧いただくことをおすすめします。
さて、おそらく2024年夏～秋頃にリリースされるLnd v0.18.0でついにInbound Routing Feeを設定できるようになります。今日はその変更の内容とその影響について改めて解説します。（若干のネタバレになりますが、上の記事で紹介した論争が収まったわけではありません。）
・ライトニングのRouting Feeの決まり方
・Inbound Routing Feeの実装方法と、各実装の反応
・本当に効果があるのかは不透明