rkfg/regolancer

lnd channel rebalancer written in Go

Intro

Why even write another rebalancer? Usually, the only motivation is that the existing software doesn't satisfy the developer. There may be different reasons why improving the existing programs isn't something the dev wants. Maybe the language is the problem or architecture. For me there were many reasons including these. Two most advanced rebalancers for lnd are rebalance-lnd (Python) and bos (JS). However, each has something the other one lacks, both have runtime requirements and both are slow. I decided to fix these issues by rewriting the things I liked in Go instead so it can be easily compiled and used anywhere. I also made the output pretty, close to the design of accumulator's fork of rebalance-lnd.

Features

• automatically pick source and target channel by local/remote liquidity ratio
• retry indefinitely until it succeeds or 6 hours pass (by default)
• payments time out after 5 minutes (by default) so if something's stuck the process will continue shortly
• timeouts can be customized
• JSON/TOML config file to set some defaults you prefer
• optional route probing using binary search to rebalance a smaller amount
• optional rapid rebalancing using the same route for further rebalances unitl route is depleted in case a rebalance succeeds
• data caching to speed up alias resolution, quickly skip failing channel pairs etc.
• storing/loading cached nodes information to disk to "warm up" much faster next time you launch the program
• sensible node capacity formatting according to Bitcoin design guidelines (easy to tell how many full coins there are)
• automatic max fee calculation from the target channel policy and preferred economy fee ratio (the amount spent on rebalance to the expected income from this channel)
• excluding your channels from consideration
• excluding any nodes from routing through (if they're known to be slow or constantly failing to route anything)
• using just one source and/or target channel (by default all imbalanced channels are considered and pairs are chosen randomly)
• calculate the rebalance amount automatically from current and desired balance percent
• safety precautions that prevent balances going beyond 50% of channel capacity, can be turned off explicitly if that's what you want
• saving successful rebalance parameters into a CSV file for further profit analysis with any external tools

Installation

You need to have Go SDK installed, then simply run go install github.com/rkfg/regolancer@latest and by default it will download, compile and build the binary in ~/go/bin/regolancer. To crosscompile for other platforms use GOARCH and GOOS env vars to choose the target architecture and OS. For RPi run it as GOARCH=arm64 go install github.com/rkfg/regolancer@latest if you run a 64 bit system (and you should!). You'll find the binaries in ~/go/bin/linux_arm64. For 32 bit use GOARCH=arm, the binary will be located in ~/go/bin/linux_arm.

Parameters

Config:
  -f, --config                 config file path

Node Connection:
  -c, --connect                connect to lnd using host:port
  -t, --tlscert                path to tls.cert to connect
      --macaroon-dir           path to the macaroon directory
      --macaroon-filename      macaroon filename
  -n, --network                bitcoin network to use

Common:
      --pfrom                  channels with less than this inbound liquidity percentage will be considered as source channels
      --pto                    channels with less than this outbound liquidity percentage will be considered as target channels
  -p, --perc                   use this value as both pfrom and pto from above
  -a, --amount                 amount to rebalance
      --rel-amount-to          calculate amount as the target channel capacity fraction (for example, 0.2 means you want to achieve at most 20% target channel local balance)
      --rel-amount-from        calculate amount as the source channel capacity fraction (for example, 0.2 means you want to achieve at most 20% source channel remote balance)
  -b, --probe-steps            if the payment fails at the last hop try to probe lower amount using this many steps
      --allow-rapid-rebalance  if a rebalance succeeds the route will be used for further rebalances until criteria for channels is not satifsied
      --min-amount             if probing is enabled this will be the minimum amount to try
  -i, --exclude-channel-in     (DEPRECATED) don't use this channel as incoming (can be specified multiple times)
  -o, --exclude-channel-out    (DEPRECATED) don't use this channel as outgoing (can be specified multiple times)
      --exclude-from           don't use this node or channel as source (can be specified multiple times)
      --exclude-to             don't use this node or channel as target (can be specified multiple times)
  -e, --exclude-channel        (DEPRECATED) don't use this channel at all (can be specified multiple times)
  -d, --exclude-node           (DEPRECATED) don't use this node for routing (can be specified multiple times)
      --exclude                don't use this node or your channel for routing (can be specified multiple times)
      --exclude-channel-age    don't use channels opened less than this number of blocks ago
      --to                     try only this channel or node as target (should satisfy other constraints too; can be specified multiple times)
      --from                   try only this channel or node as source (should satisfy other constraints too; can be specified multiple times)
      --fail-tolerance         a payment that differs from the prior attempt by this ppm will be cancelled
      --allow-unbalance-from   (DEPRECATED) let the source channel go below 50% local liquidity, use if you want to drain a channel; you should also set --pfrom to >50
      --allow-unbalance-to     (DEPRECATED) let the target channel go above 50% local liquidity, use if you want to refill a channel; you should also set --pto to >50
  -r, --econ-ratio             economical ratio for fee limit calculation as a multiple of target channel fee (for example, 0.5 means you want to pay at max half the fee you might
                               earn for routing out of the target channel)
      --econ-ratio-max-ppm     limits the max fee ppm for a rebalance when using econ ratio
  -F, --fee-limit-ppm          don't consider the target channel fee and use this max fee ppm instead (can rebalance at a loss, be careful)
  -l, --lost-profit            also consider the source channel fee when looking for profitable routes so that route_fee < target_fee * econ_ratio - source_fee

Node Cache:
      --node-cache-filename    save and load other nodes information to this file, improves cold start performance
      --node-cache-lifetime    nodes with last update older than this time (in minutes) will be removed from cache after loading it
      --node-cache-info        show red and cyan 'x' characters in routes to indicate node cache misses and hits respectively

Timeouts:
      --timeout-rebalance      max rebalance session time in minutes
      --timeout-attempt        max attempt time in minutes
      --timeout-info           max general info query time (local channels, node id etc.) in seconds
      --timeout-route          max channel selection and route query time in seconds

Others:
  -s, --stat                   save successful rebalance information to the specified CSV file
  -v, --version                show program version and exit
      --info                   show rebalance information
  -h, --help                   Show this help message

Look in config.json.sample or config.toml.sample for corresponding keys, they're not exactly equivalent. If in doubt, open main.go and look at the var params struct. If defined in both config and CLI, the CLI parameters take priority. Connect, macaroon and tls settings can be omitted if you have a default lnd installation.

Node cache

Enable the cache by setting --node-cache-filename=/path/to/cache.dat (or node_cache_filename config parameter), you're free to choose any path and file name you like. It speeds up printing routes and lowers load on lnd in case you run multiple regolancer instances. If you're not interested in technical details, feel free to skip the following section.

How this cache works

Node cache is only used for printing routes, it contains basic node information such as alias, total capacity, number of channels, features etc. However, getting this information might be slow as every request to lnd is processed sequentially. The first few routes print noticeably slower until more nodes "around" you are queried and cached in RAM. This information shouldn't be very up-to-date (unlike the channel balances, policies etc. which are retrieved on every launch and are only cached for the run time) and nodes themselves broadcast updates not very often. It makes sense to persist this data to disk and load it on every run so that routes are printed almost instantly, and the payment is only attempted after the route is fully printed. It would be good to run a payment attempt and route print in parallel but currently the payment function can dump errors and it would interfere with the route output.

However, there's a gotcha that I learned from other users of regolancer: people run multiple instances of it in parallel, so they might terminate at different times. If all those instances use the same cache file, they will overwrite it and lose information that another instance might have stored before them, or they might start writing at the same time and corrupt it. One way to solve it is to use separate cache files but then each instance would query lnd for the same nodes as other instances. So instead of this I added file locking (using /tmp/regolancer.lock file on Linux and probably %tmpdir%/regolancer.lock on Windows, haven't tested) that allows multiple readers but just one writer and implemented simple cache merging. When it's saved, first we load the existing cache (under a write lock so no one can access it), copy all nodes that are missing in our own cache or have a more recent update time, then save the result replacing the cache file.

