--- Log opened Tue Aug 11 00:00:47 2020
00:21 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #c-lightning
00:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
01:14 -!- jonatack [~jon@213.152.161.30] has joined #c-lightning
01:15 < shesek> has something changed recently with the mrkd dependency? building fails for me with "mrkd: not found", on an environment where building used to work (recently built v0.9.0 on it). I tried installing python's requirements.txt with pip (which also wasn't necessary before), and now its failing with: SyntaxError: invalid syntax   File "/home/nadav/.local/lib/python3.5/site-packages/mrkd.py", line 40   return f'{self.double_emphasis(text)}({section})'
01:16 < shesek> perhaps it requires python 3.6?
02:39 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #c-lightning
02:49 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
02:52 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
03:11 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
03:20 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]
03:23 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has left #c-lightning []
03:23 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has joined #c-lightning
03:28 -!- k3tan [~pi@unaffiliated/k3tan] has quit [Ping timeout: 246 seconds]
03:29 <@cdecker> shesek: yes, mkrd uses f-strings (formatting strings) which were stabilized in 3.6
03:29 <@cdecker> Usually you don't need mrkd at all, since we check in the compiled manpages, but every once in a while someone (i.e., me) forgets to check them in as well
03:30 -!- k3tan [~pi@unaffiliated/k3tan] has joined #c-lightning
03:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
03:44 < shesek> I have both python 3.5 and 3.6 installed, but can't seem to get it to run with 3.6. would be great if you could add them :)
03:51 < shesek> is there a way to just skip generating the manpages as a temporary workaround? 
03:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
03:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
03:58 -!- vasild_ is now known as vasild
04:10 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
04:11 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
04:12 < darosior> shesek: a quick hack would be to remove the make doc-all target from the make all, or to comment the mrkd one-liner. Otherwise if you have mrkd installed in a venv it should be ok, and if you installed it with pip3 install --user it should be fine after sourcing /usr/bin/env i guess
04:15 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
04:15 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]
04:28 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #c-lightning
04:29 -!- fiatjaf1 [~fiatjaf@2804:7f2:2a82:90a5:ea40:f2ff:fe85:d2dc] has quit [Remote host closed the connection]
04:30 -!- fiatjaf1 [~fiatjaf@2804:7f2:2a82:90a5:ea40:f2ff:fe85:d2dc] has joined #c-lightning
04:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
04:36 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
04:52 -!- jonatack [~jon@213.152.161.30] has quit [Ping timeout: 256 seconds]
05:06 < shesek> darosior, thanks!
05:06 <@cdecker> Alternatively you can call `make all-programs` instead, which skips all doc-related things as well
05:06 < shesek> nice, that's even easier :)
05:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
05:21 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
05:29 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
05:40 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
05:47 -!- sha-265 [4d7c73ae@77.124.115.174] has joined #c-lightning
05:48 < sha-265> I'm trying to use this script to over come missing blocks in pruned node: https://gist.github.com/jonasnick/e4a2b41215a35a461099a5ca2d8affc4
05:49 < sha-265> but I get an error:
05:49 < sha-265> >  bitcoin-cli-wrapper.sh exited with code 2: bitcoin-cli-wrapper.sh: 20: bitcoin-cli-wrapper.sh: Syntax error: "(" unexpected
06:31 <@cdecker> That script is missing a shebang. The first line must read something like this `#!/bin/bash` otherwise the OS doesn't know how to execute it
06:38 < sha-265> You're right, that solved the problem
06:38 < sha-265> Thanks
06:38 <@cdecker> No problem
06:42 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
06:47 < vincenzopalazzo> Hi guys, I have a stupid question about getinfo command result
06:48 < zmnscpxj_> ok
06:48 < vincenzopalazzo> When I run getinfo result I have a address array empty
06:48 <@cdecker> reproduced #3915 btw :-)
06:48 < zmnscpxj_> That is the addresses that we think the node has
06:48 < zmnscpxj_> you can give more via --addr and --announce-addr indications
06:49 < zmnscpxj_> I think we have code that tries to detect NAT and tries to use uPNP to open a port at the router
06:49 < zmnscpxj_> if the router does not support it then we end up with nada addresses
06:49 < zmnscpxj_> I think
06:49 <@cdecker> Oh please, let's not go upnp, it's a horrible protocol
06:50 < zmnscpxj_> oh, do we not go upnp?
06:50 < zmnscpxj_> not familiar with our network code
06:50 < vincenzopalazzo> Oh I think is an android system problem, I fund a problem now because I'm working on the Lam android app
06:51 < zmnscpxj_> anyway if you have NAT problems or a dumb ISP, you can just go with Torv3 addresses, that helps
06:51 < vincenzopalazzo> yep, with tor work well
06:51 <@cdecker> Only reference I could find is the instalation instruction for MacOS
06:51 < zmnscpxj_> huh
06:53 < zmnscpxj_> @cdecker re 3915, could also crash with an invalid root if we freed something without deleting from the list
06:53 < zmnscpxj_> that would be rather scary though
06:53 <@cdecker> The issue is relatively simple: for each payment we check whether it is pending. 
06:53 <@cdecker> If we used the presplit modifier no attempt with the bolt11 annotation was ever sent to lightningd (we annotate solely the root to save space)
06:54 <@cdecker> Which then bites us when we try to compare the b11 strings, which are null
06:55 <@cdecker> Modifying the presplit modifier to annotate it's splits and switching over to comparison to payment_hash to make sure we catch keysends as well
06:55 < zmnscpxj_> why only presplit tho? why not adaptive or retry as well?
06:57 < zmnscpxj_> `payments` is only modified by adding a new root payment
06:57 <@cdecker> adaptive and retry act _after_ the attempt was sent to lightningd which has stored it
06:57 <@cdecker> presplit skips the root payment being sent to lightningd at all
06:57 < zmnscpxj_> ah
06:57 < zmnscpxj_> right
06:59 < zmnscpxj_> ...and I just now realized that we build up an entire tree of sub-payments without ever freeing it
06:59 < zmnscpxj_> that I can see
07:00 <@cdecker> Yes, we could free payments once they are completed, i.e., we no longer need them to determine whether we have pending parts
07:01 < zmnscpxj_> but we cannot safely free them on failure, at least until all parts have failed
07:01 <@cdecker> Yep, as soon as no part is in-flight we could free
07:02 < zmnscpxj_> *and* we probably should check if the user tried paying an invoice that failed before, because those could have parts that are still in-flight
07:03 < zmnscpxj_> actually we should probably check if the user is paying the same invoice twice as well.....
07:03 < zmnscpxj_> it looks like we do not actually check that.....
07:04 <@cdecker> I think we are, there's a test at least
07:05 < zmnscpxj_> what test item? I cannot find it in our code at all
07:05 < zmnscpxj_> I mean two parallel attempts at paying
07:06 <@cdecker> Need to check, I remember a test in sendpay for the same payment_hash that is passed through to the caller
07:06 < zmnscpxj_> In `sendpay` yes
07:07 < zmnscpxj_> But I do not think that would work if we had two *parallel* `pay` calls
07:07 < zmnscpxj_> for the same unpaid invoice
07:08 <@cdecker> True
07:08 < zmnscpxj_> Probably means we might need a list of commands that a root payment gives
07:09 <@cdecker> Nah, we just need to check the `payments` list before initializing the new root payment in json_paymod
07:10 < zmnscpxj_> and do what? fail the second command?
07:10 < zmnscpxj_> I think it is not a good API to fail the second `pay` if the first one is not complete yet
07:11 < zmnscpxj_> since if the first one completed, the second one will succeed (due to `sendpay` immediate success)
07:11 < zmnscpxj_> that would lead to racy expectations for the second command
07:11 < zmnscpxj_> since the serialization of the commands would have led to the second command succeeding, then if we have two parallel commands, both of them should succeed if the either of them succeed
07:11 <@cdecker> Yes, fail the second call. It's wrong to call pay with the same invoice twice (at least concurrently)
07:12 < zmnscpxj_> but you cannot be sure about concurrently
07:12 < zmnscpxj_> the first one could complete before the second one reaches `pay` due to other delays
07:12 < zmnscpxj_> and then it becomes inconsistent
07:12 < zmnscpxj_> i.e. target "sequential consistency"
07:13 < zmnscpxj_> sometimes the second one fails (because the first one was not completed yet) sometimes it succeeds (because the first one *was* completed yet)
07:13 < zmnscpxj_> that is not something I think is good for clients building on top of lightningd
07:13 < sha-265> https://gist.github.com/sha-265/f1c20e304e433642221d892851dc0258
07:13 < zmnscpxj_> that is why I think we should target sequential consistency i.e. if two commands are in parallel, we should act as if one completed in full before the other
07:13 < sha-265> after the first payment the `pay` pluging is crashing
07:13 < zmnscpxj_> and in that case the second command succeeds
07:14 < sha-265> * plugin
07:15 <@cdecker> sha-265: that's the issue #3915 we're discussing 
07:15 <@cdecker> We reproduced it and have a solution in the works
07:17 < sha-265> oh nice
07:24 -!- jonatack [~jon@213.152.162.69] has joined #c-lightning
07:32 -!- jonatack [~jon@213.152.162.69] has quit [Ping timeout: 240 seconds]
07:34 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
07:45 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
07:53 <@cdecker> zmnscpxj_: if you have time, could you take a look at https://github.com/ElementsProject/lightning/pull/3927 to see if it's alright?
07:53 <@cdecker> Running it against the full test-matrix currrently
07:53 <@cdecker> I'll also push back the hotfix release v0.9.0.1 by 24hours to see if we get anything else
08:22 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
08:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
09:07 <@cdecker> Opened a tracking issue for a hotfix release I've been prepping over the weekend: https://github.com/ElementsProject/lightning/issues/3928
09:07 <@cdecker> Please report any urgent issues that need to be backported before we release v0.9.0.1
09:19 -!- vincenzopalazzo [~vincent@host-95-246-119-127.retail.telecomitalia.it] has quit [Quit: Leaving]
11:29 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
11:35 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has left #c-lightning []
11:35 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has joined #c-lightning
11:52 -!- vincenzopalazzo [~vincent@host-95-246-119-127.retail.telecomitalia.it] has joined #c-lightning
12:13 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #c-lightning
12:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
12:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
13:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds]
13:22 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]
13:26 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #c-lightning
13:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
14:06 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds]
14:13 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning
14:14 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 240 seconds]
15:02 -!- sha-265 [4d7c73ae@77.124.115.174] has quit [Ping timeout: 245 seconds]
15:05 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Remote host closed the connection]
15:06 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
15:15 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 244 seconds]
15:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
16:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
16:13 -!- darosior [~darosior@194.36.189.246] has joined #c-lightning
16:41 -!- darosior [~darosior@194.36.189.246] has quit [Quit: darosior]
16:43 -!- darosior [~darosior@194.36.189.246] has joined #c-lightning
17:13 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds]
17:49 < fiatjaf1> darosior: what do I need to get my plugins on lightningd/plugins?
17:59 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
17:59 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
18:02 < shesek> is it a known issue that v0.8.2 sometimes lists amount_sent_msat but not amount_msat in listpays? (while it does list both in listsendpays for the same payment)
18:03 < shesek> I didn't see it mentioned on the changelog
18:04 < shesek> (and actually not entirely sure that its not in v0.9.0 too, its possible that its only manifesting for the payments I have in the v0.8.2 node for some reason)
18:04 < shesek> I did try sending some regular, mpp and keysend payments and could not reproduce in v0.9.0
18:08 < fiatjaf1> shesek: https://github.com/ElementsProject/lightning/commit/639eaaf2b4dad02a761285ef96d45392b0230b9e
18:08 < fiatjaf1> just saw this, maybe it's relevant
18:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
19:08 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
19:13 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 264 seconds]
19:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds]
19:31 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
20:02 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has left #c-lightning []
20:02 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has joined #c-lightning
20:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
20:55 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
21:45 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
21:57 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
22:05 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 264 seconds]
22:30 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:30 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
22:36 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
22:42 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55]
--- Log closed Wed Aug 12 00:00:48 2020