Running clboss in a "low cost" mode

[sj-fisher]

Is there currently any support for running clboss in a "low cost" mode?

I have a node which I use to make and receive fairly small and infrequent payments over lightning. I would like to run clboss on this node in order to benefit from:

• having the channel fees automatically managed
• having the success_per_* statistics maintained for each channel
• having candidate nodes for new channels evaluated

I am not trying to make a profit from routing or to help the network by operating a routing node at a loss, so I do not want clboss to automatically do anything which costs money:

• automatic channel opening
• rebalancing via Boltz
• rebalancing via payments to self
• automatic channel closing (which can already be disabled)

It would be nice to have the ability to manually re-enable those features temporarily if I decide the node would benefit from them.

My current half-baked thinking is that the way to do this would be by adding a handful of options/new behaviors to clboss which might be individually useful, such as:

• only allow automatic channel opening if explicitly enabled, and for a time-limited period only
• only allow rebalancing via Boltz if explicitly enabled, and for a time-limited period only
• only allow rebalancing via payments to self if explicitly enabled, and for a time-limited period only

Combining these would then effectively provide a variety of "economy modes" for clboss with an emphasis on lowering costs in return for the node being less reliable and hands-off.

Noting the obvious pattern in the ideas above and that you can already do the opposite with "noticing on-chain funds" - you can temporarily disable this for a set period - I wonder if the thing to do here would be to generalize that pattern. In other words, add some generic way to configure a clboss feature to be on or off by default and to have an ability to temporarily invert that setting for a time-limited period.

I am interested in doing some implementation work to support this, if it isn't already a thing. I've opened this issue before I start hacking to see if anyone has any thoughts. Is this even a sensible thing to want? Is there an alternative automated Core Lightning node manager which suits these goals better than clboss? Is there a better way to modify clboss to achieve this goal instead of the approach I sketched out above?

[ksedgwic]

Wow, I just added #201 yesterday! I think it's mostly the same sentiment ...

Is this even a sensible thing to want?

Yes, this seems very sensible.

[ksedgwic]

One tricky part is figuring out how the various CLBOSS modules interact. For example many of the features use the EarningsTracker so we'll need to ensure that disabling feature A doesn't impede feature B ...

I've started to make diagrams to improve my own understanding:
https://github.com/ksedgwic/clboss/blob/2024-05-diagrams/docs/rebalancing.md

I'm planning on diagramming the other "feature groups" as well in my spare time.

[ksedgwic]

@sj-fisher Which features/actions (which are on by default) would be the most useful to disable? This might be a good starting point for a plan ...

[ksedgwic]

I think we can cleanly disable channel opening by telling CLBOSS to ignore the onchain funds which is already supported. Since disabling closing is also supported the remaining items from your list are:

• channel balancing (circular)
• offchain-to-onchain swap (Boltz)

Maybe these are a good starting point ...

[sj-fisher]

Thanks, I somehow managed to miss #201 - sorry about that. I guess I was too focused on the "low cost" angle when initially searching and as I kept rewriting my original issue as I thought it through it grew more similar to #201 but I'd forgotten about it by then.

I haven't looked at the code myself yet but your idea of diagramming the data flows seems a good one.

I think the items you mention from my list are a good starting point.

I would guess the Boltz swap can be disabled relatively safely, since Boltz could go down indefinitely anyway even if we'd like to use their service so we shouldn't rely on it for anything else to work.

Without having looked at the code I suspect circular balancing may be a bit trickier, since it's possible that one part of clboss will ask for this to happen, it won't happen because it's been disabled and that will be interpreted as an unreliable peer somewhere in the path. It may well not be a problem, but if there is going to be a problem with these initial changes, I suspect this is the most likely place for one to crop up.

