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

未关闭
  • 哪里不对？
#717 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 2 天内回复

@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
星标
594
派生
137
平均合并
2 天 8 小时
30 天内合并 PR
15

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

lightninglabs/loop 的其他 Issue

查看 lightninglabs/loop 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。