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