--- Log opened Mon May 13 00:00:11 2019 00:05 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 00:17 -!- Fluidjax [~textual@37.120.137.166] has joined #lightning-dev 00:42 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev 01:08 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has joined #lightning-dev 01:11 -!- ironbutt [~LiberLive@82.142.166.82] has quit [Ping timeout: 255 seconds] 01:59 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 258 seconds] 02:33 -!- kljasdfvv [~flack@p200300D46F03EB00FDA83991803D7566.dip0.t-ipconnect.de] has joined #lightning-dev 02:34 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 246 seconds] 02:34 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #lightning-dev 02:34 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host] 02:34 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev 02:36 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev 02:40 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds] 03:25 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev 03:57 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev 04:06 -!- shesek [~shesek@5.102.219.164] has joined #lightning-dev 04:06 -!- shesek [~shesek@5.102.219.164] has quit [Changing host] 04:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 04:15 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 255 seconds] 04:27 -!- scoop_ [~scoop@lexington23associates09.l.subnet.rcn.com] has quit [Remote host closed the connection] 04:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 255 seconds] 04:43 -!- scoop [~scoop@lexington23associates09.l.subnet.rcn.com] has joined #lightning-dev 04:49 -!- ccdle12 [~ccdle12@118.165.159.15] has joined #lightning-dev 04:53 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 05:21 -!- scoop [~scoop@lexington23associates09.l.subnet.rcn.com] has quit [Remote host closed the connection] 05:42 -!- scoop [~scoop@lexington23associates09.l.subnet.rcn.com] has joined #lightning-dev 05:58 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-ezvbbrgvlkmwxjmy] has quit [Ping timeout: 248 seconds] 05:59 -!- arij [uid225068@gateway/web/irccloud.com/x-ihphtfchcsthmhcp] has quit [Ping timeout: 248 seconds] 05:59 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 252 seconds] 06:02 -!- arij [uid225068@gateway/web/irccloud.com/x-vdgiunhcgtulfzvb] has joined #lightning-dev 06:07 -!- shesek [~shesek@5.102.219.164] has joined #lightning-dev 06:07 -!- shesek [~shesek@5.102.219.164] has quit [Changing host] 06:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 06:13 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-jcwaxumbygjxgvka] has joined #lightning-dev 06:18 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #lightning-dev 06:31 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 06:55 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 06:58 -!- ironbutt [~LiberLive@82.142.166.82] has joined #lightning-dev 07:00 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 246 seconds] 07:14 -!- scoop [~scoop@lexington23associates09.l.subnet.rcn.com] has quit [Remote host closed the connection] 07:31 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 07:35 -!- scoop [~scoop@lexington23associates09.l.subnet.rcn.com] has joined #lightning-dev 07:37 -!- scoop_ [~scoop@lexington23associates09.l.subnet.rcn.com] has joined #lightning-dev 07:37 -!- scoop [~scoop@lexington23associates09.l.subnet.rcn.com] has quit [Read error: Connection reset by peer] 07:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 252 seconds] 07:46 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.4] 07:47 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 07:47 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev 07:47 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Client Quit] 07:48 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev 08:16 -!- ulrichard [~richi@dzcpe6300borminfo01-e0.static-hfc.datazug.ch] has quit [Remote host closed the connection] 08:23 -!- Fluidjax [~textual@37.120.137.166] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:27 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #lightning-dev 08:34 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has joined #lightning-dev 08:37 -!- ironbutt [~LiberLive@82.142.166.82] has quit [Ping timeout: 246 seconds] 08:51 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving] 09:05 -!- scoop_ [~scoop@lexington23associates09.l.subnet.rcn.com] has quit [Remote host closed the connection] 09:06 -!- ccdle12 [~ccdle12@118.165.159.15] has quit [Remote host closed the connection] 09:24 -!- Fluidjax [~textual@37.120.137.166] has joined #lightning-dev 09:28 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has joined #lightning-dev 09:38 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Ping timeout: 245 seconds] 10:15 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 10:24 -!- shesek [~shesek@5.102.219.164] has joined #lightning-dev 10:24 -!- shesek [~shesek@5.102.219.164] has quit [Changing host] 10:24 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 10:40 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #lightning-dev 10:46 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has quit [Remote host closed the connection] 10:47 -!- sfhi [~sfhi@178.255.154.106] has joined #lightning-dev 10:51 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has joined #lightning-dev 10:52 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 10:55 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 268 seconds] 10:55 -!- __gotcha1 is now known as __gotcha 10:58 -!- sfhi2 [~sfhi@91-152-137-204.elisa-laajakaista.fi] has joined #lightning-dev 11:02 -!- sfhi [~sfhi@178.255.154.106] has quit [Ping timeout: 258 seconds] 11:44 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has quit [Remote host closed the connection] 11:45 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has joined #lightning-dev 11:48 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has quit [Remote host closed the connection] 11:48 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has joined #lightning-dev 11:55 < jtimon> I would love to get some feedback on https://github.com/lightningnetwork/lightning-rfc/pull/606 and https://github.com/lightningnetwork/lightning-rfc/pull/609 12:08 -!- nev_ [~nev_@185.43.237.7] has joined #lightning-dev 12:15 -!- scoop [~scoop@rrcs-50-74-176-238.nyc.biz.rr.com] has quit [Remote host closed the connection] 12:16 -!- scoop [~scoop@rrcs-69-193-180-22.nyc.biz.rr.com] has joined #lightning-dev 12:18 -!- JoostJager [51cf95f6@gateway/web/freenode/ip.81.207.149.246] has joined #lightning-dev 12:26 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 12:33 -!- jasonzhouu [~jason@101.132.74.90] has quit [Ping timeout: 245 seconds] 12:34 -!- jason [~jason@101.132.74.90] has joined #lightning-dev 12:34 -!- jason is now known as Guest65232 12:51 -!- Joe___ [d826964a@gateway/web/freenode/ip.216.38.150.74] has joined #lightning-dev 12:51 -!- scoop [~scoop@rrcs-69-193-180-22.nyc.biz.rr.com] has quit [Remote host closed the connection] 12:54 -!- sstone [~sstone___@185.186.24.109.rev.sfr.net] has joined #lightning-dev 12:56 -!- t-bast [~t-bast@2a01:e34:ec2c:260:5109:2ad0:54db:b559] has joined #lightning-dev 13:00 -!- notniftynei [~notniftyn@2607:fb90:18d5:6d64:3d32:d168:f2c3:c46a] has joined #lightning-dev 13:01 -!- notnotniftynei [d826964a@gateway/web/freenode/ip.216.38.150.74] has joined #lightning-dev 13:01 < cdecker> Heya all 13:01 < cdecker> Meeting? 13:01 <+roasbeef> lehdoit 13:01 < bitconner> hola! 13:01 <+roasbeef> how do we summon le bot? 13:01 < t-bast> hey guys 13:01 -!- hiroki_ [d295ff1d@gateway/web/freenode/ip.210.149.255.29] has joined #lightning-dev 13:02 < cdecker> (I won't be able to moderate today since I'm on a conference Wifi, and I might drop off at any time) 13:02 < sstone> hi everyone! 13:02 < cdecker> Commands are here: https://wiki.debian.org/MeetBot 13:03 <+roasbeef> #startmeeting 13:03 < lightningbot> Meeting started Mon May 13 20:03:03 2019 UTC. The chair is roasbeef. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:03 < cdecker> Yay :-) 13:04 < cdecker> List of topics scheduled for today: https://github.com/lightningnetwork/lightning-rfc/labels/Meeting%20Discussion 13:05 <+roasbeef> just added two things sec 13:05 < t-bast> the first two should be fairly simple :) 13:06 < cdecker> You mean the first two from the top? 13:06 <+roasbeef> #topic #609: unify redundant paragraphs 13:06 <+roasbeef> order is a bit diff now since aded soem 13:06 <+roasbeef> #609 prob falls under the typo rule 13:07 -!- nev_ [~nev_@185.43.237.7] has quit [Quit: Leaving] 13:07 < bitconner> yeh 13:07 < t-bast> cdecker: yes exactly 13:07 < cdecker> Yep, added the spelling tag 13:07 < bitconner> would also say that we probably don't even need the first sentence at all 13:07 < bitconner> the second is more specific 13:07 <+roasbeef> ok, so contest on merge? already has an ack from cdecker 13:07 < cdecker> lgtm 13:07 <+roasbeef> #action merge 609 13:07 < bitconner> lgtm, still a good clean up 13:08 < t-bast> lgtm 13:08 < sstone> ack 13:08 <+roasbeef> #topic 608 merge final expiry and unknown payment hash 13:08 <+roasbeef> so this is similar to what happend with unknown payhash and incorrect amount 13:08 <+roasbeef> rationale being that this should also be merged in order to not give back any identifiable information to nodes attempting to probe routes 13:09 < cdecker> Pretty close to a typo fix, but since it actually changes subject... 13:09 <+roasbeef> cdecker: #608? 13:09 < cdecker> Oh, sorry got confused about the order 13:09 <+roasbeef> ah np, this is 8 hrs old, so wouldn't expect ppl to have looked into it deeply yet 13:10 < bitconner> makes sense to me 13:10 -!- notniftynei [~notniftyn@2607:fb90:18d5:6d64:3d32:d168:f2c3:c46a] has quit [Remote host closed the connection] 13:11 -!- notnotniftynei [d826964a@gateway/web/freenode/ip.216.38.150.74] has quit [Quit: Page closed] 13:11 < t-bast> sounds reasonable, it could leak some info with the current behavior 13:11 < t-bast> so lgtm to update 13:11 < sstone> what does "trying payments with the correct amount" mean in this context ? 13:11 <+roasbeef> yeah that's the rationale behind the change, moving more towards a unified "that didn't work for me" error w/o giving intermediate nodes more info than they actually need 13:12 <+roasbeef> sstone: is that in the PR body? or ref to something above? 13:12 < sstone> in the PR description 13:13 <+roasbeef> I think he means payments with the proper amount, but the others modified in order to probe to see if a node will reject based on implementation specific params around grace periods 13:13 <+roasbeef> but proper amount would be guessed in many cases if the next link isn't the actual destination 13:14 <+roasbeef> i don't joost is on IRC rn, but I can forward some of these q's to him 13:14 < sstone> you mean by making up guesses as to the last hop and applying corresponding fees ? 13:14 < sstone> hops 13:14 < lndbot> hi all 13:14 <+roasbeef> a wild joost appears! 13:15 <+roasbeef> but he's on slack, so that's cheating ;) 13:15 < lndbot> sorry, other client didn't work. you apparently can't read my msgs 13:15 < lndbot> correct amount as in an amount that exceeds at least the invoice amt 13:15 < lndbot> it needs the proper amount, otherwise it would trigger the incorrect_or_unknown_payment error. the idea is to force the final_expiry_too_soon error to reveal that that node is the destination 13:15 -!- notniftynei [~notniftyn@2607:fb90:18d5:6d64:3d32:d168:f2c3:c46a] has joined #lightning-dev 13:16 < sstone> if proper means exactly what the destination is expecting Id' say guessing would not be that easy ? 13:17 < lndbot> amount doesn't need to be exact, but enough. at least as long as overpayments are accepted 13:17 < bitconner> sstone: it only needs to be within 1-2x the invoice amount, iiuc 13:17 < bitconner> or any positive value if the invoice is zero-valued 13:18 < lndbot> then the expiry needs to be lower than the final invoice cltv, that is more guesswork, but still doable 13:18 < sstone> ok 13:19 < lndbot> the success of the attack also depends on implementation specifics, but the way it currently is, some info is leaking 13:20 <+roasbeef> don't think we need to come to a general agreement rn, just wanted to intro the change, we can circle back on it next meeting to give ppl more time to digest perhaps (less than a day old), but similar to a change we've made in the past so i'm on board with the general idea 13:21 < bitconner> sgtm, not a very contentious change (i think) and we have a lot of topics today :) 13:21 < t-bast> it's going to be a trade-off between ease of debugging and security - early on in the network's life it's useful to be a bit specific in the errors, once everything works well errors should be as generic as possible to avoid leaking anything (think padding oracle attacks in crypto) 13:22 <+roasbeef> t-bast: so the sender still has all the info 13:22 <+roasbeef> but less info for the intermediate nodes 13:22 < t-bast> yeah in that case I don't think it even hurts debugability 13:22 < t-bast> so lgtm 13:22 <+roasbeef> ok, sounds like it isn't too controversial, but we're missing a few ppl in this meeting, so maybe let's keep it on the agenda for the next one to give others a chance to check it out? 13:23 < sstone> sgtm 13:23 < cdecker> Sounds good to me, would like to dig in a bit more, but overall sounds reasonable 13:23 <+roasbeef> #agreed circle back on #608 next week 13:23 <+roasbeef> #topic #607 and #603 13:23 <+roasbeef> combining them since they're proposing similar things 13:24 <+roasbeef> bitconner: wanna give us an overview on the diff tradeoffs this makes compared to rusty's original/ 13:24 <+roasbeef> ? 13:24 <+roasbeef> both on the topic of a TLV format 13:24 < bitconner> sure 13:24 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/607 13:24 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/603 13:24 <+roasbeef> (first one is the new one) 13:24 -!- hiroki_ [d295ff1d@gateway/web/freenode/ip.210.149.255.29] has quit [Ping timeout: 256 seconds] 13:24 < bitconner> the big question that i think needs to be answered here is whether or not we are okay with having two different wire formats, wire vs onion 13:25 < bitconner> to me, the tradeoffs are sufficient to warrant this, though i'm not sure if others feel the same 13:25 -!- notniftynei [~notniftyn@2607:fb90:18d5:6d64:3d32:d168:f2c3:c46a] has quit [Remote host closed the connection] 13:25 < bitconner> that being said, i took a stab at writing up a spec for a spec tailored more for wire specificaly 13:26 <+roasbeef> what makes this more wire specific? diff sizes for type + length? 13:26 < bitconner> to me the biggest differences is enforcing canonical ordering, as wire-TLV may be used to extend gossip messages that need signature verification to function properly 13:26 <+roasbeef> the additional ordering requirement deseriable in both contexts 13:27 < t-bast> can you detail why you think 2 wire formats are needed in the first place? I think canonical ordering for example could be desirable for both, isn't it? 13:27 < bitconner> it also has a requirement for readers to cache unknown fields, so that they can be reserialized properly 13:27 < cdecker> I was just about to ask the same thing 13:27 <+roasbeef> #603 lacks an odering requirement iirc 13:27 <+roasbeef> or possibly just doesn't make it explicit 13:27 -!- hiroki_ [d295ff1d@gateway/web/freenode/ip.210.149.255.29] has joined #lightning-dev 13:27 < bitconner> cdecker t-bast, i'm not certain. i would be in favor of enforcing it in either/both 13:28 < t-bast> but how do you sign without a canonical ordering? 13:28 < sstone> I think #603 also specifies ordering 13:28 < bitconner> t-bast: we need to be more space concious in the onion tlv, since space is much more limited. thus using a varint to capture the savings of encoding small values makes sense 13:29 < cdecker> No, I'm not sure I get what you refer to when saying "having two different wire formats, wire vs onion" 13:29 < bitconner> t-bast, you can't, which is why this one requires enforcing canonical ordering 13:29 < sstone> bitconner: then why not use a varint for length also, limited to 2 bytes ? 13:30 < niftynei> there is canonical ordering on #603 " MUST order `tlv` in ascending type, length and value." 13:30 < t-bast> bitconner: ok I get why you propose that then. But shouldn't we then use varint and enforce canonical ordering, and we have 1 format that works everywhere? :) 13:31 < bitconner> sstone, i'm not opposed to using a varint, though at most it will save 256/65Kb =- 0.39% of the available space and fixed-size is slightly faster 13:32 < bitconner> niftynei, the requirement is only on the writer though? 13:32 < bitconner> i'm suggesting that the reader must also assert this 13:32 -!- Guest65232 [~jason@101.132.74.90] has quit [Ping timeout: 258 seconds] 13:32 <+roasbeef> t-bast: main diff being the size constraints, 65kb just at most 1kb and some change maximally but most cases using tens of bytes 13:33 < niftynei> oh i see. my understanding was that the reader is free to enforce if they want to (it is indicated as MUST) 13:34 < sstone> also #603 seems to imply that there could be multiple occurrences of the same type 13:34 < bitconner> niftynei, in order for signature checks to pass idt we can make it optional for the reader iiuc 13:34 -!- niftynei_mobile [~notniftyn@2607:fb90:18d5:6d64:3d32:d168:f2c3:c46a] has joined #lightning-dev 13:34 <+roasbeef> #607 also doesn't have the even/odd distinction 13:35 <+roasbeef> in the past when it came up, from my PoV it can be captured using only feature bits, but depending on if wire vs onion that may not always be the case at first glance 13:35 < bitconner> another difference between the two is the even/odd rule, which isn't needed for wire messages afaik since this can be gated via feature bits 13:36 < cdecker> But the same is true for onion TLV where we signal support via the node_announcement.features 13:36 < bitconner> imo, the even odd rule should be applied at a different layer than the parsing requirements 13:37 -!- niftynei_mobile [~notniftyn@2607:fb90:18d5:6d64:3d32:d168:f2c3:c46a] has quit [Remote host closed the connection] 13:38 <+roasbeef> cdecker: meaning we do or don't need the even/odd rule? 13:38 < bitconner> cdecker, though not all nodes have nodeannouncements 13:38 <+roasbeef> hmm yeah I guess some would need to leak into the invoice as well? 13:38 < niftynei> i like how the even/odd rule signals the intent of the type author as to strength of the requirement 13:38 < cdecker> Oh I see that you wrote something about the need to use a different TLV format for wire. 13:39 < cdecker> I get the feeling I need to read more on it before making an informed decision (sorry for slowing this up) 13:39 < niftynei> it makes it easier to check on a spec/inclusion level intent wrt feature bit additions etc but that's more of a process check than code level check 13:39 < bitconner> niftynei, i think we can still use the even/odd rule in the onion-specific namespace 13:39 <+roasbeef> niftynei: depends on the context, why would you put non essential data in the onion? for the wire may apply more 13:39 < bitconner> my point is that it doesn't need to be inherited by all namespaces 13:41 < cdecker> I'm just worried about my mental capacity of keeping the context rules separate when reading the spec :-) 13:42 <+roasbeef> if distinct, ideally they'd be in distinct documents 13:42 < jtimon> re #609 Happy to remove the first sentence and the "In other words". Also, I guess "remote node's responsibility" was more specific than "the offerer's responsibility" too, so I guess I should keep that version instead. 13:42 < jtimon> sorry if it's not the right time and it's better to discuss it at the end since I'm talking about minor details 13:42 <+roasbeef> ~20 mins left, few other topics still, perhaps we should comment directly on the TLV PRs? open questions seems to be: if distinct wire and onion, and if even/odd should apply to all (or just one if unified), requirements for decoder 13:42 < cdecker> sgtm 13:43 < niftynei> cool. 13:43 < t-bast> sgtm 13:43 < sstone> sgtm 13:43 <+roasbeef> jtimon: so there's rough agreement for acceptance, have moved onto other topics, but you can change up your PR if you'd like 13:43 < bitconner> sgtm 13:43 < niftynei> thanks for the second write up bitconner, it's good to see the tradeoffs laid out 13:43 <+roasbeef> #agreed discuss #603 and #607 on PR, open q's to resolve: if distinct wire and onion, and if even/odd should apply to all (or just one if unified), requirements for decoder, 13:43 <+roasbeef> #topic 606 13:43 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/606 13:44 < jtimon> yeah, no hurry, as said it's minor details, just trying to be coherent with the "more specific is beetter" comment 13:44 <+roasbeef> has two approvals rn 13:44 <+roasbeef> changes connection to channel 13:44 <+roasbeef> I think for soem implementations a connection and channel are 1:1 13:44 <+roasbeef> while others allow more than one channel over a connection 13:44 < cdecker> Was really close to calling this a typo fix, but subject changes :-) 13:44 < bitconner> niftynei, thanks! was tyring to get a feel for how much they did/didn't intersect :) 13:45 < cdecker> This is HTLCs that are specific to a channel so I think channel is the correct scope to fail here 13:45 <+roasbeef> ah ok, expanded the diff, that's clear now 13:45 < t-bast> agreed 13:45 < bitconner> iirc, there are probably more cases where connection is used synonmously with channel, but perhaps my memory evades me 13:45 <+roasbeef> so we're good with this? 13:45 < bitconner> yep 13:46 <+roasbeef> #action merge #606 13:46 < t-bast> lgtm 13:46 <+roasbeef> #topic #601 13:46 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/601 13:46 <+roasbeef> > BOLT 3: Explicit description of implicitly enforced timelocks on HTLC outputs 13:46 < cdecker> This is a followup on a clarification we discussed last time 13:47 <+roasbeef> ah since it's a locktime rather than cltv for second levels? 13:47 < cdecker> Our comment last time was that he talks about timeout enforcement but never mentioned the locktime, so now he fixed it up 13:47 < cdecker> Yep 13:49 <+roasbeef> not sure the portion of the diff on bolt2 is well placed 13:50 -!- jason [~jason@101.132.74.90] has joined #lightning-dev 13:50 <+roasbeef> it's not that it's to make the scripts smaller, instead it makes an off chian covenant since it's a multi-sig and both sides must explicilty sign off on redemption paths 13:50 -!- jason is now known as Guest30793 13:50 <+roasbeef> i'll comments this on the PR, the rest of it looks ok to me 13:51 < t-bast> agreed with roasbeef on that part which surprised me a bit 13:51 <+roasbeef> #action roasbeef to comment on #601 about bolt2 portion of diff 13:51 < bitconner> sgtm, and can also figure out it's final resting place 13:51 < t-bast> otherwise lgtm 13:51 <+roasbeef> ppl ok if we move on? 13:51 < t-bast> yep 13:51 <+roasbeef> t-bast: yeh same 13:51 < bitconner> yes 13:51 < sstone> yes 13:51 < cdecker> sgtm 13:51 <+roasbeef> #topic #604 and #593 13:51 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/604 13:52 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/593 13:52 <+roasbeef> these are about deciding on the framing/parsing of the unused onion space 13:52 <+roasbeef> #604 is newer proposed by rusty to compromise on discussion in #593 13:52 <+roasbeef> the biggest diff is that it defines the payload entirely to use tlv everywhere 13:52 < cdecker> So I added the last commit on #593 for the multi-frame signaling. If we decide in favor of #604 we need to cherry pick that over 13:53 <+roasbeef> this cuts off some redundant data for the final hop, and imo makes this a bit more consistent (no hybrid of old and new payload) 13:53 < jtimon> bitconner: yeah, I grep'ed "fail the connection" and it felt like probably more should be revised, but that one just felt clearer because of the "fail the channel" for the offering node 13:53 <+roasbeef> recent discussion in #593 centered around if ppl should be able to use all available space and also how many possibl tlv/packet types were "enough" 13:53 < cdecker> My only concern is that we now have a mapping of realm -> num_frames that needs to be added to the onion processing code 13:53 <+roasbeef> cdecker: am i correct in that #593 leaves that old 13 padding bytes unused? not sure if just wasn't made explicit that it's part of the greater payload 13:54 <+roasbeef> cdecker: wasn't it already there with #593? just needed to be parsed out? 13:54 < cdecker> roasbeef: the old format allows you to stick additional fields at the end, so you can use them as is now 13:54 <+roasbeef> cdecker: but it expected them to be zero right? those 13 bytes 13:54 < cdecker> roasbeef: no, the feature flag was added to the node_announcement in the gossip 13:55 <+roasbeef> not sure we're talking about the same thing here, I see that added commit to add the feature bit, would need to be included independent of which approach we go with 13:55 < t-bast> I think the mapping isn't more necessary, we can just do 0x00ff & payload[0] to get the number of frames (like we would do 0xff00 & payload[0]) in 593 13:55 < cdecker> Not really, it's just treated as a normal wire-packet so if we were to define an additional field to the legacy hop data we could add that 13:56 < bitconner> 16 namespaces seems like plenty to me 13:56 < cdecker> t-bast: that assumes we only ever have 21 realms? And all realms > 0 are TLV 13:56 < t-bast> cdecker: you're right, got it 13:56 < bitconner> well, 15 i guess? 13:56 < cdecker> bitconner: where does the "namespace" come from? 13:56 < t-bast> for other realms we'd need a different parsing logic which is a bit cumbersome 13:56 <+roasbeef> bitconner: so #593 has 16 namespaces, #604 kinda defers that and makes tese new realm bytes use a new paylaod format that's all tlv so just opauqe blobs passed u p 13:57 <+roasbeef> cdecker: i think he means packet type 13:57 < cdecker> Ok, yes 13:57 < cdecker> Got it 13:57 <+roasbeef> t-bast: so you're saying remove the bit packing and use the first byte? 13:57 <+roasbeef> in #593 13:57 < bitconner> cdecker, yes packet type, since each packet type could map to distinct namepsaces :) 13:57 < bitconner> but packet type is more correct 13:58 <+roasbeef> #604 merges the packet type and the number of frames used 13:58 < bitconner> anyway, we will have another chance to consider how many packet types are needed when we redo the onion format to commit to a per-hop version 13:58 <+roasbeef> biggest thing as mentioned above is that the entire onion payload is now tlv, so the old fields like amount to forward now have a tag 13:58 < t-bast> roasbeef: for the first 4 bits (realms 0 to 15) that works but as cdecker points out, for bigger realms the mapping realm -> number of frames might be different 13:58 < cdecker> tbh I don't like namespacing since it creates composite types that, spreading the type logic over multiple fields, and they are just coarse-grained 13:59 < cdecker> The counterproposal in #593 to the whole namespacing idea is to have var_int types in TLV 13:59 < t-bast> bitconner: totally agree that we'll have another opportunity to make more changes when we re-work onion to support per-hop version and we can evaluate at that time if we need more available packet types or something 13:59 < cdecker> Which allows us to use much more types, and avoid composite types altogether 14:00 < bitconner> t-bast, yeah i don't think we'll be able to exhaust all of the ones we have before that happens (assuming it doesn't take a decade :) 14:01 < cdecker> To be clear: all packet-types in #604 would use the same TLV type namespace 14:01 < cdecker> The only difference between the packet-types is how many frames the current hop should consume 14:01 < t-bast> I think that I slightly prefer #593 because the parsing of the number of frames is a bit cleaner / doesn't leak into type namespacing. But honestly I'm fine with both and I think they would unlock things like trampoline/rendezvous routing which is nice 14:01 <+roasbeef> but also the "type" is defiend in that realm also 14:02 <+roasbeef> i lean towards #604 mostly due to the unification there, no old+new just new (speaking of how the payload is interpreted) 14:02 < bitconner> cdecker, why not defer specifying the format of those packet types until we have a use case? 14:03 <+roasbeef> yeah both kinda do that already iiuc 14:03 < bitconner> we coulddd use a different namespace if we have a reason to after seeing how the initial deployment of version 1 goex 14:03 < bitconner> goes* 14:03 < cdecker> bitconner: the multi-frame proposal is concerned solely with how we signal how many frames we need to consume 14:03 < cdecker> Mixing in the namespacing for TLVs can be deferred, which is what I'm proposing 14:04 < cdecker> The two are orthogonal really, which is why I cam up with the 4 bit / 4 bit split initially 14:04 < bitconner> cdecker, oh i see, thanks for the clarifying 14:04 < t-bast> the two are orthogonal really -> completely agree 14:05 <+roasbeef> yeh the bigger thing imo is the clean slate payload in #604 14:05 < cdecker> roasbeef: #593 would also allow old and new payload format and has them cleanly separated (lsb 4 bits) 14:05 <+roasbeef> does it? i find that kinda murky as it's written atm 14:05 < t-bast> which is why I think this is enough to unblock many new scenario until we work on another update for per-hop versioning - where we will likely revisit that and have the opportunity of a cleaner slate 14:05 <+roasbeef> so i need to have 13 bytes between the new and old when I encode? 14:06 <+roasbeef> do* 14:06 < cdecker> I think our main disagreement comes from the fact that #593 as written would allow legacy payloads with multiple frames which may not be sensible since we haven't defined additional fields for that format 14:06 <+roasbeef> there's that too 14:06 < cdecker> roasbeef: you want to mix legacy with an optional TLV at the end? 14:06 < cdecker> Sure we can do that easily 14:07 < cdecker> But then we merge #593 and then we define that we can have an optional TLV appended to the legacy payload, and we're done 14:07 < cdecker> No need for 13 0x00 bytes inbetween 14:07 <+roasbeef> not that I want to really, but that it wasn't clear to me upon reading if that was allowed or not, and then how the parser would react to that: it'd pass up the first 65 or so as the legacy payload, then the rest opque 14:07 < t-bast> sgtm 14:08 < cdecker> Since the legacy payload is parsed identically to wire messages we can append anything at the end really 14:08 <+roasbeef> but then we'd be modifying how the legacy paylaod is parsed? 14:08 <+roasbeef> as in don't read those 13 bytes 14:08 < cdecker> Oh, I see. In that case I'd expect the onion processor to hand up the legacy payload unparsed and have the caller parse it 14:08 < bitconner> mixing legacy w/ optional tlv makes sense to me, shaves a few bytes that could keep certain applications from overflowing into an additional frames 14:09 <+roasbeef> bitconner: #604 adds the overhead for signalling the payload as distinct types, but then since it's a new format entirely it drops the short chan iD for the final hop 14:09 <+roasbeef> so the code would pass teh blob up, and parsing for the types would be unified 14:09 <+roasbeef> rather than parse old then new 14:10 < cdecker> From what I see that would be perfectly doable: keep legacy payload around, open a new PR that adds an optional TLV in the place of the 13 padding bytes and voila 14:10 < cdecker> roasbeef: exactly :-) 14:10 < bitconner> awesome, sgtm 14:11 <+roasbeef> don't follow the second part of that cdecker, why this over the clean slate approach? 14:11 < cdecker> Both are doable is what I'm saying 14:11 <+roasbeef> gotcha 14:11 < cdecker> fwiw I'm planning on using TLV exclusively going forward 14:12 <+roasbeef> ok thx i understand implications of #593 now better, but still lean towards #604 myself, with the undertone that I think we'd all like this to move forward so we can get to the fun stuff it enables 14:12 < cdecker> But like bitconner says it might be useful to keep legacy around just to save on bytes and still have the TLV flxibility added 14:12 < t-bast> roasbeef: agreed ;) 14:13 < cdecker> I have a slight preference for #593 (no suprise there really) but I'm happy with either 14:13 < jtimon> what is TLV? where can I read more about that? 14:13 <+roasbeef> it only saves on bytes for intermediate nodes fwiw, i don't think we lose the flexibility 14:13 <+roasbeef> jtimon: type length value, a way for forwards/backwards compat when adding new fields to messages 14:13 < bitconner> jtimon: check out the open PRs for TLV :) 14:13 < jtimon> thanks 14:14 < bitconner> sure thing! 14:14 < bitconner> okay, so can someone quickly enumerate the multi-frame items that remain to be solidified? 14:14 < cdecker> roasbeef: we also have two variants for #593 btw (4bits + 4bits vs 5bits + 3bits) :-) 14:14 < cdecker> Just to add a bit of complexity 14:14 <+roasbeef> kek 14:15 < cdecker> Ok, so #604 explicitly enumerates 21 types (I'm assuming we want 20 TLV multi-frame types here), but mixes types and num_frames in an explicit map 14:16 < cdecker> i.e., the code processing the onion needs to know the map of packet-type to num_frames to return 14:16 < cdecker> #593 separates them into two separate regions of the former realm-byte, but loses a bit of expressiveness 14:17 <+roasbeef> along side it also makes the entire thing just tlv and drops the old aprior framing (#604 does) 14:17 < cdecker> roasbeef: packet-type 0 is still a single frame with the legacy format even in #593 14:17 < cdecker> roasbeef: literally nothing changes for that packet-type and we keep it working 14:17 <+roasbeef> yeh, #604 does away with the legacy all together 14:18 < cdecker> packet-type 0 translates into 1 frame (0x00 & 0xF0 additional frames => 1 frame total) and realm 0 (0x00 & 0x0F => realm 0) 14:18 <+roasbeef> #604 _is_ higher code impact though imo 14:18 <+roasbeef> cdecker: yeh i get that 14:20 < niftynei> what is a "code impact"? 14:20 < cdecker> So both proposals keep backward compatibility (legacy payload format is maintained and it has matching packet type 0x00), it literally just in how we decide on how many frames to return :-) 14:20 <+roasbeef> niftynei: so code to parse the first 65 bytes under the new and old format 14:20 <+roasbeef> since depending on realm, it'll be diff 14:21 < niftynei> also this may be a bit of a naive question, but doesn't doing away with the legacy entirely make it such that onions can't be routed through nodes that haven't upgraded yet? 14:21 < cdecker> Hm, I'm actually just handing the blob up to the caller, and the caller can then decode the blob depending on the packet type 14:21 <+roasbeef> yeah so you wouldn't send it to them based on the feature bit niftynei, it's also signalled in a new realm 14:21 < cdecker> (this is the layering thingy I was talking about in the PRs btw) 14:21 <+roasbeef> or a diff looking realm 14:22 < t-bast> non upgraded nodes should fail on unknown realms - but new messages can have some hops that use the old payload and route through non-upgraded nodes 14:23 < t-bast> so I think we should be good with both proposals on that front 14:23 < niftynei> kk 14:23 < cdecker> Absolutely, #604 just goes ahead and also deprecates the legacy format 14:24 < cdecker> And that's where the added code complexity comes from 14:25 < t-bast> so should we go ahead with #593? 14:25 < cdecker> Well actually it just specifies numeric types to be used to recreate the legacy payload in the TLV format, which I would have split into a separate PR 14:26 -!- hiroki__ [d295ff1d@gateway/web/freenode/ip.210.149.255.29] has joined #lightning-dev 14:26 <+roasbeef> feels a bit unfair to move on one without giving the author of the other proposal a chime in on any additional context (rusty not here) 14:26 <+roasbeef> unless one of y'all wants to speak for him? ;) 14:26 <+roasbeef> i think we're making progress though... 14:26 < t-bast> agreed, we can wait for rusty's input (maybe in PR comments?) 14:26 <+roasbeef> info wise at least 14:26 < cdecker> Yep, sounds like we're getting there 14:27 < cdecker> We could record an action to move on either once we hear from Rusty 14:27 < t-bast> sgtm 14:27 < bitconner> pRoGrEsS!? 14:27 < cdecker> Shall we count ranked choices so we can trigger once Rusty gives his? 14:27 <+roasbeef> #action wait for comments/feedback from rusty w.r.t #593 vs #604 on PR 14:27 < bitconner> cdecker, sgtm 14:28 <+roasbeef> cdecker: on teh PR on in these notes? we can add them as #info 14:28 <+roasbeef> if these notes 14:28 < cdecker> Oh, and I'd like to make the split in #593 5bits and 3bits officially so we can use all 20 frames instead of just the 17 we had so far 14:28 -!- hiroki_ [d295ff1d@gateway/web/freenode/ip.210.149.255.29] has quit [Ping timeout: 256 seconds] 14:29 < t-bast> :thumbs_up: 14:29 < t-bast> (lack of slack icons...;)) 14:29 <+roasbeef> kek 14:29 <+roasbeef> ok, so done here for now? 14:30 < t-bast> I'm good with the progress we made :) 14:30 <+roasbeef> #endmeeting 14:30 < lightningbot> Meeting ended Mon May 13 21:30:31 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 14:30 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-05-13-20.03.html 14:30 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-05-13-20.03.txt 14:30 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-05-13-20.03.log.html 14:30 < bitconner> cdecker, i think i'm in favor of the 5/3 split. num hops > num formats 14:30 < cdecker> Awesome 14:30 < t-bast> agreed with bitconner and cdecker on 5/3 split 14:30 < t-bast> which wins my vote to #593 over #604 14:31 < bitconner> ultimately, we will get another shot at this soon enough :) 14:31 < cdecker> Yep 14:31 < cdecker> So I'll amend the PR #593 with the new split, giving us 8 packet types, and 20 frames for single hops, and then we can flip a coin between #593 and #604 14:31 < bitconner> we can all start saving in our bikeshedding piggy banks 14:31 < cdecker> :-) 14:32 < bitconner> sgtm 14:32 < t-bast> sgtm! 14:32 < sstone> nice! 14:32 < bitconner> does anyone want to discuss more on tlv proposals?> 14:33 < t-bast> I think a bit more time to study the two proposals and discuss on the PRs would be great - rusty's input would be interesting here as well 14:34 < niftynei> i am curious about the requirement for saving tlv parts if there's a signature on the message 14:34 < bitconner> indeed, though i've found it tough to really dig into the tradeoffs during the past few meetings. was thinking if people have questions that can be answered now, we can shake those concern out before the next meeting is upon us 14:34 < cdecker> Ok, #593 has a fixup with the new split :-) 14:35 < niftynei> (also need to finish reading #607 tho) 14:35 < bitconner> cdecker, that was fast! 14:35 < bitconner> niftynei, i think we need to save the unknown fields anytime we have to reserialize a message that is given to us 14:36 < cdecker> My motto is "why do now, what you can spend the next 3 meetings discussing" ;-) 14:36 < bitconner> this can happen when recomputing signature digests, forwarding the message to a peer, or even writing the message to your own db 14:36 -!- sfhi2 [~sfhi@91-152-137-204.elisa-laajakaista.fi] has quit [Quit: Leaving] 14:37 < bitconner> if we don't cache the unknon fields, it will cause the signature check to fail, an incomplete message to be forwarded, or an incomplete message returned when reading from the db, respectively 14:37 < cdecker> This only applies to gossip messages right? Or am I missing a place where we need to recompose a message? 14:38 < bitconner> some messages purely contain optional fields and all processing is done in memory, in that case we wouldn't need to, e.g. in extended gossip query proposal 14:38 < niftynei> my confusion is around why the differentiation around signatures -- it seems like if you're forwarding on a message then you should always retransmit the entire received packet, even if there's parts you don't understand 14:38 < bitconner> cdecker, afaict it'd only happen for channel_update, channel_announcment, and node_announcement 14:39 < bitconner> niftynei, i suppose it depends on whether or not the entire serialized message is cached 14:39 < cdecker> Got it. In those cases we just write the messages as is out to the disk and will read from it when forwarding 14:40 < bitconner> cdecker, write the message directly from the wire to the database? 14:40 < cdecker> In our case it's an append only file 14:40 < cdecker> But yes, we don't decompose before writing it out 14:41 < niftynei> c-lightning caches the entire gossip message (i believe) 14:41 < niftynei> this definitely explains my confusion about why it's necessary to specify tho :) 14:41 < cdecker> (allows us to just not do a lot of reconstructing of packages) 14:41 < cdecker> And we use the same to reload the gossip upon restart 14:41 < cdecker> Safes loads of code :-) 14:41 < bitconner> interesting 14:42 < cdecker> Anyway, we should stick to canonical formats whenever possible 14:42 < niftynei> fwiw i have a preference for x00 as the EOF marker, over xFF 14:43 < bitconner> lnd reads the bytes into one of n buffers from a buffer pool and deserializes the message, then discards the bytes 14:43 < bitconner> cdecker, agreed 14:43 < bitconner> niftynei, why's that? then it's not sorted :) 14:44 -!- hiroki__ [d295ff1d@gateway/web/freenode/ip.210.149.255.29] has quit [Ping timeout: 256 seconds] 14:45 < niftynei> but that means something else will have the 0x00 type and 0x00 is neither even nor odd 14:45 < cdecker> 0x00 is a type 0 in both varint TLV and non-varint TLV types, wheres 0xFF would be different :-) 14:46 < bitconner> 0x00 is even? 14:47 < bitconner> cdecker, indeed it only makes sense for fixed-size namespace :) 14:47 < bitconner> with a varint type, zero is the only real option i think 14:49 < bitconner> if the even/odd rule is used, then 0x00 would just be another required type 14:49 < niftynei> oh i see, is the type field a varint in #607? (sorry haven't finished reading it yet) 14:49 < bitconner> no worries, in 607 it's just 1 byte 14:50 < bitconner> 607 uses 1-byte type, 2-byte length 14:50 < cdecker> I'm a bit confused why we're trying to minimize the type length in messages where we actually have 65k bytes available 14:51 < bitconner> the rationale previously was that 1 byte should be sufficient, because by the time we add 254 optional fields we should just make a new message altogether 14:51 < cdecker> I'd expect almost all of the spec-defined types to be in the 0-252 range (so we don't lose space there) but self-assigned stuff could use > 252 types 14:52 < bitconner> cdecker, we can also nest TLV :) 14:52 < niftynei> noooooo 14:52 < bitconner> if we have a sentinel value 14:52 < cdecker> Don't need a sentinel value 14:53 < bitconner> how does one concatenate tlv streams w/o one _and_ enforce canonical ordering? 14:53 < cdecker> You'd have a field of type TLV, which has a key TLV and the length of the nested field is basically the entire payload of the nested TLV 14:53 < niftynei> i'm strongly in favor of only allowing 1-TLV per message type 14:53 < bitconner> cdecker, ah yes good point :) 14:53 < cdecker> So we have one top-level TLV, each field in the TLV may be a TLV, and the boundary of the nested TLV is given by the outer length 14:53 < niftynei> you don't concatenate them, you add more types? 14:54 < cdecker> So sentinel isn't needed I think? 14:54 < bitconner> yeah the sentinel value has marginal utility imo 14:55 < bitconner> the only other thing i can see it useful for is as a sanity check 14:55 < bitconner> so the receiver can tell that all intended fields were serialized 14:56 < niftynei> isn't that what the length check is for? 14:56 < niftynei> like before the TLV there's a length 14:56 < bitconner> the message-level length? 14:57 < niftynei> the version of TLV that i coded up for c-lightning specifies a varint length then TLV payload 14:58 < bitconner> ah okay, is that in the spec proposal? maybe i missed it 14:58 < bitconner> i was trying to avoid having an explicit length, since it requires serializing computing the length of all fields in advance instead of just writing them 14:58 < bitconner> serializing/computing* 15:00 < cdecker> Wouldn't that be required for nested TLVs anyway? 15:00 < cdecker> This might be a case where we prefer to just reuse code that we're already writing for nesting 15:01 < cdecker> afaik there is no minimality requirement for the outer length, so you can just make it 2 bytes if you're unsure 15:01 < cdecker> :-) 15:01 -!- sstone [~sstone___@185.186.24.109.rev.sfr.net] has quit [Read error: Connection reset by peer] 15:01 < cdecker> Oh, wait, that goes against the canonicalization argument, nvm 15:01 < niftynei> oh not sure if it's in the proposal i'll check 15:02 < bitconner> yes that's true, it would be needed for nesting 15:03 < bitconner> i pray that nesting is something we have to do in practice though :) 15:03 < cdecker> I hope there's a "not" missing there 15:04 < niftynei> i think you missed a don't 15:04 < bitconner> hahahaha 15:04 < bitconner> i did indeed 15:04 -!- t-bast [~t-bast@2a01:e34:ec2c:260:5109:2ad0:54db:b559] has quit [Quit: Leaving] 15:04 < cdecker> You know... you can encode arbitrary information in the form of nesting, so we might just do that :-) 15:05 < bitconner> we should signal the bits of the message we're trying to encode by setting bit i to 1 iff type i is nested 15:05 < bitconner> :) 15:05 < cdecker> {{{}}} = 3 :-) 15:06 < bitconner> looks... lispy 15:06 < cdecker> e-lisp, I'm an emacs user :-) 15:06 < bitconner> another thing that came up when i was working on the PoC, was whether or not to use varbytes encoding for variable length byte slices 15:07 < niftynei> do we serialize the entire message length anywhere? 15:07 < cdecker> Next time we just encode our messages as simplicity contracts, that'd make roconnor happy :-) 15:07 < bitconner> and make disconner very sad 15:07 * cdecker applauds 15:07 < niftynei> loooool 15:08 < bitconner> public nope() {} 15:09 < bitconner> niftynei, apart from the message headers? 15:09 < niftynei> yeah, i'm assuming that at the packet level we send a len field... 15:10 < bitconner> indeed we do :) 15:11 < niftynei> kkk 15:12 < bitconner> was hoping the final TLV proposal would be general enough to also be used for purposes outside of those that assume the length to be already serialized tho 15:13 < niftynei> cool. ok i'll take a look at the rest of it. 15:13 < niftynei> it -> your PR 15:13 < bitconner> either really 15:15 < bitconner> but mainly that the sentinel value allows those extra use cases 15:15 < bitconner> but if it's not needed in either the wire or the onion, then maybe it's best to leave that outside of the spec 15:15 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 15:19 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev 15:19 < bitconner> niftynei cdecker, thanks for sticking aroudn to chat about TLV proposals, sounds like we've made some good progress :) 15:19 < bitconner> when rusty is back online we can also discuss some more 15:47 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 15:52 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 16:05 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 245 seconds] 16:06 -!- afk11 [afk11@gateway/vpn/privateinternetaccess/afk11] has joined #lightning-dev 16:14 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 16:33 -!- shesek [~shesek@5.22.134.182] has joined #lightning-dev 16:33 -!- shesek [~shesek@5.22.134.182] has quit [Changing host] 16:33 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 16:51 -!- afk11 [afk11@gateway/vpn/privateinternetaccess/afk11] has quit [Ping timeout: 268 seconds] 17:06 -!- afk11 [~afk11@unaffiliated/afk11] has joined #lightning-dev 17:56 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 18:03 -!- riclas [~riclas@148.63.37.111] has quit [Ping timeout: 246 seconds] 18:28 -!- unixb0y [~unixb0y@p5B029368.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 18:30 -!- unixb0y [~unixb0y@p5B02917A.dip0.t-ipconnect.de] has joined #lightning-dev 18:56 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 18:59 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 19:30 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Ping timeout: 245 seconds] 20:20 -!- eihli [~eihli@c-73-92-230-247.hsd1.ca.comcast.net] has joined #lightning-dev 20:36 -!- scoop [~scoop@rrcs-208-105-57-183.nyc.biz.rr.com] has joined #lightning-dev 21:29 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 246 seconds] 21:57 -!- Joe___ [d826964a@gateway/web/freenode/ip.216.38.150.74] has quit [Ping timeout: 256 seconds] 22:21 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Remote host closed the connection] 22:22 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev 22:39 -!- ccdle12 [~ccdle12@110.50.135.242] has joined #lightning-dev 22:41 -!- ccdle12 [~ccdle12@110.50.135.242] has quit [Remote host closed the connection] 23:04 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #lightning-dev 23:20 -!- Fluidjax [~textual@37.120.137.166] has quit [Ping timeout: 246 seconds] 23:32 -!- scoop [~scoop@rrcs-208-105-57-183.nyc.biz.rr.com] has quit [Remote host closed the connection] 23:45 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds] 23:46 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has quit [Ping timeout: 268 seconds] 23:48 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 268 seconds] 23:49 -!- scoop [~scoop@rrcs-208-105-57-183.nyc.biz.rr.com] has joined #lightning-dev 23:53 -!- scoop [~scoop@rrcs-208-105-57-183.nyc.biz.rr.com] has quit [Ping timeout: 246 seconds] --- Log closed Tue May 14 00:00:12 2019