--- Log opened Mon Apr 29 00:00:58 2019
00:05 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
00:37 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
01:21 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
01:21 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 246 seconds]
01:33 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
01:35 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
01:42 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
01:47 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 245 seconds]
01:51 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Quit: Leaving]
01:51 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev
02:10 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
02:38 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
02:55 -!- ccdle12 [~ccdle12@p116127-ipngn200301takamatu.kagawa.ocn.ne.jp] has quit [Remote host closed the connection]
03:14 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 276 seconds]
03:16 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
03:26 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
03:28 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
03:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
03:43 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev
03:55 -!- ccdle12 [~ccdle12@p116127-ipngn200301takamatu.kagawa.ocn.ne.jp] has joined #lightning-dev
04:02 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
04:13 -!- unixb0y [~unixb0y@p2E555F1A.dip0.t-ipconnect.de] has quit [Disconnected by services]
04:17 -!- hi_online [~Pep@92.177.54.77] has joined #lightning-dev
04:19 -!- hi_online [~Pep@92.177.54.77] has left #lightning-dev []
04:22 -!- unixb0y_ [~unixb0y@p2E555F1A.dip0.t-ipconnect.de] has joined #lightning-dev
04:29 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 268 seconds]
04:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
05:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
05:17 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
05:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 276 seconds]
05:33 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
05:34 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Quit: Leaving]
05:37 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
05:41 -!- ccdle12 [~ccdle12@p116127-ipngn200301takamatu.kagawa.ocn.ne.jp] has quit [Remote host closed the connection]
05:43 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev
05:54 -!- ccdle12 [~ccdle12@p116127-ipngn200301takamatu.kagawa.ocn.ne.jp] has joined #lightning-dev
06:36 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 258 seconds]
06:38 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #lightning-dev
06:44 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
06:45 -!- nirved_ [~nirved@2a02:8071:b58a:3c00:70ec:4a1f:daf3:33d2] has joined #lightning-dev
06:49 -!- nirved [~nirved@2a02:8071:b58a:3c00:3ca6:9fb9:2e23:4e12] has quit [Ping timeout: 258 seconds]
06:50 -!- Tralfaz [~none@178.128.106.205] has joined #lightning-dev
06:51 -!- mauz555 [~mauz555@80.215.85.196] has joined #lightning-dev
06:52 -!- davterra [~none@103.254.153.99] has quit [Ping timeout: 244 seconds]
06:53 -!- buZz [~buzz@unaffiliated/buzz] has quit [Ping timeout: 246 seconds]
06:59 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
07:04 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
07:04 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
07:08 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 245 seconds]
07:10 -!- buZz [~buzz@joint.ro.lt] has joined #lightning-dev
07:10 -!- buZz is now known as Guest80742
07:11 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Quit: Leaving]
07:11 -!- Guest80742 [~buzz@joint.ro.lt] has quit [Changing host]
07:11 -!- Guest80742 [~buzz@unaffiliated/buzz] has joined #lightning-dev
07:13 -!- Guest80742 is now known as buZz
07:13 -!- michaelfolkson [~textual@146.185.56.214] has joined #lightning-dev
07:21 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
07:30 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
07:31 -!- michaelfolkson [~textual@146.185.56.214] has quit [Quit: Sleep mode]
07:31 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
07:32 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
07:32 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
07:32 -!- mauz555 [~mauz555@80.215.85.196] has quit []
07:33 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
07:33 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 246 seconds]
07:35 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 250 seconds]
07:51 -!- renlord [~renlord@gateway/tor-sasl/renlord] has quit [Ping timeout: 256 seconds]
07:53 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #lightning-dev
07:56 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
07:59 -!- shesek [~shesek@5.102.229.163] has joined #lightning-dev
07:59 -!- shesek [~shesek@5.102.229.163] has quit [Changing host]
07:59 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
08:07 -!- renlord [~renlord@gateway/tor-sasl/renlord] has joined #lightning-dev
08:14 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
08:16 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 250 seconds]
08:17 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
08:18 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
08:20 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 245 seconds]
08:23 -!- ccdle12 [~ccdle12@p116127-ipngn200301takamatu.kagawa.ocn.ne.jp] has quit [Remote host closed the connection]
08:44 -!- michaelfolkson [~textual@199.203.214.3] has joined #lightning-dev
08:44 -!- michaelfolkson [~textual@199.203.214.3] has quit [Client Quit]
08:44 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
08:44 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
08:46 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
08:49 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 245 seconds]
08:49 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 245 seconds]
08:49 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
08:51 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
08:54 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer]
08:54 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 246 seconds]
08:54 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev
08:56 -!- __gotcha1 is now known as __gotcha
08:59 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
09:01 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Remote host closed the connection]
09:02 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
09:12 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
09:15 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 255 seconds]
09:17 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
09:19 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 245 seconds]
09:26 -!- t-bast-4200 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Quit: Leaving]
09:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
09:36 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
10:00 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Read error: Connection reset by peer]
10:01 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev
10:15 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
10:16 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
10:18 -!- nirved [~nirved@HSI-KBW-095-208-248-036.hsi5.kabel-badenwuerttemberg.de] has joined #lightning-dev
10:20 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds]
10:20 -!- nirved_ [~nirved@2a02:8071:b58a:3c00:70ec:4a1f:daf3:33d2] has quit [Ping timeout: 250 seconds]
10:28 -!- achow101 [~achow101@unaffiliated/achow101] has joined #lightning-dev
10:32 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
10:39 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 258 seconds]
10:40 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds]
10:45 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
10:46 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
10:50 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds]
10:53 -!- Tralfaz is now known as davterra
10:53 -!- YSqTU2XbB [~smuxi@134.28.68.51.rdns.lunanode.com] has joined #lightning-dev
10:53 -!- YSqTU2XbB is now known as araspitzu
10:59 -!- wka [592262c3@gateway/web/freenode/ip.89.34.98.195] has joined #lightning-dev
11:00 -!- wka [592262c3@gateway/web/freenode/ip.89.34.98.195] has quit [Client Quit]
11:01 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
11:04 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
11:06 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
11:07 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
11:09 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
11:09 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
11:45 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
11:45 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
11:49 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
11:49 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
11:53 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 250 seconds]
12:09 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds]
12:12 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
12:20 -!- araspitzu [~smuxi@134.28.68.51.rdns.lunanode.com] has quit [Read error: Connection reset by peer]
12:29 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has joined #lightning-dev
12:34 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has quit [Ping timeout: 256 seconds]
12:37 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
12:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 255 seconds]
12:47 -!- t-bast [~t-bast@78.194.192.38] has joined #lightning-dev
12:53 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
12:53 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
13:00 < cdecker> Heya, meeting here soon?
13:01 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has joined #lightning-dev
13:01 < t-bast> hi guys
13:01 < cdecker> Hi t-bast, sorry just saw your message now
13:01 < t-bast> no problem, we'll have time to discuss multi-frame in this meeting ;)
13:02 < bitconner> hey cdecker!
13:02 < m-schmoock> hey there
13:02 < niftynei> hey m-schmoock!
13:02 < cdecker> Hi all
13:02 < m-schmoock> :D
13:02 < cdecker> t-bast: you're from ACINQ right?
13:03 < t-bast> yes, just started last week
13:03 < niftynei> rusty's out today, cdecker are you going to chair the mtg?
13:03 < niftynei> welcome t-bast 
13:03 < t-bast> thx ;)
13:04 < cdecker> Sure, unless someone else would like to do the honors :-)
13:05 < cdecker> Ok, shall we get going?
13:05 < t-bast> ready
13:05 < cdecker> #startmeeting
13:05 < lightningbot> Meeting started Mon Apr 29 20:05:24 2019 UTC.  The chair is cdecker. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:05 < niftynei> :)
13:05 < t-bast> #info
13:05 < cdecker> The tag for today's meeting is here: https://github.com/lightningnetwork/lightning-rfc/issues?utf8=%E2%9C%93&q=label%3A%22Meeting+Discussion%22
13:06 < cdecker> Most of the things were discussed last time
13:06 < cdecker> t-bast: is sstone joining today?
13:07 < t-bast> sstone is out for the week
13:07 < t-bast> but I think andrea can speak for his progress on the range queries
13:07 < cdecker> Excellent, that was what I was hoping to get
13:07 < cdecker> #topic BOLT7: extend channel range queries with optional fields #557
13:08 < cdecker> Last time we deferred to wait for a TLVified version of the PR
13:08 < cdecker> I guess that is still pending?
13:08 -!- laptop500 [~laptop@host81-155-233-70.range81-155.btcentralplus.com] has joined #lightning-dev
13:08 < bitconner> the pr has been updated w/ tlv fields
13:08 < cdecker> Oh has it? I must've missed that
13:09 < bitconner> yeah it assumes tlv in rusty's current proposal, so might need some slight modification if that changes
13:09 < t-bast> there were some changes pushed last friday - I think sstone was now waiting for comments
13:10 < bitconner> got a chance to review last night, latest form of the proposal looks solid
13:10 < cdecker> I'm sorry I missed that, and didn't give feedback yet
13:12 < cdecker> Maybe you could clarify the format of the TLV here for me quickly: in `query_channel_range_tlv` the format would be a single dict so to speak with two possible keys (1 for timestamps_tlv and 3 for checksums_tlv), right?
13:13 < cdecker> The values then would back to back serialized arrays of timestamps and checksums respectively, right?
13:13 < bitconner> cdecker, yes i think so. i've always imagined there would be a single "tlv blob" with up to 255 keys
13:13 < cdecker> Excellent, that clarifies that
13:14 < cdecker> Other than that it appears to be just a 1-to-1 translation from feature bits to TLV
13:14 < cdecker> SGTM
13:15 < cdecker> What is the general feeling, did we torture this proposal long enough?
13:15 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
13:15 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
13:16 < bitconner> im happy with this latest iteration, i think most of the discussion now is on finalizing the exact tlv spec
13:16 < cdecker> I'm a bit worried about assigning the TLV types, since it seems we are about to make the TLV types context specific again, but other than that it looks good
13:17 < cdecker> Then again we can solve that later
13:17 < bitconner> what do you mean by context specific? as in they could be different for each message?
13:18 < cdecker> Yeah, we had this ambiguity for the feature bits as well. When they appear in one message or another their meaning could change
13:18 < cdecker> That was the basic idea behind Rusty's #571 Feature bit unification PR
13:19 <+roasbeef> what's the ambiguity in the existing feature bits? 
13:19 <+roasbeef> from my pov the unification doesn't really clear anything up 
13:19 < niftynei> my understanding for tlv types is that there's one tlv per message. each tlv has its own set of message types
13:20 < cdecker> Well, the hope was that we could have a single lookup table num->type instead of having to have one per message type since the mapping may be different
13:20 < bitconner> niftynei, same here
13:20 < cdecker> Ok, if that's the general interpretation I'm happy to accept that as well 
13:20 < bitconner> imo
13:21 < bitconner> imo having a global namespace for keys/types would limit the effectiveness of the proposal
13:21 < niftynei> having a unified set significantly constrains the total number of sub-types that we can create for messages
13:21 < cdecker> In that case we must definitely amend the TLV PR from Rusty since that contains global TLV type specifications: https://github.com/lightningnetwork/lightning-rfc/pull/572/files#diff-9198bb316a3387cc67fd543b03339b35R651
13:22 < bitconner> was not aware, thanks
13:22 < cdecker> We just need to qualify them to be message specific mappings and then it works again
13:22 < cdecker> That's where my confusion comes from btw :-)
13:23 < bitconner> makes sense now :)
13:23 < bitconner> should we change the topic to tlv btw?
13:23 < cdecker> Funnily enough the TLV types in PR #557 seem to be chosen not to clash with the ones in the TLV PR
13:23 < cdecker> Ok, just one decision on PR #557 first? Defer or accept?
13:23 < niftynei> it seems like the tlv spec proposal should be updated to reflect that they're per tlv definition, not global
13:25 < cdecker> My vote would be to accept #557 and then switch to #572 (TLV) and amend that
13:25 < niftynei> (that's because even are required, odds are optional. the tlv-types in #572 are required whereas the #557 ones are intended to be optional)_
13:25 < bitconner> in favor of accepting #557, but it's kinda blocked by the tlb proposal
13:25 < bitconner> imo we shouldn't have the even/odd rule for wire tlv 
13:25 < cdecker> Oh, but we should
13:25 < bitconner> what's the rationale?
13:26 < cdecker> For #557 for example everything works even if you don't understand the TLV fields
13:26 < bitconner> the same is true without the even odd rule, all fields are optional
13:26 < cdecker> There are other proposals where understanding a TLV field is important
13:26 <+roasbeef> in either case we'd need it scope per message, otherwise there wouldn't be enough space or even the onion there 
13:27 < cdecker> Yep, agreed with roasbeef 
13:27 <+roasbeef> why do we need even/odd for tlv? 
13:27 < bitconner> if a field is mandatory, that should be signaled via a feature bit
13:27 < cdecker> It's just really useful to be able to say "it's ok for you to ignore this", and "you must understand this otherwise the world collapses"
13:28 < niftynei> right my initial understanding was that TLV fields are all optional by nature of their being in the TLV. rusty talked me out of it but i can't remember the rationale now
13:28 <+roasbeef> yeah...if you don't understand ok, anythign else can be up front negotiated with feature bits 
13:29 < bitconner> so far i think the only place even/odd adds value is in onion tlv, because we don't have feature bits
13:30 < bitconner> but that can just be an additional constraint on the onion keys/types, and not embedded in the base tlv format
13:31 < cdecker> Feature bits seems like an odd place to put message specific things though
13:31 < niftynei> right i think it depends on how you see the future of the TLV fieldset evolving. having a rule about even and odd allows us to expand the usage of TLVs to include mandatory fields
13:31 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
13:31 < niftynei> even if at the outset we're intending it for optional fields
13:31 < cdecker> We are splitting message capability negotiation over multiple fields
13:32 < cdecker> And not all TLVs are paired with a featurebitmap
13:32 < cdecker> There seems to be no harm in at least reserving even TLV types for now
13:32 < niftynei> right. i can imagine adding a featurebitmap to a TLV, as a required field, and the rest being optional.
13:32 < cdecker> Whoa, that's a featurebit / TLV inception :-)
13:33 < niftynei> too meta? lol
13:33 < cdecker> #topic Specify tlv format, initial MPP #572
13:33 < cdecker> Switching since we are now very much in #572 territory
13:33 < cdecker> :-)
13:33 <+roasbeef> why do we need to reserve them ahead of time if they're all message specific? 
13:33 < niftynei> oh good point. the type number is basically a featurebitmap mapping
13:34 < cdecker> Because even if they are message specific you want to tell some old version of yourself that it is dangerous to continue if you don't understand a certain field
13:35 <+roasbeef> "continue" is very context specific 
13:36 <+roasbeef> even then, most of the time one party can tell and just not include that field 
13:36 <+roasbeef> for example anythig in the onion may restrict the path you can actually take 
13:36 < cdecker> Well, then let's safe "you need to fail-safe if you don't understand the type I'm giving you"
13:36 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
13:37 < cdecker> s/safe/say/
13:37 < niftynei> that feels a bit like creating exploding honeypots of TLV's. it's hard to tell when incompatibilities are going to arise. the other way to deal with this would be creating a v2 of the message format and only communicate with peers that understand that message format. it's basically the same thing, no? 
13:37 < niftynei> 'that' here meaning making mandatory TLV fields
13:37 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
13:38 < cdecker> I'm just uncomfortable with giving someone instructions (in an onion for example) and he might just ignore the important instructions because he's too old to know what I'm telling him
13:38 <+roasbeef> niftynei: what does? 
13:38 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #lightning-dev
13:38 <+roasbeef> cdecker: if they ignore them, the your protocol likley won't work, or they can just cancel it bac 
13:38 < cdecker> Right, that's what I'm saying: they should cancel it back whenever they don't understand it
13:39 < cdecker> And they should know whether what I'm telling them is just additional information, as in the #557 case, or whether it is paramount for them to really understand things
13:40 < bitconner> these concerns seem to be specific to onion tlv iiuc?
13:41 <+roasbeef> in what case would one provide additional information, that doesn't shape the route at all? 
13:41 <+roasbeef> or provide info that they can pass off for not verifying 
13:41 < cdecker> Not really, let's say I want to tell my peer not to send me a gossip dump if it is > 10 MB, and the peer doesn't understand that, I will get flooded despite me trying to protect against that
13:42 < cdecker> There are likely cases of this kind of interaction in many other contexts as well
13:42 <+roasbeef> gotcha, i'm speaking more about in the onion here while i think you're speaking on the msg lvl 
13:42 < niftynei> ah nevermind. the onion use case is a bit different than the message level
13:42 <+roasbeef> but even then, can't that be detected up front with featur ebits? 
13:42 <+roasbeef> (don't send if more than x MB)
13:42 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 245 seconds]
13:43 < cdecker> Yeah, ok, but we're splitting things across multiple messages again
13:43 < cdecker> Anyway, seems we need to discuss this a bit further on the ML or the tracker
13:43 < bitconner> sgtm
13:44 < cdecker> #agreed The TPV types need to be message-specific, not global like in the current proposal, to maintain flexibility
13:45 < cdecker> #agreed Discussion of whether the even/odd rule should apply to TLV types as well is deferred to the ML/issue tracker
13:45 < cdecker> Does that sounds correct?
13:45 < bitconner> yep
13:45 < niftynei> thumbs-up
13:46 < cdecker> Shall we discuss #571? I think Rusty was going to split the PR in two anyway
13:48 <+roasbeef> still not clear to me waht the goal is or what it achieves 
13:49 <+roasbeef> action item last time was concrete examples and motivating use cases 
13:49 < cdecker> Just checked, Rusty will split the PR in two, hopefully making its goal a bit clearer (http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-04-15-20.06.html)
13:49 < cdecker> So I'd propose we jump straight to #593 instead
13:50 < cdecker> #topic bolt04: Multi-frame sphinx onion routing proposal #593
13:50 < cdecker> We had a concept ACK from last time, and t-bast mentioned he had a question about the proposal
13:51 < t-bast> yes I have one very small question
13:51 < t-bast> it's slightly unclear if we want to support the fact that the last payload can be multi-frame (because we mention that it needs to contain amt_to_forward and cltv)
13:51 < t-bast> I think we should support multi-frame last payload
13:52 < t-bast> just want to be sure
13:52 < cdecker> Personally my hope is that we can TLVify all onion payloads. That would mean we just assign TLV types to those 2 fields and wrap them in the TLV field
13:53 < t-bast> cool, in that case last payload can be multi-frame - I think it's more flexible to say that it could be multi-frame if we need it to be
13:53 < cdecker> In that case we'd treat the last payload just like any other
13:53 < cdecker> And it'd also be pretty much required for things like MPP and spontaneous payments, where we actually need the extra space
13:54 < t-bast> agreed then, I haven't seen anything strange implementing it in eclair, it's quite easy to integrate and should be flexible enough for routing updates
13:54 < cdecker> Yes, absolutely, we keep the old `hop_data` format for the case in which nodes are in the route (or indeed the final recipient) that don't know anything about TLV or multi-frame payloads
13:55 < cdecker> Awesome
13:55 < cdecker> @everybody: shall we wait with merging #593 until we also have an independent implementation in scala?
13:55 < t-bast> the implementation is ready :)
13:56 < t-bast> I sent the PR today and reference the #593
13:56 < cdecker> (because the C and Golang implementation were created by me, and I might have just repeated the same error) :-)
13:56 < cdecker> Oh, great
13:56 < t-bast> I think we need to add the test vectors though
13:56 < t-bast> how do you usually create them?
13:56 < cdecker> That PR is tiny :-)
13:56 < t-bast> oh yeah, scala is concise ;)
13:57 < cdecker> I wrote a cli tool for Go and C that just reads the JSON file and checks the output
13:57 < bitconner> reminder that we should have a separate change to commit the version number before actually adding a new onion version
13:57 < cdecker> Isn't that a breaking change?
13:57 < t-bast> that onion version is backwards-compatible with existing onions iiuc
13:57 < t-bast> so we don't need to bump to v1
13:58 < cdecker> Yep, #593 is perfectly backward compatible, no need for a version bump
13:58 <+roasbeef> in any case the intermediate nodes need to know about it
13:58 < bitconner> oh okay, was just looking thru the pr and it sets a baseVersion so it looked like it could be something other than 0
13:59 < cdecker> roasbeef: what do you mean? We are telling the hops the payload type and the number of frames to read, what more do we need to tell them?
13:59 < t-bast> if we hit a node that doesn't understand multi-frame, we're kinda screwed
13:59 < t-bast> is that what you meant roasbeef?
13:59 < bitconner> isn't that signalled via a global feature bit?
13:59 < t-bast> but the route should fail immediately (ideally)
14:00 < t-bast> ah ok, if that's the case it would be nice
14:00 < bitconner> the i-support-multi-frame bit
14:00 < cdecker> Oh, yeah, that's needed of course
14:00 < cdecker> You're right
14:00 < bitconner> looks like it might be missing from the pr?
14:00 < cdecker> That'd be a global feature bit in the node_announcement 
14:00 < t-bast> it is definitely missing, good catch
14:01 < cdecker> Yep, it's missing
14:01 < cdecker> Will amend
14:01 < cdecker> #action cdecker to assign a node_announcement feature bit to signal multi-frame support in the gossip
14:01 <+roasbeef> yeah so if feature bit, we can commit to the version 
14:02 < t-bast> sounds good
14:02 < bitconner> also noting that we call the payload format version 1, when it's actually version 0
14:02 < cdecker> No, there is no way for an onion to switch version along a path
14:02 < cdecker> And nodes will reject a version that is not 0
14:02 < bitconner> cdecker, why not? 
14:02 < bitconner> isn't that only specific to the node that does the unwrapping?
14:03 < cdecker> Well, we need to tell the node that the version is committed in the HMAC, and we can't use a version bump to tell them because we can't switch version along a path
14:03 < bitconner> ah of course
14:04 -!- molz [~molly@unaffiliated/molly] has quit [Remote host closed the connection]
14:04 -!- molz [~molly@unaffiliated/molly] has joined #lightning-dev
14:05 <+roasbeef> cdecker: won't them signalling the feature bit handle that? 
14:05 < bitconner> we'd still have to bump the version to signal tho
14:05 < cdecker> Nope, if I signal I expect the version to be committed, and the sender doesn't understand then what?
14:05 < bitconner> there's no way to know the node constructing the onion ever got your node announcement anyway
14:05 <+roasbeef> ofc it can switch, but ppl will just reject it today, but if we're using it to gate oteh things then someone can switch it out and cause a specific type of failure 
14:06 < cdecker> (signal using a feature bit that is)
14:06 <+roasbeef> cdecker: you can tell based on the version if you should check the mac or not 
14:06 <+roasbeef> yes so bump+signal+mac 
14:07 < cdecker> roasbeef: go and check how you can receive a 0-version onion, and make sure the next hop gets 1-version onion despite you not understanding v1
14:07 < cdecker> We can do a 2-step deployment: TLV first, assign a TLV type "next-onion-version" and then use that to specify what version the next onion should have
14:08 < bitconner> we can't see what the next hops version is tho?
14:08 <+roasbeef> confused as to how that 2 step addresses anything 
14:09 < cdecker> Well that's what we're telling the processing node in the payload: "instead of the default version 0, you should serialize it with version 1"
14:09 <+roasbeef> or that example 
14:09 <+roasbeef> why wouldn't they just serailize w/ the version they get in? 
14:09 < bitconner> the bigger issue it seems is that the onion has a single version for the entire path, and not a per-hop version
14:10 < cdecker> roasbeef: that's exactly the issue, by default they will always serialize with the same version. And since already deployed nodes will reject any version that they don't know, we can't do a partial upgrade on a route
14:10 < cdecker> bitconner: exactly
14:11 < t-bast> you mean the version that's in the header (outside of the hops_data) right?
14:11 < cdecker> That and the fact that nodes reject versions they don't know means we always have to chose the lowest version supported by hops in the route
14:11 < cdecker> t-bast: yep, the first byte of the serialized onion packet
14:11 < t-bast> that seems to indicate that the multi-frame should stay in version 0 because in that case it works fine
14:11 < bitconner> could move the version into the hops data :)
14:12 < t-bast> if we keep version 0 to add the multi-frame support, everything should work fine
14:12 < cdecker> payload, yes, but that means we can't change the HMAC processing since we interpret the payload after verifyin the HMAC
14:12 < bitconner> o/w we will forever be stuck with the lowest common denominator
14:12 < t-bast> indeed
14:13 < cdecker> Yep, that's a bit of an oversight we had
14:13 < cdecker> But with the version switching in the TLV it could work
14:14 < cdecker> Anyway, let's not mix the two things, #593 is independent from any version switching (I purposefully made it that way)
14:14 <+roasbeef> ah yeah i'm not talking about a partial upgrade, a full one, so no mixed route 
14:14 < t-bast> agreed with cdecker
14:14 < cdecker> But you are right that we need to find a way to unlock the version numbering, otherwise we're stuck forever at v0
14:14 < cdecker> And can't change the processing of onions at all
14:15 <+roasbeef> we already are changing the processing of them 
14:15 < t-bast> yes but the current changes work as long as we stay on version 0
14:15 < cdecker> We are, but in a backwards compatible way
14:15 < t-bast> and that the sender knows who supports multi-frame in the path and who doesn't
14:15 < bitconner> cdecker, yes and it seems it will be rather large change and necessitate an overhaul of the onion packet anyway. best to do that in one fell swoop indepdently of these changs
14:16 < cdecker> Something that would require a version bump for example would be a change in the number of hops, HMAC computation, random bytes generation, that sort of thing
14:16 < cdecker> bitconner: agreed
14:16 < t-bast> yes, version 1 of the onion can fix that, and multi-frame can stay in version 0 :)
14:17 < bitconner> t-bast, well in theory we'd want multi-frame in version 1 as well
14:17 < t-bast> yes, what I meant is that we can do the multi-frame change while staying in version 0
14:17 < cdecker> Hehe
14:17 < t-bast> and when we move to version 1, we can fix versioning and keep multi-frame :)
14:17 < bitconner> i don't think there's any dispute there :)
14:18 < cdecker> Oh, we can do so much more trickery if we ever decide to revamp the entire onion construction xD
14:18 < t-bast> haha
14:18 < bitconner> okay, circling back. seems we just need a global feature bit?
14:18 < cdecker> Anyhow, seems we have my action item
14:18 < t-bast> bitconner: I think that's the only missing part in the spec indeed
14:18 < cdecker> Yep, will assign one asap and then we can merge next time.
14:18 < bitconner> sounds good
14:18 < t-bast> just last small point before we merge the PR
14:18 < t-bast> concerning the test vectors, I only saw the previous test vectors (single-frame) in cdecker's PR. I think we should add test vectors for multi-frame, do you want me to send a proposal?
14:19 < cdecker> Since the TLV PR is also stuck in limbo there is no real downside in deferring this one
14:19 < bitconner> sorry i didn't get a chance to look over the changes in depth since last meeting, but will do so today
14:19 -!- shesek [~shesek@5.22.134.182] has joined #lightning-dev
14:19 -!- shesek [~shesek@5.22.134.182] has quit [Changing host]
14:19 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
14:19 < cdecker> Didn't I add multiframes as well?
14:19 < t-bast> I didn't see them, no, let me double-check
14:19 < cdecker> Apparently not, need to add them as well
14:19 < cdecker> #action cdecker to add multi-frame test-vector
14:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
14:19 < cdecker> Excellent, let's proceed
14:20 < cdecker> #topic BOLT2: rephrase cltv_expiry_delta text about accepting HTLCs #595
14:20 < cdecker> I just saw that I was supposed to merge this 
14:20 < cdecker> Mea culpa
14:20 < cdecker> I'll just do so now
14:20 < bitconner> lgtm
14:20 < bitconner> we haz progress!
14:20 < cdecker> #action cdecker merged #595, based on decision from last meeting
14:21 < cdecker> OMG we better stop now
14:21 < cdecker> Otherwise what will we discuss next time?
14:21 < cdecker> #topic BOLT 5: Homogenize Local/Remote Commitment #598
14:22 < cdecker> Looks like it could fall under the spelling rule
14:22 < bitconner> looks straightforward
14:23 < cdecker> Ok, lgtm
14:23 < cdecker> #agreed cdecker to merge #598
14:23 < cdecker> Any objections?
14:23 < t-bast> lgtm
14:24 < bitconner> approved
14:24 < cdecker> Onwards, the last one for today
14:24 < cdecker> #topic BOLT 3: Explicit description of implicitly enforced timelocks on HTLC outputs #601
14:24 < cdecker> Adds more prose around the time-lock for HTLC outputs
14:25 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has quit [Ping timeout: 256 seconds]
14:25 < cdecker> Feels a bit hand-wavy to me
14:25 < cdecker> It mentions implicitly enforcing the timeout, but not how the timeout is specified
14:25 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has joined #lightning-dev
14:26 < bitconner> agree could probably use a little massaging
14:27 < cdecker> Should likely mention the difference in locktime between the two HTLC-spending transactions
14:27 < cdecker> Ok, will make a note of it
14:27 < cdecker> #action cdecker to add a bit more detail about how the timelock is committed to in the signature
14:27 < cdecker> Excellent, that concludes the official part
14:28 < cdecker> #topic Chit chat and gossip :-)
14:28 < cdecker> Anything we should discuss that was not on the agenda?
14:28 < bitconner> woo! thanks for chairing cdecker
14:28 < niftynei> :D
14:29 < cdecker> Thanks everybody for being excellent chairees :-)
14:29 < t-bast> thanks cdecker!
14:30 < m-schmoock> :D
14:30 < m-schmoock> i probably did understand like 30% of what was talked about, but im not that deep in RFC spec yet
14:30 < cdecker> If there's nothing else I think we can finish up
14:31 < cdecker> That's quite normal m-schmoock, I often have to go and look things up during these myself :-)
14:32 < cdecker> #endmeeting
14:32 < lightningbot> Meeting ended Mon Apr 29 21:32:03 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:32 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-04-29-20.05.html
14:32 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-04-29-20.05.txt
14:32 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-04-29-20.05.log.html
14:33 < t-bast> have a nice afternoon to the SF people, good night europe and good morning in the east ;)
14:33 < cdecker> Good upside down day you people in australia xD
14:38 -!- joe___ [d826964a@gateway/web/freenode/ip.216.38.150.74] has joined #lightning-dev
14:41 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
14:41 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
14:47 -!- t-bast [~t-bast@78.194.192.38] has quit [Quit: Leaving]
14:51 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
14:52 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
15:01 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has quit [Quit: Page closed]
15:01 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has joined #lightning-dev
15:01 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
15:02 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 255 seconds]
15:02 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has quit [Client Quit]
15:03 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has joined #lightning-dev
15:04 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has quit [Client Quit]
15:05 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has joined #lightning-dev
15:05 -!- joe___ [d826964a@gateway/web/freenode/ip.216.38.150.74] has quit [Quit: Page closed]
15:05 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
15:12 -!- hiroki [31ef4441@gateway/web/freenode/ip.49.239.68.65] has quit [Ping timeout: 256 seconds]
15:13 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
15:13 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
15:17 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
15:29 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
15:29 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
16:00 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
16:00 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
16:00 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
16:01 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
16:01 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 255 seconds]
16:09 -!- ccdle12 [~ccdle12@p116127-ipngn200301takamatu.kagawa.ocn.ne.jp] has joined #lightning-dev
16:10 -!- laptop500 [~laptop@host81-155-233-70.range81-155.btcentralplus.com] has quit [Ping timeout: 268 seconds]
16:17 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
16:17 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
16:23 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev
16:35 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
16:39 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
16:44 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 258 seconds]
16:49 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:08 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
17:10 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:11 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #lightning-dev
17:15 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 244 seconds]
17:17 -!- riclas [~riclas@148.63.37.111] has quit [Read error: Connection reset by peer]
17:17 -!- riclas [riclas@148.63.37.111] has joined #lightning-dev
17:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
17:31 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Read error: Connection reset by peer]
17:32 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #lightning-dev
17:34 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:39 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 258 seconds]
17:41 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
17:41 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
17:42 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:44 -!- BlueMatt_ [~BlueMatt@ircb.bluematt.me] has joined #lightning-dev
17:45 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 276 seconds]
17:47 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
17:56 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 276 seconds]
18:01 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #lightning-dev
18:01 -!- BlueMatt_ [~BlueMatt@ircb.bluematt.me] has quit [Read error: Connection reset by peer]
18:01 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
18:02 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
18:03 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has joined #lightning-dev
18:03 -!- marijnfs__ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
18:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
18:06 -!- riclas [riclas@148.63.37.111] has quit []
18:14 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
18:23 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
18:23 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
18:23 -!- scoop [~scoop@205.178.77.52] has quit [Read error: Connection reset by peer]
18:23 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
18:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
18:37 -!- marijnfs__ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
18:37 -!- marijnfs_ [~marijnfs@x5f764a8d.dyn.telefonica.de] has quit [Ping timeout: 268 seconds]
18:42 -!- unixb0y [~unixb0y@p5B0292F7.dip0.t-ipconnect.de] has joined #lightning-dev
18:46 -!- unixb0y_ [~unixb0y@p2E555F1A.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
18:47 -!- marijnfs__ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
18:47 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
18:56 -!- ccdle12 [~ccdle12@p116127-ipngn200301takamatu.kagawa.ocn.ne.jp] has quit [Remote host closed the connection]
19:03 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
19:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
19:03 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
19:15 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
19:15 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
19:35 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
19:35 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
19:55 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
19:55 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
20:09 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
20:09 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
20:10 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
20:21 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
20:21 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
20:43 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
20:43 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
20:47 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
20:47 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
20:53 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
20:53 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
21:05 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
21:05 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
21:13 -!- ccdle12 [~ccdle12@103.5.142.121] has joined #lightning-dev
21:15 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
21:15 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
21:25 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
21:25 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
21:30 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
21:30 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
21:35 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
21:35 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
21:40 -!- ugam [31cf36e6@gateway/web/freenode/ip.49.207.54.230] has joined #lightning-dev
21:50 -!- ccdle12 [~ccdle12@103.5.142.121] has quit [Remote host closed the connection]
21:51 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
21:51 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
21:57 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
22:01 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
22:02 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
22:17 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
22:18 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 255 seconds]
22:27 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
22:27 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
22:37 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
22:38 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
22:47 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
22:47 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
22:53 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
22:57 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
22:57 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 246 seconds]
22:58 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
22:59 -!- ccdle12 [~ccdle12@i210-161-167-204.s30.a048.ap.plala.or.jp] has joined #lightning-dev
23:05 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
23:08 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev
23:29 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
23:29 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
23:33 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 250 seconds]
23:36 -!- inara [~inara@68.ip-149-56-14.net] has quit [Quit: Leaving]
23:39 -!- inara [~inara@68.ip-149-56-14.net] has joined #lightning-dev
23:44 -!- ccdle12 [~ccdle12@i210-161-167-204.s30.a048.ap.plala.or.jp] has quit [Read error: Connection reset by peer]
23:53 -!- marijnfs [~marijnfs@x5f732401.dyn.telefonica.de] has joined #lightning-dev
23:54 -!- marijnfs_ [~marijnfs@x5f732401.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
--- Log closed Tue Apr 30 00:00:59 2019