--- Log opened Mon Oct 25 00:00:13 2021
00:01 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection]
00:01 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
00:45 -!- csknk [~csknk@88.87.164.26] has joined #lightning-dev
00:59 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection]
00:59 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #lightning-dev
01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:08 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has joined #lightning-dev
01:16 -!- commmon [~common@096-033-221-075.res.spectrum.com] has quit [Remote host closed the connection]
01:17 -!- commmon [~common@096-033-221-075.res.spectrum.com] has joined #lightning-dev
01:20 -!- inara [~inara@static.38.6.217.95.clients.your-server.de] has quit [Quit: Leaving]
01:24 -!- inara [~inara@static.38.6.217.95.clients.your-server.de] has joined #lightning-dev
03:01 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #lightning-dev
03:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 276 seconds]
03:47 -!- csknk [~csknk@88.87.164.26] has quit [Ping timeout: 260 seconds]
04:27 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has quit [Remote host closed the connection]
04:36 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
04:36 < lnd-bot> [lightning-rfc] t-bast force pushed 3 commits to route-blinding: https://github.com/lightningnetwork/lightning-rfc/compare/cc855c754bca...f4ea7620eeec
04:36 < lnd-bot> lightning-rfc/route-blinding 7d470f0 t-bast: Route Blinding
04:36 < lnd-bot> lightning-rfc/route-blinding 5b84849 t-bast: Add route blinding spec requirements
04:36 < lnd-bot> lightning-rfc/route-blinding f4ea762 t-bast: Remove AAD and add more TLVs
04:36 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
04:50 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has joined #lightning-dev
05:36 -!- gleb71 [~gleb@178.150.137.228] has joined #lightning-dev
05:36 -!- gleb7 [~gleb@178.150.137.228] has quit [Ping timeout: 258 seconds]
05:36 -!- gleb71 is now known as gleb7
06:29 -!- csknk [~csknk@88.87.164.26] has joined #lightning-dev
07:55 -!- ghostkeeper [~ghostkeep@47.196.70.51] has joined #lightning-dev
08:23 -!- csknk [~csknk@88.87.164.26] has quit [Ping timeout: 244 seconds]
09:19 -!- jamesob [uid180710@id-180710.helmsley.irccloud.com] has joined #lightning-dev
09:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
11:09 -!- csknk [~csknk@88.87.164.26] has joined #lightning-dev
11:13 -!- csknk [~csknk@88.87.164.26] has quit [Client Quit]
11:33 -!- gene [~gene@gateway/tor-sasl/gene] has joined #lightning-dev
11:50 < BlueMatt> meeting in 10 :)
11:55 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
11:55 < lnd-bot> [lightning-rfc] t-bast merged pull request #930: Make Markdown linguist-detectable (master...20211024) https://github.com/lightningnetwork/lightning-rfc/pull/930
11:55 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
11:55 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
11:55 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/86a96ea7c6e9...39806e7d8b45
11:55 < lnd-bot> lightning-rfc/master 39806e7 katesalazar: Make Markdown linguist-detectable (#930)
11:55 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
11:56 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev
11:59 < gene> hi
11:59 < t-bast> hey everyone
11:59 < mschmoock> hi
12:00 < gene> o/
12:00 < ariard> hi
12:00 < mschmoock> \o
12:00 < roasbeef> mad late with the email, but typing up a summary of the meatspace discussions from 2 weeks ago, 1/3 ish done, should be out by today np 
12:00 -!- lucasdcf [~lucasdcf@2804:431:c7d9:3516:eba7:9f6b:1793:ef09] has joined #lightning-dev
12:00 < t-bast> I put up a tentative agenda here: https://github.com/lightningnetwork/lightning-rfc/issues/925
12:00 < BlueMatt> t-bast: in the future, can we avoid doing prs against branches directly on lightningnetwork/lightning-rfc? I find it a bit strange that contributors push branches there to PR from (ie having "not officially-blessed" branches there)
12:00 < BlueMatt> not a big deal, just wanted to mention it.
12:01 < t-bast> BlueMatt: sure no worries, I'll move my branches to a fork
12:01 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:20f0:70e4:ff16:cb0] has joined #lightning-dev
12:01 -!- crypt-iq [~crypt-iq@2603-6080-8f06-6d01-f42a-3dfe-0bb5-a3b7.res6.spectrum.com] has joined #lightning-dev
12:01 < t-bast> BlueMatt: especially if we move the repos to the lightning org, good occasion to clean up my setup
12:01 < BlueMatt> t-bast: fwiw, wrong link for the agenda
12:01 < BlueMatt> unless the one thing we're doing today is moving the repo :)
12:02 < BlueMatt> agenda is https://github.com/lightningnetwork/lightning-rfc/issues/929
12:02 < BlueMatt> lets start?
12:02 < t-bast> woops good catch, looks like I was meaning this one to be tackled first xD
12:02 < t-bast> yep, let's start, can someone else chair? I'll need to leave in 1h
12:03 < t-bast> roasbeef: no worries, no rush on that summary!
12:03 < t-bast> just wait for a sec, cdecker is starting the bot!
12:03 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
12:04 < cdecker[m]> Bot should have started
12:04 < t-bast> I can chair though, let's do this and we'll keep it a 1h meeting max
12:04 < t-bast> #startmeeting LN Spec Meeting
12:04 < lndev-bot> Meeting started Mon Oct 25 19:04:48 2021 UTC and is due to finish in 60 minutes.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:04 < lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:04 < lndev-bot> The meeting name has been set to 'ln_spec_meeting'
12:04 < cdecker[m]> Since I'll not stick around till the end I probably shouldn't chair
12:04 < roasbeef> ah yeh as we found out, the bot 2 weeks ago, the bot isn't fully autonomous ;) 
12:05 < t-bast> The bot is cdecker's puppet
12:05 < crypt-iq> mechanical turk?
12:05 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/929
12:05 < t-bast> #topic Moving to a new org
12:05 < BlueMatt> cc roasbeef 
12:05 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/925
12:05 < cdecker[m]> Couple of people in the the video chat, but all decisions are to be taken in written form
12:06 < roasbeef> can't join the chat rn, will prob hover there in the future as able to 
12:06 < t-bast> roasbeef could you give us rights on the lightning repo?
12:06 < roasbeef> ok yeh re the org, mainly waiting for buy in from some of the other devs, seems we're all generally on board with it though? 
12:07 < t-bast> I don't think we've heard from rusty though
12:07 < roasbeef> yeh 
12:07 < t-bast> does someone know if he's down with moving the repos there?
12:07 < roasbeef> also Q of who should be made admin, was gonna add the "OG/lead dev" of the major impls, then let them take it from there 
12:07 < cdecker[m]> Rusty excuses himself, and likely won't be joining today
12:08 < roasbeef> cdecker[m]: do you know how he feels about the general concept? I can reach out directyl as well if needed
12:08 < ariard> sgtm as long as we have someone from each impl
12:08 < BlueMatt> roasbeef: sgtm, we haven't had any issues with repo rights yet, lets not worry too much about it until its a problem :)
12:09 < t-bast> So maybe let's wait for rusty to ACK on this, and we'll move then?
12:09 < cdecker[m]> For reference, Lisa and I are happy with moving the the RFC repo, and this way around the import paths don't get screwed either
12:09 < roasbeef> ok i'll reach out to him directly re that 
12:09 < cdecker[m]> Sounds good to me ^^
12:10 < t-bast> thanks roasbeef, can you also ask him whether he'd like us to rename it to lightning/bolts or keep lightning-rfc?
12:10 < roasbeef> yeh 
12:10 < t-bast> I like lightning/bolts and lightning/blips FWIW, but I can understand why some may want the more standard "RFC" naming
12:11 < t-bast> #action roasbeef to ping rusty about org move, and initiate it if we're all on board with it
12:12 < roasbeef> #903 next?
12:12 < roasbeef> I see comments filled in there, I'll make sure to get to them this week 
12:12 < t-bast> Yep let's do that
12:12 < t-bast> But I think it's just a call to action
12:13 < t-bast> If you have some time to address the comments this week roasbeef, it's all good and we can move on to something else
12:13 < t-bast> #topic Ping rate limitation
12:13 < roasbeef> yeh should be able to 
12:13 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/918
12:13 < t-bast> great, let's keep it on github then, thanks!
12:13 < t-bast> BlueMatt proposed removing that limitation from the spec
12:13 < t-bast> I think it makes sense
12:13 < roasbeef> no strong feelings on thi sone myself, but at the same time don't see the harm in the current langauge 
12:13 -!- niftynei__ [~niftynei@2603-8080-1408-3b48-14ac-5f26-e4d8-6a02.res6.spectrum.com] has joined #lightning-dev
12:13 < roasbeef> this one*
12:14 < roasbeef> as is it's just an advisory in either case right? 
12:14 < mschmoock> what does a node do when he gets flooded?
12:14 < roasbeef> so don't send too many, and maybe disconnect if they're sending too many 
12:14 < mschmoock> :]
12:14 < BlueMatt> mschmoock: if you have a problem getting flooded with pings you're very, very screwed at that point
12:14 < t-bast> yeah, but why a specific duration though?
12:15 < roasbeef> t-bast: agreed is arbitrary, is there another duration? 30 seconds seems like "long enough" I guess? 
12:15 < cdecker[m]> Pings can already be rather large, so even with a 30 sec timeout the traffic can be coniderable (2KB / s / connection)
12:15 < crypt-iq> Did mschmoock mean packet flood in general rather than ln-ping-flood
12:15 < BlueMatt> my point is largely that if you're worried about getting ping-floods your're, like, really really doing it wrong
12:15 < mschmoock> I meant LN ping flood
12:15 < BlueMatt> cause, like, I can also send gossip messages duplicatively, or, like, tcp keepalives or whatever
12:15 -!- gene is now known as mzpetty
12:15 < mschmoock> Jep I know
12:15 < roasbeef> should we soften the langauge rather than removing all together?
12:15 -!- mzpetty is now known as gene
12:15 < BlueMatt> or, like, just send you a udp flood of non-lightning traffic
12:16 < roasbeef> seems were conflating like general DoS with recommended rate limiting at the protocol level?
12:16 < t-bast> true, let's not conflate these and just stick to removing this arbitrary ping limitation?
12:16 < BlueMatt> I think so - why are we recommending rate-limiting pings in the protocol? its a really useless anti-dos mechanism by itself
12:16 < roasbeef> fwiw lnd sends pings every 1 minute rn 
12:16 < BlueMatt> nodes should do *something* about dos, but this isn't it
12:16 < roasbeef> jsut to advise re best practices? 
12:16 < mschmoock> BlueMatt: okay
12:17 < BlueMatt> roasbeef: fwiw we've moved to 3 seconds
12:17 < gene> could do increasing PoW per connecting client
12:17 < roasbeef> mainly I don't see the harm in the recommendation
12:17 < BlueMatt> and we can/should maybe have a discussion about dos, but that's pretty separate
12:17 < BlueMatt> roasbeef: because we need to be way more aggressive on mobile
12:17 < BlueMatt> and so this recommendation is preventing us from doign so
12:17 < ariard> gene: ouch for the mobile clients on low-grade CPUs
12:17 < BlueMatt> doing so
12:17 < BlueMatt> well, "preventing", we're doing it now anyway and seem to have no issues :)
12:17 < cdecker[m]> Duplicate in-flight Pings are still prohibited? If yes there's a simple way of throttling the peer
12:17 < BlueMatt> except for the occasional nodes-on-rpis that are too slow, but...
12:18 < roasbeef> iirc re mobile, we ended up tuning our read/write timeoutes to accomodate the higher latency/roaming env 
12:18 < gene> the client starts with low-no PoW, then increases log scale with each subsequent request
12:18 < gene> well-behaving clients would rarely, if ever, have to send more than a few hashes worth of PoW
12:18 < roasbeef> gene: LN nodes can already kinda opt to just not have connections to anyone that doesn't have a channel with them
12:18 < BlueMatt> gene: meh, I dunno if we need to?
12:18 < crypt-iq> doesn't rust-lightning then separate itself from the plebnet/rpi graph
12:18 < roasbeef> what do you mean separate? 
12:19 < crypt-iq> Like if you require a 3s ping and the rpi's are slow
12:19 < BlueMatt> crypt-iq: nah, you just disconnect/reconnect once an hour
12:19 < gene> BlueMatt: mb not, just throwing ideas out there. maybe that one is dumb/unworkable
12:19 < BlueMatt> gene: the broader issue is if you're worried about *incoming* traffic, you can't do anything but pay cloudflare/a ddos provider. if you're worried about *ougoing* traffic, stop sending stuff!
12:19 < gene> PoW was originally for DoS protecc tho
12:19 < roasbeef> even w/ this removed, impls can still do w/e arbitrary things to rate limit pings
12:19 < BlueMatt> yes, but I can udp flood you too and you still get packets :p
12:20 < roasbeef> just like a lot of thigns aren't spelled out in the spec, but impls do in practice anyway 
12:20 < BlueMatt> roasbeef: no?
12:20 < mschmoock> cdecker[m]: from what I read there is no " Duplicate in-flight Pings are prohibited" rule
12:20 < roasbeef> do we want to instead lower the interval here?
12:20 < BlueMatt>  - MUST respond by sending a `pong` message, with `byteslen` equal to `num_pong_bytes`.
12:20 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
12:20 < BlueMatt> the spec is very clear here
12:20 < gene> packets == drop after certain threshold?
12:20 < BlueMatt> you MUST respond
12:20 < roasbeef> BlueMatt: I mean we all do a lot of throttling for gossip messages that isn't spelled ou tin the spec 
12:20 -!- rusty [~rusty@220-244-196-8.tpgi.com.au] has joined #lightning-dev
12:20 < BlueMatt> if you dont like the peer and its being stupid, disconnect it and close your channels with it
12:20 < gene> ^
12:20 < BlueMatt> roasbeef: IIRC that part of the spec is SHOULD
12:20 < BlueMatt> not MUST
12:21 < mschmoock> Also, I doubt you should do a ping each 3sec especially on mobile
12:21 < mschmoock> but maybe thats just me :D
12:21 < roasbeef> idk, doesn't seem like the rest have strong opinions re sending more pings or w/e 
12:21 < BlueMatt> if you dont like how often someone is sending you packets, you go to your anti-ddos provider and tell them about your new firewall rule, there's just really not a lot else you can do
12:21 < BlueMatt> mschmoock: if you're in the background, no, but you generally don't get cpu time when you're in the backgrouna and not charging/on wifi anyway :p
12:22 < mschmoock> For a reason
12:22 < t-bast> I acked the PR, I think we should remove this requirement because we indeed need to be more aggressive on mobile if you hope to keep them alive, and I don't think the spec can provide a good enough / works everywhere rule of thumb / magic number here
12:22 < crypt-iq> impls won't know each others ping timeouts, so are they supposed to respond asap
12:22  * gene groans about DDoS  providers requiring non-free JS
12:22 < BlueMatt> mschmoock: yes, because stupid people like me keep writing apps that wake up the radio too often :p
12:22 < mschmoock> If my mobile wallet would do 3sec pings I would surely uninstall it
12:23 < BlueMatt> gene: i do hope your only complaint about the NSA^H^H^Hddos providers isn't just the non-free JS, 
12:23 < roasbeef> idk we'll prob eventually rate limit pings if ppl start spamming it, there's an open issue for it, similar to all the stuff ppl started doing once gossip messages were spammed/churned a ton
12:23 < cdecker[m]> crypt-iq: this is not about the liveness decision, this is just about how often you're allowed to check
12:23 < BlueMatt> roasbeef: the spec is very clear that you MUST NOT do that. if you have an issue with that, you should speak now :)
12:23 < mschmoock> cdecker[m]: yes
12:23 < BlueMatt> roasbeef: and propose something else
12:23 < gene> BlueMatt: surely more, like what that non-free JS allows alphabet soup to do to users
12:23 < cdecker[m]> I.e., you're free to wait before replying however long you want
12:23 < BlueMatt> like "no more than one ping in flight at once" or whatever
12:23 < mschmoock> cdecker[m]: I there a "duplicate inflight not allowed rule" ? 
12:23 < mschmoock> *is
12:24 < mschmoock> If so, go for 0.1secs pings
12:24 < mschmoock> :D
12:24 < crypt-iq> cdecker: got it
12:24 < BlueMatt> there is not currently a duplicate in flight requirement
12:24 < BlueMatt> we could add it, however
12:24 < mschmoock> Good
12:24 < mschmoock> maybe we do this together
12:24 < t-bast> I like that, it sounds reasonable
12:24 < cdecker[m]> I thought there was, what was I thinking of?
12:24 < BlueMatt> can we also require that byteslen be 0
12:24 < mschmoock> remove the throttle replace by a dups disallowed rule
12:24 < BlueMatt> does anyone do padding with pings?
12:24 < roasbeef> yeah we do
12:24 < crypt-iq> we do blockheaders
12:25 < BlueMatt> roasbeef: can you switch to dummy unknown messages for paddings?
12:25 < roasbeef> prior nodes do like 16 bytes or something like that
12:25 < cdecker[m]> BlueMatt: having just reimplemented that part, yes, I get all kinds of sizes
12:25 < roasbeef> and we also do the thing where we send back as muich as dictated in the ping
12:25 < BlueMatt> well, we can say "ping must be 0" today and ignore non-0 pings in 3 years :p
12:25 < cdecker[m]> And I personally like it to have decoy traffic
12:25 < BlueMatt> cdecker[m]: right, my point is decoy traffic can be other messages
12:25 < cdecker[m]> (though nobody uses it like that yet)
12:25 < roasbeef> idk, tbh this doens't seem very important to me, and nice to have that decoy measure in there as cdecker[m]  mentions
12:25 < BlueMatt> agree decoy traffic is good
12:26 < t-bast> +1 for decoy traffic (some day)
12:26 < BlueMatt> well then I'm confused, if you're annoyed at the amount of bandwidth, maybe the easiest solution is to not allow pongs up to 64KB :p
12:26 < cdecker[m]> It's just the simplest way of simulating a query-reply that is common for the protocol without having to use non-fitting other data
12:26 < crypt-iq> Is it much of a decoy if the ping is on a timer ? This is decoy for a network-level adversary
12:26 < mschmoock> BlueMatt: about using low interval pings on mobile (not related to this discussion) it comes with a high cost, it forces the radio to staay active which kills the battery
12:26 < crypt-iq> on a static timer*
12:26 < roasbeef> didn't make the bandwidth arg, just re general rate limiting of stuff peers send you, like if there's a peer that sends you the same bogus chan_ann 10000x, what do you do? 
12:27 < cdecker[m]> I think the "no duplcate" rule + "decoy traffic" is limitation enough tbh
12:27 < BlueMatt> cdecker[m]: yea, that's true I suppose, just feels awkward to try to get cbr from pings and not by both sides doing cbr
12:27 < roasbeef> but just something I don't feel strongly about really, seems RL is the one that cares mainly about pings and wants to send them more frequetnyl 
12:27 < cdecker[m]> crypt-iq: c-lightning does ping at irregular intervals too, but I see your point
12:27 < BlueMatt> mschmoock: yes, but the os prevents you from doing that in effect - you only get tcp time if you're in the foreground and the app is open, at which point users *want* things to be responsive (and generally happens for 10 seconds at a time)
12:27 < cdecker[m]> cbr?
12:28 < BlueMatt> constant bit rate
12:28 < mschmoock> Just saying, I have dealt whith this stuff a lot
12:28 < mschmoock> and android and ios behave very differntly :D
12:28 < BlueMatt> mschmoock: well in any case, we leave these decision up to our users, we dont decide for them. and users nagged us for this, soooo :)
12:28 < mschmoock> I can imagine
12:29 < cdecker[m]> BlueMatt: I see, I thought of this more like pretending to send an HTLC or a commitment, and asking the remote side to reply with a reasonable sized response
12:29 < BlueMatt> cdecker[m]: right, I think that's a really really bad way to try to get cover traffic
12:29 < BlueMatt> cdecker[m]: if you want cover traffic, you can do cbr (and maybe a second connection for gossip that doesn't do htlc relay)
12:29 < cdecker[m]> Because you're tempted to do it as a mirror of actual stuff happening, now tipping off unrelated peers?
12:29 < roasbeef> design space is open, no reason to shut off the possibility of it all together via this vector 
12:30 < BlueMatt> sure, alright, I dont care about the pong len, I was just suggesting a way to do rate limiting I thought others might like
12:30 < BlueMatt> so is there a concrete suggestion here? the "no more than one in flight" seems like it breaks some cover traffic models
12:30 < gene> are amplification attacks a concern?
12:31 < mschmoock> BlueMatt: maybe allow 2 or some more inflight :D
12:31 < BlueMatt> gene: amplification of what form?
12:31 < roasbeef> if it ain't broke...
12:31 < BlueMatt> mschmoock: to be fair, I kinda doubt any implementation is going to *enforce* the "in flight limit" requirement - its a huge pain and massive layer violation to enforce it in code
12:31 < gene> reply (much?) longer than request, malleable destination (doesn't return to requester)
12:31 < niftynei__> qq about "only one in flight at a time" -- how do you decide when your peer's offline/not responding so you can send another ping?
12:31 < t-bast> Or just remove the 30 seconds without changing anything else for now...?
12:32 < BlueMatt> niftynei__: presumably if the peer is offline/not responding after N seconds you drop the tcp connection
12:32 < t-bast> Like the current state of the PR :)
12:32 < BlueMatt> t-bast: that implies that you MUST NOT rate-limit, which roasbeef said he was planning on violating
12:32 < niftynei__> so if peer doesn't respond you drop and don't reconnect?
12:32 < BlueMatt> so I'd kinda prefer we not tweak the spec and then have lnd go shit on it again in 6 months
12:32 < cdecker[m]> Agreed with t-bast, let's remove that now, replace later
12:32 < roasbeef> if this is about the connection itself, then isn't it possible to set a lower tcp keep alive probe/time at a lower level? 
12:32 < BlueMatt> niftynei__: you totally should reconnect! but you cant ping until that's done :)
12:32 < cdecker[m]> The 30 second limitation will linger around anyway, so we havetime to find a replacement
12:33 < BlueMatt> roasbeef: tcp keepalives are fairly unreliable
12:33 < roasbeef> yeah there's also no way of knowing what kinda timer/rate teh other peer even uses 
12:33 < BlueMatt> and a pita
12:33 < niftynei__> so .. "at a time" means "per tcp connection session"?
12:33 < mschmoock> Mobile operators use all kind of nasty equiment that kill your TCP session without you knowing once in a while
12:33 < BlueMatt> the spec change in this pr, as suggested requires that you respond (though I suppose you could creatively interpret the spec to simply say "delay outbound pong messages to 1/second, and take days to respond to a flood, which is fine)
12:34 < BlueMatt> mschmoock: yes, that's why we use pings in the protocol :)
12:34 < BlueMatt> niftynei__: unclear! good reason to remove it :)
12:34 < BlueMatt> roasbeef: so what's y'all's plan? are you intending to rate-limit soon - and if so what can we put in the spec so that isn't a gratuitous incompatibility?
12:34 < t-bast> BlueMatt: but it only requires you to respond to *one* of the pending pings, right?
12:35 < BlueMatt> roasbeef: you're the only one here who said you can't live with this suggested change
12:35 < BlueMatt> t-bast: no.
12:35 < BlueMatt> t-bast: not the way i read it?
12:35 < BlueMatt>  A node receiving a `ping` message:
12:35 < BlueMatt>   - if `num_pong_bytes` is less than 65532:
12:35 < BlueMatt>     - MUST respond by sending a `pong` message, with `byteslen` equal to `num_pong_bytes`.
12:35 < BlueMatt> that's pretty clear, I think
12:35 < t-bast> Right, that is clear indeed, my bad, I was looking at that one: "if byteslen does not correspond to any ping's num_pong_bytes value it has sent: " and made a shortcut
12:36 < crypt-iq> I thought the proposed change to lnd was to enforce timely pong replies ?
12:36 < BlueMatt> <roasbeef> idk we'll prob eventually rate limit pings if ppl start spamming it, there's an open issue for it, similar to all the stuff ppl started doing once gossip messages were spammed/churned a ton
12:36 < roasbeef> maybe lets timebox this re other stuff? 
12:36 < BlueMatt> roasbeef: can you comment on the pr with a concrete suggestion?
12:36 < BlueMatt> then we can move on
12:36 < roasbeef> BlueMatt: no immediate plans to rate limit, but was brought up by a newer developer wondering why we _didn't_ as is
12:37 < t-bast> If there's no immediate plans to rate-limit at the ping level, I like the PR as-is, and once plans to rate-limit start forming we can open a new PR to accomodate it?
12:37 < mschmoock> t-bast: the problem with that is...
12:38 < roasbeef> crypt-iq: yeh there's that issue, but someone else brought up just rate limiting it in general too
12:38 < mschmoock> a stipid implementation can then send too many pings without waiting for response. when we add later, we need to make harder decisions
12:38 < roasbeef> any rate limit thing would just be avisory or impl specific really, right? just like we all rate limit gossip messages differently 
12:38 < t-bast> mschmoock: just close the connection on them then...?
12:38 < mschmoock> and the channel ?
12:38 < BlueMatt> roasbeef: rate-limiting gossip doesn't imply that nodes cant talk to each other
12:38 < roasbeef> I'm cool w/ whatever here tbh, no strong feelings, not super important to me 
12:39 < BlueMatt> roasbeef: the outcome of incompatible rate-limits here would actually be network breakage
12:39 < t-bast> mschmoock: and ban them if you want, fail the channels if they're behaving maliciously
12:39 < mschmoock> yep, maybe we are talking about stuff that never matters
12:39 < t-bast> I don't think this will actually be an issue to be honest
12:40 < mschmoock> not really, I would more likely spam a node on 0msat base fee in 10000 circles :D
12:40 < BlueMatt> no, i doubt it will either, but if someone says "I'm gonna violate that spec requirement" when we're deciding to add one I generally pause cause breakage is bad :p
12:40 < BlueMatt> mschmoock: right lol, hence why I figured we should drop the rate limit
12:40 < mschmoock> and the base fee ^^
12:41 < roasbeef> main thing re spamming it us prob just the bandwidth, since they can make you send 65kb each time, but I guess ppl will do w/e if that pops up, it's the "freest" message we have rn data, since it requires a resposne unlike doing some error ting , soyou can make things symmetric
12:41 < BlueMatt> roasbeef: right, hence why i suggested reducing the size limit
12:41 < BlueMatt> but...:shrug:
12:41  * roasbeef 1 hour later *spongebobe narrator voice
12:42 < t-bast> so...shall we voice opinions on the PR with either concrete counter-proposals or acks?
12:42 < t-bast> and move on to the next topic?
12:43 < mschmoock> Maybe someone wants to add more info on the decoy traffic stuff in the PR
12:43 < mschmoock> because otherwise i still prefere no more dups inflight rule
12:43 < BlueMatt> mschmoock: the issue with no dups in flight is its really a pita to enforce at the code-level
12:43 < BlueMatt> but lets move
12:43 < BlueMatt> on
12:43 < mschmoock> kk. just wanted to bring that in
12:44 < mschmoock> * next :D
12:44 < t-bast> #action progress on the PR, provide concrete proposals there
12:44 < t-bast> #topic Dust Exposure
12:44 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/919
12:44 < t-bast> On that one, rusty proposed doing it differently
12:45 < t-bast> niftynei do you agree with him on that? Shall we defer and discuss that with him next time, or shall we cover it today?
12:45 < BlueMatt> there's a few comments here, I'd suggested being much less prescriptive
12:45 < BlueMatt> cc ariard 
12:45 < niftynei__> i agree with the assessment that it's a proposal to do it differently :P
12:45 < roasbeef> iirc this was the original approach re a protocol extension, but then we went w/ the things we could just implement as accepting/forwarding policy essentially? 
12:45 < cdecker[m]> I'm lagging a bit behind on this, so I won't speak for Rusty here :-)
12:45 < t-bast> I agree about being less prescriptive on the actuel thresholds (dust buffer feerate)
12:45 < t-bast> niftynei: xD
12:45 < roasbeef> oh no this is diff 
12:45 < ariard> Right the `dust_buffer_feerate` should be left to implementers wisdom
12:45 < BlueMatt> sounes like "pending response to pr review feedback from ariard"
12:46 < niftynei__> the biggest difference imo is that there's an agreed/implicit 'dust bucket threshold' btw the two peers
12:46 < niftynei__> which is set to 0.5% of the channel or *waves hands*
12:46 < ariard> the issue with a protocol extension is risk exposures of node operators are not taken into accounts
12:46 < niftynei__> with a minimum of one dust htlc allowed per channel (which i think is .. reasonable?)
12:47 < t-bast> I agree with ariard there, as expressed on the PR I don't think we can capture it well enough with a static percentage of the channel capacity
12:47 < BlueMatt> may be worth noting that there's not really a way to avoid force-closure in some cases around feerate changes without a protocol extension :(
12:47 < niftynei__> yeah, rolling it out requires upgrades on both channel sides
12:47 < niftynei__> so it's definitely a slow fix
12:47 < BlueMatt> we're hoping its rare enough to not be an issue
12:47 < t-bast> But these force-closure don't happen when using anchor outputs zero fee though
12:47 < cdecker[m]> t-bast: can we do #911 next? We have merged our websocket support, and would like to hammer down the address type number, since it conflicts with DNS now, and our release is this week
12:47 < BlueMatt> but may be worth noting
12:47 < ariard> BlueMatt: you can shrugg about the dust exposure and prefer NOT to force-close, i think eclair is doing that ?
12:47 < crypt-iq> a minimum of one dust htlc allowed per channel is counter to option_dusty_htlcs_uncounted, which I know I've been sleeping on
12:47 < BlueMatt> t-bast: right, anchor makes the whole thing a non-issue anyway
12:48 < t-bast> So if we're all moving towards anchor outputs zero fee, and specing channel upgrades soon (TM) we may not need to bikeshed this?
12:48 < niftynei__> idk man this dust bucket thing is pretty problematic in general, afaict big sudden feerate changes are kinda deadly to your ability to route payments
12:48 < BlueMatt> so maybe it isn't even worth documenting any of it and we rip out all references to non-0-fee anchor stuff acros the spec :p
12:48 < t-bast> cdecker[m]: sure, next topic will be that one
12:48 < niftynei__> well, uncounted dust htlcs still counts against your 'dust bucket limit'
12:48 < niftynei__> which if you're using a 0.5% ceiling for might be ... very very small htlcs
12:48 < cdecker[m]> Thanks, that'll allow us to move bump the type out of the way if there's a conflict
12:48 < crypt-iq> if you have zero-fee-anchors (echoing here), you can just use the forwarding heuristic rather than an upgrade
12:49 < ariard> t-bast: +1, i can even propose that mitigation as a blip and up to everyone ?
12:49 -!- sr_gi [~sr_gi@static-43-117-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
12:49 < crypt-iq> > well, uncounted dust htlcs still counts against your 'dust bucket limit', I gotcha
12:50 < niftynei__> like yes, im in bigly favor of the 483 limit only touching non-dusty htlcs, but that's complicated right now... what do you do when the feerate drops and some "were dusty but now are not dusty" htlcs should be added to the 483 number?
12:51 < niftynei__> yes yes, easier with a fixed dust rate (eg zero anchor etc)
12:51 -!- sr_gi [~sr_gi@static-43-117-230-77.ipcom.comunitel.net] has joined #lightning-dev
12:51 < crypt-iq> right so maybe only if zero-fee-anchor
12:51 < roasbeef> cdecker[m]: mschmoock: so what gets 5 is the thing merged first? (dns vs ws)
12:51 < niftynei__> feerate changes suck
12:51 < t-bast> ariard: interesting, I don't know if it should be only a blip, as all implementations really need to implement *some kind of dust exposure limit* to be safe
12:51 < ariard> maybe let's do `option_dusty_htlcs_uncounted` only with zero-fee annchor
12:51 < niftynei__> yeah this is not a BLIP
12:52 < mschmoock> roasbeef: Thats what I want to know :D
12:52 < BlueMatt> ariard: why does it need an option? you can just reject them if you have 0-fee anchor, no?
12:52 < t-bast> that's why you should all shill glozow's PRs: with anchor outputs and package relay, update_fee can finally go away!
12:52 < BlueMatt> t-bast: :+1:
12:52 < niftynei__> so like, what's the status with this zero anchor thing?
12:52 < rusty> You can't, in general, set a threshold on your peer and not tell them.  You can, however, limit what you send.  IMHO we should just pick a number and start there, then later enforce it on receive, if we really care.
12:52 < t-bast> a wild rusty appears
12:53 < cdecker[m]> roasbeef: Sort of, I'm not sure we ever exchange the websocket one with anyone, so might not need a low type allocated, the important part is that implementations need to know how long the addresses are (ws = 2bytes port)
12:53 < BlueMatt> niftynei__: we merged it! we probably need channel upgrades tho
12:53 < crypt-iq> rusty: why can you not just fail back immediately after commitment without force closing in the zero-fee-anchors case?
12:53 < BlueMatt> (merged it in spec, that is)
12:53 < roasbeef> mschmoock: the DNS one is pretty small so maybe just do that first and it gets 5, then ws gets 6? cdecker[m] 
12:53 < ariard> BlueMatt: in case of update_fee, you can accept that your dust exposure is overflow instead of force-closing the chan because the feerate is unsafe
12:53 < niftynei__> BlueMatt, dont we need package relay?
12:53 < roasbeef> cdecker[m]: what do you mean exchange w/? as in advertise on gossip w/ y'alls current impl? 
12:53 < niftynei__> package relay and "umbrella RBF" lol
12:53 < roasbeef> rusty: while you're here, thoughts on https://github.com/lightningnetwork/lightning-rfc/issues/925 ? 
12:53 < BlueMatt> niftynei__: everything in lightning needs package relay :p
12:54 < cdecker[m]> Yep, it's not being shared with peers, it's just using the same serialization internally, which muddies the water
12:54 < niftynei__> someone call USPS and get them on this stat
12:54 < BlueMatt> ariard: hmm?
12:54 < mschmoock> roasbeef: rusty merged in websockets type 5 already (though experimental)
12:54 < mschmoock> (in clightning)
12:54 < BlueMatt> sounds like ws gets 5, cause its just a number, and that sounds like less coding work :)
12:54 < roasbeef> ok ws 5, dns 6? 
12:55 < BlueMatt> (does mean you have to support reading 5 to read dns, but so what)
12:55 < cdecker[m]> roasbeef: actually I'll just move the numeric type to something large (250), because it is only used internally
12:55 < mschmoock> just to be clear, implementations must ignore 6 when they cant read 5
12:55 < cdecker[m]> DNS should get type=5!
12:55 < BlueMatt> y
12:55 < roasbeef> I think CL has implemented both already fwiw, the ws PR is on my TOOD list of things to impl 
12:55 < cdecker[m]> mschmoock: yep, that's the main issue: we order them by type, the first one an impl doesn't know terminates the parsing
12:55 < roasbeef> mschmoock: wait thought you just ignored that addr? since there's a lnegth prefix you can skip 
12:56 < mschmoock> nope
12:56 < cdecker[m]> Nope, there is no length prefix... :-(
12:56 < mschmoock> it must ignore the following ones. It can however implement it by ignoring the data ;)
12:56 < t-bast> rusty: the main issue I have with telling your peer the threshold is that it will likely be dynamic, and handling updates of such parameters is a pita
12:56 < BlueMatt> maybe we define type 5 to "tlv stream" and call it a day :p
12:56 < roasbeef> ok confirmed we terminate when parsing too 
12:56 < cdecker[m]> Saving a couple of bytes, in spite of unparseability as a result
12:56 < roasbeef> (terminate on unknown type)
12:56  * BlueMatt ducks
12:57 < t-bast> looks like we moved to DNS
12:57 < roasbeef> heh
12:57 < rusty> t-bast: yeah, it's a dumb idea.  Hence nail it in the spec to some value and go home.
12:57 < niftynei__> BlueMatt: get out
12:57 < t-bast> #topic DNS addresses in node_announcement
12:57 < cdecker[m]> Welp, I'm not opposed to TLV, but yet another nesting?...
12:57 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/911
12:57 < BlueMatt> it was a joke, dont take me seriously
12:57 < mschmoock> :D
12:57 < t-bast> rusty: but I really don't want my 10 BTC channel to potentially give up 0.5% in miner fees!
12:58 < cdecker[m]> Just to make sure this doesn't create confusion: I will switch the websocket one over to type=250 so no need to drag that into the discussion here. Let's discuss DNS on its own merits ^^
12:58 < rusty> t-bast: 1%, since you could each have that much dust...
12:58 < BlueMatt> cdecker[m]: you cant skip them!
12:58 < t-bast> rusty: I hate it xD
12:58 < BlueMatt> cdecker[m]: oh, wait, ignore me, yes you can
12:58 < crypt-iq> 1% is pretttty high
12:58 < cdecker[m]> Oh, when did rusty join? Didn't see you there
12:58 < rusty> I am not here.... couldn't sleep though.,
12:58 < roasbeef> cdecker[m]: ok so....dns 5, ws 6 (250 for CL internal) 
12:59 < cdecker[m]> BlueMatt: yes, we can, we just can't skip ones from others that we don't know
12:59 < ariard> well ultimately you could be fine with really high level of dust exposure if your counterparty is trustwhorty and reliable to not go on-chain with a loaded commitment
12:59 < rusty> Happy to give 5 to DNS, ws is experimental and can break in lots of fun ways anyway.
12:59 < cdecker[m]> roasbeef: yep, you guys don't need to be concerned about WS, since that'll never leave our node
12:59 < rusty> cdecker[m]: um, no, we definitely advertize it.
12:59 < cdecker[m]> Hehe, viva el experimento :-)
12:59 < roasbeef> cool, we'll prob have it in our next major release
13:00 < mschmoock> also t-bast did a little compat test on #917 with acinq and clightning 
13:00 < rusty> cdecker[m]: I can change to type 6 before release, with the downside that we'll never parse it...
13:00 < niftynei__> wait what's the reason for not putting WS at #6?
13:00 < BlueMatt> can someone flip a coin already
13:00 < roasbeef> niftynei__: something something deployment order? 
13:00 < mschmoock> niftynei__: that our code already has it expermental on type 5
13:00 < cdecker[m]> Oh? But it doesn't have an IP address, and shouldn't it then rather be a modifier of an existing address type (you can reach me here, but speak websockeranto to me)
13:00 < t-bast> yep #917 is very simple to implement and I'm curious to see how it behaves in the wild, not acting on it yet though
13:01 < mschmoock> t-bast: what do we do if a node announces a private addres? 
13:01 < rusty> niftynei__: c-lightning used 5.  But we can switch...
13:01 < niftynei__> mschmoock, but we're clearly going with DNS for #5 yeh?
13:01 < mschmoock> (like my dump impl did?)
13:01 < roasbeef> 5 (dns), ws (6), ws-CL (250)
13:01 < t-bast> mschmoock: for now I'm just dropping it
13:01 < niftynei__> so WS can haz #6 then
13:01 < rusty> Yep, patch incoming...
13:01 < mschmoock> kk
13:02 < cdecker[m]> Uff, terribly sorry for the confusion
13:02 < mschmoock> t-bast: maybe we should add a note on #917 that it "MUST ignore" private addresses ?!?
13:02 < mschmoock> ir *SHOULD
13:02 < niftynei__> (unrelated to anything but this PR number made this song start playing in me head https://www.youtube.com/watch?v=YkyhvCdJ_vM)
13:03 < t-bast> mschmoock: "IP addresses within private networks (RFC-1918) MUST not be used" -> isn't that already it? Or do you mean we should have a similar one in the receiver requirements? If so yes, it doesn't hurt
13:03 < mschmoock> yep
13:03 < mschmoock> because it might rebroadcast crap otherwise
13:04 < t-bast> mschmoock: but to be honest I dont think it's necessary, implementations shouldn't be dumb enough to take external inputs without validating them
13:04 < mschmoock> also we can add that later if it ever gets a problem (never)
13:04 < rusty> websocket spec updated to 6.
13:04 < mschmoock> thx
13:05 < t-bast> alright folks, we've hit the 1h timer, I gotta go soon
13:05 < crypt-iq> do impl's validate node_announcement to ensure they aren't local addresses
13:06 < mschmoock> crypt-iq: they should
13:06 -!- crypt-iq35 [~crypt-iq@2603-6080-8f06-6d01-f42a-3dfe-0bb5-a3b7.res6.spectrum.com] has joined #lightning-dev
13:06 < BlueMatt> crypt-iq: no. if you send us crap, you may still want other addresses out there or whatever, and presumably you're sending it to others too, so not our problem?
13:06 < t-bast> Thanks rusty for green-lighting https://github.com/lightningnetwork/lightning-rfc/issues/925; do you want to keep the lightning-rfc name of shall we rename to lightning/bolts?
13:06 < BlueMatt> and, like, it isn't really a big deal if you tell the world your internal address. not idea, but not a big deal
13:06 < rusty> t-bast: oh, bolts FTW!
13:07 < t-bast> roasbeef if you can give us rights on the org, it would be great
13:07 < niftynei__> +1 for /bolts
13:07 < mschmoock> nice
13:07 < rusty> BlueMatt: there are weird probing things in theory... better to discard.
13:07 < t-bast> nice, looks like lightning/bolts gets traction, roasbeef we're all good to go to transfer the repo then rename it then ;)
13:07 < BlueMatt> rusty: sure, but if you also have "real" addresses there, you'd probably prefer they get out there.
13:07 < BlueMatt> rusty: and, sadly, its signed, so we cannot discard parts
13:08 < rusty> BlueMatt: sure, but we can ignore parts, which would be best practice.
13:08 < niftynei__> is this `remote_addr` just an IP discovery service?
13:08 < mschmoock> niftynei__: yep, but decentralized :D
13:08 < niftynei__> peer tells me my IP addy cuz i don't know it
13:08 < BlueMatt> oh, sure, yes, *definitly* dont *connect* to a local ip in an announcement :)
13:08 < niftynei__> i'm dmb, what's this useful for?
13:09 < BlueMatt> niftynei__: yes, what you just said
13:09 < mschmoock> NATs etc
13:09 < gene> yeah, NAT traversal/hole-punch
13:09 < mschmoock> you just need to open the 9735 port
13:09 < mschmoock> discovery then works out of the box
13:09 < niftynei__> am i, the node getting my `remote_addr` back, going to update my address list based on this?
13:09 < niftynei__> like is this actionable??
13:09 < mschmoock> niftynei__: yes, the node can do some checks
13:10 < mschmoock> but basically if its sure enough the address is usable then announce it
13:10 < rusty> niftynei: it's better than many of the alternatives, it turns out...
13:10 < t-bast> niftynei: that's the big question, if enough of your peers send you back the same ip address and it's not the one you advertized, maybe your ISP changed your IP and you should advertize this new one
13:10 < niftynei__> so i start up, connect to some peers, make sure the majority of them agree about what my IP addr is and set that as my connection deets?
13:10 -!- crypt-iq [~crypt-iq@2603-6080-8f06-6d01-f42a-3dfe-0bb5-a3b7.res6.spectrum.com] has quit [Ping timeout: 256 seconds]
13:10 < BlueMatt> niftynei__: recall you have a pubkey and can provide multiple ips :)
13:10 < t-bast> niftynei: it should at least send the node operator a notification and let them act on it - or automatically decide to use it
13:11 < rusty> niftynei: we would do it by default only in the case where we don't otherwise advertize *any* addresses.  So it's better than nothing...
13:11 < niftynei__> sort of a nit but this PR's commit message would be easier to figure out if it had the word "discovery" in it somewhere
13:12 < mschmoock> kk
13:12 < niftynei__> BlueMatt: ack, seems like it's not useful for a node that knows it's multi IPs then?? or do you just add all reported IPs to your list lol
13:12 < BlueMatt> niftynei__: not a lot of reason to not report 2/3 ips?
13:12 < BlueMatt> niftynei__: i mean it costs something to the network, so dont send 10
13:12 < niftynei__> i mean if you've got a pubkey others can verify, you could jsut append anything anyone tells you back yolo
13:12 < niftynei__> ahh facts
13:12 < BlueMatt> but, like, if you're not sure, and you think maybe some ip is workable, just tell people it?
13:13 < niftynei__> is this to get people away from TOR?
13:13 < t-bast> #endmeeting
13:13 < lndev-bot> Meeting ended Mon Oct 25 20:13:15 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:13 < lndev-bot> Minutes:        https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-10-25-19.04.html
13:13 < lndev-bot> Minutes (text): https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-10-25-19.04.txt
13:13 < lndev-bot> Log:            https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-10-25-19.04.log.html
13:13 < niftynei__> i'm sorry i'm like, these are very tangential questions about this
13:13 < t-bast> Sorry guys, gotta go, but keep it going!
13:13 < niftynei__> thanks t-bast! 
13:13 < mschmoock> niftynei__: among others yes
13:13 < mschmoock> thank everyone
13:13 < mschmoock> *S
13:13 < t-bast> Thanks for your time, please review PRs and shill glozow's package relay ;)
13:13 -!- lucasdcf [~lucasdcf@2804:431:c7d9:3516:eba7:9f6b:1793:ef09] has quit [Quit: Client closed]
13:14 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving]
13:14 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:20f0:70e4:ff16:cb0] has quit [Quit: Client closed]
13:14 -!- crypt-iq35 [~crypt-iq@2603-6080-8f06-6d01-f42a-3dfe-0bb5-a3b7.res6.spectrum.com] has quit [Quit: Client closed]
13:14 < niftynei__> this IP discovery service is A+ imo
13:15 < mschmoock> thx :D
13:15 < mschmoock> already implemented it (partly) on https://github.com/ElementsProject/lightning/pull/4864
13:15 < niftynei__> like, definitely some really cool ways to use the lightning node network to bootstrap home server infra
13:16 < niftynei__> let's make the web more decentralizeddd
13:16 < mschmoock> dddddd...
13:16 < niftynei__> ok i definitely had coffee today
13:16 < mschmoock> :]
13:16 < mschmoock> also
13:16 < mschmoock> You can use that without using lightning itself
13:16 < mschmoock> i mean without channels :D
13:16 < niftynei__> well you need a pubkey 
13:16 < mschmoock> yes
13:16 < mschmoock> but thats that
13:17 < niftynei__> "the lightning web" lol
13:17 < mschmoock> So software like 'ddclient' can have an adapter that uses LN and no static web URL to check
13:17 < mschmoock> that would be kinda cool
13:17 < niftynei__> yeh exactly
13:18 < niftynei__> it's a really dope service
13:18 < niftynei__> nice idea mschmoock !
13:19 < mschmoock> :D also this came out of the discussion with t-bast t.b.h.
13:19 < niftynei__> +1 to house ACINQ
13:20 < mschmoock> 'stacking sats and onion networks'  :D
13:20 < mschmoock> just came to my mind
13:20 < niftynei__> haha
13:20 < mschmoock> (about TOR)
13:20 < niftynei__> something something "every application expands until it includes an IP address discovery service"
13:20 < mschmoock> :D
13:21 < niftynei__> ok gonna go put this caffeine to use elsewhere. ttyl mschmoock <3
13:21 < mschmoock> c'ya
13:26 -!- niftynei [~niftynei@2600:1700:d0e:284f:506:b731:f5d3:3ccf] has quit [Remote host closed the connection]
13:26 -!- niftynei [~niftynei@2600:1700:d0e:284f:455e:7e85:6a27:e5cf] has joined #lightning-dev
13:27 < mschmoock> rusty: now theres inconsistencies on https://github.com/lightningnetwork/lightning-rfc/pull/891/files  
13:27 < mschmoock> some other lines tell "MUST NOT create a ... `type 5` address descriptor with `port` equal" or "MUST NOT add a `type 5` address unless there ..."
13:30 < mschmoock> noted that on gh
13:31 < rusty> mschmoock: thanks, fixed...
13:35 < mschmoock> rusty: nice. do you know is that "MUST NOT have port 0" rule in there btw? (I want to understand because the DNS PR can need it as well)
13:36 -!- rusty [~rusty@220-244-196-8.tpgi.com.au] has quit [Ping timeout: 244 seconds]
13:36 < mschmoock> arg
14:03 -!- ghostkeeper [~ghostkeep@47.196.70.51] has quit []
14:18 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
15:03 -!- Aaronv___ [~AaronvanW@71pc74.sshunet.nl] has joined #lightning-dev
15:05 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has quit [Ping timeout: 265 seconds]
15:50 -!- niftynei__ [~niftynei@2603-8080-1408-3b48-14ac-5f26-e4d8-6a02.res6.spectrum.com] has quit [Ping timeout: 264 seconds]
16:03 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection]
16:03 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #lightning-dev
16:55 -!- rusty [~rusty@220-244-196-8.tpgi.com.au] has joined #lightning-dev
16:59 -!- Aaronv___ [~AaronvanW@71pc74.sshunet.nl] has quit [Quit: Leaving...]
17:17 -!- waxwing_ [~waxwing@193.29.57.116] has joined #lightning-dev
17:17 -!- waxwing [~waxwing@user/waxwing] has quit [Read error: Connection reset by peer]
17:54 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 265 seconds]
17:57 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
18:00 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 276 seconds]
18:18 -!- rusty [~rusty@220-244-196-8.tpgi.com.au] has quit [Ping timeout: 260 seconds]
19:28 -!- plankster [~plankster@user/plankers] has quit [Ping timeout: 244 seconds]
19:32 -!- plankster [~plankster@user/plankers] has joined #lightning-dev
19:41 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 244 seconds]
19:53 -!- belcher [~belcher@user/belcher] has joined #lightning-dev
20:04 -!- rusty [~rusty@220-244-196-8.tpgi.com.au] has joined #lightning-dev
20:22 -!- plankster_ [~plankster@user/plankers] has joined #lightning-dev
20:23 -!- plankster [~plankster@user/plankers] has quit [Ping timeout: 265 seconds]
21:18 -!- rusty [~rusty@220-244-196-8.tpgi.com.au] has quit [Ping timeout: 260 seconds]
22:22 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
22:37 -!- plankster_ is now known as plank
--- Log closed Tue Oct 26 00:00:14 2021