From corne at bitonic.nl Wed Feb 7 10:00:09 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Wed, 7 Feb 2018 11:00:09 +0100 Subject: [Lightning-dev] channel rebalancing support kind of exists already? In-Reply-To: References: Message-ID: 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