20:05:11 <t-bast> #startmeeting
20:05:11 <lightningbot> Meeting started Mon Jul  8 20:05:11 2019 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:05:11 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:05:34 <t-bast> #topic the allmighty variable-length onion: https://github.com/lightningnetwork/lightning-rfc/pull/619
20:06:17 <cdecker> Thanks for providing the additional steps t-bast, I only saw the request for extra info today
20:06:34 <t-bast> I hope it will help debug this, troubleshooting onion encryption is always a pain :)
20:06:50 <cdecker> Yep, definitely
20:06:55 <t-bast> On the spec side, does someone have something to say?
20:07:01 <roasbeef> yeh i think it's just something with the hop serialization, or some interaction when they're intermingled
20:07:28 <t-bast> Or do we all agree on the PR as it is today?
20:07:47 <roasbeef> seems perhaps #622 should go in before that
20:07:48 <cdecker> Well, let's wait for LL to reproduce, then we can merge
20:07:54 <roasbeef> as it still has stuff like "integer"
20:07:58 <rusty> t-bast: IIRC, we're all good on the spec, we were awaiting reproduction.  Of course, if we find a difference we may want spec clarification, but that can always go in later.
20:08:15 <rusty> roasbeef: agreed.  cdecker: agreed.
20:08:17 <t-bast> ok good
20:08:28 <t-bast> I think there's one thing we can update though
20:08:40 <t-bast> the current feature bit uses 0/1 which won't play nicely with feature bit unification
20:09:00 <t-bast> I think we should change that to a currently unassigned bit pair to make it simpler to do feature bit unification, WDYT?
20:09:27 <cdecker> SGTM
20:09:33 <cdecker> Any proposal?
20:09:35 <roasbeef> we'll also need some BOLT 11 updates likely as well, but that'll prob be dependent on the exact payment scheme used
20:09:42 <bitconner> do we also need the invoice tags?
20:09:56 <t-bast> I think we can add the Bolt 11 changes in a separate PR, can't we?
20:10:12 <roasbeef> still in the dark w.r.t the motivation for the feature bit unification
20:10:16 <cdecker> Hm? Why would we need bolt11 updates?
20:10:17 <roasbeef> yeh, since it's scheme dependent
20:10:29 <roasbeef> well to signal if they support amp or spontaenous payments for example
20:10:41 <bitconner> for unadertised nodes to communicate support for variable length payloads
20:10:41 <cdecker> Yeah, but that's orthogonal to this
20:11:05 <cdecker> For unadvertised channels we'd infer from spontaneous or amp
20:11:12 <cdecker> No need to signal twice imho
20:11:43 <t-bast> on the feature bit, should we "steal" one of the bit pair assigned in the issue but currently not spec-ed?
20:11:45 <t-bast> see https://github.com/lightningnetwork/lightning-rfc/issues/605
20:12:34 <t-bast> I think most feature bits defined in that issue will be spec-ed after onion, so it would be faire for onion to steal the first unassigned bits (ie 8/9) and update the issue to take that into account, wdyt?
20:12:46 <rusty> roasbeef: unification is so we can advertize both in the node_announcement.
20:12:59 <roasbeef> they're a diff namespace though, we haven't used anything in the global namespace, so we can start from 0/1
20:13:25 <rusty> roasbeef: then how do we advertize that our node supports this in node_announcement?
20:13:27 <t-bast> roasbeef: but we'd like to combine them in a single byte array
20:13:30 <bitconner> they'll be shared if we also decide to move forward on unification
20:13:32 <roasbeef> cdecker: infer? how, you'd need to know what they support before you send the payment, so you can use the invoie for that
20:13:56 <cdecker> roasbeef: signalling in an invoice seems weird for spontaneous payments xD
20:13:58 <rusty> roasbeef: vs, say, option_dataloss_protect which is 0/1 in local features.
20:14:30 <bitconner> cdecker, what if i want to signal support w/o supporting those features?
20:14:30 <cdecker> But for AMP I get an invoice that signals support for AMP, then I can infer that the recipient supports variable payloads :-)
20:14:34 <rusty> (which, if we proceed with unification, will appear in node_announcement)
20:15:07 <cdecker> bitconner: if you don't need variable payloads, why would you want to get variable payloads?
20:16:00 <bitconner> amp and spontaneous payments aren't the only use cases for variable payloads
20:16:05 <roasbeef> cdecker: you may want to attach additional data
20:16:13 <cdecker> But we digress, I propose we just signal standalone variable payload support using feature bits 40/41
20:16:15 <roasbeef> cdecker: otherwise, how do you know if they support it at all?
20:16:20 <rusty> The bolt11 suggestion was for a new field `9` which adds another (bolt11-specific) feature bitset.  We could use the same namespace, but some things don't make sense...
20:16:33 <rusty> cdecker: ack
20:16:39 <t-bast> cdecker: agreed, let's go for 40/41 then
20:16:54 <t-bast> #action cdecker will update the feature bit in the PR
20:16:59 <cdecker> roasbeef, bitconner I retract my objection to standalone signalling :-)
20:16:59 <roasbeef> 40/41?
20:17:20 <t-bast> roasbeef: it's the first unassigned one in the issue linked, let me fetch the link again
20:17:21 <cdecker> roasbeef: if you look at #605 they are the lowest not-yet-claimed feature bits
20:17:28 <t-bast> https://github.com/lightningnetwork/lightning-rfc/issues/605
20:18:00 <rusty> Comment added to that issue...
20:18:01 <roasbeef> those arwe stuff that we don't even know for sure will happen, seems to assign ahead of time w/o even a high level description of the change
20:18:19 <roasbeef> also in my mind, they're distinct namesapces, local vs global
20:18:28 <roasbeef> afaik we don't have any global feature bits
20:18:37 <t-bast> the namespaces will be merged if we do feature bit unification
20:18:55 <rusty> roasbeef: but people wanted local features in node_announcement, so they could find peers which supported certain features.
20:19:23 <roasbeef> depends on what a "local" is, stuff like bigger chans is a global bit
20:19:36 <roasbeef> basically anything that you may need to use for preferential peer selection
20:19:45 <t-bast> let's discuss that when we discuss the feature bit unification PR :)
20:19:59 <rusty> roasbeef: no, the original idea of global was "stuff you need to know to *route* through"
20:20:13 <rusty> roasbeef: hence this would be our first global bit, with var onion.
20:20:36 <rusty> (Or, if we prefer the nomenclature,  "routing" bit vs "peer" bit maybe...)
20:20:45 <t-bast> maybe we should switch the topic to discuss feature bit unification? and then come back to the onion bit?
20:21:03 <cdecker> I think we are moving away from the var payload
20:21:29 <cdecker> Seems we mostly agree on the contents of the var payload (once LL reproduces our test vectors)
20:21:45 <cdecker> So in my mind, once they do, we can merge without further delays
20:21:48 <t-bast> let me summarize: apart from the exact feature bit to use and the pending LL implementation, we are good on the onion proposal?
20:21:59 <rusty> t-bast: ack.
20:21:59 <t-bast> cdecker: ack
20:22:03 <cdecker> We can certainly move the discussion about feature bits out
20:22:12 <cdecker> t-bast: ACK
20:22:16 <bitconner> idt the question of what an `integer` encoding is was ever addressed
20:22:42 <cdecker> It's the shortest binary representtion for a given number
20:22:56 <t-bast> bitconner: true, I think there are many small wording pending questions on the PR. cdecker could you do a pass on the pending comments and clarify?
20:23:18 <cdecker> 0x01 => integer 1, 0x0123 => integer 291
20:23:38 <cdecker> Sure, I can do that ^^
20:23:56 <rusty> Yes, I think #622 needs some bikeshedding love :)
20:24:03 <t-bast> cdecker: thx, and makes sense for the `integer` notation
20:24:32 <bitconner> sweet, yeah defining the varint encoding in the pr would be helpful
20:24:45 <cdecker> Shall I call it CompactInteger to differentiate from varint and fixed size integers?
20:24:47 <t-bast> so do we agree on the following next steps: cdecker will clarify pending questions, LL will finish their implementation and then we regroup on the github PR?
20:24:59 <rusty> t-bast: agreedd.
20:25:04 <cdecker> agreed
20:25:04 <roasbeef> or just `varint` in our context? do you we hav emore than 1?
20:25:45 <cdecker> roasbeef: varint has an implied size (it's part of the encoding) the integers in the payload have a given size (from being encoded in the TLV) hence no length encoding is required there
20:25:56 <bitconner> we use `varint` in the tlv proposal to refer to compact size
20:26:10 <roasbeef> varint and CompactSize are different?
20:26:15 <t-bast> I think we're using the terms without referring to the same thing :)
20:26:17 <roasbeef> i thought we wanted to use the same scheme everywhere
20:26:23 <cdecker> Yes, those are for types and lengths, but not to encode the actual numbers
20:27:19 <cdecker> We can use `varint`s to encode the data as well if desired, but it's redundant since the TLV already tells us its length
20:27:42 <t-bast> I think we have: `varint` (aka Bitcoin compact size) which encodes its length in its representation and uses 1, 3, 5, 7 or 9 bytes. And we have something else which cdecker named `integer`, which is an integer with all the `0x00` bytes stripped out (because the length is already encoded in the length part of the TLV).
20:28:08 <t-bast> Does that sound correct and clear enough? Maybe adding concrete examples (in the spec) will make it crystal-clear (in the test vectors?)
20:28:15 <cdecker> Ok, let me take a step back. We currently have 3 encodings for numbers: varint (bitcoin calls them compact size), fixed size integers (u16, u32, u64) and finally we have integers in the TLVs
20:28:45 <bitconner> would be nice if the 0's could be optionally stripped, so that one can encode a uint32 normally or add the optimization to strip 0x00's
20:28:45 <roasbeef> if we're making a new var int, we can make a much better encoding
20:28:49 <cdecker> The reason we can use "integers" in the TLV is because the L in the TLV tells us exactly how many bytes are part of the number
20:28:50 <roasbeef> just use 1 bit for "more bytes"
20:29:18 <niftynei> +1 for including concrete examples in the spec
20:29:29 <cdecker> roasbeef: but that's exactly the point, in the TLV we have the information about how many bytes are used to encode the number already, no need to encode the length in the number itself
20:29:45 <roasbeef> i mean using that format everywhere
20:29:45 <cdecker> +1 for niftynei's proposal, I'll come up with examples
20:29:48 <roasbeef> it's more compact
20:30:07 <roasbeef> that as in '1 bit is more bytes'
20:30:10 <cdecker> roasbeef: how would you represent 256 then in that new encoding as part of a TLV
20:30:48 <cdecker> Sorry 255 of course
20:30:51 <rusty> #622 calls them tu16, tu32 and tu64, FWIW
20:30:52 <roasbeef> basically something like this https://golang.org/src/encoding/binary/varint.go
20:31:10 <cdecker> In TLV with my encoding it'd be 0xAB01FF, type=0xAB, length=0x01, value=0xFF
20:31:15 <t-bast> I think the current TLV proposal is both flexible enough and simple enough that we don't need to re-invent the wheel here :)
20:31:17 <niftynei> as a bit of a dumb clarification, this 'truncated integer in a varint field' only applies to Types where the only 'field' is an integer, yes?
20:31:25 <roasbeef> or utf
20:31:33 <cdecker> niftynei: yes
20:31:34 <t-bast> niftynei: yes I think so
20:31:40 <niftynei> kk ty
20:31:45 <bitconner> rusty, is the idea that all integers encoded in tlv would use tu16, tu32, and tu64?
20:32:06 <rusty> bitconner: no, only as explicitly specced, since they have to be standalone.
20:32:09 <cdecker> tu = truncated unsigned???
20:32:18 <rusty> cdecker: or tlv integer, yeah.
20:32:23 <cdecker> Ah k
20:32:32 <rusty> cdecker: u == unsigned.  so we ahve u64, and tu64.
20:32:48 <bitconner> rusty, cool just double checking. for non-onion tlvs this could be a privacy leak
20:32:53 <roasbeef> seems weird to go down this truncated path, when there was push back for a better varint format with the rationale that we can use something "off the shelf" and everyone has libraries for it
20:33:04 <t-bast> bitconner: interesting point
20:33:29 <t-bast> bitconner: indeed we need to use that carefully to avoid traffic analysis from inferring amount ranges
20:33:31 <niftynei> well, i think you'd still use varint for specifying the length of the field, this is just for how to represent the actual value
20:33:35 <cdecker> roasbeef: the point here is that any form of varint auto-encodes its length (CompactSize uses the first byte, golang varints use the
20:33:40 <rusty> niftynei: indeed.
20:33:41 <cdecker> "there's more bit)
20:33:44 <roasbeef> the variable length stuff leaks info in any sense, since it tells you the ceiling of the # of hops after you
20:33:52 <roasbeef> when before you extracted the same amt of info
20:34:19 <cdecker> Ok, we're getting off track here, I'll write this thing up and add it to the PR, would that be ok?
20:34:29 <t-bast> cdecker: ACK
20:34:40 <rusty> cdecker: NO.  It's all in #622 already, shall we discuss that?
20:34:47 <cdecker> Ok
20:34:54 <t-bast> great let's do it
20:35:08 <t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/622
20:35:16 <cdecker> Let's discuss #622 and I'll amend #619 accordingly :-)
20:35:36 <rusty> OK, this seemed to get general approval, it's basically changing raw lengths to actual types.  I made up the types, roasbeef prefers to keep it more general.
20:36:01 <rusty> roasbeef: eg. I differentiated `chain_hash` from `sha256` (which it doesn't have to be, but do we care?)
20:36:33 <cdecker> Oh, I see tu16, tu32, and tu64, thanks rusty :-)
20:36:33 <rusty> Similarly, I differentiated `point` (tweaked to make a key) from `pubkey` (use as-is).
20:36:41 <t-bast> I think it's helpful for spec readers to see types that are more fine-grained
20:36:57 <t-bast> ie `chain_hash` instead of `bytes32`
20:37:18 <rusty> t-bast: well, 32*byte would also be legal.
20:37:33 <t-bast> It doesn't have to leak in the implementations anyway, it's only for readability right?
20:37:39 <niftynei> i'm in favor of keeping more specific 'type labels' on fields, as it makes tracing intent + instructions for use a bit easier
20:37:44 <cdecker> I like the more explicit types :+1:
20:37:46 <rusty> t-bast: exactly, there's no spec change here.
20:37:55 <t-bast> rusty: perfect then, that sounds good to me
20:38:06 <bitconner> +1 on adding types, it does help readability imo
20:38:09 <rusty> But it makes it easier to parse: we had to do some fuzzy matching on field names internally.
20:38:56 <rusty> I want this merged now because it's a scattergun change which will cause merge conflicts :)
20:39:07 <t-bast> :D
20:39:51 <cdecker> Yep, happy to rebase #619 right now ^^
20:40:02 <t-bast> nits: why are some of the types commented in the python code?
20:40:16 <t-bast> shall we remove those before merging?
20:40:29 <t-bast> or is it the description?
20:41:02 <rusty> OK, secret is only used in two places, and preimage in only one.  I'm happy to replace those by 32*byte, removing two boutique types.
20:41:09 <bitconner> does seem like there's a bit of redudancy in the types, but not a big deal i suppose
20:41:29 <rusty> t-bast: where?
20:41:32 <bitconner> rusty, ack
20:42:03 <t-bast> rusty: I went too fast on that, iiuc this is the explanation of what the code outputs
20:42:03 <niftynei> t-bast i think you're referring to the documentation, they're supposed to be example inputs for what the script outputs
20:42:15 <t-bast> niftynei: thanks for confirming, got it
20:42:27 <niftynei> :thumbs_up:
20:42:41 <bitconner> t-bast: `point` vs `pubkey`, `secret` vs `primage` vs `sha256`
20:43:07 <t-bast> sgtm
20:43:21 <bitconner> yeah but otherwise lgtm
20:43:22 <rusty> bitconner: we literally only use pubkey for `funding_pubkey` everything else is a point.
20:44:00 <rusty> bitconner: and calling a point a pubkey is kind of misleading, since it's never used that way.  I think the differentiation here is actually useful, TBH.
20:44:41 <bitconner> i was thinking the opposite, and make them all `point`s, but if you think the differentiation is useful then okay by me :)
20:45:16 <rusty> bitconner: I'm happy with that, actually.
20:45:24 <t-bast> that change looks good to me, roasbeef are you convinced?
20:45:35 <rusty> OK, so pubkey->point, and secret and preimage removed in favor of `32*byte`?
20:45:50 <t-bast> rusty: sgtm
20:45:52 <rusty> (Damn, we're getting faster at bikeshedding!)
20:45:54 <bitconner> sgtm1
20:46:00 <bitconner> !
20:46:37 <rusty> OK, happy for me to merge once those changed applied?  I can do it today.
20:46:47 <t-bast> rusty: ack
20:46:52 <bitconner> ack
20:46:58 <cdecker> ACK
20:47:18 <t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/607 -> short update?
20:47:21 <rusty> #action rusty to Change pubkey->point, and secret and preimage removed in favor of `32*byte` in #622 and then merge.
20:47:22 <cdecker> Sounds like we agree ^^
20:47:39 <t-bast> This is the TLV proposal we already agreed on.
20:47:55 <t-bast> Shall we wait for test vectors or merge this and then add test vectors afterwards?
20:47:57 <rusty> t-bast: I'll merge it today, too?
20:48:02 <bitconner> yes i think the outstanding thing is test vectors
20:48:03 <t-bast> rusty: oh yeah
20:48:05 <cdecker> I think with #622 out of the way, the last hanging issue for #619 (tu32, ...) is also now solved?
20:48:38 <rusty> t-bast: yes, I volunteer to do test vectors, as additional PR.
20:48:53 <t-bast> rusty: great! bitconner would this be ok for you?
20:49:10 <t-bast> I added my informal test suite to the PR, that might be helpful
20:49:33 <t-bast> cdecker: sgtm, I'd just like to choose a feature bit that's not already assigned before we merge #619 though, wdyt?
20:50:09 <cdecker> Sounds good, 40/41 still good for everybody?
20:50:09 <rusty> t-bast: looks like you've already done all the work!  I'll repro them and turn it into an Appendix...
20:50:11 <bitconner> sure that's fine by me, tho i don't see a rush in merging 607 until we have the test vectors
20:50:30 <rusty> bitconner: because merging is fun! :)
20:50:38 <t-bast> bitconner: I think it finally completely unblocks the channel_queries discussion which is a bit in limbo - and it shows progress
20:51:28 <t-bast> rusty: perfect thanks!
20:52:12 <t-bast> so shall we merge #607 now and have an action item on rusty to produce formatted test vectors?
20:52:18 <rusty> OK, do we want to go a bit meta on feature bit discussion?  I'm happy for the features to be assigned as they're spec-approved, and keep that #605 as a kind of waiting room.
20:52:30 <bitconner> t-bast, sure sgtm
20:52:36 <rusty> t-bast: sgtm
20:52:48 <rusty> Otherwise I think roasbeef was worried we're reserving for stuff which will never eventuate, which is fair.
20:52:48 <t-bast> great, I'm merging it (my first merge on the repo!)
20:53:02 <cdecker> Awesome, congrats t-bast ^^
20:53:06 <niftynei> yay!
20:53:28 <bitconner> 🎉
20:53:29 <rusty> 🎉
20:53:44 <t-bast> give me 5 minutes to open some champagne, I'll be back
20:54:01 <roasbeef> instead of 40/41 start from scratch imo
20:54:11 <t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/571 and https://github.com/lightningnetwork/lightning-rfc/issues/605
20:54:23 <niftynei> #action t-bast to get champagne for chatroom
20:54:29 <t-bast> This is the feature bit unification discussion
20:54:48 <t-bast> niftynei: we don't even have champagne emojis on irc :(
20:55:24 <rusty> t-bast: 🥂
20:55:29 <t-bast> I agree with roasbeef that it would be cleaner to prioritize variable-length onion in the feature bits over features that were discussed but not spec-ed
20:55:38 <t-bast> rusty: omg
20:56:10 <rusty> t-bast: OK, so then let's give 8/9 to cdecker for varonion.  Anyone object?
20:56:19 <t-bast> that sounds perfect
20:56:27 * cdecker wonders whether using a non-unicode capable IRC clients was a smart move...
20:56:39 <cdecker> rusty: ack
20:56:39 <t-bast> :)
20:56:59 <rusty> And I'll update the wording on #605 to indicate it's purely a waiting room for testing, and features get assigned on first-approved basis.
20:57:14 <t-bast> Good idea.
20:57:37 <cdecker> #action cdecker to update #619 to use feature bits 8/9 instead
20:57:50 <t-bast> On the feature bit PR itself
20:57:59 <cdecker> #action cdecker to update #619 with the tu32 and tu64 types from #622
20:58:05 <t-bast> We said last time that the names weren't convincing yet
20:58:20 <t-bast> I posted a few proposals on the PR, should we bikeshed naming proposals right now?
20:58:44 <rusty> t-bast: yes, I've been remiss on not revisiting naming :(
20:58:58 <roasbeef> was this ever addressed?
20:58:59 <roasbeef> 16:20 <+roasbeef> seems weird to go down this truncated path, when there was push back for a better varint format with the rationale that we can use something "off the shelf" and everyone has libraries for it
21:00:30 <t-bast> roasbeef: I think it's a misunderstanding over what cdecker meant by `integer` (which only needs the varint Bitcoin and TLV use), isn't it?
21:00:42 <cdecker> roasbeef: yes, we have some places where we have fixed size integers, no need for varints (and lose precision there), we have real varints (where we extract the length while parsing) and finally we have tu32, tu64 etc where the context (being inside a TLV) gives us the encoding legnth
21:00:55 <rusty> roasbeef: yeah, you're wrong ;)
21:01:33 <bitconne1> idt any of the varint schemes lose precision?
21:02:12 <cdecker> bitconne1: we use more bytes if we need to encode both the value and the length of the encoding in the same space
21:02:16 <cdecker> That's what I meant :-)
21:02:27 <roasbeef> but we may be able to save bytes by usin ga more compacrt format
21:02:44 <roasbeef> we're saving 1 byte with the trunacrtion atm?
21:03:00 <cdecker> roasbeef: there is no more compact format if we don't need to encode the encoding length inside the integer itself
21:03:03 <niftynei> i think we missed an action item where t-bast is merging #607 and rusty is turning the test vectors into an appendix in a new PR
21:03:18 <t-bast> nitfynei: thanks, adding those
21:03:24 <t-bast> #action t-bast merge 607
21:03:39 <t-bast> #action rusty add TLV test vectors in separate PR
21:03:49 <cdecker> roasbeef: if we have a value for msat of 255, in a TLV, then we'd use 3 bytes for the value using the compact size from bitcoin
21:03:58 <cdecker> we'd use 2 bytes for the golang varint
21:04:14 <cdecker> and we'd use 1 byte for the tu64 since we truncate the leading 0x00 bytes
21:05:06 <t-bast> honestly guys I think it we should focus more on improving bandwidth by using signature aggregation or smarter gossip algorithms that saving 1 byte in some integer cases...and it's more fun! just sayin' ;)
21:05:10 <cdecker> We can do that since the TLV actually tells us how many bytes are encoding the value, no need to redundantly store that in the value itself (which is what varints do)
21:05:25 <t-bast> I think the current proposal gives good enough trade-offs
21:05:38 <cdecker> Agreed, we can use u64 everywhere for all I care :-)
21:06:01 <rusty> We kind of get it for free though, so why not?
21:06:39 <cdecker> Yep, but if we're getting hung up on integer encoding one more meeting then I'm happy to go the least efficient rute
21:06:41 <t-bast> yes, we already have good optimizations with the current proposals, I don't think it's worth searching for different encodings, is it? we have more fun improvements to work on :)
21:06:58 <cdecker> Bikeshedding integer encodings here is not productive
21:07:09 <rusty> Anyway, we're over time, I promise to revisit the feature naming with t-bast before next meeting, and try to convince roasbeef that unification is A Real THing.
21:07:29 <roasbeef> t-bast: totally tangential really
21:07:55 <t-bast> roasbeef: shall we start a thread somewhere else and discuss that over the week?
21:08:09 <t-bast> or maybe schedule a video meeting to discuss this?
21:08:45 <t-bast> I think we'd be more efficient that way
21:09:07 <t-bast> rusty: were you able to make progress on the channel_queries implementation?
21:09:31 <rusty> t-bast: yeah, let's do it!  coord with roasbeef?  This time any day works for me, really.
21:10:00 <rusty> t-bast: unf not, got distracted writing protocol tests, and option_static_remotekey.
21:10:18 <t-bast> #action t-bast find a meeting slot with roasbeef and rusty to discuss integer encoding and feature bit unification
21:10:37 <t-bast> roasbeef: are you ok with that? I'll propose meeting slots to discuss this with rusty this week or next week
21:10:39 <roasbeef> static key >>>>>>>>> channel_queries im o
21:10:42 <roasbeef> imo*
21:10:58 <rusty> roasbeef: I know!
21:11:04 <roasbeef> as far as safety of users
21:11:22 <t-bast> rusty: no problem
21:11:25 <roasbeef> commented on that old diff, was going to start my own this week if didn't see any movement there
21:11:28 <rusty> roasbeef: I've got the pieces, just need to finish the protocol tests.  Had hoped to have it ready to present today, but school holidays...
21:11:48 <t-bast> Are there any other topics people want to discuss?
21:13:34 <rusty> Congrats on all three implementations for their recent releases :)
21:13:53 * cdecker would like to thank roasbeef for the really good BOLT 08 documentation
21:14:10 <cdecker> I reimplemented the handshake over the weekend in python and it was a breeze :-)
21:14:36 <t-bast> I wanted to get everyone's opinion on something. We have many small sentence clarification PRs from contributors that have been ignored for a while. Do we want to merge those? How should we organize ourselves to review them somewhat quickly?
21:14:55 <rusty> Oh, and I've got protocol testing working, up to HTLC acceptance and failure, and reconnection during HTLC during.  Next step: option_static_remotekey.
21:15:18 <t-bast> rusty: nice!
21:15:19 <cdecker> t-bast: shall we just give like 5 of the small things as homework?
21:15:30 <rusty> t-bast: shall we merge them under the "spelling" rule which requires two approvals, no dissent, and no meeting?
21:15:34 <cdecker> Like a small reading assignment?
21:15:50 <t-bast> cdecker: that's a good idea - I think 2 approvals would be enough for all the simple ones right?
21:16:00 <cdecker> With the warning that they will either be merged, or closed during the next meeting (just to up the pressure a bit)
21:16:17 <cdecker> t-bast: agreed
21:16:40 <rusty> OK, please tag them as "spelling" then, for clarity.
21:17:07 <t-bast> Ok here's what I suggest: let's make a list of 5 of them to review, notify all of us about those 5, and once we have 2 approvals we merge
21:17:25 <rusty> t-bast: ack.
21:17:33 <t-bast> Everyone ok with this? I can work on that list and we can make progress 5 by 5 every 2 weeks.
21:18:00 <t-bast> I'll ping people on github to get either the two approvals or a dissent
21:18:00 <niftynei> sgtm
21:18:14 <t-bast> bitconner, roasbeef, what's your opinion on that?
21:18:23 <cdecker> ACK
21:18:46 <t-bast> bitconner has already reviewed some of those, we exchanged some comments on a few
21:22:47 <t-bast> #action t-bast select 5 clarification PRs and assign reviewers / get them merged sooner than later
21:23:21 <t-bast> Do we have ending remarks from the audience or shall we end the meeting for today?
21:23:32 <cdecker> sgtm
21:24:22 <t-bast> #endmeeting