Allow specifying a max fee for static Loop In to force splitting across multiple channels to the last hop

Đang mở
  • Có gì không ổn?
#1,208 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
50/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend-api-design, cli, payments

Hướng nghiên cứu

Bắt đầu từ lệnh Loop In tĩnh và phần xử lý yêu cầu, lần theo các đối số phí swap tối đa hiện có đến lời gọi định tuyến thanh toán và LND payment API. So sánh các giới hạn phí định tuyến được đề xuất với hành vi MPP hiện có; được xem là hoàn thành khi một giới hạn phí định tuyến riêng biệt được chấp nhận cho Loop In và được xác minh là ngăn một tuyến single-HTLC vốn đủ điều kiện trong trường hợp giới hạn yêu cầu phải chia nhỏ.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Is your feature request related to a problem? Please describe.
When using static Loop In (loop static in ... --last_hop <pubkey>) with more than one channel open to the same last-hop peer, there's currently no way to force the payment to split across those channels. LND's pathfinding only attempts to shard a payment when no single route/channel can carry the full HTLC — if one channel happens to be big enough on its own, LND will always prefer the single-HTLC route, even if the user would rather spread liquidity across both channels.

This matters for users actively managing inbound liquidity across multiple channels to the same peer (e.g. Loop's own routing node) — right now the only way to force a split is to manually shrink the swap amount below the capacity of any single channel, which isn't practical for larger swaps or automated tooling.

Describe the solution you'd like

Add a max-fee argument to the loop-in request (e.g. --max_fee_sat / --max_fee_ppm at the routing/HTLC level, distinct from the existing --max_swap_fee_sat / --max_swap_fee_ppm which caps Loop's service fee).

Setting a low-enough max routing fee would eliminate the single-HTLC route from consideration (a single larger HTLC generally costs more in routing fees than an equivalent smaller shard), forcing the payment to split across the available channels as a side effect — without needing to build new explicit splitting/shard-count logic.

An alternative would be an explicit shard-count argument on the loop-in request, but the max-fee approach seems simpler since it reuses a lever that already exists conceptually in LND's payment API rather than requiring new splitting logic.

(Note for maintainers: in LND terms this means the payment falls back to its existing MPP shard-splitting behavior once the single-HTLC route is priced out of consideration.)

Describe alternatives you've considered

MPP?

Additional context
Static Loop In user with 2 channels open to the Loop peer, wanting a large loop-in swap (static or normal) to route inbound liquidity across both channels rather than concentrating it on whichever single channel happens to have enough capacity.

Ngôn ngữ chính
Go
Star
594
Fork
137
Merge trung bình
2 ngày 8 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của lightninglabs/loop

Tất cả issue của lightninglabs/loop

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.