--- Log opened Mon Feb 18 00:00:53 2019
00:36 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev
00:39 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 246 seconds]
00:39 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
00:56 -!- Amperture [~amp@24.136.5.183] has quit [Remote host closed the connection]
01:01 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has joined #lightning-dev
01:09 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
01:15 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has quit [Quit: Leaving]
01:20 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
01:22 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev
01:40 -!- araspitzu [~araspitzu@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
01:41 < araspitzu> hey there, is anyone prototyping with option_simplified_commitment?
01:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
02:03 -!- kexkey [~kexkey@87.101.92.74] has quit [Read error: Connection reset by peer]
02:07 -!- siom [~siom@165.84.231.19] has joined #lightning-dev
02:20 -!- mode/#lightning-dev [+o rusty] by ChanServ
02:20 -!- rusty changed the topic of #lightning-dev to: Bitcoin Lightning Network Development: Be Excellent To Each Other!  Logging at http://gnusha.org/lightning-dev/ Next Meeting: https://github.com/lightningnetwork/lightning-rfc/issues/574
02:20 -!- mode/#lightning-dev [-o rusty] by rusty
02:21 < araspitzu> @rusty I actually wanted to discuss https://github.com/lightningnetwork/lightning-rfc/pull/539 but I don't have the permission to add labels to PRs
02:21 < rusty> araspitzu: done :)
02:21 < araspitzu> thanks!
02:24 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 250 seconds]
02:45 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
02:47 -!- harding [~quassel@li1258-130.members.linode.com] has joined #lightning-dev
03:39 -!- Amperture [~amp@24.136.5.183] has joined #lightning-dev
03:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 272 seconds]
04:13 -!- deafboy [quasselcor@cicolina.org] has quit [Remote host closed the connection]
04:17 -!- deafboy [quasselcor@cicolina.org] has joined #lightning-dev
04:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
04:58 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
05:17 -!- shesek [~shesek@141.226.152.217] has joined #lightning-dev
05:17 -!- shesek [~shesek@141.226.152.217] has quit [Changing host]
05:17 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
05:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
05:33 -!- thomasan_ [~thomasand@2607:fb90:1bd1:e979:1415:8290:5be2:db51] has joined #lightning-dev
05:35 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
05:53 -!- Watermaniak [592660bd@gateway/web/freenode/ip.89.38.96.189] has joined #lightning-dev
05:53 -!- Watermaniak [592660bd@gateway/web/freenode/ip.89.38.96.189] has left #lightning-dev []
05:58 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
06:02 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
06:04 < shesek> is the dev-listaddrs rpc command expected to remain available without DEVELOPER=1? could I rely on it or should I expect that it might go away?
06:05 -!- m8tion [~user@2a01:e35:8bef:9310:100c:b6f0:1e34:944d] has joined #lightning-dev
06:12 -!- Amperture [~amp@24.136.5.183] has quit [Remote host closed the connection]
06:22 -!- thomasan_ [~thomasand@2607:fb90:1bd1:e979:1415:8290:5be2:db51] has quit [Remote host closed the connection]
06:35 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
06:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
06:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev
07:19 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
07:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
07:53 -!- kexkey [~kexkey@87.101.92.74] has joined #lightning-dev
07:56 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #lightning-dev
07:56 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
07:56 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev
08:02 -!- watermaniak [~watermani@89.38.96.189] has quit [Remote host closed the connection]
08:03 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
08:06 -!- watermaniak [~watermani@89.38.96.189] has quit [Remote host closed the connection]
08:09 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
08:23 -!- booyah_ [~bb@193.25.1.157] has joined #lightning-dev
08:24 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]
08:28 -!- kexkey [~kexkey@87.101.92.74] has quit [Ping timeout: 246 seconds]
08:51 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection]
08:56 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
08:56 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
09:13 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]
09:21 -!- araspitzu [~araspitzu@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Quit: Leaving]
09:37 -!- watermaniak [~watermani@89.38.96.189] has quit [Remote host closed the connection]
09:41 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Ping timeout: 244 seconds]
09:46 -!- lsshpw2 [~user@185.107.80.78] has joined #lightning-dev
09:55 -!- lsshpw2_ [~user@185.107.80.78] has joined #lightning-dev
09:58 -!- lsshpw2 [~user@185.107.80.78] has quit [Ping timeout: 255 seconds]
10:00 -!- lsshpw2 [~user@185.107.80.78] has joined #lightning-dev
10:02 -!- lsshpw2_ [~user@185.107.80.78] has quit [Ping timeout: 272 seconds]
10:09 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #lightning-dev
10:12 -!- lsshpw2_ [~user@185.107.80.78] has joined #lightning-dev
10:15 -!- lsshpw2 [~user@185.107.80.78] has quit [Ping timeout: 246 seconds]
10:17 -!- lsshpw2_ [~user@185.107.80.78] has quit [Ping timeout: 250 seconds]
10:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
10:32 -!- Amperture [~amp@24.136.5.183] has joined #lightning-dev
10:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
10:45 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has joined #lightning-dev
10:48 -!- waterman_ [~watermani@89.38.96.189] has joined #lightning-dev
10:51 < cdecker> shesek: all `dev-` commands are for DEVELOPER=1 only, so you shouldn't rely on it. If there is a need for it we can promote it to be a non-dev command
10:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer]
10:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
10:54 -!- araspitzu [~ott0disk@134.28.68.51.rdns.lunanode.com] has joined #lightning-dev
10:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
10:54 -!- waterman_ [~watermani@89.38.96.189] has quit [Remote host closed the connection]
10:55 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
10:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
10:57 < araspitzu> hi all
10:57 < rusty> cdecker: any chance you can run the meeting?  Alex is away on vacation, and Finn has an uncanny ability to interrupt meetings (he's already woken once this morning!)
10:57 < rusty> araspitzu: hi!
10:58 < cdecker> Sure, lemme look at the agenda
10:58 < sstone> hi!
10:58 < rusty> cdecker: I checked the onion test vectors, so I'd like to approve that first and finally *drumroll* tag v1.0!
10:58 < cdecker> Hi sstone 
10:58 < cdecker> Yeah
10:58 < bitconner> hola!
10:59 < rusty> US has a holiday today, so they might be off having fun...
10:59 < niftynei> :waves:
10:59 < cdecker> Let's ping all the usual suspects and then we can get started
10:59 -!- hiroki [a331d17f@gateway/web/freenode/ip.163.49.209.127] has joined #lightning-dev
10:59 < cdecker> AmikoPay_CJP bitconner BlueMatt cdecker Chris_Stewart_5 kanzure niftynei
10:59 < cdecker> ott0disk roasbeef rusty sstone bitconner BlueMatt cdecker johanth kanzure
10:59 < cdecker> roasbeef rusty sstone
11:00 < Chris_Stewart_5> hello! 
11:00 < cdecker> Hi Chris_Stewart_5 :-)
11:00 < cdecker> #startmeeting
11:00 < lightningbot> Meeting started Mon Feb 18 19:00:17 2019 UTC.  The chair is cdecker. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < cdecker> #info Agenda for today can be found here https://github.com/lightningnetwork/lightning-rfc/issues/574
11:00 < kanzure> hi.
11:01 < cdecker> Hi kanzure 
11:01 < rusty> And search by tag: https://github.com/lightningnetwork/lightning-rfc/labels/2019-02-18
11:01 < cdecker> Oh, by the way please tell me if I should remove someone from the ping list (don't want to wake people up accidentally)
11:02 < cdecker> Very short agenda today, let's see if we can get a quorum of all implementations and we should be done quickly
11:02 < rusty> Added https://github.com/lightningnetwork/lightning-rfc/pull/570 
11:02 < lndbot> <johanth> hi
11:02 < cdecker> Hi johanth
11:03 < bitconner> hi johan :)
11:03 < cdecker> Ok, so we have Johan from LL, sstone from ACINQ, rusty, niftynei and me from BS
11:03 < cdecker> Does that count as quorum?
11:03 < bitconner> sounds about right
11:04 < cdecker> Cool
11:04 < cdecker> #topic Tagging v1.0
11:04 < rusty> https://github.com/lightningnetwork/lightning-rfc/pull/570 Is so nice, I (somehow) acked it twice!
11:04 < cdecker> So we wanted to tag v1.0 last time, but there was an issue with the onion test vectors if I remember correctly
11:05 < rusty> https://github.com/lightningnetwork/lightning-rfc/milestone/2
11:05 < rusty> Yes, the intermediary results had not been updated (the final onion result was correct).  I went through and validated it against our implementation, and it matches.
11:05 < cdecker> Are we sure that the routing_info[4] unencrypted is correct? IMHO that should have the filler bytes at the end
11:07 < cdecker> ok, if rusty checked it I'm satisfied :-)
11:07 < cdecker> So any objections to applying PR #570?
11:07 < sstone> lgtm :)
11:07 < bitconner> utACK :)
11:08 < cdecker> #agreed cdecker to merge PR #570
11:08 < cdecker> Sounds good, so that should resolve the last open issue for v1.0
11:08 < cdecker> Anything that we need to do before tagging?
11:08 < lndbot> <johanth> \o/
11:09 < rusty> cdecker: Not that I know of.... I will merge and tag immediately after meeting, so anything else we approve here goes *post* v1.0.
11:09 < cdecker> Ok, if something comes up, please let me know, otherwise rusty can merge and tag
11:09 < cdecker> #agreed rusty to tag v1.0 after merging #570
11:10 < cdecker> #topic PR #539: BOLT 3: add test vectors for htlc-transactions in case where CLTV is used as tie-breaker for sorting
11:10 < cdecker> Link: 
11:10 < cdecker> https://github.com/lightningnetwork/lightning-rfc/pull/539
11:11 < araspitzu> so, i reworked the PR because initially i took too much liberty redefining HTLC #1 and #2, now it should be okay but the vectors need a second ACK
11:12 < cdecker> rusty and araspitzu: am I correct in assuming you cross-checked the results and this is to be merged?
11:12 < rusty> #action rusty to validate PR 539 test vectors.
11:12 < rusty> cdecker: no, still a TODO....
11:12 < araspitzu> note that after @rusty's comment the content of the vector changed
11:12 < cdecker> Ok, so this is more of a call to action to discuss the issue then :-)
11:12 <+roasbeef> at some point, i think we should aim to make all the test vectors machine readable and human parseable 
11:12 < cdecker> Oh hi roasbeef :-)
11:12 < rusty> But I agree that it's a really nice addition...
11:12 <+roasbeef> rn you need to do a ton of copy/paste
11:12 < rusty> roasbeef: :+1:
11:13 < cdecker> Absolutely
11:13 <+roasbeef> one mega copy/paste would be nice 
11:13 < Chris_Stewart_5> :+1: 
11:13 < araspitzu> agreed, IIRC a json based approach was suggested the last time?
11:13 < cdecker> (I have a json onion spec format for my onion proposal, so that should make everybody happy)
11:13 <+roasbeef> yeh many moons ago... 
11:13 -!- ysangkok [janus@hapy.0x90.dk] has joined #lightning-dev
11:13 < Chris_Stewart_5> it might be worth looking at the bitcoin core test vectors for some guidance of structure.. at least some people have already written parsing code for that
11:13 < rusty> araspitzu: yes, I have a JSON spec start, but that's more for actual conversations between peers.  MIght be nice to have variants for this too.
11:14 < cdecker> #agreed everybody to aim for machine-readable test-vectors (in JSON)
11:14 < rusty> I think we should move them out of the docs proper, too, FWIW.  JSON in a spec doc seems a bit weird?
11:14 < rusty> (eg test_vectors/01-xxx.json)
11:14 < cdecker> Yep, separate JSON docs that can be references would be nice
11:15 < niftynei> rusty :+1:
11:15 < rusty> Then we can add new files rather than editing existing ones, too.
11:15 < bitconner> 1.1 goals?
11:15 < cdecker> I was going for boltxy/test-x-y-z.json to group by bolt
11:15 < cdecker> Ok, but I think we digress slightly (also we seem to agree on this 110%)
11:15 < rusty> cdecker: nice.  Of course, format for test vectors will be a little ad-hoc, since they test different things, but we can get closer.
11:16 < rusty> I'll open an issue to track...
11:16 < cdecker> On to feature bit unification :-)
11:16 < cdecker> #topic PR #571 Feature bit unification and assignment
11:17 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has joined #lightning-dev
11:17 < cdecker> Should be rather uncontroversial, except for the newly allocated feature bits
11:18 < cdecker> rusty: you just went through the list and assigned bits right? No attempt to group them by topic or anything like that?
11:18 < rusty> cdecker: yep, I just walked the list on the wiki....
11:18 < cdecker> (I fully support that, just making sure)
11:18 < cdecker> Sounds good
11:18 <+roasbeef> i still don't get the rationale, w.r.t the unification/split
11:18 <+roasbeef> it's just renaming? 
11:19 < sstone> and also combining 
11:19 <+roasbeef> but why?
11:19 < rusty> roasbeef: it's just renaming, but also making sure the numbers don't clash, so we can advertize them both together in node_announce.
11:19 < rusty> roasbeef: people want to search for nodes with certain peer features.
11:20 < rusty> eg. option_dataloss_protect. Orgiinally we werent' going to advertize those, since it's a local matter
11:22 <+roasbeef> no it's a global thing also, i can fitler thos peers out to connect to them 
11:22 < cdecker> Might be an idea to merge channelfeatures and peerfeatures altogether (hard since it's the `init` message)
11:22 < bitconner> what's the rationale behind advertising peer+channel features on connection? shouldn't peer be all that matters?
11:22 <+roasbeef> most local/global things also make sense on a global level, as you need to filter out peers to connect to them 
11:22 < rusty> There's one hole as the spec is currently proposed.  If there's a channelfeature you need, and you only know about the channel because of a bolt11 route hint, there's no way to tell you.  You'll try and get a required_channel_feature_missing error
11:22 <+roasbeef> so it combines the name spaces also? 
11:22 < rusty> roasbeef: the original "global" was for routing, "local" was for connecting.  Agreed you want to advertize nodes on both.
11:23 < rusty> roasbeef: ack.
11:23 < cdecker> Great moar profilability :-)
11:24 < araspitzu> concept ACK and very welcome 
11:24 <+roasbeef> rationale is still unclear to me
11:26 < rusty> roasbeef: combined namespace because as you agree you want to advertize both.  But they're still separate:  there's a difference between "you can't gossip with me" and "you can't route through me".
11:26 -!- mkl [b6e8a039@gateway/web/freenode/ip.182.232.160.57] has joined #lightning-dev
11:26 < rusty> Hence global/channel features are all you need to see in channel_announce.
11:26 < rusty> We already have both when you connect to the peer, in init msg.
11:27 < cdecker> We should have made this a flat bitfield right from the getgo, having multiple bitfields with different interpretations is really confusing
11:28 <+roasbeef> flat bitfield would mean they share a feature space, when they're really distinct 
11:28 < rusty> cdecker: <shrug> maybe the distinction will prove moot.  Maybe if you're so old you can't route through me, you should just damn well ugprade.
11:29 < rusty> Well, one option would be to not distinguish; if you don't understand a bit, just don't deal with me at all. If I want to make option_dataloss_protect compulsory on my node, and ancient nodes stop routing through me, do we care?
11:29 < cdecker> Mhe, it should a put-your-flags-here scratchspace, and when creating any message I can decide what I'm going to tell you about :-)
11:30 < cdecker> But anyhow, too late for that, we're left with the partitioned bitfields
11:30 < rusty> cdecker: ick, that's *really* nasty for a test matrix!  I suddently turn on a feature bit halfway through a conversation...
11:30 < cdecker> rusty: not really, the only time I tell you about my features is in the `init` message, so you get one shot for that
11:31 < rusty> (cdecker: oh, I thought you were suggesting attaching a feature bitfield to every message!)
11:31 < cdecker> Anyhow, seems to me like PR #571 needs some more discussion on the tracker?
11:31 < rusty> But I guess the q. is, are we happy with the draft assignments?  We can append more, but it's nice to be able to code against something which feels tangible...
11:32 <+roasbeef> i don't think the channel features rename makes sense, for example we may switch the way we do the handshake in the future and i may need to fish that out of the global feature 
11:32 < cdecker> Yeah, I'd definitely like to have the bits sorted out, even without the renameing and combining
11:32 <+roasbeef> aside from the rename, i don't really see much here (skimmed the PR a few times) 
11:32 <+roasbeef> ohh, it combines them
11:32 < cdecker> Yep
11:33 < rusty> roasbeef: yep, for *node announce* only.
11:33 < sstone> rusty: I like the PR but maybe without bits for features that are not really specified yet. and if we change he handshake we'll have the same pb ? 
11:33 <+roasbeef> so now they must select distinct bits? 
11:33 < rusty> roasbeef: yeah...
11:34 < cdecker> sstone: I'd really like to have bits assigned so we can actually start working on this stuff
11:34 < rusty> (We don't have a great place to put meta stuff in the spec, like "when selecting bits in future, don't clash!")
11:35 < cdecker> Hm, maybe we should have that then
11:35 < cdecker> BOLT 09 seems like an excellent place for such a thing
11:35 < sstone> cdecker: ok, the current selection is consistent except maybe for option_fec_gossip
11:36 <+roasbeef> i don't think bits need to be assigned before we can start working on anything 
11:36 < cdecker> Hm, why is that? sstone 
11:36 <+roasbeef> just select a random bit on testnet, gg
11:36 <+roasbeef> the bigger q is how bits are assinged in the first place 
11:36 <+roasbeef> and if there're reserved sections, etc 
11:36 < cdecker> Yeah right, and then we get the funny clashes we had when lnd joined the spec testnet xD
11:37 <+roasbeef> there's a ton of bits, so don't see it being an issue in the near future, but there's no guidance rn 
11:37 <+roasbeef> extra tests for your implementation ;)
11:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
11:37 < cdecker> Well, I really dislike the way BIP numbers are assigned (with gaps and grouped by topics)
11:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
11:37 < rusty> roasbeef: I think we should be pretty free with assigning them, we can always reassign if features never get merged and we want to.
11:37 < sstone> cdecker: because it's the only feature that I don't think we'll get (will be very happy if s.o proves me wrong :))
11:37 -!- mkl [b6e8a039@gateway/web/freenode/ip.182.232.160.57] has quit [Quit: Page closed]
11:37 < cdecker> We should just incrementally assign the bits so that we end up with a compact representation when serialized
11:38 <+roasbeef> do we need a blockchain for this? 
11:38 < rusty> roasbeef: LOL
11:38 <+roasbeef> who comes "first"? 
11:38 <+roasbeef> kek
11:38 < rusty> I think generally people should self-assign when they create a PR for the spec, and we do final disambiguation at merge tiime (which, given BOLT 9 clashes, will be obvious)
11:38 < cdecker> The one with the LN Torch!
11:39 < cdecker> This is group therapy and the torch is out talking pillow xD
11:39 < cdecker> sstone: I think there are quite a few features in there that we're unlikely to see realized (2p_ecdsa for example)
11:40 < rusty> ? #action Rusty to write BOLT-BOLT proposing meta stuff like how to assign feature bits?
11:40 < sstone> ok then I guess we can always reassign 
11:40 < niftynei> "This is group therapy and the torch is out talking pillow xD" <3
11:40 < rusty> (I actually just assigned them in the PR there to avoid this bikeshed, but there we are :)
11:40 < cdecker> Ok, it seems we need to bikeshed a bit more on #571, would you agree? 
11:41 < rusty> Yep... but FWIW, I'll use those draft feature bits in my test code :)
11:41 < cdecker> Sounds good
11:41 < cdecker> So let's move on
11:41 < cdecker> #agreed everyone to bikeshed on #571 a bit more
11:41 < cdecker> #topic PR #572 Specify tlv format, initial MPP
11:42 < rusty> Connor is not here to defend TLV; roasbeef attack!
11:42 -!- Kostenko [~Kostenko@bl5-167-188.dsl.telepac.pt] has quit [Remote host closed the connection]
11:42 < bitconner> rusty: i'm here
11:42 < cdecker> I kind of dislike even allowing >256 byte values
11:43 < rusty> cdecker: hmm, for the length?  We could simply reserve >= 253
11:43 < cdecker> So for me `var_int` for the length feels really weird
11:43 < cdecker> Yeah
11:43 < cdecker> We have 1300 bytes of total payload we can split up along the route
11:44 < rusty> cdecker: it's even more awkward if we need it later though.  255 bytes is not *quite* enough.  And this can be used in other msgs, which don't have so much space restriction.
11:44 <+roasbeef> 1 byte type seems very limiting, would also say tlv on the wire protocol has more impact than the onion atm
11:44 < cdecker> Having a single value consume 20% of that is a bit much (and might cause route-length issues if people really start using it)
11:44 <+roasbeef> tlv should also be optional in the onion as well
11:44 < rusty> roasbeef: it is... a 0 byte terminates it, so if first byte is 0, it's not there.
11:45 <+roasbeef> which means we need a length indicator for each cell/blob, or some padding scheme 
11:45 < cdecker> TLV is pretty much what gates us for multi-part payments, rendez-vous and spontaneous payments, so I do think that TLV is rather urgent
11:45 -!- mkl [b6e8a039@gateway/web/freenode/ip.182.232.160.57] has joined #lightning-dev
11:45 < rusty> (Though note this PR doesn't talk about *how* this gets encoded in the onion; that's up to the multi-frame proposals...)
11:46 < cdecker> Wait, the 0-byte is useable for padding
11:46 <+roasbeef> all that work can already be underway and proceeed concurrently really 
11:46 <+roasbeef> but for the cases that want a compact encoding, the tlv just wastes a ton of space, given that there's 32/65 bytes available per hop
11:46 < bitconner> why does even/odd need to be in the encoding, rather than in feature bit neogitation
11:46 < cdecker> Yeah, but we'd be reinventing the wheel when it comes to serialization formats
11:46 <+roasbeef> but if there's no outside type byte, imo you need 2 bytes for the type
11:46 < rusty> roasbeef: wastes 1 byte you mean?
11:46 <+roasbeef> if the outside type byte is there (tlv optional) then there's more working room 
11:47 < cdecker> What outside type byte? Where is that signaled?
11:47 <+roasbeef> which gets us to 65k combos which should be nough, 256 seems too small given app developer interest in using this space 
11:47 < cdecker> Do you mean the realm?
11:47 <+roasbeef> imo the realm should be kept in tact, and another byte from the nion padding used to signal the type 
11:48 <+roasbeef> just for clean seperation, "this is the chain", "this is the metadata" 
11:48 < rusty> roasbeef: yes, that's exactly what TLV *is*.
11:48 <+roasbeef> ?
11:48 < rusty> the byte used to signal the type is the T in TLV :)
11:48 <+roasbeef> yes, 256 isn't enough imo
11:48 <+roasbeef> or 55 w/e
11:49 < cdecker> Ok, we can make the type `var_int` (but I doubt we're ever going to hit that)
11:49 < bitconner> imo onion tlv should be considered separate from wire tlv. not that i want the extra complexity, but they have diff constraints
11:50 <+roasbeef> either two bytse there, or the outside type, don't think var int needed there 
11:50 < rusty> roasbeef: I really can't see more than a few dozen.  If app level want to do something, they need to signal it somehow anyway.
11:50 <+roasbeef> rusty: i constantly get messages from devs asking hwo they can use the space for their applications 
11:50 < rusty> bitconner: I was trying to start with general TLV stuff, then go into the onion.  I really don't want multiple TLVs if we can avoid it.
11:50 <+roasbeef> you may not see the possibilities, but the devs do
11:50 < rusty> roasbeef: yeah, me too.
11:51 <+roasbeef> the two areas have diff constraints (wire vs onion) 
11:51 < cdecker> Well then tell them to use TLV + different realm that gives you 2^4 * 256 possible types
11:51 <+roasbeef> type byte would be 65k, breaking off bits from real seems unecessary 
11:52 < bitconner> rusty: tbh the only that would really change between the two is the varint (i think?), which is just a matter of changing constants
11:52 -!- watermaniak [~watermani@89.38.96.189] has quit [Remote host closed the connection]
11:52 < rusty> roasbeef: we can certainly assign a "end2end" type pair, and they can put whatever they want in there.
11:53 < rusty> bitconner: so you're saying onion TLV would not use varint length?  That seems weird.
11:53 < BlueMatt> oops, laptop was having issues and just got back online from fc...guess I missed a second meeting in a row :(
11:53 < cdecker> BlueMatt: still discussing TLV bikesheds, feel free to join the fight
11:54 < bitconner> rusty: the wire protocol needs to handle fields up to 65kb, the onion doesn't. they can use the same algo, just have different parameters
11:54 <+roasbeef> rusty: it doesn't need up to 4 bytes to signal the length, at most we can fit 1.3kb or so
11:54 <+roasbeef> bitconner: def
11:54 < cdecker> Yeah, and I feel uncomfortable allowing even anything >256 in the onion
11:54 < rusty> bitconner: the efficiency difference is literally the case where you have 253, 254 or 255 bytes then?
11:55 < cdecker> But ok, var_int type and var_int length to get a unified TLV spec for wire and onion sounds like a tradeoff
11:55 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
11:56 < cdecker> Ok, we're coming up on time, we have 3 options here: continue discussing here, continue discussing on the issue, or accepting it
11:56 < rusty> cdecker: I think there's a valid case for jup to 512 bytes.  But yeah, bikeshedding.
11:56 -!- watermaniak [~watermani@89.38.96.189] has quit [Remote host closed the connection]
11:56 < cdecker> I think we don't have a quorum for the latter, so more discussion is needed
11:57 < cdecker> Does everybody agree on defering to the issue tracker?
11:57 < rusty> Sure... can we discuss SURBS now?
11:57 < cdecker> Totally forgot about them
11:58 < rusty> (BTW, randomly I looked at some JS implementations of BOLT11 decoding... it's a nightmare and I need to write many more test vectors for BOLT11)
11:58 < cdecker> #agreed everybody to weigh in on the discussion of PR #572
11:58 < cdecker> #topic SURBs as a Solution for Protocol-Level Payment ACKs
11:58 < bitconner> cdecker: agreed
11:59 <+roasbeef> in the future we should really rip out the bech32 from bolt11, it makes things soooo much more complicated vs just a byte buffer that uses base32 
11:59 < cdecker> The surbs mail refers a lot to the EOB proposal by roasbeef, which I just created a counter-proposal for 
11:59 <+roasbeef> since we really don't get much from bech32 since we're encoding such large strings, with the switch over, visually it can stay the same
11:59 <+roasbeef> does it? they're distinct cdecker 
12:00 < cdecker> (I was planning to send that mail much earlier, but didn't finish it in time)
12:00 < rusty> cdecker: yeah, I thought they were indep?
12:00 < cdecker> They are, I'm just re-reading the SURBS mail and got confused :-)
12:00 <+roasbeef> kek
12:01 <+roasbeef> you mean the EOB stuff cdecker ?
12:01 <+roasbeef> flat encoding vs multi-hop encoding 
12:01 < rusty> Note: I'm not sure we'd use SURBs, since we have a much more reliable backwards transmission mechanism than attempting a random backroute, but they are *cool* and we should discuss them.
12:02 <+roasbeef> the SRUB stuff is a possible candidate for the soft errors/acks, tho it's more invasive that re-using the error tunnel
12:02 <+roasbeef> is it more reliable? 
12:02 <+roasbeef> the bakcroute isn't random, then sender selects it
12:02 < cdecker> Oh hey, we don't actually need to re-introduce the e2e packet in the onion format itself, we can just add another field in parallel to the onion that also gets encrypted
12:02 < cdecker> But I honestly don't get why SURBs are better than the current error-return mechanism
12:03 < rusty> roasbeef: pick a random route today and watch it fail, though.  But you know the forward route succeeded.
12:03 <+roasbeef> yeh that's what this is, it's a bckwards packet
12:03 <+roasbeef> cdecker: from a traffic analsysi perspctive, it's indistinguishable from regular payments 
12:03 <+roasbeef> as they're the same size, so there's mroe cover traffic for all 
12:04 < rusty> roasbeef: well, it's totally distinguishable because real payments follow a ->, <-, -> pattern, but that can be fixed.
12:04 <+roasbeef> rusty: sorry still not following, random route for what? the backwards route? 
12:04 < cdecker> Ok, so why not just add a SURB to add_htlc that also gets processed like the rest of the onion (layer peeling)
12:04 < rusty> roasbeef: yeah
12:04 <+roasbeef> rusty: if this was also the error source acks and errors look the same more or less, and that amongst the possible probing traffic as well 
12:05 <+roasbeef> it's not random though...the receiver doesn't know who the sender is, how can they pick a route back to them? 
12:05 < rusty> roasbeef: ah, agreed with that.
12:05 <+roasbeef> cdecker: even more packt expansion 
12:05 < rusty> roasbeef: they don't need to, they just reply.  It's implied.
12:05 < rusty> roasbeef: and everyone has financial incentive to keep that route working.
12:06 <+roasbeef> not that this is more invasive than re-using the error tunnel stuff atm, it just occured to me that we revmoed this featur ehwen we didn't have a use, but imo it's a better way to send back errors than the other thing we came up w/ 
12:06 <+roasbeef> note*
12:06 < rusty> roasbeef: I disagree, it's far less reliable in practice than inline soft errors.
12:06 <+roasbeef> why is it less reliable?
12:06 < rusty> roasbeef: but, better for the network because more traffic.
12:07 < rusty> roasbeef: because most routes fail.
12:07 <+roasbeef> why would this fail? it's independent of payment bandwidth along the route 
12:07 <+roasbeef> there's no payment for the ack, it can proceed on any path
12:07 <+roasbeef> doesn't even need to be the same as the forward path, just like hornet 
12:08 < rusty> roasbeef: but in practice it will be the same, because, as I keep saying, if you pick a random route it often fails.  Ask niftynei or cdecker about their rate of success with probes....
12:09 <+roasbeef> probes don't apply here
12:09 <+roasbeef> probes fail due to insufficinet paymetn bandwidth 
12:09 <+roasbeef> this isn't sending a new payment 
12:09 <+roasbeef> this is an ack 
12:09 < rusty> roasbeef: they also fail because nodes are down.
12:09 < rusty> Or temporarily disconnected.
12:09 <+roasbeef> sure just make sure the backwards route if it isn't the same goes thru active nodes 
12:10 < cdecker> My probes fail mostly due to temporary failures, not insufficient capacity...
12:10 <+roasbeef> this can also be a diff way to do rendezvous that lets you do max hops in both directions 
12:10 < rusty> roasbeef: a peers visibility of the network is only going to get worse in future.  I don't think we can do that.
12:11 <+roasbeef> using a diff route isn't required, it's an option 
12:11 < rusty> roasbeef: an option nobody will use, ebcause it won't work.  See ^cdecker
12:11 <+roasbeef>  /shrug 
12:11 <+roasbeef> up to the sender 
12:12 < rusty> Well, I think we should add soft errors, and keep SURBs up our sleeves in case we find a better use.  I really like them, I just don't think they're going to win here :(
12:13 < cdecker> Agreed, they're a really cool tool, but one that we don't have a necessity for right now
12:13 < cdecker> (believe me I like having tools :-D)
12:13 < cdecker> Ok, seems like we reached 14 minutes overtime, shall we call it a day?
12:14 < cdecker> Any last objections?
12:14 < rusty> I think so...
12:14 < cdecker> #agreed everybody to discuss SURBS on the mailing list
12:15 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
12:15 < cdecker> And I'm looking forward to the feedback to the multi-frame proposals (both mine and roasbeef's) on the ML and the issue trackers
12:15 < cdecker> #endmeeting
12:15 < lightningbot> Meeting ended Mon Feb 18 20:15:38 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:15 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-02-18-19.00.html
12:15 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-02-18-19.00.txt
12:15 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-02-18-19.00.log.html
12:15 < bitconner> thanks cdecker :)
12:16 < cdecker> Thanks everybody for the discussion :-)
12:16 < niftynei> :+1: :waves: (ps rusty/cdecker i'll be afk most of today, holiday in the USA)
12:16 < rusty> Oh, I;ll create a tag for next meeting now, and so people can tag things during the two weeks...
12:16 < araspitzu> hey it's a bit OT but is anyone prototyping on option_simplified_commitment?
12:16 < cdecker> Looking forward to the discussions ^^
12:16 < rusty> bitconner, roasbeef, niftynei: sorry about your holiday day, I missed it...
12:17 < bitconner> rusty: yeah weird day in the us where we celebrate our overlords...
12:17 < rusty> araspitzu: Yes, I have a really messy prototype...
12:17 < rusty> bitconner: that's the spirit!
12:17 < cdecker> Next meeting is March 4 :-)
12:17 < bitconner> :)
12:17 < cdecker> Anybody joining the MIT Bitcoin Expo?
12:17 < sstone> cdecker: yes I'll be there
12:17 < cdecker> It's the weekend after, and they haven't published speakers yet
12:17 <+roasbeef> prob not, seems to not be as good as it was in the past...but that's just me
12:18 <+roasbeef> lol see?
12:18 < araspitzu> rusty: good to know! I'm onto something too, i might ping you for some test eventually :)
12:18 < cdecker> Excellent, looking forward to seeeing you sstone 
12:18 < bitconner> not this year, but sounds fun!
12:19 -!- watermaniak [~watermani@89.38.96.189] has quit [Ping timeout: 240 seconds]
12:19 < sstone> thanks laolu!
12:20 < cdecker> OK, got to go cook dinner, see you guys and gals around
12:20 < sstone> cdecker: see you!
12:21 < sstone> roasbeef: btw did you have time to look at the extension channel queries ?
12:21 <+roasbeef> re SURBs, we'll have to change the hltc add mesasge for the multi-hop locks stuff, so that may be a good opportunity to introduce them 
12:22 <+roasbeef> not yet, my TODO list has a mind of its own these days, things keep replicating 
12:22 <+roasbeef> odn't have much time to work on spec stuff lately :( 
12:22 < sstone> I'd like to propose something for INV-based gossip that is very similar 
12:23 < sstone> I know you had ideas for INV based gossip too that's why I wanted to get some feedback first
12:24 < rusty> https://github.com/lightningnetwork/lightning-rfc/releases/tag/v1.0
12:25 < sstone> but basically INV and queries are almost the same: instead of sending of query you send an inv which means "I have this", with nearly the same data and format
12:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:25 < sstone> rusty: \o/
12:26 -!- kexkey [~kexkey@87.101.92.74] has joined #lightning-dev
12:33 -!- hiroki [a331d17f@gateway/web/freenode/ip.163.49.209.127] has quit [Quit: Page closed]
12:35 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving]
12:43 -!- araspitzu [~ott0disk@134.28.68.51.rdns.lunanode.com] has quit [Quit: Leaving]
12:58 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
13:05 -!- watermaniak [~watermani@89.38.96.189] has quit [Remote host closed the connection]
13:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
13:15 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
13:19 -!- watermaniak [~watermani@89.38.96.189] has quit [Ping timeout: 272 seconds]
13:21 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.3]
13:26 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
13:39 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
13:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds]
14:07 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
14:08 -!- mkl [b6e8a039@gateway/web/freenode/ip.182.232.160.57] has quit [Ping timeout: 256 seconds]
14:11 -!- watermaniak [~watermani@89.38.96.189] has quit [Ping timeout: 240 seconds]
14:16 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
14:20 -!- watermaniak [~watermani@89.38.96.189] has quit [Ping timeout: 255 seconds]
14:27 -!- cam__ [~se3jay@cpe-104-35-13-231.socal.res.rr.com] has joined #lightning-dev
14:29 -!- se3jay [~se3jay@2605:e000:141c:95ca:cc84:a80e:4417:f986] has quit [Ping timeout: 264 seconds]
14:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
14:45 -!- watermaniak [~watermani@89.38.96.189] has joined #lightning-dev
14:46 < lndbot> <addressleak> Congratulantions on lightning-rfc v1.0!
14:49 -!- watermaniak [~watermani@89.38.96.189] has quit [Ping timeout: 244 seconds]
14:51 -!- thomasan_ [~thomasand@2607:fb90:1bd6:4507:fd5c:1b3f:358f:b4e9] has joined #lightning-dev
15:09 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 246 seconds]
15:12 -!- thomasan_ [~thomasand@2607:fb90:1bd6:4507:fd5c:1b3f:358f:b4e9] has quit [Ping timeout: 268 seconds]
15:15 < lndbot> <moli> @addressleak you forgot to order pizza for the devs, now they're gone...
15:24 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
15:26 -!- cam__ [~se3jay@cpe-104-35-13-231.socal.res.rr.com] has left #lightning-dev []
15:33 -!- v8c9X [~v8C16x3R@178.138.35.113] has joined #lightning-dev
15:38 -!- siom [~siom@165.84.231.19] has quit [Remote host closed the connection]
15:52 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has quit [Ping timeout: 246 seconds]
15:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
16:05 -!- mode/#lightning-dev [+o rusty] by ChanServ
16:08 -!- rusty changed the topic of #lightning-dev to: Bitcoin Lightning Network Development: Be Excellent To Each Other!  Logging at http://gnusha.org/lightning-dev/ Next Meeting: https://github.com/lightningnetwork/lightning-rfc/issues/577
16:08 -!- mode/#lightning-dev [-o rusty] by rusty
16:24 -!- shesek [~shesek@141.226.217.238] has joined #lightning-dev
16:24 -!- shesek [~shesek@141.226.217.238] has quit [Changing host]
16:24 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
16:33 -!- kexkey [~kexkey@87.101.92.74] has quit [Quit: Scaling pentatonically]
17:12 < lndbot> <addressleak> I am so sorry, i was AFK :(
17:24 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
17:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
17:51 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
17:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Client Quit]
18:15 -!- unixb0y [~unixb0y@p5B029C62.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
18:18 -!- unixb0y [~unixb0y@p5B029B41.dip0.t-ipconnect.de] has joined #lightning-dev
18:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
18:22 -!- m8tion [~user@2a01:e35:8bef:9310:100c:b6f0:1e34:944d] has quit [Remote host closed the connection]
18:23 -!- thomasan_ [~thomasand@2607:fb90:cdb:4605:259e:8927:6778:fe4e] has joined #lightning-dev
18:35 -!- thomasan_ [~thomasand@2607:fb90:cdb:4605:259e:8927:6778:fe4e] has quit [Remote host closed the connection]
18:49 -!- Madars [~null@unaffiliated/madars] has quit [Read error: Connection reset by peer]
18:53 < drolmer> I wonder if they are any thoughts regarding nodes' pubkey being associated to people/identities from a privacy/security standpoint. Is it a bad practice? (assuming Tor-only nodes or ones without public clearnet addresses)
18:54 < drolmer> (meaning is it a bad practice to publicly share your node's pubkey either plainly or through an invoice as we see with the LightningTorch)
18:54 < lndbot> <alexbosworth> It would be nice if we had multiple public keys to use for identities but there are some inherent limitations in LN
18:55 < lndbot> <alexbosworth> I wouldn’t say it’s any worse practice than sharing an address
18:57 < drolmer> ah, haven't thought of that, that would be interesting
19:10 -!- Madars [~null@unaffiliated/madars] has joined #lightning-dev
20:17 -!- kexkey [~kexkey@87.101.92.74] has joined #lightning-dev
20:24 -!- kexkey [~kexkey@87.101.92.74] has quit [Ping timeout: 246 seconds]
21:06 -!- foureighttwonine [~foureight@82.102.28.107] has joined #lightning-dev
23:14 -!- www-let [910ff41a@gateway/web/freenode/ip.145.15.244.26] has joined #lightning-dev
23:15 -!- www-let [910ff41a@gateway/web/freenode/ip.145.15.244.26] has quit [Client Quit]
23:25 -!- Blackwolfsa [sid307900@gateway/web/irccloud.com/x-pyqbyuzxqnbfdler] has quit [Excess Flood]
23:25 -!- Blackwolfsa [sid307900@gateway/web/irccloud.com/x-ctrdzpqjiuicrbel] has joined #lightning-dev
23:58 -!- zerogue [~irc@nullstruct.com] has quit [Quit: Goodbye Cruel World]
--- Log closed Tue Feb 19 00:00:54 2019