From robban at robtex.com Tue Feb 6 19:16:02 2018 From: robban at robtex.com (Robert Olsson) Date: Tue, 6 Feb 2018 21:16:02 +0200 Subject: [Lightning-dev] channel rebalancing support kind of exists already? In-Reply-To: <64377caf.AEAAScyO3BEAAAAAAAAAAAHPbO0AAABGqAQAAAAAAAotPgBaeeOY@mailjet.com> References: <64377caf.AEAAScyO3BEAAAAAAAAAAAHPbO0AAABGqAQAAAAAAAotPgBaeeOY@mailjet.com> Message-ID: Hi Aleksej, Yes i was talking about rebalancing without blockchains. and that there is a need for rebalancing, since things routed thru you can also affect balances an a surprising fashion. A function to avoid routing too much thru your channels would be nice too. Consider a scenario where your employer opens a channel to you, and send your salary. You can then go shopping and use the channel via you employer, but after a while you want some more capacity, or less fees, or redundancy in case your employers node is offline. So you open a new one directly to walmart with a tx because you plan to go there after work, and go there often. Now it turns out your employer also buys stuff from walmart, so they pay them via your channel to walmart and uses up most of it. So when you go to walmart to shop, you notice your brand new channel with them is already used up so you will have to route it back thru your employer, however they are of course currently doing maintenance on their node. Your redundancy is gone. And if they were up, your fee saving idea with a direct walmart channel would have been gone. So, I think a function to "refuse routing over this channel if it would result in less than X% of capacity" and "automatically balance this channel to have at least X% of capacity" would be very useful features, and i think they don't have to be extremely hard to implement over current protocol. Best regards Robert Olsson On Tue, Feb 6, 2018 at 7:19 PM, Aleksej wrote: > Hi > > Yeah, you can always refund your channels thorugh other channels. > I don't think however that it would be usually necessary to balance funds > on the channel to be equal. > I always assumed that a typical user would have perhaps one channel where > he receives funds (employer) and others for spending (stores). > In order to refund them, he would simply spend funds thorugh channels that > are more unbalanced in direction where the user is "owned" coins. > And of course, the other way around, employer would be able to pay the > employee throgh channels he has with stores where he owns the money. > > In conclusion, I don't think rebalnacing would need to be a sperate > transaction. > This could simply be done automatically when the user sends or receives > his usual transactions. > I am not sure about all the diffuclties regarding routing in LN. Hopefully > all of this can be done safely, reliably and quickly. > > Best regards, > Aleksej > > On Tue, 2018-02-06 at 18:53 +0200, Robert Olsson wrote: > > 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 listLightning-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: