--- Log opened Fri Jul 17 00:00:22 2020
00:33 -!- nixbitcoin_ is now known as nixbitcoin
00:35 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
00:36 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
02:16 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
03:16 < m-schmoock> cdecker: im updating the decomission feature request a bit. ZmnSCPxj commented https://github.com/ElementsProject/lightning/issues/3550#issuecomment-657357549 
03:17 < m-schmoock> My suggestion would be to make openchannel chained. and if multiple plugins return { 'result': 'continue', 'close_to': 'something_else' }  we make a fat warning in the log about this and take the first plugins response. also we point out in the plugin docs that openchannel can only have one plugin to set close_to
03:18 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
03:19 < m-schmoock> Other option would be similar a chainable hook without the 'close_to' option and keep the openchannel as is
03:19 < m-schmoock> what do you think about this issue?
03:19 < m-schmoock> zmnscpxj__: just talking about your comment https://github.com/ElementsProject/lightning/issues/3550#issuecomment-657357549
03:20 < zmnscpxj__> m-schnoock your proposal seems fine to me
03:20 < m-schmoock> if we go for separate hook, we can make a chainable hook without the close_to option, but this is bloat so we should handle it with the current openchannel hook by taking the first close_to plugin response and make a fat warning
03:21 < zmnscpxj__> I mean make openchannel chained
03:21 < zmnscpxj__> and get first close_to
03:21 < m-schmoock> and do just a warning in the log about it ?
03:22 < zmnscpxj__> For more complexity, add a "priority" field (default 0 if not specified), get the highest priority, and only warn if the highest priority has multiple
03:22 < m-schmoock> whoaa  :D
03:22 < zmnscpxj__> so for example you could run a plugin which analyzes the blockchain and if you do not like the peer because you are censoring them, you can close_to elsewhere
03:22 < m-schmoock> not sure, seems overkill
03:23 < zmnscpxj__> but "get first close_to" is fine LOL
03:23 < zmnscpxj__> just me being evil
03:23 < m-schmoock> >  you could run a plugin which analyzes the blockchain and if you do not like the peer because you are censoring them, you can close_to elsewhere
03:23 < m-schmoock> such a plugin would not set close_to right?
03:23 < m-schmoock> but simply reject
03:24 < zmnscpxj__> No, I mean have a normal plugin that assigns close_to as normal, but have a second plugin which does blockchain analysis and secretly puts funds from censored nodes in a different wallet
03:24 < zmnscpxj__> just being evil
03:24 < zmnscpxj__> first close_to is fine
03:25 < m-schmoock> :D ill update the issue
03:28 < m-schmoock> zmnscpxj__: I do like the 'decomission' file because I am lazy, but Im sure the PR wont go through if I do the easy way :D
03:29 < zmnscpxj__> I think `decommission` file is better for an operator, though.
03:29 < m-schmoock> Maybe I just go for it (as its very cheap to implement) and then we discuss this in the PR
03:29 < zmnscpxj__> easier for scripts to check if `decommission` file exists in your `.lightningd/`
03:29 < zmnscpxj__> than hack the database
03:29 < m-schmoock> it has pros and cons
03:30 < m-schmoock> its clearly a hack, maybe a good one
03:31 < m-schmoock> zmnscpxj__: also, what do you think about redirecting funds off-chain before closing? Its faster and maybe more secure that way
03:32 < zmnscpxj__> depends on the decommissioning.  What if I am decommissioning because I am retiring and putting all my funds into an icy cold wallet?
03:32 < zmnscpxj__> then redirecting funds offchain is not an option I would take
03:32 < m-schmoock> user should decide
03:33 < zmnscpxj__> yes, but that adds more options to the decommission flow
03:33 < zmnscpxj__> *shrug*
03:33 < m-schmoock> future problem
03:33 < zmnscpxj__> I suggest doing the `openchannel` chaining in a separate PR, by the way
03:33 < m-schmoock> kk
03:33 < m-schmoock> maybe we start by this first then
03:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
03:53 <@cdecker> Agreed, we should make the openchannel hook chainable, and then we can discuss semantics of multiple `close_to` on the PR. I quite like keeping it simple (accept the first, fail the call if any other one tries to also set it)
03:54 <@cdecker> Regarding the decommission file, I think that's probably also a good option, plugins generally should not expect to have access to the DB, but they can rely on being run in the same directory they were run the last time
03:55 <@cdecker> It's also what I went for with the backup plugin, since changing backup destination between runs is almost never what you want xD
03:55 < zmnscpxj__> And you can always ln -s to point a file elsewhere
03:56 < zmnscpxj__> oh and since cdecker is here, cdecker: please check https://github.com/ElementsProject/lightning/issues/3846
03:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
04:21 <@cdecker> Roger that :+1:
04:24 <@cdecker> That's weird, the line in the commit mentioned in the issue is empty
04:26 < zmnscpxj__> non-empty on my repo, as well as on ElementsProject/lightning master
04:26 < zmnscpxj__> See my comment
04:26 < zmnscpxj__> on the issue
04:27 <@cdecker> Doh, I have multiple worktrees open, checked out in one, and looking at the file in another :facepalm:
04:27 <@cdecker> But to your point, yes it should be safe to return immediately if r == NULL
04:27 < zmnscpxj__> sufficient to stop the crash, but is there some underlying error here?
04:28 <@cdecker> And the code below handles that case, but kills the plugin as well
04:28 < zmnscpxj__> should the json parsing fail?
04:28 <@cdecker> At least we'd get some more indication about the result that failed
04:29 <@cdecker> You know what? I'll move the inferring of the result down below the `p->result == NULL` test
04:57 <@cdecker> Currently funding two new nodes to try and recreate the issue, but not knowing the waitsendpay result makes that a bit hard
04:58 < zmnscpxj__> okay, we can provide a patch moving the infer call after the if(NULL) check and ask OP to report again
04:59 <@cdecker> CAIt's probably something rather dumb, like a single field missing in the response, and I was a bit too restrictive with what I accept. Since the result comes from lightningd I thought that was the right thing to do :tm:
05:18 -!- Amperture [~amp@65.79.129.113] has joined #c-lightning
05:29 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection timed out]
05:31 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning
06:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:11 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has left #c-lightning []
06:11 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has joined #c-lightning
06:13 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
06:30 < m-schmoock> thanks for both of your input
06:30 < zmnscpxj__> np
06:31 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
06:38 <@cdecker> Turns out after following all result paths for waitsendpay, that there are quit a few (unparseable onion, unspecified error, try other, and all the possible sendpay results)
06:38 <@cdecker> The good news is that we guard against p->result == NULL in all current modifiers, and can happily go on even in that case.
06:39 < zmnscpxj__> so we just make it a rule that modifiers should not expect it to be non-NULL?
06:40 <@cdecker> I'll update the plugin_err call to log the error (with the full waitsendpay result for future handling) and call payment_continue instead, worst case is that be hit the same issue a couple of times by retrying the same route
06:40 <@cdecker> zmnscpxj__: exactly
06:41 < zmnscpxj__> so plugin_log at LOG_UNUSUAL instead?
06:43 <@cdecker> Yep
07:05 -!- Amperture [~amp@65.79.129.113] has quit [Quit: Leaving]
07:15 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
07:31 <@cdecker> Ok, new fix is up: https://github.com/ElementsProject/lightning/pull/3839#issuecomment-660139431
07:31 <@cdecker> zmnscpxj__: could you give it a quick scan if it makes sense?
07:32 <@cdecker> If you think it's good I can tag a new rc2 tonight ^^
08:01 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver]
08:24 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
08:31 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
08:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
08:34 -!- vasild_ is now known as vasild
08:37 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: mrostecki]
08:41 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
08:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
09:14 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: mrostecki]
09:26 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Quit: %bye%]
09:26 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #c-lightning
09:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
10:48 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
11:00 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
12:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
13:06 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
13:07 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
13:21 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
14:29 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has left #c-lightning []
14:30 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has joined #c-lightning
14:44 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
15:03 -!- mol [~mol@unaffiliated/molly] has joined #c-lightning
15:36 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
15:38 -!- mol [~mol@unaffiliated/molly] has joined #c-lightning
16:01 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
16:19 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
16:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
16:35 -!- mol_ [~mol@unaffiliated/molly] has joined #c-lightning
16:38 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
17:10 -!- qubenix [~qubenix@66.172.11.228] has quit [Quit: quit]
17:12 -!- qubenix [~qubenix@66.172.11.228] has joined #c-lightning
17:31 -!- grubles [~blockhash@unaffiliated/grubles] has joined #c-lightning
17:52 -!- nixbitcoin [~nixbitcoi@gateway/tor-sasl/nixbitcoin] has quit [Remote host closed the connection]
17:53 -!- nixbitcoin [~nixbitcoi@gateway/tor-sasl/nixbitcoin] has joined #c-lightning
18:29 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
18:29 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #c-lightning
20:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
20:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
22:46 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has left #c-lightning []
22:46 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-xadswhvwruqyrqgr] has joined #c-lightning
--- Log closed Sat Jul 18 00:00:26 2020