The holy grail for hubs is self-auto-balancing channels. The protocol would run rebalance command with specific exit and entrance channels
auto-balance Settings that each person chooses:
Min-Chan capacity (so you're not trying to balance a .00001 channel) default .01BTC
MaxFee (ensures you don't pay more than you'd make) default 0
Max-unbalance (what's the max % that can be on either side... like 90% and must be above 75%) default 90
Then, each time there is a transaction through, to, or from a channel, it checks to see if it's above max-unbalanced, then picks another another channel unbalanced in the other direction, and sends funds out one and in through the other.
By default, it'd only autobalance if the transaction fees to do so are zero.
This is not the same as https://github.com/lightningnetwork/lnd/issues/1603, it's the next evolutionary step.
The holy grail for hubs is self-auto-balancing channels.
Not necessarily. It's also a very challenging feature to implement as one needs to ensure that (as its a control system) a node doesn't shift the network of those doing auto rebalancing into a negative feedback cycle that results in non-conversion (to a steady state) for all nodes.
Nah, it's trivial. Assign it to me... I'll have it ready in a week. ^_^
Because one couldn't use already balanced channels of another node directly connected, you'd eventually reach an equilibrium of all nodes with all balanced channels.
And using maxfee < fees you generate on all nodes, this prevents a cycle, as each subsequent balancing node would have to have lower fees than the previous. This can be hard-coded -> if Maxfee < Outgoing channel fee Then use OutgoingChanneFee -1 as max. [Or max fee of zero, if outgoing channel fee is zero]
Though... there would need to be some message passing, to prevent BOTH nodes on either side of an unbalanced channel from trying to "balance" it.
Because one couldn't use already balanced channels of another node directly connected, you'd eventually reach an equilibrium of all nodes with all balanced channels
I patiently await your proof. Are you familiar with control systems? Also don't assume that rebalancing policy is homogenous within the network.
I'm working on external balancing tool using gRPC. I believe such functionality should not be a part of the node itself as there're many strategies how to do this.
Currently I target at very basic semi-manual functionality. I'll publish it when ready.
There's no legitimate reason for disallowing an optional feature from being hard-coded in.
It's off by default. One could always leave the basic internal one off, and opt in for your code that does 'advanced strategies'.
I tend to agree with @slush0 here. Our role here is to provide the tool to allow node operators to do automated channel level management like rebalancing via the RPC interface. The current SendToRoute RPC is a start, and we'll be improving the RPC to make it easier to user in the near future.
There's no legitimate reason for disallowing an optional feature from being hard-coded in.
mo code, mo problems ;)
Most helpful comment
I'm working on external balancing tool using gRPC. I believe such functionality should not be a part of the node itself as there're many strategies how to do this.
Currently I target at very basic semi-manual functionality. I'll publish it when ready.