--- Log opened Thu Jun 17 00:00:40 2021
00:34 < mschmoock> warren: yes, from a network health perspective TOR makes the situaion worse. One can disable it, but how does my node know if a rout he tries contains TOR nodes?
00:35 < mschmoock> Hm.. maybe ask gosspi for announced addresses before routing :D
00:35 < mschmoock> Sometimes sendpay attempts take a minute or longer when there are non-responsive nodes along the route
00:53 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has joined #c-lightning
01:15 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
01:24 < mschmoock> rusty: do you think its legit to exclude nodes from routing that only have a tor address announced? ;)    they often really mess up the responsiveness, particular when theres just one tor node on a 7hop route   
01:31 < _aj_> rusty: rayodelmar - more or less what you get if you plug "sea lightning" into google translate :)
01:31 < _aj_> (er, en->es)
01:38 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 244 seconds]
01:41 -!- k3tan [~pi@user/k3tan] has joined #c-lightning
03:23 < lxer> mschmoock: why does that happen? is it tor, CL, or LND?
03:28 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
03:29 < rusty> mschmoock: I wonder if we should increase our timeouts?
03:35 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
03:40 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 240 seconds]
03:48 < openoms[m]> mschmoock I don't think filtering Tor only nodes would help as that is only one possible cause for delays. There are nodes running on an HDD, how can filter those? Also a generally flaky internet connection can be responsible.
03:57 < darosior> I like rayo del mar
04:02 < vincenzopalazzo> openoms: Or maybe the other side is crashed :-D I think this is a philosophic talk and I like it, but I think one missing here is that at the moment a method to calculate how good is the node where we are connected in. Maybe the latency problem is caused only when a node has a lot of payment to share, and this include all your consideration about the HDD and internet quality
04:02 < vincenzopalazzo> But the only error here is that we are connected in a not good node
04:04 < vincenzopalazzo> darosior: do you mean the song https://www.youtube.com/watch?v=fczULv40VRc :-D (I missed somethings here, I know)
04:04 < mschmoock> What if we add a protocol field that tells a node along the route to respect a certain response timeout on the next hop, when reached the node should fail the payment
04:04 < mschmoock> sure thats on a good will basis, if a node wants to collect the fees, he shouldnt care for the timeout
04:05 < mschmoock> or maybe we make a plugin that traces node/channel network performance whenever payment attempts fail or are successful
04:06 < mschmoock> because from my own experiencing network quality is degrading quick
04:06 < vincenzopalazzo> mschmoock: In some c-lightning meeting we talk about to make a some system to report the metrix, like lnd does with some side project that I don't rememeber the name :) 
04:07 < vincenzopalazzo> On solution can be that your node report the life metrics of itself and the other node connected in
04:07 < ChristianDecker[> Problem is that these metrics are all self-reported, and if you ask nodes to not forward if their peer is slow you are asking them to forgo the forwarding fee, so they definitely do not have an incentive to do so
04:07 < mschmoock> jup
04:08 < mschmoock> ChristianDecker[: how about a nexthop timeout value (also good will, but software can choose to set it).
04:09 < ChristianDecker[> Who'd set it and who'd enforce it?
04:09 < mschmoock> The source can decide to use a custom next hop timoue value. the node along the payment can choose to respect it
04:09 < mschmoock> of course there can be implementations that choose not to respect it
04:10 < mschmoock> theres a potential good reason to let this up to the source, maybe he has found a slow but cheap route ...
04:10 < ChristianDecker[> And the tiimeout would measure what?
04:11 < mschmoock> The response to the forward request to the next hop
04:11 < mschmoock> 'the TCP sockets delay between the node'
04:12 < mschmoock> Also, this would give users an incentive to have a good connection ;)
04:12 < mschmoock> at least the ones looking to forward payments
04:13 < ChristianDecker[> But you are trusting the node to respect it, and lose out on the fees, seems like nobody would chose to respect it
04:13 < mschmoock> I know that point is not perfect
04:14 < mschmoock> if its done like this in common implemnetations, people my go with it
04:14 < mschmoock> *may
04:14 < mschmoock> just a thought... I recently see sendpay attempts timouting after a minute before trying the next route/part
04:14 < mschmoock> we may want to address that before its getting a bigger deal :D
04:15 < mschmoock> (likely often caused by some tor only node)
04:16 < ChristianDecker[> Hm, maybe you're right, I usually don't like modelling everybody as (economically) rational attempting to extract as much value as possible. Ad your proposal matches that: users participate because they get utility from LN, not because they can rent-seek
04:16 < mschmoock> also rent-seek is not a businesscase in LN and maybe never will
04:25 < mschmoock> I really shoudl open two RFC proposales about this and advertising hostnames. They kinda go together, as home-users usually rely on using TOR only, which cripples responsiveness
06:40 < ChristianDecker[> Ci fix PR for lightningd/plugins is up :+1:
06:46 < vincenzopalazzo> Christian Decker: LGTM :-D let's see if Github action will approve it too :)
06:47 < _aj_> ChristianDecker[: rational nodes want successful payments -- you don't collect fees on failed payments; so reporting .. channel latency honestly so people can set correct timeouts might be rational anyway?
06:48 < _aj_> ChristianDecker[: https://github.com/bitcoin/bips/pull/943 is out of draft btw, assuming you're not sailing/holidaying now
06:50 < ChristianDecker[> Awesome, thanks _aj_ I'll take a look this weekend and start pressuring people to merge it ^^
06:51 < _aj_> ChristianDecker[: should just need an ACK from you followed by an @ at luke and kallewoof, assuming there's no obvious problems / easy fixes
06:52 < ChristianDecker[> Sounds good 👍️
06:52 < _aj_> ChristianDecker[: (maybe since it's a big change it should be posted to -dev as well...)
07:12 < mschmoock> ChristianDecker[: thx <3
07:42 -!- jonatack [jonatack@user/jonatack] has joined #c-lightning
09:02 -!- jarthur [~jarthur@cpe-70-114-198-37.austin.res.rr.com] has joined #c-lightning
09:19 < warren> mschmoock: tor-only peers often fail to route at all for me. cdecker at one point found the added network delay was severe enough to eat most of the time budget for one hop.
11:12 < mschmoock> cdecker: did a little something today: https://github.com/ElementsProject/lightning/pull/4609
11:26 < mschmoock> looks like theres still valgrind stuff todo...
12:28 -!- Guest1 [~Guest1@2405:201:400e:4178:a491:987b:8a75:2e81] has joined #c-lightning
12:31 -!- Guest1 [~Guest1@2405:201:400e:4178:a491:987b:8a75:2e81] has quit [Client Quit]
12:47 < vincenzopalazzo> mschmoock: Not a expert with memory management, and I don't test my idea, so this ca be complelly stupid
12:47  * vincenzopalazzo  < https://libera.ems.host/_matrix/media/r0/download/libera.chat/40c7049b9907de39c04d7c1b2eeabc892044a22d/message.txt >
12:48 < vincenzopalazzo> bat maybe you need to free the path also in the if before brealk?
12:48 < vincenzopalazzo> break*
13:59 < mschmoock> yes maybe. thx will try
14:04 < mschmoock> I think I got it. It was something similar obscure
14:05 < mschmoock>         p->cmd = tal_strdup(p, path);
14:05 < mschmoock> -       p->checksum = file_checksum(path);
14:05 < mschmoock> +       p->checksum = file_checksum(p->cmd);
14:09 < vincenzopalazzo> mschmoock: lets see if valgrind agree :)
14:09 < mschmoock> I already tried locally
14:09 < mschmoock> Usually I let CI do the job. But once it discovered something im able to reproduce
14:11 < vincenzopalazzo> Same
15:25 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has quit [Ping timeout: 268 seconds]
17:06 -!- belcher_ [~belcher@user/belcher] has joined #c-lightning
17:09 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 244 seconds]
18:09 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
18:33 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 244 seconds]
18:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
20:12 -!- rusty [~rusty@203.221.41.134] has joined #c-lightning
23:13 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has joined #c-lightning
--- Log closed Fri Jun 18 00:00:41 2021