There's also the cache expiration parameter (--node-cache-lifetime) set to 1440min/24h by default that lets you skip cached nodes that are older than that. It doesn't affect any actual logic, just that these nodes will be queried again from lnd when they're printed for the first time. Set it to a bigger number if you don't care about the node stat actuality.

Cache is also saved if you interrupt regolancer with Ctrl+C.

Probing

This is an obscure feature that bos uses in rebalances, it relies on protocol error messages. I didn't read the bos source but figured out how to check if the route can process the requested amount without actually making a payment: generate a random payment hash and send it. lnd will refuse to accept it (because there's no corresponding invoice) but the program gets a different error than the usual TEMPORARY_CHANNEL_FAILURE. Then we can do a binary search to estimate the best amount in a few steps. Note, however, that the smallest amount can be 2ⁿ times less than you planned to rebalance (where n is the number of steps during probing). For example, 5 steps and 1,000,000 sats amount mean that you might rebalance at least 1000000/2⁵ = 31250 sats if the probe succeeds. You can override this minimum with --min-amount so that probing begins with this amount instead and either goes up or fails immediately. Another problem is that fees can become too high for smaller amounts because of the base fee that starts dominating the fee structure. It's handled properly, however.

When enabled, probing starts if the payment fails at the second to last channel. The last channel comes to yourself so you know it's guaranteed to accept the specified amount. If all other channels could route this amount, the only unknown one is that second to last. Then we try different amounts until either a good amount is found or we run out of steps. If a good amount is learned the payment is then done along this route and it should succeed. If, for whatever reason, it doesn't (liquidity shifted somewhere unexpectedly) the cycle continues.