I would ideally like to be able to disable (e.g.) channel opening by saying "don't do this, except when I allow you explicitly for the next n hours" rather than having to set "don't do this for the next infinity hours" to disable it, needing to set "allow this" when I want to enable it and needing to remember to set back to "disable for infinity hours" manually later on. So (just by way of example) instead of clboss-ignore-onchain=n (hours) and clboss-notice-onchain to revert before the n hours are up, we'd have something like cboss-monitor-onchain={true,false} and clboss-monitor-onchain-invert=n (hours). I don't like those names very much, but I hope this gets the idea across.

[sj-fisher]

FWIW I am working on a prototype implementation of this.

[sj-fisher]

I've implemented a prototype of this at https://github.com/sj-fisher/clboss/tree/low-cost-v1. Feedback would be appreciated!

This has been lightly tested on signet and nothing more. Please be very cautious if using this on mainnet!

Overview

This adds three new boolean options:

• clboss-auto-open-channels - is clboss allowed to open channels?
• clboss-auto-swap - is clboss allowed to perform offchain-to-onchain swaps?
• clboss-circular-rebalance - is clboss allowed to perform circular rebalancing?

The new options can be specified via config file entries, e.g.

important-plugin=/path/to/clboss
clboss-auto-open-channels=false

and can also be controlled via lightning-cli, e.g.:

$ lightning-cli clboss-auto-open-channels false

If present, config file entries are applied on startup, overriding any changes made earlier using lightning-cli commands. Otherwise, changes made with lightning-cli are persisted in the database across restarts. This feels a bit over-complex, but it's also the most flexible approach.

If nothing is ever specified, all three default to "true" for backwards compatibility.

Each of the options can also be temporarily set using lightning-cli, e.g.:

$ lightning-cli clboss-temporarily-auto-open-channels true 3

will temporarily allow auto-opening of channels for 3 hours. If this command uses the same boolean value as the base state, it is a no-op.

A temporary setting can be removed before it times out by using the non-temporary form of the command. For example, to cancel the previous temporary permission to auto-open channels:

$ lightning-cli clboss-auto-open-channels false

You can see the current state using:

$ lightning-cli clboss-status

Possible problems

Overlap between auto-open-channels and ignore-onchain

The new auto-open-channels/temporarily-auto-open-channels commands have a lot of overlap with the existing notice/ignore-onchain commands. They are not quite the same:

• auto-open-channels can default to "false" and be temporarily set to "true", whereas ignore-onchain is always temporary and the base state is always "notice"
• they are checked in different places in the code (ignore-onchain in OnchainFundsAnnouncer::on_block(), auto-open-channels in ChannelCreationDecider::Impl::run())

It would obviously be possible to check in the same places in the code if desired. I do like the ability to have "default false", which is why I added this in the first place. I think there is a theoretical difference between the two which doesn't apply at the moment - if (for example) we had support for advertising our willingness to dual-fund channels, ignore-onchain should probably prevent that, whereas "auto-open-channels false" would not.

I'm reluctant to break backwards compatibility by removing the notice/ignore-onchain options completely, but they could be handled as special-case syntax for the new auto-open-channels behavior.

Implementation notes

Most of the new code is in Boss/ModG/TimedBoolean.hpp, which adds a TimedBoolean helper class which deals with all the messy user interface and state maintenance for "timed booleans", i.e. booleans which have a base state and which can be set to a different state for a fixed period of time. This has its origins in the existing OnchainFundsIgnorer code.

Three new controllers (AutoOpenController, AutoSwapController and CircularRebalanceController, all in Boss/Mod) use TimedBoolean internally and expose a pair of Request/Response messages to allow their current state to be queried.

Logic has then been added (in ChannelCreationDecider, NodeBalanceSwapper and EarningsRebalancer) to disable the existing behavior where the relevant timed boolean is currently false.

[ksedgwic]

@sj-fisher apologies for the delay, starting to look ...

Can you make a PR from your branch? It's fine to mark it Draft if you are not ready to have it merged. The PR comments and approvals are a well understood process and it should streamline collecting comments etc.

[sj-fisher]

Thanks Ken! I didn't know draft pull requests were a thing. I've opened one now and copied my initial comments from this issue into that pull request to keep everything together.