--- Log opened Thu Jun 24 00:00:47 2021 00:14 -!- belcher_ is now known as belcher 00:34 -!- lxer [~lx@95.91.246.102] has joined #c-lightning 00:48 -!- jb55 [jb55@jb55.com] has quit [Ping timeout: 268 seconds] 01:27 -!- k3tan [~pi@user/k3tan] has quit [Ping timeout: 252 seconds] 01:29 -!- k3tan [~pi@user/k3tan] has joined #c-lightning 02:51 < mschmoock> cdecker: what would be the appropriate way in a plugin to check for the availabilty of a newer optional parameter in a RPC method (i.e. 'destination' in listchannels). So the plugin checks if the RPC supports that dynamically 02:51 < mschmoock> Or is this hardwired only possible with a pyln update to recent version? 02:53 < cdecker[m]> You should be able to use `rpc.call("command", **kwargs)` to call with the new argument even with older pyln versions that don't know about the arg yet. Checking is more difficult, and I think calling `rpc.help("command")` might be the only option here. There is no versioning of RPC methods exposed by plugins (yet...) 02:56 < mschmoock> old versions simply ignore this argument and return all channels? (that would be suboptimal in my case) 02:56 < mschmoock> If I only can get all channels (not by destination) I need to do that in another location to it is not that resource intense 02:56 < cdecker[m]> No, silent errors are pretty bad for users. We should always return an error (the builtin plugins do) 02:57 < mschmoock> Ah, you mean try to call "`rpc.call("command", **kwargs)" and If I get the exception from old servers use antoher way ? 02:58 < cdecker[m]> The usual way of doing this is to wait for the users to upgrade, until then using the old client-side filtering, and then deprecate support for the old version 02:58 < cdecker[m]> Yes, you can test using the new version, catch the error and fallback if you want, but sounds a bit dirty :-) 02:59 < mschmoock> Yes I know, Im just thinking its a bit more fluid to do the update by checking for server capabilities 02:59 < mschmoock> kk. will try 03:00 < cdecker[m]> Facing a similar issue with https://github.com/ElementsProject/lightning/pull/4610 btw, which changes the behavior of `keysend` to accept on unknown fields, and not reject it anymore. This changes the noise plugin and simplifies it massively, but behavior is different enough not to be compatible at all xD 03:34 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has joined #c-lightning 03:37 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has quit [Client Quit] 03:37 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 04:16 < mschmoock> cdecker: is it okay if I merge trivial changes on the plugin repo without review? (i.e. https://github.com/lightningd/plugins/pull/258/files ) I dont want to stress ppl with maintenance and test improvements etc 05:02 < cdecker[m]> Sounds good to me, i guess we can have a simple maintenance rule like we have a spelling rule on the spec: if you just fixup a minor thing there is no need to pull in extra reviews 05:05 < vincenzopalazzo> Christian Decker: ack :) 05:22 < mschmoock> for the plugin repo that sounds reasonable 06:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 06:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #c-lightning 06:37 < openoms> how can I verify that my peers (channels) support option_dataloss_protect? Or is it just default for all now? I am aware that supporting the option does not mean compliance. 06:40 < cdecker[m]> If both sides signal support via the featurebits it should be enabled 06:47 < openoms> ok, I need to learn how to parse the featurebits. Would be nice if it would just appear in features like the option_static_remotekey 06:49 -!- jb55 [jb55@jb55.com] has joined #c-lightning 07:30 < mschmoock> anyone else having troubles to push git refs to github? I always get: "exists; cannot create" (though it does not exist) 08:00 < cdecker[m]> What kind of push? 09:25 -!- gnusha [~gnusha@user/gnusha] has joined #c-lightning 09:25 -!- Topic for #c-lightning: https://github.com/ElementsProject/lightning https://lists.ozlabs.org/listinfo/c-lightning Current Version: https://github.com/ElementsProject/lightning/releases/tag/v0.10.0 Dev Roadmap: https://github.com/ElementsProject/lightning/wiki Logging: https://gnusha.org/c-lightning/ 09:25 -!- Topic set by rusty [~rusty@103.93.169.121] [Mon May 31 14:24:13 2021] 09:25 [Users #c-lightning] 09:25 [ _0x0ff ] [ cdecker[m] ] [ face ] [ jonatack ] [ mschmoock ] [ remyers ] 09:25 [ _aj_ ] [ Dan[m] ] [ FelixWeis ] [ k3tan ] [ nathanael ] [ sword_smith ] 09:25 [ achow101] [ darosior ] [ fiatjaf ] [ kanzure ] [ Nebraskka ] [ ufotofu ] 09:25 [ aechu ] [ DeanGuss ] [ ghost43 ] [ ksedgwic ] [ niftynei ] [ valwal ] 09:25 [ belcher ] [ devrandom ] [ gnusha ] [ livestradamus ] [ openoms ] [ vincenzopalazzo] 09:25 [ berndj ] [ dr-orlovsky] [ jackielove4u] [ lxer ] [ openoms[m]] [ warren ] 09:25 [ cdecker ] [ early ] [ jb55 ] [ michaelfolkson] [ qubenix ] [ willcl_ark ] 09:25 -!- Irssi: #c-lightning: Total of 42 nicks [0 ops, 0 halfops, 0 voices, 42 normal] 09:25 -!- Channel #c-lightning created Wed May 19 12:44:07 2021 09:27 -!- Irssi: Join to #c-lightning was synced in 136 secs 09:36 < mschmoock> cdecker: a push that creates a new branch that does not exist yet 09:39 < vincenzopalazzo> mschmoock: I had not problem until now 09:39 < mschmoock> I figured I can use a branch that already exists for now (i.e. master) 09:40 < mschmoock> but it does not work for new branches. wired. never had this 09:41 < vincenzopalazzo> mschmoock: what is the error that you received? 09:42 < mschmoock> ah, I have the cause 09:42 < mschmoock> theres is already a branch called beginning with the same name. stupid, it stops after the "/" character 09:43 < mschmoock> I try to push feeadjuster/some_feature but if "feeadjuster" is already a branch at the repo it gets the exists message 09:43 < mschmoock> cannot lock ref 'refs/heads/feeadjuster/listchannels_dst': 'refs/heads/feeadjuster' exists; cannot create 'refs/heads/feeadjuster/listchannels_dst' 09:43 < mschmoock> nvm 09:45 < vincenzopalazzo> anyway the error is cryptic :) 09:48 < mschmoock> I think git uses inodes internally to store the refs 09:48 < mschmoock> so in my repo there was a file called "feeadjuster" and I tried to poush to the directory "feeadjuster" into a file in that dir 09:49 < mschmoock> cdecker: check for new RPC parameter like that? https://github.com/lightningd/plugins/pull/259 09:53 < mschmoock> cant write a test for that, but tested with both versions 10:09 < vincenzopalazzo> mschmoock: in my understanding here you catch the exception throws by the command, maybe avoid the exception and make an analysis of the help result? like I did a couple of days ago on my java plugin https://github.com/clightning4j/lightning-rest/blob/18fe5ac5ecb781b569a0abf107b0858acf97984a/src/main/java/io/vincenzopalazzo/lightning/rest/utils/ServerUtils.java#L104 10:10 < mschmoock> yeah thats also possible 10:10 < vincenzopalazzo> But I'm no an expert of python, maybe with exception catch it is good too, in my case with Java it is not. 10:11 < mschmoock> not sure whats better. help uses less resources. the other one does not rely on human readable output 10:11 < vincenzopalazzo> maybe this morning Christian Decker said also this solution 10:12 < vincenzopalazzo> mschmoock: The things that I'm worrry when I catch the exception is all the stack trace that the interpreter in this case need to mantains to give details 10:13 < mschmoock> which is why I raise if I get an exception that I dont expect 10:13 < vincenzopalazzo> Also, with the analysis of the help command you can parse the result in parallel, but it is not the case of python 10:14 < mschmoock> guess your right 10:14 < mschmoock> will implement both versions and let others decide :D 10:15 < vincenzopalazzo> benchmark is the answer :D 10:16 < mschmoock> has someone seen Zmn recently? 10:19 < vincenzopalazzo> mschmoock: I ask a couple of question about clboss by email last month 10:19 < mschmoock> did he answer? 11:12 < niftynei> openoms: there's a quick python example of how to pull features out of featurebits in the FAQ section on channel state loss 11:12 < niftynei> https://github.com/ElementsProject/lightning/blob/master/doc/FAQ.md#database-corruption--channel-state-lost 11:12 < vincenzopalazzo> mschmoock: Sorry, I miss it, yes after a couple of week 11:12 < niftynei> you just need to know the number of the feature that you're looking for 11:13 < openoms[m]> thank you, that is very useful! 11:15 < openoms[m]> this tells me I am looking for 0/1 instead of 12/13 in the example https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md#bolt-9-assigned-feature-flags 12:10 < niftynei> yes 0/1 are the bits for `option_data_loss_protect` 12:48 < vincenzopalazzo> mschmoock: About the summary plugin, there is any method to have a json report? 15:15 < vincenzopalazzo> protocol testing with lnprototest is finally happy with all github actions :) https://github.com/ElementsProject/lightning/pull/4517 15:19 -!- Netsplit *.net <-> *.split quits: lxer, face, nathanael, vincenzopalazzo, berndj, niftynei, belcher, achow101, Dan[m], livestradamus, (+31 more, use /NETSPLIT to show all of them) 15:25 -!- Netsplit over, joins: michaelfolkson, dr-orlovsky, DeanGuss, ksedgwic, belcher, openoms, willcl_ark, qubenix, _0x0ff, kanzure (+31 more) 15:28 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Ping timeout: 272 seconds] 15:28 -!- lxer [~lx@95.91.246.102] has quit [Ping timeout: 252 seconds] 15:28 -!- cdecker[m] [~cdeckerma@2001:470:69fc:105::2e8e] has quit [Ping timeout: 272 seconds] 15:28 -!- Dan[m] [~drobertsm@2001:470:69fc:105::c80] has quit [Ping timeout: 272 seconds] 15:28 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Ping timeout: 272 seconds] 15:28 -!- openoms[m] [~openomsma@2001:470:69fc:105::c2f] has quit [Ping timeout: 272 seconds] 15:28 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Ping timeout: 272 seconds] 16:42 -!- ichack17 [~ichack17@2601:18c:8401:7e30::22e4] has joined #c-lightning 17:00 -!- aechu [~major@gateway/tor-sasl/major] has quit [Remote host closed the connection] 17:00 -!- aechu [~major@gateway/tor-sasl/major] has joined #c-lightning 17:07 -!- belcher_ [~belcher@user/belcher] has joined #c-lightning 17:11 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 246 seconds] 17:13 -!- jonatack [jonatack@user/jonatack] has quit [Quit: Ping timeout (120 seconds)] 18:05 -!- ichack17 [~ichack17@2601:18c:8401:7e30::22e4] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:08 -!- ichack17 [~ichack17@2601:18c:8401:7e30::22e4] has joined #c-lightning 18:36 -!- ichack17 [~ichack17@2601:18c:8401:7e30::22e4] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 19:32 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 22:56 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has joined #c-lightning --- Log closed Fri Jun 25 00:00:48 2021