Allow specifying a max fee for static Loop In to force splitting across multiple channels to the last hop
I maintainer di solito rispondono entro 7 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 50/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- go
- Ambito
- backend-api-design, cli, payments
Direzione di ricerca
Inizia dal comando statico Loop In e dalla gestione delle richieste, seguendo gli argomenti esistenti per la commissione massima dello swap fino alla chiamata di instradamento del pagamento e alla LND payment API. Confronta i limiti di commissione di instradamento proposti con il comportamento MPP esistente; il lavoro è concluso quando viene accettato e verificato un limite distinto per la commissione di instradamento per Loop In, in modo da impedire una route single-HTLC altrimenti idonea quando il limite richiede la suddivisione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Go
- Stelle
- 593
- Fork
- 138
- Merge medio
- 4g 9h
- PR unite (30g)
- 14
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di lightninglabs/loop
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
lightninglabs/loop#1246 ·
I maintainer di solito rispondono entro 7 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
lightninglabs/loop#1196 ·
I maintainer di solito rispondono entro 7 giorni
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 42/100
lightninglabs/loop#1172 ·
I maintainer di solito rispondono entro 7 giorni
-
Track armed static address HTLCs after aborted swapsForse di nuovo libera @hieblmi l’ha presa 103 giorni fa e non c’è nessuna pull request aperta. Aperta
lightninglabs/loop#1171 · 1 assegnatario ·
I maintainer di solito rispondono entro 7 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
lightninglabs/loop#1170 ·
I maintainer di solito rispondono entro 7 giorni
Tutte le issue di lightninglabs/loop
Issue simili
-
[BUG]: Windows GUI package of v1.17.0-rc3 has no GTK DLLsForse già presa @andrut-ds l’ha presa oggi. Apertabug CI/CD Pactus-GUI Windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
pactus-project/pactus#2428 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 91/100
I maintainer di solito rispondono entro 1 giorno
-
feat
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
ory/hydra-maester#312 · 1 reazione ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
rossoctl/context-guru#610 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
I maintainer di solito rispondono entro 1 giorno