--- 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