Docker Setup

In general its recommanded to run regolancer in a normal environment because it is so easy to install as mentioned above. However if you want to run it in a docker we also provide the Dockerfile so that you can easily get started.

Build the container or pull it:

docker build -t regolancer . or docker pull ziggie1984/regolancer

Now you can use regolancer with your lnd instance:

docker run --rm --add-host=host.docker.internal:host-gateway -it -v /home/lnd:/root/.lnd regolancer --connect host.docker.internal:10009

The above command assumes /home/lnd is your lnd configuration directory. Please adjust as required.

If you want to use a config file either copy the file into the mounted volume (/home/lnd) or mount a separate volume. Then just add the --config /root/.lnd/config.toml parameter to your start command

Note for Umbrel/Umbrel-OS users

docker run --rm --network=umbrel_main_network -it -v /home/umbrel/umbrel/app-data/lightning/data/lnd:/root/.lnd regolancer --connect 10.21.21.9:10009

Optionally you can create an alias in your shell's environment file like so:

alias regolancer="docker run --rm --network=umbrel_main_network -it -v /home/umbrel/umbrel/app-data/lightning/data/lnd:/root/.lnd regolancer --connect 10.21.21.9:10009"

For older versions of Umbrel please use /home/umbrel/umbrel/lnd instead of /home/umbrel/umbrel/app-data/lightning/data/lnd

What's wrong with the other rebalancers

While I liked probing in bos, it has many downsides: gives up quickly on trivial errors, has very rigid channel selection options (all should be chosen manually), no automatic fee calculation, cryptic errors, weird defaults and ineffective design. It can also unbalance another channel, there are no safety belts. It might be okay if you absolutely need one channel to be refilled no matter the cost but if you want your node to be profitable you have to account for every sat.

Rebalance-lnd is much better for automation but it still can't choose multiple source and destination channels and try to send between them. You have to select one source and/or one target, the other side is chosen randomly, often only to discard a lot of routes because of too high fees (this constraint can be specified while querying routes but it isn't). The default route limit is 100 so you either have to increase it or restart the script until it succeeds. I noticed multiple times that it concedes after 20-30 attempts saying there are no more routes but after restart still finds and tries more. It also lacks probing, consumes quite a lot of CPU time sometimes and I personally find Python a big pain to work with.

Why rebalance at all

I'm still a bit torn on this topic. At some points in time I was a fan of rebalancing, then I stopped, now I began again. I guess it all comes with experience. LN is still in its infancy and when the network is widely available and used on daily basis rebalancing won't be needed. But today we have a lot of poorly managed nodes (especially the big ones!) with default minimal fees and more experienced nodes quickly drain this liquidity only to resell it for a higher price. If a node has hundreds or thousands of channels with zero liquidity hints it becomes very hard to balance such channels. It essentially boils down to a bruteforce which is exactly what this program does. It seeks the network for liquidity that's cheaper than your own and moves it to you.

