--- Log opened Mon Sep 27 00:00:19 2021
00:27 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 265 seconds]
00:32 -!- shariashaman [~Rheanna@101.91.192.124] has quit [Remote host closed the connection]
00:38 -!- shariashaman [~Rheanna@101.91.192.124] has joined #lightning-dev
00:59 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:18 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection]
01:18 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #lightning-dev
01:39 -!- shariashaman [~Rheanna@101.91.192.124] has quit [Remote host closed the connection]
01:41 -!- shariashaman [~Rheanna@101.91.232.94] has joined #lightning-dev
02:28 -!- shariashaman [~Rheanna@101.91.232.94] has quit [Remote host closed the connection]
02:31 -!- shariashaman [~Rheanna@101.91.197.175] has joined #lightning-dev
03:17 -!- dunxen [~dunxen@gateway/tor-sasl/dunxen] has joined #lightning-dev
03:18 -!- shariashaman [~Rheanna@101.91.197.175] has quit [Remote host closed the connection]
03:20 -!- shariashaman [~Rheanna@101.91.238.197] has joined #lightning-dev
04:09 -!- shariashaman [~Rheanna@101.91.238.197] has quit [Remote host closed the connection]
04:10 -!- shariashaman [~Rheanna@101.89.197.243] has joined #lightning-dev
04:11 -!- bairen [~bairen@gateway/tor-sasl/bairen] has quit [Remote host closed the connection]
04:11 -!- bairen [~bairen@gateway/tor-sasl/bairen] has joined #lightning-dev
04:20 -!- plank [~plankster@user/plankers] has quit [Ping timeout: 260 seconds]
04:22 -!- plankster [~plankster@user/plankers] has joined #lightning-dev
04:25 -!- shariashaman [~Rheanna@101.89.197.243] has quit [Remote host closed the connection]
04:26 -!- shariashaman [~Rheanna@101.89.197.243] has joined #lightning-dev
05:06 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
05:10 < lnd-bot> [lightning-rfc] m-schmoock opened pull request #917: BOLT 1: adds remote address to optional init_tlvs (master...bolt1-remote-address) https://github.com/lightningnetwork/lightning-rfc/pull/917
05:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
05:54 -!- smartin [~Icedove@88.135.18.171] has joined #lightning-dev
06:47 -!- shariashaman [~Rheanna@101.89.197.243] has quit [Remote host closed the connection]
06:48 -!- shariashaman [~Rheanna@218.78.88.163] has joined #lightning-dev
07:08 -!- _niftynei [~niftynei@2600:1700:d0e:284f:afe0:6898:22e4:1a36] has quit [Remote host closed the connection]
07:09 -!- _niftynei [~niftynei@2600:1700:d0e:284f:5481:2bed:8a23:c83] has joined #lightning-dev
07:24 -!- Kiowa [~Jason@047-028-195-151.res.spectrum.com] has quit [Quit: WeeChat 2.3]
07:24 -!- shariashaman [~Rheanna@218.78.88.163] has quit [Remote host closed the connection]
07:28 -!- shariashaman [~Rheanna@218.78.88.163] has joined #lightning-dev
07:28 -!- shariashaman [~Rheanna@218.78.88.163] has quit [Remote host closed the connection]
07:28 -!- Kiowa [~Jason@047-028-195-151.res.spectrum.com] has joined #lightning-dev
07:29 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
08:09 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
08:09 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
08:10 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
08:11 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
08:11 -!- sr_gi [~sr_gi@static-43-117-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
08:12 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
08:12 -!- sr_gi [~sr_gi@static-43-117-230-77.ipcom.comunitel.net] has joined #lightning-dev
08:18 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
08:18 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
08:20 -!- shariashaman [~Rheanna@101.91.180.110] has joined #lightning-dev
08:21 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
09:07 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
09:08 -!- shariashaman [~Rheanna@101.91.180.110] has quit [Remote host closed the connection]
09:10 -!- shariashaman [~Rheanna@218.78.77.129] has joined #lightning-dev
09:25 -!- gene [~gene@gateway/tor-sasl/gene] has joined #lightning-dev
09:40 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
10:05 -!- smartin [~Icedove@88.135.18.171] has quit [Quit: smartin]
10:09 -!- whysthatso [~whysthats@74-206-50-195.sta.estpak.ee] has joined #lightning-dev
10:24 -!- gene [~gene@gateway/tor-sasl/gene] has joined #lightning-dev
10:27 -!- joostjgr [~joostjgr@2a02-a450-1546-1-e924-f805-d3ef-3908.fixed6.kpn.net] has joined #lightning-dev
10:49 -!- shariashaman [~Rheanna@218.78.77.129] has quit [Remote host closed the connection]
10:50 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
10:56 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 276 seconds]
10:57 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
10:59 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
11:02 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
11:11 -!- jarthur [~jarthur@2603-8080-1540-002d-544b-b972-a6f4-ec7d.res6.spectrum.com] has joined #lightning-dev
11:32 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
11:39 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
11:40 -!- shariashaman [~Rheanna@218.78.88.163] has joined #lightning-dev
12:10 -!- AaronvanW [~AaronvanW@190.242.161.186] has joined #lightning-dev
12:24 -!- lucasdcf [~lucasdcf@2804:431:c7d9:7008:5c4c:7486:2906:4c63] has joined #lightning-dev
12:24 -!- lucasdcf [~lucasdcf@2804:431:c7d9:7008:5c4c:7486:2906:4c63] has quit [Client Quit]
12:24 -!- lucasdcf [~lucasdcf@2804:431:c7d9:7008:5c4c:7486:2906:4c63] has joined #lightning-dev
12:29 -!- shariashaman [~Rheanna@218.78.88.163] has quit [Remote host closed the connection]
12:30 -!- shariashaman [~Rheanna@101.91.240.201] has joined #lightning-dev
12:52 -!- dunxen [~dunxen@gateway/tor-sasl/dunxen] has quit [Remote host closed the connection]
12:55 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev
12:58 < t-bast> Good morning folks!
12:58 < BlueMatt> hi all
12:59 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has joined #lightning-dev
12:59 < BlueMatt> rusty: wen2rebase warning messages
12:59 < mschmoock> hi BlueMatt 
13:00 < t-bast> That's an aggressive "Good morning Rusty" you did there BlueMatt
13:00 < BlueMatt> lol
13:00 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:2c97:caca:b647:d55b] has joined #lightning-dev
13:00 < BlueMatt> I'd mail some coffee as pennance, but I don't think rusty would appreciate my american coffee
13:01 < cdecker[m]> Hey all 
13:01 < ariard> hi
13:01 < ryanthegentry> hi
13:02 < t-bast> I put up an agenda over here: https://github.com/lightningnetwork/lightning-rfc/issues/916
13:02 < t-bast> Joost made some good point about choosing PR priorities
13:03 < t-bast> My TL;DR is that we should prioritize things that people are interested in; a good way to ensure that would be to let rotating chairs pick the order in which they want to review things (or pick things outside of the proposed agenda)
13:03 < t-bast> With chair rotating often enough, everyone should have opportunities to get the things they're interested in reviewed
13:03 < t-bast> At least that's my hope
13:04 < cdecker[m]> Agreed, pure mechanical priorities may not get us to the interesting things
13:04 < t-bast> Didn't work that well for trampoline though xD
13:04 < ariard> Yeah SGTM to have rotating chairs
13:04 < BlueMatt> one thing I think we should all consider doing more is trading implementation - I want something, so I offer to implement (and thus get past the "two implementations are compatible" point) something you want in exchange for implementing what I want
13:04 < BlueMatt> just a general note
13:04 < _niftynei> hello hello
13:05 < t-bast> Hey _niftynei
13:05 < t-bast> BlueMatt: agreed, that's a good way to ensure quick(er) progress
13:06 < t-bast> BlueMatt: I'll trade you "compression algorithm advertisement" for trampoline
13:06 < BlueMatt> t-bast: lol, one of those seems much easier.......
13:06 < ariard> ahah that deal!!
13:06 < BlueMatt> anyway, meeting start time?
13:06 < t-bast> right, trampoline is indeed simpler than it looks :)
13:06 < ariard> you can propose multiple ones :D
13:07 < t-bast> let's start, who chairs tonight?
13:07 < ariard> i'm good to do it
13:07 < t-bast> ACK
13:07 < cdecker[m]> I'm on mobile today so likely not the quickest typer in town 😀
13:07 < ariard> #startmeeting LN marketing committee
13:07 < lndev-bot> Meeting started Mon Sep 27 20:07:38 2021 UTC and is due to finish in 60 minutes.  The chair is ariard. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:07 < lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:07 < lndev-bot> The meeting name has been set to 'ln_marketing_committee'
13:07 < t-bast> Please diverge from the item order in the issue!
13:08 < ariard> Let starts by #910
13:08 < ariard> https://github.com/lightningnetwork/lightning-rfc/pull/910
13:08 < mschmoock> use #topic  command ;)
13:08 < ariard> Pending on Rusty addressing comments or any other feedback ?
13:08 < t-bast> I think we still have pending action items from the last meeting on that one
13:08 < ariard> #topic #910
13:09 < ariard> mschmoock: danke schon
13:09 < mschmoock> oehm, gerne... if it would accept that command
13:09 < t-bast> We decided to add a feature bit, and to clarify the commitment_number, but that's still pending
13:09 < ariard> Okay so no discussion to hold, pending on Rusty?
13:09 < rusty> Sorry, I'm lagging.  (I tried to rebase warnings., but it' not the completely trivial task I'd hoped).
13:10 < BlueMatt> yea, I dunno how much discussion is needed on 910, we need implementation(s) of it. I have one 1/4 done, but needs more.
13:10 < ariard> let moves forward
13:10 < t-bast> We should have an implementation of 910 quickly as well in eclair
13:10 < ariard> #topic dynamic DNS support in gossip messages #911 or #917
13:11 -!- lndev-bot` [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
13:11 < ariard> mschmoock: iiuc it's either #911 or #917 ?
13:11 < BlueMatt> I'm game for either. networking is hard, lots of issues with any option.
13:12 < mschmoock> well, lot of back and forth. I think 917 is better
13:12 < BlueMatt> honestly could do both, but at least 917 is probably a better first-pass imo if only because it means less setup on the admin end
13:12 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 265 seconds]
13:12 < t-bast> I'd slightly prefer avoiding using DNS explicitly, so #917 for me, but I don't have a strong NACK on #911 though
13:12 < BlueMatt> t-bast: had said concept ack on 917 and said he was gonna start coding :)
13:12 < mschmoock> is there any usage of #917 when using IPv6 addresses ? Is there something like IPv6 NAT??
13:12 < BlueMatt> mschmoock: yes, there is address mapping in v6
13:13 < BlueMatt> so i think it may be useful for v6 as well
13:13 < mschmoock> good
13:13 < BlueMatt> its probably also useful for tor
13:13 < BlueMatt> though somewhat less so
13:13 < t-bast> Can you detail why it's useful for tor?
13:14 < t-bast> To check the bridges used (bridge isn't the right term, is it)?
13:14 < BlueMatt> just means a node can auto-discover its addresses with zero configuration. eg if you configure tor but forget to configure your ln node, and then tell someone to connect to you on tor, *boom* your ln node is now configured
13:14 < BlueMatt> which seems nifty, but, indeed, isnt exactly a headline features
13:14 < t-bast> Oh ok, so you'd really put the onion address in there
13:15 < BlueMatt> yea, just putting "I think I'm connecting to 10.X" isnt exactly useful :)
13:15 < cdecker[m]> Or Tor will return 127.0.0.1 always :-)
13:16 < BlueMatt> right or that
13:16 < mschmoock> Okay, when we discover some new address supposedly of our node, whats the best strategy to use that? BlueMatt mentioned just to broadcast 'all' (maybe upt to a limit)
13:16 < cdecker[m]> So needs to filter local addrs
13:16 < BlueMatt> yea, i dunno, doesn't need to be in the spec imo.
13:16 < BlueMatt> just "dont include local addresses" could be mentioned
13:16 < BlueMatt> but nodes can figure out for themselves how they want to use the addresses provided, including them all is cool, trying to filter is cool too.
13:16 < roasbeef> ye re #910, I think we just need more impls, we're working on one in the background, but also considering how the pubkey based routing proposal would also serve to simplify certain aspects of it 
13:17 < roasbeef> made a comment on #917 that it doesn't really seem to be an alternative to #911: https://github.com/lightningnetwork/lightning-rfc/pull/917#issuecomment-928235635
13:18 < mschmoock> BlueMatt: by "dont iclude local addresses"  you mean more than the note about pricate addresses I already added?
13:18 < BlueMatt> mschmoock: yes, but I hadnt realized you'd done that already :)
13:18 < mschmoock> k
13:18 < t-bast> roasbeef: true, both could potentially be used for different purposes
13:18 -!- shariashaman [~Rheanna@101.91.240.201] has quit [Remote host closed the connection]
13:19 < roasbeef> t-bast: yeh the DNS thing seems really useful for ppl managing automated fleets of nodes 
13:19 < rusty> 911/917: Hmm, you'd need to open a port either way.  But I agree it's not really an alternative; people *do* run dyndns, and that works, using your peers to get your current address; it's probably harmless to do, but it's a bit weird.
13:19 < mschmoock> I have 911 half implemented. 917 is easy
13:19 < roasbeef> rn we have a setting where lnd will hit a DNS record and then advertise the new IP addr as a workaround, since we don't support DNS names within the node_ann 
13:19 < roasbeef> since when we spin up a new node, we may not yet know what the reachable IP of it is gonna be 
13:19 < cdecker[m]> We should mkae sure this doesnt end up with all NATed and unconnectable node anns
13:20 < BlueMatt> rusty: fwiw, bitcoin core uses "what my peer told me my ip address is" for advertisements to some extent and it works reasonably. of course its different in core cause you don't care if its "my" ip vs "a node's ip" but still
13:20 -!- shariashaman [~Rheanna@101.91.232.94] has joined #lightning-dev
13:20 < BlueMatt> cdecker[m]: presumably ignoring local addresses suffices?
13:21 < roasbeef> cdecker[m]: things are kiiiinda like that rn w/ how many nodes are tor only these days 
13:21 < cdecker[m]> No if you tell me I'm seeing you as x.y.z and then you use that in your ann it still means you're unrachable
13:21 < rusty> We already have a local addr filter for our auto-announce stuff, so this is pretty easy.  Oh, BTW we're moving to 15-45 second pings for all connections in next release, because ppl were complaining about Tor circuits breaking and them only finding out when trying to send an HTLC...
13:22 < BlueMatt> we tried to move to 5 second pings, now all my lnd peers drop off regularly
13:22 < BlueMatt> but c-lightning peers seem totally fine
13:22 < BlueMatt> but I think we'll stick with 5 second pings, tbh
13:22 < rusty> BlueMatt spec says once per minute, IIRC.
13:22 < mschmoock> theres some spam limit on pings...
13:22 < BlueMatt> i know it does, but we had the same problem as you, and even worse on mobile cause of ios limits....
13:22 < rusty>   - SHOULD NOT send `ping` messages more often than once every 30 seconds.
13:23 < BlueMatt> maybe we should drop that, that's not really practical on mobile, especially ios
13:23 < mschmoock> (and should not send another ping when the pong has not been received)
13:23 < BlueMatt> I'll follow up, I had forgotten that was there, thanks
13:23 < rusty> BlueMatt: +1
13:23 < BlueMatt> mschmoock: well that's easy, we just disconnect if the pong wasn't received!
13:23 < mschmoock> sure
13:24 < BlueMatt> anyway, seems we're done with 917?
13:24 < BlueMatt> next topic?
13:24 < mschmoock> just wanted to note repreating a ping may result in spam on the other side when there was TCP jam
13:24 < ariard> oky, so let's end up with both 911 and 917 as it offers more flexibility to node operators?
13:24 < BlueMatt> pending further discussion and implementaiton of course, but, I'm fine with both.
13:25 < mschmoock> we could prioritize 917 as its simpler
13:25 < t-bast> ACK
13:25 < mschmoock> well both are simple
13:25 < ariard> #topic #912 
13:25 < roasbeef> BlueMatt: yeh I saw that issue, we had really low values there, but then raied it a ton, once we started testing from diff locations, throw in tor/mobile, etc, etc 
13:25 < cdecker[m]> ACK, it also takes the longest to bear fruit
13:26 < roasbeef> generally the timeouts prob need to be longer than you anticipate is what we've leanred over the years 
13:26 < ariard> what's the state of ML discussion on 912 ?
13:26 < BlueMatt> roasbeef: I dont think I filed an issue? but, in my case its not a tor or mobile issue, its just lnd ignoring pings, cause its clearnet and actual pings are fine
13:26 < BlueMatt> or lnd being blocked doing other things, i dunno
13:26 < roasbeef> there was some other issue on teh RL repo, where someone found that RL was disconnecting from lnd peers due to some like queueing thing...would need to go find it 
13:27 < roasbeef> we respond to pings right away and don't add them to some processing queue, I think we was something related to like initial graph download and pings at the same time or the idle conn timer, can go find the link later 
13:27 < t-bast> There is more rationale about #912 on the ML, Joost clearly laid out how that can be used to create invoices without storing anything until it's paid
13:27 < BlueMatt> roasbeef: https://github.com/lightningnetwork/lnd/issues/4006 you mean? that's not an RL bug, but we've now got explicit code to handle it just like c-lightning does....it'd be really nice if y'all fixed it to be spec-compliant
13:28 < roasbeef> BlueMatt: no that's not it 
13:28 < BlueMatt> roasbeef: we dont (materially) queue graph messages or pings? unless y'all just dump the whole graph into the send queue? In any case, I do not see this issue with c-lightning
13:28 < BlueMatt> and its rare enough that I dont care much
13:28 < ariard> t-bast: and you pointed it's coming for free with route blinding ?
13:28 < t-bast> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003236.html
13:29 < BlueMatt> anyway, on-topic... by "its free with route blinding" you just mean that you have ~the same feature in route blinding, no?
13:29 < BlueMatt> so its easy to land this pr and then use it in route blinding instead of a new field?
13:29 < t-bast> ariard: yep, in route blinding we already have an encrypted field that is provided by the final recipient that the sender must include in the final payload
13:29 < t-bast> ariard: so that can enable stateless invoices as well
13:30 < t-bast> BlueMatt: it couldn't be used directly in route blinding, it has to be layered inside a different tlv stream, but it's easy to reuse code though
13:30 < BlueMatt> ah, ok
13:30 < t-bast> I was pointing it out, but route blinding isn't a reason to *not* do #912 now
13:31 < t-bast> too many negations in my sentence...
13:31 < t-bast> TL;DR: #912 seems useful on its own :)
13:31 < BlueMatt> ok, cool
13:31 < BlueMatt> agreed
13:31 < BlueMatt> lets do it :)
13:31 < BlueMatt> implementations plz :)
13:31 < roasbeef> 912 is pretty straight forward, lets ppl add new things that the client can interpret, _maybe_ also needs a feature bit w.r.t critical use cases so a user can know: "ok you must put that thing in the metadata in the onion" 
13:32 < ariard> okay and the size bound of the new field is only hop payload?
13:32 < roasbeef> I think the section where it adds the feature bit for the new thing itself is wrong though? just has 9 there, whereas I think it only needs to be inthe invoice (or maybe not at all?) 
13:32 < t-bast> roasbeef: that's what 9 is, isn't it? Feature bit only in invoice?
13:33 < ariard> roasbeef: agree you assume interactivity with the recipient to learn the payload field
13:33 < t-bast> roasbeef: the way I'd use it is that I would set it mandatory in my stateless invoices, since I'll *need* the payer to include it for the payment to succeed
13:34 < cdecker[m]> Colliding featurebits?...
13:34 < ariard> like yes we only need the feature bit in the invoice, nowhere else ?
13:34 < roasbeef> t-bast: ahh duhhh ok ignore me lol 
13:34 < roasbeef> was expected a letter like the rest :p 
13:34 < rusty> Yes, and this carries across trivially to bolt12, it's pretty easy.  We need to assign a number though.
13:35 < rusty> It's probably useless unless it's an even feature, right?  I mean, if it's optional why bother?
13:35 < t-bast> rusty: agreed, I don't see how it could be useful without being mandatory
13:36 < t-bast> We don't have a `9+` option like we have for `C+`/`C-` though
13:36 < ariard> Well sounds we'll introduce one ?
13:36 < rusty> Technically it's not mandatory.  It's just practically mandatory :)
13:36 < roasbeef> t-bast: you'd need another bit to force them to know that you want them to use the stateless derivation tho right? 
13:37 < t-bast> roasbeef: the payer doesn't need to do/know anything
13:37 < cdecker[m]> Sort of supercedes payment_secrets though, so we can save some space again
13:37 < rusty> roasbeef: the presence of the field is enough,th feature bit is just so old wallets reject it properly rather than wondering why it failed.
13:37 < t-bast> roasbeef: they just need to include this tlv in the final payload, all the logic happens at the recipient side
13:37 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
13:37 < lnd-bot> [lightning-rfc] TheBlueMatt opened pull request #918: Drop ping sending rate-limit suggestion (master...2021-09-drop-ping-rl) https://github.com/lightningnetwork/lightning-rfc/pull/918
13:37 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
13:38 < t-bast> cdecker[m]: good point, the way Joost uses it makes the `payment_secret` redundant
13:38 < roasbeef> rusty: t-bast how would they know they _must_ use it like that thuogh? 
13:38 < roasbeef> since ppl can in theory put w/e data they ant in there? 
13:38 < rusty> roasbeef: even feature bit they don't understand
13:38 < t-bast> roasbeef: no, as a payer you don't put anything in there, you just copy what's inside the invoice into the final payload you'll send to the recipient
13:39 < t-bast> roasbeef: the payer doesn't choose what to put in that field, it's like payment_secret, he just pastes what was in the invoice
13:39 < ariard> t-bast: though you will need to encode both `payment_secret` and `payment_metadata` as you don't know if the sender support the latter one ?
13:39 < roasbeef> yeh even bit 
13:39 < ariard> at least for a while
13:40 < rusty> ariard: no, if they specified metadata they know what they're doing.
13:40 < cdecker[m]> Should be optional for the transitory time until senders commonly support it
13:40 < roasbeef> t-bast: yes, but I mean how do they know what to copy into where as the payer
13:40 < roasbeef> understood the receiver is what's populating the field 
13:40 < t-bast> roasbeef: gotcha, then it's because it will be a mandatory feature bit in the invoice
13:40 < rusty> AFAICT this is a generalized payment_secret in fact.
13:40 < cdecker[m]> Otherwise we end up with two QR codes everywhere, one with and one without the data
13:40 < roasbeef> ahh ok so we're saying there's always a _specific_ metadata TLV we're using right? 
13:40 < roasbeef> so it's universal 
13:40 < t-bast> rusty: exactly, it feels like we could have done a variable-size payment_secret...it would have been more future-prof
13:41 < roasbeef> ok totally makes ense now 
13:41 < ariard> rusty: how the recipient who is issuing the invoice can know that the invoice reader understands the new field?
13:41 < roasbeef> sense*
13:41 < rusty> t-bast: yeah, lesson learned.
13:41 < t-bast> rusty: that's on my for putting only 32 bytes there!
13:41 < t-bast> I'll offer Joost a beer to make up for this
13:41 < roasbeef> ariard: they set an even bit, if they can't pay it, hopefully the wallet bubbles it up to them 
13:41 < rusty> ariard: at some point, it has to be forced.  Until then it's unusable.
13:42 -!- positiveblue [~positiveb@d207-102-166-73.bchsia.telus.net] has joined #lightning-dev
13:42 < cdecker[m]> Exactly
13:42 < rusty> Long transition, but "the second best time is today"
13:42 < ariard> rusty: i see, so we deploy-and-wait?
13:42 < rusty> ariard: yeah.  I wish we had a wallet compatibility matrix for these things :(
13:42 < t-bast> Luckily the sender code is really trivial: grab a field from the invoice and put it inside a TLV, so hopefully it ships everywhere soon
13:43 < t-bast> Then in months/years we can enjoy this feature :)
13:43 < rusty> t-bast: and omit the payment secret, right?
13:43 < t-bast> rusty: yep, once the spec PR is updated to say that!
13:43 < cdecker[m]> No that needs to stay until migration completes
13:43 < rusty> #action joost to update spec to point out this replaces the payment secret in the onion.
13:44 < cdecker[m]> It's either secret or data, until data becomes compulsory
13:44 < BlueMatt> given we just made payment secret required, I dunno if it "replaces"?
13:44 < rusty> cdecker[m]: both must appear in BOLT11 invoice, but you MUST only send one in onion.
13:44 < cdecker[m]> Ah, both until data becomes compulsory
13:44 < BlueMatt> more that its a generalized form of
13:44 < roasbeef> payment secret can just stand on its own really, we already require it for all mpp stuff as is 
13:44 < cdecker[m]> Correct, was talking about invoice
13:45 < ariard> okay more on this topic or we can move on?
13:45 < BlueMatt> what roasbeef said, why bother replacing? If you want more data, just add more data, you still probably need at least 32 bytes of random or payment-specific data either way
13:45 < t-bast> #action joost to grab feature bits for this
13:45 < BlueMatt> its kinda awkward, but no reason to fight the backwards compatibility fight over it.
13:46 < rusty> BlueMatt: it's trivial to swap it out, so why do both?  I mean, MPP is unspeced so it can do whatever, but normal payments, seems a waste of space.
13:46 < rusty> (keysend MPP that is)
13:47 < BlueMatt> ah, ok, I misunderstood the context, sorry about that.
13:47 < BlueMatt> lets move on in any case?
13:47 < ariard> #topic #908
13:47 < ariard> https://github.com/lightningnetwork/lightning-rfc/pull/908
13:48 < BlueMatt> we've changed to "implement" this, so ack on our end
13:48 < ariard> Make it mandatory to encode bitcoin amounts compliant with the upper bound of 21M BTC
13:49 < t-bast> Otherwise people will accuse lightning-BTC to inflate the bitcoin supply
13:49 < rusty> Sure, why not.  We changed a few things to use channel capacity where we didn't care, for this reason.   I can add a wire checker to make sure.
13:49 < ariard> okay so good with #908, need for interops testing?
13:50 < rusty> Typo: /21 millions/21 million/ because english is weird.
13:50 < t-bast> We actually have a live interop testing, because eclair has always done that xD
13:50 < mschmoock> Some people use Lighning with different (non-bitcoin) networks. Should we change to working a bit to reflect that?
13:50 < ariard> Yeah it's just not merged on our side
13:50 < BlueMatt> heh, I'm fien taking it, then :)
13:50 < mschmoock> like "the maximum the underlying supports" ?
13:50 < BlueMatt> meh?
13:50 < t-bast> rusty: really, 21 million must stay singular??
13:50 < joostjgr> sorry, only entering the room now. quickly read back the discussion on payment metadata and merging with payment secret. one thing is that the payment secret also protects against probing. if payment metadata is something like 'beer', it isn't very secure. so with a single field, there should probably some guideline on how to populate it (enough randomness)
13:51 < mschmoock> :D
13:51 < BlueMatt> the BOLTs specify bitcoin-lightning, if you want to do something else, you can modify the BOLTs as required :)
13:51 < ariard> like some many things can get wrong if you use lightning on other networks and aren't specificed in the BOLTs
13:51 < cdecker[m]> Likely you'd encrypt the data for yourself joostjgr , wouldn't you?
13:52 < ariard> s/some/so/g
13:52 < rusty> joostjgr: yeah, I was assuming it was a signed blob.  How would it work without somehow encoding the preimage?
13:52 < mschmoock> also, isnt 0x000775f05a074000  (21mio) more than the actual maximum?
13:52 < rusty> mschmoock: yes.  Yes it is.
13:52 < BlueMatt> :shrug: pedantics :p
13:52 < rusty> Because I lost at least 10,000 sats playing with lightning.
13:52 < t-bast> xD
13:53  * BlueMatt shakes fists at OP_RETURN outputs
13:53 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
13:53 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to bitcoin-amount-restrictions: https://github.com/lightningnetwork/lightning-rfc/compare/8ebf0c58aa93...40d5cb4a732a
13:53 < lnd-bot> lightning-rfc/bitcoin-amount-restrictions 40d5cb4 t-bast: fixup! Restrict bitcoin amounts
13:53 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
13:53 < ariard> let's move on ?
13:53 < joostjgr> cdecker,rusty: could encrypt, but in the scheme that i described in the ml post, the preimage is based on a H(receiver_secret | payment_meta). So if the sender would modify the meta, the preimage cannot be reproduced anymore receiver-side
13:54 < BlueMatt> ack merge 908
13:55 < rusty> ack 908
13:55 < ariard> #topic #894
13:55 < BlueMatt> we merged the pr to fully comply with this this morning.
13:55 < t-bast> Nice!
13:55 < t-bast> I have the PR pending on the eclair side, waiting for the spec PR to be accepted
13:55 < BlueMatt> I can put it on a public node if anyone wants to test
13:56 < rusty> joostjgr:  Thanks, I'm behind on ml.  OK, so decide if we want to replace payment secret or not, I guess maybe not?  But slightly more efficient if we do?
13:56 < ariard> yes we're good on our side
13:56 < t-bast> I blasted non-segwit out of existence in the last iteration of this PR, but implementations can of course continue supporting this for as long as they'd like, they just need to ensure they handle the potential edge case where they'd need to force-close
13:56 < rusty> Ack, will implement.
13:57 < cdecker[m]> Well invoice creator gets to choose what to enforce
13:57 < rusty> cdecker[m]: 894?
13:57 < ariard> okay let's move on to next topic
13:57 < cdecker[m]> Was laggin, sorry, ignore me
13:58 < ariard> #topic #884 
13:58 < ariard> blips-or-not-blips-that-is-the-question :)
13:58 < ryanthegentry> seems like 3 outstanding questions: 1) new BOLT for TLV/message type/etc. registry or adjust BOLT 9
13:58 < ryanthegentry> 2) require discussion of "not intended to be universal hence not BOLT" in bLIP
13:59 < ryanthegentry> 3) in lightning-rfc repo or new repo?
13:59 < ryanthegentry> my reading rn is consensus is 1) new BOLT 2) idk, new issue 3) start in lightning-rfc, move if people complain. Does that sound right?
13:59 < t-bast> My personal choice: 1) New BOLT 2) Don't mind 3) Small preferrence for new repo inside lightningnetwork org, but can live with them inside the BOLTs
13:59 < joostjgr> rusty: yes, i guess not replace. metadata is just an optional field without any security requirements
14:00 < BlueMatt> #2 is just "please write a paragraph discussing the tradeoffs in ux between this being common to everyone and not", so I dont really see why its a big deal aside from it being nice to make sure people think hard about such things. I've historically found "make someone write a pharagraph" is a really really effective way to ensure things are considered, whether you read what they wrote or not.
14:00 < roasbeef> i'm cool w/ new BOLT for the registry/tlv stuff for bLIP, no strong feeling there 
14:00 < BlueMatt> #3 - i dont care
14:00 < BlueMatt> and #1 i dont care lol
14:00 < ariard> my preference 1) new BOLT and 3) in a new repo
14:00 < ryanthegentry> any burning passion against 2)? 
14:01 < roasbeef> #2 sure ppl can add w/e they want there, but question is under what conditions is it "rejected"? if they say "I like bLIPs more for this", is that ok? how is that paragraph to be evaluated? 
14:01 < BlueMatt> my understanding of the current doc is that *nothing* in a blip gets "evaluated"
14:01 < roasbeef> #3 same repo imo, just a sub-folder, then a single commit can "upgrade" something to a BOLT, and we keep all the same maintainers and don't need to boostrap a new set 
14:01 < rusty> Yeah, I'm happy if something begins as a BLIP and then everyone implements it and it becomes a must have and we promote it.  What harm?
14:02 < BlueMatt> outside of "yep, you wrote the things the blip doc says you should write and its english/not obvious spam"
14:02 < roasbeef> ok yeh sure 
14:02 < _niftynei> re #3 i think there's a small problem with acceptance criteria for the bolt repo (e.g. implementation and interop testing is well defined for the BOLT repo), a new repo and develop a new 'acceptance criteria' there
14:02 < BlueMatt> rusty: dunno if anyone's disagreeing with that?
14:02 < ryanthegentry> BlueMatt: +1
14:02 < _niftynei> e.g. who's merging blips into the repo?
14:02 < _niftynei> why not keep it as a PR until it's fully baked then, if  it's intended to be a bolt anyway?
14:02 < ariard> on #3, i prefer a separate repo, otherwise I think we're giving the perception that blips have been actually reviwed and interop tested by LN devs
14:03 < _niftynei> like clearly there's some form of 'inclusion' that needs to be formed for the bLIP process that isn't the BOLT process (hence their development)
14:03 < ariard> and if it successful as a process, it's going to be a cognitive overload for contributors involved in BOLT but not desirous to follow on a regular basis the blips
14:04 < BlueMatt> _niftynei: right, well that's why i suggested that bLIPs need to include some text that explains why you aren't targeting univeral deployment.
14:04 < _niftynei> 'bLIP acceptance' is a whole can of worms and it seems nice to cordon that off into its own project immo
14:04 < BlueMatt> its not an "acceptance" criteria
14:04 < BlueMatt> cause, indeed, thats a can of worms
14:05 < BlueMatt> but you're required to write down in enlish why this bLIP is *not* being targeted at "most nodes implement this"
14:05 < _niftynei> are there welll defined criteria for when to merge a bLIP PR?
14:05 < BlueMatt> if you cant do that, probably stop and make it a bolt pr :)
14:05 < BlueMatt> _niftynei: when its gramatically english and not spam :)
14:05 -!- gene [~gene@gateway/tor-sasl/gene] has joined #lightning-dev
14:06 < _niftynei> if there's two distinct tracks for merging, seems like a great reason to keep them in a separate repo imo
14:07 < cdecker[m]> Yeah, I'd prefer a separate repo as well
14:07 < ariard> i agree, and bLIP acceptance might evolve with its own criterias with time and another set of maintainers
14:07 < t-bast> I tend to agree
14:07 < _niftynei> doesnt seem like this is a controversial opinion either re: separate repo or not, anyway didnt mean to divert the discussion
14:07 < rusty> BTW, I prefer all my magic numbers in one place, so I'd prefer the TLV reservations and feature bits in bolt 9.  Even if it's a separate section which indicates draftiness.  We currently use PR titles to reserve them.
14:07 < BlueMatt> ack rusty 
14:07 < rusty> (And there have been mistakes with this process, even, since it's racy).
14:08 < t-bast> the PR title reservation is horrible btw, I preferred when we'd just choose the feature bits when actually merging, and used temporary ones in a high range until it was merged...
14:08 < rusty> Oh, BTW, cdecker[m] noticed someone setting feature bit 32,000-something in a node announce...
14:08 < cdecker[m]> Yeah that was a 4.1kB node announcement :-)
14:08 -!- shariashaman [~Rheanna@101.91.232.94] has quit [Remote host closed the connection]
14:08 < rusty> t-bast: painful transition for experimental features though....
14:09 < t-bast> rusty: why? You simply accept two feature bits for a given feature
14:09 < t-bast> rusty: and can keep advertizing both for a while
14:09 < rusty> t-bast: but now we have the how-do-I-assign-the-first-feature problem...
14:10 < t-bast> rusty: and it's likely that the final version that gets merged may have slightly diverged from the experimental one, which makes it easy to keep them separate and working
14:10 < rusty> ... leading us to reserve them in the initial PR title?
14:10 < _niftynei> i like being able to search the PRs for 'feature bit' to figure out what's been reserved
14:10 < _niftynei> fwiw
14:10 < t-bast> rusty: you don't need to, only when doing cross-compat tests, where someone will need to talk to you anyway to know how to test your impl, so you can tell them "I have a node over there and I use feature bit XXX"
14:11 < roasbeef> _niftynei: when it gets to the end of the process outlined in the "defining" bLIP doc (re when its merged) 
14:11 < rusty> t-bast: except we've had experimental options for over two years, e.g. blinded HTLCs :(
14:11 < roasbeef> +1 for bits or w/e in one place, can coin flip it as far as I'm concerned tho lol 
14:11 -!- shariashaman [~Rheanna@101.89.197.243] has joined #lightning-dev
14:12 < BlueMatt> ack roasbeef 
14:12 < roasbeef> cdecker[m]: heh WTB sparse feature bit encoding :p 
14:12 < BlueMatt> lets do it by just putting a txt file on a random host we all telnet into
14:12 < roasbeef> kek
14:12 < BlueMatt> EDIT_THIS_FOR_FEATURE_RESERVATIONS.txt
14:12 < t-bast> rusty: I've had trampoline for more than that using an experimental feature bit xD, and I'm glad I did because the final version will likely be a bit different and I'll need to support both during the transition
14:13 < roasbeef> totally diff topic but have been thinking about trampoline more lately and how to go about answering some of the open deployment questions in my mind (how the nodes are discveroed/selected, latency+fee impacts, how to propagate back failure info, if nodes will retry _within_ the network themselves or not, etc) 
14:14 < t-bast> rusty: what happens if during the spec review we find that we want to make a breaking change to the proposed onion message for example? You'll have a harder time keeping existing code compatible if you need to keep the same feature bit, don't you?
14:15 < t-bast> roasbeef: neat, I'd love to chat about all this!
14:15 < rusty> t-bast: yes, but feature bits can always be reassigned, worst-case.  In practice it's been less hassle than the system we had before.
14:15 < _niftynei> (worth pointing out we're struggling with acceptance criteria for blip 1 as is... if it was in its own repo we wouldn't have to worry much about what needs to be done to merge it here )
14:15 < roasbeef> t-bast: diff bit maybe? I guess depends on if w/e is out there will continue doing so, or if there was a small window like non-zero fee anchors and we weren't too concerned about it 
14:15 < t-bast> _niftynei: agreed!
14:16 < rusty> The idea was to reduce roadblocks, and it did that somewhat.
14:16 < t-bast> rusty/roasbeef: I'm not necessarily saying we should change back, but wanted to highlight why I'm still uneasy with the PR title reservation
14:17 < t-bast> But sorry for hijacking the bLIP thread, let's resume!
14:18 < roasbeef> are we struggling w/ it? in the diff it describes what "acceptance" is there 
14:18 < _niftynei> in some sense, all feature bits are experimental until implemented/merged; in the current process we're optimistically using low bits for experimental features
14:18 < roasbeef> basically just some min criteria, "doesn't do anything bad, etc" 
14:18 < BlueMatt> I hae to run, sorry folks. roasbeef: as a follow up, if you could dig up the aforementioned indication that maybe ldk peers were not able to stay connected with lnd I'd greatly appreciate it. I'm not aware of any inconsistency today, aside from eg lnd running on RPIs seems to sometimes not want to respond to pings in a timely manner.
14:18 < rusty> Remember kids, features 100+ are for playing with!  1000+ is not to escape onto mainnet please!
14:18 < rusty> roasbeef: "don't be stupid" requirement?  I like it!
14:19 < _niftynei> it's possible that you'd need to change a feature bit later, as opposed to always changing them for the high experimental bit selection etc
14:20 < ariard> yeah I don't have a strong opinion on blips 1) new BOLT or all-in-BOLT9
14:21 < t-bast> If we do bLIPs in a separate repo, the reservation of feature bits / tlv / message types will also happen in the bLIP repo so point 1) would be moot
14:21 < roasbeef> mo repos mo problems 
14:22 < rusty> blib/ subdir.
14:22 < t-bast> I think we'd have more velocity with a separate repo TBH, which is more suited for bLIPs
14:22 < roasbeef> rusty: +1
14:22 < ariard> roasbeef: mo repos can have different maintainers ?
14:22 < rusty> t-bast: naah, we just give ryanthegentry the keys,
14:22 < roasbeef> ariard: yeh  needs to be boostrapped vs going w/ what's already bootstrapped 
14:22 < ryanthegentry> 😈
14:22 < roasbeef> not like we have some issue w/ too many PRs landing quickly in the BOLT repo as is ;) 
14:23 < ariard> roasbeef: with that reasoning BIPs could have be used few years ago :) ?
14:23 < ariard> instead of starting BOLTs
14:24 < roasbeef> nah imo, was still a good idea to do BOLTs first, smaller group of ppl could move quickly amongst ourselves to build out all the critical early stuff not having luke-jr be the arbiter of everything
14:24 < ariard> though I think the blessing perception point still holds, accepting the blips in the same repo that's at least a janitorial work on our side which could be interpreted as a low-ack
14:24 < roasbeef> bolts have also prob changed more than any existing BIP as well 
14:24 < _niftynei> ... why are bLIPs not BIPs again?? :P
14:24 < ariard> roasbeef: but we can apply the same argument, a smaller groups of blips editors will move faster than the whole set of BOLTs devs
14:25 < roasbeef> they're diff processes tho, bLIPs don't have the "2 impls" rule as an example 
14:26 < ariard> so if they have different rules better to have them in separate repos as it's clearer for any observers that they're different things?
14:26 < roasbeef> can just re-use what we have (blip/ subdir as rusty suggested) vs bootstrapping a new repo 
14:26 < roasbeef> they way I see it, bLIPs are under the BOLT umbrella, so subdir makes sense 
14:27 < ariard> i'm nack on that, the way I see it bLIPs are a new process of its own
14:27 < roasbeef> I guess ppl can mirror in some new one if they really wanna, or something something git sub mobule idk 
14:27 < _niftynei> what about a ...git submodule 
14:27 < roasbeef> kek
14:27 < t-bast> _niftynei: thinking outside the box
14:28 < cdecker[m]> The more I think about it the less I like re-using the same repo, separate repo and bootstrap with us as initial reviewers
14:28 < roasbeef> same repo lets us also keep that git history in place, re something moving from bLIP to BOLT in a single commit 
14:28 < roasbeef> cdecker[m]: +1, no need to boostrap a new set of ppl, we haven't had any sort of like bitcoin.org issues w/ teh current set of maintainers (kek)
14:28 < cdecker[m]> ..., I vote for separate repos ... (damn mobile keyboard)
14:29 < ariard> roasbeef: the reverse argument, it would let a new set of ppl emerge ?
14:29 < roasbeef> ok lets go w/ cdecker[m] first statement ;) 
14:29 < rusty> OK hard timeout for me.  Feel free to keep arguing.  But roasbeef is right :)
14:29 < roasbeef> ariard: who would that be? idk I wouldn't underestimte all the extra administrative stuff you'd add in there w/ a new repo 
14:30 < cdecker[m]> Gotta go too, it's been fun ^^
14:30 < roasbeef> it's like trying to make a new PoV chain ;) 
14:30 < roasbeef> PoW chain* 
14:30 < ariard> roasbeef: new folks from the wider LN ecosystem? dunno hard to see them before they show up
14:30 < roasbeef> ariard: yeh they can participate w/ the same repo, they already know the lightning-rfc repo (which isn't called the BOLT repo btw ;) ) 
14:31 < cdecker[m]> roasbeef: wow, that's the overstatement of the year
14:31 < ariard> roasbeef: but they can also participate more easily in a separate repo as you don't have the cognitive overload of browsing thrugh issues
14:31 < roasbeef> gotta go consume calories to keep my meat sack going 
14:31 < roasbeef> ariard: labels, gg
14:31 < harding> It shouldn't count for much, but a vote from me for separate repos (as I mentioned on the ML months ago).
14:32 < ariard> okay let's time out
14:32 < ariard> #endmeeting
14:32 < lndev-bot`> Meeting ended Mon Sep 27 21:32:15 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:32 < lndev-bot`> Minutes:        https://lightningd.github.io/meetings/ln_marketing_committee/2021/ln_marketing_committee.2021-09-27-20.07.html
14:32 < lndev-bot`> Minutes (text): https://lightningd.github.io/meetings/ln_marketing_committee/2021/ln_marketing_committee.2021-09-27-20.07.txt
14:32 < lndev-bot`> Log:            https://lightningd.github.io/meetings/ln_marketing_committee/2021/ln_marketing_committee.2021-09-27-20.07.log.html
14:32 < mschmoock> :D  cu guys
14:33 < t-bast> FWIW I'd still prefer a separate repo too, and I agree with ariard that if we do that, I think it's likely that the maintainer set will slowly evolve and diverge from the BOLT maintainers, and will also help onboard people to the BOLTs in the long run
14:33 < t-bast> But time to go for me as well, thanks for the discussions everyone!
14:33 < roasbeef> BlueMatt: poked eugene, and he dug this PR up (wasn't an issue after all): https://github.com/rust-bitcoin/rust-lightning/pull/1051 
14:33 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has quit [Ping timeout: 252 seconds]
14:33 < ariard> Yeah thanks everyone, see you all!
14:34 < harding> My ML post also mentioned using a monotree approach, if you want to be able to promote a BLIP to a BOLT but still keep the issues/PRs separate: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-July/003116.html
14:35  * harding homer simpson fades back into the bushes.gif
14:35 < BlueMatt> roasbeef: ah, yes, debug builds with no optimization can be *slow*, glad it wasn't an issue, thanks for digging!
14:35 < roasbeef> labels can do a pretty good job of that imo, re t-bast: I guess the diff is starting an entirely new process (effectively forking everything and adding in entirely new ppl) vs jsut nesting it under the existing one, and not have to worry about boostrapping something new from scratch w/ mo repos mo problems, etc 
14:36 < roasbeef> BlueMatt: ahh ok was a debug mode, makes ense 
14:36  * roasbeef naruto runs away from IRC 
14:36 < BlueMatt> roasbeef: yea, no such issue exists on non-debug-mode lol
14:36 < t-bast> harding: xD
14:37 < t-bast> roasbeef: TBH I don't see the bootstrapping cost at all, if we start with the same maintainer set + ryanthegentry, and then let things evolve
14:37 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving]
14:38 -!- joostjgr [~joostjgr@2a02-a450-1546-1-e924-f805-d3ef-3908.fixed6.kpn.net] has quit [Ping timeout: 265 seconds]
14:46 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection]
14:47 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #lightning-dev
15:03 -!- valwal [~valwal@70.107.207.192] has quit [Quit: Ping timeout (120 seconds)]
15:03 -!- whysthatso [~whysthats@74-206-50-195.sta.estpak.ee] has quit [Quit: Ping timeout (120 seconds)]
15:04 -!- whysthatso [~whysthats@74-206-50-195.sta.estpak.ee] has joined #lightning-dev
15:04 -!- dongcarl [~dongcarl@70.107.207.192] has quit [Quit: Ping timeout (120 seconds)]
15:04 -!- valwal [~valwal@70.107.207.192] has joined #lightning-dev
15:04 -!- dongcarl [~dongcarl@70.107.207.192] has joined #lightning-dev
15:04 -!- johnzweng [~johnzweng@zweng.at] has quit [Quit: Leaving...]
15:04 -!- johnzweng [~johnzweng@zweng.at] has joined #lightning-dev
15:05 -!- td001 [~td001@172.245.134.58] has quit [Remote host closed the connection]
15:05 -!- td001 [~td001@172.245.134.58] has joined #lightning-dev
15:26 -!- positiveblue [~positiveb@d207-102-166-73.bchsia.telus.net] has quit [Quit: Leaving...]
15:40 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has joined #lightning-dev
15:49 -!- shariashaman [~Rheanna@101.89.197.243] has quit [Remote host closed the connection]
15:51 -!- shariashaman [~Rheanna@101.91.180.110] has joined #lightning-dev
15:51 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
16:31 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has quit [Ping timeout: 250 seconds]
16:31 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Ping timeout: 246 seconds]
16:31 -!- greypw [~greypw@user/greypw] has quit [Ping timeout: 264 seconds]
16:31 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Ping timeout: 264 seconds]
16:37 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #lightning-dev
16:38 -!- shariashaman [~Rheanna@101.91.180.110] has quit [Remote host closed the connection]
16:41 < luke-jr> roasbeef: I'm not the arbiter of anything much. I think it would be helpful to have someone involved in Lightning as a BIP editor so you guys can move at whatever pace you need tho
16:41 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined #lightning-dev
16:41 -!- shariashaman [~Rheanna@101.89.197.243] has joined #lightning-dev
16:42 < luke-jr> "2 impls rule" is just what determines the Status field, which is merely an indication anyway
16:43 -!- jarthur [~jarthur@2603-8080-1540-002d-544b-b972-a6f4-ec7d.res6.spectrum.com] has quit [Ping timeout: 245 seconds]
16:46 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has joined #lightning-dev
16:46 -!- greypw [~greypw@user/greypw] has joined #lightning-dev
16:57 -!- jarthur [~jarthur@2603-8080-1540-002d-49f9-d8e9-21a2-a096.res6.spectrum.com] has joined #lightning-dev
17:01 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:07 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
17:13 -!- belcher [~belcher@user/belcher] has joined #lightning-dev
17:14 -!- jarthur [~jarthur@2603-8080-1540-002d-49f9-d8e9-21a2-a096.res6.spectrum.com] has quit [Quit: jarthur]
17:28 -!- shariashaman [~Rheanna@101.89.197.243] has quit [Remote host closed the connection]
17:31 -!- shariashaman [~Rheanna@101.91.240.201] has joined #lightning-dev
17:33 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
17:35 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
17:36 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 276 seconds]
17:39 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has joined #lightning-dev
17:57 -!- jarthur [~jarthur@2603-8080-1540-002d-49f9-d8e9-21a2-a096.res6.spectrum.com] has joined #lightning-dev
18:13 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
18:18 -!- shariashaman [~Rheanna@101.91.240.201] has quit [Remote host closed the connection]
18:21 -!- shariashaman [~Rheanna@101.89.154.192] has joined #lightning-dev
18:37 -!- jarthur [~jarthur@2603-8080-1540-002d-49f9-d8e9-21a2-a096.res6.spectrum.com] has quit [Quit: jarthur]
18:46 -!- jarthur [~jarthur@2603-8080-1540-002d-49f9-d8e9-21a2-a096.res6.spectrum.com] has joined #lightning-dev
19:08 -!- shariashaman [~Rheanna@101.89.154.192] has quit [Remote host closed the connection]
19:11 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
19:14 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has joined #lightning-dev
19:35 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has quit [Ping timeout: 265 seconds]
19:49 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
19:49 -!- shariashaman [~Rheanna@101.91.193.123] has joined #lightning-dev
19:58 -!- shariashaman [~Rheanna@101.91.193.123] has quit [Remote host closed the connection]
20:00 -!- shariashaman [~Rheanna@218.78.88.163] has joined #lightning-dev
20:19 -!- AaronvanW [~AaronvanW@190.242.161.186] has quit [Quit: Leaving...]
20:48 -!- shariashaman [~Rheanna@218.78.88.163] has quit [Remote host closed the connection]
20:51 -!- shariashaman [~Rheanna@101.91.180.110] has joined #lightning-dev
21:07 -!- gleb7 [~gleb@178.150.137.228] has quit [Ping timeout: 252 seconds]
21:08 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has joined #lightning-dev
21:39 -!- shariashaman [~Rheanna@101.91.180.110] has quit [Remote host closed the connection]
21:41 -!- shariashaman [~Rheanna@101.91.180.110] has joined #lightning-dev
21:56 -!- rusty2 [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has joined #lightning-dev
21:56 -!- rusty [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has quit [Ping timeout: 245 seconds]
22:12 -!- gleb7 [~gleb@178.150.137.228] has joined #lightning-dev
22:22 -!- rusty2 [~rusty@pa49-178-65-24.pa.nsw.optusnet.com.au] has quit [Ping timeout: 265 seconds]
22:29 -!- shariashaman [~Rheanna@101.91.180.110] has quit [Remote host closed the connection]
22:30 -!- shariashaman [~Rheanna@119.96.171.22] has joined #lightning-dev
22:50 -!- joostjgr [~joostjgr@2a02-a450-1546-1-39db-27c7-756b-215d.fixed6.kpn.net] has joined #lightning-dev
23:18 -!- shariashaman [~Rheanna@119.96.171.22] has quit [Remote host closed the connection]
23:20 -!- shariashaman [~Rheanna@101.91.214.30] has joined #lightning-dev
23:33 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
23:33 < lnd-bot> [lightning-rfc] t-bast merged pull request #908: Restrict bitcoin amounts (master...bitcoin-amount-restrictions) https://github.com/lightningnetwork/lightning-rfc/pull/908
23:33 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
23:33 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
23:33 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/c876dac2b503...e832059827cb
23:33 < lnd-bot> lightning-rfc/master e832059 Bastien Teinturier: Restrict bitcoin amounts (#908)
23:34 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev
23:35 -!- lnd-bot [~lnd-bot@165.227.7.29] has quit [Remote host closed the connection]
23:36 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
23:36 < lnd-bot> [lightning-rfc] t-bast deleted 0 commit to bitcoin-amount-restrictions: https://github.com/lightningnetwork/lightning-rfc/compare/40d5cb4a732a...000000000000
23:36 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
23:36 -!- t-bast [~t-bast@user/t-bast] has quit [Client Quit]
--- Log closed Tue Sep 28 00:00:20 2021