--- Day changed Mon Feb 12 2018
00:24 -githubby:#c-lightning- [lightning] cdecker closed pull request #981: doc: Include apt-get update as first step (master...patch-2) https://git.io/vAqz8
00:28 -githubby:#c-lightning- [lightning] cdecker pushed 3 new commits to master: https://git.io/vAq9d
00:28 -githubby:#c-lightning- lightning/master b4a2f51 Rusty Russell: Travis: use more fine-grained tests....
00:28 -githubby:#c-lightning- lightning/master 106c830 Rusty Russell: Travis: don't perform source-check on every build variant....
00:28 -githubby:#c-lightning- lightning/master 6757300 Rusty Russell: Travis: slightly more finegrained, should be under 17 minutes now....
00:30 -githubby:#c-lightning- [lightning] cdecker pushed 1 new commit to master: https://git.io/vAq9b
00:30 -githubby:#c-lightning- lightning/master 4e382eb ZmnSCPxj: doc: Mention keyword arguments, update pay to mention use of null.
00:31 -githubby:#c-lightning- [lightning] cdecker pushed 1 new commit to master: https://git.io/vAq9A
00:31 -githubby:#c-lightning- lightning/master fe670b9 practicalswift: Improve log message when receiving unknown message type
01:18 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Remote host closed the connection]     
01:18 -!- simlay [~simlay@gateway/tor-sasl/simlay] has joined #c-lightning     
01:23 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has joined #c-lightning     
01:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning     
02:38 -!- ougha [~quassel@b2b-130-180-107-194.unitymedia.biz] has joined #c-lightning     
02:38 -!- ougha [~quassel@b2b-130-180-107-194.unitymedia.biz] has quit [Changing host]     
02:38 -!- ougha [~quassel@unaffiliated/ougha] has joined #c-lightning     
02:53 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Remote host closed the connection]     
02:54 -!- simlay [~simlay@gateway/tor-sasl/simlay] has joined #c-lightning     
03:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]     
04:09 -!- ougha [~quassel@unaffiliated/ougha] has quit [Remote host closed the connection]     
04:10 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Remote host closed the connection]     
04:10 -!- simlay [~simlay@gateway/tor-sasl/simlay] has joined #c-lightning     
04:45 -!- tmus [~tmus@194.177.231.78] has joined #c-lightning     
04:46 < tmus> Are there any current thoughts on securing high availability of lightningd though some type of clustering?
04:47 < bitonic-cjp> What do you mean?
04:49 < tmus> I'm thinking, when eventually running c-lightning in production, it would be good to be able to ensure continued service even in case of hardware failure. So I'm wondering if any thoughts had been done about enabling this type of thing
04:51 < bitonic-cjp> You mean, something like having a backup server up and running, which is continuously being synced from the main server, and ready to immediately take over whenever it notices that the main server has stopped working?
04:52 < tmus> something like that... preferably active/active though, but any thought in this regard would be interesting
05:20 < mlz> tmus, the worst that can happen to your node is your channels are closed, then you reopen them later, not sure what your issue is 
05:33 -!- Mark__ [5bd4cf04@gateway/web/freenode/ip.91.212.207.4] has joined #c-lightning     
05:37 < bitonic-cjp> I think he wants to have a very high uptime for his Lightning node; higher than can be guaranteed by just having reliable hardware.
05:39 < bitonic-cjp> Maybe even have a single node running on several co-locations, to deal with ISP down-time.
05:39 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning     
05:40 < contrapumpkin> or load-balanced nodes, perhaps
05:44 < tmus> Something like that, yes... 
05:48 < tmus> I'm essentially examining my options for keeping my channels operational at all times - even in case of hardware failure.
05:49 < bitonic-cjp> Load balancing might be achieved by simply running more than one node. Except you aren't really flexible in the "balancing": if the neighbors of one node structurally generate more load than those of another node, there isn't much balance.
05:49 < contrapumpkin> yeah, I mean load balancing with shared keys
05:50 < contrapumpkin> which would achieve tmus's goal and actual balancing
05:50 < contrapumpkin> well, shared state
05:50 < contrapumpkin> not just keys
05:50 < tmus> Exactly what I'm looking for
05:51 < contrapumpkin> then you just stick your nodes into an AWS autoscaling group and forget about it :P
05:51 < tmus> precisely!
05:51 < contrapumpkin> (and they maintain their state in dynamodb)
05:51 < tmus> Is that possible at this time?
05:52 < contrapumpkin> not as far as I know
05:52 < tmus> I thought so... Would make a ton of sense though - to me at least :)
05:53 < bitonic-cjp> lightningd has one "secret" file that acts as root for all its secrets; this file should be copied to all servers.
05:54 < contrapumpkin> but it's not just about the secret, right? it's about channel state
05:54 < bitonic-cjp> lightningd stores its state in an sqlite database; this should instead be a database that is shared across all servers, and kept consistent at all times.
05:54 < tmus> bitonic-cjp, as I understand, keys and secrets are only part of the equation - you'd need "state" as well, which is probably in-memory structures etc, replicated as well
05:54 < contrapumpkin> yeah, that seems ideal
05:54 < contrapumpkin> if all the state is in sqlite, then putting that into a transactional remote SQL DB sounds like it wouldn't be too traumatic
05:55 < tmus> bitonic-cjp, so no in-memory state? is everything in the database?
05:55 < tmus> contrapumpkin, yeah, if that's all, it should be to problematic
05:55 < bitonic-cjp> I don't know what in-memory state the software keeps track of. From what I know, currently, the network shape ("routing tables") are in-memory, and not stored on disk.
05:56 < tmus> alright
05:57 < bitonic-cjp> A typical server node that only forwards or receives payments shouldn't need that routing info.
06:00 < bitonic-cjp> You'd have to deal with connection opening/closing. You can avoid a lot of complicated mess if only one of the servers at a time connects to a certain peer.
06:02 < tmus> As long as the state, funds and transactions etc are sync'ed, the actual connection is probably okay to re-establish (should be quick i think)
06:02 < tmus> if the remote node would support that kind of thing
06:02 < tmus> (it would at a minimum see it as a re-connect)
06:03 < bitonic-cjp> To the remote node, a re-balancing would probably look like a disconnect, followed by a re-connect.
06:04 < tmus> yes. are we typically losing state in those situations? or can the channel live across a reconnect like this?
06:04 < bitonic-cjp> I think I'm actually beginning to appreciate the C-Lightning architecture. It sounds like this kind of thing can become possible in the future.
06:05 < bitonic-cjp> Channels don't lose state just by disconnecting/reconnecting the network link.
06:06 < tmus> cool
06:42 < AndyMillar> anyone here tried to use the cdecker/lightningd:master docker image for c-lightning?
06:43 < AndyMillar> or know or a better docker image; it keeps failing to start for me and doesn't seem to give any useful logs
06:58 -!- bryan_w [~is@2600:2108:9:8a90:72a3:5780:f492:1888] has joined #c-lightning     
07:22 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-rvgbudxdnooeytzv] has quit [Quit: Connection closed for inactivity]     
07:40 < AndyMillar> I end up with https://www.andymillar.co.uk/temp/cl1.txt - which doesn't tell me anything remotely useful :(
07:40 < AndyMillar> (as far as I can tell)
08:00 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 264 seconds]     
08:20 -!- grafcaps [~haroldbr@104.137.194.255] has joined #c-lightning     
08:25 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 264 seconds]     
08:28 -!- grafcaps [~haroldbr@104.137.194.255] has joined #c-lightning     
08:30 -githubby:#c-lightning- [lightning] gabridome opened pull request #986: Preventing lightningd closing when the session ends. (master...patch-1) https://git.io/vAmiv
08:41 -!- bryan_w [~is@2600:2108:9:8a90:72a3:5780:f492:1888] has quit [Ping timeout: 276 seconds]     
08:51 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has quit [Quit: Leaving]     
09:01 -!- alanc44 [~alanc@109.255.196.64] has joined #c-lightning     
09:05 -!- tmus [~tmus@194.177.231.78] has quit [Remote host closed the connection]     
09:46 -!- tmus [~tmus@194.177.231.78] has joined #c-lightning     
10:18 -!- jojeyh [~delphi@2602:306:b8b6:b970:9998:324b:a5a3:1e2c] has joined #c-lightning     
10:35 < jojeyh> looking at the fundchannel help line it says the amount specified in satoshis
10:37 < jojeyh> if i input 10000 to fund the channel, the listpeers command shows the channel has "msatoshi_to_us":10000000
10:37 < jojeyh> so it seems opposite
10:38 < jojeyh> as if the fundchannel command is interpreting the amount as msatoshi
10:38 < jojeyh> and listpeers is showing the amount of satoshis
10:38 < jojeyh> am i correct in this?
10:56 < tmus> Does c-lightning have an authentication system?
10:57 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has joined #c-lightning     
11:06 < mlz> jojeyh, i think you have to 3 extra "0" at the end.. it's confusing, not sure how this is going to help users 
11:06 < mlz> you have to add*
11:07 < mlz> to me "msat" is too extreme 
11:08 < jojeyh> mlz, regardless of whether we want to change it i'm saying that in its current state it is wrong
11:09 < jojeyh> if i enter 10000 satoshis in the fundchannel command and it should show having 10 msat
11:09 < jojeyh> but it shows 10000000 msat
11:10 < jojeyh> let me see what the listing is under the listchannels command
11:10 < mlz> jojeyh, you enter the "sat" amount
11:10 < mlz> it's then interpreted into "msat"
11:11 < mlz> so, 10000 sat == 10000000 msat
11:11 < buZz> how can i debug whats happening on a channel thats in CHANNELD_SHUTTING_DOWN for a long time?
11:11 < jojeyh> ok channel doesn't specify amount so its only listpeers
11:11 < mlz> and let me tell you.. some crazy nuts now want to use "bits", i can see LN is going nowhere 
11:12 < jojeyh> lol     
11:12 < buZz> mlz: at least its not tonal btc :D
11:12 < buZz> lol     
11:12 < mlz> lol     
11:12 < mlz> really ffs, keep it simple, STUPIDS
11:12 < buZz> ^_^     
11:13 < jojeyh> if the fundchannel spec says to specifiy amount in {satoshis} shouldn't the amount specified in listpeers show that amount of satoshis in msats?
11:13 < jojeyh> lol wait i'm confusing myself now
11:13 < jojeyh> how is 10000 sat == 10000000 msat ?
11:14 < buZz> what do you mean 'how'
11:14 < buZz> 'milli' is 1/1000st
11:14 < jojeyh> isn't 1 msat == 1000 sat ?
11:14 < buZz> didnt you learn metric? :D
11:14 < jojeyh> LULZ
11:14 < jojeyh> touche
11:14 < buZz> 1 Msat is 1000000 sat
11:14 < buZz> milli vs mega
11:14 < jojeyh> chyes ok
11:15 < jojeyh> msat == millisat
11:15 < jojeyh> got it
11:15 < jojeyh> haha
11:15 < buZz> ^_^     
11:15 < jojeyh> glad we got that cleared up lol
11:24 -!- tmus [~tmus@194.177.231.78] has quit [Quit: Leaving]     
11:35 < mlz> hm ..now i'm wondering if rompert meant to set his routing fee at 18 sat, instead he set it at 18000 sat and someone paid it yesterday .. lol
11:38 < rompert> no i meant to make it stop throwing errors in my log :) i've set it to 1 micropicowhateversatoshi now
11:40 < grafcaps> femptoshi
11:41 < rompert> however clightning nodes are still hammering me with errors about 14000 fees... which i think sounds like a protocol derived from 14 htlc or something. which i don't have either. it just picks it up out of thin air :)
11:56 -!- alanc44 [~alanc@109.255.196.64] has quit [Ping timeout: 240 seconds]     
12:10 -!- alanc44 [~alanc@109.255.196.64] has joined #c-lightning     
13:03 -!- alanc44 [~alanc@109.255.196.64] has quit [Ping timeout: 240 seconds]     
13:14 -!- alanc44 [~alanc@109.255.196.64] has joined #c-lightning     
13:25 -githubby:#c-lightning- [lightning] cdecker opened pull request #987: Fix crash when trying to forget a channel with HTLCs (master...dev-forget-channel) https://git.io/vAYC9
13:26 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has quit [Ping timeout: 265 seconds]     
13:31 < jojeyh> one thing i've noticed is that no matter what happens to a channel, the listpeers command always lists current and previous channels for a particular id
13:31 < jojeyh> is this normal?
13:32 < jojeyh> if i forcefully close a channel shouldnt it eventually be removed from listpeers output ?
13:35 < grafcaps> jojeyh: when was the last time you pulled and recompiled? I did last Friday and a bunch of dead peers disappeared shortly thereafter
13:35 < jojeyh> grafcaps, let me recompile and see
13:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds]     
14:00 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-gkxckesijgafxhmg] has joined #c-lightning     
14:05 < jojeyh> grafcaps, looks to have done the trick, danke
14:09 < grafcaps> thumbs up emoji
14:36 -!- farmerwampum_ [~farmerwam@173.244.200.116] has joined #c-lightning     
14:37 -!- farmerwampum [~farmerwam@209.95.51.99] has quit [Ping timeout: 265 seconds]     
14:37 -!- farmerwampum_ is now known as farmerwampum     
14:39 -!- farmerwampum [~farmerwam@173.244.200.116] has quit [Client Quit]     
14:39 -!- farmerwampum [~farmerwam@173.244.200.116] has joined #c-lightning     
14:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning     
14:47 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has joined #c-lightning     
15:40 -!- alanc44 [~alanc@109.255.196.64] has quit [Ping timeout: 268 seconds]     
16:08 -!- JSorel [~JSorel@modemcable086.144-178-173.mc.videotron.ca] has joined #c-lightning     
16:13 -!- ctrlbreak [~ctrlbreak@fctnnbsc38w-47-55-95-227.dhcp-dynamic.fibreop.nb.bellaliant.net] has quit [Ping timeout: 248 seconds]     
16:14 -!- ctrlbreak [~ctrlbreak@fctnnbsc38w-47-55-95-227.dhcp-dynamic.fibreop.nb.bellaliant.net] has joined #c-lightning     
16:16 -!- booyah [~bb@193.25.1.157] has joined #c-lightning     
16:20 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-gkxckesijgafxhmg] has quit [Quit: Connection closed for inactivity]     
16:45 -!- narcelio [b3bb8a52@gateway/web/freenode/ip.179.187.138.82] has joined #c-lightning     
16:48 < narcelio> Is it possible to reduce network usage for clightning? My node is uploading many Gigabytes everyday, making it too expensive.
17:02 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-wifyelvjempnbhnw] has joined #c-lightning     
17:06 -!- JSorel [~JSorel@modemcable086.144-178-173.mc.videotron.ca] has quit [Ping timeout: 240 seconds]     
17:13 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 240 seconds]     
17:19 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 240 seconds]     
17:20 -!- jonasschnelli [~jonasschn@bitcoinsrv.jonasschnelli.ch] has joined #c-lightning     
17:29 -!- grafcaps [~haroldbr@50.90.83.229] has joined #c-lightning     
17:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning     
17:38 -!- contrapumpkin is now known as Whale     
17:38 -!- Whale is now known as contrapumpkin     
17:39 -!- contrapumpkin is now known as Whale     
17:39 -!- Whale is now known as contrapumpkin     
18:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 248 seconds]     
18:22 -!- bryan_w [~is@2600:2108:9:8a90:72a3:5780:f492:1888] has joined #c-lightning     
18:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning     
20:01 -!- newbold [~adam@pug.sh] has quit [Remote host closed the connection]     
20:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]     
20:26 -!- ruby32 [~ruby32@158.106.219.26] has quit [Remote host closed the connection]     
20:29 < jojeyh> { "outputs" : 
20:29 < jojeyh> 	[      
20:29 < jojeyh> 		{ "txid" : "6cc1fba8a17bfe73ce43d32bc29b3d7fd7143879f9ccab0149387bab82700909", "output" : 1, "value" : 50000000 }, 
20:29 < jojeyh> 		{ "txid" : "0e482f032af6cc7998aebfb5ae8bb44f5cb3fdac2229db81d4f41b5f035453c9", "output" : 1, "value" : 99989308 } ], "channels" : 
20:29 < jojeyh> 	[      
20:29 < jojeyh> 		{ "peer_id" : "02fa77e0f4ca666f7d158c4bb6675d1436e339903a9feeeaacbd6e55021b98e7ee", "short_channel_id" : "1282116:5:0", "channel_sat" : 10000, "channel_total_sat" : 10000, "funding_txid" : "0e482f032af6cc7998aebfb5ae8bb44f5cb3fdac2229db81d4f41b5f035453c9" }, 
20:29 < jojeyh> 		{ "peer_id" : "0245bd37f9c036832c3b51867d21d83f01e54ea182fa453250f75c6ac5d4c050a0", "short_channel_id" : "1260178:119:0", "channel_sat" : 0, "channel_total_sat" : 100000, "funding_txid" : "4a45f3cd422254262ccee0861cde90ab4951a1762601b36fa4db22b32f151b49" } ] }
20:30 < jojeyh> do the bottom entries signify a collected payment from a peer ?
20:37 < jojeyh> also get this error when trying to send a payment usng bolt11
20:37 < jojeyh> { "code" : 204, "message" : "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)", "data" : { "erring_index" : 1, "failcode" : 4103, "erring_node" : "eee7981b02556ebdaceaee9f3a9039e336145d67b64b8c157d6f66caf4e077fad45d056a662ec93cacfe8cc29503f7c72cb44e4c158b19e843fea1f8c542f262", "erring_channel" : "1282119:7:0" } }
20:37 -!- ruby32 [~ruby32@158.106.219.26] has joined #c-lightning     
20:37 < jojeyh> both nodes that i am sending/receiving from are in state CHANNELD_NORMAL with testnet node
20:41 -!- shesek [~shesek@bzq-84-110-234-105.red.bezeqint.net] has joined #c-lightning     
20:41 -!- shesek [~shesek@bzq-84-110-234-105.red.bezeqint.net] has quit [Changing host]     
20:41 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning     
20:53 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection]     
21:43 -!- narcelio [b3bb8a52@gateway/web/freenode/ip.179.187.138.82] has quit [Quit: Page closed]     
21:50 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-rcgcavgpmfcwnrgt] has joined #c-lightning     
21:51 < rodarmor> Is it possible to query c-lightning for IP addresses of other lightning nodes?
22:00 < rodarmor> I added a couple of peers, but `listpeers` only shows those peers that I've manually added.
22:08 < jojeyh> rodarmor, i don't think that is possible, since channels don't give you information about IP addresses
22:09 < jojeyh> rodarmor, you only need one peer that is connected to the network to get all the channel information for the entire network
22:09 < jojeyh> rodarmor, but you would only be able to send payments through that one channel for that one peer
22:09 < jojeyh> to anybody else on the network
22:12 < rodarmor> jojeyh: That doesn't seem right. I've heard about an "autopilot" mode (possibly in lnd only) which opens channels automatically. If nodes don't gossip about other nodes' ip and port, then it would only be possible to add nodes that you already know about, which seems suboptimal for the network topology.
22:13 < rodarmor> jojeyh: Also, public lightning network explorers show a bunch of nodes, including IP address and port, so I assume it's available somehow
22:15 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has joined #c-lightning     
22:15 < buZz> rodarmor: buzz@lightning:~$ ./lightning-cli listnodes
22:16 < buZz> outputs ip addresses
22:17 < rodarmor> buZz: Awesome, that did it!
22:17 < buZz> ./lightning-cli help -J 
22:17 < buZz> highly recommended ;)
22:18 < rodarmor> buZz: I got stuck on listpeers, and was confused that it wasn't showing anything
22:18 < buZz> peers lists the peer connections you set up , just like on bitcoin
22:19 < rodarmor> buZz: But bitcoind will gossip and connect to new peers automatically, and try to maintain a healthy number of active connections to peers at all times
22:20 < rodarmor> buZz: Is lightning different, in that it doesn't try to keep a number of connections open to peers?
22:20 < buZz> yes     
22:20 < buZz> the simularity is in -established- peer connections
22:21 < rodarmor> buZz: Huh, interesting. 
22:21 < rodarmor> Should I manually add peers, or is it not important?
22:23 < buZz> i'd follow a tutorial ;)
22:31 < jojeyh> sweet i learned something new lol
22:31 < jojeyh> there's so much to learn
22:32 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has quit [Ping timeout: 260 seconds]     
22:32 < rodarmor> buZz: The tutorials I've looked at don't mention adding peers, aside from adding a single peer and opening a channel with that peer
22:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]     
22:38 < buZz> yep, you dont need em, LN isnt a cryptocurrency ;)