19:00:44 <rusty> #startmeeting 19:00:44 <lightningbot> Meeting started Mon Jan 7 19:00:44 2019 UTC. The chair is rusty. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:44 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:13 <AmikoPay_CJP> Happy new year! Has the orthodox new year already started? 19:01:49 <cdecker> Uh, we have a meetbot, excellent 19:01:56 <rusty> I expect some chaos, but fortunately things are fairly quiet on the spec front. The main aim is to get the v1 stuff out of the way. 19:02:16 <rusty> #info https://docs.google.com/document/d/1Clbw41wY7hNbfMPozH0IRhmqO4ERDR6FdnBGp79VJ3M/edit# Agenda 19:02:39 <cdecker> I propose we go through the spelling PRs first, and then dig into the meatier stuff 19:03:42 <AmikoPay_CJP> Do we note down presence (and how do we determine that)? 19:03:43 <rusty> Any which now have two acks can be applied and removed from the list... 19:04:02 <cdecker> Well, do mine and yours count as two independent acks? 19:04:09 <rusty> AmikoPay_CJP: I think it's unfair to assume everyone lurking is "present". 19:04:32 <AmikoPay_CJP> I'd say, to be present, you have to say something? 19:04:35 <rusty> cdecker: not usually, but I'm tempted to waive this rule given how long it's been. 19:04:54 <cdecker> Right, #bitcoin-core-dev usually pings a list of regular people, maybe we can do something similar? 19:05:00 <rusty> AmikoPay_CJP: agreed, I'll note presence retrospectively :) 19:06:13 <Chris_Stewart_5> meta stuff: is this monthly or biweekly? 19:06:19 <cdecker> biweekly 19:06:20 <roasbeef> bi weekly 19:06:29 <cdecker> Hi roasbeef 19:06:47 <rusty> #lightning-dev roasbeef aj BlueMatt cdecker jimpo niftynei rpickhardt I'm sure I missed others... 19:06:48 <bitconner> hi all, happy new year! 19:06:53 <cdecker> Are pm7 and sstone also present 19:07:02 <roasbeef> we'll see how well it works out, idk i feel like it'll be less productive than the reg, the bitcoind are working on an impl and just so happen to always hook in protocol stuffs, while we all have diff impls and work together on protocol 19:07:04 <rusty> pm7 sstone 19:07:07 <BlueMatt> huh 19:07:08 <AmikoPay_CJP> Do we keep a complete IRC log or only the BOT minutes? 19:07:08 <BlueMatt> wat 19:07:09 <roasbeef> main upside i guess is more participation 19:07:12 <sstone> present, pm won't be joining us today 19:07:13 <BlueMatt> oh meeting? 19:07:18 <roasbeef> i think kanzure logs this channel? 19:07:24 <niftynei> hello and happy new year 19:07:27 <roasbeef> i have some of by own, but they aren't to be counted on 19:07:29 <rusty> roasbeef: bot lots, so do I... 19:08:00 <rusty> AmikoPay_CJP: I think bot logs everything, also provides minutes summary. 19:08:02 <cdecker> Ok, shall we get going on the PRs? Seems we have quorum 19:08:19 <AmikoPay_CJP> cdecker: ok 19:08:33 <rusty> OK, I move that we accept any typo changes which have two acks, even if from cdecker and me. Since you didn't all do your homework :) 19:08:51 <cdecker> +1 on merging spellings 19:08:54 <rusty> (I usually prefer we get two independent acks, but...) 19:08:55 <BlueMatt> spellings, sure 19:09:24 <rusty> https://github.com/lightningnetwork/lightning-rfc/milestone/2 gives most of them... 19:09:31 <roasbeef> rusty: bot bot isn't a thing anymore 19:10:11 <rusty> roasbeef: :( But in this case we have a lightningbot for the meeting records. 19:10:26 <roasbeef> where doe sit store them? 19:10:39 <cdecker> #action Merge #514 #515 #518 #520 #521 under the spelling rule with two acks 19:10:43 <rusty> roasbeef: AJ's server I think, same as bitcoin-core-dev. 19:11:06 <sstone> cdecker: ok 19:11:35 <cdecker> Seems the meeting chair (rusty) needs to record actions 19:11:40 <BlueMatt> 514 looks wrong 19:12:22 <cdecker> We have been using mutual closing and closing as synonyms for the longest time IIRC 19:12:29 <cdecker> This just cleans up the aliasing 19:12:32 <BlueMatt> ehh, whatever, then, just reads weird 19:12:46 <roasbeef> mutual close seems more precise? there're multiple ways to close 19:12:53 <AmikoPay_CJP> "unilateral close" sounds like a subset of "close". 19:13:44 <cdecker> In the glossary in BOLT#0 the closing transaction is defined as being the mutual close 19:14:06 <cdecker> So if we're not happy with going just with "closing transaction" we need to amend the glossary as well 19:14:31 <rusty> We can certainly replace the phrase "closing transaction" as "mutual close transaction", which is slightly clearer IMHO. 19:14:43 <BlueMatt> ok, that sounds wholly separate, the change is fine as-is, and we can look into replacing it separately 19:14:53 <rusty> #action accept 514 19:14:59 <AmikoPay_CJP> agree 19:15:03 <BlueMatt> kool 19:15:11 <sstone> ack 19:15:18 <roasbeef> is this process even defined or written down anywhere? are there docs on the bot? 19:15:30 <rusty> #action Merge #515 #518 #520 #521 under the spelling rule with two acks 19:15:42 <roasbeef> approved em all on gh, sgtm 19:15:47 <rusty> roasbeef: https://wiki.debian.org/MeetBot 19:16:14 <rusty> cdecker: want to merge them live, to cut down the list :) 19:16:37 <cdecker> +1 19:17:06 <AmikoPay_CJP> rusty: you mean, outside the meeting? 19:17:14 <kanzure> hi. 19:17:18 <BlueMatt> next topix 19:17:20 <BlueMatt> ? 19:17:30 <kanzure> biweekly is ambiguous; do you mean fortnightly? 19:17:45 <kanzure> roasbeef: http://gnusha.org/lightning-dev/ 19:18:05 <AmikoPay_CJP> "Biweekly means either occurring every two weeks, or occurring twice every week." lol didn't realize that. 19:18:07 <rusty> #topic Remaining v1.0 Milestone PRs 19:19:12 <AmikoPay_CJP> kanzure: it's fortnightly. 19:19:21 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/500 19:20:53 <rusty> roasbeef: full quote helps here: "Note that the `htlc_maximum_msat` field is static in the current 19:20:53 <rusty> protocol over the life of the channel: it is *not* designed to be 19:20:54 <rusty> indicative of real-time channel capacity in each direction, which 19:20:54 <rusty> would be both a massive data leak and uselessly spam the network (it 19:20:54 <rusty> takes an average of 30 seconds for gossip to propagate each hop)." 19:21:18 <roasbeef> it's static on the link level, but you can issue updates on the network level 19:21:36 <rusty> roasbeef: this advice is saying explicitly not to do that. 19:21:40 <roasbeef> but the update can't be greate rhtan the link level value, or exceed the max capacity of the channel 19:21:51 <roasbeef> well yeh don't spam it, but you can modify your routing policies in real time 19:21:58 <cdecker> So you are saying we can send updates that set this in the acceptable range? 19:22:13 <cdecker> Sounds a bit micro-managy, but interesting 19:22:18 <roasbeef> i don't mean each time you forward, i mean lets say you want to carry even smaller htlcs that are routed across, you can modify this 19:22:24 <roasbeef> yeh 19:23:04 <cdecker> Are there good use-cases for this functionality? Or reasons to do so? If not I'm tempted to defer 19:23:07 <BlueMatt> current spec says you shouldnt do that, if you want to change it, thats a separate discussion from 500... 19:23:08 <roasbeef> or lets say for w/e reason, someone is being a nuisance and just hodling onto larger htlcs thru your channel, you can clamp down a bit on that by lowering this value and notifying all others interested in routing across 19:23:15 <BlueMatt> 500 just notes that minmum is, too, which is definitely true 19:23:35 <roasbeef> yeh the original wording itself was too restrictive, for example you _can't_ update the link level values, but you can update the network level value 19:23:54 <roasbeef> or even in a world of multi path payments, you may want to modify based on how ppl are typically splitting 19:24:00 <rusty> roasbeef: explicitly no. That's basically reflecting dynamic capacity. 19:24:07 <cdecker> Ok, shall we accept #500 and defer the discussion about the ability to change this to another PR? 19:24:25 <BlueMatt> cdecker: ack, htlc_minimum_msat even says you MUST set it to the value your peer will accept 19:24:31 <BlueMatt> so thats an orthogonal change 19:24:52 <cdecker> roasbeef: would that work for you? 19:25:05 <rusty> roasbeef: Yeah, more useful (in an AMP world) would be giving *some* vague non-completely-leaky indication of how far out the capacity constraint is. 19:25:16 <roasbeef> you can't enforce that it's static though 19:25:27 <roasbeef> nodes would need to rememebr the "first" (w/e that is) value and reject the rest 19:25:54 <rusty> roasbeef: of course not, but this is advice to avoid people trying to use this to send dynamic information. 19:26:01 <BlueMatt> or just the most recent and always check its the same in each update, thats pretty trivial, but it doesnt really matter, the text says you MUST set it to the value your peer sets, which is constant 19:26:12 <roasbeef> BlueMatt: how do you know what the first update looked like? 19:26:39 <cdecker> I think he means the first one you saw and then just check on each update that the value doesn't change 19:26:44 <BlueMatt> that 19:26:52 <roasbeef> rusty: ok then in that case the language can be relaxed, rn it asserts it's static in the protocol which is false 19:27:09 <roasbeef> so then nodes are to reject if it chaanges? 19:27:28 <BlueMatt> no, its not, look later down... "MUST set htlc_minimum_msat to the minimum HTLC value that the channel peer will accept" 19:27:43 <BlueMatt> it is absolutely required to be static right now, but I agree we can/should look into relaxing that 19:27:54 <roasbeef> it isn't though :/ 19:27:59 <BlueMatt> the text change proposed in 500 is consistent, even if you'd prefer it not be 19:28:04 <rusty> roasbeef: sure, it's sloppily worded. It should say the total channel capacity is static in current protocol, and the intent of this is to reflect that, not dynamic capacity. Of course, this has to be rewritten for 1.1 anyway... 19:28:07 <roasbeef> it doesn't reflect reality 19:28:56 <cdecker> Does it get worse if we apply #500 and make a new issue discussing whether we should relax it roasbeef? 19:28:59 <BlueMatt> roasbeef: how is it not reflective of the requirement later down in that section? what am I missing? 19:29:01 <rusty> So, I think 500 is OK, but there's a deeper issue in the text it hits. 19:30:26 <rusty> Since no agreement here, let's move on. 19:30:42 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/502 19:30:49 <cdecker> #agreed Defer discussion of #500 to the issue tracker 19:31:00 <roasbeef> BlueMatt: then doesn't that contradict itself? top tries to say static, below indicates it's dynamic value (what i accept today, may not accept tomorrow), i get we want to discourage flappy updates but we can do that with more precise language 19:31:04 <roasbeef> sgtm 19:31:47 <rusty> There's a style nit that cdecker commented on... I think our style guide says use explicit 0 for a zero. 19:32:45 <cdecker> Ok, didn't realize that, if the styleguide says that I retract my nit :-) 19:32:52 <rusty> But I think we should apply this, with a note to clean up the tabs v spaces whitespace post. This too has been sitting here 3 months. 19:33:29 <rusty> #action Rusty to clean up whitespace tabs vs space in BOLT11 19:33:41 <BlueMatt> concept ack the changes, though I havent looked through them 19:33:42 <BlueMatt> roasbeef: ohhhh, I see your reading of it, yea, i guess thats obviously not how anyone else read it, so the text would need "assuming the channel capacity is available" or so in the MUST set section later 19:33:52 <BlueMatt> to make it match how everyone else read it 19:34:07 <rusty> Any objections to 502? 19:34:14 <BlueMatt> sounds like no 19:34:18 <sstone> rusty: no 19:34:28 <niftynei> there's a few outstanding spelling issues in 502 19:34:29 <rusty> #action Apply 502. 19:34:50 <niftynei> i'll go in and annotate them, other 19:34:54 <niftynei> *annotate them 19:34:55 <rusty> niftynei: thanks :) 19:35:21 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/514 19:35:43 <BlueMatt> huh? it got merged? 19:35:49 <BlueMatt> did you mean something else 19:35:50 <roasbeef> looks liek it's aleady dunzo 19:35:51 <ott0disk> isn't 514 already discussed? 19:35:51 <BlueMatt> we already did 514 19:35:57 <roasbeef> yeh it was batched 19:36:01 <AmikoPay_CJP> as typo pull 19:36:33 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/525 19:36:37 <cdecker> #514 was one of the spellings we agreed before :-) 19:36:45 * rusty furiously searches for one not closed already... 19:37:11 <AmikoPay_CJP> Wait, are we actually going to finish going through this list today? 19:37:26 <cdecker> Hehe, rusty maybe we can define a milestone for each meeting, that way the issues become easier to iterate through 19:37:40 <rusty> cdecker: good idea... 19:37:41 <BlueMatt> ack 525 19:37:49 <rusty> #action Apply 525 19:37:51 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/528 19:37:52 <BlueMatt> looks like lots o' acks 19:37:53 <roasbeef> AmikoPay_CJP: most of them are already ticked, well a good bit, buncha small ones 19:38:36 <cdecker> lol, that one's a freudian switch if I ever saw one :-) 19:39:05 <rusty> #action Apply 528 19:39:25 <AmikoPay_CJP> ack 528 19:39:54 <BlueMatt> note: if possible please write up what was discussed in meeting on the pr as required, best to keep notes so its visible after the fact imo 19:40:28 <rusty> OK, 529 and 530 already double-acked, am simply applying. 19:40:30 <BlueMatt> even if its just a comment that says "looks good as per meeting discussion" or something (unless, obviously, it meets ack requirements on its own) 19:40:37 <cdecker> Agreed 19:40:55 <cdecker> We also probably shouldn't merge mid-meeting either :-) 19:41:52 <rusty> Yes, for non-typo things, sure. 19:42:09 <rusty> We shouldn't even need to discuss typos in meeting, but getting acks proved hard. 19:42:23 <rusty> #action Merge 523 19:42:51 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/527 19:42:52 <bitconner> ack 523 19:44:38 <rusty> I convinced myself this was correct when I acked it, but it's a bit non-trivial. 19:44:53 <BlueMatt> this reads wrong to me? 19:45:08 <BlueMatt> MUST *resolve* the _remote node's offered HTLCs_.....with HTLC-Timeout? 19:45:20 <BlueMatt> remote's offered implies to-us implies *they* should time it out? 19:45:23 <BlueMatt> or am I misreading? 19:45:41 <rusty> BlueMatt: misreading... "* spend the *HTLC-timeout tx*, if the remote node has published it." 19:45:50 <BlueMatt> oh lol, yup, indeed 19:46:13 <BlueMatt> ack'd 19:46:25 <cdecker> #agreed Merge #527 19:46:29 <rusty> #action Merge #527 19:46:50 <BlueMatt> cdecker: plzackonzegithubz 19:47:45 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/532 19:47:49 <rusty> Can I have an ack please? 19:49:05 <rusty> I think it needs bitconner, roasbeef or cdecker ack really. 19:49:21 <cdecker> Not sure, roasbeef you're the resident Noise_XK expert, can you confirm this is correct? 19:49:21 <AmikoPay_CJP> It doesn't look like a typo. Isn't there actually a meaning difference? 19:49:45 <roasbeef> slightly off-topic, but there's a Noise Protocol meetup this week in the bay area, collocated with RWC 19:49:53 <cdecker> Indeed there is, it now switches which key is used, and I failed to follow the rationale 19:49:53 <roasbeef> the diagram above and the text are correct 19:49:58 <roasbeef> this body was diff 19:50:09 <BlueMatt> if it were wrong, my code definitely wouldnt work, so this is clearly the ways its implemented, and the header matches the change 19:50:19 <roasbeef> the prior text was wrong, the ephemeral keys are already exchanged earlier in the protocol 19:50:24 <rusty> Yeah, it was well-spotted. 19:50:27 <BlueMatt> also what roasbeef said 19:50:30 <roasbeef> this is now the initiator telling the responder who they are 19:50:36 <rusty> #action Apply #532 19:50:46 <cdecker> Excellent, so that's an ACK from BlueMatt and roasbeef :-) 19:51:00 <rusty> #action https://github.com/lightningnetwork/lightning-rfc/pull/533 19:51:42 <BlueMatt> do we really want to gossip these instead of just returning them via update_fails 19:51:43 <BlueMatt> ? 19:51:45 <rusty> Now I read it again I'm not so sure. It's undefined what "completely unbalanced" means. 19:51:48 <roasbeef> imo just return the fail 19:51:51 <cdecker> Shall we add that completely empty means below minimum_msat? 19:52:14 <BlueMatt> I mean better response is to rebalance the channel or so vs gossiping something 19:52:15 <roasbeef> from my PoV, you don't even really need the gossip, you can just get all these updates back in error messages 19:52:36 <rusty> FWIW, we considered not sending out a channel_update until we had some outgoing capacity, but niftynei pointed out that's a terrible passive data leak. 19:52:41 <roasbeef> as more users really only pay a select number of destinations at this stage, and impls can learn from their behavior to optimize which updates to fetch optimistically and which ones to just grab the fail 19:52:47 <ott0disk> note that a channel might be disabled due to other reason too 19:52:48 <cdecker> Right, this is a tradeoff between letting people try and fail, or telling them ahead of time 19:53:04 <roasbeef> ott0disk: yeh that too, atm lnd only does offline/online thresholds 19:53:18 <roasbeef> just raising fees on a channel to "too damn high" can also signal the same thign 19:53:32 <roasbeef> cdecker: does CL disable a channel until it's above the reserve? 19:53:32 <cdecker> Same with c-lightning, but we wait for someone to actually attempt to use the channel before broadcasting 19:53:39 <rusty> roasbeef: no. 19:53:50 <cdecker> That'd leak the funder 19:53:58 <roasbeef> gotcha, not sure why i thought y'all did 19:54:21 <cdecker> (I might have mentioned something like that in the past. mea culpa) 19:55:19 <rusty> cdecker: I think it was my clever idea, TBH. But yeah, not so clever. 19:55:29 <rusty> Don't know how to undo an ack on GH. 19:55:44 <rusty> So, we Nak this change with some explanation? 19:56:04 <BlueMatt> sounds good to me, yes 19:56:08 <BlueMatt> will write up 19:56:09 <BlueMatt> sec 19:56:13 <sstone> like what it actually means to be unbalanced ? 19:56:16 <cdecker> Yep, sounds good 19:56:22 <roasbeef> sstone: /shrug 19:56:50 <rusty> #action Close #533 with explanation 19:57:06 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/533 19:57:33 <rusty> BlueMatt points out that it's technically backwards incompatible, but since nobody uses the error fields at the moment... 19:57:45 <BlueMatt> rusty: wrong link 19:57:53 <BlueMatt> 538 is what you meant 19:57:56 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/538 19:58:03 <rusty> Thanks. 19:58:26 <BlueMatt> yea, I dont care, I'm happy to just see it merged as-is, just noting that it would break someone actually currently using that data 19:58:39 <BlueMatt> actually, I think we use them 19:58:39 <BlueMatt> wait 19:58:46 <roasbeef> yeh at a glance woudl seem it isn't backwards compat? 19:59:01 <roasbeef> why is it better to return the outogoing in these cases? the PR description doesn't have any sort of justification 19:59:32 <rusty> roasbeef: well, that's the one you're complaining about. And in fact, that's what c-lightning does, from a quick reading now. 20:00:23 <BlueMatt> oh, no, we dont use them 20:00:28 <rusty> Yes, confirmed; we generate those errors on the outgoing side, it has no concept of where it came from. 20:00:58 <roasbeef> why's it better to return the amt in the onion instead of the amt extended if it's below min? 20:01:18 <roasbeef> by outgoing htlc, it means the onion forwarding info right? 20:01:53 <cdecker> Yep, that'd be the value you'd apply when forwarding 20:01:54 <BlueMatt> for amount_below_minimum it makes sense, but, indeed, for cltv_expiry_delta, I dont think it does 20:02:09 <sstone> yes (it only applies when you're forwarding payments) 20:02:10 <BlueMatt> ie cause you know the value they're supposed to set on the remote cause they told you the onion passed mac check 20:02:22 <BlueMatt> but you cant be sure the previous hop forwarded it correctly 20:03:00 <roasbeef> i'm confused...yeh you know the onion vlaue is correct if it checked, so then someone didn't give you the correct value, which means you should tell the incoming value? 20:03:18 <roasbeef> same w/ the cltv expiry 20:03:38 <BlueMatt> well the htlc value change there only is the minimum, so really any data you might send is redundant 20:03:46 <BlueMatt> but for cltv_expiry doesnt make sense 20:04:26 <roasbeef> seems there's two cases: the sender messed up and didn't checkk your min value, and the node before you took too many fees or gave you an incorrect htlc 20:04:43 <BlueMatt> took too many fees should be covered by fee_Insufficient 20:04:48 <BlueMatt> not amount_below_minimum 20:04:56 <BlueMatt> incorrect htlc -> cltv_expiry, yea 20:06:51 <roasbeef> i guess we're also over time now 20:07:16 <cdecker> Ok, so the correction seems correct to me, the value for amount_below_minimum seems redundant since the sender knows that value but ok 20:07:22 <rusty> And bad cltv should be caught by incorrect_cltv_expiry. So we assume it's not the fault of the prior node. 20:08:08 <roasbeef> commented on the PR 20:08:12 <rusty> Yes, we're into overtime, and I need coffee to consider all the cases here. So let's defer this one onto the PR and close? 20:08:14 <rusty> roasbeef: thanks! 20:08:27 <BlueMatt> kool 20:08:31 <BlueMatt> next topic? 20:08:44 <cdecker> Yep, defer is good here 20:08:59 <rusty> #action Defer 538 to the PR itself. 20:09:19 <cdecker> I think we're through the issues/PRs 20:09:47 <roasbeef> lingering stuff at the end: lnd has a fixed for an update_fee related bug, might explain some of the random force closes even between ourselves, should land in this week and we'll follow up with a minor release to get ppl on the network updated 20:09:55 <rusty> I'm going to close the formal meeting due to time constraints, but feel free to discuss wider issues. Sorry we didn't get to it. 20:10:03 <rusty> #endmeeting