--- Day changed Wed Jul 25 2018 00:08 -!- RubenSomsen [uid301948@gateway/web/irccloud.com/x-rpfirxzzilscrfuo] has quit [Quit: Connection closed for inactivity] 00:51 -!- froyer [~froyer@124.19.31.4] has quit [Remote host closed the connection] 00:55 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #c-lightning 01:21 -!- froyer [~froyer@pa49-195-60-164.pa.nsw.optusnet.com.au] has joined #c-lightning 01:26 -!- froyer [~froyer@pa49-195-60-164.pa.nsw.optusnet.com.au] has quit [Ping timeout: 256 seconds] 01:43 -!- tiagotrs [~user@mue-88-130-105-171.dsl.tropolys.de] has joined #c-lightning 01:43 -!- tiagotrs [~user@mue-88-130-105-171.dsl.tropolys.de] has quit [Changing host] 01:43 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #c-lightning 02:46 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 02:51 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 260 seconds] 02:55 -githubby:#c-lightning- [lightning] SimonVrouwe closed pull request #1714: Prevent defaulting of feerate at first poll (master...exp-smoothing-feerate-estimates) https://git.io/fNsvn 03:01 -!- deusexbeer [~deusexbee@095-129-170-057-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 248 seconds] 03:03 -!- deusexbeer [~deusexbee@080-250-075-105-dynamic-pool-adsl.wbt.ru] has joined #c-lightning 03:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:07 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning 03:56 < molz> so for the latest master version 'alias' is not in 'listpeers' anymore and now we have "global_features": "", 03:56 < molz> "local_features": "", what are these for? 04:02 -!- renepickhardt [5882344e@gateway/web/freenode/ip.88.130.52.78] has joined #c-lightning 04:18 -!- farmerwampum [~farmerwam@88.202.178.98] has quit [Ping timeout: 264 seconds] 04:19 -!- froyer [~froyer@126.121.233.220.static.exetel.com.au] has joined #c-lightning 04:24 -!- froyer [~froyer@126.121.233.220.static.exetel.com.au] has quit [Ping timeout: 260 seconds] 04:34 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 04:39 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 248 seconds] 05:17 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds] 05:36 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning 05:50 -!- booyah [~bb@193.25.1.157] has quit [Remote host closed the connection] 06:23 -!- tiagotrs [~user@mue-88-130-105-171.dsl.tropolys.de] has joined #c-lightning 06:23 -!- tiagotrs [~user@mue-88-130-105-171.dsl.tropolys.de] has quit [Changing host] 06:23 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #c-lightning 06:25 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Client Quit] 06:40 < renepickhardt> can anyone tell my why in lightningd.c the argument of the function is called ctx? ( cf: static struct lightningd *new_lightningd(const tal_t *ctx) ) I was reading channel.c and I thought ctx would be short for commitment transaction. the argument is used only once in the function to allocate the tal_pointer for ld (struct lightningd) 06:44 -githubby:#c-lightning- [lightning] cdecker pushed 1 new commit to master: https://git.io/fNR9J 06:44 -githubby:#c-lightning- lightning/master 21e61a5 ueno: fix: make devtools-clean 06:53 < bitonic-cjp> renepickhardt: ctx is a memory allocation ConTeXt. 06:54 < bitonic-cjp> Lightningd uses a Tree ALlocation (tal) system. 06:54 < renepickhardt> ok so I can always think of it as some pointer for which the allocation of the memory of the desired object shall take place? I saw rusty also used the variable name in his ccan / tal repo 06:55 < renepickhardt> yeah I read about tal pointer and think from a high level I understand how they would work 06:55 < renepickhardt> so ligtningd is allocated via tal (as well as its fields) and when you free ld you don't need to free the children (in this case the fields of the struct) 06:55 < bitonic-cjp> The idea is: you allocate a parent object, and when you allocate child objects, you pass the parent object as context. 06:56 < renepickhardt> ah ok. this is how the link goes 06:56 < bitonic-cjp> When the parent object is freed, its child objects are freed as well (recursively if necessary). 06:56 < renepickhardt> it is not so much about being part of the struct (which I had thought so far) so I can basically have to completely independend pointers 06:57 < renepickhardt> and when I allocate the second pointer via tal I can give the first as a context meaning whenever I free the first the second will also be freed 06:58 < renepickhardt> which is the reason why struct lightningd *ld = tal(ctx, struct lightningd); works with ctx being NULL as there is no parent supposed to exist 07:02 < renepickhardt> do I understand it correctly that I can only bind a new pointer to a parant by providing the parent pointer in tal or talz but I can't later say: "I want this to my child" 07:03 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 07:04 < bitonic-cjp> you can do tal_steal to let something that was allocated as A's child become B's child. 07:05 < renepickhardt> thx 07:25 < renepickhardt> just to make sure ..._fd means file descriptor and could be a socket or a real file? 07:26 < bitonic-cjp> I can't guarantee that for all code, but yes, fd is a frequently used abbreviation for file descriptor, which can indeed be a socket or a real file or anything else a UNIX file descriptor can be. 07:32 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 07:33 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning 07:36 -!- tiagotrs [~user@mue-88-130-105-171.dsl.tropolys.de] has joined #c-lightning 07:36 -!- tiagotrs [~user@mue-88-130-105-171.dsl.tropolys.de] has quit [Changing host] 07:36 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #c-lightning 07:44 < blockstream_bot> [Hugo Doyon, Blockstream] Hi, I have satoshis missing after channel closure from http://rompert.com node (wake up this morning and realized they close the channel and 8050 satoshis are missing ) Initial channel funding was 100000 satoshis, no transaction done with them, the onchain transaction fee for closure is 202 satoshis :S Where is the remaining part? Anyone can explain that why the did not return me 99798 sat 07:47 < renepickhardt> can you post the txid if the funding transaction opening the channel? 07:51 < blockstream_bot> [Hugo Doyon, Blockstream] Funding txid = 627aecd6242adeec3b62b5ca2e2c8dc6f8a002ff6313c3454073dff97bec1614, closing txid = dfe9abb1ce9a0b35e11ce72e277bbaec09a3dd86f4e5e948b111995a47617781 07:52 < blockstream_bot> [Hugo Doyon, Blockstream] node name is not http://rompert.com but satoshis.place (my mistake) 07:55 < blockstream_bot> [Hugo Doyon, Blockstream] I made no payment with this node yet. Only connect and open channel (listpayments and listinvoices are both empty) 07:55 < renepickhardt> the blockexplorer shows that there was some intermediary tx https://www.smartbit.com.au/tx/fbe74f72da13ee9f3990860b25c0a3054757351ee680da1246f00eadf047be2b 07:55 < blockstream_bot> [Hugo Doyon, Blockstream] asdf@ubuntu-ln-001:~/lightning# cli/lightning-cli listpayments 07:55 < blockstream_bot> { 07:55 < blockstream_bot> "payments": [ 07:55 < blockstream_bot> ] 07:55 < blockstream_bot> } 07:55 < blockstream_bot> asdf@ubuntu-ln-001:~/lightning# cli/lightning-cli listinvoices 07:55 < blockstream_bot> { 07:55 < blockstream_bot> "invoices": [ 07:55 < blockstream_bot> ] 07:55 < blockstream_bot> } 07:55 < renepickhardt> which has exactly the fee that you mentioned 07:57 < blockstream_bot> [Hugo Doyon, Blockstream] humm intermediary fee? what is that? 07:58 < renepickhardt> no what I mean is if you look at your funding tx 627aecd6242adeec3b62b5ca2e2c8dc6f8a002ff6313c3454073dff97bec1614 it has two outputs 07:58 < blockstream_bot> [Hugo Doyon, Blockstream] yep 07:58 < blockstream_bot> [Hugo Doyon, Blockstream] channel opening and change 07:59 < renepickhardt> keyhash (which probably was your change) and a script hash 07:59 < renepickhardt> so the script hash was spent with this tx: https://www.smartbit.com.au/tx/fbe74f72da13ee9f3990860b25c0a3054757351ee680da1246f00eadf047be2b 07:59 < renepickhardt> which has a fee of 8050 satoshi 08:01 < renepickhardt> and that tx has one output whish is P2SH and was spent by the tx that you called the closing tx. I would guess that the one that I mentioned was the closing tx and the one that you mentioned took place when you used ./lighting-cli withdraw ? 08:02 < renepickhardt> does that make sense? 08:02 < blockstream_bot> [Hugo Doyon, Blockstream] I dit not do any withdraw ethier 08:04 < blockstream_bot> [Hugo Doyon, Blockstream] My understanding is that there is a onchain fee for opening a channel and closing a channel. But what is this intermediary P2SH address things? 08:05 < renepickhardt> to me it looks like a mutual close since the spend of the funding tx has exactly one output. sorry can't tell you more from here 08:06 < renepickhardt> well it could have been an unilateral close. in which even if the funding tx is spend with only one output there is the time lock. this is the intermediatry p2sh address and then the second tx is claming the output after the timelock 08:07 < renepickhardt> that is actually what it looks like to me. if you compare the difference of blockheight between fbe74... and dfe9a... this shows there is 145 blocks difference 08:07 < blockstream_bot> [Hugo Doyon, Blockstream] ok 08:08 < renepickhardt> so your node published the commitment tx with a pretty high fee (dunno why it used 53 B/ sat) and the commitment tx has your funds on a relative time lock which was then claimed after 144 blocks with dfe9a... 08:08 < blockstream_bot> [Hugo Doyon, Blockstream] so it look like they close the channel unilateraly? 08:08 < renepickhardt> at least this is how I would interpret the situation 08:09 < renepickhardt> from what I see on the blockchain and from what you are telling me I would say yes (but obviously I was not sitting on your machine) 08:10 < blockstream_bot> [Hugo Doyon, Blockstream] ok then how do a broadcast a transaction to correct the situation? 08:10 < renepickhardt> what do you mean correct? 08:11 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 08:11 < blockstream_bot> [Hugo Doyon, Blockstream] if they close the channel with the wrong amount unilateral I should be able to broadcast a transaction to correct this 08:11 -githubby:#c-lightning- [lightning] wythe opened pull request #1751: Add lightningd-config(5) to install (master...add-man5) https://git.io/fNRhU 08:12 -!- annonch [d82f98f2@gateway/web/freenode/ip.216.47.152.242] has joined #c-lightning 08:12 -!- qubenix [~qubenix@185.65.135.179] has quit [Remote host closed the connection] 08:13 < renepickhardt> they cannot close the channel unilaterally with a wrong amount. just with an old state 08:14 < renepickhardt> in case that happens the output of the commitment tx they broadcast can be collected by u with the help of the revocation key of the other side 08:15 < renepickhardt> they must have exchanged that key with you while you sign off a new commitment tx 08:15 < blockstream_bot> [Hugo Doyon, Blockstream] ok. but do I have to handle that with a specific command or it's manage automagicly with c-lightning 08:15 < renepickhardt> should be automatically 08:16 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 260 seconds] 08:16 < renepickhardt> only problem is that commitment tx has two outputs one with the time lock which can be spent directly once your c lightning code provides that key (which works automatically and does work) and the other one is an output which only you can spend anyway. I filed a bug two days ago because c lightning had problems collecting it 08:19 < blockstream_bot> [Hugo Doyon, Blockstream] ok. My understanding is that when a channel is funded the satoshis goes in a HTLC multisig wallet. When a channel close the satoshis in the wallet goes back to the the node original wallet in proportion of the spending wright? 08:20 < renepickhardt> on a high level yes. (the word HTLC is not neccessary here). 08:21 < renepickhardt> when there is a mutual close there will be one transaction sending the satoshis back according to the balance. but if some one published the commitment transaction (unilateral close) then the situation is a little bit different 08:22 < renepickhardt> I recently did a presentation on it https://commons.wikimedia.org/w/index.php?title=File:Examining_the_lightning_network_on_a_protocol_level.pdf&page=37 (page 37 of the pdf file and the following would explain the situation) 08:23 < renepickhardt> so what happend is that the fbe74 was the RSMC transaction which your node after the time lock has successfully claimed therefor you see 3 txs on the blockchain 08:25 < blockstream_bot> [Hugo Doyon, Blockstream] RSMC ? 08:27 < annonch> Hey all trying to get started with c-lightning, firstly just trying to see how the Bolt 3 creating the transactions part is working. can someone correct me if I am mistaken: it seems that the bitcoin directory holds the support functionality like encoding and signatures for forming transactions, while the ccan directory is like types and stuff while the onchain directory actually forms the transactions. 08:28 < annonch> I want to be able to run the tests for individual parts of the code so I can better understand the components so I was wondering if there are directions to do that 08:32 < renepickhardt> RSMC = Revocable Sequence Maturity Contract. this is the script that is being used to spend the time locked output (it is written down exactly on page 37 of that pdf) The term is not as known as HTLC (to some degree you could say they are also somewhat similar though it is definately not the same) 08:33 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 08:37 < renepickhardt> anyone here can explain line 342 in lightningd.c ? /* We do extra checks in io_loop. */ io_poll_debug = io_poll_override(io_poll_lightningd); my question is that io_poll_lightningd seems to be defined as a static function with several parameters but only the name is given) that does not make any sense to me 08:38 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 268 seconds] 08:40 < blockstream_bot> [Hugo Doyon, Blockstream] Amazing pdf Rene, I will read it in detail for sure! But now my understanding is when a channel is close unilateraly is that there is another on chain transaction that is created were fund are move from one P2SH wallet to another P2SH where both party can claim the balance and dispute with key, thus it explain the 8050 satoshis of fee of the intermediary transaction? Did I got wright? 08:42 < renepickhardt> sounds good. what you say. I would express this a little different but I think you got the right meaning 08:42 < renepickhardt> the intermediary transaction is the commitmentransaction which spends the funding tx 08:42 < renepickhardt> the output script of the commitment transaction is the third transaction which can spend whoever has the correct keys 08:43 < renepickhardt> the reason why you can't spend the outputs of the commitment transaction directly is because then you could probably not invalidate the transaction when there is a channel update 08:45 < blockstream_bot> [Hugo Doyon, Blockstream] ok great I understand. But why the other node did a unilateral close of the channel? 08:46 < blockstream_bot> [Hugo Doyon, Blockstream] (it the second node that is doing that to my node) 08:51 < renepickhardt> the fact that you claimed your outputs only after 144 blocks suggests that you did the unilateral close. if the other side closed the channel you would have been able to redeem your outputs directly 08:51 < renepickhardt> and I don't know why channels are being closed. you would have to look in your logfiles and post them or file an issue on github 08:52 -!- rq732p [uid310871@gateway/web/irccloud.com/x-wwjwrhrwxntbvkwx] has quit [Quit: Connection closed for inactivity] 08:53 < blockstream_bot> [Hugo Doyon, Blockstream] So what you suggest is that my node did a unilateral close? 08:54 < blockstream_bot> [Hugo Doyon, Blockstream] Is that a default HTLC timeout (144 blocks)? 08:54 -githubby:#c-lightning- [lightning] SimonVrouwe opened pull request #1752: at startup initialize smoothed feerate to polled feerate (master...init-smoothing) https://git.io/fN0fx 08:55 -!- grafcaps [~haroldbr@104.137.194.255] has joined #c-lightning 08:57 < renepickhardt> yeah from the information u shared I would be 99% confident that your node unilaterally closed the channel. the default RSMC timeout is 144 blocks there was not HTLC involved at this point 08:57 < blockstream_bot> [Hugo Doyon, Blockstream] The thing is that I did not close the channel manually or did not withdraw funds either from this channel. So who created the fbe74f...7be2b transaction? 08:58 < renepickhardt> the f transaction was created while opening the channel 08:59 < renepickhardt> it needs to be there in order to make sure that you can close the channel unilaterally 08:59 -!- Drolmer [~Drolmer@unaffiliated/drolmer] has quit [Ping timeout: 256 seconds] 08:59 -!- froyer [~froyer@126.121.233.220.static.exetel.com.au] has joined #c-lightning 08:59 < renepickhardt> only if it is signed of by both sides the funding transaction will be broadcasted and the channel is being created 08:59 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 240 seconds] 09:00 < renepickhardt> the question is rather why did your node broadcast the the fbe... transaction. I guess we won't find out unless you provide some excerpt from the logs 09:00 < renepickhardt> but a lightning client could assume something suspecious is going on or lost contact with a peer and just wants to be on the safe side 09:00 -!- Drolmer [~Drolmer@unaffiliated/drolmer] has joined #c-lightning 09:01 < renepickhardt> so in general you don't have to initiate an unilateral close. it could happen automatically as part of the process 09:02 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving] 09:02 < blockstream_bot> [Hugo Doyon, Blockstream] ohh your right that my mistake I mean the dfe9abb1ce9a0b35e11ce72e277bbaec09a3dd86f4e5e948b111995a47617781 09:03 -!- froyer [~froyer@126.121.233.220.static.exetel.com.au] has quit [Ping timeout: 248 seconds] 09:05 < blockstream_bot> [Hugo Doyon, Blockstream] The correct log to check if cli/lightning-cli getlog or the log in the lightning folder? 09:06 < renepickhardt> well the dfe9 is even more part of the process. because the unilateral close is only done when you redeem your funds from the revocable delivery (which is the way the commitment was formulated) 09:07 < renepickhardt> well you can check both logs or someone else here has to jump in. 09:10 -!- grafcaps [~haroldbr@104.137.194.255] has joined #c-lightning 09:10 < blockstream_bot> [Hugo Doyon, Blockstream] check log ... 09:14 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving] 09:14 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #c-lightning 09:20 < annonch> what is "config.h" which is imported in many files. Is this something that is created when running configure? 09:23 < annonch> oh nvm I get it now 09:23 < blockstream_bot> [Hugo Doyon, Blockstream] Will dig deeper in your precious pdf Rene and investigate ! Thank for your help! 09:28 < renepickhardt> do I understand correctly that all those main functions are just need for testing? and that the only main that actually is ever called is the one in lightningd.c ? 09:56 -!- booyah [~bb@193.25.1.157] has joined #c-lightning 09:56 -!- qubenix [~qubenix@38.132.120.4] has joined #c-lightning 10:25 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning 10:39 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #c-lightning 11:24 -githubby:#c-lightning- [lightning] cdecker opened pull request #1755: Separately shut down the JSON-RPC subsystem in a DB transaction (master...issue-1737) https://git.io/fN0Cv 11:28 -!- shesek [~shesek@bzq-84-110-232-73.cablep.bezeqint.net] has joined #c-lightning 11:28 -!- shesek [~shesek@bzq-84-110-232-73.cablep.bezeqint.net] has quit [Changing host] 11:28 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 12:28 -!- yoyo_ [uid312116@gateway/web/irccloud.com/x-feqdpydjzjnobycj] has joined #c-lightning 12:53 -!- froyer [~froyer@126.121.233.220.static.exetel.com.au] has joined #c-lightning 12:57 -!- froyer [~froyer@126.121.233.220.static.exetel.com.au] has quit [Ping timeout: 256 seconds] 13:06 < blockstream_bot> [MattK, Blockstream] 13:07 < blockstream_bot> [MattK, Blockstream] The previous is a chunk of code that I am attempting to understand. 13:17 < yoyo_> i am trying to make a payment from the eclair wallet to my c-lighting node and i cannot get a route although i have opened channels with some of the big public nodes like yalls.org and htlc.me any clues ? 13:17 < yoyo_> on testnet 13:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 13:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning 13:44 < molz> yoyo_, do both of your c-lightning node and eclair node have channels with Endurance node? 13:46 < molz> yoyo_, try this: get both of those nodes to open channels with Endurance node: 03933884aaf1d6b108397e5efe5c86bcf2d8ca8d2f700eda99db9214fc2712b134@34.250.234.192:9735 13:47 < molz> yoyo_, and then get Eclair to pay for several cups of coffee at Starblocks: https://starblocks.acinq.co/ 13:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #c-lightning 13:47 < roasbeef> yoyo_: bigger != better 13:47 < molz> then try again to see if Eclair can pay your c-lightning node, which i'm sure it will be able then 13:47 < renepickhardt> anyone has an idea why I can't attach lightningd to gdb? 13:48 < Chris_Stewart_5> any reason why I would be getting a wallet error like this: https://pastebin.com/2HgKZeys 13:48 < renepickhardt> I have finally managed to have the project running from within eclipse but attaching gdb does not work :( 13:48 < Chris_Stewart_5> My lightningd has `network=regtest` in config and bitcoin.conf 13:49 < Chris_Stewart_5> bitcoin-cli getblockchaininfo returns regtest 13:50 < yoyo_> just did that waiting for the channel to establish thanks :) 13:51 < Chris_Stewart_5> The lightning config file: https://pastebin.com/q8qWcTEp 13:53 < molz> Chris_Stewart_5, but the .lightning data is from a different chain? 13:54 < Chris_Stewart_5> molz: Does lightningd not partition like bitcoind? 13:55 < molz> im not sure if it does now, it didn't in the past 13:56 < Chris_Stewart_5> hmm, i'm on v0.6, so maybe not. I do see I have a .lightning-regtest dir 14:09 < polydin> hey all, shouldn't there be a crash log generated if i started `lightningd` with `--log-level=debug` ? 14:10 < polydin> gossipd failed with STATUS_FAIL_MASTER_IO 14:16 < polydin> renepickhardt, i've been able to attach lightningd to gdb 14:16 < renepickhardt> I guess on the command line or via eclipse? 14:17 < polydin> i work on ubuntu, it was on the command line 14:17 < polydin> renepickhardt, are you using eclipse 14:18 < renepickhardt> yeah 14:18 < polydin> renepickhardt, alas i have no exp with eclipse 14:18 < renepickhardt> after studying the protocol I have started reading the code yesterday. I think some ide would help since I see call hierarchies and similar things 14:18 < polydin> renepickhardt, the inability to attach lightningd to gdb shouldn't be because of lightningd 14:19 < renepickhardt> also I am not so experienced with c... but what choice do I have 14:19 < yoyo_> i am directly connected to eclair on my c-lighting node and on the eclair wallet after buying several coffees in starblock still getting a peer on the route failed ... any sugestions ?cli/lightning-cli getroute 03933884aaf1d6b108397e5efe5c86bcf2d8ca8d2f700eda99db9214fc2712b134 0 0 14:19 < yoyo_> { 14:19 < yoyo_> "route": [ 14:19 < yoyo_> { 14:19 < yoyo_> "id": "03933884aaf1d6b108397e5efe5c86bcf2d8ca8d2f700eda99db9214fc2712b134", 14:19 < yoyo_> "channel": "1355445:1947:1", 14:19 < yoyo_> "msatoshi": 0, 14:19 < yoyo_> "delay": 9 14:19 < yoyo_> } 14:19 < yoyo_> ] 14:19 < yoyo_> } 14:19 < Chris_Stewart_5> molz: I don't think lightningd is reading my config :-( 14:20 < renepickhardt> well I saw the statement in the documentation that one can attach single deamons to gdb but for now I just want to be able to execute the code step by step and track variables - which I guess would ease up the process of reading the code 14:20 < polydin> renepickhardt, are you working on windows? 14:20 < renepickhardt> mac os 14:20 < molz> Chris_Stewart_5, hm.. i think it would be best to separate the data files completely? 14:21 < renepickhardt> I could switch to ubuntu but I'd currently prefer to stay on macos 14:21 < polydin> renepickhardt, should be able to use terminal to attach pretty easily 14:21 < polydin> no macos is fine you can run unix commands on it 14:22 < renepickhardt> yeah I could try that but as I said since I am basically not an experience c programmer I thought it might be easier to use the comfort from an gui based ide like eclipse when debugging 14:22 < renepickhardt> but I might very well just also learn gdb from the command line if the eclipse way turns out to be even more cumbersome 14:22 < polydin> renepickhardt, it's up to you i don't use IDEs 14:22 < renepickhardt> How did you attach gdb from the command line? 14:23 < polydin> renepickhardt, if you have lightningd running just type `ps -ef | grep lightningd` into a terminal to get the pid 14:23 < renepickhardt> and then gdb pid? 14:23 < polydin> renepickhardt, first run `gdb` alone in a terminal 14:24 < polydin> renepickhardt, then when the prompt comes up run `attach ` 14:24 < polydin> renepickhardt, and that should do it 14:24 < polydin> then you can do all the lovely gdb things you normall do 14:24 < polydin> you can't run `gdb ` from the get go for already running processes 14:24 < polydin> afaik 14:26 < polydin> oh wait you can totally run `gdb attach ` 14:26 < renepickhardt> rpickhardt$ ps -ef | grep lightningd 501 48758 48160 0 11:23pm ?? 0:01.26 /Users/rpickhardt/eclipse-workspace/lightning/lightningd/lightningd --testnet --bind-addr 127.0.0.1:9735 --announce-addr 88.130.52.78:9735 14:26 < renepickhardt> (gdb) attach 48758 Attaching to process 48758 Unable to find Mach task port for process-id 48758: (os/kern) failure (0x5). (please check gdb is codesigned - see taskgated(8)) 14:27 < polydin> make sure you have root priv 14:27 < renepickhardt> oh ok (: 14:28 < polydin> don't know if that's the problem but i need root priv to run `gdb attach ` on lightningd process 14:29 < renepickhardt> I go the other way around. I will first start to learn more about gdb with a very small c programm 14:29 < renepickhardt> in this setup I try weired stuff and it is not clear why it is not working 14:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 14:31 < polydin> good luck! :) 14:31 < renepickhardt> @polydin thanks for your help I am out for today anyway. kind of late in europe. trying more tomorrow 14:40 -!- renepickhardt [5882344e@gateway/web/freenode/ip.88.130.52.78] has quit [Ping timeout: 252 seconds] 14:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 256 seconds] 15:03 -!- shesek [~shesek@bzq-84-110-232-73.red.bezeqint.net] has joined #c-lightning 15:03 -!- shesek [~shesek@bzq-84-110-232-73.red.bezeqint.net] has quit [Changing host] 15:03 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 15:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 15:24 < grubles> how often does c-lightning rebroadcast transactions 15:25 < grubles> i'm using spruned and for some reason the funding tx did not get broadcasted 15:41 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving] 16:02 < molz> grubles, at the current state, i'm afraid to try spruned or pruned 16:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #c-lightning 16:13 < grubles> yeah it does not seem to play nice with c-lightning anymore 16:21 -!- froyer [~froyer@124.19.31.4] has joined #c-lightning 16:27 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 244 seconds] 16:32 -!- froyer [~froyer@124.19.31.4] has quit [Ping timeout: 256 seconds] 16:58 -!- qubenix [~qubenix@38.132.120.4] has quit [Remote host closed the connection] 17:01 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 256 seconds] 17:01 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 17:06 -!- froyer [~froyer@124.19.31.4] has joined #c-lightning 17:28 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 244 seconds] 17:42 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 18:02 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has quit [Ping timeout: 256 seconds] 18:06 -!- jpe__ [~jpe@200116b8428ba500d32346fca66cf31a.dip.versatel-1u1.de] has joined #c-lightning 18:09 -!- jpe_ [~jpe@200116b8420b1b007e36f4caa2b6fc55.dip.versatel-1u1.de] has quit [Ping timeout: 260 seconds] 18:21 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 19:10 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 268 seconds] 19:11 -!- froyer [~froyer@124.19.31.4] has quit [Remote host closed the connection] 19:13 -!- froyer [~froyer@124.19.31.4] has joined #c-lightning 19:14 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 19:18 -!- froyer [~froyer@124.19.31.4] has quit [Ping timeout: 260 seconds] 20:07 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 260 seconds] 20:12 -!- qubenix [~qubenix@178-175-142-195.static.as43289.net] has joined #c-lightning 20:20 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 20:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 20:22 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning 20:25 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 20:59 -!- mn3monic [~xxwa@host39-21-dynamic.14-87-r.retail.telecomitalia.it] has quit [Ping timeout: 268 seconds] 21:05 -!- mn3monic [~xxwa@host39-21-dynamic.14-87-r.retail.telecomitalia.it] has joined #c-lightning 21:08 -!- froyer [~froyer@124.19.31.4] has joined #c-lightning 21:59 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 22:42 -githubby:#c-lightning- [lightning] rustyrussell closed pull request #1751: Add lightningd-config(5) to install (master...add-man5) https://git.io/fNRhU 23:02 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #c-lightning 23:06 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 260 seconds] 23:24 -!- froyer [~froyer@124.19.31.4] has quit [Remote host closed the connection] 23:24 -!- froyer [~froyer@124.19.31.4] has joined #c-lightning 23:27 -!- ken2812221 [~User@1.200.198.248] has quit [Ping timeout: 260 seconds] 23:29 -!- froyer [~froyer@124.19.31.4] has quit [Ping timeout: 265 seconds] 23:32 -!- froyer [~froyer@124.19.31.4] has joined #c-lightning 23:46 -!- froyer [~froyer@124.19.31.4] has quit [Remote host closed the connection] 23:49 -!- froyer [~froyer@124.19.31.4] has joined #c-lightning