Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Unintended behaviour with lowToHighRoutingPlugin due to outlier LOOP peer with high fee

オープン
  • 何か問題がありますか？
#717 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 7 日以内に返信

@bhandras がすでに取り組んでいます。

2024年3月14日 から。

評価

この issue はまだ評価されていません。

説明

To prepare lnd for looping out the mc is manipulated to help with finding a route to LOOP. This is done by building a list of LOOP peers and sorting that list by fee.

Before each "attempt" (defined by MaxPaymentRetries which is 3 by default) the lowToHighRoutingPlugin.BeforePayment is called which will reconfigure the mc based on the sorted-by-fee list of LOOP peers.

The list is simply divided by MaxPaymentRetries and with each attempt that is >1 the fee floor is increased and each peers with fees below that floor will essentially be excluded from the pathfinding.

The fee range to LOOP right now is 180-14,262 sats, this will result in floor steps of (14262-180)/3 = 4694 sats (first attempt does not count so the floor for attempt#1 is 180). Part of the relevant code:

        // Do not do anything unless we tried to route the payment at least
	// once.
	if currAttempt < 2 {
		return nil
	}

	// Calculate the limit until we'll disable edges. The way we calculate
	// this limit is that we take the minimum and maximum fee peers which
	// define our fee range. Within this fee range we'll scale linearly
	// where each step euqals to the range divided by maxAttempts.
	minFee := r.nodesByMaxFee[0].fee
	maxFee := r.nodesByMaxFee[len(r.nodesByMaxFee)-1].fee
	limit := minFee +
		((maxFee-minFee)/int64(maxAttempts))*int64(currAttempt)

https://github.com/lightninglabs/loop/blob/master/routing_plugin.go#L509

Effective, the peers that are included for pathfinding by this logic per attempt:

Attempt 1: fee >=180-14262
Attempt 2: fee >=9568-14262 (the double step up is another issue)
Attempt 3: fee >=14262-14262

In practice, only the first attempt will be able to find a "reasonable" route to LOOP since that's the only one that uses a floor that actually includes pretty much all the peers.

What I have not mentioned yet is that if you look at the LOOP peers all of them have LOOP fees <= 4000 ppm (I disregard base fee for since it's not relevant in this issue) except for one that has 14,262 ppm. This is causing the big steps.

So this lowToHighRoutingPlugin mechanism does not seem to do anything useful in practice. It also does not seem to hinder the ability to find a path to LOOP since there are plenty of peers in the first attempt.

Though, more broadly speaking now I understand this code better: conceptually, this whole approach is not intuitive to me. To me it seems like a better strategy to step up the fee ceiling and slowly include more peers with higher fees instead of excluding peers with lower fees. It might take a bit longer to find a path but the fees could be lower for the client. It also does not completely exclude low fee LOOP peers that could be used for a partial payment via MPP.

Full disclosure: I am a LOOP peer that has a relatively low fee compared to other peers so changes to this code could have an impact on my ability to route to LOOP.

主要言語
Go
スター
593
フォーク
138
平均マージ
4日 9時間
マージ済み PR（30日）
14

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

lightninglabs/loop のほかの issue

lightninglabs/loop の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。