20:04:28 <niftynei> #startmeeting
20:04:28 <lightningbot> Meeting started Mon Jul 22 20:04:28 2019 UTC.  The chair is niftynei. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:04:28 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:05:33 <niftynei> ok. i thought we'd start with the rest of the outstanding TLV PR's
20:05:53 <cdecker> Yep, they are needed for the var-hop-payload PR anyway
20:06:00 <rusty> A lot to get through today, indeed!  Let's do it.
20:06:03 <cdecker> (sort of)
20:06:05 <niftynei> which are ... conveniently not in the meeting agenda. let me add them.
20:06:11 <t-bast> agreed, let's start with TLV and then onion ;)
20:06:21 <niftynei> #640
20:06:45 <niftynei> #topic #640 swap CompactSize for BigSize in TLV format
20:06:50 <cdecker> #topic BOLT01: swap CompactSize for BigSize in TLV format
20:06:53 <niftynei> :D
20:06:55 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/640
20:07:06 <cdecker> Hehe, sorry about that
20:07:20 <rusty> niftynei knocks cdecker off the chair... :)
20:07:28 <t-bast> :)
20:07:48 <t-bast> Is there some outstanding discussion on using big-endian instead of little-endian?
20:08:02 <t-bast> I think CL, LL and Eclair have all made the code changes, right?
20:08:09 <roasbeef> don't think so, this also includes psuedo code of the encoding as well
20:08:16 <cdecker> Can we externalize the test-vectors like we did for the var-hop-payload?
20:08:29 <roasbeef> cdecker:  as in make a new file in the repo?
20:08:33 <rusty> I think consensus was clear.  Prev agreement on CompactSize didn't take this into account; everyone's a bit relieved.
20:09:04 <cdecker> Yep, just move them into a separate JSON file instead of having them in the text itself (minor cleanup for after the merge)
20:09:13 <rusty> cdecker: I think we should do a pass and get all the test vectors moved.  Can we push that to a subcommittee?
20:09:25 <t-bast> I agree with rusty on that
20:09:28 <rusty> (As a spelling/formatting change)
20:09:30 <cdecker> Absolutely, just something that jumped me in the eye
20:09:39 <roasbeef> yeh can be done afterwards
20:09:43 <cdecker> +1
20:09:44 <niftynei> ok great
20:10:05 <niftynei> #agreed merging #640
20:10:08 <t-bast> Would be good to merge TLV changes and onion to be able to make progress on things that build on top of it, and do some clean-up afterwards if needed
20:10:08 <rusty> #action cdecker to lead bikeshedding on externalizing and neatening test vectors.
20:10:22 <rusty> t-bast: +1
20:10:23 * cdecker loves bikeshedding :-)
20:10:50 <cdecker> All my sheds turn out to be some maroon color because I keep changing my mind :-)
20:10:51 <niftynei> in the same vein, the next order of business is the TLV testcases
20:11:10 <t-bast> yep, I think bitconner, rusty and I all have updated our test suite to match #631
20:11:12 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/631
20:11:15 <niftynei> #topic TLV testcases #631
20:11:17 <niftynei> lol
20:11:17 <t-bast> do we all have a green test suite?
20:11:30 <t-bast> cdecker got kicked out, now it's rusty's time...
20:11:38 <t-bast> fithgint for the chair at Blockstream
20:11:46 <t-bast> just reptilian things?
20:12:01 <niftynei> we're working on our chair sharing algorithm
20:12:06 <t-bast> haha
20:12:22 <cdecker> The dining blockstreamers problem all over again :-)
20:12:27 <rusty> niftynei: sorry.  Links are nice though, since they're clickable in the minutes.
20:12:48 <niftynei> noted. thanks rusty!
20:13:00 <t-bast> I think for #631 we have a pretty good test suite now, if we decide that moving these to a JSON file is for another effort we should be good, aren't we?
20:13:14 <t-bast> is bitconner here tonight?
20:13:17 <rusty> OK, bikeshedding over BigSize can be put on hold.  I think we're good for 631.  Ack.
20:13:46 <t-bast> 631 is an ACK from me too, I think bitconner was ok too but wouldn't want to speak for him.
20:14:33 <rusty> t-bast: he acked on-issue.
20:14:40 <rusty> https://github.com/lightningnetwork/lightning-rfc/pull/631#pullrequestreview-260999156
20:14:59 <t-bast> sgtm then
20:15:15 <t-bast> shall we have an action item to merge that asap too then?
20:15:32 <niftynei> #action merge #631
20:15:56 <rusty> Yep... it was also suggested to use `bigsize` rather than `varint` throughout the spec, but that's under the #spelling rule really.
20:16:15 <t-bast> agreed, we can do spelling fixes in later PRs to replace it everywhere
20:16:27 <t-bast> otherwise it's distracting from the more important feature discussions
20:16:48 <niftynei> that wraps up the outstanding TLV PRs
20:16:57 <t-bast> That's great!
20:17:05 <t-bast> Let's do the same with onion then :)
20:17:17 <t-bast> IIRC cdecker is thirsty and has a prosecco bottle nearby
20:17:21 <niftynei> #topic variable sized onion payloads https://github.com/lightningnetwork/lightning-rfc/pull/619
20:17:24 <niftynei> :D
20:17:46 <cdecker> Yep, ready to go :-)
20:17:47 <rusty> OK, only issue here was signalling.  zero-HMAC vs 0-TLV.
20:18:06 <t-bast> roasbeef were you able to update your onion implementation to bigsize and verify the latest test vector?
20:18:18 <roasbeef> not yet
20:18:21 <cdecker> I think keeping both is ok: the zero-HMAC is needed for backward compatibility and the 0-TLV allows us to reclaim the last 32 bytes of the onion
20:18:34 <t-bast> I agree with cdecker
20:18:43 <roasbeef> wait both?
20:18:51 <roasbeef> you only need 1
20:19:06 <roasbeef> it's also weird to have the tlv layer reach down and inform the onion if it's the terminal node or not
20:19:13 <cdecker> But if desired we can permit zero-HMAC only for legacy hop_data, and only 0-TLV for the newer TLV based payload :-)
20:19:18 <roasbeef> one is a sphinx laevle indicator, the other is an app level indicator
20:19:26 <rusty> roasbeef: but in practice, it's "if first byte is 0, there's no HMAC".
20:19:28 <roasbeef> layers crossing into other layers
20:19:31 <t-bast> I think that termination should have been handled one layer above the onion layer. It probably wasn't do-able for legacy so legacy uses an empty hmac but for TLV it makes more sense in my opinion to handle termination when interpreting the payload.
20:19:48 <t-bast> Why does it make sense for the onion layer to know about termination?
20:19:56 <roasbeef> why above? terminiation is a packet level thing, the structure is even diff when constructing everything
20:20:00 <t-bast> The onion layer only peels one layer of the onion and passes that to the app layer right?
20:20:09 <cdecker> So shall we just have a followup PR that allows 0-TLV for TLV based payloads?
20:20:14 <roasbeef> it cna signal to the app if it's done or not
20:20:26 <roasbeef> it also makes termination independent of w/e app level framing
20:20:50 <t-bast> In my opinion termination isn't a packet-level thing for onion. For trampoline for example I'm using onions in a slightly different way and it doesn't really make sense to have "termination" at the onion layer but rather at the application level.
20:21:12 <rusty> I dislike crossing the two lines, where the TLV stream length is only known once you start parsing the TLV stream.  However, in this case it's trivial enough that I can't raise strong objection.  You literally look at the first byte of the tlv stream: if it's zero, there's no HMAC.
20:21:21 <cdecker> Yeah, agreed with t-bast: remember it's the HMAC for the _next_ hop not ourselves :-)
20:21:31 <cdecker> So it should be considered part of the payload, not the onion
20:21:47 <cdecker> Using the 0-TLV and zero-HMAC is perfectly identical in that sense
20:21:48 <roasbeef> yeah it's for the next hop, the original sphinx used the next addr, but at that point the routing info is more closely embedded into the packet itself (as was before)
20:22:22 <roasbeef> dunno how trampoline relates to this, that's something else all together that isn't even fully baked
20:22:29 <rusty> I disagree that all-zero-hmac should work for non-legacy though.  That's just weird.
20:22:42 <roasbeef> if we remov ehamc, just more code that needs to change (awareness wise) between the legacy and the new
20:22:54 <t-bast> it's just about using the onion's flexibility: it will be useful for other scenario as well that require playing with what's inside the onion
20:23:04 <cdecker> But it gives us back 32 bytes of payload
20:23:24 <roasbeef> and we save a ton along the way w/ all the other additions ;)
20:24:11 <cdecker> Let's quickly enumerate the variants that we could agree on: a) keep zero-HMAC as sole signal, b) use zero-HMAC for legacy and 0-TLV for TLV payloads, or c) allow zero-HMACs also in TLV based payloads
20:24:17 <roasbeef> i think this can be resolved later since you can add it, but then keep the hmac are the primary
20:24:20 <t-bast> I honestly don't feel very strongly about this. I think cdecker's proposal is totally fine, but if it's a no-go for some we can stick to the HMAC
20:24:22 <cdecker> Which ones are people most comfortable with?
20:24:29 <roasbeef> i'm ok w/ b, but then it's just redundant information
20:24:40 <roasbeef> err c
20:24:50 <roasbeef> c or a
20:25:04 <t-bast> I implemented c for now
20:25:13 <t-bast> Waiting for a final decision :)
20:25:14 <rusty> Nack C.  Have one signalling mechanism please!
20:25:14 <roasbeef> but your primary is hmac t-bast ?
20:25:19 <cdecker> So, (c) is what the current spec says
20:25:22 <roasbeef> one FTW
20:25:35 <cdecker> Ok, so everybody ok with (a)?
20:25:45 <t-bast> No my primary right now is -> if legacy check mac, if TLV check first byte and additionnally check HMAC
20:26:07 <t-bast> We can do a) for this proposal and re-visit later, right?
20:26:21 <cdecker> If that's the only issue we have I can just drop the final signal in the PR and we can merge :-)
20:26:25 <t-bast> a) is the least amount of changes compared to legacy, and we can change that later when we feel we really need those 32 bytes
20:26:29 <rusty> t-bast: hmm, yes, 0 is even :)
20:26:58 <roasbeef> don't think all the latest test vectors have been cross ref'd
20:27:03 <t-bast> rusty: :)
20:27:19 <roasbeef> also there was confusion if the old ones worked w/ pre-emptive use of BigSize?
20:27:26 * cdecker puts the prosecco back in the fridge...
20:27:31 <t-bast> were you able to check them roasbeef? the latest test vectors on the PR work for eclair and CL
20:27:45 <t-bast> they use the big-endian bigsize encoding
20:27:48 <roasbeef> haven't yet
20:27:56 <cdecker> roasbeef: the latest version of the test-vector now all use bigsize as per spec
20:28:12 <t-bast> I think if you got them to work with your previous little-endian encoding, the easy code change to move to big-endian should make it work
20:28:24 <t-bast> I don't foresee anything complex there :)
20:28:26 <rusty> OK, so plan is to eliminate the 0 TLV record for now, and roasbeef to ack test vectors?
20:28:34 <roasbeef> sgtm
20:28:39 <t-bast> sgtm
20:28:42 <cdecker> In the meantime I'll drop the 0-TLV type so we use zero-HMAC for termination only
20:28:45 <cdecker> SGTM
20:28:52 <t-bast> once ack-edm can we agree to merge?
20:29:10 <t-bast> That makes it easier to build on top of it (AMP, message extensions, etc)
20:29:16 <niftynei> #agreed eliminate 0 TLV record for now
20:29:24 <niftynei> #action roasbeef to ack test vectors
20:29:25 <rusty> t-bast: +1 from me!
20:29:51 <niftynei> ok so if roasbeef acks the test vectors, we consider this PR good to merge?
20:29:54 <t-bast> roasbeef are you ok with that? Once ack-ed that your implementation verifies the updated test vectors, we can merge without waiting for next meeting?
20:30:09 <roasbeef> don't think there's ever been a req to wait for this meeting to merge stuff
20:30:20 <t-bast> great :)
20:30:37 <niftynei> ok great. moving on
20:30:46 <rusty> Yeah, unless unforseen issues (as always!)
20:30:49 <t-bast> related to onion and tlv
20:30:57 <t-bast> nitftynei I have a small PR to look at
20:31:06 <t-bast> https://github.com/lightningnetwork/lightning-rfc/pull/627
20:31:21 <t-bast> I'm wondering how other implementations deal with that error code right now
20:31:36 <t-bast> It feels to me that a new error code would be useful
20:31:44 <roasbeef> how would you error out? since atm it's just a fixed number of bytes
20:31:49 <roasbeef> so failing on integer parsing or something?
20:31:58 <roasbeef> or the packet is the wrong size?
20:32:11 <roasbeef> matters more in a post TLV world I guess
20:32:14 <t-bast> there are many things than can be wrong in the TLV: invalid order, unknown even type, etc
20:32:23 <t-bast> yes exactly, I detail that in the PR intro
20:32:38 <niftynei> #topic BOLT 04: Add failure code for invalid payload
20:32:52 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/627
20:33:06 <niftynei> ok so my two cents on this PR is that it looks like we still need LL and CL to review it
20:33:25 <t-bast> agreed, just wanted to bring it to their attention while they're finalizing the onion implementation
20:33:31 <cdecker> Well, it just formalizes what we'd be doing anyway
20:33:37 <roasbeef> no strong objection at a glance, we'll def need a way to signal back the sender that they messed up somewhere
20:33:44 <cdecker> So from me it looks reasonable
20:33:58 <t-bast> great, so let's discuss the exact bit used on the PR in the following days, no rush here
20:34:04 <roasbeef> have a history of accidentally adding new probing vectors with precise errors, so should have that in mind, but don't see anything at a glance
20:34:06 <niftynei> it's a short proposal to add a new error type for onions
20:34:25 <rusty> t-bast: errors for things which Shouldn't Happen aren't high on my priority list, but I'll comment on-issue.
20:34:50 <cdecker> I'm happy with using BADONION|PERM since it seems to be the most generic failure we can hit
20:35:03 <t-bast> rusty: sgtm
20:35:11 <t-bast> cdecker: that was indeed my first choice
20:35:24 <rusty> It should only be BADONION if we think we can't generate a valid reply.  I don't think that's the case.
20:35:43 <rusty> Would prefer to include offset of error within TLV, too, as a hint.
20:36:20 <roasbeef> yueh sounds useful for debugging
20:36:22 <rusty> Anyway, will make these points on the issue to avoid derailing
20:36:48 <niftynei> #action rusty to leave feedback on PR
20:36:50 <t-bast> perfect, let's discuss this on github after giving it some thought and seeing how that would fit in our implementations
20:37:41 <niftynei> ok i'd like to get a one easy-ack PR through so we can merge it
20:37:53 <t-bast> good idea
20:37:56 <niftynei> #topic BOLT7: (announcement_signatures) Fail channel if `short_channel_id` not correct. #635
20:38:00 <niftynei> https://github.com/lightningnetwork/lightning-rfc/pull/635
20:38:03 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/635
20:38:25 <roasbeef> easy lgtm
20:38:29 <rusty> +1
20:38:30 <niftynei> great. moving on
20:38:31 <cdecker> ack
20:38:32 <roasbeef> I guess SHOULD instead of MAY?
20:38:32 <t-bast> simple enough
20:38:42 <rusty> roasbeef: yeah, let's upgrade to SHOULD.
20:38:54 <roasbeef> commented on PR
20:39:00 <niftynei> #action upgrade from MAY to SHOULD
20:39:00 <t-bast> then maybe update the following lines to SHOULD too?
20:39:01 <rusty> Probably should upgrade the other ones too, but that's a separate PR.
20:39:34 <niftynei> yes we MAY update them
20:39:50 <rusty> niftynei: I think we SHOULD.  Nay, MUST!
20:39:55 <roasbeef> kek
20:40:26 <niftynei> #agreed MAY be merged after SHOULD updated
20:40:47 <niftynei> moving on, i'd like to get these two DLP wording PR's out
20:41:13 <niftynei> #topic BOLT 2: remove local/remote from reestablish field names.
20:41:19 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/634
20:41:37 <t-bast> ACK
20:41:55 <rusty> I was testing these, and the names made it worse.  They're actively misleading, so it's almost a spelling fix.
20:42:31 <t-bast> they really confused me when I first read the spec
20:42:34 <niftynei> same
20:42:45 <rusty> Sorry :(  Let
20:42:48 <niftynei> i found the DLP section incredibly hard to parse. i think this is a definite win
20:42:50 <t-bast> I hesitated to send a PR but was too shy, early times
20:42:54 <rusty> 's kill them.
20:42:56 <niftynei> ok, if there's on dissent let's move on
20:43:06 <niftynei> #agreed merge #634
20:43:36 <niftynei> this next one's similar
20:43:45 <niftynei> #topic option_data_loss_protect: concretely define `my_current_per_commitment_point`
20:43:45 <rusty> W00t! Where's that prosecco...
20:44:07 <rusty> link?
20:44:09 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/550
20:44:26 <roasbeef> well don't htink removing the context makes it more clear re chan reest fields names
20:44:53 <roasbeef> we use slighlty diff names in our code: https://github.com/lightningnetwork/lnd/blob/master/lnwire/channel_reestablish.go#L20
20:45:01 <roasbeef> referring to "chain height"
20:45:06 <roasbeef> commit height*
20:45:32 <rusty> roasbeef: yeah, there's definitely a strong argument that this entire section should be rewritten.
20:46:12 <rusty> But adding the words in #550 def makes it better, not worse.
20:46:21 <rusty> (Since there's currently no description of taht field!)
20:46:28 <ianthius> the docs for LND say that my bitcoind must be compiled with zmq, do folks know if the binaries from the the ubuntu repository bitcoin/bitcoin include this?
20:46:33 <niftynei> right, it adds a description for a currently undefined field
20:46:37 <t-bast> I agree that this is a useful addition
20:46:59 <t-bast> ianthius: I think there are instructions in bitcoin-core's readme about that
20:47:33 <t-bast> ianthius: I would suggest not to use bitcoin from ubuntu's PPA though
20:47:56 <t-bast> ianthius: you should instead use one of the repoducible builds as explained on bitcoin's github repo
20:47:58 <niftynei> roasbeef, if your comment about 'removing the context' regarding #550 or #635?
20:48:40 <niftynei> :s/if/is
20:48:44 <roasbeef> #634
20:49:00 <roasbeef> had forgotten about #550
20:49:20 <roasbeef> i had a comment that looks to hav eben a ddressed many months ago? will check it out again and lgtm it if things look ok
20:49:28 <rusty> ianthius: yes, pretty sure the ppa does, FWIW.
20:49:37 <niftynei> ah ha. ok. well since there's now two outstanding PR's to clarify the section, that seems like a strong indication that we should update it
20:49:43 <cdecker> I found the DLP stuff to be utterly confusing tbh
20:49:59 <roasbeef> has worked pretty well in the field for us FWIW
20:50:04 <ianthius> t-bast: this is not for production, any other reason you suggest not using the binaries besides security?
20:50:08 <cdecker> So any more clarification would be great in my mind
20:50:21 <t-bast> iantius: it's just security, for experimenting you should be fine then
20:50:30 <ianthius> thx all
20:50:32 <cdecker> ianthius: could this wait 30 minutes? We're in the middle of a spec meeting
20:50:34 <niftynei> #action roasbeef to check outstanding comment
20:50:45 <rusty> roasbeef: we keep getting sync errors from lnd, so not sure it's actually working in practice :(
20:50:47 <ianthius> oh whoops sorry folks. i am done
20:50:50 <lndbot> <jtimon> looking at https://github.com/lightningnetwork/lightning-rfc/pull/651 at a glance it looks like it will be extremely useful, at least to me. But I don't think my review will be very ujseful since I will basically just believe anything it tells me. can I review beg for other person's PR?
20:51:46 <cdecker> Yep, we're still trying to hunt down the "sync error" issue that's been haunting us, and it might just be an imprecision in the DLP wording
20:51:47 <t-bast> agreed with jtimon, this one should be useful to get in
20:52:30 <roasbeef> rusty: sync error can just be a timing thing
20:52:49 <roasbeef> andn doesn't always mean that we can't continue forwrd, or y'all sent the wrong info
20:52:53 <rusty> I'd like someone from LL to read through #651 please.
20:53:14 <niftynei> i'd like to hear more about sync error root causes, but i'd also like to move on.
20:53:14 <roasbeef> concept looks sound, didn't know if it till this meeting just now
20:53:37 <niftynei> #topic CONTRIBUTING.md: first draft of how to write and change spec. #651
20:53:38 <rusty> roasbeef: OK, we're going to have to ignore it for 0.7.2, which means DLP will fail to do its job, since we won't force close if you're *actually* out of sync.
20:53:49 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/651
20:54:32 <niftynei> i think this one still needs some review time.
20:54:38 <rusty> Perhaps we get an ack to apply it, but give a week for more feedback?  If nothing emerges in that time, apply?
20:54:47 <niftynei> sgtm
20:54:49 <roasbeef> rusty: would discourage against that in favor or trying to locate the root cause, otehrwise just ignoring can mean loss of funds, if y'all have a repro can prob track it down easily
20:54:50 <t-bast> sgtm
20:54:51 <rusty> (Nothing major, that is, obc clarifications and typos)
20:54:59 <cdecker> sgtm
20:55:16 <cdecker> roasbeef: the problem is we can't reproduce it in a lab setting
20:55:20 <niftynei> roasbeef we've been having trouble nailing down a repro
20:55:25 <niftynei> :D
20:55:48 <rusty> roasbeef: I'll try ignoring it on my node, see if it self-heals or just gets stuck in a sync error loop?
20:55:59 <cdecker> We'll have to ignore it since otherwise we end up closing a lot of channels, since lnd has forced our hand here
20:56:21 <rusty> cdecker: I lost three channels during a restart the other day :(
20:56:32 <roasbeef> depends on what's being ignored, and the action
20:56:40 <roasbeef> if you get teh chan reset message, then you can act accordignly
20:56:49 <cdecker> Ok, definitely need to run my nodes with IO logging so I can at least reconstruct some of the state
20:57:02 <roasbeef> if we don't get urs, but you get ours and we're behind, then you can act
20:57:09 <niftynei> regarding #651, if there's no objections i'm going to take rusty's suggestion as the action
20:57:22 <cdecker> niftynei: sgtm
20:57:24 <t-bast> niftynei: ACK
20:57:51 <niftynei> #agreed one week for feedback, once resolved ok for approval
20:57:54 <t-bast> There was a new wave of feedback on gossip stuff, should we spend some time on range_queries/inventory gossip?
20:58:12 <niftynei> #topic BOLT7: extend channel range queries with optional fields #557
20:58:20 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/557
20:58:21 <t-bast> thanks :)
20:58:53 <rusty> t-bast: well, niftynei literally finished our TLV autogen code on the weekend for c-lightning, so now I get to update our implementation; should be ready before next mtg.
20:59:09 <t-bast> rusty: that would be great!
20:59:34 <t-bast> so we're still at a concept ACK on 557 and will update once we have a second implementation?
21:00:12 <t-bast> and will discuss inventory gossip once we've made progress on 557's implementation?
21:00:28 <sstone> rusty: do you think that 557 needs a new feature bit now or that it can be added later ?
21:00:30 <rusty> t-bast: I will also ahve a test in my protocol test framework, too.
21:00:43 <t-bast> rusty: fancy
21:00:44 <rusty> sstone: I think 2 feature bits, yes.
21:01:21 <niftynei> ok, so it sounds like CL is going to fixup their implementation and we'll revisit in the future
21:01:46 <niftynei> :s/in the future/at the next meeting
21:02:01 <rusty> Since 557 is really two features.  The query_short_channel_id flags, and the query_channel_range flags.
21:02:45 <sstone> I see them as one since you can't really use  extended query_short_channel_id with extended query_channel_range ?
21:02:46 <rusty> Using feature negotiation lets us turn them off individually if we find out we deployed too soon :)
21:03:15 <sstone> Yes that's right
21:03:17 <rusty> sstone: oh, they're closely related.  But they're separate.
21:04:06 <rusty> You can def use the query_short_channel ID if you know about the channel but just want the latest update, I guess?
21:04:53 <sstone> How would you know you need it ?
21:05:20 <sstone> without having received timestamps first I mean
21:05:33 <rusty> sstone: handwave!  Maybe you want to check you have the latest you're going to use in a route?
21:05:52 <rusty> Or somehow otherwise prioritize?
21:06:13 <rusty> But yeah, it's probably not going to happen in any implementation.
21:06:39 <rusty> So perhaps we
21:06:59 <sstone> that what worries me: impl supporting one without the other
21:07:07 <sstone> that's
21:07:25 <rusty> d disable both anyway, in case of problems.  OK, maybe one feature bit for both?
21:07:32 <rusty> They're pretty easy to implement.
21:08:12 <jtimon> sorry if the meeting is not the appropriate time to ask for this, I can wait, but roasbeef could you give a hint to fix https://github.com/cdecker/lightning-integration/issues/59 ? not familiar with go at all...
21:08:36 <cdecker> jtimon: roasbeef gave me a few hints, and I'll try them asap :-)
21:08:48 <jtimon> cdecker: oh, awesome
21:08:59 <sstone> rusty: sgtm, we can continue on the PR discussion section
21:09:04 <niftynei> ok we're over time.
21:09:10 <cdecker> I'll add the transcript to that issue jtimon so it isn't blocking on me
21:09:27 <jtimon> double awesome
21:09:28 <niftynei> #action to continue discussion on PR, CL to re-do implementation
21:09:47 <cdecker> Awesome job everybody, looks like we made good progress today :-)
21:09:53 <niftynei> #topic next meeting chair?
21:10:07 <t-bast> Good job guys, thanks a lot! Sorry for your prosecco cdecker, it will be even better next time ;)
21:10:19 <sstone> an open question for next time: how do you feel about using short channel id as an alias for node id ?
21:10:31 <sstone> context: inv gossip
21:10:32 <niftynei> any volunteers for next mtg? i found it really helpful to have time to organize the agenda beforehand
21:10:50 <t-bast> I agree with niftynei, it's great to know you're chairing to be able to prepare
21:10:58 <t-bast> I can volunteer if no-one wants to
21:11:11 <rusty> niftynei: I think you should do it again, now you've had practice :)
21:11:43 <rusty> sstone: if it saves space, I'm all for it...
21:11:44 <niftynei> i'd be happy to!
21:12:20 <niftynei> i think LL hasn't had a chair spot in a few meetings tho
21:12:36 <t-bast> I agree, maybe someone from LL to rotate frequently?
21:12:41 <niftynei> also happy to trade off with t-bast :)
21:13:12 <niftynei> also, i'd like to go ahead and unmark everything that is "Meeting Discussion". anything that needs to be discussed next week can re-add it
21:13:30 <t-bast> niftynei: agreed
21:13:34 <niftynei> otherwise it's too hard to keep track of what's Actually on the docket for the meeting
21:14:02 <t-bast> @roasbeef no-one on your side wants to chair?
21:14:12 <t-bast> time to get joost and johan in there ;)
21:14:33 <rusty> t-bast: bitconner has chaired before, and he's not here so we can volunteer him, right? :)
21:14:39 <niftynei> #action niftynei to untag every Meeting Discussion label (so they can be re-added for next meeting)
21:15:15 <t-bast> rusty: that sounds evil, I love it
21:15:21 <niftynei> i second a nomination for bitconner
21:15:45 <niftynei> in the case that he's unavailable in two weeks, t-bast can chair
21:15:49 <t-bast> that's settled then, democracy is a beautiful thing
21:16:04 <niftynei> #agreed bitconner nominated to chair next meeting, t-bast will serve as backup chair
21:16:09 <niftynei> great. thanks everyone!
21:16:15 <niftynei> tag your issues for next meeting !
21:16:17 <niftynei> #endmeeting