--- Log opened Sat May 18 00:00:17 2019
00:37 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 250 seconds]
00:46 -!- booyah [~bb@193.25.1.157] has joined #c-lightning
00:47 -!- darosior [52ff9820@gateway/web/freenode/ip.82.255.152.32] has joined #c-lightning
03:00 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:06 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
03:32 < darosior> m-schmoock: cdecker: What do you think about adding a default plugin directory in ~/.lightning ?
04:57 <@cdecker> Sounds ok, though having code in a config dir is a bit weird
05:44 < m-schmoock> cdecker: executables != code   unless python :D 
05:45 < m-schmoock> I support the idea, we need to get handling plugins more easy. most people dont realize or know how to handle them correctly currently
05:48 < m-schmoock> cdecker: My machine rebooted this night (each saturday). Did you response something about the reserves thing? Im going to implement a cheap solutino for now that drains up to like 100% - reserves - fixed_amount_for_htlc (i.e. 500sat). Im still thinking about that dust reduction/accumulation thing. We might need an option to intentionally draw a channel down to 0msat before closing. this way we can 
05:48 < m-schmoock> (maybe) reduce UTXO bloat and such
05:51 < m-schmoock> There is no real gametheoretical usecase in going below reserves before closing a channel, right? I mean when I have 0msat, how can I be cheated on? Maybe you can give me some hints....
06:03 <@cdecker> It's not about you, it's about the counterparty needing assurance that you aren't going to cheat, hence it forces you to keep some skin in the game
06:25 < fiatjaf> "We might need an option to intentionally draw a channel down to 0msat before closing.", I would love that.
06:26 < fiatjaf> ~ can we get a hook for when a channel is closed? I specifically want to know who was the m*** who closed the channel.
06:26 <@cdecker> +1 on that fiatjaf :-)
06:31 < fiatjaf> haha
06:58 < m-schmoock> cdecker: thanks for the clarification
06:59 < m-schmoock> lets wait for eltoo with that channel margin optimization then.
06:59 < m-schmoock> companies like bitrefill and such are likely to close channels now end then, they miht want to fill up the channel as most as possible before doing so
07:01 <@cdecker> Either that or they might want to keep liquidity in the network, so drain as much as possible before closing
07:01 < m-schmoock> yup. today I learned about LN ... #reckless
07:02 < m-schmoock> is there a 'good guess' on HTLC commitment fee, is 500sat good, or is there a way to get it more precisely?
07:05 < m-schmoock> hm, if i get error (which i will for '100% drain') I can catch and increase in 50sat steps until it works... dunno if thats too hacky, but it will fail locally, so maybe fast enought with little footprint
07:10 < m-schmoock> does clightning enforce the remote side not running too low?
07:15 <@cdecker> Yep, it does
07:34 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
08:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
09:48 < m-schmoock> cdecker: I implemented a funny/hacky incremental method to determine an effective HTLC fee within the plugin. By doing so I discoverd an interesting side effect
09:49 < m-schmoock> when I drain the channel to the absolute minimum, I cant easily fill it up again but will get WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) when I try
09:49 < m-schmoock> when using a _very_ small amount for the first rebalance/fill up (like 100 sat) it will work
09:49 < m-schmoock> for the second I can choose a higher amount to bring the channel to any value
09:52 < m-schmoock> when skipping the step with the tiny payment, the channel effectively becomes useless without anybody knowing
09:52 < m-schmoock> good thing is that I need to drain the channel 'twice 100%' to get into that state
09:52 < m-schmoock> but its interesting
09:54 < m-schmoock> it seems like the remote is having troubles to account fees when I drain 'twice'
09:58 -!- ctrlbreak_MAD is now known as ctrlbreak
10:01 < m-schmoock> the first drain will bring it to reserves + 230sat htlc_fee  := 1230sat   the second one can bring it down to 1200sat (dont know the reson). But after the second one, the channel turns in a unuslable state for the remote, if the next payment isnt small enough. I tried this at severa remotes
10:08 < m-schmoock> update: the reason I can bring it down more by doing it twice is that the detected required effective HTLC fee is 190sat when the channel is extremly low already
10:12 < m-schmoock> this leaves the channel at a balance where theres less than the normal reserves+226sat htlc  left. I think this causes the state where it fails for the remote for payments bigger than ~700sat
10:12 < m-schmoock> ~(reserves - commitment)
10:14 < m-schmoock> Thoughts? I think this is bad, as it can render channels unusable without anybody knowing
10:18 < m-schmoock> I can construct an attack, that bleeds (any?) remote channels below the regular HTLC commitment by twice circular payments to myself. Then I turn of my machine, leaving the network with having less working channels. I can repeat that until (all) channels are in a state where only a tiny payment 'unlocks' them
10:19 < m-schmoock> All I need is a big enought input and output channel
10:19 < m-schmoock> and fancy routin scripts
10:20 < m-schmoock> niftynei: ping (see above)
10:36 < m-schmoock> this effect does not happen (yet) when the reserves are not yet build up
11:15 <@cdecker> How big is the reserve in that case? Might be that the HTLC output pushes the settlement transaction over the dust limit suddenly creating two outputs that have to be paid by the funder (which cannot since it effectively only has a tiny amount)
11:19 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 258 seconds]
11:46 < m-schmoock> the reserves are 1000sat 
11:48 < m-schmoock> the HTLC fee requirements are 226sat  and drop to ~190sat if the channel is already below ~1230sat. this results in a locked up channel with 1200sat (to us)
11:50 < m-schmoock> you can checkout my working branch of the drain plugin and test it quickly. just drain it two times. you cannot fill it up again (i.e. via rebalance) until you start with a tiny amount of >~700sat
11:52 < m-schmoock> thats about all I can tell :D
11:53 < m-schmoock> I could make a POC that locks up remote channels in a pytes testcase
11:53 < m-schmoock> dont know if it affects all equal: LND, CLND and ACINQ
12:07 -!- darosior [52ff9820@gateway/web/freenode/ip.82.255.152.32] has quit [Ping timeout: 256 seconds]
12:41 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
12:50 < fiatjaf> how do you install these plugins?
12:50 < fiatjaf> they're all python stuff with requirements
12:50 < fiatjaf> where do you put the requirements? virtualenv?
12:51 < fiatjaf> all that inside the 'plugins' folder?
12:56 < m-schmoock> fiatjaf: heres some README.md in the repo mainpage: https://github.com/lightningd/plugins
12:57 < fiatjaf> hm, so you just install globally?
12:57 < fiatjaf> sorry, I missed that part.
13:24 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
13:31 <@cdecker> `lightningd` will inherit the path it is run from, so if you have a virtualenv, activate it and then start `lightningd`, it should pick the python3 binary from the virtualenv
13:32 <@cdecker> That
13:32 <@cdecker> That's how I run all my plugins: fixup the PATH to pick the correct python3 and then start lightningd
13:41 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
14:20 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:27 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
14:34 -!- deicidus [~deicidus@185.9.19.107] has joined #c-lightning
14:35 < deicidus> hi!
14:35 < deicidus> i am trying to get a pruned c-lightning node to work on a raspberry pi
14:35 < deicidus> i got it working but it wont launch via systemd
14:35 < deicidus> it just says "dead (inactive)"
14:36 < deicidus> but it can be launched manually. once. then it hangs on launch. and "sudo systemctl start lightning" also hangs
14:36 < deicidus> can anyone help?
14:36 <@cdecker> What is `journalctl -fu lightning` saying?
14:36 <@cdecker> That'll print the log output from the unit
14:37 < deicidus> hang on...
14:38 < deicidus> pi zero* btw
14:38 < deicidus> so i'm waiting on it to print the logs hehe...
14:41 < deicidus> nothing is printing...
14:42 <@cdecker> Hm, I'm running on a Pi Zero W as well btw
14:43 <@cdecker> Could it be an issue with the user it is being run with?
14:43 < deicidus> could you send me your lightning.service file?
14:43 < deicidus> it could be a user issue potentially
14:43 <@cdecker> You could call `sudo su -s /bin/bash username` and then try to execute lightningd
14:44 <@cdecker> Sure, just a sec
14:44 < deicidus> because it works when run manually as my user, but not when run by systemd, which runs as root
14:44 < deicidus> but systemd is supposed to use the correct user based on the configuration file, no?
14:45 <@cdecker> Yeah, should be better to use systemd
14:45 <@cdecker> Had it wrong, I'm running it using supervisord with the pi user
14:46 < t0mix> pruned + c-lightning. bad experience for me. but not related to systemd.
14:46 < deicidus> hmm
14:46 < deicidus> well c-lightnting itself pruned seemed to be working when run manually
14:46 < deicidus> we are very pleased
14:46 <@cdecker> t0mix: yeah, when they get too much out of sync it's painful
14:46 < deicidus> here is the project if anyone is curious: https://photos.app.goo.gl/4jx8mbXE2MRM24jX6
14:46 < deicidus> ah
14:47 < deicidus> yeah, that might be a problem, since this image will be distributed via torrent
14:47 < deicidus> so later users will have a problem
14:47 < deicidus> but, it's the best we can do for now
14:47 < deicidus> we could reissue the torrent
14:48 <@cdecker> Yeah, working on a simple bitcoin-cli replacement that just talks to explorers when it can't get the block from bitcoin-cli
14:48 < deicidus> ok, so after running your super meta command `sudo su -s /bin/bash username` lightningd will still launch manually
14:48 < deicidus> so, that makes it less likely it is a weird systemd user issue, right?
14:48 <@cdecker> Hm, that's weird
14:48 <@cdecker> Can you share the service file?
14:49 < deicidus> yeah
14:49 < deicidus> did you send me yours?
14:49 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
14:49 <@cdecker> I don't have one turns out :-)
14:49 < deicidus> hang on while i get the file...
14:49 < deicidus> oh yeah
14:50 < t0mix> I run on rpi 2, but I always start bitcoin + cln manually =D since I don't do it very often.
14:51 < deicidus> trying to make this one easy so they can just burn the pi image and plug it in, and it starts hosting
14:52 <@cdecker> Awesome
14:52 < deicidus> yeah it's gonna be slick
14:52 < t0mix> ++
14:52 < deicidus> here we go:
14:52 < deicidus> [Unit]
14:52 < deicidus> Description=lightning-deamon
14:52 < deicidus> After=bitcoin.service
14:52 < deicidus> Requires=bitcoin.service
14:52 < deicidus> [Service]
14:52 < deicidus> ExecStart=/usr/local/bin/lightningd --daemon --pid-file=/home/doge/.lightning/lightning.pid
14:52 < deicidus> PIDFile=/home/doge/.lightning/lightning.pid
14:52 < deicidus> User=doge
14:52 < deicidus> Group=doge
14:52 < deicidus> Type=forking
14:52 < deicidus> #PrivateTmp=true
14:52 < deicidus> Restart=on-failure
14:52 < deicidus> RestartSec=30
14:53 < deicidus> TimeoutStartSec=300
14:53 < deicidus> [Install]
14:53 < deicidus> WantedBy=multi-user.target
14:53 < deicidus> tried several variations
14:53 < deicidus> including no daemon, no pid, simple instead of forking
14:53 < deicidus> an ampersand
14:53 <@cdecker> Pastebin would have been nice :-)
14:53 < deicidus> ah sorry
14:54 <@cdecker> Can you try and make it simple without the `--daemon- flag?
14:54 <@cdecker> That makes it so much easier
14:54 < deicidus> https://pastebin.com/mbStX287
14:54 < deicidus> k
14:55 < deicidus> ok done. did daemon-reload
14:55 < deicidus> the behavior will probably be the same. takes about 3 minutes or so to be sure
14:56 < deicidus> i left the PID business but i have no idea what it's for
14:56 < deicidus> or if it's necessary
14:57 <@cdecker> Likely only needed for forking, not sure if it'll interfere, but hey
14:58 <@cdecker> I mostly do trial-and-error with systemd if it doesn't work at first
15:00 < t0mix> yup.. same for me. I still don't like systemd. but I get it, what its added value is.
15:00 < deicidus> i have been doing trial and error on this for hours... no idea what the problem is
15:00 < deicidus> if systemd is running it as the wrong user, i dont know how to fix it
15:00 < deicidus> otherwise not sure why it would run manually but not via systemd
15:01 < deicidus> Active: inactive (dead)
15:02 < deicidus> trying again with the PID stuff removed
15:02 < deicidus> systemd file is very simple now
15:02 < t0mix> add a cronjob for doge user ¯\_(ツ)_/¯
15:02 <@cdecker> Anything with just `journalctl`? I'm hoping that'd include some meta information about systemd trying to start the service
15:03 < deicidus> haha ok. we might do that. or we might just integrate the interface and logic to launch and sustain lightning into the GUI of our main app
15:03 < deicidus> (that video i linked above)
15:03 < deicidus> yes:
15:04 < deicidus> it's complaining that the .service files are marked as executable but "proceeding anyway"
15:04 < deicidus> it says the systemctl command is being run as root, which is as expected since i ran it as sudo
15:05 < deicidus> "session opened for user root by (uid=0)"
15:05 <@cdecker> Ok, nothing useful then :-(
15:05 < deicidus> seems like more of the same
15:05 < deicidus> yeah
15:06 < deicidus> is there anyone who might be around later who would know exactly how to fix this? i am pretty stumped
15:06 < deicidus> current least effort is to reimplement the functionality of systemd in my GUI lol
15:06 < deicidus> thanks, systemd
15:06 <@cdecker> Maybe Rusty has some experience debugging systemd, in the meantime you could ask on StackOverflow
15:06 < deicidus> ok thanks
15:07 <@cdecker> Sorry I couldn't be of more help
15:08 < t0mix> maybe you can set LogLevel in /etc/systemd/system.conf to debug? =/
15:08 <@cdecker> And you can try to ramp up the log-level in lightningd as well
15:15 < deicidus> posted on stack overflow here: https://stackoverflow.com/questions/56203240/why-is-c-lightning-working-when-launched-manually-but-fails-to-start-via-system
15:15 < deicidus> ok, i will set that
15:16 < deicidus> ooo this is much more detailed
15:18 < deicidus> hmm, none of this seems to be an error message or explain any weirdness though
15:18 < deicidus> i will be back in a bit, thanks for all your help so far!
15:32 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:38 -!- deicidus [~deicidus@185.9.19.107] has quit [Ping timeout: 268 seconds]
15:50 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
16:05 -!- deicidus [~deicidus@185.9.19.107] has joined #c-lightning
16:20 -!- deicidus [~deicidus@185.9.19.107] has quit [Ping timeout: 246 seconds]
16:49 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #c-lightning
16:51 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #c-lightning
17:11 -!- deicidus [~deicidus@185.9.19.107] has joined #c-lightning
17:11 < deicidus> i'm back
17:11 < deicidus> still stuck on this
17:12 < deicidus> we seem to be having a similar problem getting systemd to launch c-lightning on a regular computer, too. not just the Pi Zero W.
17:17 < deicidus> has anyone gotten c-lightning to start via systemd?
17:41 < deicidus> GOT IT
17:42 < deicidus> the After=bitcoin.service line is hanging it up
17:42 < deicidus> so maybe bitcoin needs to be run as simple... testing that now
17:56 < deicidus> yes! that seems to have been it. rebooting for a final check now...
18:03 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
18:04 -!- rh0nj [~rh0nj@88.99.167.175] has joined #c-lightning
19:22 < jb55> deicidus: it shouldn't require anything special. I have mine as After=network.target, ExecStart=lightningd
19:28 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Quit: gone]
20:03 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
20:05 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 244 seconds]
20:20 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
20:39 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
20:50 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.4]
20:53 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #c-lightning
21:00 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
21:01 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 258 seconds]
21:15 -!- deicidus [~deicidus@185.9.19.107] has quit [Ping timeout: 255 seconds]
21:49 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 268 seconds]
--- Log closed Sun May 19 00:00:17 2019