loop
loop copied to clipboard
lightninglabs
Autoloop V2 Features
There are many directions we could take the autoloop feature in. This issue outlines a few features that could be implemented in upcoming iterations.
Please comment if a specific feature would be helpful for your usecase, or you would like to request a feature that is not listed.
Liquidity Management
- [x] Per-peer rules: rather than setting a liquidity thresholds on a per-channel basis, specify a desired liquidity balance per-peer
- [ ] Flow awareness: track lnd's sends/receives/forwards and inform autoloop's swap decisions based on htlc flows
- [x] Custom swap amounts: allow user-set minimum and maximum swap amounts
- [x] Auto-loop-in: add support for automated loop in
Control
- [ ] Recurring budget: add a recurrence period for budget which will automatically roll over (eg, weekly/ monthly budget)
- [ ] Param handing: read parameters in from loop config, store on disk so they persist across restarts
- [ ] Batching: to save on fees, set autoloopers to execute at set times to take advantage of the server's ability to batch swaps
- [ ] Amount based backoff: if an auto-out fails due to off-chain routing, a smaller amount is likely to succeed, adjust accordingly
Per-peer rules: rather than setting a liquidity thresholds on a per-channel basis, specify a desired liquidity balance per-peer
Taking this a step further, I would love to be able to set a default rule for all channels as in general, I want the same autoloop rules for all of my channels. In my case my desire is just to acquire more inbound liquidity.
Batching: to save on fees, set autoloopers to execute at set times to take advantage of the server's ability to batch swaps
This would be awesome - I'd love to be able to batch loop operations across multiple channels / peers at once to save fees.
In addition, I'd love to just be able to set percentage fee limits rather than raw satoshis. If my node is doing a 2x larger loop, I'm okay with paying 2x more in fees. Normally the limits of what I'm willing to pay is percentage based.
Wouldn't making loop scriptable be a better approach? Anyway, things that probably can't be done in scripts without direct support:
- Instead of executing
loop inright away, somehow transfer the address to BTCPayServer and wait for payment, so that the next paying customer actually unknowingly pays for it, confusing chain analysis. Bonus points for doing PayJoin at the same time. Special prize if the PayJoin includes inputs from swap server. - Optimize for UTXOs - if there's a UTXO with amount close to the desired amount, use that UTXO for
loop in. Swap server could offer the same forloop outwith discount. - Automatically run the coins through some CoinJoin
- Allow using a "foreign" wallet - custom xpub for
loop outto HWW,bitcoindRPC wallet, NBXplorer hot wallet forloop in(which can also be used for PayJoin) - Join UTXOs of several nodes that are swapping at the ~same time (just wait for a good opportunity) in a way that makes the transaction confusing to third parties.
- Avoid swapping during high-fee spikes
- Allow funding a completely new channel by swapping out from existing channel in a single operation
- Merge
loop outwith PayJoin (as a client)
Thanks for the feedback @Kixunil!
Wouldn't making loop scriptable be a better approach?
Uncertain by what you mean here?
Just a note that a lot of your suggestions here aren't specifically tied to autoloop, so probably deserve their own issue on the loop repo if they are features that are important to you! Commented on a few here that I think are relevant.
Avoid swapping during high-fee spikes
Good news is that autoloop already covers this! You can set a sweeplimit in sat/byte and autoloop will only swap when expected chain fees are below that, which is awesome for setting 1sat/byte then leaving the client to dispatch swaps in low fee markets.
Join UTXOs of several nodes that are swapping at the same time
Further good news is that this is already the case, and something that we have on the cards (referred to as batching in the top level issue). When you perform a swap, you can advertise a cutoff time by which you want the on chain htlc to be published. If the swap server has multiple swaps that hit a similar deadline, they will all go in one tx. We're looking into taking this further with autoloop, and having the loop server advertise specific batch times so that all the autoloopers running can pick a batch time and get better privacy and fees.
somehow transfer the address to BTCPayServer and wait for payment, so that the next paying customer actually unknowingly pays for it, confusing chain analysis.
For loop in, you can set the client to externally provide the on-chain htlc, so as is it is possible for a client to pay on chain and the loop server to pay btcpay off-chain. However, there is some complexity there. The btcpay node needs to be reachable by the loop server off-chain, otherwise it can't make the payment to the merchant. If loop can't pay the merchant, it will never sweep the on-chain htlc, and then the person paying the on-chain htlc will need to sweep the timeout path, which has a large delay, and requires additional action from a client paying a merchant. Theoretically possible, but would not recommend at present (lots of edge cases to work out). Would recommend opening an issue for this one if possible.
Optimize for UTXOs
Since you can create the loop in htlc yourself using external, this is already manually possible with the upcoming coin selection in lnd 0.12. The loop client generally just uses lnd to create the on-chain htlc, so would open an issue on that repo if you have some thoughts on selection in general.
Automatically run the coins through some CoinJoin
This is out of scope for a swap, I would say, and is likely more complex than it's worth.
Allow using a "foreign" wallet - custom xpub for
loop out
You can already provide loop out with whatever payout address you like. Xpub support would indeed be cool, would suggest a feature request issue here if just providing an address is insufficient for your use case.
Uncertain by what you mean here?
Having ability to supply a script (e.g. by running external program that connects to RPC) that can dynamically affect the rules of swapping could allow others to implement various rules as they wish. This is already possible using RPC and such, but I guess there's a room for making it simpler. E.g. have an RPC method scheduleswap with params min_sat, max_sat, deadline_seconds, max_fee, channel, direction, psbt (if present inputs/outputs will be added to this psbt) would go long way to making it possible. For even better experience, providing a libraries in a few popular languages that allow one to receive a callback when channels change and respond to it with swaps could be provided. Then custom policies would boil down to a simple function.
Yeah, I guess those features can be implemented with external scripts if the above is available. I wrote my ideas as things I'd love to see implemented somehow and if the solution is creating all building blocks to allow other software to implement these ideas then it's fine.
The btcpay node needs to be reachable by the loop server off-chain
I would expect the node be the same lnd loopd connects to (could even contain a check if the invoice is present in lnd listinvoices). To solve edge cases, maybe use it in PayJoin scenario only as it has more room for a custom logic that solves them. To cover non-PayJoin scenarios, loop could provide a special address that will be automatically emptied into a channel once a payment arrives. This address could then be supplied to BTCPay.
if you have some thoughts on selection in general
Not entirely sure if the logic of picking a UTXO which satisfies the requirements should be in lnd or loopd. The requirements are obviously min and max amount, probably also being segwit/confirmed (I'm not entirely familiar with loopd requirements)
This is out of scope for a swap, I would say, and is likely more complex than it's worth.
Providing required APIs to do this externally would be helpful and hopefully not too complex. Maybe it only needs PSBT support.
About xpub, my general idea is that a mechant wants to keep at least x sats and at most y sats in LN wallet, once the amount a >= y there should be an automated loop out of a - x sats to an unused address of the provided xpub.
In addition, I'd love to just be able to set percentage fee limits rather than raw satoshis. If my node is doing a 2x larger loop, I'm okay with paying 2x more in fees. Normally the limits of what I'm willing to pay is percentage based.
I second this! Being able to set a maximum effective fee rate, like balanceofsatoshi's bos rebalance --max-fee-rate value is the only missing feature that currently stops me from using Autoloop! I personally don't care how specifically the fees I pay break down, or how much I pay in fees total. The one magic number I care about is the effective fee rate! :+1:
