20:05:59 <rusty> #startmeeting
20:05:59 <lightningbot> Meeting started Mon May 27 20:05:59 2019 UTC.  The chair is rusty. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:05:59 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:06:45 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/593
20:07:17 <cdecker> Yay :-)
20:07:18 * rusty tries to remember how to drive this thing...
20:07:29 <t-bast> :)
20:08:03 <cdecker> So, since last meeting I changed the split to 5bits num_frames + 3 bits payload type
20:08:18 <cdecker> Added the multi-frame test vector that I forgot
20:08:31 <t-bast> sgtm and tested the updated vector against the eclair implementation: works great
20:08:36 <cdecker> Spelled out the explicit packet-type 0x01 + num_frames combinations
20:08:39 <roasbeef> anyone have an answer to my q on there? not saying we need to modify things, but just curious to see if there's some gap in my understanding i'm over looking
20:09:00 <t-bast> roasbeef: the one about the frame size?
20:09:04 <bitconner> roasbeef, no idt we're tied to fixed-size frames
20:09:09 <roasbeef> t-bast: yeah
20:09:19 <rusty> #info Ping bitconner BlueMatt cdecker jb55 jimpo niftynei pm47 roasbeef sstone and anyone else i missed.
20:09:21 <roasbeef> consider it a pedagogical question
20:09:23 <t-bast> I answered on the PR, we're not tied to anything
20:09:39 <t-bast> but it would be a breaking change (something we can introduce for other version of the onion)
20:09:40 <bitconner> after unwrapping and shifting, the next hop won't be able to tell what frame size is used before or after
20:09:52 <t-bast> and I agree it makes sense for future versions to consider it
20:10:02 <roasbeef> your answer made it seem as if it would violate any existing security notions
20:10:16 <roasbeef> ah, new comment
20:10:39 <t-bast> I initially hadn't understood that your question was just about changing the frame size
20:10:51 <rusty> roasbeef: It's a very good point, actually.
20:11:25 <rusty> Seems like, other than "legacy reasons" there's no obv reason to go in 65-byte chunks.
20:11:33 <t-bast> it's something I took advantage of for trampoline routing: I proposed a bigger frame size, but actually a smaller one might make even more sense
20:11:50 <t-bast> I think onion v1+ can change the frame size freely
20:11:55 <cdecker> Yep, I don't see anything wrong with making it more flexible
20:12:35 <bitconner> t-bast i think the idea would be to not have frame sizes at all, but rather making each one variably sized iinm
20:12:39 <rusty> Strawman: 0 == 65, N != 0 == N + sizeof(hmac) ?
20:12:44 <cdecker> It'd take a bit more time though and some refactoring (further pushing this back)
20:13:23 <cdecker> rusty: that limits us to 256 bytes of payload though
20:13:24 <t-bast> bitconner: interesting, I'd need a bit more time to convince myself that this doesn't change the security assumptions
20:13:39 <cdecker> t-bast: it doesn't :-)
20:14:10 <rusty> cdecker: If there were... some kind of variable... integer... thing. But nobody has invented that yet!
20:14:28 <cdecker> So do we really want to add some more weeks to this whole variable size onion?
20:14:42 <cdecker> lol rusty
20:14:43 <rusty> cdecker: not if we can come to agreement at this meeting :)
20:15:14 <cdecker> Well, we can come to an agreement now, but that still requires reworking the implementations and re-writing the spec changes
20:15:36 <cdecker> So that's at least 2 more weeks to have a chance to get this working
20:15:38 <rusty> roasbeef, bitconner: how about we do the varint thing, with 0 being legacy?  Otherwise it's a varint (length of hmac at end is implied).
20:15:57 <rusty> And non-zero means it contains TLV format, of course.
20:16:07 <rusty> This *also* solves the sentinel problem!
20:16:10 <jtimon> ghost43: I guess we can continue this after the meeting, but the chain_hash is included in the channel_announcement just like the node_id (except there's no need for a bit to specify the direction)
20:16:13 <t-bast> that sounds like a good idea
20:17:09 <rusty> cdecker: future generations will thank you for your patience.
20:17:26 <jtimon> ghost43: but if I understand you correctly, your answer is, because this way you filter out messages more eaasily, correct?
20:17:27 <cdecker> Ok
20:18:04 <rusty> Does anyone have any objections?  It means losing the "realm" bits altogether, though.
20:18:31 <cdecker> sgtm
20:18:44 <bitconner> rusty, would that mean we now only distinguish between realms of 0 and non-zero?
20:18:52 <t-bast> sgtm to explore this, we can comment more on the PR in the next few days
20:18:57 <roasbeef> so what's the new encoding? assumed_65_bytes + some_other_bytes_here?
20:19:07 <rusty> bitconner: yes, we'd now be relying on the TLV format being sufficient in future.
20:19:09 <bitconner> it is nice that it removes the need for a sentinel
20:19:31 <cdecker> Was there ever a need for a sentinel? I thought we said none were needed
20:19:36 <roasbeef> yeah ran into the sentinel thing again when I tried to hook together tlv+hopframes
20:19:56 <roasbeef> the issue is that once you have the payload, you don't know where the tlv actually stops, since there's framing
20:20:01 <roasbeef> padding*
20:20:02 <rusty> roasbeef: 0 == legacy, non-zero == varint length-before-hmac.  non-zero also implies contents is TLV.
20:20:03 <cdecker> roasbeef: realm = 0 => hop_data_v0 (65 bytes), realm != 0 => varint size and TLV payload
20:20:27 <roasbeef> so you have a value you've extracted, but then there's 8 extra bytes, you don't know those 8 are extra, and try to hash it as if it's a pre-image, no match
20:20:30 <t-bast> rusty: this is great because it means we don't lose any byte to padding
20:21:11 <t-bast> it kinda defers the realm thing to the content of the TLV stream and agreeing on "standard" streams
20:21:13 <roasbeef> cdecker: gotcha, so where's this new length go? still packed in realm?
20:21:26 <rusty> t-bast: yeah, I think we have to thank roasbeef for asking "dumb questions" here.  I promise I'll never call him annoying again :)
20:21:35 <rusty> roasbeef: yeah.
20:21:35 <cdecker> rusty wants it to be a varint
20:21:43 <bitconner> idt the realm is big enought, it'd be 65-byte + varint length + tlv stream + mac
20:21:47 <t-bast> haha there are no dumb questions :)
20:22:07 <cdecker> bitconner: what's the 65 bytes in there?
20:22:17 <roasbeef> the existing payload I think
20:22:26 <roasbeef> (tho leaves off those 13 unused bytes atm)
20:22:51 <cdecker> Nono, we encode the entire payload into a single TLV and the varint length describes the entire payload length
20:23:08 <cdecker> Therefore it is [varint, TLV, next HMAC]
20:23:09 <roasbeef> including the current "routing instructions" payload?
20:23:12 <bitconner> i see
20:23:32 <cdecker> Yes, we want to make the routing instructions flexible by making it into a TLV
20:23:36 <rusty> cdecker: s/TLV/TVL stream/
20:23:47 <roasbeef> ah, that was #604, thought we were talking about #593, so going back in that direction after all?
20:24:04 <roasbeef> (routing instructions in tlv like the rest, no hybrid)
20:24:07 <bitconner> we did discuss possibly including legacy info on its own, then adding tlv tlv
20:24:07 <cdecker> That way we can swap out parts we can in the future (shorter next-hop descriptions, shorter value descriptions, ...)
20:24:33 <bitconner> can we agree that the legacy info all fits in one record?
20:24:40 <cdecker> Right, but that's limited to 32 bytes since only realm 0x00 is non-TLV
20:24:43 <rusty> bitconner, roasbeef: I think it's cleaner to leave v0 alone, and go full-tlv for others.  We get to save some space.
20:24:48 <t-bast> small note: would that still be for onion v0?
20:25:11 <roasbeef> rusty: basically what #604 suggested right?
20:25:19 <cdecker> t-bast: yes, not touching the onion version itself
20:25:38 <t-bast> it would effectively be using up all the current non-0 realms for onion v0 - and still having the opportunity to update the onion version for other types of changes (like changing the size of the whole packet)
20:25:41 <rusty> Yeah.
20:25:42 <bitconner> yeah i'm fine with tlv everything
20:25:43 <t-bast> cool I agree to that
20:26:10 <t-bast> so now that means we need to agree on the TLV format :D
20:26:21 <bitconner> would be great if hash, amt, cltv all fit in one record though, so we incur the miminal T+L overhead
20:26:24 <rusty> OK, I think we have consensus, just need to type it up and make sure we've colored the bikeshed correctly on the issue.  Or should we open a new one, since it's quite a change?
20:26:24 <cdecker> bitconner: sure, we can make the hop_data_v0 a single type-value pair, but then we'll need to swap it out entirely if we want to replace a part of it
20:26:34 <bitconner> cdecker, sgtm
20:26:35 <roasbeef> cool, gonna throw this comment back out there then: https://github.com/lightningnetwork/lightning-rfc/pull/604#discussion_r285790465  ;)
20:26:54 <roasbeef> related comment there from decker that it's nice to be able to swap out induvidual items as well
20:27:05 <rusty> bitconner: turns out that's *larger*, since TLV per amt + CLV uses less space in practice.
20:27:45 <rusty> (Numeric fields should *not* be fixed length,that's just wasteful)
20:27:45 <cdecker> Yep, especially amount and CLTV can be nicely compressed even if we use TLV
20:28:07 <bitconner> yes, but those can be compressed *and* still fit in one record, which is what i'm getting at
20:28:28 <cdecker> If we transfer < 256 msat we get a nice 3 byte representation for the value :-)
20:28:56 <cdecker> Honestly don't care enough at this point
20:28:58 <rusty> bitconner: ?  How would you encode two variable-length values in one TLV?
20:29:24 <bitconner> add a sentinel :^)
20:29:40 <cdecker> I'll get working on the variable lenght onion and you guys figure out the payload format...
20:29:40 <bitconner> jk, this can bikeshedded later tho
20:29:45 <rusty> bitconner: lol.  Or, y'know, use the existing tlv format and just ahve several :)
20:30:07 <rusty> OK, NP.  I think we should start a new issue, since otherwise readers will get whiplash trying to follow?
20:30:16 <cdecker> bitconner: let's not defer everything to later, we've been sitting on the multi-frame + TLV proposals for months now...
20:30:36 <roasbeef> bitconner: why do we need a sentintel if the payload is precisely sized?
20:31:00 <roasbeef> ah multiple values in a single type?
20:31:04 <bitconner> roasbeef, this was re: inside a record, but it was also a joke
20:31:15 <bitconner> cdecker, understood
20:31:58 <rusty> #action cdecker to create new varint onion proposal: 0 = legacy, non-0 = varint TLV-stream-length-before-hmac.  Details in proposal, but we seem to have consensus.
20:32:05 <rusty> OK, phew!
20:32:09 <rusty> Shall we TLV now?
20:32:13 <t-bast> sgtm, great idea guys
20:32:15 <t-bast> let's TLV
20:32:25 <t-bast> and everything can come together nicely
20:32:54 <roasbeef> lingerin questions here seem to be: even odd or not, sentintel (tho i think just solved?), and cannonical encodings?
20:32:56 <rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/607 vs https://github.com/lightningnetwork/lightning-rfc/pull/603 FIGHT!
20:32:57 <roasbeef> (tlv)
20:33:10 <t-bast> indeed sentinel just got obsolete
20:33:37 <rusty> Yeah.  So technically odd/even rule is redundant in some contents.  Like in our p2p messages (you should never send me an unknown even without feature negotiation!).
20:33:58 <roasbeef> i think another one is: unified format, or diff for onion vs wire msgs
20:34:10 <rusty> But in my experience it turns out to give sane errors as protocol gets older and dealing with ancient peers.
20:34:23 <t-bast> I think we can have a unified one, there's nothing requiring a different one for onion if we get rid of sentinel
20:34:33 <bitconner> so idt the debate is best framed as either or, rather i think the goal was to determine where 603 and 607 should inserect, and what differentiates them
20:34:34 <rusty> (like, ones that fall out of your test matrix because we assume everyone supports FOO now)
20:34:49 <rusty> bitconner: yeah, topic was kind of a joke, sorry.
20:35:03 <rusty> t-bast: agree on unification.
20:35:03 <bitconner> rusty, i figured, just clarifiying :)
20:35:20 <rusty> bitconner: they're basically identical, TBH, with trivial differences.
20:35:57 <t-bast> concerning even/odd, I think that in a perfect world, only the top-level message type should need it and TLV shouldn't (every unknown TLV should be considered optional). However in the real world, even/odd could be a simple rule that helps things go more smoothly.
20:36:27 <rusty> Yeah, and it turns out to be easy to implement in the parser, at least for us.
20:36:38 <rusty> (We treat unknown even TLVs like any other malformation)
20:37:56 <t-bast> I agree with rusty that the risk is an explosion of feature bits that become very hard to properly configure and maintain...but I can't be 100% sure that we'll avoid it even with the even/odd rule
20:38:12 <rusty> t-bast: sure, but as you say, it's simple.
20:38:23 <bitconner> keep in mind, that feature bits are only required if we need to negotiate whether a field should be required
20:38:35 <bitconner> otherwise, they are implicitly optional
20:38:43 <rusty> Re: type.  I'm happy with 1 byte type, because we can always define inner type later if we start running out.  OTOH cdecker had an idea we could use types 32k+ for experimental use.
20:39:09 <rusty> bitconner: agreed.  But the odd/even rule makes people think harder about it, whether it can be ignored.
20:39:15 <t-bast> pragmatically, it sounds like keeping the even/odd rule means staying on the safe side of things
20:39:30 <roasbeef> what does it protect against though?
20:39:43 <roasbeef> historically, it's caused a good bit of confusion for the wire messages
20:39:50 <cdecker> Yes, I'd like to reserve types with a short representation (<256) for common use-cases that are spec'd
20:39:51 <roasbeef> we've had to modify the wording a few times to make it more clear
20:40:00 <roasbeef> doesn't it also cut into the existing tlv namespace?
20:40:32 <rusty> roasbeef: really, I don't recall any modification to the odd/even wording?  It's been one thing which has always worked?
20:40:46 <bitconner> gossip messages, e.g., cannot have required fields
20:41:42 <rusty> bitconner: of course they can!  You just need to tell me you understand them first, before I relay it to you.
20:41:42 <roasbeef> a while back there was confusion if even was the bit position, or the value iirc
20:41:45 <roasbeef> https://github.com/lightningnetwork/lightning-rfc/pull/102
20:42:06 <rusty> roasbeef: oh yeah :) That's true.
20:42:18 <bitconner> rusty: and partition the gossip network?
20:42:36 <rusty> bitconner: schnorr gossip will do this, for example, yes.
20:42:45 <t-bast> the only downside to even/odd is that it constrains a bit more the types we can use (if we don't have the same amount of required vs optional types, we're wasting some bits in the T part of TLV) - is there any other downside?
20:43:00 <t-bast> if that's the only downside it's more about estimating if we'll need more optional or more required types
20:43:07 <rusty> "127 types should be enough for anyone!"
20:43:16 <t-bast> X)
20:43:49 <bitconner> rusty: we've discussed ways of introducing schnorr gossip that won't partition the network
20:44:39 <rusty> bitconner: yeah, by replicating.  But at some point, some client will stop sending out old-style gossip.  That's OK, right?  But this is exactly where we'd use an even TLV, too.
20:44:42 <bitconner> plus partioning the network over changing the signature algo makes much more sense rather than a single signed field
20:45:33 <rusty> bitconner: the cases are analogous.  I'm not saying we'll hand out even gossip TLV fields easily, but I'm saying I can think of cases where we'll want to.
20:46:40 <bitconner> rusty: tbh i'd rather just make a new message type at that point
20:46:55 <bitconner> otherwise the message will still have a blank 64-byte region anyway
20:47:29 <rusty> Sure, and maybe we never decide to use an even field, but I think it's worth having in case we do want a breaking change.
20:47:56 <rusty> ( I *would* use them for breaking changes that should never escape the lab, I guess? )
20:48:33 <rusty> Anyway, 1 byte type is enough, or do we go full varint?
20:49:07 <rusty> bitconner: I think you were tending to 1-byte, I have a vague preference for varint.  Anyone else have an opinion?
20:49:12 <roasbeef> for type or length?
20:49:16 <rusty> roasbeef: type.
20:49:21 <t-bast> I still prefer the varint, it's more flexible and still costs only 1 byte in most cases
20:49:35 <bitconner> so if we go the varint type, there is the edge case i discussed on the PR that would need to be addressed
20:49:37 <t-bast> it's cleaner than having to nest another type imo, but I'm not strongly against it
20:49:38 <roasbeef> 1 byte pref here, we can always use a designated type for extensions or nested fields
20:49:59 <rusty> bitconner: edge case?  Re-reading now....
20:50:01 <cdecker> Definitel varint for type for me
20:50:23 <cdecker> Composite types across a number of fields is hell to maintain
20:50:30 <bitconner> since there's no sentinel, the stream should be allowed to producing an EOF while reading type
20:50:37 <bitconner> for 1-byte type, this just means 0 bytes were read
20:50:52 <bitconner> for varint, it may not be the case. we have read the flag 0xfe byte, and then got an EOF
20:51:07 <t-bast> then it's an error, isn't it?
20:51:10 <bitconner> q is whether that should be silenced or permitted, and whether that byte should be included in the "strea,"
20:51:41 <bitconner> t-bast: yes, but it's an EOF, and currently with 1-byte we silence the EOF under the assumption that nothing was actually read
20:51:41 <rusty> bitconner: meh.  If you ran out of bytes before you started pulling the varint, you're at the end.  If you start pulling and run out of bytes, it's malformed.
20:52:00 <t-bast> I agree with rusty on that
20:52:03 <bitconner> rusty: but it's the same error that's produced when no bytes are read, which should be valid
20:52:21 <cdecker> I still don't get why everybody wants "TLV streams", a single TLV that just has all the key-value pairs ought to be enough, or what am I missing?
20:52:28 <bitconner> (i ended up having to change the errors returned from default CompactSize to avoid this)
20:52:49 <cdecker> And if we say that we have X bytes, but then truncate the message at <X bytes that's an error and the bloody message ought to b discarded
20:52:50 <rusty> bitconner: this is literally a "while size > 0: { type = read_varint(); len = read_varint(); val = read_more(len); }"
20:54:26 <roasbeef> cdecker: i don't think "stream" here means anything other than a blob of tlv values, where you may not know the total size ahead of time from teh pov of the parser
20:54:29 <rusty> Trying to pull the type and failing is a layering violation.  You can get away with that if it's 0 or 1 byte though.
20:54:49 <rusty> roasbeef: you will always know total size, now we fixed the onion.
20:55:11 <cdecker> roasbeef: gotcha, I misremembered it as being multiple TLVs one after the other
20:55:36 <cdecker> (and we do know the length of the TLV stream we are reading in all cases now with the variable frames)
20:55:54 <bitconner> rusty: yes, if nothing else the language will need to be changed in the current proposal
20:55:59 * cdecker is slow with typing today :-)
20:56:58 <t-bast> hum no we don't always know the whole size of the stream, that's kind of the goal because we want to be able to add new optional tlv types to the stream without having to go back to the spec of a specific message type (for non-onion messages)
20:57:05 <bitconner> the effects are somewhat impl specific, so just pointing out that it may require modifying CompactSize depending on your impl...
20:57:32 <cdecker> t-bast: we always know the length of the fields in the TLV, but the message framing also means we know the length of the TLV overall
20:57:41 <rusty> bitconner: but don't mistake me arguing coding technicalities from actually caring too much about type encoding though!
20:58:00 <rusty> cdecker: I like bitconner's "tlv stream" phrasing here.
20:58:07 <cdecker> t-bast: every message that may include a TLV now is prefixed with a size
20:58:12 <t-bast> cdecker: yes but for non-onion that's not the case, the message framing would like to be free of not specifying its length right?
20:58:29 <t-bast> cdecker: oh really? I hadn't seen that in the proposal, ok
20:58:39 <cdecker> Well for existnig messages we'd just define anything appended to the end as being the TLV
20:58:51 <cdecker> (also prefixed by a size)
20:58:52 <bitconner> rusty: seems we are headed towards varint?? :)
20:59:10 <bitconner> t-bast: all wire messages have a known length?
20:59:31 <t-bast> but don't we want to enable the following scenario? I define new gossip message `my_gossip` and specify that it contains a TLV stream of unknown size
20:59:58 <rusty> bitconner: I think so, but it's a bit of a line ball IMHO.
21:00:10 <bitconner> we have to serialize it first, write the message's size in the header, then send the message
21:00:32 <bitconner> rusty: yeah, i'm partial to 1-byte type, but see the use cases for extensions
21:00:36 <rusty> t-bast: how do you send a message of unknown size?  How would I know you've finished sending it? :)
21:01:12 <t-bast> that's true, I wanted to say "I'd close the connection so EOF" but we use long-lived single connections :)
21:01:33 <t-bast> got it then
21:01:48 <bitconner> fwiw i did some quick maths and found that nesting/concatenating tlv streams actually performs better than using a varint in the vast majority of cases
21:02:43 <roasbeef> t-bast: it's bounded rather than unknown
21:02:45 <cdecker> How so? Presumably we'll use the short single-byte representations for type and length for the really common things
21:02:59 <t-bast> roasbeef: got it, makes sense now
21:03:12 <cdecker> And have experiments run on multi-byte types that are not as rare
21:03:17 <bitconner> cdecker, they only differ when needing to encode types that would otherwise require a varint ;)
21:03:56 <cdecker> Right, but in those cases dragging context around to interpret the type seems like a worse tradeoff tbh
21:04:25 <rusty> bitconner: you mean allocating type=255 to mean "subtype is first two bytes inside the TLV"?  That seems to be equivalent to a varint type, but loses the odd/even rule.
21:05:56 <bitconner> idts, i mean type=255 is tlv_stream, also with one byte types. nesting one layer gives you values in the range 0-254*2
21:06:20 <bitconner> for every item in the nested tlv, we only need 1 byte to signal it's type instead of 3
21:06:26 <rusty> bitconner: yeah, but if we've hit 255 already, we'll def want two-byte inner types.
21:06:35 <cdecker> Yeah, but that results in weird groupings into sub-tlvs that have the same prefix...
21:06:50 <cdecker> Composite keys are not nice, just trust me
21:06:51 <rusty> OK, this has dragged on :(  We still have to cover what varint encoding we want to use, and canonicalization rules.
21:07:35 <rusty> bitconner: it's basically boutique vs CompactInt.  I don't think there's enough benefit to justify not reusing CompactInt.
21:07:47 <bitconner> rusty: agree. varint encoding?
21:08:00 <t-bast> sgtm
21:08:23 <rusty> bitconner: you suggested a boutique encoding (255 == two extra bytes), vs the existing bitcoin one.
21:08:59 <bitconner> yeah, mainly to avoid handling 64-bit types if we went the route of varint type
21:09:17 <bitconner> also bounds the decoded length to the max msg size
21:09:22 <rusty> We currently have a 64k msg limit, so bitcoin one is overkill of course.  But I think existing standards win.
21:09:22 * cdecker votes against reinventing the wheel
21:09:28 <roasbeef> bitcoin one is max 8 bytes?
21:09:36 <rusty> roasbeef: 9 total, yeah.
21:09:41 <roasbeef> yeah seems like more than we need
21:09:43 <bitconner> 9 bytes on the wire, but max 8-byte value
21:09:59 <bitconner> cdecker, it's more like deleting parts of an existing wheel :)
21:10:03 <roasbeef> would that mean i can create two distinct encodings of the same value?
21:10:10 <roasbeef> length wise
21:10:28 <bitconner> roasbeef, they should be minimally encoded
21:10:37 <roasbeef> gotcha makes sense
21:10:59 <rusty> roasbeef: yeah, you need to insist on minimal encodings.  There are encodings which don't have this problem but they're ugly in even worse ways.
21:11:12 <cdecker> bitconner: have you tried removing part of a wheel before? It hurts your back :-)
21:11:43 <rusty> I think it's overkill but we can just reuse it and move on.  For us, it's No New COde, which is nice.
21:12:12 <bitconner> if we only use varint for length, compactsize i think is fine. if we also use it for types, i'd prefer the stripped down variant
21:12:34 <bitconner> or can we at least say clamp all types to be 16-bits?
21:12:36 <rusty> bitconner: OK, shall we compromise on 1 byte type, and CompactSize for length?
21:12:58 <rusty> bitconner: hmm, autoreject 254/255-starting lengths?
21:13:07 <bitconner> yeh
21:13:07 <rusty> s/lengths/varints/
21:13:27 <bitconner> which is why i ended up just making the boutique version :P
21:13:40 <cdecker> That doesn't mean we use nested TLVs though, right?
21:13:51 <cdecker> (to expand the type space again)
21:13:58 <bitconner> no we have varint, prob no nesting
21:14:02 <rusty> bitconner: hmm, that destroys the experimental-types-start-at-64k idea though.  In effect, lengths of that amount will be autorejected anyway by a parser.
21:15:03 <bitconner> also destroys my plan to make a type for every atom in the universe :(
21:15:13 <rusty> bitconner: I actually lol'ed.
21:15:48 <bitconner> lolol
21:16:30 <rusty> OK, I think this unf. needs more bikeshedding.  Can bitconner and I get together sometime this week and try to come to agreement on this and canonicalization?  Are others happy for us to come back with a unified proposal?
21:16:36 <bitconner> my thoughts are that we should do a varint type, because either way it will end up less complex than nesting
21:16:46 <t-bast> rusty: sgtm
21:17:01 <bitconner> rusty: sounds good!
21:17:03 <cdecker> +1
21:17:08 <rusty> We're *so close* that it seems like we just have to thresh through the possibilities.  Thanks
21:17:18 <cdecker> And +1 on varint types
21:17:32 <rusty> #action bitconnor and rusty to flip coins until TLV proposals unified.
21:17:34 <roasbeef> vary, the length shall
21:17:50 <rusty> OK, unf. we're out of time, but good meeting!
21:18:01 <rusty> #endmeeting