--- Log opened Mon Apr 15 00:00:45 2019
00:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
00:37 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
00:50 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #lightning-dev
00:57 -!- mauz555 [~mauz555@78.31.45.164] has joined #lightning-dev
01:04 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has joined #lightning-dev
01:08 -!- araspitzu [~araspitzu@irc.acinq.fr] has joined #lightning-dev
01:12 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has quit [Remote host closed the connection]
01:12 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has joined #lightning-dev
01:40 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
01:46 -!- face [~face@80.72.82.160.coresnet.bg] has joined #lightning-dev
01:46 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
01:51 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
01:57 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
02:11 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
02:32 -!- mauz555 [~mauz555@78.31.45.164] has quit [Remote host closed the connection]
02:42 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
02:50 -!- ccdle12 [~ccdle12@061092247118.ctinets.com] has quit [Remote host closed the connection]
03:02 -!- shesek [~shesek@5.22.134.182] has joined #lightning-dev
03:02 -!- shesek [~shesek@5.22.134.182] has quit [Changing host]
03:02 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
03:12 -!- mauz555 [~mauz555@lstlambert-658-1-130-230.w217-128.abo.wanadoo.fr] has joined #lightning-dev
03:21 -!- mauz555 [~mauz555@lstlambert-658-1-130-230.w217-128.abo.wanadoo.fr] has quit [Read error: Connection reset by peer]
03:22 -!- mauz555 [~mauz555@lstlambert-658-1-130-230.w217-128.abo.wanadoo.fr] has joined #lightning-dev
03:31 -!- riclas [riclas@148.63.37.111] has joined #lightning-dev
03:44 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
03:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
04:04 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 250 seconds]
04:11 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer]
04:15 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has quit [Ping timeout: 268 seconds]
04:23 -!- giantseabass [uid358814@gateway/web/irccloud.com/x-ywsrecucwnamyxok] has quit [Quit: Connection closed for inactivity]
04:31 -!- RonNa [~quassel@220-133-223-206.HINET-IP.hinet.net] has quit [Quit: No Ping reply in 180 seconds.]
04:34 -!- RonNa [~quassel@220-133-223-206.HINET-IP.hinet.net] has joined #lightning-dev
04:50 -!- bralyclow [~bralyclow@193.36.117.238] has quit [Ping timeout: 264 seconds]
04:56 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has joined #lightning-dev
05:16 -!- shesek [~shesek@5.102.229.163] has joined #lightning-dev
05:16 -!- shesek [~shesek@5.102.229.163] has quit [Changing host]
05:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
05:54 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
06:00 -!- mauz555 [~mauz555@lstlambert-658-1-130-230.w217-128.abo.wanadoo.fr] has quit [Remote host closed the connection]
06:54 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
07:07 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
07:15 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
07:32 -!- davterra [~none@91.214.169.69] has joined #lightning-dev
07:35 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 252 seconds]
08:00 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 252 seconds]
08:14 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Remote host closed the connection]
08:16 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
08:17 -!- Ed0 [~edouard@2001:41d0:401:3100::4897] has joined #lightning-dev
08:28 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
08:29 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
08:40 -!- bralyclow [~bralyclow@193.36.117.238] has joined #lightning-dev
09:15 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
09:20 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 264 seconds]
09:24 -!- araspitzu [~araspitzu@irc.acinq.fr] has quit [Quit: Leaving]
09:31 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
09:34 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Ping timeout: 250 seconds]
09:50 -!- tgitm [~tgitm@c-73-14-30-230.hsd1.co.comcast.net] has joined #lightning-dev
09:54 -!- niftynei [~niftynei@104.131.77.55] has quit [Quit: ZNC - http://znc.in]
09:54 -!- niftynei [~niftynei@104.131.77.55] has joined #lightning-dev
09:56 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has joined #lightning-dev
10:02 -!- davterra [~none@91.214.169.69] has quit [Quit: Leaving]
10:10 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
10:19 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 252 seconds]
10:29 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
10:30 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
10:34 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 246 seconds]
10:35 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has quit [Remote host closed the connection]
10:41 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has quit [Remote host closed the connection]
10:51 -!- herbert [6dc5d2c3@gateway/web/freenode/ip.109.197.210.195] has joined #lightning-dev
11:07 -!- shesek [~shesek@5.102.229.163] has joined #lightning-dev
11:07 -!- shesek [~shesek@5.102.229.163] has quit [Changing host]
11:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
11:09 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:14b:3d0a:98d3:ed6] has joined #lightning-dev
11:13 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:14b:3d0a:98d3:ed6] has quit [Ping timeout: 252 seconds]
11:18 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
11:20 -!- herbert [6dc5d2c3@gateway/web/freenode/ip.109.197.210.195] has left #lightning-dev []
11:23 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
11:23 -!- pauljohnson [6dc5d2c3@gateway/web/freenode/ip.109.197.210.195] has joined #lightning-dev
11:31 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 252 seconds]
11:49 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:3906:99b4:77a7:2f06] has joined #lightning-dev
11:50 -!- pauljohnson [6dc5d2c3@gateway/web/freenode/ip.109.197.210.195] has quit [Ping timeout: 256 seconds]
12:04 < kanzure> hi
12:06 -!- laptop500 [~laptop@host109-149-118-169.range109-149.btcentralplus.com] has joined #lightning-dev
12:08 -!- hiroki [d295fc99@gateway/web/freenode/ip.210.149.252.153] has joined #lightning-dev
12:13 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:22 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
12:24 < warren> BlueMatt: blame Bitcoin for taking rusty away from kernel
12:30 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
12:34 -!- droark [~droark@c-24-21-203-195.hsd1.or.comcast.net] has quit [Quit: Later.]
12:40 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
12:47 -!- nettijoe [d826964a@gateway/web/freenode/ip.216.38.150.74] has joined #lightning-dev
12:51 -!- laptop500 [~laptop@host109-149-118-169.range109-149.btcentralplus.com] has quit [Ping timeout: 252 seconds]
12:52 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has joined #lightning-dev
12:53 < cdecker> What's a kernel and how do we implement it in Lightning? xD
12:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
12:57 < cdecker> @here: Specification meeting soon
12:58 < cdecker> Better get caught up with the list of pending PRs and issues: https://github.com/lightningnetwork/lightning-rfc/labels/Meeting%20Discussion
13:01 < rusty> I would also like to ask the q about TLVs: should we just assert that any extra bytes in msgs is the TLV, or have an explicit length then TLVs field in each msg...
13:02 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:3906:99b4:77a7:2f06] has quit []
13:02 < cdecker> You mean just appending the TLV to existing messages?
13:02 <+roasbeef> what if....we had a meeting time that didn't change multiple times during the year? tho I guess it's subjective
13:02 <+roasbeef> 3 hr swing so far 
13:03 < rusty> Yes.  If that's what we're def using for all future extensions, it's simplest.
13:03 < cdecker> Hehe, same here roasbeef, kind of hard to find a time that doesn't swing too much
13:03 < cdecker> Anyhow, let's ping everyone and see who shows up:-)
13:04 < cdecker> PING AmikoPay_CJP bitconner BlueMatt cdecker Chris_Stewart_5 kanzure niftynei
13:04 < rusty> roasbeef: you'll be happy to know I support the idea of removing DST in my state, so that may improve things!
13:04 < cdecker>   ott0disk roasbeef rusty sstone bitconner BlueMatt cdecker johanth kanzure
13:04 < cdecker>   roasbeef rusty sstone
13:04 < sstone> present :)
13:04 < rusty> niftynei
13:04 < niftynei> i feel lucky that gcal keeps track of it tbh 
13:04 < niftynei> :wave:
13:04 < cdecker> Ok, who would like to chair today?
13:05  * cdecker volunteers, but is happy to have someone else take the gavel :-)
13:05  * rusty hides...
13:06  * cdecker throws gavel xD
13:06 < cdecker> Ok, if noone volunteers let's get going
13:06 < cdecker> #startmeeting
13:06 < lightningbot> Meeting started Mon Apr 15 20:06:16 2019 UTC.  The chair is cdecker. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:06 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:06 < cdecker> Shall we jump right into reviewing the pending things or are there any important announcements to get in first?
13:07 < bitconner> present, your honor
13:07 < cdecker> Congrats to the LL team for the launch of Loop first of all:-)
13:07 < lndbot> <alexbosworth> moli just did the first clightning loop
13:07 < cdecker> Awesome :-)
13:08 < cdecker> #topic BOLT7: extend channel range queries with optional fields #557
13:09 < cdecker> As far as I can see the last few changes were mostly typo fixes
13:09 < rusty> OK, I have been working on converting this to TLV.  I have a commit, but I'm not happy with it.  See my TLV extension q. from before the meeting:
13:09 < cdecker> Did someone have an objection last time?
13:09 < rusty> "should we just assert that any extra bytes in msgs is the TLV, or have an explicit length then TLVs field in each msg..."
13:09 < bitconner> i think the primary objection from the last meeting was the to requiredness of the checksums
13:09 < cdecker> Ok, shall we tackle TLVs first? Seems they block a couple of things (including extensions on the new onion format)
13:10 < rusty> bitconner: well, also TLV, which makes it more optional.
13:10 < cdecker> Right, so the idea is to go fully flexible with TLV right away
13:10 < rusty> My plan was to implement and test against ACINQ then get back.
13:11 < sstone> with what we have or with changes to TLV format ?
13:11 < bitconner> was thinking it could also be done by defining option_extended_query_flag as a bitfield, tlv would also make that easier
13:12 < sstone> I'm not completely sure about TVL for this specific use-case
13:12 < sstone> TLV
13:13 < rusty> sstone: it's hitting the problem that it's the first one, so if we're going TLV we should do it for this.  Sorry...
13:13 < cdecker> I see your point, assigning types for query_short_channel_ids(chain_hash) seems weird
13:13 < sstone> rusty: I understand, it just looks a bit weird. 
13:13 < rusty> I *believe* we had consensus on TLV being the way forward, and so it seems simpler to make everything not already defined in messages to be a TLV; i.e. any leftover bytes.
13:14 < cdecker> A message (chain_hash|encoded_channel_ids|TLV_with_optional_parts) does seems sensible though
13:14 < sstone> ok. does everyone agree that we need the extra timestamps ?
13:14 < bitconner> yes
13:14 < cdecker> :+1:
13:15 < rusty> (niftynei has a PR which actually defines and parses the TLV format, FWIW, so I'll be making sure that's in sync)
13:15 <+roasbeef> cdecker: thanks! 
13:15 <+roasbeef> my q in #557 is how the checksum willbe modified in the future 
13:15 < bitconner> sstone, correct me if i'm wrong, but does the current proposal specify any sort of negotation?
13:15 <+roasbeef> like if we get more fields, or is that what we're saying above to just checksum all the optional fields as well? 
13:16 < cdecker> IIRC we must checksum the entire message (sans timestamp and signatures), otherwise we might miss updates that are important for our peers
13:16 < rusty> roasbeef: yeah, it's defined to skip TS and signature only...
13:17 <+roasbeef> ok, but if you're using a new tlv field, I don't know of, then how can we arrive at the same checksum? unless there's some upfront signalling 
13:17 < sstone> well sending optional fields is a very basic form of neg ?
13:17 < cdecker> (partial broadcasts that just end whenever they encounter a node that doesn't know how to parse has weird semantics)
13:17 < bitconner> sstone, no we'd making the same mistake we made w/ the encoding options, which forces everyone to understand it
13:17 < cdecker> roasbeef: the length gives you how many bytes to skip for that field, so just skip them when parsing and you can just resume parsing after that with the next field
13:18 < rusty> roasbeef: if channel_update contains new appended fields (TLV, presumably), they'll get included in checksum, just like they get incldued in signature?
13:18 <+roasbeef> is there an assumed upon ordering for the types in the TLV? 
13:18 < sstone> bitconner: sorry I don't understand your point
13:18 < rusty> roasbeef: increasing, yes.
13:19 < cdecker> increasing by type
13:19 < cdecker> With length and lexicographic content as tiebreaker for duplicate fields
13:20 <+roasbeef> gotcha, but even with that, lets say I have the old channel update on disk w/o the new field how am I able to compute your new check sum? 
13:21 < cdecker> Well, your checksum just includes the message you have on disk, and since your peer's will not match you will download and see the new fields
13:21 < bitconner> sstone, let's send query_flag=1 in a query_channel_range, if the remote peer doesn't support it are they allowed to send back reply_channel_range with query_flag=0?
13:21 < bitconner> and not include the extra data
13:22 < cdecker> Sure, why not?
13:22 < cdecker> You can always send back the old format, it's just an optimization for peers that know how to speak the new format
13:22 < sstone> you would just not include the optional flag
13:23 < bitconner> so then my proposal is to make option_extended_query_flag a bit field, allocating a bit for timestamps and another for checksums
13:23 < bitconner> it doesn't make sense to have checksums w/o timestamps, but vice versa is fine
13:23 < bitconner> then B can respond to A by masking it's supported feature w/ what is requrest
13:23 < bitconner> s/requrest/requested
13:24 < cdecker> Why not go TLV then? It's 2 additional bytes and allows us to swap out any part of the extra info in future without assigning a feature bit
13:24 < sstone> there is no specific feature bit in the current PR
13:25 <+roasbeef> cdecker: gotcha that makes sense 
13:25 < sstone> cdecker: ok one more argument for TLV
13:26 < cdecker> Yay :-)
13:26 < bitconner> so then what is the purpose of returning query_flag in the reponse, if not to signal what is included?
13:26 < cdecker> Ok, seems we sort of are agreeing that we want the timestamp and checksum fields to be split and made into a TLV field, am I interpreting this correctly?
13:26 < rusty> BTW, the TLV-ized version is here: https://github.com/rustyrussell/lightning-rfc/tree/fun-with-tlvs
13:27 < rusty> It's currently a pile of commits on top of the original proposal, sstone and I should go through and clean it up.
13:27 < bitconner> i think it makes sense to split them because adding checksums is a much bigger change from timestamps
13:28 < bitconner> timestamps alone solves the initial problem, while checksums are an additional optimization
13:28 < cdecker> Ok, I'll need to review rusty's proposal first :-)
13:28 < sstone> rusty: having fun with TLV sounds ...fun :)
13:28 < rusty> bitconner: easily done, just another TLV field.  sstone, do you agree?
13:28 < bitconner> rusty, a TLV on channel updates themselves? or the reply_channel_range?
13:29 < rusty> bitconner: the query and reply... the query uses it to flag what it wants,the reply uses it for the actual ts & csums.
13:29 < cdecker> Uhm, is that two TLV fields or a TLV with two fields? (for reference I always think of TLVs as a dict in python, or a map in go)
13:30 < bitconner> cdecker, i think it would be two fields so that each can be parsed independently?
13:30 < rusty> cdecker: bikeshed... we can have a TLV field saying "here's a flags word representing what I want" or one for "gimme timestamps" and anotehr for "gimme checksums"
13:30 < rusty> ... latter is probably cleaner, if we treat them independent.
13:31 < cdecker> Well, let me rephrase: the former is {"timestamps": []} {"checksums": []} whereas the latter which I prefer, is {"timestamps": [], "checksums": []} in JSON notation
13:31 < cdecker> And given that these are type-length-value encoded you can easily skip fields that you don't know how to interpret
13:32 < cdecker> Anyway, sorry for getting sidetracked
13:32 < cdecker> Do we agree that we want timestamps and optionally checksums?
13:32 < sstone> I prefer one TLV with two fields too
13:33 < cdecker> #agreed PR #557 is to be amended to track timestamps and checksums separately, so one or the other can be omitted.
13:33 < rusty> cdecker: the latter is more {"timestamps_and_checksums": []}?  That's the current proposal, but if we split it becomes {"timestamps": []} {"checksums": []} ?
13:34 < rusty> But yes, let's move on...
13:34 < cdecker> No the current proposal would be {"timestamps_and_checksums": []} which is inseparable
13:34 < bitconner> sgtm, long as there is some method of doing timestamps-only, i think it will reduce time to initial deployment :)
13:35 < cdecker> The distinction between one TLV with multiple fields or multiple TLVs become important once we talk about serialization of TLVs
13:35 < cdecker> It's not important here
13:35 < cdecker> Do we also agree that we want to investigate the TLV encoding for the fields??
13:35 <+roasbeef> cdecker: what's 1 with multiple fields entail? 
13:35 <+roasbeef> so the value is an array?
13:36 < rusty> I'm still confused.  There's one "tlvs" field in the message.  It  can contain multuple T's.  In this case 1 == timestamps, 2 == checksums, say.
13:36 < cdecker> Possibly, or just back to back serialized timestamps or checksums
13:37 < cdecker> Oh yeah, that's exactly what I was looking for, thanks rusty 
13:37 < rusty> OK, good.
13:37 < cdecker> So I count sstone and rusty in favor of TLV encoding the optional fields, do I get an ack from LL?
13:37 <+roasbeef> ok I think that clarifies it, ihave some other q's w.r.t why this particualr checksum algo was selected and the impact of it, but can push that to the PR itself 
13:38 < cdecker> #agreed PR #557 should be amended to use the TLV encoding for optional fields
13:38 < bitconner> sgtm, thanks for clarification rusty
13:39 < cdecker> Ok, I think that covers #557, right?
13:39 <+roasbeef> yep
13:39 < cdecker> Great, moving on
13:39 < cdecker> #topic Feature bit unification and assignment  #571
13:40 < cdecker> This one was skipped last time since it wasn't tagged, but it got dragged in through a later PR
13:41 -!- notniftynei [~notniftyn@c-73-206-86-168.hsd1.tx.comcast.net] has joined #lightning-dev
13:41 < cdecker> I think roasbeef had an issue with it last time
13:42 <+roasbeef> i was just never clear on what it was solving or why we wanted to do it, seems it just comes down to a rename? 
13:42 <+roasbeef> and iirc at the tail end last time, it was realzied that it could be done slighlty diff based on the discussion about the wumbo bit? 
13:42 < cdecker> Yep, pretty much. It just means that talking about feature bit 8 is not context dependent
13:43 < rusty> roasbeef: yes, but also we don't overlap so we can spray them both over the node_announcement, so you can tell I support foobar-channels.
13:43 <+roasbeef> maybe soem motivating uses cases or like user/nodes stories would make it more clear? 
13:43 <+roasbeef> like "bob wants to know if alice supports the new dlog htlcs, he looks at __ and __ to determine" 
13:43 < rusty> roasbeef: agreed.  And I'll leave the renaming to a separate PR, since it just muddies the issue?
13:44 -!- tgitm [~tgitm@c-73-14-30-230.hsd1.co.comcast.net] has quit []
13:44 < rusty> (I'm coming around to "channel" features vs "node" features, TBH, but that's a separate discussion).
13:44 < rusty> I think action is for me to clean that up to just state the overlap, give a good usage description, drop the renaming (for now), and have the feature assignments in a separate PR?
13:45 < cdecker> #action rusty to separate the PR into two PRs, one for rename and one for the overlap avoidance
13:45 < cdecker> :-)
13:45 < rusty> Great, let's move on...
13:46 < cdecker> #topic Specify tlv format, initial MPP #572
13:48 < rusty> Let's defer this... the rules for TLV need to be updated to specify varint, and that we're simply appending them to msgs.  The others, again, need to be split.
13:48 < rusty> (varint for type, that is: len is already varint)
13:48 < cdecker> Hm, too bad I really like the proposall
13:48 < cdecker> #action everybody to review the PR on Github
13:48 < rusty> Oh, I like it too, but it needs work on the PR.
13:49 < cdecker> #topic bolt04: Multi-frame sphinx onion routing proposal #593
13:50 < cdecker> I hope people had some time to look into the proposal since the last time
13:50 -!- notnifty_ [~notniftyn@2607:fb90:bde:1fd2:158b:97c7:dd08:98af] has joined #lightning-dev
13:50 < cdecker> Sorry for posting it so late the last time, but I procrastinated on the writeup a bit :-)
13:50 < bitconner> had a little bit of time, i do like it reduces the number of crypto operations :)
13:50 <+roasbeef> have some unpublished comments, but I've come around to the unification this achives between the two approaches 
13:51 < cdecker> Awesome, thanks :-)
13:51 < rusty> :hooray:
13:51 < cdecker> roasbeef: can you still publish those comments? I'm curious ^^
13:51 < cdecker> sstone: did you have time to take a look too?
13:51 < bitconner> iirc, one thing that was unresolved from last time was how to signal a partially complete payload?
13:52 -!- notniftynei [~notniftyn@c-73-206-86-168.hsd1.tx.comcast.net] has quit [Ping timeout: 255 seconds]
13:52 < sstone> yes but I did not have time to write a prototype :(
13:52 < cdecker> You mean how to use only part of a frame if the payload does not fit perfectly?
13:52 < bitconner> cdecker, yes, tho maybe that is done implicitly when using a TLV payload?
13:53 < cdecker> Yep, the TLV proposal defines type 0 as padding basically :-)
13:53 < cdecker> And for the old style payload we have the same convention anyway
13:53 < cdecker> (must be 0-padded)
13:54 < bitconner> sgtm
13:54 < cdecker> Ok, everybody happy with the proposal then?
13:56 < cdecker> Letting people finish writing their objection :-)
13:56 < bitconner> yep i'm happy. do we also agree that committing to the version number is a prerequesite, now that we'll have something other than 0? :)
13:57 < bitconner> will leave other notes on the pr, but approach is solid imo
13:57 < cdecker> You mean add the version number to the associated data?
13:57 < cdecker> Sure
13:58 < cdecker> Though that might be backwards incompatible wouldn't it?
13:58 < bitconner> yes, it isn't necessary atm since everyone only knows 0
13:58 < rusty> Dumb q: is there a decryption oracle problem now we can flip "realm byte" bits and measure how long it take to check hmac?
13:58 < cdecker> Wait, #593 doesn't change the onion version at all
13:59 < cdecker> rusty: hmac is still computed only once before we decrypt, and before we read the realm bits, so no
13:59 < bitconner> rusty, as in a timing orcale?
13:59 < rusty> cdecker: we could do some hack where we add realm byte to AD IFF it's != 0, but that seems icky...
14:00 < m-schmoock> good evening :D
14:00 < rusty> bitconner: yeah, but it was a half-baked thought.
14:00 < cdecker> rusty: yes, but that's not the realm byte its the onion serialization version which is currently not covered by hmac
14:00 < cdecker> Anyway, seems only minor things to hammer out
14:01 < rusty> cdecker: ah!  RIght.... hmm, bumping onion version is a diff change, needs signalling across path.
14:01 < cdecker> #agreed Conceptually accepted PR #593
14:01 < bitconner> yay!!
14:01 < cdecker> rusty: exactly, hence we only touch the realm byte which is covered by the hmac :-)
14:01 < cdecker> Awesome 
14:01 < cdecker> #topic BOLT2: rephrase cltv_expiry_delta text about accepting HTLCs #595
14:02 < cdecker> A small rephrase from harding, which I thought makes a lot of sense
14:02 < rusty> Yep, Ack.
14:02  * harding waves
14:02 < bitconner> ack
14:02 < sstone> ack
14:02 < cdecker> It's unwinding a few contortions from the original format
14:02 < bitconner> thanks harding!
14:02 < cdecker> #action cdecker to merge asap!
14:03 < rusty> Yeah, who wrote that original crap!  Oh...
14:03 < cdecker> #topic Miscelaneous and chit chat :-)
14:03 <+roasbeef> our 0.6 should be dropping this week, should reduce some of the enable/disable spam we see on the network 
14:03 < rusty> roasbeef: w00t!
14:03 <+roasbeef> have seen it go down a bit with nodes upgrading to the latest release candidate 
14:03 < cdecker> Great ^^
14:04 < rusty> I'll be missing next meeting: apparently there are these things called vacations?
14:04 <+roasbeef> one thing we've started to do is just not sync everything from all peers, so if you have 1k peers, we'll only actively get updates for 3 peers or so whcih makes a big diff w.r.t bandwidth usage 
14:04 < cdecker> I know, strange right?
14:04 <+roasbeef> inv stuff should clear up the remaining redundnacy 
14:04 < cdecker> Yeah, we might implement that soon too (2 weeks...)
14:05 < rusty> roasbeef: nice!  My own efforts to reduce gossip have stalled due to other random crap, but I've got a plan in a GH issue somewhere, so that's a start!
14:05 < cdecker> Have you guys seen the Turbo channels from bitrefill? They're 0-conf channels that are usable in one direction until they confirm
14:05 < m-schmoock> yep, didnt try thou
14:06 < cdecker> I was shocked initially, but after thinking about them a bit more it makes sense since they have all the capacity on their side
14:06 < cdecker> Anyway, we should probably end the meeting here.
14:06 < cdecker> Hoping we have some more discussion on trampolines for next time :-)
14:06 < rusty> cdecker: are they only usable in 1 dir?
14:07 < cdecker> Yep, they seem to refuse HTLCs in the other direction
14:07 < rusty> I bought a channel off bitrefill, but didn't try a turbo one... interesting...
14:07 < cdecker> Any famous last words?
14:08 < cdecker> #endmeeting
14:08 < lightningbot> Meeting ended Mon Apr 15 21:08:42 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:08 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-04-15-20.06.html
14:08 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-04-15-20.06.txt
14:08 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-04-15-20.06.log.html
14:09 < cdecker> Great talking to you guys :-)
14:09 < bitconner> anyone have a chance to look at the proposal from joost on integrating cltv errors into unknown payment hash + amount?
14:09 < bitconner> (on the ML)
14:09 < rusty> bitconner: still on my reading list.... I'll bump it up today.  Thoughts?
14:10 -!- notnifty_ [~notniftyn@2607:fb90:bde:1fd2:158b:97c7:dd08:98af] has quit [Remote host closed the connection]
14:10 -!- nettijoe [d826964a@gateway/web/freenode/ip.216.38.150.74] has quit [Quit: Page closed]
14:10 < cdecker> Sounds reasonable, but haven't had time to dig in
14:10 < bitconner> it seems to make sense to me, the same general probing attack that led us to bundling amount also seems possible with timeouts. proposal would unify (hash, amount, cltv) into a single
14:10 < bitconner> singgle error
14:11 < cdecker> Makes sense
14:12 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds]
14:12 < cdecker> It's always a bit of a tradeoff between how much we tell so the sender can adjust and how much we want to leak 
14:12 < rusty> bitconner: BTW, I think we'll actually want an error which indicates ~ how many orders of magnitude a payment was from avail capacity.  With any kind of AMP, we end up probing anyway, and this can just make it more efficient.
14:13 < rusty> But yeah, as cdecker said...
14:14 < bitconner> ah i see, that would make things easier
14:14 < bitconner> cdecker, good description of the tradeoff
14:14 < bitconner> cool, just wanted to bring it to people's attention, we can discuss further on the ML :)
14:15 < rusty> sstone: fun-with-tlvs branch updated to split the fields.
14:15 < cdecker> Yep, definitely appreciated, thanks bitconner 
14:15 < cdecker> I better get some sleep, see you around ^^
14:16 < rusty> cdecker: thanks for excellent chairing, too!
14:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 268 seconds]
14:26 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving]
14:35 -!- laptop500 [~laptop@host109-149-118-169.range109-149.btcentralplus.com] has joined #lightning-dev
14:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
15:05 -!- hiroki [d295fc99@gateway/web/freenode/ip.210.149.252.153] has quit [Ping timeout: 256 seconds]
16:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
16:10 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
16:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
16:29 -!- bralyclo_ [~bralyclow@193.36.117.238] has joined #lightning-dev
16:32 -!- bralyclow [~bralyclow@193.36.117.238] has quit [Ping timeout: 245 seconds]
16:42 -!- bralyclo_ [~bralyclow@193.36.117.238] has quit []
16:42 -!- bralyclow [~bralyclow@193.36.117.238] has joined #lightning-dev
16:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:04 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
17:13 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:21 -!- riclas [riclas@148.63.37.111] has quit [Ping timeout: 268 seconds]
17:38 < fiatjaf> bolt1 says there's a list of all messages used in the protocol in that same repository.
17:38 < fiatjaf> where are they?
17:40 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
17:43 < rusty> fiatjaf: where does it say there's a list?
17:45 -!- shesek [~shesek@5.22.134.182] has joined #lightning-dev
17:45 -!- shesek [~shesek@5.22.134.182] has quit [Changing host]
17:45 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
17:47 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:49 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
17:54 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
17:56 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
17:59 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
18:36 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 255 seconds]
18:49 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
18:49 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
18:57 -!- unixb0y [~unixb0y@p5B02959F.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
19:04 -!- unixb0y [~unixb0y@p2E555BAE.dip0.t-ipconnect.de] has joined #lightning-dev
19:26 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 252 seconds]
19:53 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
20:17 -!- khs9ne [~xxwa@host235-10-dynamic.211-62-r.retail.telecomitalia.it] has quit [Ping timeout: 252 seconds]
20:17 -!- khs9ne [~xxwa@host235-10-dynamic.211-62-r.retail.telecomitalia.it] has joined #lightning-dev
20:59 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
21:03 -!- StopAndDecrypt_ [~StopAndDe@96.47.239.18] has joined #lightning-dev
21:04 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 252 seconds]
21:37 -!- bralyclo_ [~bralyclow@2600:1700:3d70:93b0:6050:f9f4:cb62:8d30] has joined #lightning-dev
21:37 -!- StopAndDecrypt [~StopAndDe@96.47.229.186] has joined #lightning-dev
21:38 -!- StopAndDecrypt [~StopAndDe@96.47.229.186] has quit [Changing host]
21:38 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #lightning-dev
21:38 -!- StopAndDecrypt_ [~StopAndDe@96.47.239.18] has quit [Ping timeout: 252 seconds]
21:41 -!- bralyclow [~bralyclow@193.36.117.238] has quit [Ping timeout: 268 seconds]
22:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds]
22:59 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
23:04 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 246 seconds]
23:26 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-dctnsleffvfuxsal] has quit [Ping timeout: 252 seconds]
23:27 -!- takinbo [sid19838@gateway/web/irccloud.com/x-lpqvlaxuxfdyltsj] has quit [Ping timeout: 252 seconds]
23:28 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
23:29 -!- ThisAsYou [sid214210@gateway/web/irccloud.com/x-kzwblspyffyslcpb] has quit [Ping timeout: 258 seconds]
23:30 -!- dongcarl [sid321684@gateway/web/irccloud.com/x-zetauabocrfhksce] has quit [Ping timeout: 264 seconds]
23:36 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-zbzjlvltcztceqgl] has joined #lightning-dev
23:38 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-zbzjlvltcztceqgl] has quit [Max SendQ exceeded]
23:53 -!- takinbo [sid19838@gateway/web/irccloud.com/x-ymhvogtuqazzinto] has joined #lightning-dev
23:53 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-fwejofvhhdiimmzo] has joined #lightning-dev
23:54 -!- ThisAsYou [sid214210@gateway/web/irccloud.com/x-swxnwpcjvslznawu] has joined #lightning-dev
23:54 -!- dongcarl [sid321684@gateway/web/irccloud.com/x-jocbovnlvwjwimzj] has joined #lightning-dev
--- Log closed Tue Apr 16 00:00:46 2019