--- Day changed Thu Mar 01 2018 00:01 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Ping timeout: 252 seconds] 00:21 -!- icota [~igor@cm-2230.cable.globalnet.hr] has joined #c-lightning 00:55 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection] 00:57 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 01:01 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 240 seconds] 01:07 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has joined #c-lightning 01:08 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Ping timeout: 265 seconds] 01:12 -!- sndr [~sander@185-61-53-164.185-61-53-ip.fmo-solutions.nl] has joined #c-lightning 01:12 -githubby:#c-lightning- [lightning] rustyrussell opened pull request #1142: Short channel id cleanup (master...short_channel_id-cleanup) https://git.io/vAMYC 01:27 -!- deusexbeer [~deusexbee@080-250-076-008-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 252 seconds] 01:28 -!- deusexbeer [~deusexbee@080-250-076-084-dynamic-pool-adsl.wbt.ru] has joined #c-lightning 01:32 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 01:34 -!- sndr [~sander@185-61-53-164.185-61-53-ip.fmo-solutions.nl] has quit [Quit: sndr] 01:35 -!- renlord [~ry@unaffiliated/renlord] has quit [Ping timeout: 265 seconds] 01:36 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 240 seconds] 01:36 -!- renlord [~ry@unaffiliated/renlord] has joined #c-lightning 01:38 -!- Mark__ [5bd4cf04@gateway/web/freenode/ip.91.212.207.4] has quit [Ping timeout: 260 seconds] 01:41 -!- sndr [~sander@185-61-53-210.185-61-53-ip.fmo-solutions.nl] has joined #c-lightning 01:42 -!- Mark__ [5bd4cf04@gateway/web/freenode/ip.91.212.207.4] has joined #c-lightning 02:30 -!- hba [55617ae8@gateway/web/freenode/ip.85.97.122.232] has joined #c-lightning 02:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 02:44 < bitonic-cjp> The way how config_log_stderr_exit works... WTF? I can see how it works now, but... really? 02:50 < bitonic-cjp> Is it OK if I try to fix it (it does have a FIXME comment)? 02:52 -!- hba [55617ae8@gateway/web/freenode/ip.85.97.122.232] has quit [Ping timeout: 260 seconds] 03:01 < p3tr> bitonic-cjp: please do, i quickly looked at it yesterday and i'm still not sure how exactly it works... and why 03:02 < bitonic-cjp> I know how it works, and why. You want me to give an explanation? 03:06 < mlz> bitonic-cjp, what does it do? and yes please explain 03:06 < bitonic-cjp> First, read opt_parse_from_config. It's the only place where config_log_stderr_exit is used. 03:07 < bitonic-cjp> The purpose of opt_parse_from_config is to read options from a config file. 03:08 < bitonic-cjp> It uses the "opt" module from ccan to parse options, but that module is really only built to parse commandline options. 03:08 < bitonic-cjp> So, what opt_parse_from_config does is: it reads the config file, and builds a commandline (argc, argv) from it. 03:09 -!- sndr [~sander@185-61-53-210.185-61-53-ip.fmo-solutions.nl] has quit [Quit: sndr] 03:09 < bitonic-cjp> Then, it calls opt_early_parse and opt_parse to process that commandline. 03:10 < bitonic-cjp> The problem is: what do you do when you encounter an error (e.g. a non-existing option name)? 03:10 < bitonic-cjp> What opt_*parse does is: it calls a callback function to log an error message. 03:11 < bitonic-cjp> The problem is: this error message is only understandable in the context of this artificial commandline, it makes no sense to the user. 03:12 < bitonic-cjp> config_log_stderr_exit is a callback function that is passed to opt_*parse, and translates the error message to something that is understandable in the context of a config file. 03:13 < bitonic-cjp> Now, config files have something that commandlines don't: line numbers! Rusty hacked a dirty way in this code to have line numbers in the error messages. 03:15 < bitonic-cjp> What he does is: he adds a string containing the line number *after* the terminating nul-character of the option string (opt_parse_from_config, line 539). 03:15 < bitonic-cjp> Then, in config_log_stderr_exit, line 500, he gives himself access to the line number again. 03:17 -!- sndr [~sander@185-61-53-164.185-61-53-ip.fmo-solutions.nl] has joined #c-lightning 03:17 < bitonic-cjp> This assumes, of course, that const char *arg points to the string that was constructed by opt_parse_from_config, not to some newly created string. 03:17 < bitonic-cjp> Clear? 03:18 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 03:19 -!- booyah [~bb@193.25.1.157] has joined #c-lightning 03:19 < p3tr> yes, interesting thank you 03:23 < bitonic-cjp> Fixing it is another issue, of course. If it were trivial, it wouldn't have a FIXME. 03:24 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 03:29 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 252 seconds] 03:31 < p3tr> to be honest in this case i don't think having the line numbers in the error messages are worth the trouble 03:33 < bitonic-cjp> Not *this* trouble, maybe. But I have a different idea. 03:45 -!- icota [~igor@cm-2230.cable.globalnet.hr] has joined #c-lightning 04:25 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-szaxntcyzblxvrqo] has quit [Quit: Connection closed for inactivity] 04:38 -!- sndr [~sander@185-61-53-164.185-61-53-ip.fmo-solutions.nl] has quit [Quit: sndr] 04:49 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 04:53 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 245 seconds] 04:54 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Ping timeout: 240 seconds] 05:03 -!- icota [~igor@cm-2230.cable.globalnet.hr] has joined #c-lightning 05:03 -!- llou [~textual@cm-83-97-182-195.telecable.es] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:20 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 05:23 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning 05:24 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 240 seconds] 05:26 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 05:59 -!- hkjn0 [~hkjn@4.128.198.35.bc.googleusercontent.com] has quit [Ping timeout: 240 seconds] 06:05 -!- hkjn0 [~hkjn@4.128.198.35.bc.googleusercontent.com] has joined #c-lightning 06:14 -githubby:#c-lightning- [lightning] bitonic-cjp opened pull request #1143: Add assertions in various places to ensure tal_fmt doesn't receive NULL as argument for strings. (master...patch2) https://git.io/vAMXs 06:40 -!- jasan [~jasan@2001:0:d91f:ca12:2cb2:3f17:a480:266c] has joined #c-lightning 06:47 -!- sndr [~sander@185-61-53-164.185-61-53-ip.fmo-solutions.nl] has joined #c-lightning 06:51 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #c-lightning 06:51 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 06:56 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 260 seconds] 07:05 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Remote host closed the connection] 07:08 -!- simlay [~simlay@gateway/tor-sasl/simlay] has joined #c-lightning 07:20 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 07:30 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 276 seconds] 07:37 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 256 seconds] 07:51 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Remote host closed the connection] 07:52 -!- kexkey [~kexkey@173.209.53.190] has quit [Ping timeout: 252 seconds] 07:56 -!- grafcaps [~haroldbr@50.90.26.145] has joined #c-lightning 08:01 -!- grafcaps [~haroldbr@50.90.26.145] has quit [Ping timeout: 248 seconds] 08:22 -!- grafcaps [~haroldbr@104.137.194.255] has joined #c-lightning 08:34 -!- llou [~textual@cm-83-97-182-195.telecable.es] has joined #c-lightning 09:16 -!- sndr [~sander@185-61-53-164.185-61-53-ip.fmo-solutions.nl] has quit [Quit: sndr] 09:43 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has quit [Quit: Leaving] 10:02 < jasan> https://www.jasan.tk/crypto/currencies/open/source/2018/03/01/lightning_works_on_alpine 10:02 < jasan> oops, sorry for that 'crypto/currencies', should be 'bitcoin'... changing now 10:04 < jasan> https://www.jasan.tk/bitcoin/open/source/2018/03/01/lightning_works_on_alpine 10:05 < jasan> It's actually just a proof that it works on musl-based Alpine Linux (what I was doubting frst) with a link to my branch with little modifications on GitHub. 10:24 -githubby:#c-lightning- [lightning] jsarenik opened pull request #1145: bitcoin.bib: Add Satoshi paper URL and date to bib file (master...jasan/add_bitcoin_url) https://git.io/vADYC 10:28 -githubby:#c-lightning- [lightning] jsarenik opened pull request #1146: Jasan/other md reflow (master...jasan/other_md_reflow) https://git.io/vADYy 10:31 < mlz> does anyone know how long this state is supposed to take before the tx is closed: "state": "CLOSINGD_SIGEXCHANGE", 10:33 < lxer> mlz: I have on like that also. I think it is since 2 days now 10:33 < lxer> *one 10:35 < mlz> hm something is wrong, this is on testnet so im not losing money but just trying to help test c-lightning here 10:55 -githubby:#c-lightning- [lightning] jBarz opened pull request #1147: revert 0e40c8 and re-enable test_withdraw (master...test) https://git.io/vADsH 11:05 < p3tr> mlz: have you tried dev-fail command? 11:09 < mlz> p3tr, no i haven't, oh i didn't know i could use that for this state , thanks :) 11:11 < p3tr> np, it helped me several times to get out of stuck channels 11:13 < mlz> hm doesn't seem to work, or mye not yet? 11:13 < mlz> maybe* 11:13 < mlz> "CLOSINGD_SIGEXCHANGE:Negotiating closing fee between 184 and 184 satoshi (ideal 184)", 11:13 < mlz> "CLOSINGD_SIGEXCHANGE:Waiting for another closing fee offer: ours was 184 satoshi, theirs was 178 satoshi," 11:13 < mlz> that's the case ^^ i think the fee diff is very trivial 11:42 < mlz> oh cool.. now it's "onchain" 11:42 < mlz> "ONCHAIN:3 outputs unresolved: in 143 blocks will spend DELAYED_OUTPUT_TO_US (92fb6584b72c33ae04131467712e145071b4cf942c5eec3bc25b15304f812dc0:1) using OUR_DELAYED_RETURN_TO_WALLET" 11:42 < mlz> why is it that c-lightning never issue the closing TXID? 11:42 < mlz> issues* 12:10 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-wxyifzsntpbybltp] has joined #c-lightning 12:17 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 12:28 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Read error: Connection reset by peer] 12:28 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 12:30 -!- grafcaps [~haroldbr@104.137.194.255] has joined #c-lightning 13:06 -!- igreen [5cb0e3e8@gateway/web/freenode/ip.92.176.227.232] has joined #c-lightning 13:09 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning 13:40 < igreen> hi? 13:40 < igreen> i got this error: feerate_per_kw 254 below minimum 255 13:41 < igreen> does someone know how to change my feerate? 13:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 13:45 < lxer> you can set it when starting bitcoind 13:46 < lxer> --override-fee-rates=400/300/200 13:46 < mlz> oh really? when starting bitcoind? 13:46 < lxer> sorry, I mean lightningd 13:46 < mlz> ah ok 13:53 < igreen> i used cli/lightning-cli dev-setfees 255 600 1000 13:54 < igreen> ops the order is reversed 14:19 -!- sndr [~sander@178-85-223-176.dynamic.upc.nl] has joined #c-lightning 14:20 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-wxyifzsntpbybltp] has quit [Quit: Connection closed for inactivity] 14:33 -githubby:#c-lightning- [lightning] cdecker pushed 1 new commit to master: https://git.io/vADXi 14:33 -githubby:#c-lightning- lightning/master 6f14736 John Barboza: revert 0e40c8 and renable test_withdraw... 14:34 -githubby:#c-lightning- [lightning] cdecker closed pull request #1142: Short channel id cleanup (master...short_channel_id-cleanup) https://git.io/vAMYC 14:58 < lxer> igreen: are you sure if it works with lightning-cli ? 15:03 < igreen> yes, i used it 15:03 < igreen> its working now 15:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 15:26 < rusty> igreen: what are you connecting to? 15:26 -!- mode/#c-lightning [+o rusty] by ChanServ 15:27 -!- rusty changed the topic of #c-lightning to: Chat about the C-lightning implementation: https://github.com/ElementsProject/lightning https://lists.ozlabs.org/listinfo/c-lightning Logs RSN: https://botbot.me/freenode/c-lightning 15:31 < igreen> rusty: it is a c-lightning node from a friend 15:32 < igreen> but is already working with the fees changed 15:32 <@rusty> igreen: you're trying to open a channel to them? 15:32 < igreen> yes i did 15:33 <@rusty> igreen: OK... we have hacky ways of forcing fees, but there's also a --ignore-fee-limits the receiving peer can use. Dangerous option, though. 15:35 < igreen> :) 15:35 < igreen> rusty: lnd and c-lightning node are incompatible? 15:40 -!- sndr [~sander@178-85-223-176.dynamic.upc.nl] has quit [Quit: sndr] 15:56 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds] 16:13 <@rusty> igreen: lnd using btcd often guesstimates different fees to bitcoind :( 16:39 < mlz> rusty, bitcoind still can't do a decent job even with "estimatesmartfee" 16:40 < mlz> i would never use bitcoind to give me a fee estimate, i always have to figure it out on my own by looking at how many txs are in my mempool and in jochen's mempool 16:41 <@rusty> mlz: more immediately, we made the decision to simplify the fee mechanism by letting one side do it. That means the other side has to agree, so discrepencies are bad. 16:41 <@rusty> mlz: this may well be something which gets revised in the spec soon, as it seems to be a real pain point. 16:42 < mlz> i hope so 16:42 < mlz> like when i was paying less than 30 sat/byte, bitcoind gave me the figure over 100 sat/byte 16:43 < mlz> wow.. omg.. the mempool is empty right now lmao 16:43 < igreen> where can u see your mempool? im noob :S 16:44 < mlz> ok heres my mempool with these many txs: "size": 775, 16:45 < mlz> and here's bitcoind's feerate, not to bad but still: 16:45 < mlz> ~$ bitcoin-cli estimatesmartfee 6 16:45 < mlz> { 16:45 < mlz> "feerate": 0.00024481, 16:45 < mlz> we can send txs with just 1 sat/byte right now 16:47 < mlz> igreen, do : bitcoin-cli getmempoolinfo and you can do: "bitcoin-cli help" to find all commands 16:51 < igreen> but theres not more documentation on the commands no? 16:51 < igreen> for example, the estimatesmartfee 6, is the fee to pay if you want the tx to get in the net 6 blocks? 16:57 <@rusty> igreen: bitcoin-cli help estimatesmartfee 16:57 <@rusty> igreen: you usually want the ECONOMICAL setting, not CONSERVATIVE. 17:00 < igreen> ops thnks 17:02 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #c-lightning 17:16 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [] 17:27 < mlz> rusty, here's the estimatefee from btcd, not much different: 17:27 < mlz> ~$ btcctl estimatefee 6 17:27 < mlz> 0.00022654867256637168 17:28 <@rusty> mlz: what's the difference between estimatefee 100 from btcd and estimatesmartfee 100 ECONOMICAL from bitcoind though? That's what we use as the lower bound. 17:30 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #c-lightning 17:32 < mlz> hm btcd can't do 100 blocks from now 17:32 -!- igreen [5cb0e3e8@gateway/web/freenode/ip.92.176.227.232] has quit [Ping timeout: 260 seconds] 17:37 < mlz> rusty, you know LND also uses bitcoind 17:40 < dougsland> never used LND, I thought it was btcd 17:41 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [] 17:46 -githubby:#c-lightning- [lightning] rustyrussell closed pull request #1141: WIP: Routing graph lifetime rework (master...routing-graph-rework) https://git.io/vAMfW 17:58 < mlz> dougsland, LND can run with either btcd or bitcoind as the backend 18:02 <@rusty> mlz: sure, but it's kinda insane to insist on matching, synced bitcoind's too. Esp. when we think about lite nodes, who may have other means of estimating fees. 18:05 < mlz> rusty, i'm not sure i understand what you mean? 18:06 < mlz> i run several bitcoind nodes for both lnd and c-lightning on testnet, not sure what's the problem? 18:06 <@rusty> mlz: I'm saying that the problems we see connecting to lnd with btcd is a symptom; there are many other cases where we might have different ideas on "reasonable fees". 18:07 < mlz> rusty, i think if you guys relax the rules a bit, and let users have their choices, that will solve the incompatibilities 18:08 <@rusty> mlz: if you let the peer set fees too low, you end up with a unilateral transaction you can't spend, however. 18:10 < mlz> if you let them negotiate and the two parties agree on their fees, if their txs get unconfirmed, it's their problem then but at least they made their own choice 18:15 <@rusty> mlz: sure, they negotiate on startup, but fees change all the time, and if you disagree you can only close the channel. See https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-January/000935.html 18:22 < mlz> yes i understand the pain 18:25 -githubby:#c-lightning- [lightning] rustyrussell closed pull request #1113: Print node alias when listing peers (master...alias) https://git.io/vA63B 18:29 -githubby:#c-lightning- [lightning] rustyrussell reopened pull request #1141: WIP: Routing graph lifetime rework (master...routing-graph-rework) https://git.io/vAMfW 18:29 -githubby:#c-lightning- [lightning] rustyrussell closed pull request #1141: WIP: Routing graph lifetime rework (master...routing-graph-rework) https://git.io/vAMfW 18:30 -githubby:#c-lightning- [lightning] rustyrussell created routing-branch-rework from master (+0 new commits): https://git.io/vAyvB 18:32 -githubby:#c-lightning- [lightning] rustyrussell deleted routing-branch-rework at 35ce131: https://git.io/vAyvw 18:33 -githubby:#c-lightning- [lightning] rustyrussell opened pull request #1150: Routing graph lifetime rework (master...routing-graph-rework) https://git.io/vAyv6 18:48 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 245 seconds] 18:59 -!- grafcaps [~haroldbr@50.90.83.229] has joined #c-lightning 19:01 < dougsland> mlz, good to know, only running c-lightning here at moment. 19:10 < dougsland> mlz, I was wondering these days why they created btcd.. just to be in go? 19:13 < mlz> why not? 19:13 < mlz> it seems btcd can handle re-orgs much better than bitcoind 19:15 < mlz> i'm running a LND node with btcd on mainnet, i've had the btcd node running on mainnet since last year so it's been months now and has never crashed, i started the LND node on jan 17 the day after BS opened their store and LND has never crashed either 19:15 < mlz> my lnd node is just idling but it has 22 channels people opened to it currently :) 19:17 < mlz> the only deficiency btcd has is it doesn't have a manpower behind it to optimize it like bitcoind 19:24 < jojeyh> when i run 'lightning-cli listchannels' is the result ALL of the channels in the entire network ? 19:32 -githubby:#c-lightning- [lightning] dougsland opened pull request #1151: pylightning: label is required for waitinvoice() (master...waitinvoice) https://git.io/vAyTW 19:45 -!- blyat [~blyat@cpe-71-71-200-3.carolina.res.rr.com] has joined #c-lightning 19:46 -!- kexkey [~kexkey@173.209.57.12] has joined #c-lightning 19:55 < dougsland> jojeyh, so far I understood yes 19:55 < dougsland> you can specify short_channel_id as param if you want as well. 19:55 < jojeyh> dougsland, i wonder if that will become a problem as num of channels get really really big 19:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds] 19:56 < jojeyh> seems if that happens there might be a tendency towards greater centralization, whereby most nodes don't want to download full list so they just rely on some central hub for node information 19:58 < dougsland> jojeyh, /me nods 19:59 < jojeyh> i mean *channel information 20:00 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 20:00 < jojeyh> anybody know the size of a channel offhand? 20:11 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-ubcpzrugyykdkjql] has quit [Read error: Connection reset by peer] 20:11 -!- rompert [sid13298@gateway/web/irccloud.com/x-aodmmoywjdllxbmd] has quit [Read error: Connection reset by peer] 20:11 -!- takinbo [sid19838@gateway/web/irccloud.com/x-drpfynfscxvzgjjf] has quit [Write error: Connection reset by peer] 20:11 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-rkgsxjlwzdjkliqz] has quit [Read error: Network is unreachable] 20:12 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-kouabmilfcelzufk] has quit [Ping timeout: 256 seconds] 20:13 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-vycvequsgtqwxscv] has joined #c-lightning 20:14 -!- rompert [sid13298@gateway/web/irccloud.com/x-bjbtesketzxlikef] has joined #c-lightning 20:14 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-qfdfnesyxjorhyix] has joined #c-lightning 20:15 -!- takinbo [sid19838@gateway/web/irccloud.com/x-uoahppaffhvhltml] has joined #c-lightning 20:15 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-syawefquppqlmftp] has joined #c-lightning 20:16 -!- almkglor [9258463b@gateway/web/freenode/ip.146.88.70.59] has joined #c-lightning 20:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 20:22 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 20:32 < mlz> your node can never see the whole network 21:10 < jojeyh> mlz, how so? 21:10 < jojeyh> mlz, or why not? 21:11 < mlz> that's how it is 21:12 < mlz> i don't know fully the technical detail of it but each node can only see part of the whole network, there will be private nodes or nodes running on tor that we don't see or know about 21:13 < jojeyh> ok thnx 21:33 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 21:35 < almkglor> TOR nodes can still be public, it's just that all we'll know is their hidden service address 21:36 < almkglor> nodes are private if all their channels are private, c-lightning has no support for private channels yet that I noticed 21:42 < mlz> lnd has it 21:43 < mlz> if your node doesn't have a channel and has no peers, it's not known to anyone 21:44 < mlz> i haven't tested this, but i guess if i set up 3 nodes and they only connect to each other, the rest of the network probably don't know about them 21:45 < jojeyh> mlz, i did this with c-lightning and that was the behavior 21:45 < jojeyh> mlz, if you have no peers there is no way to discover channels through anouncements 21:46 < jojeyh> any peer that is already connected to the rest of network will automatically start sending you channel info 21:46 < mlz> well i had another node on mainnet that never had a channel, so i connected it to my other node as peer, then it got a couple more peers and that was it 21:47 < mlz> then i took it down, a week later i got it back up, had no peers again for a few days, nobody knew about it 21:50 -!- blyat_ [~blyat@cpe-71-71-200-3.carolina.res.rr.com] has joined #c-lightning 21:53 -!- blyat [~blyat@cpe-71-71-200-3.carolina.res.rr.com] has quit [Ping timeout: 240 seconds] 21:56 < jojeyh> weird 22:04 < almkglor> not weird: you need to lock funds in Lightning to get the privilege of being visible on Lightning, otherwise people could DoS the network with spurious node_announcement 22:05 < almkglor> Unless you are calling something else weird, hahah 22:05 < almkglor> (I wonder what Peter Todd thinks can be DoS'ed about the LN protocol though) 22:10 < jojeyh> almkglor, yeah i get that, so i guess connections (peers) are automatically removed when a node shutdown ? 22:12 -!- almkglor [9258463b@gateway/web/freenode/ip.146.88.70.59] has quit [Ping timeout: 260 seconds] 22:24 -!- almkglor [9258463b@gateway/web/freenode/ip.146.88.70.59] has joined #c-lightning 22:57 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has quit [Ping timeout: 260 seconds] 23:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 23:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 23:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 23:48 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has joined #c-lightning 23:55 -!- blyat__ [~blyat@cpe-71-71-200-3.carolina.res.rr.com] has joined #c-lightning 23:59 -!- blyat_ [~blyat@cpe-71-71-200-3.carolina.res.rr.com] has quit [Ping timeout: 268 seconds]