--- Log opened Mon Jul 08 00:00:04 2019
00:05 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 272 seconds]
00:06 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
00:16 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 248 seconds]
00:16 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
00:21 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
00:21 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 258 seconds]
00:22 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
00:31 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
00:32 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
00:37 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
00:45 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev
00:47 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
00:47 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 244 seconds]
00:50 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Remote host closed the connection]
00:51 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
00:52 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 248 seconds]
00:56 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
01:02 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
01:06 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
01:06 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 248 seconds]
01:08 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
01:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
01:20 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]
01:27 -!- darosior [6dbe8dc1@193-141-190-109.dsl.ovh.fr] has joined #lightning-dev
01:39 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
01:43 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev
01:44 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 244 seconds]
01:47 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 276 seconds]
01:55 -!- reallll is now known as belcher
02:38 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
02:44 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]
02:45 -!- booyah [~bb@193.25.1.157] has joined #lightning-dev
02:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
03:09 -!- shesek [~shesek@141.226.145.179] has joined #lightning-dev
03:09 -!- shesek [~shesek@141.226.145.179] has quit [Changing host]
03:09 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
03:10 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
03:13 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev
03:16 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 272 seconds]
03:20 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
03:28 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 244 seconds]
03:29 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
03:39 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 272 seconds]
04:03 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
04:08 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 258 seconds]
04:40 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 260 seconds]
04:42 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #lightning-dev
04:42 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
04:47 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 244 seconds]
04:49 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
04:58 -!- cdecker [~cdecker@mail.snyke.net] has joined #lightning-dev
04:59 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 268 seconds]
05:26 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
05:29 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]
05:30 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 268 seconds]
05:35 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
05:38 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
05:45 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 248 seconds]
05:46 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
05:55 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
05:56 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 246 seconds]
06:04 -!- sh_smith [~sh_smith@cpe-76-174-142-242.socal.res.rr.com] has joined #lightning-dev
06:05 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
06:19 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
06:20 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
06:29 -!- Guest61179 [~jason@101.132.74.90] has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
06:33 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds]
06:34 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
06:35 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
06:40 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
06:45 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 258 seconds]
06:46 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
06:47 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
06:53 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has quit [Ping timeout: 258 seconds]
06:58 -!- llfourn [~llfourn@n114-73-101-240.sbr1.nsw.optusnet.com.au] has joined #lightning-dev
07:11 -!- davterra [~tralfaz@178.128.106.205] has quit [Ping timeout: 258 seconds]
07:13 -!- davterra [~tralfaz@178.128.106.205] has joined #lightning-dev
07:15 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has quit [Ping timeout: 248 seconds]
07:20 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has joined #lightning-dev
07:29 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has quit [Ping timeout: 246 seconds]
07:33 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has joined #lightning-dev
07:38 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #lightning-dev
07:38 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Changing host]
07:38 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev
07:43 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #lightning-dev
07:59 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #lightning-dev
08:09 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
08:12 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #lightning-dev
08:54 -!- sfhi [~sfhi@178.255.154.107] has joined #lightning-dev
08:58 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection]
09:05 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
09:16 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:23 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
09:31 -!- darosior [6dbe8dc1@193-141-190-109.dsl.ovh.fr] has quit [Remote host closed the connection]
09:42 -!- StopAndDecrypt_ [~StopAndDe@197.189.219.146] has joined #lightning-dev
09:46 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 272 seconds]
09:47 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #lightning-dev
09:55 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds]
10:01 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
10:12 -!- davterra [~tralfaz@178.128.106.205] has quit [Read error: Connection reset by peer]
10:34 -!- davterra [~tralfaz@209.58.184.163] has joined #lightning-dev
10:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
10:58 -!- sfhi [~sfhi@178.255.154.107] has quit [Quit: Leaving]
11:29 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
11:30 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
11:35 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 245 seconds]
12:33 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]
12:42 -!- t-bast [~t-bast@2a01:e34:ec2c:260:21e4:48eb:8ce9:41de] has joined #lightning-dev
12:47 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
12:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
12:58 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
12:59 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
12:59 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
13:00 < t-bast> hello everyone!
13:00 < niftynei> hello!
13:00 < cdecker> Heya
13:00 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has joined #lightning-dev
13:00 -!- hiroki_ [d295fef1@241.254.149.210.rev.vmobile.jp] has joined #lightning-dev
13:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
13:01 < rusty> Hi all!
13:01 < sstone> Hi!
13:01 < t-bast> hey rusty
13:02 < t-bast> do we have a chair tonight?
13:03 < t-bast> or I can do it if no-one wants to :)
13:03 < rusty> t-bast: I think that's an excellent idea!
13:03 < bitconner> howdy!
13:03 < t-bast> hey bitconner
13:03  * cdecker votes for t-bast as chair ^^
13:03 < rusty> t-bast:  there's a cheat-sheet at https://wiki.debian.org/MeetBot
13:03 < sstone> hi conner!
13:03 < t-bast> is roasbeef around? should we wait a bit before starting?
13:04 < bitconner> yeah he's here, think he's just setting up
13:04 < t-bast> rusty: thanks!
13:04 < t-bast> allright let's wait a bit for roasbeef
13:04 < rusty> Or you can copy from prev minutes :)
13:04 < t-bast> heh
13:05 <+roasbeef> iiiiiii'm ready 
13:05 < t-bast> cool, hey roasbeef
13:05 < t-bast> #startmeeting
13:05 < 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.
13:05 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:05 < t-bast> #topic the allmighty variable-length onion: https://github.com/lightningnetwork/lightning-rfc/pull/619
13:06 < cdecker> Thanks for providing the additional steps t-bast, I only saw the request for extra info today
13:06 < t-bast> I hope it will help debug this, troubleshooting onion encryption is always a pain :)
13:06 < cdecker> Yep, definitely
13:06 < t-bast> On the spec side, does someone have something to say?
13:07 <+roasbeef> yeh i think it's just something with the hop serialization, or some interaction when they're intermingled 
13:07 < t-bast> Or do we all agree on the PR as it is today?
13:07 <+roasbeef> seems perhaps #622 should go in before that 
13:07 < cdecker> Well, let's wait for LL to reproduce, then we can merge
13:07 <+roasbeef> as it still has stuff like "integer"  
13:07 < 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.
13:08 < rusty> roasbeef: agreed.  cdecker: agreed.
13:08 < t-bast> ok good
13:08 < t-bast> I think there's one thing we can update though
13:08 < t-bast> the current feature bit uses 0/1 which won't play nicely with feature bit unification
13:09 < t-bast> I think we should change that to a currently unassigned bit pair to make it simpler to do feature bit unification, WDYT?
13:09 < cdecker> SGTM
13:09 < cdecker> Any proposal?
13:09 <+roasbeef> we'll also need some BOLT 11 updates likely as well, but that'll prob be dependent on the exact payment scheme used 
13:09 < bitconner> do we also need the invoice tags?
13:09 < t-bast> I think we can add the Bolt 11 changes in a separate PR, can't we?
13:10 <+roasbeef> still in the dark w.r.t the motivation for the feature bit unification 
13:10 < cdecker> Hm? Why would we need bolt11 updates?
13:10 <+roasbeef> yeh, since it's scheme dependent 
13:10 <+roasbeef> well to signal if they support amp or spontaenous payments for example 
13:10 < bitconner> for unadertised nodes to communicate support for variable length payloads
13:10 < cdecker> Yeah, but that's orthogonal to this
13:11 < cdecker> For unadvertised channels we'd infer from spontaneous or amp
13:11 < cdecker> No need to signal twice imho
13:11 < t-bast> on the feature bit, should we "steal" one of the bit pair assigned in the issue but currently not spec-ed?
13:11 < t-bast> see https://github.com/lightningnetwork/lightning-rfc/issues/605
13:12 < 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?
13:12 < rusty> roasbeef: unification is so we can advertize both in the node_announcement.
13:12 <+roasbeef> they're a diff namespace though, we haven't used anything in the global namespace, so we can start from 0/1 
13:13 < rusty> roasbeef: then how do we advertize that our node supports this in node_announcement?
13:13 < t-bast> roasbeef: but we'd like to combine them in a single byte array
13:13 < bitconner> they'll be shared if we also decide to move forward on unification
13:13 <+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 
13:13 < cdecker> roasbeef: signalling in an invoice seems weird for spontaneous payments xD
13:13 < rusty> roasbeef: vs, say, option_dataloss_protect which is 0/1 in local features.
13:14 < bitconner> cdecker, what if i want to signal support w/o supporting those features?
13:14 < cdecker> But for AMP I get an invoice that signals support for AMP, then I can infer that the recipient supports variable payloads :-)
13:14 < rusty> (which, if we proceed with unification, will appear in node_announcement)
13:15 < cdecker> bitconner: if you don't need variable payloads, why would you want to get variable payloads?
13:16 < bitconner> amp and spontaneous payments aren't the only use cases for variable payloads
13:16 <+roasbeef> cdecker: you may want to attach additional data 
13:16 < cdecker> But we digress, I propose we just signal standalone variable payload support using feature bits 40/41
13:16 <+roasbeef> cdecker: otherwise, how do you know if they support it at all? 
13:16 < 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...
13:16 < rusty> cdecker: ack
13:16 < t-bast> cdecker: agreed, let's go for 40/41 then
13:16 < t-bast> #action cdecker will update the feature bit in the PR
13:16 < cdecker> roasbeef, bitconner I retract my objection to standalone signalling :-)
13:16 <+roasbeef> 40/41? 
13:17 < t-bast> roasbeef: it's the first unassigned one in the issue linked, let me fetch the link again
13:17 < cdecker> roasbeef: if you look at #605 they are the lowest not-yet-claimed feature bits
13:17 < t-bast> https://github.com/lightningnetwork/lightning-rfc/issues/605
13:18 < rusty> Comment added to that issue...
13:18 <+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 
13:18 <+roasbeef> also in my mind, they're distinct namesapces, local vs global 
13:18 <+roasbeef> afaik we don't have any global feature bits 
13:18 < t-bast> the namespaces will be merged if we do feature bit unification
13:18 < rusty> roasbeef: but people wanted local features in node_announcement, so they could find peers which supported certain features.
13:19 <+roasbeef> depends on what a "local" is, stuff like bigger chans is a global bit 
13:19 <+roasbeef> basically anything that you may need to use for preferential peer selection 
13:19 < t-bast> let's discuss that when we discuss the feature bit unification PR :)
13:19 -!- darosior [~darosior@107.175.255.247] has joined #lightning-dev
13:19 < rusty> roasbeef: no, the original idea of global was "stuff you need to know to *route* through"
13:20 < rusty> roasbeef: hence this would be our first global bit, with var onion.
13:20 < rusty> (Or, if we prefer the nomenclature,  "routing" bit vs "peer" bit maybe...)
13:20 < t-bast> maybe we should switch the topic to discuss feature bit unification? and then come back to the onion bit?
13:21 < cdecker> I think we are moving away from the var payload
13:21 < cdecker> Seems we mostly agree on the contents of the var payload (once LL reproduces our test vectors)
13:21 < cdecker> So in my mind, once they do, we can merge without further delays
13:21 < 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?
13:21 < rusty> t-bast: ack.
13:21 < t-bast> cdecker: ack
13:22 < cdecker> We can certainly move the discussion about feature bits out
13:22 < cdecker> t-bast: ACK
13:22 < bitconner> idt the question of what an `integer` encoding is was ever addressed
13:22 < cdecker> It's the shortest binary representtion for a given number
13:22 < 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?
13:23 < cdecker> 0x01 => integer 1, 0x0123 => integer 291
13:23 < cdecker> Sure, I can do that ^^
13:23 < rusty> Yes, I think #622 needs some bikeshedding love :)
13:24 < t-bast> cdecker: thx, and makes sense for the `integer` notation
13:24 < bitconner> sweet, yeah defining the varint encoding in the pr would be helpful
13:24 < cdecker> Shall I call it CompactInteger to differentiate from varint and fixed size integers?
13:24 < 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?
13:24 < rusty> t-bast: agreedd.
13:25 < cdecker> agreed
13:25 <+roasbeef> or just `varint` in our context? do you we hav emore than 1? 
13:25 < 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
13:25 < bitconner> we use `varint` in the tlv proposal to refer to compact size
13:26 <+roasbeef> varint and CompactSize are different? 
13:26 < t-bast> I think we're using the terms without referring to the same thing :)
13:26 <+roasbeef> i thought we wanted to use the same scheme everywhere 
13:26 < cdecker> Yes, those are for types and lengths, but not to encode the actual numbers
13:27 < 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
13:27 < 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).
13:28 < 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?)
13:28 < 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
13:28 < 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
13:28 <+roasbeef> if we're making a new var int, we can make a much better encoding 
13:28 < 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
13:28 <+roasbeef> just use 1 bit for "more bytes" 
13:29 < niftynei> +1 for including concrete examples in the spec
13: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
13:29 <+roasbeef> i mean using that format everywhere 
13:29 < cdecker> +1 for niftynei's proposal, I'll come up with examples
13:29 <+roasbeef> it's more compact 
13:30 <+roasbeef> that as in '1 bit is more bytes' 
13:30 < cdecker> roasbeef: how would you represent 256 then in that new encoding as part of a TLV
13:30 < cdecker> Sorry 255 of course
13:30 < rusty> #622 calls them tu16, tu32 and tu64, FWIW
13:30 <+roasbeef> basically something like this https://golang.org/src/encoding/binary/varint.go 
13:31 < cdecker> In TLV with my encoding it'd be 0xAB01FF, type=0xAB, length=0x01, value=0xFF
13:31 < 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 :)
13:31 < 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?
13:31 <+roasbeef> or utf
13:31 < cdecker> niftynei: yes
13:31 < t-bast> niftynei: yes I think so
13:31 < niftynei> kk ty
13:31 < bitconner> rusty, is the idea that all integers encoded in tlv would use tu16, tu32, and tu64?
13:32 < rusty> bitconner: no, only as explicitly specced, since they have to be standalone.
13:32 < cdecker> tu = truncated unsigned???
13:32 < rusty> cdecker: or tlv integer, yeah.
13:32 < cdecker> Ah k
13:32 < rusty> cdecker: u == unsigned.  so we ahve u64, and tu64.
13:32 < bitconner> rusty, cool just double checking. for non-onion tlvs this could be a privacy leak 
13:32 <+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 
13:33 < t-bast> bitconner: interesting point
13:33 < t-bast> bitconner: indeed we need to use that carefully to avoid traffic analysis from inferring amount ranges
13:33 < 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
13:33 < cdecker> roasbeef: the point here is that any form of varint auto-encodes its length (CompactSize uses the first byte, golang varints use the 
13:33 < rusty> niftynei: indeed.
13:33 < cdecker> "there's more bit)
13:33 <+roasbeef> the variable length stuff leaks info in any sense, since it tells you the ceiling of the # of hops after you 
13:33 <+roasbeef> when before you extracted the same amt of info 
13:34 < cdecker> Ok, we're getting off track here, I'll write this thing up and add it to the PR, would that be ok?
13:34 < t-bast> cdecker: ACK
13:34 < rusty> cdecker: NO.  It's all in #622 already, shall we discuss that?
13:34 < cdecker> Ok
13:34 < t-bast> great let's do it
13:35 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/622
13:35 < cdecker> Let's discuss #622 and I'll amend #619 accordingly :-)
13:35 < 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.
13:36 < rusty> roasbeef: eg. I differentiated `chain_hash` from `sha256` (which it doesn't have to be, but do we care?)
13:36 < cdecker> Oh, I see tu16, tu32, and tu64, thanks rusty :-)
13:36 < rusty> Similarly, I differentiated `point` (tweaked to make a key) from `pubkey` (use as-is).
13:36 < t-bast> I think it's helpful for spec readers to see types that are more fine-grained
13:36 < t-bast> ie `chain_hash` instead of `bytes32`
13:37 < rusty> t-bast: well, 32*byte would also be legal.
13:37 < t-bast> It doesn't have to leak in the implementations anyway, it's only for readability right?
13:37 < niftynei> i'm in favor of keeping more specific 'type labels' on fields, as it makes tracing intent + instructions for use a bit easier
13:37 < cdecker> I like the more explicit types :+1:
13:37 < rusty> t-bast: exactly, there's no spec change here.
13:37 < t-bast> rusty: perfect then, that sounds good to me
13:38 < bitconner> +1 on adding types, it does help readability imo
13:38 < rusty> But it makes it easier to parse: we had to do some fuzzy matching on field names internally.
13:38 < rusty> I want this merged now because it's a scattergun change which will cause merge conflicts :)
13:39 < t-bast> :D
13:39 < cdecker> Yep, happy to rebase #619 right now ^^
13:40 < t-bast> nits: why are some of the types commented in the python code?
13:40 < t-bast> shall we remove those before merging?
13:40 < t-bast> or is it the description?
13:41 < 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.
13:41 < bitconner> does seem like there's a bit of redudancy in the types, but not a big deal i suppose
13:41 < rusty> t-bast: where?
13:41 < bitconner> rusty, ack
13:42 < t-bast> rusty: I went too fast on that, iiuc this is the explanation of what the code outputs
13:42 < niftynei> t-bast i think you're referring to the documentation, they're supposed to be example inputs for what the script outputs
13:42 < t-bast> niftynei: thanks for confirming, got it
13:42 < niftynei> :thumbs_up:
13:42 < bitconner> t-bast: `point` vs `pubkey`, `secret` vs `primage` vs `sha256`
13:43 < t-bast> sgtm
13:43 < bitconner> yeah but otherwise lgtm
13:43 < rusty> bitconner: we literally only use pubkey for `funding_pubkey` everything else is a point.
13:43 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
13:44 < 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.
13:44 < bitconner> i was thinking the opposite, and make them all `point`s, but if you think the differentiation is useful then okay by me :)
13:45 < rusty> bitconner: I'm happy with that, actually.
13:45 < t-bast> that change looks good to me, roasbeef are you convinced?
13:45 < rusty> OK, so pubkey->point, and secret and preimage removed in favor of `32*byte`?
13:45 < t-bast> rusty: sgtm
13:45 < rusty> (Damn, we're getting faster at bikeshedding!)
13:45 < bitconner> sgtm1
13:46 < bitconner> !
13:46 < rusty> OK, happy for me to merge once those changed applied?  I can do it today.
13:46 < t-bast> rusty: ack
13:46 < bitconner> ack
13:46 < cdecker> ACK
13:47 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/607 -> short update?
13:47 < rusty> #action rusty to Change pubkey->point, and secret and preimage removed in favor of `32*byte` in #622 and then merge.
13:47 < cdecker> Sounds like we agree ^^
13:47 < t-bast> This is the TLV proposal we already agreed on.
13:47 < t-bast> Shall we wait for test vectors or merge this and then add test vectors afterwards?
13:47 < rusty> t-bast: I'll merge it today, too?
13:48 < bitconner> yes i think the outstanding thing is test vectors
13:48 < t-bast> rusty: oh yeah
13:48 < cdecker> I think with #622 out of the way, the last hanging issue for #619 (tu32, ...) is also now solved?
13:48 < rusty> t-bast: yes, I volunteer to do test vectors, as additional PR.
13:48 < t-bast> rusty: great! bitconner would this be ok for you?
13:49 < t-bast> I added my informal test suite to the PR, that might be helpful
13:49 < t-bast> cdecker: sgtm, I'd just like to choose a feature bit that's not already assigned before we merge #619 though, wdyt?
13:49 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
13:50 < cdecker> Sounds good, 40/41 still good for everybody?
13:50 < rusty> t-bast: looks like you've already done all the work!  I'll repro them and turn it into an Appendix...
13:50 < bitconner> sure that's fine by me, tho i don't see a rush in merging 607 until we have the test vectors
13:50 < rusty> bitconner: because merging is fun! :)
13:50 < t-bast> bitconner: I think it finally completely unblocks the channel_queries discussion which is a bit in limbo - and it shows progress
13:51 < t-bast> rusty: perfect thanks!
13:52 < t-bast> so shall we merge #607 now and have an action item on rusty to produce formatted test vectors?
13:52 < 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.
13:52 < bitconner> t-bast, sure sgtm
13:52 < rusty> t-bast: sgtm
13:52 < rusty> Otherwise I think roasbeef was worried we're reserving for stuff which will never eventuate, which is fair.
13:52 < t-bast> great, I'm merging it (my first merge on the repo!)
13:53 < cdecker> Awesome, congrats t-bast ^^
13:53 < niftynei> yay!
13:53 < bitconner> 🎉
13:53 < rusty> 🎉
13:53 < t-bast> give me 5 minutes to open some champagne, I'll be back
13:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
13:54 <+roasbeef> instead of 40/41 start from scratch imo 
13:54 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/571 and https://github.com/lightningnetwork/lightning-rfc/issues/605
13:54 < niftynei> #action t-bast to get champagne for chatroom
13:54 < t-bast> This is the feature bit unification discussion
13:54 < t-bast> niftynei: we don't even have champagne emojis on irc :(
13:55 < rusty> t-bast: 🥂
13:55 < 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
13:55 < t-bast> rusty: omg
13:56 < rusty> t-bast: OK, so then let's give 8/9 to cdecker for varonion.  Anyone object?
13:56 < t-bast> that sounds perfect
13:56  * cdecker wonders whether using a non-unicode capable IRC clients was a smart move...
13:56 < cdecker> rusty: ack
13:56 < t-bast> :)
13:56 < 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.
13:57 < t-bast> Good idea.
13:57 < cdecker> #action cdecker to update #619 to use feature bits 8/9 instead
13:57 < t-bast> On the feature bit PR itself
13:57 < cdecker> #action cdecker to update #619 with the tu32 and tu64 types from #622
13:58 < t-bast> We said last time that the names weren't convincing yet
13:58 -!- bitconne1 [~root@138.68.244.82] has joined #lightning-dev
13:58 < t-bast> I posted a few proposals on the PR, should we bikeshed naming proposals right now?
13:58 < rusty> t-bast: yes, I've been remiss on not revisiting naming :(
13:58 <+roasbeef> was this ever addressed? 
13:58 <+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
13:59 -!- bitconner [~root@138.68.244.82] has quit [Ping timeout: 268 seconds]
14:00 < 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?
14:00 < 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
14:00 < rusty> roasbeef: yeah, you're wrong ;)
14:01 < bitconne1> idt any of the varint schemes lose precision?
14:02 < cdecker> bitconne1: we use more bytes if we need to encode both the value and the length of the encoding in the same space
14:02 < cdecker> That's what I meant :-)
14:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []
14:02 <+roasbeef> but we may be able to save bytes by usin ga more compacrt format 
14:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:02 <+roasbeef> we're saving 1 byte with the trunacrtion atm? 
14:02 -!- bitconne1 is now known as bitconner
14:03 < cdecker> roasbeef: there is no more compact format if we don't need to encode the encoding length inside the integer itself
14: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
14:03 < t-bast> nitfynei: thanks, adding those
14:03 < t-bast> #action t-bast merge 607
14:03 < t-bast> #action rusty add TLV test vectors in separate PR 
14:03 < 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
14:03 < cdecker> we'd use 2 bytes for the golang varint
14:04 < cdecker> and we'd use 1 byte for the tu64 since we truncate the leading 0x00 bytes
14:05 < 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' ;)
14:05 < 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)
14:05 < t-bast> I think the current proposal gives good enough trade-offs
14:05 < cdecker> Agreed, we can use u64 everywhere for all I care :-)
14:06 < rusty> We kind of get it for free though, so why not?
14:06 < 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
14:06 < 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 :)
14:06 < cdecker> Bikeshedding integer encodings here is not productive
14:07 < 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.
14:07 <+roasbeef> t-bast: totally tangential really
14:07 < t-bast> roasbeef: shall we start a thread somewhere else and discuss that over the week?
14:08 < t-bast> or maybe schedule a video meeting to discuss this?
14:08 < t-bast> I think we'd be more efficient that way
14:09 < t-bast> rusty: were you able to make progress on the channel_queries implementation?
14:09 < rusty> t-bast: yeah, let's do it!  coord with roasbeef?  This time any day works for me, really.
14:10 < rusty> t-bast: unf not, got distracted writing protocol tests, and option_static_remotekey.
14:10 < t-bast> #action t-bast find a meeting slot with roasbeef and rusty to discuss integer encoding and feature bit unification
14:10 < t-bast> roasbeef: are you ok with that? I'll propose meeting slots to discuss this with rusty this week or next week
14:10 <+roasbeef> static key >>>>>>>>> channel_queries im o
14:10 <+roasbeef> imo* 
14:10 < rusty> roasbeef: I know!
14:11 <+roasbeef> as far as safety of users 
14:11 < t-bast> rusty: no problem
14:11 <+roasbeef> commented on that old diff, was going to start my own this week if didn't see any movement there 
14:11 < 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...
14:11 < t-bast> Are there any other topics people want to discuss?
14:13 < rusty> Congrats on all three implementations for their recent releases :)
14:13  * cdecker would like to thank roasbeef for the really good BOLT 08 documentation
14:14 < cdecker> I reimplemented the handshake over the weekend in python and it was a breeze :-)
14:14 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:14 < 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?
14:14 < 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.
14:15 < t-bast> rusty: nice!
14:15 < cdecker> t-bast: shall we just give like 5 of the small things as homework?
14:15 < rusty> t-bast: shall we merge them under the "spelling" rule which requires two approvals, no dissent, and no meeting?
14:15 < cdecker> Like a small reading assignment?
14:15 < t-bast> cdecker: that's a good idea - I think 2 approvals would be enough for all the simple ones right?
14:16 < cdecker> With the warning that they will either be merged, or closed during the next meeting (just to up the pressure a bit)
14:16 < cdecker> t-bast: agreed
14:16 < rusty> OK, please tag them as "spelling" then, for clarity.
14:17 < 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
14:17 < rusty> t-bast: ack.
14:17 < t-bast> Everyone ok with this? I can work on that list and we can make progress 5 by 5 every 2 weeks.
14:18 < niftynei> sgtm
14:18 < t-bast> I'll ping people on github to get either the two approvals or a dissent
14:18 < t-bast> bitconner, roasbeef, what's your opinion on that?
14:18 < cdecker> ACK
14:18 < t-bast> bitconner has already reviewed some of those, we exchanged some comments on a few
14:22 < t-bast> #action t-bast select 5 clarification PRs and assign reviewers / get them merged sooner than later
14:23 < t-bast> Do we have ending remarks from the audience or shall we end the meeting for today?
14:23 < cdecker> sgtm
14:24 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 272 seconds]
14:24 < t-bast> #endmeeting
14:24 < lightningbot> Meeting ended Mon Jul  8 21:24:22 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:24 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-07-08-20.05.html
14:24 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-07-08-20.05.txt
14:24 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-07-08-20.05.log.html
14:24 < t-bast> Everyone have a good morning / afternoon / night and see you on github or in two weeks
14:24 < cdecker> Great, thanks t-bast for moderating ^^
14:25 < t-bast> cdecker: my pleasure ;)
14:25 < rusty> t-bast: thanks for moderating.  I think niftynei is up next time :)
14:25 < t-bast> I haven't seen niftynei moderate yet indeed!
14:25 < t-bast> Next time it is then
14:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
14:29 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
14:32 -!- t-bast [~t-bast@2a01:e34:ec2c:260:21e4:48eb:8ce9:41de] has quit [Quit: Leaving]
14:32 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving]
14:32 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #lightning-dev
14:34 -!- hiroki_ [d295fef1@241.254.149.210.rev.vmobile.jp] has quit [Remote host closed the connection]
14:35  * niftynei waves
14:46 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
14:48 -!- davterra [~tralfaz@209.58.184.163] has quit [Ping timeout: 248 seconds]
14:52 -!- RawphullCawpter [~mikey@cpe-192-136-227-107.tx.res.rr.com] has left #lightning-dev []
14:53 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:58 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 272 seconds]
15:03 < bitconner> join #lnd
15:03 < bitconner> lol
15:07 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
15:16 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
15:23 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
15:27 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
15:36 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
15:46 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
15:49 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #lightning-dev
15:55 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]
16:00 -!- davterra [~tralfaz@209.58.184.163] has joined #lightning-dev
16:12 -!- darosior [~darosior@107.175.255.247] has quit [Quit: The Lounge - https://thelounge.chat]
16:13 -!- darosior [~darosior@107.175.255.247] has joined #lightning-dev
16:33 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 244 seconds]
16:41 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
17:02 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 252 seconds]
17:03 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #lightning-dev
17:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:39 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
18:02 < rusty> Hmm, we need to define whether extra bytes at end of a TLV record are allowed.
18:03 < rusty> I think the answer, at least for variable length integers, is "no".  For other fields, it's tempting, but I say "no" is a simple universal rule.  You can always add another TLV for extra fields.
18:30 -!- bauerj [~bauerj@unaffiliated/bauerj] has quit [Remote host closed the connection]
18:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
18:31 -!- bauerj [~bauerj@unaffiliated/bauerj] has joined #lightning-dev
18:31 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
18:31 -!- riclas [~riclas@148.63.37.111] has quit []
18:34 -!- rompert_ [sid13298@gateway/web/irccloud.com/x-oxijeubfstfvmzfj] has quit [Read error: Connection reset by peer]
18:34 -!- rompert_ [sid13298@gateway/web/irccloud.com/x-xiymwwijiozsgjvs] has joined #lightning-dev
18:36 < bitconner> rusty: yeah disallowing extra bytes for everything is how i have it implemented
18:37 < rusty> bitconner: yeah, and t-bast's test vectors assume the same. Similarly, non-minimal encodings for variable-lenght fields inside value are verboten (eg. integer with leading zeroes).  That keeps things canonical if pulled apart and re-created.
18:37 < rusty> Things that come out when writing test vectors!
18:38 < bitconner> +1 on rationale for keeping it canonical after reserializing!
18:40 < rusty> bitconner: I try to only make each mistake once :)
18:41 -!- darosior [~darosior@107.175.255.247] has quit [Ping timeout: 248 seconds]
18:53 <+roasbeef> +1 for no, that way you can just take a value and hash it for hash comparisons or the like, moving to the variable sized payloads allowed us to move away from sentintel stuff, at least in this context 
19:08 -!- davterra [~tralfaz@209.58.184.163] has quit [Ping timeout: 248 seconds]
19:18 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
19:19 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Client Quit]
19:38 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
19:38 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
19:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
19:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
19:50 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
20:57 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
20:59 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
21:35 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection]
21:40 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
21:44 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
21:48 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 245 seconds]
21:59 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
22:42 -!- RonNa [~quassel@220-133-223-206.HINET-IP.hinet.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
22:53 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:53 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
22:56 -!- RonNa [~quassel@2001-b011-4004-000d-8c83-068f-3d1c-fc9d.dynamic-ip6.hinet.net] has joined #lightning-dev
23:36 -!- scoop [~scoop@205.178.77.52] has joined #lightning-dev
23:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:40 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 245 seconds]
23:47 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev
23:48 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]
23:50 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
23:51 -!- reallll is now known as belcher
23:55 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
--- Log closed Tue Jul 09 00:00:05 2019