--- Log opened Mon Jun 24 00:00:51 2019 00:30 -!- reallll is now known as belcher 00:43 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev 00:47 -!- moonfunjohn [~moonfunjo@218.20.9.108] has quit [Ping timeout: 246 seconds] 00:47 -!- moonfunjohn [~moonfunjo@218.20.10.62] has joined #lightning-dev 00:51 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Remote host closed the connection] 00:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 00:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 01:05 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #lightning-dev 01:08 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev 01:16 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds] 01:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 248 seconds] 01:21 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev 01:23 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds] 01:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 01:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Remote host closed the connection] 01:45 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds] 01:51 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 01:56 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Ping timeout: 272 seconds] 01:59 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 02:00 -!- shesek [~shesek@188.120.150.117] has joined #lightning-dev 02:00 -!- shesek [~shesek@188.120.150.117] has quit [Changing host] 02:00 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 02:10 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 02:22 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 248 seconds] 02:25 -!- darosior [6dbe8dc1@193-141-190-109.dsl.ovh.fr] has joined #lightning-dev 02:29 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev 03:37 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev 03:39 -!- m-schmoock [~will@schmoock.net] has quit [Ping timeout: 258 seconds] 03:44 -!- GAit [~GAit@unaffiliated/gait] has quit [Ping timeout: 244 seconds] 03:44 -!- Madars_ [~null@unaffiliated/madars] has joined #lightning-dev 03:45 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 264 seconds] 03:52 -!- GAit [~GAit@unaffiliated/gait] has joined #lightning-dev 04:00 -!- m-schmoock [~will@schmoock.net] has joined #lightning-dev 04:06 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 04:06 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 04:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 04:12 -!- renlord [~renlord@gateway/tor-sasl/renlord] has joined #lightning-dev 04:42 -!- bralyclow01 [~bralyclow@unaffiliated/bralyclow] has joined #lightning-dev 04:44 -!- bralyclow [~bralyclow@unaffiliated/bralyclow] has quit [Ping timeout: 246 seconds] 04:46 -!- nirved_ [~nirved@2a02:8071:b58a:3c00:3ca6:9fb9:2e23:4e12] has quit [Ping timeout: 252 seconds] 04:50 -!- nirved [~nirved@2a02:8071:b58a:3c00:f5ca:5b97:e492:79dc] has joined #lightning-dev 05:02 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 272 seconds] 05:04 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 05:19 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #lightning-dev 05:35 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 05:52 -!- shesek [~shesek@188.120.150.117] has joined #lightning-dev 05:52 -!- shesek [~shesek@188.120.150.117] has quit [Changing host] 05:52 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 06:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 06:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 06:41 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 06:42 -!- gabuqo [~gabuqo@gateway/tor-sasl/gabuqo] has joined #lightning-dev 06:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 06:58 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 07:16 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds] 07:22 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev 07:33 -!- bralyclow [~bralyclow@unaffiliated/bralyclow] has joined #lightning-dev 07:36 -!- bralyclow01 [~bralyclow@unaffiliated/bralyclow] has quit [Ping timeout: 245 seconds] 07:38 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 07:48 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Remote host closed the connection] 07:49 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 07:53 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds] 07:58 -!- queip [~queip@unaffiliated/rezurus] has quit [Quit: bye, freenode] 08:19 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 08:24 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Ping timeout: 272 seconds] 09:01 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving] 09:07 -!- gabuqo [~gabuqo@gateway/tor-sasl/gabuqo] has quit [Remote host closed the connection] 09:17 -!- darosior [6dbe8dc1@193-141-190-109.dsl.ovh.fr] has quit [Remote host closed the connection] 09:17 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 09:35 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 09:35 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Remote host closed the connection] 09:35 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 09:52 -!- bralyclow01 [~bralyclow@unaffiliated/bralyclow] has joined #lightning-dev 09:54 -!- bralyclow [~bralyclow@unaffiliated/bralyclow] has quit [Ping timeout: 245 seconds] 10:55 -!- darosior [5ba5be47@91-165-190-71.subs.proxad.net] has joined #lightning-dev 11:11 -!- michaelfolkson [~textual@81.134.128.130] has joined #lightning-dev 11:14 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 11:19 -!- michaelfolkson [~textual@81.134.128.130] has quit [Quit: Sleep mode] 11:20 -!- michaelfolkson [~textual@81.134.128.130] has joined #lightning-dev 11:23 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Remote host closed the connection] 11:26 -!- michaelfolkson [~textual@81.134.128.130] has quit [Quit: Sleep mode] 11:26 -!- michaelfolkson [~textual@81.134.128.130] has joined #lightning-dev 11:34 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 11:48 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 11:49 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #lightning-dev 11:50 -!- bralyclow01 [~bralyclow@unaffiliated/bralyclow] has quit [Ping timeout: 245 seconds] 11:59 -!- ianthius [~ianthius@unaffiliated/ianthius] has joined #lightning-dev 12:00 -!- eklitzke [~evan@monad.io] has joined #lightning-dev 12:01 -!- eklitzke [~evan@monad.io] has quit [Client Quit] 12:01 < ianthius> what is the planned methos of onboaring no-coiners to bitcoin via the lightning labs lightning wallet? e.g how can i use lightning to send funds to a brand new lightning wallet with no money in it? 12:01 < ianthius> this is a critical use case and I am interested in how this will work and when it will be available 12:03 < lndbot> There is the Lightning Loop service that can help with inbound liquidity 12:04 < ianthius> alex, will it be built in to the lightning labs android app in some capacity? 12:04 < lndbot> Yes that is planned 12:08 < ianthius> so the no-coiner will open the wallet write down their recovery phrase and then select an option to create a lightning invoice without any existing channels? when the invoice is paid some of the money goes to the loop service? where will the loop service be mentioned? on the sending or recieving side? 12:09 < lndbot> The exact UI is still being developed, so I’m not sure exactly how it will look 12:10 < lndbot> If you have any ideas you could post them on the app github it is an open source project 12:11 < ianthius> presumably to be non-custodial the no-coiners wallet will need to create a channel so perhaps it's not an invoice, but rather a QR with the node id for the other wallet to open a channel with them? or alternatively i suppose the person doing the onboarding would send a lightning payment to a loop node, which would then open a channel with the no-coiner? 12:11 < ianthius> forget the UI, what is the basic workflow. e.g. what computer does what, when, and in what order? 12:12 < lndbot> The Loop node itself won’t create channels 12:13 < lndbot> I’m not sure about the workflow, that’s what I mean by UI, like UI/UX is still being thought through 12:13 < lndbot> We may need other tools in Lightning for people who really have no coins 12:14 < lndbot> Like a mailbox style node that opens the end channel 12:14 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 12:45 -!- booyah [~bb@193.25.1.157] has quit [Remote host closed the connection] 12:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 258 seconds] 12:50 -!- YSqTU2XbB [~smuxi@134.28.68.51.rdns.lunanode.com] has joined #lightning-dev 12:52 -!- t-bast [~t-bast@2a01:e34:ec2c:260:6097:8c4d:c25b:16db] has joined #lightning-dev 12:55 -!- YSqTU2XbB is now known as araspitzu 12:57 -!- michaelfolkson [~textual@81.134.128.130] has quit [Quit: Sleep mode] 13:00 < araspitzu> Hi there 13:00 < t-bast> hey everyone, how is it going? 13:01 < bitconner> hi everyone 13:02 < cdecker> Heya 13:02 < lndbot> hi all 13:02 < t-bast> are some of you at the chaincode residency? 13:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:03 < cdecker> Yep, Fabrice and I are at the residency 13:03 < cdecker> So I probably shouldn't chair the meeting, not sure I can stick around the whole time 13:03 < t-bast> cool 13:03 * niftynei waves 13:04 < t-bast> does that mean niftynei wants to chair? :) 13:04 < rusty> Can we have a volunteer to chair please? 13:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev [] 13:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:04 < bitconner> sure i'll volunteer! 13:05 < t-bast> thx bitconner 13:05 < rusty> thanks! 13:05 * cdecker bows to the chair 13:05 < bitconner> cdecker, do you have the link? 13:05 <+roasbeef> link to the agenda? 13:05 < bitconner> link to the site w/ commands 13:05 < cdecker> #link https://github.com/lightningnetwork/lightning-rfc/projects/1 13:05 -!- sstone [~sstone@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #lightning-dev 13:06 <+roasbeef> cdecker: https://github.com/lightningnetwork/lightning-rfc/labels/Meeting%20Discussion 13:06 < cdecker> https://wiki.debian.org/MeetBot 13:06 < bitconner> awesome thanks! 13:06 < bitconner> #startmeeting 13:06 < lightningbot> Meeting started Mon Jun 24 20:06:28 2019 UTC. The chair is bitconner. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:06 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:07 < bitconner> alright, should we start with 619? 13:07 < cdecker> We have both pending and accepted 13:07 < cdecker> Awesome 13:07 < t-bast> Let's go for onion ;) 13:07 < cdecker> I think we have a number of things to discuss on this: 13:07 < bitconner> #topic https://github.com/lightningnetwork/lightning-rfc/pull/619 13:08 < cdecker> 1) Potential future payload formats, or fixing on TLV for now 13:08 < cdecker> 2) Keep the legacy format description as is, or generalize the overall structure and move legacy into a more specific section 13:09 < cdecker> I think all other things are addressed 13:09 < t-bast> concerning 1), I think keeping the realm byte is a fair proposal to provide more flexibility at the cost of only one byte per hop, wdyt? 13:09 < t-bast> it also allows defining a termination condition via a special realm value instead of using the last hmac 13:10 < cdecker> So keep the realm byte, define 0x01 as TLV, and then have a varint after that to determine the payload length? 13:10 < t-bast> exactly 13:10 < cdecker> t-bast: I disagree on encoding the last hop in the realm 13:10 < t-bast> at least that's how I understood it, roasbeef & bitconner wdyt? 13:10 < cdecker> That really should be part of the TLV 13:10 < bitconner> t-bast, sounds right to me 13:10 < bitconner> cdecker, why is that? 13:10 < t-bast> cdecker: but if it's part of the TLV that's a bit of a layering violation though, the onion parser needs to start interpreting the TLV payloads doesn't it? 13:11 < bitconner> it seems more complicated to require/not-require fields conditional on the presence of others 13:11 <+roasbeef> sounds good to be up until the var int, at that point we can still use only 3 bytes by using a fixed sized 2 byte integer there 13:11 < cdecker> Oh, I see for the hmac on terminal nodes 13:12 < cdecker> Problem is that the HMAC is already being speacial-cased when processing the onion 13:12 < t-bast> exactly, instead of signaling termination via 32 0x00 bytes, we signal it via realm = 255. We change the hmac special case to be a realm special case 13:12 -!- booyah [~bb@193.25.1.157] has joined #lightning-dev 13:12 < cdecker> No, we are not actually acting on the HMAC at all, we just hand it up 13:13 < bitconner> t-bast, my original ideaa was to signal with the high order bit, and keep the remaining 7 bits for other versions 13:13 < cdecker> Remember that the HMAC inside the payload is destined for the next hop, not ourselves 13:13 < bitconner> even 255 is 8x more info than we need :) 13:13 < cdecker> I don't see a layering violation with that setup at all 13:13 < t-bast> cdecker: oh right, indeed 13:13 <+roasbeef> yeah it's a diff layer imo, like onion just does parsing, then the thing that actually makes the forwarding decisions is at the channel/link layer 13:13 < t-bast> bitconner: definitely, it was just a visual argument :) 13:14 < cdecker> TLV has a "terminal" type and then we know that the HMAC being handed up (that would be used when serializing for the next hop) is just garbage like usual 13:14 < t-bast> yeah that does work too and is quite simple 13:14 < cdecker> Since we are not doing anything with the garbage HMAC in case of a terminal payload, I don't see a layering violation here 13:15 < rusty> BTW, Re: realm. 0 is an even type, so future implementations that drop legacy handling will Just Work in that they'll reject it. 13:16 < cdecker> Ok, can we agree that using signalling final hop in the realm is not needed? 13:16 < t-bast> I agree that we can do it using TLV 13:16 < bitconner> cdecker, so then can't we signal the final hop via whether or not there is a short_chan_id present? 13:16 < cdecker> Sure, that works as well 13:16 < t-bast> and after thinking about it a bit more, it's not the onion parser who should decide termination but rather the layer that interprets the TLV so it makes sense 13:16 < cdecker> But I think explicit signalling is better bitconner 13:17 < cdecker> Reason being that we might find other ways of specifying the next hop, which also omits the scid 13:17 < t-bast> we do agree though that we can choose to signal termination at the TLV interpretation level, do we all agree on that? 13:17 < cdecker> It's 2 bytes (1 byte type, 1 byte 0x00 length) 13:17 < rusty> t-bast: ack 13:18 < bitconner> sgtm, yeah i can see that we may want them distinct 13:18 < cdecker> t-bast: ack 13:18 < t-bast> cool I think the other question was keeping the realm byte to move away from TLV if needed in the future 13:18 < t-bast> and have real 0x01 be TLV stream as currently specified 13:18 < cdecker> Ok, then for (1) we just need to decide whether we want to save 1 byte by keeping the realm and add the varint or smash them together 13:18 < bitconner> #agreed signal termination via TLV record 13:19 < t-bast> I don't have a very strong opinion on that, but it does feel safer to keep the realm as an additional upgrade mechanism 13:19 < rusty> t-bast: Hacky as it is, just not defining a type 0 and having code to peek "is the first byte 0?" works. 13:19 < bitconner> my preference would be to keep the realm for versioning 13:19 < t-bast> rusty: agreed for version 0, but if we want to update to use something else than TLV (like TLV 2.0) we need a way to signal this right? while still supporting tlv 1.0? 13:20 < rusty> I think we're fairly wedded to the idea of TLV being the future upgrade mechanism. We still have the onion version if we want to ugprade. 13:20 <+roasbeef> i'm for realm and 2 byte fixed integer (no need for var int for signalling, but it's more interesting in the onion for values since we can save some space) 13:20 < bitconner> rusty, would say upgrade path on the outer version isn't super clear atm 13:20 < t-bast> if we're fully committed to TLV no need for the realm. If we're having doubts I think we need it :) 13:20 <+roasbeef> yeh i'd like to keep the real upgrade path in tact, juuust in case 13:20 < cdecker> Just so I mentioned this: the current writeup special-cases realm 0x00 and uses all others as the byte length of the payload 13:20 < t-bast> my first comment was also that we still have the outer version if needed 13:21 < cdecker> roasbeef: I still want the varint for the length, since 90+% will use <253 byte payloads we can really safe quite a bit there 13:21 < t-bast> roasbeef: I'm not sure it saves some space, because it means each payload always needs 2 bytes for length whereas most payloads will be less than 253 bytes so would need a single byte...I'd say we should optimize for the most common case so I'm not a big fan of fixed 2 bytes length 13:22 < rusty> cdecker: ah, yes, of course. So the byte is not redundant. While I'm all about future compat, I think this is a bit too far. 13:22 <+roasbeef> t-bast: the var int type can use a single byte for smaller values? iirc the bitcoin var int is also 2 bytes minimal 13:22 < t-bast> roasbeef: no, varint is 1 byte for values less than 253 13:22 < cdecker> roasbeef: values <253 are represented in a single byte 13:22 <+roasbeef> gotcha 13:22 < t-bast> that's why I think it's nice 13:22 < cdecker> Yep 13:23 < t-bast> (for onion) 13:23 <+roasbeef> ok seems more worth it in that case, we're talking about the length prefix here right? 13:23 < t-bast> yes exactly 13:23 < cdecker> Yep 13:23 < rusty> We can also reserve length 1, since that's impossible too, if we want. 13:23 < t-bast> good point 13:23 < cdecker> rusty: pretty much any value below 8 is likely to never be used for the length 13:24 < bitconner> since we're saving one byte on the length, we can reinstate realm for free ;) 13:24 < niftynei> lol 13:24 < cdecker> So we could reserve realm/packet_type 0-7 for other formats 13:24 < t-bast> :) 13:24 < t-bast> that sounds like a good compromise 13:24 < rusty> cdecker: not if clever people end up encoding everything in the shared secret :) 13:25 < t-bast> rusty: that sounds fancy, I want the logs of such a proposal :) 13:25 < cdecker> That's going to be hard rusty, basically breaks the crypto assumptions we have if we try to pack fixed information in there :-) 13:25 < t-bast> roasbeef, bitconner, what do you think about that compromise? 13:26 < cdecker> Compromise being realm byte intact + varint for payload length? 13:26 < t-bast> we keep the current proposal by cdecker (no realm byte) but still have values 0-7 as an escape hatch if we really want to get rid of tlv 13:26 < cdecker> Oh, I see, thanks t-bast 13:27 < t-bast> we can explicitly disallow length values beneath 8, or just assume that no-one is going to be using those anyway 13:27 < bitconner> would still lean towards realm+varint, overloading seems less than desirable 13:27 < rusty> t-bast: I'm uncomfortable with that. len=1 doesn't need to be special-cased. 13:28 < cdecker> I mean, I pretty much like the idea of keeping the realm byte in place and not be as stingy with space, but I also like the current writeup and want it merged :-) 13:28 * cdecker flipflops a lot when he's jetlagged 13:29 < rusty> cdecker: I think it's worth thinking of what this looks like in a post-legacy world. The realm byte there will look odd, IMHO. 13:29 <+roasbeef> so this comnbines both relam and legnth? why not clean separation? 13:29 < rusty> roasbeef: because, since length < 2 is impossible, it is a clean separation :) 13:30 < t-bast> rusty: that means length = 1 would need to be treated as a completely new thing right? to keep interpreting the bytes that come after? 13:30 < cdecker> roasbeef: the question is much more whether we want to make legacy a special case and TLV the default or to keep both at the same level 13:31 < t-bast> cdecker: agreed, good way of clarifying it 13:31 < rusty> t-bast: sure, but that's beautiful. We don't need to do *anything* until/unless we decide we need a new version. Currently implementations will already fail to parse len=1. 13:32 < t-bast> rusty: I agree that it looks clean, I'm ok with that solution (as I'm not even sure this escape mechanism will ever be needed) 13:32 < t-bast> that would mean keeping the proposal as-is currently in the PR right? 13:33 < bitconner> we'd sill need to add the signaling condition 13:33 <+roasbeef> wouldn't say having a double interpretation of the field is a clean separation, it's overloading the length 13:33 < t-bast> bitconner: yes of course, just on the realm vs no-realm discussion 13:34 < t-bast> roasbeef: it saves up to 20 bytes!!! maybe even a few more, I know you could squeeze many cool things in those bytes :) 13:34 < rusty> roasbeef: sure. But it's even cleaner once we get rid of legacy support. Y'know, when we're retired :) 13:36 < bitconner> as much as i'd like to think we will never need to upgrade the inner version, that isn't the conclusion experience would lead me to :) 13:37 < bitconner> so i think we want some versioning, and whether we want those upgrade paths to be hindered by the overloading is unclear 13:37 < bitconner> well, actually i'd say it'd be preferable that the inner versions are all on the same level as cdecker phrased it 13:38 < rusty> bitconner: my experience tells me the opposite. We went for a flexible format so we don't have to upgrade again, but we've still left an "out" if we need. I'm happy. 13:38 -!- sstone__ [~sstone@li1491-181.members.linode.com] has joined #lightning-dev 13:38 -!- sstone__ [~sstone@li1491-181.members.linode.com] has quit [Client Quit] 13:38 < bitconner> the out being 0-7 bytes? 13:38 < t-bast> bitconner: that means you don't believe that much in TLV, even though you made the PR! 13:38 < bitconner> realm 0-7* 13:39 < rusty> bitconner: well, I don't like 0-7, but 0-1 I'm happy with since it happens automatically. 13:39 < bitconner> t-bast nothing to do with believing in tlv 13:39 < t-bast> bitconner: I know, just teasing ;) 13:39 < bitconner> tlv isn't a magic bullet :) 13:39 < t-bast> but we still always have the onion outer version explicitly there for upgrades 13:40 < t-bast> I don't understand why we're not feeling that as an upgrade safety net 13:40 -!- sstone [~sstone@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 272 seconds] 13:40 <+roasbeef> because the outer oino version change is a hard fork essentially, it isn't committed to at all 13:40 < bitconner> the outer version is more difficult to change, it requires a network-wide upgrade to be effective 13:41 < bitconner> all hops in the path must use the same outer version, so you're always constrained to the lowest common denominator 13:41 < t-bast> why? because intermediate nodes would override your version with a 0? 13:41 < t-bast> I think it would just mean that you wouldn't be routing through nodes that only support v0 indeed 13:41 < t-bast> but I think that would likely be the case anyway if you want to upgrade routing 13:42 < t-bast> regardless of whether you use the outer version or only inner versions 13:42 < t-bast> and you'll be looking at each node's feature flags anyway before including them in a route with new features 13:43 -!- sstone [~sstone@li1491-181.members.linode.com] has joined #lightning-dev 13:44 < rusty> ... and that's only once we've exhausted the len=1 upgrade option. My experience leads me to believe that we are not likely to use either, FWIW. 13:44 < t-bast> I think so too 13:45 < bitconner> okay so is there agreement on len=1 upgrade path being sufficient? 13:45 < t-bast> sgtm 13:45 < rusty> ack 13:46 < bitconner> #agreed no-realm, signal future versions with low-value lengths 13:47 < rusty> This means, aside from perhaps a note that we can use len=1 in future for upgrades, we can apply as-is? 13:47 < bitconner> once the signaling mechanism is added i think so 13:48 < t-bast> I think so, only a few nits to fix and termination signaling to describe and it should be ready 13:48 < t-bast> decker, wdyt? 13:48 < t-bast> *cdecker 13:48 < bitconner> #topic https://github.com/lightningnetwork/lightning-rfc/pull/557 13:48 < t-bast> shouldn't we do 607 before 557? 13:49 < t-bast> I think 557 builds on 607 13:49 < bitconner> i think since last time, extended gossip queries replaced Adler32 with CRC32 13:49 < bitconner> t-bast, i think 607 was good just need to add test vectors 13:49 < rusty> Yes, sorry, I've been distracted, so I need to revisit 557, with tests. 13:49 < t-bast> bitconner: perfect, sgtm 13:49 < bitconner> wanted to get this in before time is up 13:49 < t-bast> cool thx 13:49 < bitconner> anyone else have comments on 557? 13:50 < sstone> the test vectors I added for 557 should be valid with the latest TLV PR 13:51 < bitconner> sstone: great! 13:51 < rusty> bitconner: I am happy to ack it, and have the test vectors added as a separate commit. 13:51 < rusty> (After I've tested them of course!) 13:51 < bitconner> rusty: we talking about 557 or 607? 13:51 < rusty> Sorry, 607. 13:52 < bitconner> ah okay, well looks like both could use committed test vectors actually :) 13:52 < rusty> 557 I'm still working on our implementation. Apologies, but it should now go much smoother since we have TLV defined. Also, it's our first use of TLV in the spec, so I need to make sure we're happy with the exact format.' 13:53 < bitconner> rusty: yes that reminds me i had a comment on 619 regarding the tlv field formatting 13:53 < rusty> (I did want to ask about tools/extract-formats.py -- do other people care or can niftynei and I go nuts in there?) 13:53 < bitconner> sure don't see why no 13:54 < bitconner> not 13:54 < niftynei> :D 13:54 < t-bast> have fun ;) 13:54 < bitconner> okay so seems 557 still good from design perspective, waiting on impls? 13:54 < t-bast> sgtm 13:54 < rusty> Good.... I've got a very early set of conversational test (finally!) running, which use that to parse the spec to create messages. It's pretty sweet, hope a topic for next mtg. 13:55 < rusty> bitconner: ack. 13:55 < bitconner> #agreed design still solid, waiting on feedback from second impl 13:56 < rusty> sstone: note, with CRC we should specify the Castagnoli CRC-32C polynomial used in iSCSI or SCTP. We can include a ref to the iSCSI test vectors, too. THat's what Intel implemented, FWIW. 13:56 < cdecker> Sorry for not replying on 619, I'll amend by adding the terminal signalling and the special-case for realm=0x01 as an escape hatch 13:57 < sstone> rusty: thanks I'll update the PR 13:57 < t-bast> Do we have some time to discuss feature bits unification and large channels? #571 and #596. I think those are pretty small and simple but useful. 13:57 < rusty> cdecker: you don't specify 0x01, since it's already going to fail parsing. Just note it. 13:57 < bitconner> sure t-bast 13:58 < rusty> YEah, 571 is almost entirely janatorial. 13:58 < bitconner> #topic https://github.com/lightningnetwork/lightning-rfc/pull/571 13:58 < rusty> Renaming, and making sure feature bits don't overlap. Removing some cases where we said we should reject msgs, which was short-sighted. 13:59 < bitconner> rusty, why do we refer to them as channelfeatures? and not something like connfeatures? 13:59 < bitconner> since there can be more than one channel, and the features may apply to more than just channel operation 14:00 < t-bast> do you have an example on something else than a channel operation which wouldn't be a nodefeature? 14:00 < rusty> bitconner: *channel* features are things people need to know about the channel. ie. externally visible (prev global). 14:00 < rusty> bitconner: node features are much more common (we don't have any channel features yet) 14:00 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 248 seconds] 14:01 < bitconner> oh i see, misread that as the renaming for localfeatures 14:01 < bitconner> still though, that can be used to signal other node-related things that don't apply to channels 14:01 < bitconner> like option_i_haz_channel_proofs 14:01 < rusty> bitconner: it's advertized in channel_annoucement... 14:02 < rusty> bitconner: option_i_haz_channel_proofs is a node feature, no? 14:02 < rusty> (Depends on what channel proofs are I guess?) 14:05 <+roasbeef> yeh would say that's a node feature, but it depends on how we roll it out: is it attached to all chan anns, or do you query for them on a per channel basis? 14:06 < araspitzu> #590 uses the global features atm, with #571 should it become a channel feature? If so then using `channel_update.htlc_maximum_msat` for routing information makes the large channel option kinda redundant in the new channel features 14:06 < rusty> roasbeef: since a third party can attach it, I assumed it'd be for all channel_anns. 14:06 < rusty> araspitzu: indeed. 14:07 < araspitzu> how about encoding 'this node supports opening channel with feature X'? it seems a better fit for node features 14:07 < rusty> roasbeef: I don't think we want the channel_announce to commit to it, that'd be weird. It's like an addendum, a new "channel_announcement_plus" message, I think. 14:07 <+roasbeef> would potentially be a lot of bandwidth if it's on all the channel anns though 14:07 <+roasbeef> especially for nodes that don't need them at all 14:08 < bitconner> for me i think the naming is confusing bc it's the opposite of how it reason about local vs global sets 14:08 < rusty> roasbeef: indeed. We could waste a RTT and ask for proofs explicitly, or have a feature or msg to say "attach proofs to all channel_annnouncements please". 14:09 < rusty> bitconner: yeah, I dislike the naming too. Hence, the original global or local, but people confused that as well. Perhaps 'routing' and um... ? 14:10 < rusty> Shall we bikeshed over names before next meeting? That worked well before.... 14:10 < bitconner> lol 14:11 < bitconner> do people have a strong desire to proceed with the clean up? or do we think we need more bikeshed? 14:11 < rusty> OK, so I think the distinction is fairly clear, but naming needs work. Next issue? 14:11 < bitconner> sgtm 14:12 < bitconner> #agreed work out naming of feature bit groups 14:12 < t-bast> sgtm 14:12 < araspitzu> sgtm 14:13 < bitconner> #topic https://github.com/lightningnetwork/lightning-rfc/pull/596 14:13 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 14:13 < bitconner> major comment here looked to have been whether we start at 0 or 16 14:13 < araspitzu> do we want to merge the large channel bit with the current features or we bikeshed it until #571? 14:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 14:13 < t-bast> I think we can merge with the current features, right? 14:14 < t-bast> if we agree on the name for this feature :) 14:14 < bitconner> araspitzu, that was going to be my suggestion as well. possible to proceed with them as disjoint sets 14:14 -!- rh0nj [~rh0nj@88.99.167.175] has joined #lightning-dev 14:14 < araspitzu> yes it sounds right to me too :) 14:14 < t-bast> the comment about namespace was to allow the feature bit unification (and combining local/global features) 14:14 < t-bast> it feels to me that it's safer to use a bit that's disjoint from local feature bits, wdyt? 14:15 < araspitzu> if we want them completely disjoint then it should start using globalFeatures from 0 14:15 < araspitzu> and the unification would reorg the features accordingly (and avoiding overlap) 14:15 < rusty> araspitzu: I like the idea, I'd like to give some minor textual feedback on the issue itself. Concept ack from me. 14:16 < rusty> (For technical reasons I think this should be merged after #571) 14:17 < bitconner> araspitzu: a slight naming suggestion: option_remove_funding_limit since it's more specific. up to you though :) 14:17 < araspitzu> rusty: isn't #571 backward compatible? 14:17 < rusty> araspitzu: option_what_the_hell_is_wumbo works too.... 14:17 < t-bast> araspitzu: I think my sentence ended up saying the opposite of what I meant: I think it's safer to use feature bit values that are disjoint between local and global to be able to merge them in a single byte array (what's currently done in the PR) 14:17 < araspitzu> eheh 14:18 < rusty> araspitzu: it is, just want to avoid merge hell :) 14:18 < bitconner> t-bast: yes i agree 14:18 < rusty> I've acked it, with some minor comments, now. 14:19 < bitconner> question: will this also be set in the localfeatures? 14:19 < t-bast> great, so the decision is a concept ack but we wait for 571 to be merged (hopefully next meeting) before merging 596? 14:19 < bitconner> or is the receiver supposed to just reject if they don't want the channel 14:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 14:19 < rusty> t-bast: ack 14:20 < t-bast> bitconner: I think you should reject if you don't want that channel indeed 14:20 < t-bast> bitconner: I don't think it needs to be reflected in the local features, but maybe someone has a good reason to reflect it? 14:20 < rusty> bitconner: it's a local feature, yes. But with #571 we advertize those in node_announcement too, so we can see them without having to connect to find it. 14:20 < bitconner> do we have a way of signaling that the reason for the failure is that i don't want a large channel? 14:21 < rusty> bitconner: we use generic error to reject too-small, too-large, too-salty channels... 14:21 < rusty> bitconner: though if I don't offer the feature, you shouldn't even try... 14:21 < araspitzu> t-bast: ack (i'll rebase that on #571) 14:22 < bitconner> rusty: yes but what you support could beb different from the latest node_announcement i have, setting it on the localfeatures upon connection would clarify support at the time of the request 14:22 < rusty> bitconner: that's always true, yes. 14:23 < rusty> node_announcement is always kind of best effort. 14:23 < bitconner> but since it's set in globalfeatures, we should be okay i think 14:23 < bitconner> cool then ack from me 14:23 < rusty> bitconner: ? No it's not. 14:24 < bitconner> the text says the feature bits can be sent in init? 14:24 -!- hiroki_ [d295fbaa@170.251.149.210.rev.vmobile.jp] has joined #lightning-dev 14:24 < rusty> bitconner: both global and local are sent in init 14:24 < bitconner> right, so why wouldn't we set it there? 14:25 < rusty> bitconner: we would. I'm confused... 14:25 < bitconner> my question is: is option_support_large_channel set in init upon each connection, in addition to the node_announcement 14:26 < araspitzu> bitconner: yes it is 14:26 < bitconner> great 14:26 < bitconner> thanks! 14:26 < bitconner> i think that clarifies all of my questions 14:27 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection] 14:27 < bitconner> #agreed rebase on 571 and await merge 14:27 < rusty> OK, I have to go, but good progress. Let's bikeshed later, OK! 14:27 < bitconner> sounds good, later rusty! 14:27 < t-bast> ack! 14:27 * cdecker wants to point out that #619 was updated with the requested changes before we close the meeting :-) 14:27 < t-bast> cdecker: faster than lightning 14:27 < bitconner> awesome thanks cdecker! 14:28 < bitconner> any other topics we'd like to discuss? 14:28 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:28 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 14:28 < lndbot> 608? 14:29 < lndbot> proposal has been improved since last time it was discussed. it should fix the probe vector without sacrificing the info that we get from the failure 14:29 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:29 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 14:29 < t-bast> joost: ack 14:29 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:29 < cdecker> I don't think it addresses probing at all tbh 14:30 < cdecker> Oh, wait I didn't see that it only protects against intermediate nodes 14:30 < cdecker> ack 14:30 < lndbot> it is similar to the previous merging of `incorrect_payment_amount` into invalid payment details 14:31 < bitconner> #topic https://github.com/lightningnetwork/lightning-rfc/pull/608 14:31 < bitconner> joost: ack from me 14:31 < lndbot> the new thing compared to previous time it was discussed, is that the final hop now returns its current height. that way we, as a sender, can distinguish between intermediates delaying on the forward path vs us using the wrong payment details 14:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 268 seconds] 14:32 -!- araspitzu [~smuxi@134.28.68.51.rdns.lunanode.com] has quit [Ping timeout: 244 seconds] 14:32 < lndbot> otherwise we'd get an `incorrect_or_unknown_payment_details` without knowing whether to retry via another route or stop trying 14:33 < bitconner> makes sense to me 14:33 < bitconner> we have some acks from various impls 14:34 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds] 14:34 < bitconner> might be good to have rusty chime in as well, but the meeting is quite a bit over 14:34 < bitconner> will mark as tentative approval 14:34 < t-bast> maybe tag him on github to ask for a review? 14:35 < bitconner> #agreed tnetative ACK, looking for rusty's feedback before final approval 14:35 < t-bast> joost: btw I discussed with some Tor people and it looks like they managed to achieve what you want to achieve for error message authentication with a fixed-length. They referred me to Tor proposal 295 for details, it's probably worth having a close look at how they do it. Anyone familiar with this already? 14:35 < lndbot> tentative ack, sounds good 14:36 < bitconner> t-bast, not familiiar with 295 myself, but should read up on it 14:36 < lndbot> tor parallels sounds interesting. do you have a link? 14:36 < t-bast> https://github.com/torproject/torspec/blob/master/proposals/295-relay-crypto-with-adl.txt 14:37 < t-bast> at first glance it might be tightly coupled with AES-GCM so it would not work for us 14:37 < t-bast> but worth investigating 14:38 < bitconner> thanks t-bast 14:38 < t-bast> ah no AES-CTR, strange 14:38 < bitconner> #endmeeting 14:38 < lightningbot> Meeting ended Mon Jun 24 21:38:25 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 14:38 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-06-24-20.06.html 14:38 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-06-24-20.06.txt 14:38 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-06-24-20.06.log.html 14:38 < t-bast> thanks guys, see you on github ;) 14:38 < lndbot> thx will check it out 14:38 < bitconner> sounds good, later everyone! 14:39 < cdecker> Great work everyong :-) 14:39 -!- t-bast [~t-bast@2a01:e34:ec2c:260:6097:8c4d:c25b:16db] has quit [Quit: Leaving] 14:39 < bitconner> next meeting looks like it will be a merge fiesta? :) 14:44 < lndbot> :fireworks: :fireworks: :fireworks: 14:45 -!- hiroki_ [d295fbaa@170.251.149.210.rev.vmobile.jp] has quit [Remote host closed the connection] 14:45 -!- sstone [~sstone@li1491-181.members.linode.com] has quit [Ping timeout: 252 seconds] 14:48 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:120:3abe:46f4:9ff] has joined #lightning-dev 14:48 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Quit: Leaving] 14:49 -!- araspitzu [~smuxi@134.28.68.51.rdns.lunanode.com] has joined #lightning-dev 14:54 -!- araspitzu [~smuxi@134.28.68.51.rdns.lunanode.com] has quit [Remote host closed the connection] 14:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds] 15:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds] 15:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:18 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 258 seconds] 15:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:27 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:27 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 15:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 15:35 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 16:00 -!- StopAndDecrypt_ [~StopAndDe@104.223.94.250] has quit [] 16:02 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Remote host closed the connection] 16:03 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 16:04 -!- moonfunjohn [~moonfunjo@218.20.10.62] has quit [Ping timeout: 244 seconds] 16:05 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Remote host closed the connection] 16:08 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 16:13 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:120:3abe:46f4:9ff] has quit [Quit: Sleep mode] 16:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 16:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 16:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 17:02 -!- darosior [5ba5be47@91-165-190-71.subs.proxad.net] has quit [Remote host closed the connection] 17:17 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:120:3abe:46f4:9ff] has joined #lightning-dev 17:21 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Remote host closed the connection] 17:21 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has joined #lightning-dev 17:25 -!- scoop [~scoop@c-67-190-7-239.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] 17:42 -!- riclas [~riclas@148.63.37.111] has quit [Ping timeout: 258 seconds] 18:04 -!- moonfunjohn [~moonfunjo@218.20.10.62] has joined #lightning-dev 18:10 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev 18:10 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 246 seconds] 18:13 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 244 seconds] 18:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 18:23 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:120:3abe:46f4:9ff] has quit [Quit: Sleep mode] 18:35 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 19:03 -!- moonfunjohn [~moonfunjo@218.20.10.62] has quit [Quit: Leaving...] 19:13 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev 19:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds] 19:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 19:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 19:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 19:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 19:45 -!- bralyclow01 [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #lightning-dev 19:49 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Ping timeout: 248 seconds] 19:55 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds] 19:56 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 21:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 21:08 -!- bralyclow01 [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Remote host closed the connection] 21:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 21:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 22:04 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #lightning-dev 22:16 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Remote host closed the connection] 22:24 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 245 seconds] 22:36 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #lightning-dev 22:41 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Ping timeout: 248 seconds] 22:42 -!- shesek [~shesek@5.22.134.185] has joined #lightning-dev 22:42 -!- shesek [~shesek@5.22.134.185] has quit [Changing host] 22:42 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 22:59 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #lightning-dev 23:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] --- Log closed Tue Jun 25 00:00:52 2019