--- Log opened Fri Mar 06 00:00:18 2020
00:01 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 265 seconds]
00:08 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
00:10 < m-schmoock> vasild: yes, im right now trying to tell my vim to regard .editorconfig or clang-format
00:13 < vasild> m-schmoock: for editorconfig I am using a vim plugin: github.com/editorconfig/editorconfig-vim, but editorconfig is really limited compared to clang-format. I think one should fall back to editorconfig only if clang-format is not available for him for some reason.
00:15 < vasild> integrating clang-format is even easier: just drop this line into your vimrc:
00:15 < vasild> " Invoke clang-format with ctrl+i
00:15 < vasild> map <C-I> :py3file /usr/local/llvm10/share/clang/clang-format.py<cr>
00:16 < vasild> (that .py script is installed with clang)
00:23 < vasild> Hmm, maybe put some of the above to doc/STYLE.md, at least a mention of .clang-format and .editorconfig?
02:11 < vasild> Aha! I think I know why the libwally-core build issue manifested again even though my PR is rebased and includes the fix and also why yesterday my mods to external/Makefile seemed to not be picked up by travis -- https://github.com/ElementsProject/lightning/blob/master/.travis.yml#L41. The ./external directory is cached. Solution: https://docs.travis-ci.com/user/caching/#clearing-caches <--- cdecker
02:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
03:16 <@cdecker> Doh! Thanks vasild, I should've figured that out, my bad
03:18 <@cdecker> It's a peer-branch cache, so that'd explain the intermittent results on some branches/PRs and not others
03:18 <@cdecker> I cleared all caches I could find :-)
03:22 < vasild> :-)
03:26 < vasild> cdecker: I wonder how this caching works - would it first checkout everything from git and then replace ./external with a version from the cache or the other way around - first plant ./external from the cache and then pull from git?
03:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning
03:32 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
03:38 <@cdecker> I think it does, yes. looking at the logs it checks out and then replaces the cached directories
03:39 < m-schmoock> vasild: editorconfig does for me, i like it slick
03:39 <@cdecker> I think we save ~2mins of compile time on each configuration and run, which is kind of a neat optimization
03:40 < vasild> cdecker: yes, I just observed the same - first git checkout and then overwrite from cache
03:42 < m-schmoock> cdecker: are we going to deprecate all these non-msat, pure integer amounts, notations in the JSON RPC eventually? It really starts looking confusing...
03:42 < vasild> hmm, we can cache just the build directories, assuming out-of-source builds?
03:43 <@cdecker> m-schmoock: not sure, that'd be a major breaking change in the interface, so we better make sure that's the direction we want to go in
03:43 <@cdecker> (personally I dislike unit suffixes in what is supposed to be a programming interface, not a human interface...)
03:44 <@cdecker> vasild: excellent idea, I'm not really familiar with out-of-source builds, any pointers where to look?
03:44 < m-schmoock> ah, anyway going both ways until infinity looks a bit silly
03:44 < m-schmoock> it does not hurt though
03:45 < vasild> cdecker: convert everything to cmake! ;-)
03:45 <@cdecker> rofl, talk to rusty ^^
03:46 < vasild> well, we already do out-of-source builds in external/Makefile: mkdir -p ${TARGET_DIR}/libsodium-build
03:46 < vasild> and mkdir -p ${TARGET_DIR}/libwally-core-build
03:47 < m-schmoock> hows that building on ARM/Android topic going on?
04:01 < vasild> external/jsmn-build external/libbacktrace-build external/libsodium-build external/libwally-core-build -- looks like it would be easy
04:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
04:02 < vasild> we already compile those out-of-source
04:02 < vasild> I wonder what will break if we cache just these directories...
04:02 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
04:03 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning
04:05 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
04:06 -!- k3tan [~pi@unaffiliated/k3tan] has quit [Ping timeout: 265 seconds]
04:06 -!- GAit [~GAit@unaffiliated/gait] has quit [Ping timeout: 265 seconds]
04:07 -!- k3tan [~pi@unaffiliated/k3tan] has joined #c-lightning
04:07 < vasild> maybe timestamps of the .c files and of the .o files will not be as expected
04:07 <@cdecker> We can cache them and then call `make submodcheck` to update to the ones we were expecting
04:08 < vasild> I think its is worth experimenting
04:08  * vasild bbl
04:09 -!- GAit [~GAit@unaffiliated/gait] has joined #c-lightning
04:14 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
04:16 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
04:47 < darosior> m-schmoock: great I'm now making a Kivy Around wrapper around the 0.8.1 release
04:48 < darosior> But didn't find the time to get back to it since two weeks ago..
04:48 < darosior> s/Kivy Around/Kivy Android/
04:55 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
05:38 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
05:38 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
05:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]
05:57 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]
05:59 -!- rafalcpp_ [~racalcppp@ip-178-211.ists.pl] has quit [Ping timeout: 256 seconds]
06:00 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
06:00 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Client Quit]
06:00 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
06:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:05 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 256 seconds]
06:07 -!- jonatack [~jon@134.19.179.235] has joined #c-lightning
06:30 < m-schmoock> darosior: awesome. Can't wait for the first non-custodial, fullnode clightning mobile wallet
06:31 < darosior> :)
06:32 < darosior> I'll give you the repo once I have something runable
06:37 < m-schmoock> I think we would also need some modifications on the bitcoind interface, having fullnode bitcoind on mobile will not be suitable
06:39 < zmnscpxj> Yes, we need a `isblockrelevant blockId [addr1, addr2, outpoint1, outpoint2]` to the bitcoind interface.
06:39 < m-schmoock> yep, and then run it in full pruned at least
06:40 < zmnscpxj> Then the backend interface uses whatever magic it has (e.g. Neutrino) to determine if the block is relevant to the C-Lightning node.
06:40 < zmnscpxj> and probably we could optionally drop historic channels that we cannot verify due to dropping their blocks out
06:42 < m-schmoock> maybe ship a potential wallet (incl pruned bitcoind) with a pruned+synced blockchain until release build. but in this case the APK will be to big i guess
06:42 < m-schmoock> libbitcoin can operator by starting at a given block when the wallet was created via libbitcoin
06:43 < m-schmoock> *operate
06:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
07:17 < darosior> m-schmoock: I plan to make an API for this, but for the tests I used an Esplora instance
07:18 < darosior> Like https://github.com/lightningd/plugins/pull/89
07:19 < darosior> What I do is I replace bcli with a Bitcoin plugin hitting my API over bitcoind at home
07:20 < darosior> That way only the heavy part of the LN node is externalized (bitcoind), and you have your wallet on your phone instead of using a remote control
07:25 < m-schmoock>  while technically possible, not end user friendy :D but the end-user friendly crowd is already using phoenix wallet :D
07:25 < m-schmoock> so how cares
07:57 < darosior> haha
08:05 < m-schmoock> hmmm, should be able to deliver a pruned bitcoind packaged that is having the release date latest block as fake 'genesis' (no prior history) and then we simply add the real genesis 'offset' at the JSON RPC.  whacky  -QQQQo.O
08:07 < m-schmoock> the block index is not included in the header, so aside from being really really ugly it could actually work
08:47 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection timed out]
08:49 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning
08:52 -!- jonatack [~jon@134.19.179.235] has quit [Ping timeout: 255 seconds]
08:54 -!- jonatack [~jon@37.171.246.141] has joined #c-lightning
08:55 < darosior> If you really want bitcoind on your phone why not using abcore ?
08:55 < darosior> I guess it can be pruned
09:30 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
09:32 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
09:33 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Quit: Leaving]
09:59 < m-schmoock> darosior: I think that might be too heavy for data usage, for a mobile clightning a headers only partial syncing library should doe it (like schildbach wallet has)
09:59 < m-schmoock> not sure if we can adapt to bitcoinj
10:16 -!- jtimon [~quassel@206.160.134.37.dynamic.jazztel.es] has joined #c-lightning
10:17 < jtimon> in https://lightning.readthedocs.io/lightning-invoice.7.html there's a preimage param, but how can I pass the payment hash directly instead of the preimage if I don't know the preimage?
10:17 < jtimon> For example, say alice want me to pay an invoice to carol because it's for another chain, and I want to create an invoice to alice with the same payment preimage than the invoice from carol to alice
10:19 < jtimon> that way I can use the invoice_payment hook when I receive payment for my invoice, try to pay carol's invoice, and if anything fails just not accept the payment
10:23 < jtimon> I guess I would also need a way to pass the preimage back from the invoice_payment once I get it from succesfully paying carol
10:47 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning
11:11 < m-schmoock> jtimon: I think a good way to see how this can be handled is to:   cd lightning.git/tests  ;  git grep payment_hash
11:11 < m-schmoock> for example in    tests/test_pay.py
11:12 < m-schmoock> `payment_hash` is returned by the `invoice` command and can be used in  `sendpay` directly (as second arg, first is the route)
11:13 < m-schmoock> generally,   `git grep` is a _very_ good friend :D
11:19 < m-schmoock> hopr that helps a bit
11:21 -!- Maitor [~goban@gateway/tor-sasl/maitor] has quit [Ping timeout: 240 seconds]
11:24 -!- Maitor [~goban@gateway/tor-sasl/maitor] has joined #c-lightning
11:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
11:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
11:52 -!- Amperture [~amp@65.79.129.113] has joined #c-lightning
12:10 -!- vasild_ is now known as vasild
12:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
13:11 -!- Netsplit *.net <-> *.split quits: gwillen, otoburb, Ed0, drolmer, grubles, berndj, ysangkok, qubenix, asoltys
13:12 -!- Netsplit over, joins: gwillen, asoltys, berndj, qubenix, grubles, otoburb, drolmer, Ed0, ysangkok
13:13 -!- drolmer [~drolmer@unaffiliated/drolmer] has quit [Max SendQ exceeded]
13:17 -!- drolmer [~drolmer@unaffiliated/drolmer] has joined #c-lightning
13:42 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
13:42 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
14:11 < fiatjaf> darosior: how can I know what kind of argument lightningd passes to bcli and what kind of response it expects?
14:11 < fiatjaf> I tried running bcli directly and manually calling methods on it from stdin
14:11 < fiatjaf> but it crashed on "getmanifest"
14:13 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
14:17 < fiatjaf> oh I see
14:17 < fiatjaf> getchaininfo just replicates getblockchaininfo
14:17 < fiatjaf> but does lightningd expect ALL that?
14:27 < k3tan> does c-lightning support reciprocal channels yet?
14:35 < fiatjaf> k3tan: no
14:40 < fiatjaf> please ignore my messages, I've found my way through the code, it was great
14:50 -!- jonatack [~jon@37.171.246.141] has quit [Read error: Connection reset by peer]
14:54 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
15:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
15:30 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:52 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning
15:58 -!- notplato [4cae81cb@cpe-76-174-129-203.socal.res.rr.com] has joined #c-lightning
16:53 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
16:59 -!- vincenzopalazzo [~vincent@89.34.99.79] has joined #c-lightning
17:24 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 255 seconds]
17:28 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
17:55 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
17:59 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 240 seconds]
18:04 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
18:05 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
18:16 -!- notplato [4cae81cb@cpe-76-174-129-203.socal.res.rr.com] has quit [Ping timeout: 260 seconds]
18:19 -!- Amperture [~amp@65.79.129.113] has quit [Remote host closed the connection]
18:31 < fiatjaf> these "unrecognized option" failures are a big pain when you are testing plugins
18:31 < fiatjaf> sometimes you just want to replace a plugin, disable, reenable
18:31 < fiatjaf> and then you also have to tweak .lightning/config so lightningd won't complain of unrecognized options
18:32 < fiatjaf> just saying
18:34 -!- notplato [4cae81cb@cpe-76-174-129-203.socal.res.rr.com] has joined #c-lightning
18:35 < notplato> Eclair log shows that CL queried it for blocks 504500 and the following 115902 blocks.  Block 554714 is in that range, and CL replied with an error that it already had that block.  Is it really an error that Eclair sends data for a block within the queried range just because CL already had it?  Seems like a CL bug.
18:43 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
18:53 < notplato> Here is a chunk of the Eclair log that shows c-lightning requesting a range of blocks and then throwing an error because Eclair sent a block within that range which CL already had:
18:53 < notplato> ```received query_channel_range with firstBlockNum=504500 numberOfBlocks=116047 extendedQueryFlags_opt=TlvStream(List(QueryFlags(1)),List())
18:53 < notplato> onnection-level error, failing all channels! reason=reply_channel_range 562480+3200 already have block 562480
19:08 < notplato> It seems that c-lightning is not being a good downstream peer.  It requests a large chunk of blocks, gets one of them which it discovers it already has, and sends back an error. Am I misunderstanding the logs?
19:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
20:14 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 240 seconds]
20:19 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
22:01 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
22:02 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
22:04 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
22:05 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
22:07 -!- jtimon [~quassel@206.160.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds]
22:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
23:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
23:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
23:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
--- Log closed Sat Mar 07 00:00:16 2020