--- Log opened Mon Jan 06 00:00:58 2020
00:08 -!- marcoagner [~user@dsl-54-248.bl26.telepac.pt] has joined #lightning-dev
00:31 -!- m-schmoock [~will@schmoock.net] has joined #lightning-dev
01:37 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
01:41 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
01:51 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
02:06 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
02:13 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev
02:42 -!- nobody123 [~nobody123@92.223.89.60] has joined #lightning-dev
02:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
03:11 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 265 seconds]
03:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
03:24 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev
03:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
03:43 -!- Jmabsd [~jmabsd@unaffiliated/jmabsd] has joined #lightning-dev
03:44 < Jmabsd> Wait what's the function of the OP_CHECKSEQUENCEVERIFY in the Lightning templates (i.e. BOLT 3)?  I saw the BIP for OP_CSV and I don't see the obviouspoint 
04:05 -!- Jmabsd2 [~jmabsd@180.131.165.45] has joined #lightning-dev
04:07 -!- Jmabsd2 [~jmabsd@180.131.165.45] has quit [Client Quit]
04:08 -!- phwalkr [~phwalkr@2001:1284:f01c:48a1:9c86:9dc6:6bd3:deea] has joined #lightning-dev
04:08 -!- Jmabsd [~jmabsd@unaffiliated/jmabsd] has quit [Ping timeout: 240 seconds]
04:09 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
04:12 -!- phwalkr [~phwalkr@2001:1284:f01c:48a1:9c86:9dc6:6bd3:deea] has quit [Ping timeout: 248 seconds]
04:25 -!- nirved [~nirved@2a02:8071:b58a:3c00:3ca6:9fb9:2e23:4e12] has quit [Ping timeout: 252 seconds]
04:27 -!- nirved [~nirved@2a02:8071:b58a:3c00:101a:1e6:1c2a:1acb] has joined #lightning-dev
04:35 -!- rdymac [uid31665@gateway/web/irccloud.com/x-msgkvvajkynpyken] has joined #lightning-dev
04:35 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
04:43 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
04:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
04:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
04:52 -!- fergaloc1998 [6d4dcce9@109.77.204.233] has joined #lightning-dev
04:55 < fergaloc1998> Hey - just wondering if a payment fails (outward direction) due to a party not having enough funds - does everyone (up until that point) need to wait until the HTLCs time out to release their funds or can the payment be "cancelled"?
04:56 -!- Jmabsd [~jmabsd@unaffiliated/jmabsd] has joined #lightning-dev
05:00 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
05:02 < cdecker> No, they can tear down all the HTLCs in reverse order since the node that can't forfeit offers a cancel knowing it can't forward
05:03 < cdecker> This cancellation then just telescopes back to the origin of the payment
05:03 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
05:04 < fergaloc1998> Okay, thanks! And if it gets to the end and the preimage is being propagated back to say C, and B suddenly goes offline - does C close its channel with B after a while to be safe?
05:28 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]
05:51 -!- AbramAde_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
05:53 -!- AbramAdelmo_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Ping timeout: 260 seconds]
06:11 -!- vasild_ is now known as vasild
06:21 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
06:21 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
06:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
06:26 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
06:28 -!- nobody123 [~nobody123@92.223.89.60] has quit [Remote host closed the connection]
06:39 -!- Jmabsd [~jmabsd@unaffiliated/jmabsd] has quit [Ping timeout: 260 seconds]
06:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
06:45 -!- Jmabsd [~jmabsd@14-0-153-126.static.pccw-hkt.com] has joined #lightning-dev
06:46 -!- molly [~molly@unaffiliated/molly] has joined #lightning-dev
06:55 -!- rdymac [uid31665@gateway/web/irccloud.com/x-msgkvvajkynpyken] has quit [Quit: Connection closed for inactivity]
06:57 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
07:03 -!- Jmabsd [~jmabsd@14-0-153-126.static.pccw-hkt.com] has quit [Read error: Connection reset by peer]
07:10 < cdecker> fergaloc1998: C would wait for B to come back. If B doesn't come back in time to clear collaboratively (HTLC timeout is about to expire) then C will close and claim on-chain instead
07:12 < fergaloc1998> Okay cool thats what I thought - thanks for your help!
07:14 < cdecker> Anytime ^^
07:21 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
07:33 -!- molly [~molly@unaffiliated/molly] has quit [Quit: Leaving]
07:34 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
--- Log closed Mon Jan 06 07:55:11 2020
--- Log opened Mon Jan 06 07:55:11 2020
08:02 -!- cubancorona2 [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has quit [Quit: Leaving]
08:18 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
08:31 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
08:53 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
08:53 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
09:10 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
09:11 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #lightning-dev
09:16 -!- fergaloc1998 [6d4dcce9@109.77.204.233] has left #lightning-dev []
09:43 -!- joncoe1 [joncoe@gateway/vpn/protonvpn/joncoe] has joined #lightning-dev
09:46 -!- joncoe1 [joncoe@gateway/vpn/protonvpn/joncoe] has quit [Client Quit]
09:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
09:50 < cdecker> @here: I might be a bit late for the spec meeting, but I'll join asap
09:55 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
10:05 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
10:17 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
10:18 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
10:36 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
10:38 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
10:47 -!- cdecker_ [~cdecker@178.197.225.195] has joined #lightning-dev
10:47 -!- arij [uid225068@gateway/web/irccloud.com/x-uebkkqiuirhunfjo] has joined #lightning-dev
10:48 -!- t-bast [~t-bast@2a01:e34:ec2c:260:cdee:4a11:f946:edd2] has joined #lightning-dev
10:48 -!- cdecker_ [~cdecker@178.197.225.195] has quit [Client Quit]
10:50 -!- cdecker2 [~cdecker2@178.197.225.195] has joined #lightning-dev
10:50 -!- cdecker2 [~cdecker2@178.197.225.195] has quit [Client Quit]
10:50 -!- cdecker2 [~cdecker2@178.197.225.195] has joined #lightning-dev
10:52 -!- cdecker2 [~cdecker2@178.197.225.195] has quit [Read error: Connection reset by peer]
10:53 -!- cdecker2 [~cdecker2@178.197.225.195] has joined #lightning-dev
10:55 -!- cdecker2 [~cdecker2@178.197.225.195] has quit [Read error: Connection reset by peer]
10:56 -!- cdecker2 [~cdecker2@178.197.225.195] has joined #lightning-dev
11:00 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
11:01 < t-bast> hey everyone, do we have a meeting tonight or are folks on vacation?
11:02 < BlueMatt> its jan 6, who's still on vacation?!
11:02 < t-bast> yeah who takes vacations anyway?
11:02 < t-bast> if even the french are working, everyone should be
11:03 < BlueMatt> oof
11:04 < niftynei> hello
11:05 < t-bast> hey niftynei!
11:05 < niftynei> rusty's out of town this week, but he's expected back in time for our next meeting
11:05 < niftynei> (speaking of vacationers :) 
11:05 < t-bast> thanks, good to know ;)
11:05 < BlueMatt> I dont think "running from a fire" counts as vacation
11:05 < niftynei> it seems cdecker should be joining us shortly
11:06 < t-bast> BlueMatt: xD
11:06 < t-bast> good, anyone from lightning labs around?
11:06 < sstone> hi eveyrone!
11:07 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
11:09 -!- cdecker2 [~cdecker2@178.197.225.195] has quit [Read error: Connection reset by peer]
11:09 < ariard> hi
11:09  * t-bast waves at ariard
11:12 < t-bast> It seems that apart from anchor outputs, we mostly have many small clean-up PRs pending - would be nice to finalize those
11:13 < cdecker> Hi guys and gals :-)
11:14 < t-bast> Hey cdecker!
11:14 < cdecker> Sorry for being late, but I was following along in the logs :-)
11:14 <+roasbeef> oy
11:14 < t-bast> No problem :), who wants to do the honors and chair?
11:14 < t-bast> hey roasbeef!
11:18 < t-bast> Allright, I'll take the lead then if no-one wants to ;)
11:18 < t-bast> #startmeeting
11:18 < lightningbot> Meeting started Mon Jan  6 19:18:37 2020 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:18 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:18 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/719
11:19 < t-bast> This is a PR to clarify dependencies between features
11:19 < cdecker> #info Happy new year 2020, the year of the Lightening :-)
11:19 < t-bast> It also caught the fact that we left out var_onion_option from the dependencies of most new features 
11:20 <+roasbeef> t-bast: some ppl had issues scanning invoices made by pheonix from lnd 
11:20 <+roasbeef> iirc it was that they didn't specify the new onion format, but specified mpp 
11:20 < t-bast> roasbeef: yep because we didn't include the var_onion_option bit because the spec explicitly left it out
11:20 < t-bast> currently the spec said that it was a feature bit that we could not put in invoices
11:20 < t-bast> we should fix the spec, which both conner and bluematt did in their PRs :)
11:21 < t-bast> BTW is lnd ready for complete compat' testing of MPP?
11:21 <+roasbeef> yep master can recv, 0.9 (coming soon) will be able to recv as well 
11:21 <+roasbeef> you can send on teh RPC level, but only with multuiple nodes paying a single invoice, so like crowd funding style 
11:22 < t-bast> great, I'll start doing some tests against master this week then!
11:22 < joostjgr> hi all
11:22 < t-bast> hi Joost
11:22 < joostjgr> what we can't do is sending multiple parts from a single node
11:22 < t-bast> good to know, thanks, I'll make sure I used two nodes
11:22 < joostjgr> it is possible to send multiple parts, but 'crowd sourced' from multiple instances
11:22 <+roasbeef> so let's roll in #723 into #719? 
11:23 < t-bast> #723 has another point about feature handling, but we can definitely merge those two if we ACK them all
11:23 < BlueMatt> fine by me. if you just take the second commit the first comit is redundant with 719
11:23 < t-bast> #719 needs an ACK from cdecker or niftynei
11:23 < t-bast> #723 needs an ack from someone LL-side
11:24 < t-bast> BlueMatt or ariard, do you have comments on #719?
11:24 < cdecker> I think we are already compliant with #719
11:24 < BlueMatt> 719 lgtm
11:25 < BlueMatt> cdecker: well you also have to reject on the receive side....like, reject the message
11:25 < BlueMatt> and disconnect them
11:25 < BlueMatt> actually, 719 should specify what you should do
11:25 < BlueMatt> it just says "MUST validate" but that doesnt mean anything
11:26 < t-bast> actually on #719 it seems like conner made a mistake, and added `9` to `gossip_queries` instead of `var_onion_optin`
11:26 < cdecker> Yes, I don't see any prescribed action for recipients in there
11:27 < cdecker> You're right t-bast allowing gossip signalling in the invoice is not correct imho
11:27 < BlueMatt> alright, so 719 clearly needs work, lets boot conversation to github.
11:27 < t-bast> Then let's let conner fix that and add some requirements
11:27 < t-bast> Let's move to 723 which we can probably merge
11:28 < t-bast> #action Fix a few comments on #719 before merge
11:28 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/723
11:28 < ariard> a strict definition of transitive feature dependency could be laid out before the "MUST set all transitive feature dependencies" tho
11:29 <+roasbeef> ariard: #719 attempts to do that 
11:29 < niftynei> 723 lgtm, other than the fact that "should in general override" is too weak of language imo
11:29 < BlueMatt> niftynei: that's a non-normative note for future spec changes
11:29 < BlueMatt> hence it being in the "Rationale" section.
11:30 < ariard> roasbeef: that just a nit for clarity but #719 tells you what are actual dependencies but not formal definition
11:30 < niftynei> i get that, i'm in favor of making it stricter and letting future spec revisions relax it, rather than hedging in the present
11:30 < cdecker> btw I'm removing the meeting discussion tags as we address them, so the issues don't accumulate over time
11:31 < BlueMatt> niftynei: hm? it being in the Rationale section is a note *for us* for future changes. not for implementors
11:31 <+roasbeef> ariard: def of transitive deps? what's the advantage over just enumerating them all?
11:31 < t-bast> cdecker: thanks!
11:31 < BlueMatt> ie "in the future, as spec changes are made, keep in mind that you should probably let node_annoucement be overridden by invoices, but also as an implementor note that this is likely to be how things work, so keep that in mind"
11:31 <+roasbeef> cdecker: well some get discussed, then just sit aroudn, so they should retain the label until things are either "dropped" or they move forward 
11:32 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
11:32 < BlueMatt> Rationale is not the place to put "strict" things, cause they have no strict meaning
11:33 < cdecker> roasbeef: I think of the tag as "to be discussed in the next meeting", so auto-adding them to the meeting list is probably not the desired effect, i.e., if the required changes have not been done, we just lose time asserting that the problem persists :-)
11:33 < niftynei> right, my preference is that the rationale is more opinionated, which you can do by removing the 'in general' :P
11:33 < ariard> roasbeef: bolt clarity but nevermind
11:34 < niftynei> the 'in general' makes me think that you've already got an exempting case in mind or that exists, which afaik is not the case
11:34 < cdecker> Either make the point weaker ("notice that contradictions may arise") or make it normative
11:34 < BlueMatt> ok, done, removed "in general"
11:35 < niftynei> awesome. thanks
11:35 < cdecker> SGTM
11:35 < t-bast> ACK
11:35 < t-bast> roasbeef, joost, you ok with merging #723?
11:36 <+roasbeef> would want to check it out in detail first, and also give conner a chance to look over it since he's been doing a lot of feature bit clean up in lnd lately 
11:36 < BlueMatt> roasbeef: its like 100 chars different, you can read it quick :p
11:36 < t-bast> It's quite a small one honestly
11:36 <+roasbeef> i think we already use the onion bit in the invoice 
11:36 < BlueMatt> t-bast: last I heard we only require two implementation acks to merge something anyway :p
11:37 < t-bast> Heh ;)
11:37 < cdecker> Well, there's no hurry is there? We can count ACKs on the issue, so why not let Conner weigh in?
11:38 < BlueMatt> cdecker: cause we have a ton of tiny trivial changes piling up, waiting for an ack from someone who proposed the same change in another pr........
11:38 < BlueMatt> whatever.
11:38 < t-bast> SGTM, let's merge this once conner acks
11:38 < t-bast> #action ping conner for ACK then merge
11:39 < t-bast> I agree with BlueMatt though that overall those small PRs aren't looked at and pile up. I think we could do a better job at reviewing them outside of the meetings to speed up the meeting itself...
11:39 < cdecker> Definitely, I know I could do a better job working through the tiny/uncontroversial stuff before the meeting
11:40 < t-bast> Let's move to two issues that a bit of discussion
11:40 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/issues/721
11:40 < t-bast> This is a remark on a potential attack on MPP that's not explicitly handled by the spec
11:41 < t-bast> I think we could fix this with a small spec change, are implementations vulnerable to that today?
11:41 < cdecker> imho this is pure receiver policy and shouldn't normative
11:42 < t-bast> but at least we should mention it then, otherwise the receiver can simply lose everything because the implementer hadn't thought about that attack
11:42 < cdecker> You can also steer this pretty easily through the number of channels you publicize (multiple tiny htlcs on a single channel aggregate, unless the attacker happens to peer directly with the recipient).
11:42 <+roasbeef> it's also related to the min htlc value on the final channel 
11:43 < BlueMatt> right, this can be handled with a min htlc value/max_htlcs_in_flight
11:43 <+roasbeef> if you set that high enough, they you guard against this as the sender shouldn't route a payment too s mall, and the penultimiate node should reject and not forward on the outgoing channel 
11:43 < BlueMatt> ultimately its the same risk number
11:43 < t-bast> It's true that it's mostly an issue for big nodes with many channels
11:43 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
11:44 < BlueMatt> if you're running a big node taking lots of payments, the risk from a number of payments is the same as the risk from one payment across a number of MPPs
11:44 < BlueMatt> err MPs
11:44 < t-bast> IIUC your overall feeling is that this isn't a big concern in practice?
11:45 < BlueMatt> now I wouldnt object to, eg, MPP may be paid with no more than 128 HTLCs, but its not due to this attack, more a general nice thing
11:45 <+roasbeef> t-bast: it can be mitigated by properly setting the minhtlc value in the channel policy, may be nice to make it more explicit in like a best practices section 
11:45 < BlueMatt> this *is* a concern, but it has nothing to do with MPP, and is exactly why max_htlcs_in_flight and htlc_minium_msat exist.
11:45 < niftynei> yeah this is a specific case of a general problem, i think what roasbeef is saying about the minhtlc value makes sense
11:46 < cdecker> Yep, same here
11:46 < BlueMatt> sounds like we're all on the same page, yea.
11:46 < t-bast> gotcha
11:46 < cdecker> We need to be careful not to overload the spec with too many details that are just special cases of what we already handle imho
11:46 < BlueMatt> somewhat tangentially, it may make sense to have a general limit just to, eg, restrict things to sanity
11:46 < t-bast> let's move on then, I'll summarize those points on the issue for reference
11:47 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/issues/724
11:47 < BlueMatt> eg 128 chunks, but thats mostly cause like more than that is obviously someone doing something stupid (or over-wumbo-ing pre-wumbo)
11:48 < t-bast> I noticed that c-lightning changed its behavior to more aggressively re-send its node_announcement to work around what sstone describes in this issue
11:48 -!- michaelfolkson [~textual@host-92-3-210-254.as43234.net] has joined #lightning-dev
11:48 <+roasbeef> t-bast: fwiw we're skipping over things that are marked as meeting discussion and adding things that weren't tagged label wise 
11:48 <+roasbeef> but yeh this is relevant, node ann's don't propagate super well rn 
11:48 <+roasbeef> seems this is solved by reviving the inv proposal 
11:48 <+roasbeef> which would need a way to fetch a node ann in isolation 
11:48 < t-bast> roasbeef: is there something specific you want to discuss? It feels to me that apart from anchor outputs which hasn't changed, we only have small PRs that are all waiting review that can be done outside of the meeting...
11:49 < t-bast> That's not necessarily very easy to do with INV either...
11:49 < t-bast> Long term may be using minisketch to reconcile node_announcements
11:49 <+roasbeef> t-bast: no nothing in particular, just ref'ing that 
11:49 <+roasbeef> t-bast: why isn't it easy to do with an inv? 
11:50 <+roasbeef> you don't want _all_ the node anns, only those that you may care about or frequently use also 
11:50 < sstone> roasbeef: I don't think that node inv will let you quickly reconcile your node anns
11:50 < t-bast> Mostly because INV is more work than enriching the existing queries, so it would need to add more to be really meaningful IMO
11:50 <+roasbeef> sstone: it depends on what the goal is 
11:50 <+roasbeef> do you want 100% up to date node anns at all time, or do you want to be able to get the node anns you care about 
11:51 < sstone> roasbeef: the goal is to be able to quickly learn about new/updated node anns, possible with feature and/or timestamp based filters
11:51 < sstone> possibly
11:52 < sstone> I see INV as a way to reduce broadcast bandwidth, but we still need queries
11:52 <+roasbeef> feature filter seems desirable
11:53 <+roasbeef> yeh the inv would add a way to query for the node ann, otherwise it's only half operational 
11:53  * BlueMatt -> meeting, see y'all.
11:53 <+roasbeef> lack of propagation of node anns also seems to have been exacerbated by some impls no longer asking for any sort of gossip backlog when connecting 
11:54 < cdecker> See you BlueMatt :-)
11:55 < t-bast> Do you feel working on a broader INV proposal that encompasses this is something we should do now? Or should we work on extending the existing queries to help node_ann propagation and implement some filters? What's the general feeling on the most urgent work needed on gossip right now?
11:55  * t-bast waves at BlueMatt
11:55 <+roasbeef> sstone: the extended query stuff doesn't cover this as is today? or I guess it would be an avenue to address this?
11:55 < t-bast> we could extend the existing extended queries to add node_announcement and filters
11:56 < t-bast> if people feel that it's useful we can work on that
11:56 < sstone> roasbeef: not well. you can ask for node anns but it's the same issue as with chan. updates: we need additional info such as timestamps
11:56 < t-bast> we'll call them super-extended-queries
11:56 <+roasbeef> in the past I wasn't a huge fan of the checksum approach in the extended queries, which is why I mostly stopped commenting on it, lack of granularity meant that you shoudl be forced to always fetch in case of a change of which you may not have cared about 
11:57 < niftynei> it seems that there's a general case about being able to query for 'newer gossip' via timestamps?
11:58 < sstone> niftynei: yes. we can already do that for updates but not node anns because it was not needed until now
11:58 <+roasbeef> there's that, then also possibly being able to filter based on feature bits 
11:58 <+roasbeef> main thing is that node anns weren't very important til we started to actually use the global feature bits namespace 
11:58 < ariard> did anyone explore using minisketch with multiple reconciliation sets per-feature or object of interest?
11:58 < niftynei> yep, that sounds about right
11:58 < niftynei> i know rusty  has been working on a minisketch compaction/filter for gossip
11:59 <+roasbeef> ariard: i think rusty looked into basic integration, but idk feels like too big of a hammer for this simple case 
11:59 < t-bast> ariard: we had an intern working on that for a few months, and I know rusty has been doing some experimentation too - but I think it's a longer term solution, we'll need something before
11:59 < niftynei> (i might be using the wrong term here, i'm not totally clear on what minisketch is composed of)
12:00 < t-bast> it's not trivial to correctly use minisketch for lightning - done naively it ends up being worse than IBLT
12:00 < t-bast> definitely doable, but more long-term
12:00 < ariard> okay good to know, well I'm following how it's going to be deployed on the base layer and learn from that before going further
12:00 < t-bast> great we'll learn a lot from that
12:01 < niftynei> it sounds like a extending query extensions is a reasonable move
12:01 <+roasbeef> yeh we don't need to use every new shiny hammer just because it exists or was produced for other use cases 
12:01 < t-bast> My proposal is that we could start drafting something to add filters to queries and node_announcement capabilities
12:01 <+roasbeef> yeh seems so, iirc there's a PR that half way adds node anns to them? or maybe was just a todo left over 
12:01 < t-bast> sstone and I will work on that for next meeting, how does that sound?
12:01 < ariard> right right, but having already a minisketch production library is cool too
12:01 < niftynei> sounds great t-bast
12:02 < t-bast> roasbeef: there's already *some* node_anns capabilities, but not enough :)
12:02 <+roasbeef> t-bast: could be good to maybe first to an ML post to state the goals of w/e the new additions would be, and greater context in the network, etc 
12:02 < sstone> sgtm. you can already query node anns but it useful only for channels you had not seen yet
12:02 <+roasbeef> what's missin is feature bit filtering?
12:03 < t-bast> roasbeef: good idea, we'll start with the mailing list
12:03 < t-bast> not only, right now you can't know if a node_ann has changed compared to what you have
12:03 < t-bast> we need to use checksum or something else
12:03 <+roasbeef> gotcha, it just comes along with w/e other chanenls you were asking for 
12:03 -!- fox2p [~fox2p@185.212.170.51] has joined #lightning-dev
12:03 < t-bast> exactly you can opt-in to receive the node_ann with the channel_udpate
12:04 <+roasbeef> how do y'all handle reconcilling the feature bits inteh invoice w/ the node ann in practice today? 
12:04 < t-bast> but right now you'd have to refetch it even if it hasn't changed
12:04 <+roasbeef> like if they're conflicting somehow 
12:04 <+roasbeef> example being the node ann of the dest doesn't signal var onion, but the invoice doe 
12:04 < t-bast> for your own feature bits or when reading some else's?
12:04 <+roasbeef> s
12:04 < t-bast> ok, when paying invoice takes precedence
12:04 <+roasbeef> so you're about to send out, and need to know how to pack the onion  
12:05 <+roasbeef> gotcha, I think we do the same 
12:05 < t-bast> #action sstone and t-bast to post to the mailing list and work on a draft PR before next meeting
12:05 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/697
12:05 < t-bast> It looks like we still haven't merged that sphinx fix :)
12:06 < t-bast> is it already in lnd and c-lightning's master branches?
12:06 <+roasbeef> yeh have been meaning to get around to it 
12:06 <+roasbeef> i think CL has merged a fix, but we haven't 
12:06 < cdecker> It is in c-lightning, but I haven't validated the new test vectors yet
12:06 <+roasbeef> final thing was if we shoudl jsut use random bytes, or try to extract more bytes from teh existing csprng key stream 
12:06 < t-bast> yep, I quite like the deterministic approach proposed by cdecker, that's what I currently implemented
12:07 < t-bast> but I don't feel very strongly about that
12:07 <+roasbeef> have been meaning to update to juse use a new key, as the test vectors then can be deterministic 
12:07 < cdecker> Yeah, the only advantage is the test-vectors are reproducible afaik
12:07 <+roasbeef> sgtm, I'll update the spec PR 
12:07 <+roasbeef> and then can re-gen the test vectors 
12:07 < t-bast> I think that's useful for new implementers/newcomers
12:08 < t-bast> great thanks!
12:08 <+roasbeef> yeh one less thing to have to make a decision w.r.t 
12:08 < t-bast> #action roasbeef update PR to use deterministic derivation
12:08 -!- fox2p [~fox2p@185.212.170.51] has quit [Ping timeout: 260 seconds]
12:08 < t-bast> Is there a specific PR you'd like to do next? Or should we stop there?
12:09 < t-bast> It would be awesome if everyone could have a quick look outside of the meeting at the PRs marked "discuss at next meeting", most of them can be handled on Github directly to save time
12:10 < cdecker> I need to drop off, got some more reviews for a conference to do and the deadline's approaching ^^
12:11  * cdecker waves
12:11 < t-bast> cdecker: is that for CES?
12:13 <+roasbeef> #672 can land, it needs to be rebased tho 
12:14 <+roasbeef> i think rusty is out for another meeting or two, so i'll just resolve the conflict and psuh it out 
12:14 -!- michaelfolkson [~textual@host-92-3-210-254.as43234.net] has quit [Quit: Sleep mode]
12:14 <+roasbeef> t-bast: was the issue w/ CL and elcair resolved in #682? the chain innit msgs 
12:14 < t-bast> thanks roasbeef, sgtm
12:15 < t-bast> re #682 CL has fixed that indeed, so it should be good to go too
12:15 < cdecker> t-bast: yes
12:16 < t-bast> cdecker: I'll very likely attend, see you there! Good luck with the reviews
12:16 < cdecker> I'll not be able to attend myself, just doing the work, not getting the upside xD
12:17 < t-bast> heh ;)
12:17 < t-bast> roasbeef: re 682 do you know if conner or you ack-ed it?
12:18 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has joined #lightning-dev
12:20 -!- sennn [~tobiasmcf@253.192.220.35.bc.googleusercontent.com] has joined #lightning-dev
12:22 < niftynei> i know we're out of time, but would there be any interest in putting together a small working group for going through 'non-active feature' PR changes? small things like https://github.com/lightningnetwork/lightning-rfc/pull/703/files that are clarification and grammar related
12:23 < niftynei> i really like talking grammatical and symmantic minutiae but this meeting doesn't seem like a great forum for those kinds of discussions
12:23 <+roasbeef> niftynei: I commented on that one, but the OP never replied, current guidelines for like typo/grammar stuff is a main champion for sanity checks 
12:24 <+roasbeef> t-bast: don't think so, we haven't implemented it either, but at a glance looks mostly good to me 
12:24 < t-bast> niftynei: I agree, I think we should look at those on Github and use the "spelling" label
12:24 < t-bast> regarding 703 specifically I think this clarification isn't needed and bloats the spec a bit
12:25 < niftynei> agreed. this seems like something you might write in a blog post or 3rd party explainer doc
12:27 < t-bast> roasbeef: cool, we can merge it if you want or keep it like this if you plan to implement it soon-ish
12:27 < t-bast> roasbeef: let me know what you prefer
12:30 < niftynei> "spelling" doesn't seem like exactly the right label for some of them; in some cases it is a subtantive addition or change but won't have an impact on current implementations
12:31 < t-bast> true, in that case I think it's worth a brief mention at meeting and review from different people. But I agree it feels like it wastes some meeting time, we should strive to keep it short but that's hard :)
12:32 < niftynei> right, it feels like something that needs attention but ultimately would require more time, so another dedicated time to go through them seemed like not a bad idea
12:33 < niftynei> anyway, just an idea. ok, i need to go find some lunch
12:34 < niftynei> are we wrapping up shortly?
12:34 < t-bast> yes, I'm heading off too, let's stop there
12:34 < t-bast> #stopmeeting
12:34 < t-bast> #endmeeting
12:34 < lightningbot> Meeting ended Mon Jan  6 20:34:33 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:34 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-01-06-19.18.html
12:34 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-01-06-19.18.txt
12:34 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-01-06-19.18.log.html
12:34 < t-bast> Thanks all, please do some Github reviews (thanks niftynei for the ones you just did)!
12:37 -!- t-bast [~t-bast@2a01:e34:ec2c:260:cdee:4a11:f946:edd2] has quit [Quit: Leaving]
12:38 < niftynei> kk. i made a new label "clarification" to make it a bit easier to sort spec PRs by intent 
12:57 -!- designwish [~designwis@51.ip-51-68-136.eu] has quit [Quit: ZNC - https://znc.in]
13:08 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
13:09 -!- designwish [~designwis@2001:41d0:601:1100::2bda] has joined #lightning-dev
13:17 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
13:20 -!- cdecker2 [~cdecker2@217.22.138.202] has joined #lightning-dev
13:20 -!- cdecker2 [~cdecker2@217.22.138.202] has quit [Read error: Connection reset by peer]
13:20 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
13:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
13:42 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
13:49 -!- AbramAde_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Read error: Connection reset by peer]
13:49 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
13:50 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
13:51 -!- cdecker2 [~cdecker2@217.22.138.202] has joined #lightning-dev
13:53 -!- cdecker2 [~cdecker2@217.22.138.202] has quit [Read error: Connection reset by peer]
14:03 -!- designwish [~designwis@2001:41d0:601:1100::2bda] has quit [Quit: ZNC - https://znc.in]
14:14 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
14:18 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
14:32 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving]
14:55 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
15:17 -!- nobody123 [~nobody123@92.223.89.60] has joined #lightning-dev
15:21 -!- nobody12_ [~nobody123@92.223.89.60] has joined #lightning-dev
15:21 -!- nobody123 [~nobody123@92.223.89.60] has quit [Read error: Connection reset by peer]
15:52 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:56 -!- nobody12_ [~nobody123@92.223.89.60] has quit [Remote host closed the connection]
16:10 -!- marcoagner [~user@dsl-54-248.bl26.telepac.pt] has quit [Ping timeout: 258 seconds]
16:33 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
16:35 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
17:50 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
18:02 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Remote host closed the connection]
18:10 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
18:11 -!- AbramAdelmo_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
18:12 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Read error: Connection reset by peer]
18:13 -!- AbramAdelmo_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Remote host closed the connection]
18:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
18:46 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
18:55 -!- sennn [~tobiasmcf@253.192.220.35.bc.googleusercontent.com] has quit [Quit: Leaving]
18:55 -!- sennn [~chapsui@253.192.220.35.bc.googleusercontent.com] has joined #lightning-dev
19:18 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev
20:09 -!- sennn [~chapsui@253.192.220.35.bc.googleusercontent.com] has left #lightning-dev []
20:30 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
20:43 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Remote host closed the connection]
20:55 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev
20:57 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
21:00 -!- CCR5-D32 [~CCR5@unaffiliated/ccr5-d32] has joined #lightning-dev
21:02 -!- Jmabsd [~jmabsd@180.131.165.45] has joined #lightning-dev
21:13 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
21:38 -!- Jmabsd [~jmabsd@180.131.165.45] has quit [Ping timeout: 268 seconds]
21:41 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection]
22:10 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
22:57 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #lightning-dev
23:02 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #lightning-dev
23:04 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
23:04 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
23:04 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
23:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
23:05 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
23:05 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #lightning-dev
23:06 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 260 seconds]
23:10 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]
23:12 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #lightning-dev
23:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
23:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
--- Log closed Tue Jan 07 00:01:01 2020