--- Log opened Mon May 27 00:00:25 2019
00:10 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
00:10 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 272 seconds]
00:26 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
00:26 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
00:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds]
00:39 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
00:40 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
00:40 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 248 seconds]
00:42 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
00:54 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
00:54 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
00:56 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:dc13:eb9c:4a69:7a8d] has joined #lightning-dev
01:18 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
01:18 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 248 seconds]
01:19 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds]
01:21 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:dc13:eb9c:4a69:7a8d] has quit []
01:25 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
01:32 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
01:32 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
01:37 -!- shesek [~shesek@5.102.216.113] has joined #lightning-dev
01:37 -!- shesek [~shesek@5.102.216.113] has quit [Changing host]
01:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
01:50 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
01:50 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
02:04 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
02:04 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
02:09 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
02:13 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
02:22 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
02:22 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
02:40 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
02:40 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
02:54 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
02:54 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 272 seconds]
03:04 -!- berndj [~berndj@azna.co.za] has quit [Ping timeout: 246 seconds]
03:07 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
03:24 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
03:25 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 272 seconds]
03:27 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
03:31 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 245 seconds]
03:42 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
03:42 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
03:48 -!- nibbier [~quassel@mx01.geekbox.info] has quit [Ping timeout: 244 seconds]
03:48 -!- nibbier [~quassel@mx01.geekbox.info] has joined #lightning-dev
03:49 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev
03:58 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
04:02 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 252 seconds]
04:10 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
04:10 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 259 seconds]
04:24 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
04:24 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
04:40 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
04:41 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 272 seconds]
04:52 -!- booyah [~bb@193.25.1.157] has joined #lightning-dev
04:54 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
04:54 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
05:08 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 248 seconds]
05:08 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
05:20 -!- berndj [~berndj@azna.co.za] has joined #lightning-dev
05:26 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
05:26 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
05:54 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
05:54 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
06:18 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
06:18 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
06:21 -!- michaelfolkson [~textual@82-132-226-188.dab.02.net] has joined #lightning-dev
06:43 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
06:48 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
06:48 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
07:00 -!- nirved_ [~nirved@2a02:8071:b58a:3c00:c9dd:ae30:e933:9510] has quit [Quit: Leaving]
07:01 -!- nirved [~nirved@2a02:8071:b58a:3c00:3ca6:9fb9:2e23:4e12] has joined #lightning-dev
07:02 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has joined #lightning-dev
07:13 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
07:15 -!- michaelfolkson [~textual@82-132-226-188.dab.02.net] has quit [Ping timeout: 248 seconds]
07:21 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
07:36 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
07:36 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
07:49 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
07:51 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
07:52 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
07:52 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
07:56 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 272 seconds]
07:59 -!- ulrichard [~richi@dzcpe6300borminfo01-e0.static-hfc.datazug.ch] has quit [Remote host closed the connection]
08:02 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has quit [Remote host closed the connection]
08:03 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has joined #lightning-dev
08:06 -!- michaelfolkson [~textual@46.233.78.173] has joined #lightning-dev
08:11 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
08:17 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has quit [Remote host closed the connection]
08:18 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
08:18 -!- marijnfs__ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
08:21 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
08:31 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.4]
08:37 -!- michaelfolkson [~textual@46.233.78.173] has quit [Quit: Sleep mode]
08:42 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
08:42 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
08:48 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
08:58 -!- AbuseOfNotation [~AbuseOfNo@217.151.98.168] has joined #lightning-dev
08:58 -!- michaelfolkson [~textual@46.233.78.173] has joined #lightning-dev
09:00 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
09:04 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
09:07 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
09:08 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
09:08 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
09:08 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
09:10 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 268 seconds]
09:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]
09:32 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 248 seconds]
09:32 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
09:36 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Ping timeout: 258 seconds]
09:50 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has joined #lightning-dev
09:50 -!- marijnfs_ [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Ping timeout: 248 seconds]
09:53 -!- marijnfs [~marijnfs@x4d077a85.dyn.telefonica.de] has quit [Remote host closed the connection]
10:00 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
10:03 -!- michaelfolkson [~textual@46.233.78.173] has quit [Quit: Sleep mode]
10:42 -!- sfhi [~sfhi@178.255.154.107] has joined #lightning-dev
11:21 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev
11:22 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 248 seconds]
11:22 -!- __gotcha1 is now known as __gotcha
11:46 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #lightning-dev
11:47 < jtimon> in bolt7, in channel_update, why deduce the node_id from the channel but not the chain_hash?
11:50 < ghost43> how would you deduce the chain_hash?
11:50 < lndbot> <alexbosworth> Is it because a node can have multiple chains?
11:52 < ghost43> even if a node is on a single chain, messages re another chain could be mistakenly forwarded to it, which are trivially filterable due to chain_hash being explicitly in the message
11:53 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
11:58 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 272 seconds]
11:59 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:06 -!- sfhi [~sfhi@178.255.154.107] has quit [Read error: Connection reset by peer]
12:13 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
12:16 -!- takinbo [sid19838@gateway/web/irccloud.com/x-kmjdifsocslcvitq] has quit [Ping timeout: 252 seconds]
12:16 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-ygwbmhlhjmnoqdvi] has quit [Ping timeout: 252 seconds]
12:21 -!- Guest1469 [sid19838@gateway/web/irccloud.com/x-sojffothjulkiyil] has joined #lightning-dev
12:22 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
12:28 -!- Guest1469 [sid19838@gateway/web/irccloud.com/x-sojffothjulkiyil] has quit [Ping timeout: 248 seconds]
12:29 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 272 seconds]
12:41 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-vhagwgvkgmyhaknr] has joined #lightning-dev
12:42 -!- Guest1469 [sid19838@gateway/web/irccloud.com/x-khjxhymesieoomuc] has joined #lightning-dev
12:47 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection]
12:47 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #lightning-dev
12:52 -!- t-bast [~t-bast@2a01:e34:ec2c:260:d09b:758b:80a4:3464] has joined #lightning-dev
12:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
12:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
13:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
13:00 < t-bast> hi everyone!
13:00 < bitconner> howdy t-bast
13:01 < cdecker> Heia
13:01 -!- sstone [~sstone___@185.186.24.109.rev.sfr.net] has joined #lightning-dev
13:01 < rusty> Hello all!
13:01 < t-bast> busy schedule today (looks a lot like the last meeting heh)
13:02 < rusty> This is *fancy& cdecker: https://github.com/lightningnetwork/lightning-rfc/projects/1  nice work!
13:03 < cdecker> Yeah, thought I might just give it a try
13:04 -!- sstone [~sstone___@185.186.24.109.rev.sfr.net] has quit [Remote host closed the connection]
13:04 < t-bast> it doesn't add any tags to the issues themselves right? works completely orthogonally?
13:04 < cdecker> Yep
13:05 < cdecker> Rusty would you like to do the honors? Or does someone else volunteer?
13:05 -!- sstone [~sstone___@185.186.24.109.rev.sfr.net] has joined #lightning-dev
13:05 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
13:05 < rusty> I can do it, sure.
13:05 < rusty> #startmeeting
13:05 < lightningbot> Meeting started Mon May 27 20:05:59 2019 UTC.  The chair is rusty. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:06 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/593
13:07 < cdecker> Yay :-)
13:07  * rusty tries to remember how to drive this thing...
13:07 < t-bast> :)
13:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds]
13:08 < cdecker> So, since last meeting I changed the split to 5bits num_frames + 3 bits payload type
13:08 < cdecker> Added the multi-frame test vector that I forgot
13:08 < t-bast> sgtm and tested the updated vector against the eclair implementation: works great
13:08 < cdecker> Spelled out the explicit packet-type 0x01 + num_frames combinations
13:08 <+roasbeef> anyone have an answer to my q on there? not saying we need to modify things, but just curious to see if there's some gap in my understanding i'm over looking 
13:09 < t-bast> roasbeef: the one about the frame size?
13:09 < bitconner> roasbeef, no idt we're tied to fixed-size frames
13:09 <+roasbeef> t-bast: yeah
13:09 < rusty> #info Ping bitconner BlueMatt cdecker jb55 jimpo niftynei pm47 roasbeef sstone and anyone else i missed.
13:09 <+roasbeef> consider it a pedagogical question 
13:09 < t-bast> I answered on the PR, we're not tied to anything
13:09 < t-bast> but it would be a breaking change (something we can introduce for other version of the onion)
13:09 < bitconner> after unwrapping and shifting, the next hop won't be able to tell what frame size is used before or after
13:09 < t-bast> and I agree it makes sense for future versions to consider it
13:10 <+roasbeef> your answer made it seem as if it would violate any existing security notions 
13:10 <+roasbeef> ah, new comment 
13:10 < t-bast> I initially hadn't understood that your question was just about changing the frame size
13:10 < rusty> roasbeef: It's a very good point, actually.
13:11 < rusty> Seems like, other than "legacy reasons" there's no obv reason to go in 65-byte chunks.
13:11 < t-bast> it's something I took advantage of for trampoline routing: I proposed a bigger frame size, but actually a smaller one might make even more sense
13:11 < t-bast> I think onion v1+ can change the frame size freely
13:11 < cdecker> Yep, I don't see anything wrong with making it more flexible
13:12 < bitconner> t-bast i think the idea would be to not have frame sizes at all, but rather making each one variably sized iinm
13:12 < rusty> Strawman: 0 == 65, N != 0 == N + sizeof(hmac) ?
13:12 < cdecker> It'd take a bit more time though and some refactoring (further pushing this back)
13:13 < cdecker> rusty: that limits us to 256 bytes of payload though
13:13 < t-bast> bitconner: interesting, I'd need a bit more time to convince myself that this doesn't change the security assumptions
13:13 < cdecker> t-bast: it doesn't :-)
13:14 < rusty> cdecker: If there were... some kind of variable... integer... thing. But nobody has invented that yet!
13:14 < cdecker> So do we really want to add some more weeks to this whole variable size onion?
13:14 < cdecker> lol rusty 
13:14 < rusty> cdecker: not if we can come to agreement at this meeting :)
13:15 < cdecker> Well, we can come to an agreement now, but that still requires reworking the implementations and re-writing the spec changes
13:15 < cdecker> So that's at least 2 more weeks to have a chance to get this working
13:15 < rusty> roasbeef, bitconner: how about we do the varint thing, with 0 being legacy?  Otherwise it's a varint (length of hmac at end is implied).
13:15 < rusty> And non-zero means it contains TLV format, of course.
13:16 < rusty> This *also* solves the sentinel problem!
13:16 < jtimon> ghost43: I guess we can continue this after the meeting, but the chain_hash is included in the channel_announcement just like the node_id (except there's no need for a bit to specify the direction)
13:16 < t-bast> that sounds like a good idea
13:17 < rusty> cdecker: future generations will thank you for your patience.
13:17 < jtimon> ghost43: but if I understand you correctly, your answer is, because this way you filter out messages more eaasily, correct?
13:17 < cdecker> Ok
13:18 < rusty> Does anyone have any objections?  It means losing the "realm" bits altogether, though.
13:18 < cdecker> sgtm
13:18 < bitconner> rusty, would that mean we now only distinguish between realms of 0 and non-zero?
13:18 < t-bast> sgtm to explore this, we can comment more on the PR in the next few days
13:18 <+roasbeef> so what's the new encoding? assumed_65_bytes + some_other_bytes_here? 
13:19 < rusty> bitconner: yes, we'd now be relying on the TLV format being sufficient in future.
13:19 < bitconner> it is nice that it removes the need for a sentinel
13:19 < cdecker> Was there ever a need for a sentinel? I thought we said none were needed
13:19 <+roasbeef> yeah ran into the sentinel thing again when I tried to hook together tlv+hopframes 
13:19 <+roasbeef> the issue is that once you have the payload, you don't know where the tlv actually stops, since there's framing 
13:20 <+roasbeef> padding*
13:20 < rusty> roasbeef: 0 == legacy, non-zero == varint length-before-hmac.  non-zero also implies contents is TLV.
13:20 < cdecker> roasbeef: realm = 0 => hop_data_v0 (65 bytes), realm != 0 => varint size and TLV payload
13:20 <+roasbeef> so you have a value you've extracted, but then there's 8 extra bytes, you don't know those 8 are extra, and try to hash it as if it's a pre-image, no match 
13:20 < t-bast> rusty: this is great because it means we don't lose any byte to padding
13:21 < t-bast> it kinda defers the realm thing to the content of the TLV stream and agreeing on "standard" streams
13:21 <+roasbeef> cdecker: gotcha, so where's this new length go? still packed in realm? 
13:21 < rusty> t-bast: yeah, I think we have to thank roasbeef for asking "dumb questions" here.  I promise I'll never call him annoying again :)
13:21 < cdecker> rusty wants it to be a varint
13:21 < rusty> roasbeef: yeah.
13:21 < bitconner> idt the realm is big enought, it'd be 65-byte + varint length + tlv stream + mac
13:21 < t-bast> haha there are no dumb questions :)
13:22 < cdecker> bitconner: what's the 65 bytes in there?
13:22 <+roasbeef> the existing payload I think 
13:22 <+roasbeef> (tho leaves off those 13 unused bytes atm)
13:22 < cdecker> Nono, we encode the entire payload into a single TLV and the varint length describes the entire payload length
13:23 < cdecker> Therefore it is [varint, TLV, next HMAC]
13:23 <+roasbeef> including the current "routing instructions" payload? 
13:23 < bitconner> i see
13:23 < cdecker> Yes, we want to make the routing instructions flexible by making it into a TLV 
13:23 < rusty> cdecker: s/TLV/TVL stream/
13:23 <+roasbeef> ah, that was #604, thought we were talking about #593, so going back in that direction after all?
13:24 <+roasbeef> (routing instructions in tlv like the rest, no hybrid) 
13:24 < bitconner> we did discuss possibly including legacy info on its own, then adding tlv tlv
13:24 < cdecker> That way we can swap out parts we can in the future (shorter next-hop descriptions, shorter value descriptions, ...)
13:24 < bitconner> can we agree that the legacy info all fits in one record?
13:24 < cdecker> Right, but that's limited to 32 bytes since only realm 0x00 is non-TLV
13:24 < rusty> bitconner, roasbeef: I think it's cleaner to leave v0 alone, and go full-tlv for others.  We get to save some space.
13:24 < t-bast> small note: would that still be for onion v0? 
13:25 <+roasbeef> rusty: basically what #604 suggested right? 
13:25 < cdecker> t-bast: yes, not touching the onion version itself
13:25 < t-bast> it would effectively be using up all the current non-0 realms for onion v0 - and still having the opportunity to update the onion version for other types of changes (like changing the size of the whole packet)
13:25 < rusty> Yeah.
13:25 < bitconner> yeah i'm fine with tlv everything
13:25 < t-bast> cool I agree to that
13:26 < t-bast> so now that means we need to agree on the TLV format :D
13:26 < bitconner> would be great if hash, amt, cltv all fit in one record though, so we incur the miminal T+L overhead
13:26 < rusty> OK, I think we have consensus, just need to type it up and make sure we've colored the bikeshed correctly on the issue.  Or should we open a new one, since it's quite a change?
13:26 < cdecker> bitconner: sure, we can make the hop_data_v0 a single type-value pair, but then we'll need to swap it out entirely if we want to replace a part of it 
13:26 < bitconner> cdecker, sgtm
13:26 <+roasbeef> cool, gonna throw this comment back out there then: https://github.com/lightningnetwork/lightning-rfc/pull/604#discussion_r285790465  ;)
13:26 <+roasbeef> related comment there from decker that it's nice to be able to swap out induvidual items as well 
13:27 < rusty> bitconner: turns out that's *larger*, since TLV per amt + CLV uses less space in practice.
13:27 < rusty> (Numeric fields should *not* be fixed length,that's just wasteful)
13:27 < cdecker> Yep, especially amount and CLTV can be nicely compressed even if we use TLV
13:28 < bitconner> yes, but those can be compressed *and* still fit in one record, which is what i'm getting at
13:28 < cdecker> If we transfer < 256 msat we get a nice 3 byte representation for the value :-)
13:28 < cdecker> Honestly don't care enough at this point
13:28 < rusty> bitconner: ?  How would you encode two variable-length values in one TLV?
13:29 < bitconner> add a sentinel :^)
13:29 < cdecker> I'll get working on the variable lenght onion and you guys figure out the payload format...
13:29 < bitconner> jk, this can bikeshedded later tho
13:29 < rusty> bitconner: lol.  Or, y'know, use the existing tlv format and just ahve several :)
13:30 < rusty> OK, NP.  I think we should start a new issue, since otherwise readers will get whiplash trying to follow?
13:30 < cdecker> bitconner: let's not defer everything to later, we've been sitting on the multi-frame + TLV proposals for months now...
13:30 <+roasbeef> bitconner: why do we need a sentintel if the payload is precisely sized? 
13:31 <+roasbeef> ah multiple values in a single type? 
13:31 < bitconner> roasbeef, this was re: inside a record, but it was also a joke
13:31 < bitconner> cdecker, understood
13:31 < rusty> #action cdecker to create new varint onion proposal: 0 = legacy, non-0 = varint TLV-stream-length-before-hmac.  Details in proposal, but we seem to have consensus.
13:32 < rusty> OK, phew!
13:32 < rusty> Shall we TLV now?
13:32 < t-bast> sgtm, great idea guys
13:32 < t-bast> let's TLV
13:32 < t-bast> and everything can come together nicely
13:32 <+roasbeef> lingerin questions here seem to be: even odd or not, sentintel (tho i think just solved?), and cannonical encodings? 
13:32 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/607 vs https://github.com/lightningnetwork/lightning-rfc/pull/603 FIGHT!
13:32 <+roasbeef> (tlv) 
13:33 < t-bast> indeed sentinel just got obsolete
13:33 < rusty> Yeah.  So technically odd/even rule is redundant in some contents.  Like in our p2p messages (you should never send me an unknown even without feature negotiation!).
13:33 <+roasbeef> i think another one is: unified format, or diff for onion vs wire msgs 
13:34 < rusty> But in my experience it turns out to give sane errors as protocol gets older and dealing with ancient peers.
13:34 < t-bast> I think we can have a unified one, there's nothing requiring a different one for onion if we get rid of sentinel
13:34 < bitconner> so idt the debate is best framed as either or, rather i think the goal was to determine where 603 and 607 should inserect, and what differentiates them
13:34 < rusty> (like, ones that fall out of your test matrix because we assume everyone supports FOO now)
13:34 < rusty> bitconner: yeah, topic was kind of a joke, sorry.
13:35 < rusty> t-bast: agree on unification.
13:35 < bitconner> rusty, i figured, just clarifiying :)
13:35 < rusty> bitconner: they're basically identical, TBH, with trivial differences.
13:35 < t-bast> concerning even/odd, I think that in a perfect world, only the top-level message type should need it and TLV shouldn't (every unknown TLV should be considered optional). However in the real world, even/odd could be a simple rule that helps things go more smoothly.
13:35 -!- sfhi [~sfhi@178.255.154.107] has joined #lightning-dev
13:36 < rusty> Yeah, and it turns out to be easy to implement in the parser, at least for us.
13:36 < rusty> (We treat unknown even TLVs like any other malformation)
13:37 -!- AbuseOfNotation [~AbuseOfNo@217.151.98.168] has quit [Ping timeout: 258 seconds]
13:37 < t-bast> I agree with rusty that the risk is an explosion of feature bits that become very hard to properly configure and maintain...but I can't be 100% sure that we'll avoid it even with the even/odd rule
13:38 < rusty> t-bast: sure, but as you say, it's simple.
13:38 < bitconner> keep in mind, that feature bits are only required if we need to negotiate whether a field should be required
13:38 < bitconner> otherwise, they are implicitly optional
13:38 < rusty> Re: type.  I'm happy with 1 byte type, because we can always define inner type later if we start running out.  OTOH cdecker had an idea we could use types 32k+ for experimental use.
13:39 < rusty> bitconner: agreed.  But the odd/even rule makes people think harder about it, whether it can be ignored.
13:39 < t-bast> pragmatically, it sounds like keeping the even/odd rule means staying on the safe side of things
13:39 <+roasbeef> what does it protect against though? 
13:39 <+roasbeef> historically, it's caused a good bit of confusion for the wire messages 
13:39 < cdecker> Yes, I'd like to reserve types with a short representation (<256) for common use-cases that are spec'd
13:39 <+roasbeef> we've had to modify the wording a few times to make it more clear
13:40 <+roasbeef> doesn't it also cut into the existing tlv namespace? 
13:40 < rusty> roasbeef: really, I don't recall any modification to the odd/even wording?  It's been one thing which has always worked?
13:40 < bitconner> gossip messages, e.g., cannot have required fields
13:41 < rusty> bitconner: of course they can!  You just need to tell me you understand them first, before I relay it to you.
13:41 <+roasbeef> a while back there was confusion if even was the bit position, or the value iirc
13:41 <+roasbeef> https://github.com/lightningnetwork/lightning-rfc/pull/102
13:42 < rusty> roasbeef: oh yeah :) That's true.
13:42 < bitconner> rusty: and partition the gossip network?
13:42 < rusty> bitconner: schnorr gossip will do this, for example, yes.
13:42 < t-bast> the only downside to even/odd is that it constrains a bit more the types we can use (if we don't have the same amount of required vs optional types, we're wasting some bits in the T part of TLV) - is there any other downside?
13:43 < t-bast> if that's the only downside it's more about estimating if we'll need more optional or more required types
13:43 < rusty> "127 types should be enough for anyone!"
13:43 < t-bast> X)
13:43 < bitconner> rusty: we've discussed ways of introducing schnorr gossip that won't partition the network
13:44 < rusty> bitconner: yeah, by replicating.  But at some point, some client will stop sending out old-style gossip.  That's OK, right?  But this is exactly where we'd use an even TLV, too.
13:44 < bitconner> plus partioning the network over changing the signature algo makes much more sense rather than a single signed field
13:45 < rusty> bitconner: the cases are analogous.  I'm not saying we'll hand out even gossip TLV fields easily, but I'm saying I can think of cases where we'll want to.
13:46 < bitconner> rusty: tbh i'd rather just make a new message type at that point
13:46 < bitconner> otherwise the message will still have a blank 64-byte region anyway
13:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
13:47 < rusty> Sure, and maybe we never decide to use an even field, but I think it's worth having in case we do want a breaking change.
13:47 < rusty> ( I *would* use them for breaking changes that should never escape the lab, I guess? )
13:48 < rusty> Anyway, 1 byte type is enough, or do we go full varint?
13:49 < rusty> bitconner: I think you were tending to 1-byte, I have a vague preference for varint.  Anyone else have an opinion?
13:49 <+roasbeef> for type or length? 
13:49 < rusty> roasbeef: type.
13:49 < t-bast> I still prefer the varint, it's more flexible and still costs only 1 byte in most cases
13:49 < bitconner> so if we go the varint type, there is the edge case i discussed on the PR that would need to be addressed
13:49 < t-bast> it's cleaner than having to nest another type imo, but I'm not strongly against it
13:49 <+roasbeef> 1 byte pref here, we can always use a designated type for extensions or nested fields 
13:49 < rusty> bitconner: edge case?  Re-reading now....
13:50 < cdecker> Definitel varint for type for me
13:50 < cdecker> Composite types across a number of fields is hell to maintain
13:50 < bitconner> since there's no sentinel, the stream should be allowed to producing an EOF while reading type
13:50 < bitconner> for 1-byte type, this just means 0 bytes were read
13:50 < bitconner> for varint, it may not be the case. we have read the flag 0xfe byte, and then got an EOF
13:51 < t-bast> then it's an error, isn't it?
13:51 < bitconner> q is whether that should be silenced or permitted, and whether that byte should be included in the "strea,"
13:51 < bitconner> t-bast: yes, but it's an EOF, and currently with 1-byte we silence the EOF under the assumption that nothing was actually read
13:51 < rusty> bitconner: meh.  If you ran out of bytes before you started pulling the varint, you're at the end.  If you start pulling and run out of bytes, it's malformed.
13:52 < t-bast> I agree with rusty on that
13:52 < bitconner> rusty: but it's the same error that's produced when no bytes are read, which should be valid
13:52 < cdecker> I still don't get why everybody wants "TLV streams", a single TLV that just has all the key-value pairs ought to be enough, or what am I missing?
13:52 < bitconner> (i ended up having to change the errors returned from default CompactSize to avoid this)
13:52 < cdecker> And if we say that we have X bytes, but then truncate the message at <X bytes that's an error and the bloody message ought to b discarded
13:52 < rusty> bitconner: this is literally a "while size > 0: { type = read_varint(); len = read_varint(); val = read_more(len); }"
13:54 -!- booyah [~bb@193.25.1.157] has joined #lightning-dev
13:54 <+roasbeef> cdecker: i don't think "stream" here means anything other than a blob of tlv values, where you may not know the total size ahead of time from teh pov of the parser 
13:54 < rusty> Trying to pull the type and failing is a layering violation.  You can get away with that if it's 0 or 1 byte though.
13:54 < rusty> roasbeef: you will always know total size, now we fixed the onion.
13:55 < cdecker> roasbeef: gotcha, I misremembered it as being multiple TLVs one after the other
13:55 < cdecker> (and we do know the length of the TLV stream we are reading in all cases now with the variable frames)
13:55 < bitconner> rusty: yes, if nothing else the language will need to be changed in the current proposal
13:55  * cdecker is slow with typing today :-)
13:56 < t-bast> hum no we don't always know the whole size of the stream, that's kind of the goal because we want to be able to add new optional tlv types to the stream without having to go back to the spec of a specific message type (for non-onion messages)
13:57 < bitconner> the effects are somewhat impl specific, so just pointing out that it may require modifying CompactSize depending on your impl...
13:57 < cdecker> t-bast: we always know the length of the fields in the TLV, but the message framing also means we know the length of the TLV overall
13:57 < rusty> bitconner: but don't mistake me arguing coding technicalities from actually caring too much about type encoding though!
13:58 < rusty> cdecker: I like bitconner's "tlv stream" phrasing here.
13:58 < cdecker> t-bast: every message that may include a TLV now is prefixed with a size
13:58 < t-bast> cdecker: yes but for non-onion that's not the case, the message framing would like to be free of not specifying its length right?
13:58 < t-bast> cdecker: oh really? I hadn't seen that in the proposal, ok
13:58 < cdecker> Well for existnig messages we'd just define anything appended to the end as being the TLV
13:58 < cdecker> (also prefixed by a size)
13:58 < bitconner> rusty: seems we are headed towards varint?? :)
13:59 < bitconner> t-bast: all wire messages have a known length?
13:59 < t-bast> but don't we want to enable the following scenario? I define new gossip message `my_gossip` and specify that it contains a TLV stream of unknown size
13:59 < rusty> bitconner: I think so, but it's a bit of a line ball IMHO.
14:00 < bitconner> we have to serialize it first, write the message's size in the header, then send the message
14:00 < bitconner> rusty: yeah, i'm partial to 1-byte type, but see the use cases for extensions
14:00 < rusty> t-bast: how do you send a message of unknown size?  How would I know you've finished sending it? :)
14:01 < t-bast> that's true, I wanted to say "I'd close the connection so EOF" but we use long-lived single connections :)
14:01 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
14:01 < t-bast> got it then
14:01 < bitconner> fwiw i did some quick maths and found that nesting/concatenating tlv streams actually performs better than using a varint in the vast majority of cases
14:02 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 256 seconds]
14:02 <+roasbeef> t-bast: it's bounded rather than unknown 
14:02 < cdecker> How so? Presumably we'll use the short single-byte representations for type and length for the really common things
14:02 < t-bast> roasbeef: got it, makes sense now
14:03 < cdecker> And have experiments run on multi-byte types that are not as rare
14:03 < bitconner> cdecker, they only differ when needing to encode types that would otherwise require a varint ;)
14:03 < cdecker> Right, but in those cases dragging context around to interpret the type seems like a worse tradeoff tbh
14:04 < rusty> bitconner: you mean allocating type=255 to mean "subtype is first two bytes inside the TLV"?  That seems to be equivalent to a varint type, but loses the odd/even rule.
14:05 < bitconner> idts, i mean type=255 is tlv_stream, also with one byte types. nesting one layer gives you values in the range 0-254*2
14:06 < bitconner> for every item in the nested tlv, we only need 1 byte to signal it's type instead of 3
14:06 < rusty> bitconner: yeah, but if we've hit 255 already, we'll def want two-byte inner types.
14:06 < cdecker> Yeah, but that results in weird groupings into sub-tlvs that have the same prefix...
14:06 < cdecker> Composite keys are not nice, just trust me
14:06 < rusty> OK, this has dragged on :(  We still have to cover what varint encoding we want to use, and canonicalization rules.
14:07 < rusty> bitconner: it's basically boutique vs CompactInt.  I don't think there's enough benefit to justify not reusing CompactInt.
14:07 < bitconner> rusty: agree. varint encoding?
14:08 < t-bast> sgtm
14:08 < rusty> bitconner: you suggested a boutique encoding (255 == two extra bytes), vs the existing bitcoin one.
14:08 < bitconner> yeah, mainly to avoid handling 64-bit types if we went the route of varint type
14:09 < bitconner> also bounds the decoded length to the max msg size
14:09 < rusty> We currently have a 64k msg limit, so bitcoin one is overkill of course.  But I think existing standards win.
14:09  * cdecker votes against reinventing the wheel
14:09 <+roasbeef> bitcoin one is max 8 bytes? 
14:09 < rusty> roasbeef: 9 total, yeah.
14:09 <+roasbeef> yeah seems like more than we need 
14:09 < bitconner> 9 bytes on the wire, but max 8-byte value
14:09 < bitconner> cdecker, it's more like deleting parts of an existing wheel :)
14:10 <+roasbeef> would that mean i can create two distinct encodings of the same value? 
14:10 <+roasbeef> length wise 
14:10 < bitconner> roasbeef, they should be minimally encoded
14:10 <+roasbeef> gotcha makes sense
14:10 < rusty> roasbeef: yeah, you need to insist on minimal encodings.  There are encodings which don't have this problem but they're ugly in even worse ways.
14:11 < cdecker> bitconner: have you tried removing part of a wheel before? It hurts your back :-)
14:11 < rusty> I think it's overkill but we can just reuse it and move on.  For us, it's No New COde, which is nice.
14:12 < bitconner> if we only use varint for length, compactsize i think is fine. if we also use it for types, i'd prefer the stripped down variant
14:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
14:12 < bitconner> or can we at least say clamp all types to be 16-bits?
14:12 < rusty> bitconner: OK, shall we compromise on 1 byte type, and CompactSize for length? 
14:12 < rusty> bitconner: hmm, autoreject 254/255-starting lengths?
14:13 < bitconner> yeh
14:13 < rusty> s/lengths/varints/
14:13 < bitconner> which is why i ended up just making the boutique version :P
14:13 < cdecker> That doesn't mean we use nested TLVs though, right?
14:13 < cdecker> (to expand the type space again)
14:13 < bitconner> no we have varint, prob no nesting
14:14 < rusty> bitconner: hmm, that destroys the experimental-types-start-at-64k idea though.  In effect, lengths of that amount will be autorejected anyway by a parser.
14:15 < bitconner> also destroys my plan to make a type for every atom in the universe :(
14:15 < rusty> bitconner: I actually lol'ed.
14:15 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
14:15 < bitconner> lolol
14:16 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
14:16 < rusty> OK, I think this unf. needs more bikeshedding.  Can bitconner and I get together sometime this week and try to come to agreement on this and canonicalization?  Are others happy for us to come back with a unified proposal?
14:16 < bitconner> my thoughts are that we should do a varint type, because either way it will end up less complex than nesting
14:16 < t-bast> rusty: sgtm
14:17 < bitconner> rusty: sounds good!
14:17 < cdecker> +1
14:17 < rusty> We're *so close* that it seems like we just have to thresh through the possibilities.  Thanks
14:17 < cdecker> And +1 on varint types
14:17 < rusty> #action bitconnor and rusty to flip coins until TLV proposals unified.
14:17 <+roasbeef> vary, the length shall
14:17 < rusty> OK, unf. we're out of time, but good meeting!
14:18 < rusty> #endmeeting
14:18 < lightningbot> Meeting ended Mon May 27 21:18:01 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:18 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-05-27-20.05.html
14:18 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-05-27-20.05.txt
14:18 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-05-27-20.05.log.html
14:18 < t-bast> thanks guys for this progress!
14:18 < jb55> that was interesting
14:18 <+roasbeef> who here is gonna be at breaking bitcoin? or the dev meeting a few days beforehand? 
14:18 < t-bast> one small note: could we add #596 to the next meeting discussions? It's small and should be easy to discuss
14:18 < t-bast> roasbeef: I'll be there with sstone from acinq
14:18 < rusty> Yeah!  As always, impressed with everyone's ability to think on the spot about the devilish details...
14:19 <+roasbeef> t-bast: cool! conner and I will be there, will be nice to meeting in person 
14:19 < rusty> t-bast: tag it for meeting?
14:19 <+roasbeef> also joost on our side as well 
14:19 < t-bast> rusty: I think I can't, I don't have rights on the repo...
14:19 < t-bast> roasbeef: great, it will be nice to meet irl!
14:19 -!- scoop [~scoop@2601:240:d700:b3a:e981:819d:327f:29e9] has joined #lightning-dev
14:20 < bitconner> t-bast, i will follow up on my beer offer :)
14:20 < t-bast> bitconner: for sure ;)
14:20 < rusty> t-bast: invited...
14:20 < t-bast> rusty: thx!
14:21 <+roasbeef> cdecker: making a guest appearance? europe is just all like the same thing or something like that right? 
14:22 < rusty> bitconner: I'll ping you and we can discuss, right now I have to get kids up...
14:22 < t-bast> thanks again guys, good night/afternoon/morning to everyone
14:23 < bitconner> rusty: perfect, sounds good!
14:24 -!- scoop [~scoop@2601:240:d700:b3a:e981:819d:327f:29e9] has quit [Ping timeout: 252 seconds]
14:25 -!- t-bast [~t-bast@2a01:e34:ec2c:260:d09b:758b:80a4:3464] has quit [Quit: Leaving]
14:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
14:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
14:33 -!- sstone [~sstone___@185.186.24.109.rev.sfr.net] has quit [Remote host closed the connection]
14:34 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
14:36 -!- sfhi [~sfhi@178.255.154.107] has quit [Quit: Leaving]
14:57 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 256 seconds]
15:09 -!- booyah_ [~bb@193.25.1.157] has joined #lightning-dev
15:09 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]
15:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
15:35 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Quit: gone]
15:36 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
16:06 -!- scoop [~scoop@2601:240:d700:b3a:e981:819d:327f:29e9] has joined #lightning-dev
16:44 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has quit [Ping timeout: 258 seconds]
16:44 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has joined #lightning-dev
17:11 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
17:12 -!- scoop [~scoop@2601:240:d700:b3a:e981:819d:327f:29e9] has quit [Remote host closed the connection]
17:39 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 245 seconds]
17:40 -!- riclas [~riclas@148.63.37.111] has quit [Ping timeout: 248 seconds]
17:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
18:13 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
18:17 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 272 seconds]
18:23 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
19:06 -!- Guest1469 [sid19838@gateway/web/irccloud.com/x-khjxhymesieoomuc] has left #lightning-dev []
19:06 -!- oneark [uid254801@gateway/web/irccloud.com/x-zwruwojrxjrpwvgd] has joined #lightning-dev
19:07 -!- takinbo [sid19838@gateway/web/irccloud.com/x-khjxhymesieoomuc] has joined #lightning-dev
20:03 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has joined #lightning-dev
20:11 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
20:24 -!- renlord [~renlord@gateway/tor-sasl/renlord] has quit [Remote host closed the connection]
20:25 -!- renlord [~renlord@gateway/tor-sasl/renlord] has joined #lightning-dev
20:34 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has quit [Remote host closed the connection]
20:54 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has joined #lightning-dev
21:08 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 258 seconds]
21:12 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has quit [Remote host closed the connection]
21:14 -!- scoop [~scoop@2601:240:d700:b3a:8cd9:4226:28ee:3dd0] has joined #lightning-dev
21:19 -!- scoop [~scoop@2601:240:d700:b3a:8cd9:4226:28ee:3dd0] has quit [Ping timeout: 250 seconds]
21:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
22:17 -!- ulrichard [~richi@dzcpe6300borminfo01-e0.static-hfc.datazug.ch] has joined #lightning-dev
22:19 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:19 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
22:19 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
22:28 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
23:05 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has joined #lightning-dev
23:16 -!- ccdle12 [~ccdle12@pcd537031.netvigator.com] has quit [Remote host closed the connection]
23:32 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 272 seconds]
23:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
23:58 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
23:59 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Client Quit]
--- Log closed Tue May 28 00:00:25 2019