[Lightning-dev] channel rebalancing support kind of exists already?

[Corné Plooy]

Hi,

Amiko Pay had this: on an invoice, you could (optionally) specify
through which peer you wanted to be paid; on a payment, you could
(optionally) specify through which peer you wanted to pay. In fact, if
you didn't do this, a payment-to-self would not result in any channel
actions, since the most efficient route to yourself makes zero hops.
There was some weird edge case in this if you had a channel to
yourself(*) and specified it in both the invoice and the payment: the
route would actually be forced to go multiple times through the same
channel.

Routing in Lightning is a bit different than in Amiko Pay, and I never
attempted to adapt Amiko Pay to the Lightning protocol standard. I do
think that Lightning offers *better* possibilities for channel
re-balancing, since it offers source routing: the source can explicitly
specify the entire route. If any channels offer negative fee rates to
have them re-balanced, you might even make money by rebalancing other
peoples' channels.

I'm not sure when channel re-balancing would be useful: if you are able
to pay through the B-A-others-C-B route and through the B-C-anyone
route, then certainly B-A-others-C-anyone would work as well?

Maybe to reduce risk that some channels on the 'others' path might be
saturated at inconvenient moments? If Bob receives monthly salary from
Alice and regularly wants to buy things from Carol, he'd probably want
to transfer his funds from the A-B channel as soon as possible to the
B-C channel. Alternatively, he could speculate on when fees on the
OTHERS route would be optimal to make the transfer.

Another use case could be privacy protection: if Alice is an employer,
she probably knows Bob's identity; Bob probably doesn't want her to know
details about his spending behavior as well. Bob-Carol could be a
pseudonymous contact on the TOR network. On receiving salary from Alice,
Bob would immediately transfer it to the B-C link, and perform
individual payments from there.

CJP

(*) not very useful in practice, but certainly useful for testing.
Besides, *some* user is going to try that sooner or later, so you have
to be robust against it.


Op 06-02-18 om 17:53 schreef Robert Olsson:
> Hello
>
> Let's say Bob opens a channel to Alice for 2BTC
> Carol then opens a channel to Bob for 2BTC.
> Alice and Carol are already connected to Others (and/or eachother even)
> The network and channel balances will look like this:
>
> Alice 0--2 Bob 0--2 Carol
>   |                   |
>   +----- OTHERS ------+ 
>
> Bob for some reason wants the channels to be balanced, so he has some
> better redundancy and it looks better.
>
> So hypothetically Bob solves this by paying himself an invoice of 1BTC
> and making sure the route goes out thru Alice and comes back via
> Carol. Bob pays fees so he isn't ashamed if it disturbs the other
> balances in the network. Should he care?
>  
> Alice 1--1 Bob 1--1 Carol
>   |                   |
>   +----- OTHERS ------+ 
>
> Now Bob has two nice balanced channels, meaning he has better
> connectivity in both directions.
>
> Doesn't the protocol already support that kind of solutions, and all
> we need is a function in the CLI allowing Bob to pay to himself, and
> specify which two channels he would like to balance?
>
> Maybe even make it automatically balance.
>
> Is this a good idea of something to support, and/or Is there a risk
> the entire network will start doing this and it will start oscillating?
>
> Best regards
> Robert Olsson
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev