--- Log opened Thu Apr 25 00:00:54 2019 01:37 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #c-lightning 02:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 03:03 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 03:13 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 04:01 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving] 04:36 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds] 04:38 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 245 seconds] 04:38 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #c-lightning 04:45 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning 05:35 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 05:36 -!- booyah [~bb@193.25.1.157] has joined #c-lightning 05:42 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds] 05:42 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #c-lightning 05:42 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 246 seconds] 05:51 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning 06:24 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #c-lightning 06:26 <@cdecker> k3tan: your node is telling you that your peers are unreachable (WIRE_TEMPORARY_CHANNEL_FAILURE) 06:26 <@cdecker> Are they connected? (`listpeers` is your friend) 06:29 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #c-lightning 07:15 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds] 07:16 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #c-lightning 07:16 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 255 seconds] 07:22 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning 07:30 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving] 07:34 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 07:43 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 07:43 < m-schmoock> cdecker: niftynei: I was fiddling around with rebalancing channels. It seemed a bit complicated, so what do you think about this improvements: https://github.com/lightningd/plugins/pull/11 07:49 < m-schmoock> Also when rebalancing fails along the route, we could try to rebalance the same amount with several smaller payments, as its often the case that a specific channel along the route is too imbalanced... right? 07:49 < m-schmoock> Or do clients see/check for the current channel state somehow when constructing the route? 08:10 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds] 08:11 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #c-lightning 08:12 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 246 seconds] 08:12 <@cdecker> m-schmoock: nodes can only see the current balances of their own channels, but attempting multiple smaller rebalancings over different paths may be useful 08:18 < m-schmoock> is that one reason why LN routing fails occasionally? If yes the problem gets exponetionally bigger the longer the route. 08:21 < m-schmoock> Is that currently addressed on the protocol/bolt level? If not, how will balanced channels be incentivized? 08:24 < m-schmoock> One option a client has is to prefer the biggest channels along the route to minimize the problem. 08:26 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning 09:03 < nibbier> so an optimal channel has the same amount of sat on both sides? 09:20 <@cdecker> nibbier: hard to say what is optimal without knowing much else. For example if you plan to only send or receive payments most of the time you'd prefer an imbalanced channel. If you plan on routing payments, then balanced is likely what you are trying to get 09:20 <@cdecker> m-schmoock: yes, the probability that some channel along a route has insufficient capacity grows with the route length 09:21 < nibbier> ok, so the other network members won't make any assumptions about balances? 09:21 <@cdecker> m-schmoock: there's little we can do without flooding the network with high-frequency updates and leaking privacy by doing so 09:22 <@cdecker> nibbier: since you and your peer are the only parties that can / should be able to see the current balance the other nodes will just go by trial-and-error trying to route a payment and retrying if it fails 09:23 < m-schmoock> cdecker: we could start a probe network that does little probes from time to time to figure out the qualitiy of the topology (channel balance, responsivness, ...) a client could use that (third party informatino) to build better routes :D 09:23 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #c-lightning 09:23 < m-schmoock> just like some guys did decades ago figuring out ISP internals by having a global network of udp probes 09:25 <@cdecker> Something like this? https://github.com/lightningd/plugins/tree/master/probe 09:27 <@cdecker> :-) 10:23 < m-schmoock> :D lol 10:23 < m-schmoock> the answer was a click away 10:26 < m-schmoock> So currently to balance channels fees can be used. but also not all the nodes will be doing this. also, as you said, some nodes have other requirements (i.e. iconming capacity for selling points, or balance for routers). this contradicts, as a client can not know this different and will try to route through i.e. bitrefills node wich may not be intended, but the clients cant know 10:28 <@cdecker> I think mostly users wont try to actively rebalance unless channels get really skewed anyway (and even less so once we have multi-path routing), when you want to send a payment either it works (yay) or it doesnt and you retry 10:28 <@cdecker> No need to keep channels perfectly balanced at all times (might be very counterproductive to try that) 12:01 -!- rotarydialer [~rotarydia@unaffiliated/rotarydialer] has quit [Ping timeout: 246 seconds] 12:03 -!- rotarydialer [~rotarydia@unaffiliated/rotarydialer] has joined #c-lightning 12:59 < fiatjaf> it's very annoying when you have 500 sat in your side of the channel then the other side closes it 12:59 < fiatjaf> there's probably no solution to that 13:31 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 258 seconds] 13:39 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 13:47 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 14:22 < nibbier> thanks cdecker 15:56 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 16:06 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 17:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 18:21 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning 19:17 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 19:54 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 19:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Disconnected by services] 19:54 -!- justan0theruser is now known as justanotheruser 20:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds] 20:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 21:41 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 21:59 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 22:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds] 22:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 22:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds] 23:55 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 23:55 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds] --- Log closed Fri Apr 26 00:00:55 2019