For now some liquidity can be just dead. Even if you set 0/0 on a full channel you see no routing through it. Because it's the opposite direction that everyone wants. So you have to move it manually, getting incoming liquidity to sell for some other outbound liquidity you have. And when you run out of it you need to refill the channels using that dead liquidity. In the future, hopefully, the daily network activity will do this job thanks to circular economy. Today it's not yet the case.

However, there's not much point in rebalancing all the channels. See which are empty for weeks and consider them as candidates. From my experience, you might have a few channels that can be drained very quickly if the fee is too low. They are channels to exchanges and service providers, sometimes other big nodes that consume all liquidity you throw at them. That's your source of income, basically. These channels should be added to exceptions in your config so they're never used as a source, even when they match the percent limit.

How to route better

By all means, use charge-lnd. Your goal is to minimize local forward failures. It can be achieved with fees and/or max HTLC parameter. You can try to move the dead liquidity with 0/0 fee before doing rebalance. You absolutely should discourage routing through empty channels. Best way is to set max_htlc on them so they're automatically discarded during route construction. You can also disable them (it only happens on your end so you'll be able to receive liquidity but not send it) but it hurts your score on various sites so better not to do it. Increase fees or lower max_htlc and you'll be good. You can set multiple brackets with multiple limits like:

• 20% local balance => set max_htlc to 0.1 of channel capacity (so it can process ≈2 payments max or more smaller payments)
• 10% local balance => set max_htlc to 0.01 of channel capacity (small payments can get through but channel won't be drained quickly)
• 1% local balance => set max_htlc to 1 sat essentially disabling it

Same can be done with fees but if you decide to rebalance, watch out: you might spend a lot on rebalancing if your empty channel sets 5000ppm fee but after it gets refilled it switches back to regular 50 or 100ppm. You'll never earn that back. Learn how charge-lnd works and write your own rules!

Goals and future

It's a small weekend project that I did for myself and my own goals. I gladly accept contributions and suggestions though! For now I implemented almost everything I needed, maybe except a couple of timeouts being configurable. But I don't see much need for that as of now. The main goals and motivation for this project were:

• make it reliable and robust so I don't have to babysit it (stop/restart if it hangs, crashes or gives up early)
• make it fast and lightweight, don't stress lnd too much as it all should run on RPi
• provide many settings for tweaking, every node is different but the incentives are the same
• since it's a user-oriented software, make the output pleasant to look at, the important bits should be highlighted and easy to read

Feedback and contact

We have a Matrix room to discuss this program and solve issues, feel free to join #regolancer:matrix.org!

regolancer's Issues

Inappropriate rebalances being selected

I'm currently testing with the config file settings:

econ_ratio: 0.5
lost_profit: true

... and have run the rebalancer with no further parameters specified via command line. Each time, it has selected routes that are inappropriate. For instance, rebalancing a target channel that I currently charge 30ppm with a source currently charging 200ppm.

Also, I've attempted to specify a source channel via command line without any further parameters, hoping regolancer would attempt to find an appropriate rebalance with any possible target channels fitting the liquidity criteria specified in config.json; however, it throws error "No source channels selected." Am I missing something here?

Thanks!

Lost_Profit feature and Lnd QueryRoutes seem not to work

Thanks for this new feature. Just tested it, but it seems that as soon as the value is negative lnd throws it away and uses the default value of 5%:

2022/10/01 15:42:24 Attempt #1, amount: 100000 (max fee: -2)
Total fee: 21

ROUTE X 

2022/10/01 15:42:28 Success! Paid 21 in fees

Seems like a check if its negative needs to be done by regolancer itself ?

[enhancement-request] automated rebalancing based on forwards

Hi,

This seems like quite an interesting project. I use lntop already and notice rkfg is a frequent contribute there. I am currently using jet to do some automated rebalancing, but I am always looking for ways to improve the process.

The main feature missing for me in regolancer is "forward based rebalancing".

Say my node completes a forward as follows:

Node A -> Node B
ppm earned 1000
amount forwarded 100,000 sats

This automation, after detecting the forward, would try to quickly move the funds in the opposite direction, for less than we earned.

Node B -> Node A
ppm limit 1000
amount target: 100,000 sats

It would also be nice to set a percentage target for the ppm limit. So I could say "spend up to 80%" of the earnings in order to complete this rebalance.

As a bonus feature, it could be useful to set local and remote balance thresholds on when to trigger the automatic rebalancer.

Cheers,
The Wall

Take "lost profits" from source channels into consideration for picking a route

Rebalance-lnd's biggest strength coming from the economical viable computation whether a source is the right source or not.
I just tried a rebalance with --pfrom and --pto, and it picked a rather expensive source, to pull a certainly cheaper target.

Aware that I can exclude the channel or the node, but is it feasible to implement the profitability computation to mark sources only if the cost + lost profit is < than the possible profit of a target?

[Feature] Show all parameters and selected channels

Proposed by some noderunners it would be nice to have a feature to show all channels which would be considered when using specific parameters of regolancer.

For example show/record all potential source/target channels which would be flagged by using --pfrom 15 --pto 30.

A first idea was to use --list to show exactly that. One could also think of also providing a nice graphical output to the terminal (including channel gauges) in accordance with lntop.

Feature Proposal: Running until all channels are rebalanced

At the moment from my experience the program completes after only 1 successful rebalance attempt. This means I have to run it again and again until the program cannot find any more at least 1 source and 1 destination channel based on my filters.

Could be possible to automate this manual proceduce or it was designed like this by choice?

Thank you for the help

Feature request: Limitation of outgoing htlcs per channel

I am running regolancer simultaneously with 6 workers.
Sometimes a channel or the connection to the peer gets buggy and the different regolancer sessions do not limit the outgoing amount of htlcs so it is accumulating the payment htlcs on the buggy channel. See example: Nordicrails with 7 pending payment htlcs.

Especially in high-fee onchain environment a FC can get very expensive.
So it would be great to have a general check for stuck htlcs (e.g. allowing a configurable maximum of 2-3 stuck payments) on the outgoing channel before establishing new payments htlcs.

Support Inbound Fees when LND 18 is released.

See for reference:

1. lightningnetwork/lnd#6703
   and
2. lightningnetwork/lnd#6934

Maybe we also need to wait for the buildroute command as well:

3. lightningnetwork/lnd#7060

Failing rapid rebalance

Hi,

The rapid-rebalance attemps from regolancer seem to fail often with this error code: "Error building route: rpc error: code = Unknown desc = no matching outgoing channel available for node 0 ()".
What is going wrong here?

exclude nodes , weird behavior

hey,
super great script !!! but, i think i have found a weird behavior with exclude_nodes , with this configuration, it says "no route", but with the second version using exclude_channels behavior is correct.

"fee_limit_ppm"= 500
"amount"= 10000
"min_amount"= 1000
"probe_steps"= 5
"pfrom"= 20
"pto"= 80
"stat"= "stats.csv"
 "exclude_nodes"= [
     "033d8656219478701227199cbd6f670335c8d408a92ae88b962c49d4dc0e83e025", # bfx-lnd0
     "02cc125c2770dd293f56b50841c8d847276efd00634d48e947c9b83125315d8f", # bfx-lnd1
     "021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d", # loop
     "024bfaf0cabe7f874fd33ebf7c6f4e5385971fc504ef3f492432e9e3ec77e1b5cf" # deezy
]
"to" = [
  831055968312229888
]
"from" = [
    
]
lost_profit = true
allow_unbalance_to = true
allow_unbalance_from = true

not working,

but this is working :

"fee_limit_ppm"= 500
"amount"= 10000
"min_amount"= 1000
"probe_steps"= 5
"pfrom"= 20 
"pto"= 80
"stat"= "stats.csv"
"exclude_channels"= [
        796000239066611713, #bfx0
        832584289538146304, # bfx0
        831646406136823809, #bfx1
        832612876845056000,  #deezy
        833668408015519745 #deezy
]
"to" = [
  831055968312229888
]
"from" = [
    
]
lost_profit = true
allow_unbalance_to = true
allow_unbalance_from = true

Channel candidate selection issue in getChannelCandidates

I just noticed there is an issue with picking source channels if the intended source channel is in the exclude_channels_in list.

If I specify --from xyz and --exclude-channel-in xyz the xyz channel will be skipped completely. The reason is the continue in the if _, ok := r.excludeIn[c.ChanId]; ok check in getChannelCandidates (line 50 atm). It will skip all the code underneath it and not add the channel to the from list.

I also think that piece of code should be brought up before the balance check since it's not needed to check the balance if the channel is excluded.

Have `econ-ratio-max-ppm ` account for source channel fee rate as well, when `--lost-profit` is enables

Currently, econ ratio is first processed and then adjusted with lost profit, and then, if econratiomaxppm exists, the resulting value will be furter limited:

regolancer/routes.go

Line 73 in fb578ad

if params.EconRatioMaxPPM != 0 && int64(float64(feeMsat)/float64(amtMsat)*1e6) > params.EconRatioMaxPPM {

This means that when econratiomaxppm is lower than econratio-lostprofit, it will be used 100% without lost profit.

Wouldn't it be more appropriate to move up the check of the econratiomaxppm option, and after that apply the lostprofit, whether it is over econratio or a lower maxppm?

[Feature Request] Check for max pending HTLC or latest HTLC timeout of a channel

Its very important to not fill a channel with HTLCs when the channel will shortly be resolved onchain, therefore I propose a check which either filters for the HTLC count on a channel or fetches the shortest to expiry absolute timelock and prevents more HTLC on a channel until the absolute timelock is greater than blockheight + safetyamount (20 blocks for example) again.

I would propose some good default values and a cmd flag with which they can be modified

Deprecating allow-unbalance

Looks like it's more confusing than useful. Should we maybe allow it by default (i.e. allow any channel to go below/above 50%) and show a notice that it doesn't have any effect if specified? Looks like in most use cases the operator doesn't care if the source channel goes too much down or the target goes up and the channels that are active in both directions don't need any rebalances at all and can be excluded. My (possibly wrong) reasoning was that channel should have liquidity in both directions to be useful. But in reality most channels favor only one direction and you need to rebalance for the opposite so it makes sense to remove any limitations for that.

Thoughts?

Relative amounts cannot be included in the json config

I'm trying to include --rel-amount-to and --rel-amount-from in my config.json but both values are not recognized. Both as they are written here and using underscore instead of dashes.

[feature] Learning about failures between channels

When using regolancer, we fetch all possible routes a specific channel combination has before trying all routes regarding this channel-combination. Problem with this approach is that our system does not learn about the channel failure which would give us more information and discard maybe routes which have the same channels which failed before. Hence making regolancer more efficient.
Do you know whether SendPaymentV2 would solve this kind of problems because we let lnd do the job, gaining a better overview of the channel graph and we would just give lnd the outgoing channel and the destination ? Otherwise we could build up those information locally, what do you think?

regolancer.lock not deleted

I am experimenting with multiple reglancer sessions. I have realized that after a full run the regolancer.lock still exists. I guess that's not the correct behaviour.

Return value on failure

Hi, is there a specific error code returned when regolancer fails to do a rebalance? I try to setup a simple loop script using "while [ $? -eq 0 ]", but on failure it also seems to repeat. So in case of no route for example it keeps spamming no route and saving it to the cache file.

[Request] Add absoluteto (ato) and absolutefrom (afrom)

I'm more interested in the absolute balances from my channels, rather than relative balances. Can you please add this option?

Fee-Limit-PPM also for econ-handle

I am having the usecase that I am increasing the fee-ppm for channels which are drained under a specific amount to very high values. Now it happens when selecting econ_ratio (which I want) that rebalance-fees are very high. Should we also include the possibility of a ppm limit when using econ_ratio?

Question about --lost-profit

I have a question about the description of the lost-profi option

-l, --lost-profit            also consider the outbound channel fees when looking for profitable routes so that outbound_fee+inbound_fee < route_fee

I think you mean the lost-profit on the outgoing channel as outbound_fee in the inequality. But hasn't it to be route_fee + outbound_fee < inbound_fee or more exactly route_fee + outbound_fee < inbound_fee * econ_ratio? Equivalent would be route_fee < inbound_fee - outbound_fee or route_fee < inbound_fee * econ_ratio - outbound_fee. Imho the last one is implemented.

"Successful" Route with no third party?

Any idea what is going on behind the scenes here?

I've seen a few rebalance attempts come back as successful, but that did not involve a third peer in the route. See output below in which I attempt to rebalance out of a channel at fixed ppm limit. Bos telegram then reports "Rebalanced 2,000,000 out zero fee routing > zero fee routing. Fee 0"

$ regolancer -f config.json --allow-unbalance-to --allow-unbalance-from --from=828274203871412225 --fee-limit-ppm=15 --amount=2000000

2022/10/07 06:41:26 Attempt #1, amount: 561670 (max fee: 8)
Total fee: 0.0
828274203871412225        [zero fee routing | CLN|1408ch|84.08,094,738sat|038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5]
801702306459746305 0      [TacoBazooka|96ch|1.12,200,837sat|034718d8f0a79420104247abd6c414b23dc211fe1c74f4da69a7c7ec2483efb402]
816773312315719681 0      [Milky*Cilia|229ch|24.98,388,655sat|022a03c83e94ab037a64dd71e54f1796db185f21b1d88ceea5486a274ec257e995]

2022/10/07 06:41:33 TEMPORARY_CHANNEL_FAILURE TacoBazooka ⇒ Milky*Cilia

2022/10/07 06:41:33 Attempt #2, amount: 934919 (max fee: 14)
Total fee: 12
828274203871412225        [zero fee routing | CLN|1408ch|84.08,094,738sat|038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5]
818130109649911809 0      [036947a18a1eace8a5a5|6ch|23,000,000sat|036947a18a1eace8a5a559e85b8bb6324cbd09b8865824f5965a76af9b58f398e3]
805196554390798337 1934   [WalletOfSatoshi.com|2446ch|109.56,097,414sat|035e4ff418fc8b5554c5d9eea66396c227bd429a3251c8cbc711002ba215bfc226]
819792571175731201 9349   [LN.SIDESHIFT.AI|177ch|9.87,761,722sat|02459b759a62bc3ebfe98a320da237944cc4f35456384bd8fdefa7d0340c75f46f]
823352789853601801 935    [Milky*Cilia|229ch|24.98,388,655sat|022a03c83e94ab037a64dd71e54f1796db185f21b1d88ceea5486a274ec257e995]

2022/10/07 06:41:38 TEMPORARY_CHANNEL_FAILURE 036947a18a1eace8a5a5 ⇒ WalletOfSatoshi.com

2022/10/07 06:41:38 Attempt #3, amount: 204364 (max fee: 3)
Total fee: 2
828274203871412225        [zero fee routing | CLN|1408ch|84.08,094,738sat|038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5]
813581429992325121 0      [03cc1d0932bb99b0697f|49ch|1.05,632,995sat|03cc1d0932bb99b0697f5b5e5961b83ab7fd66f1efc4c9f5c7bad66c1bcbe78f02]
802760036711137281 1204   [WalletOfSatoshi.com|2446ch|109.56,097,414sat|035e4ff418fc8b5554c5d9eea66396c227bd429a3251c8cbc711002ba215bfc226]
804066256423682049 0      [THEwhiteRABB!T|19ch|2,320,000sat|03068febce690ea2d5de0d4d5830f74f4afc81bd677da2a194486ca44d6f028920]
806167423163564032 1204   [Milky*Cilia|229ch|24.98,388,655sat|022a03c83e94ab037a64dd71e54f1796db185f21b1d88ceea5486a274ec257e995]

2022/10/07 06:41:49 TEMPORARY_CHANNEL_FAILURE 03cc1d0932bb99b0697f ⇒ WalletOfSatoshi.com

2022/10/07 06:41:50 Attempt #4, amount: 204364 (max fee: 3)
Total fee: 1
828274203871412225        [zero fee routing | CLN|1408ch|84.08,094,738sat|038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5]
828119172850122753 0      [Einundzwanzig|154ch|3.17,075,456sat|03a09f56bba3d2c200cc55eda2f1f069564a97c1fb74345e1560e2868a8ab3d7d0]
804029972618215425 204    [THEwhiteRABB!T|19ch|2,320,000sat|03068febce690ea2d5de0d4d5830f74f4afc81bd677da2a194486ca44d6f028920]
806167423163564032 1204   [Milky*Cilia|229ch|24.98,388,655sat|022a03c83e94ab037a64dd71e54f1796db185f21b1d88ceea5486a274ec257e995]

2022/10/07 06:41:54 TEMPORARY_CHANNEL_FAILURE Einundzwanzig ⇒ THEwhiteRABB!T
Probing route...
2022/10/07 06:41:58 100000 is too much, lowering amount to 100000, 4 steps left
2022/10/07 06:41:58 Best amount is unknown

2022/10/07 06:42:02 Attempt #5, amount: 2000000 (max fee: 30)
Total fee: 0.0
828274203871412225        [zero fee routing | CLN|1408ch|84.08,094,738sat|038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5]
828274203871412225 0      [Milky*Cilia|229ch|24.98,388,655sat|022a03c83e94ab037a64dd71e54f1796db185f21b1d88ceea5486a274ec257e995]

2022/10/07 06:42:06 Success! Paid 0.0 in fees

Add a parameter to substitute -a (Amount) with a relative target

When rebalancing, an absolute target to rebalance isn't always appropriate, especially when using a range of --pto.
Is it possible to add a percentage target, eg --per=0.7, to enable a range of targets to be filled up and the routine not stopping, until a percentage of 70% inbound is reached?

It's relevant for a larger node-runner, who has like 10 or more channels with < 10% outbound.
Ideally the rebalancer is running, until it hits a desired target with all channels market as target, with desired outbound at X %

Add max ppm in addition to econ-ratio

I would like to push out of a specific source channel to all my other channels (except the ones I've excluded) at max 20 ppm. I used to do this with rebalance-lnd by setting the --reckless and --fee-ppm-limit flags. Could you add something like that fee-ppm-limit in regolancer too?

Feature request: Avoid channels below fee

Hello,

Is it possible to add a flag called --exclude-below-fee that takes an argument in msat?

Usage:

--exclude-below-fee 1000

Using this flag and value would cause regolancer to avoid any channel with a fee lower than 1000 msat.

The problem that this aims to solve is that there are many channels charging very low fees that also have no available liquidity. There is a lot of time spent trying these routes, and the likelihood of success is very low in my experience.

This is an enhancement request that I think will prove to be useful.

Thanks,
The Wall

Allow more than one "from" channel

I want to rebalance from a list of channels to all other channels.

Right now I have to define every channel I don't want to send out of in the "exclude_channels_out" parameter.
It would be much easier to just be able to define more than one "from" channels.

Accelerator for rapid-rebalance

The rapid-rebalance is great. But it has the "disadvantage" that it can leads to an huge number of payments if there is a lot to rebalance and the amount is very low.

I'd like to propose an accelerator. First rebalance is with the amount given by the user. The first rapid-rebalance is with the double amount and with each following step the amount doubles, e.g. 20k, 40k, ..., 20k * 2^i.
If one rapid-rebalance (i>0) fails go back to i=0 and start the acceleration sequence again. Stop the whole rebalance if a rebalance with i=0 fails.

Edit:
Some thoughts how you can decrease the number of payments even more.
After the first rapid-rebalance sequence as proposed you have rebalanced $amount \cdot (2^{i+1}-1)$ overall. Now you can try rebalancing $amount \cdot 2^{i}$ again. Then go backward to $amount \cdot 2^{i-1}$, independently whether the trial before failed or succeeded. Then take $amount \cdot 2^{i-2}$. etc until you have reached the orginal amount again.

Example: There is a theorethical amount of 5000k which you could rebalance on a route. If you take an amount of 20k you have to repeat 250 times with current rapid-rebalancing. With the acceleration you rebalance 20k, ...., 1280k (7 steps). 2560k fails, because you have already rebalanced 2540k and only 2460k are free. Then test 20k, ...., 1280k again. Except 80k all will succeed. Overall you had 15 payment trials on this route.

add parameter to exclude channels by age

Hi,

This is an enhancement request to add a flag to exclude channels by their age.

Here is one possible scenario that it will help with:

An unsolicited channel is opened, and the default ppm in lnd.conf is high; like 2000ppm. This new channel will be picked up by a currently running rebalance operation using --pfrom. Even if you use profitability flags like like -r and -l, it is likely that this new channel will be used as a source, and you will rebalance at a loss.

If I could also set --exclude-channel-age 7 ; any channel that is newer than 7 days will be excluded. This gives time to adjust the rebalancer or add manually channel excludes.

Thanks!