--- Log opened Mon Mar 04 00:00:06 2019
00:20 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #lightning-dev
00:38 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
00:55 -!- araspitzu [~araspitzu@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
00:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
01:20 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
02:04 -!- kexkey [~kexkey@68.168.122.228] has quit [Ping timeout: 245 seconds]
03:17 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
03:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:35 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev
03:44 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
04:02 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
04:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
04:25 -!- m8tion [~user@2a01:e35:8bef:9310:449b:38a4:5130:c201] has joined #lightning-dev
04:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host]
04:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
04:55 -!- deafboy [quasselcor@cicolina.org] has quit [Quit: deafboy]
04:55 -!- deafboy [quasselcor@cicolina.org] has joined #lightning-dev
05:28 -!- m8tion_ [~user@167.88.108.151] has joined #lightning-dev
05:31 -!- m8tion [~user@2a01:e35:8bef:9310:449b:38a4:5130:c201] has quit [Ping timeout: 257 seconds]
05:31 -!- shesek [~shesek@141.226.146.161] has joined #lightning-dev
05:31 -!- shesek [~shesek@141.226.146.161] has quit [Changing host]
05:31 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
05:42 -!- m8tion_ [~user@167.88.108.151] has quit [Quit: Leaving]
06:07 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 244 seconds]
06:12 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
06:29 -!- booyah [~bb@193.25.1.157] has joined #lightning-dev
06:36 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
06:37 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
06:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
06:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.9.1]
06:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
06:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Client Quit]
06:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
06:54 -!- kexkey [~kexkey@68.168.122.228] has joined #lightning-dev
07:19 -!- shesek [~shesek@unaffiliated/shesek] has quit [Quit: Leaving]
07:20 -!- shesek [~shesek@141.226.146.161] has joined #lightning-dev
07:20 -!- shesek [~shesek@141.226.146.161] has quit [Changing host]
07:20 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
07:28 -!- robmyers [sid14471@gnu/social/robmyers] has quit [Ping timeout: 264 seconds]
07:28 -!- robmyers [sid14471@gnu/social/robmyers] has joined #lightning-dev
07:30 -!- araspitzu [~araspitzu@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Quit: Leaving]
08:03 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
08:05 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev
08:40 -!- mikethetike_ [sid308076@gateway/web/irccloud.com/x-ingztfjotwrdnmnw] has quit []
08:41 -!- mikethetike_ [sid308076@gateway/web/irccloud.com/x-xhkjhhkgwsrbaocd] has joined #lightning-dev
08:41 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 245 seconds]
08:43 -!- mikethetike_ [sid308076@gateway/web/irccloud.com/x-xhkjhhkgwsrbaocd] has left #lightning-dev []
08:43 -!- harding [~quassel@li1258-130.members.linode.com] has joined #lightning-dev
09:00 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection]
09:37 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
09:57 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has quit [Remote host closed the connection]
10:00 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev
10:02 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has quit [Remote host closed the connection]
10:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
10:06 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev
10:17 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has quit [Remote host closed the connection]
10:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
10:25 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has joined #lightning-dev
10:51 -!- araspitzu [~ott0disk@5.170.48.56] has joined #lightning-dev
10:53 -!- araspitzu [~ott0disk@5.170.48.56] has left #lightning-dev []
10:53 -!- ott0disk [~ott0disk@5.170.48.56] has joined #lightning-dev
10:54 -!- nkohen [~nkohen@199.188.64.16] has joined #lightning-dev
10:55 -!- ott0disk [~ott0disk@5.170.48.56] has left #lightning-dev []
10:55 -!- araspitzu [~ott0disk@5.170.48.56] has joined #lightning-dev
10:55 < araspitzu> Hi there!
10:59 < sstone> Hi :)
10:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
11:00 < cdecker> Heya :-)
11:00 < Chris_Stewart_5> hello 
11:00 < rusty> cdecker: GUG!  Should we ping all the regulars?
11:01 -!- mode/#lightning-dev [+o rusty] by ChanServ
11:01 < cdecker> ping AmikoPay_CJP bitconner BlueMatt cdecker Chris_Stewart_5 kanzure niftynei
11:01 < cdecker>   ott0disk roasbeef rusty sstone bitconner BlueMatt cdecker johanth kanzure
11:01 < cdecker>   roasbeef rusty sstone
11:01 < cdecker> :-)
11:01 < cdecker> My ever growing list of participants 
11:01 < BlueMatt> heyyyyy-o
11:01 < cdecker> Hi Matt
11:02 < BlueMatt> I'm finally not in some godforsaken timezone jetlagged out of my mind!
11:02 < sstone> Hello everyone!
11:02 <@rusty> #startmeeting
11:02 < lightningbot> Meeting started Mon Mar  4 19:02:44 2019 UTC.  The chair is rusty. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:02 <@rusty> #link https://github.com/lightningnetwork/lightning-rfc/issues/577
11:03 <@rusty> And of course, https://github.com/lightningnetwork/lightning-rfc/labels/2019-03-04
11:04 <@rusty> Shall we start with an easy one?  :)
11:04 <@rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/550
11:04 <@rusty> We're basically waiting for roasbeef's call on whether the new wording is good...
11:05 < cdecker> We might be missing a representative from LL
11:06 <@rusty> Just got msg, he's only just landed.  So he's clearly going to be acking that on-issue :)
11:06 <@rusty> #action 550 to resolve on-issue, since other acks are there.
11:07 <@rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/557
11:07 < cdecker> Sounds good to me, but roasbeef had voiced some concerns last time
11:07 < lndbot> <johanth> Hi all
11:07 < cdecker> So it's probably up to him to give the final ack as well
11:08 < lndbot> <johanth> I'm in between flights, other LL members might also still be traveling
11:08 < sstone> afaik last time he had not really looked at it yet
11:09 <@rusty> cdecker: well, for this we need 2 implementations.  I'm pretty sure sstone has an implementation; I might commit c-lightning to implement it too, for testing.  It's pretty simple.
11:10 <@rusty> sstone: are you ready for some interoperation testing?  That's the next step, AFAICT.
11:10 < sstone> yes definitely
11:10 <@rusty> (I need to work on c-lightning's primitive gossip issues anyway).
11:10 <@rusty> Great!
11:10 <@rusty> #action rusty to implement 557 in c-lightning, provide feedback and interop testing with sstone.
11:11 <@rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/571
11:11 < cdecker> Oh, I got them mixed up, it was #571 which was blocked on roasbeef :-)
11:12 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds]
11:12 <@rusty> Really two questions: 1) should we maintain two types of features, or completely unify.  And 2) should we start using those nominal feature assignments.
11:12 <@rusty> If we completely unify, it means that if you see a node with a feature you don't understand, you can't route through it, even though you might have actually been able to.
11:13 <@rusty> Similarly, you think you can't even gossip with it.
11:13 <@rusty> But, compulsory features are pretty extreme, and imply the majority of the network has upgraded, so maybe we don't care.
11:14 <@rusty> Background: right now we have global (aka "channel" features) and local (aka "peer" features).  THe former tells whether you can use a channel, the latter whether you can chat directly to a peer. 
11:15 <@rusty> eg. if someone insists on option_dataloss_protect, you can still route through their channels even if you have no idea WTF that is.
11:15 <@rusty> But if someone insists on scriptless_scripts for their channel, you can't.   But you can still connect to them for gossip.
11:16 <@rusty> I'll stop typing now to let you all rush in... :)
11:17 -!- hiroki [a331cce4@gateway/web/freenode/ip.163.49.204.228] has joined #lightning-dev
11:17 < BlueMatt> lol, so it sounds like you're advocating not unifying global and local in your above description :p
11:17 < cdecker> Definitely a +1 for the tentative assignment of feature bits
11:17 < cdecker> And you just managed to unconvince me about the unification :-)
11:17 < BlueMatt> but tentative assignment sounds great
11:18  * BlueMatt is fine unifying the namespace, even if not actually ever setting the same bits on local/global
11:18 < sstone> when you say "completely unify" does it mean not having features that don't overlap anymore ?
11:18 < BlueMatt> would be somewhat wasteful, but oh well
11:18 <@rusty> sstone: Yes, we won't overlap.  That's almost a requirement, since people want to be able to select for peer features before connect, as we've seen.
11:19 <@rusty> (Technically, we could add another field to node_announce, but it's easier to just have no overlap).
11:19 < sstone> ok
11:19 <@rusty> We can always recycle bits by introducing a mega bit which supercedes previous bits.
11:19 <@rusty> (Note to self: this is a horrible idea rusty, WTF are you thinking)
11:20 <@rusty> OK, so while we won't merge the feature assignments, we'll take them as stable for the moment?
11:20 < BlueMatt> ack
11:20 < cdecker> Well, not having them overlap is useful, at least we need to keep less context in mind to map bits to features, but we should still only use them in a context in which they are sensible
11:21 < BlueMatt> agreed
11:21 < cdecker> SGTM
11:21 <@rusty> #action rusty to update accepted proposal index at https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States with nominal feature assignments.
11:21 < sstone> sgtm
11:22 <@rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/578
11:22 <@rusty> I first rejected this out-of-hand as non-backwards compat, but it's actually not that impossible.
11:22 < cdecker> This is an interesting one
11:23 <@rusty> 1 hr was my initial guess, with high bitcoin price volatility.  I actually think in practice it's been a PITA.
11:23 < cdecker> For one I disagree that the fallback should be to open a new channel with the merchant (leads to preferential attachment)
11:23 <@rusty> cdecker: well, you may need to open a channel with *someone*.
11:23 < cdecker> Rather we should fall back to on-chain transaction and in parallel open a channel to someone
11:23 < BlueMatt> yea, I dont think "I tried to pay this guy once" is neccessarily the best channel-open strategy
11:23 <@rusty> In my limited experience, 1 day would have been far preferable to 1 hour.
11:24 < cdecker> And we definitely should not do that in an automated way which is what I read between the lines
11:25 <@rusty> Note: during transition, it would be unclear what a missing 'x' meant.  Was it 1 hour, or 1 day?  But if we assume 1 day and get it wrong, other end will in fact reject.  So it's not a disaster, just a bit of UX nastiness.
11:25 < cdecker> Yeah, but we should push merchants to opt-in to longer timeouts, not having them opt-out of them
11:25 <@rusty> So I suggest we accept this, with a suggestion that during transition, x be explicit.
11:26 < BlueMatt> why? why not just have a note suggesting that people should try to use more than 3600 if possible
11:26 < BlueMatt> and x should be explicit
11:26 <@rusty> Technically, the x default is an optimization; any implementation can choose whatever default they want.  In practice, however, they saw bolt11 as guidence.
11:26 < BlueMatt> so split the guidance into two: default, and default-if-not-present
11:26 < sstone> but 1 day is really a long time when your payment does not go through. I'm not sure it's better UX
11:27 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 268 seconds]
11:27 <@rusty> sstone: 1 day covers all the timezones though.
11:27 < sstone> at least with 1h you don't have to worry that much about paying for something that may not make sense anymore or may not even be available
11:28 <@rusty> sstone: yes, that was the original intent.  But for online stores, like the blockstream store, we would have been happier with a 1 day option.
11:28 <@rusty> Though it implies Just in Time inventory management.
11:28 < cdecker> Having invoices expire only after 1 day also means that the default shopping cart timeout is 1 day, which causes merchants to reserve stuff for way longer
11:29 <@rusty> cdecker: but 1 hour is still a long time for some orders.  When I order concert tickets or book flights it's 15 minutes.
11:30 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev
11:30 < sstone> and with 1h you can retry safely, though it seems many shops don't actually enforce payment expiries :(
11:31 <@rusty> Good discussion; I think c-lightning might increase default (my original idea was 1 hr + 10 minutes per block we require for channel confirmation, but I think cdecker will disagree with that).
11:32 < cdecker> Well, that puts us at 80 minutes in expectation which is way more reasonable than 1440 :-)
11:32 <@rusty> OK, so I think the consensus is that there's no magic value; certainly not anything enough to make us break compat.  So this becomes an implementation recommendation, should I draft something?
11:32 < cdecker> SGTM :-)
11:33 <@rusty> #action rusty to draft words around how implementations should select expiry values; no default change.
11:33 <@rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/584
11:33 <@rusty> sstone: you have the floor :)
11:34 < sstone> I thought that the channel queries are really close to what we need for INV-based gossip
11:34 < sstone> so I went for it
11:35 < sstone> Basically you announce the channel_updates that you have
11:36 < sstone> when you receive an inv message you compare to what you have and query what you need. And I've reused the "checksum" from the extended channel queries to filter on content as well
11:37 < cdecker> It's a nice and clean proposal imho
11:37 <@rusty> sstone: Again, this looks elegent and simple.  Should we try implementing this once we've got 557 working between us?
11:37 < cdecker> Am I correct in assuming that the checksums can be computed on demand (since we don't query with them, rather we only check for changes)
11:37 < cdecker> ?
11:38 < cdecker> Just want to make sure we don't actually need yet another index into our gossip data
11:39 <@rusty> (BTW, my raspberry Pi node with USB-connected spinning rust drive is now up-to-date with the main chain, so I will be playing with optimizations like this on that node.  It validates almost 3 blocks per minute!)
11:39 < sstone> for each channel update you compare your local checksum to the one you've received and if they match you may decide not to ask for it even if it is newer
11:40 <@rusty> cdecker: yes, we'd probably just store the 4 bytes, but yes, no index needed.
11:40 <@rusty> sstone: do you have an implementation yet
11:41 < sstone> not yet but I can have something very soon so if you're game I can test with c-lightning when you're ready. I just wanted some feedback first before I started implementing
11:41 <@rusty> sstone: OK, let's do 557 first, then aim for this.
11:42 <@rusty> # action rusty,sstone to implement between implementations after 557.
11:42 <@rusty> #action rusty,sstone to implement between implementations after 557.
11:42 < cdecker> Excellent :-)
11:42 <@rusty> In case the ' ' mattered...
11:43 <@rusty> #topic https://github.com/lightningnetwork/lightning-rfc/issues/586
11:44 <@rusty> .... what's that roasbeef?  You unconditionally approve this and want it merged immediately? Great!
11:44 < cdecker> Ok, this is basically the linked up version of the ML post I did 2 weeks ago
11:44 < cdecker> LOL :-)
11:44 <@rusty> cdecker: given roasbeef is MIA, I think we need to defer.  But I reviewed the implementation, and it does seem straightforward.
11:45 < cdecker> Given the lack of discussion on the ML I assume I should probably just write up the BOLT changes so we can discuss in detail next time (and we have an issue to put on the agenda)
11:45 < cdecker> s/lack of discussion/lack of criticism/g :-)
11:45 <@rusty> cdecker: Agreed.  I didn't put my MPP proposal up for this meeting, since implementation depends on this decision, but I'd really like to move forward with that after this.
11:46 < cdecker> That and the rendezvous routing and spontaneous payments which are all pretty exciting imho
11:46 <@rusty> #action cdecker to write up formal BOLT 4 proposal.
11:46 < cdecker> SGTM
11:47 <@rusty> OK, any other business we should discuss?  Like, how to find that kid from http://lightning.pictures who still hasn't sent me the picture?
11:48 < BlueMatt> so I found a strange corner-case via fuzzing that may be of interest to folks:
11:49 < BlueMatt> in receiving an update_add_htlc, I was enforcing the reserve value based on all relevant inbound htlcs, which made sense, but the other side sometimes forgot about htlcs that it just needed to send a final raa to confirm removal for, resulting in htlcs getting rejected for reserve-value-violations
11:50 < BlueMatt> ie lesson is make sure the reserve-value restriction applies to whatever their *next* commitment transaction will contain when applying it based on update_add_htlc, ie not including things which are sufficiently far along the removal process
11:50 < BlueMatt> of course to hit this the fuzzer found some stupidly strange test-cases with crazy in-flight htlcs in both directions generated at exactly the right time
11:51 < BlueMatt> but, hey, thats why I have protocol-level fuzzers :P
11:51 <@rusty> BlueMatt: there's a subtlety here; you're explicitly allowed to defer checks until commit, which is detectable as it's a bit looser in this case I think,
11:52 <@rusty> BlueMatt: (we check as you go, because debugging otherwise would be a PITA)
11:52 < BlueMatt> yes, if you deferred the checks it would be ok
11:52 <@rusty> BlueMatt: well, as long as you *remove* first, then add...
11:52 < BlueMatt> but if you dont (which I dont do, at least for reserve value), then you need to make sure that you're ignoring htlcs that you still see, but which are in-flight-to-be-removed-before-their-next-commitment-tx
11:52 <@rusty> BlueMatt: yeah.
11:53 < BlueMatt> anyway, yay protocol-level-fuzzing!
11:53 < BlueMatt> found so many stupidly-subtle bugs this way
11:53 <@rusty> BlueMatt: nice!  I look forward to turning those into portable JSON tests one day when I get my act together.
11:53 < cdecker> Sounds awesome, fuzzing is still on our roadmap somewhere
11:54 < BlueMatt> rusty: they're all written as rust-lightning calls, but it should be reasonably doable to convert them
11:55 <@rusty> BlueMatt: yes, I need to get back to that project, which is buried in a branch on GH.  It will allow nice sharing of these kind of corner cases.
11:55 < cdecker> Speaking of JSON tests: the c-lightning frame-onion PR contains a tool and JSON onion specs for future tests
11:55 <@rusty> cdecker: nice, I missed that!
11:56 < BlueMatt> cdecker: sadly, the only real reason rust-lightning has protocol-level-fuzzing is that you can run multiple of them in a single process and make them talk to each other....
11:56 < cdecker> Hehe, c-lightning still has a test of the state-machine that Rusty wrote at the very beginning that basically has two nodes talk to each other
11:57 <@rusty> Oh, BTW, lnd still has the "send an empty update under stress" bug; c-lightning is going to have to allow it, as it breaks channels.
11:58 < cdecker> Yep, and we are officially in quirksmode territory :-)
11:58 < BlueMatt> ugh
11:58 < sstone> rusty: you mean send a sig when there are no changes ?
11:58 <@rusty> sstone: yeah.
11:59 <@rusty> OK, if no more topics, I'll close meeting?
12:00 < cdecker> +1
12:00 < BlueMatt> yea, sorry for the tangent
12:00 < BlueMatt> just figured it may be of interest
12:00 < cdecker> It definitely is interesting
12:00 <@rusty> BlueMatt: no, it's great!
12:00 < cdecker> Thanks ^^
12:00 < sstone> it was!
12:00 <@rusty> #endmeeting
12:00 < lightningbot> Meeting ended Mon Mar  4 20:00:48 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-03-04-19.02.html
12:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-03-04-19.02.txt
12:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-03-04-19.02.log.html
12:01 < BlueMatt> https://github.com/TheBlueMatt/rust-lightning/commit/613323d4df4a2dbc6784006ed05b05a894f5ee2f <- fix, fwiw, unit-test form still in-progress
12:06 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 256 seconds]
12:07 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has quit [Remote host closed the connection]
12:08 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving]
12:08 -!- kanzure [~kanzure@unaffiliated/kanzure] has quit [Ping timeout: 246 seconds]
12:09 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #lightning-dev
12:09 -!- hiroki [a331cce4@gateway/web/freenode/ip.163.49.204.228] has quit [Quit: Page closed]
12:20 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev
12:21 -!- araspitzu [~ott0disk@5.170.48.56] has quit [Quit: Leaving]
12:31 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.4]
12:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
12:56 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
13:06 -!- nkohen [~nkohen@199.188.64.16] has quit [Quit: Leaving]
13:19 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 244 seconds]
13:22 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev
13:36 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
13:49 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #lightning-dev
13:52 -!- Eliel [~jojkaart@163.172.153.251] has joined #lightning-dev
14:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
14:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
14:09 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
14:11 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #lightning-dev
14:11 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
14:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
14:36 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev
14:40 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has quit [Remote host closed the connection]
15:08 -!- makey40 [~jodie@24.215.123.241] has joined #lightning-dev
15:11 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
15:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
15:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:55 -!- makey40 [~jodie@24.215.123.241] has quit [Quit: WeeChat 1.0.1]
16:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds]
16:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
16:25 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev
16:36 -!- arshbot [unknown@overflod.chary.us] has quit [Quit: ZNC - https://znc.in]
16:36 -!- arshbot [unknown@2604:180::7f1b:29b8] has joined #lightning-dev
16:36 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has quit [Remote host closed the connection]
16:37 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev
16:38 -!- thomasan_ [~thomasand@cpe-172-116-160-42.socal.res.rr.com] has quit [Remote host closed the connection]
16:56 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
17:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
18:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
18:35 -!- riclas [~riclas@148.63.37.111] has quit [Ping timeout: 268 seconds]
18:52 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 255 seconds]
18:57 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #lightning-dev
18:59 -!- unixb0y [~unixb0y@p5B029972.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
19:00 -!- unixb0y [~unixb0y@p5B029A01.dip0.t-ipconnect.de] has joined #lightning-dev
20:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
20:10 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
20:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:10 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
22:23 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev
22:49 -!- alldev [4d77807f@gateway/web/freenode/ip.77.119.128.127] has joined #lightning-dev
22:55 -!- alldev [4d77807f@gateway/web/freenode/ip.77.119.128.127] has quit [Quit: Page closed]
--- Log closed Tue Mar 05 00:00:07 2019