20:07:38 <ariard> #startmeeting LN marketing committee 20:07:38 <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. 20:07:38 <lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:07:38 <lndev-bot> The meeting name has been set to 'ln_marketing_committee' 20:07:40 <t-bast> Please diverge from the item order in the issue! 20:11:41 <ariard> mschmoock: iiuc it's either #911 or #917 ? 20:11:42 <BlueMatt> I'm game for either. networking is hard, lots of issues with any option. 20:12:00 <mschmoock> well, lot of back and forth. I think 917 is better 20:12:00 <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 20:12:27 <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 20:12:29 <BlueMatt> t-bast: had said concept ack on 917 and said he was gonna start coding :) 20:12:39 <mschmoock> is there any usage of #917 when using IPv6 addresses ? Is there something like IPv6 NAT?? 20:12:53 <BlueMatt> mschmoock: yes, there is address mapping in v6 20:13:01 <BlueMatt> so i think it may be useful for v6 as well 20:13:06 <mschmoock> good 20:13:07 <BlueMatt> its probably also useful for tor 20:13:23 <BlueMatt> though somewhat less so 20:13:26 <t-bast> Can you detail why it's useful for tor? 20:14:09 <t-bast> To check the bridges used (bridge isn't the right term, is it)? 20:14:13 <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 20:14:25 <BlueMatt> which seems nifty, but, indeed, isnt exactly a headline features 20:14:42 <t-bast> Oh ok, so you'd really put the onion address in there 20:15:11 <BlueMatt> yea, just putting "I think I'm connecting to 10.X" isnt exactly useful :) 20:15:51 <cdecker[m]> Or Tor will return 127.0.0.1 always :-) 20:16:01 <BlueMatt> right or that 20:16:01 <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) 20:16:18 <cdecker[m]> So needs to filter local addrs 20:16:20 <BlueMatt> yea, i dunno, doesn't need to be in the spec imo. 20:16:29 <BlueMatt> just "dont include local addresses" could be mentioned 20:16:48 <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. 20:16:57 <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 20:17:36 <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 20:18:18 <mschmoock> BlueMatt: by "dont iclude local addresses" you mean more than the note about pricate addresses I already added? 20:18:34 <BlueMatt> mschmoock: yes, but I hadnt realized you'd done that already :) 20:18:44 <mschmoock> k 20:18:47 <t-bast> roasbeef: true, both could potentially be used for different purposes 20:19:10 <roasbeef> t-bast: yeh the DNS thing seems really useful for ppl managing automated fleets of nodes 20:19:17 <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. 20:19:28 <mschmoock> I have 911 half implemented. 917 is easy 20:19:30 <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 20:19:44 <roasbeef> since when we spin up a new node, we may not yet know what the reachable IP of it is gonna be 20:19:48 <cdecker[m]> We should mkae sure this doesnt end up with all NATed and unconnectable node anns 20:20:23 <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 20:20:47 <BlueMatt> cdecker[m]: presumably ignoring local addresses suffices? 20:21:03 <roasbeef> cdecker[m]: things are kiiiinda like that rn w/ how many nodes are tor only these days 20:21:29 <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 20:21:50 <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... 20:22:17 <BlueMatt> we tried to move to 5 second pings, now all my lnd peers drop off regularly 20:22:17 <BlueMatt> but c-lightning peers seem totally fine 20:22:31 <BlueMatt> but I think we'll stick with 5 second pings, tbh 20:22:33 <rusty> BlueMatt spec says once per minute, IIRC. 20:22:38 <mschmoock> theres some spam limit on pings... 20:22:47 <BlueMatt> i know it does, but we had the same problem as you, and even worse on mobile cause of ios limits.... 20:22:56 <rusty> - SHOULD NOT send `ping` messages more often than once every 30 seconds. 20:23:13 <BlueMatt> maybe we should drop that, that's not really practical on mobile, especially ios 20:23:22 <mschmoock> (and should not send another ping when the pong has not been received) 20:23:23 <BlueMatt> I'll follow up, I had forgotten that was there, thanks 20:23:32 <rusty> BlueMatt: +1 20:23:35 <BlueMatt> mschmoock: well that's easy, we just disconnect if the pong wasn't received! 20:23:58 <mschmoock> sure 20:24:18 <BlueMatt> anyway, seems we're done with 917? 20:24:20 <BlueMatt> next topic? 20:24:22 <mschmoock> just wanted to note repreating a ping may result in spam on the other side when there was TCP jam 20:24:24 <ariard> oky, so let's end up with both 911 and 917 as it offers more flexibility to node operators? 20:25:00 <BlueMatt> pending further discussion and implementaiton of course, but, I'm fine with both. 20:25:08 <mschmoock> we could prioritize 917 as its simpler 20:25:15 <t-bast> ACK 20:25:17 <mschmoock> well both are simple 20:25:37 <ariard> #topic #912 20:25:48 <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 20:25:56 <cdecker[m]> ACK, it also takes the longest to bear fruit 20:26:01 <roasbeef> generally the timeouts prob need to be longer than you anticipate is what we've leanred over the years 20:26:30 <ariard> what's the state of ML discussion on 912 ? 20:26:32 <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 20:26:44 <BlueMatt> or lnd being blocked doing other things, i dunno 20:26:56 <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 20:27:40 <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 20:27:49 <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 20:27:53 <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 20:28:11 <roasbeef> BlueMatt: no that's not it 20:28:35 <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 20:28:42 <BlueMatt> and its rare enough that I dont care much 20:28:54 <ariard> t-bast: and you pointed it's coming for free with route blinding ? 20:28:56 <t-bast> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003236.html 20:29:13 <BlueMatt> anyway, on-topic... by "its free with route blinding" you just mean that you have ~the same feature in route blinding, no? 20:29:22 <BlueMatt> so its easy to land this pr and then use it in route blinding instead of a new field? 20:29:26 <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 20:29:40 <t-bast> ariard: so that can enable stateless invoices as well 20:30:20 <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 20:30:40 <BlueMatt> ah, ok 20:30:51 <t-bast> I was pointing it out, but route blinding isn't a reason to *not* do #912 now 20:31:10 <t-bast> too many negations in my sentence... 20:31:24 <t-bast> TL;DR: #912 seems useful on its own :) 20:31:39 <BlueMatt> ok, cool 20:31:40 <BlueMatt> agreed 20:31:41 <BlueMatt> lets do it :) 20:31:44 <BlueMatt> implementations plz :) 20:31:55 <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" 20:32:18 <ariard> okay and the size bound of the new field is only hop payload? 20:32:38 <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?) 20:32:59 <t-bast> roasbeef: that's what 9 is, isn't it? Feature bit only in invoice? 20:33:15 <ariard> roasbeef: agree you assume interactivity with the recipient to learn the payload field 20:33:59 <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 20:34:00 <cdecker[m]> Colliding featurebits?... 20:34:05 <ariard> like yes we only need the feature bit in the invoice, nowhere else ? 20:34:27 <roasbeef> t-bast: ahh duhhh ok ignore me lol 20:34:32 <roasbeef> was expected a letter like the rest :p 20:34:36 <rusty> Yes, and this carries across trivially to bolt12, it's pretty easy. We need to assign a number though. 20:35:04 <rusty> It's probably useless unless it's an even feature, right? I mean, if it's optional why bother? 20:35:52 <t-bast> rusty: agreed, I don't see how it could be useful without being mandatory 20:36:08 <t-bast> We don't have a `9+` option like we have for `C+`/`C-` though 20:36:25 <ariard> Well sounds we'll introduce one ? 20:36:43 <rusty> Technically it's not mandatory. It's just practically mandatory :) 20:36:45 <roasbeef> t-bast: you'd need another bit to force them to know that you want them to use the stateless derivation tho right? 20:37:05 <t-bast> roasbeef: the payer doesn't need to do/know anything 20:37:20 <cdecker[m]> Sort of supercedes payment_secrets though, so we can save some space again 20:37:21 <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. 20:37:24 <t-bast> roasbeef: they just need to include this tlv in the final payload, all the logic happens at the recipient side 20:37:28 <lnd-bot> [13lightning-rfc] 15TheBlueMatt opened pull request #918: Drop ping sending rate-limit suggestion (06master...062021-09-drop-ping-rl) 02https://github.com/lightningnetwork/lightning-rfc/pull/918 20:38:01 <t-bast> cdecker[m]: good point, the way Joost uses it makes the `payment_secret` redundant 20:38:25 <roasbeef> rusty: t-bast how would they know they _must_ use it like that thuogh? 20:38:31 <roasbeef> since ppl can in theory put w/e data they ant in there? 20:38:31 <rusty> roasbeef: even feature bit they don't understand 20:38:56 <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 20:39:25 <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 20:39:42 <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 ? 20:39:48 <roasbeef> yeh even bit 20:39:51 <ariard> at least for a while 20:40:05 <rusty> ariard: no, if they specified metadata they know what they're doing. 20:40:13 <cdecker[m]> Should be optional for the transitory time until senders commonly support it 20:40:18 <roasbeef> t-bast: yes, but I mean how do they know what to copy into where as the payer 20:40:31 <roasbeef> understood the receiver is what's populating the field 20:40:33 <t-bast> roasbeef: gotcha, then it's because it will be a mandatory feature bit in the invoice 20:40:33 <rusty> AFAICT this is a generalized payment_secret in fact. 20:40:43 <cdecker[m]> Otherwise we end up with two QR codes everywhere, one with and one without the data 20:40:54 <roasbeef> ahh ok so we're saying there's always a _specific_ metadata TLV we're using right? 20:40:57 <roasbeef> so it's universal 20:40:58 <t-bast> rusty: exactly, it feels like we could have done a variable-size payment_secret...it would have been more future-prof 20:41:14 <roasbeef> ok totally makes ense now 20:41:14 <ariard> rusty: how the recipient who is issuing the invoice can know that the invoice reader understands the new field? 20:41:15 <rusty> t-bast: yeah, lesson learned. 20:41:15 <roasbeef> sense* 20:41:20 <t-bast> rusty: that's on my for putting only 32 bytes there! 20:41:30 <t-bast> I'll offer Joost a beer to make up for this 20:41:34 <roasbeef> ariard: they set an even bit, if they can't pay it, hopefully the wallet bubbles it up to them 20:41:51 <rusty> ariard: at some point, it has to be forced. Until then it's unusable. 20:42:03 <cdecker[m]> Exactly 20:42:05 <rusty> Long transition, but "the second best time is today" 20:42:07 <ariard> rusty: i see, so we deploy-and-wait? 20:42:29 <rusty> ariard: yeah. I wish we had a wallet compatibility matrix for these things :( 20:42:53 <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 20:43:07 <t-bast> Then in months/years we can enjoy this feature :) 20:43:15 <rusty> t-bast: and omit the payment secret, right? 20:43:31 <t-bast> rusty: yep, once the spec PR is updated to say that! 20:43:37 <cdecker[m]> No that needs to stay until migration completes 20:43:53 <rusty> #action joost to update spec to point out this replaces the payment secret in the onion. 20:44:01 <cdecker[m]> It's either secret or data, until data becomes compulsory 20:44:20 <BlueMatt> given we just made payment secret required, I dunno if it "replaces"? 20:44:20 <rusty> cdecker[m]: both must appear in BOLT11 invoice, but you MUST only send one in onion. 20:44:20 <cdecker[m]> Ah, both until data becomes compulsory 20:44:21 <BlueMatt> more that its a generalized form of 20:44:31 <roasbeef> payment secret can just stand on its own really, we already require it for all mpp stuff as is 20:44:35 <cdecker[m]> Correct, was talking about invoice 20:45:05 <ariard> okay more on this topic or we can move on? 20:45:07 <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 20:45:15 <t-bast> #action joost to grab feature bits for this 20:45:20 <BlueMatt> its kinda awkward, but no reason to fight the backwards compatibility fight over it. 20:46:29 <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. 20:46:42 <rusty> (keysend MPP that is) 20:47:24 <BlueMatt> ah, ok, I misunderstood the context, sorry about that. 20:47:29 <BlueMatt> lets move on in any case? 20:47:35 <ariard> #topic #908 20:47:44 <ariard> https://github.com/lightningnetwork/lightning-rfc/pull/908 20:48:04 <BlueMatt> we've changed to "implement" this, so ack on our end 20:48:23 <ariard> Make it mandatory to encode bitcoin amounts compliant with the upper bound of 21M BTC 20:49:10 <t-bast> Otherwise people will accuse lightning-BTC to inflate the bitcoin supply 20:49:12 <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. 20:49:59 <ariard> okay so good with #908, need for interops testing? 20:50:04 <rusty> Typo: /21 millions/21 million/ because english is weird. 20:50:18 <t-bast> We actually have a live interop testing, because eclair has always done that xD 20:50:29 <mschmoock> Some people use Lighning with different (non-bitcoin) networks. Should we change to working a bit to reflect that? 20:50:32 <ariard> Yeah it's just not merged on our side 20:50:35 <BlueMatt> heh, I'm fien taking it, then :) 20:50:47 <mschmoock> like "the maximum the underlying supports" ? 20:50:57 <BlueMatt> meh? 20:50:57 <t-bast> rusty: really, 21 million must stay singular?? 20:50:59 <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) 20:51:00 <mschmoock> :D 20:51:12 <BlueMatt> the BOLTs specify bitcoin-lightning, if you want to do something else, you can modify the BOLTs as required :) 20:51:42 <ariard> like some many things can get wrong if you use lightning on other networks and aren't specificed in the BOLTs 20:51:46 <cdecker[m]> Likely you'd encrypt the data for yourself joostjgr , wouldn't you? 20:52:04 <ariard> s/some/so/g 20:52:04 <rusty> joostjgr: yeah, I was assuming it was a signed blob. How would it work without somehow encoding the preimage? 20:52:23 <mschmoock> also, isnt 0x000775f05a074000 (21mio) more than the actual maximum? 20:52:27 <rusty> mschmoock: yes. Yes it is. 20:52:41 <BlueMatt> :shrug: pedantics :p 20:52:41 <rusty> Because I lost at least 10,000 sats playing with lightning. 20:52:56 <t-bast> xD 20:53:07 * BlueMatt shakes fists at OP_RETURN outputs 20:53:26 <lnd-bot> [13lightning-rfc] 15t-bast pushed 1 commit to 06bitcoin-amount-restrictions: 02https://github.com/lightningnetwork/lightning-rfc/compare/8ebf0c58aa93...40d5cb4a732a 20:53:26 <lnd-bot> 13lightning-rfc/06bitcoin-amount-restrictions 1440d5cb4 15t-bast: fixup! Restrict bitcoin amounts 20:53:47 <ariard> let's move on ? 20:53:58 <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 20:54:24 <BlueMatt> ack merge 908 20:55:02 <rusty> ack 908 20:55:06 <ariard> #topic #894 20:55:31 <BlueMatt> we merged the pr to fully comply with this this morning. 20:55:37 <t-bast> Nice! 20:55:51 <t-bast> I have the PR pending on the eclair side, waiting for the spec PR to be accepted 20:55:54 <BlueMatt> I can put it on a public node if anyone wants to test 20:56:02 <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? 20:56:39 <ariard> yes we're good on our side 20:56:47 <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 20:56:54 <rusty> Ack, will implement. 20:57:12 <cdecker[m]> Well invoice creator gets to choose what to enforce 20:57:35 <rusty> cdecker[m]: 894? 20:57:35 <ariard> okay let's move on to next topic 20:57:57 <cdecker[m]> Was laggin, sorry, ignore me 20:58:04 <ariard> #topic #884 20:58:31 <ariard> blips-or-not-blips-that-is-the-question :) 20:58:35 <ryanthegentry> seems like 3 outstanding questions: 1) new BOLT for TLV/message type/etc. registry or adjust BOLT 9 20:58:55 <ryanthegentry> 2) require discussion of "not intended to be universal hence not BOLT" in bLIP 20:59:06 <ryanthegentry> 3) in lightning-rfc repo or new repo? 20:59:48 <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? 20:59:49 <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 20:59:59 <joostjgr> rusty: yes, i guess not replace. metadata is just an optional field without any security requirements 21:00:09 <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. 21:00:14 <roasbeef> i'm cool w/ new BOLT for the registry/tlv stuff for bLIP, no strong feeling there 21:00:15 <BlueMatt> #3 - i dont care 21:00:28 <BlueMatt> and #1 i dont care lol 21:00:38 <ariard> my preference 1) new BOLT and 3) in a new repo 21:00:55 <ryanthegentry> any burning passion against 2)? 21:01:27 <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? 21:01:46 <BlueMatt> my understanding of the current doc is that *nothing* in a blip gets "evaluated" 21:01:50 <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 21:01:57 <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? 21:02:01 <BlueMatt> outside of "yep, you wrote the things the blip doc says you should write and its english/not obvious spam" 21:02:11 <roasbeef> ok yeh sure 21:02:14 <_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 21:02:22 <BlueMatt> rusty: dunno if anyone's disagreeing with that? 21:02:23 <ryanthegentry> BlueMatt: +1 21:02:40 <_niftynei> e.g. who's merging blips into the repo? 21:02:53 <_niftynei> why not keep it as a PR until it's fully baked then, if it's intended to be a bolt anyway? 21:02:57 <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 21:03:35 <_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) 21:03:42 <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 21:04:24 <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. 21:04:44 <_niftynei> 'bLIP acceptance' is a whole can of worms and it seems nice to cordon that off into its own project immo 21:04:53 <BlueMatt> its not an "acceptance" criteria 21:04:57 <BlueMatt> cause, indeed, thats a can of worms 21:05:16 <BlueMatt> but you're required to write down in enlish why this bLIP is *not* being targeted at "most nodes implement this" 21:05:20 <_niftynei> are there welll defined criteria for when to merge a bLIP PR? 21:05:24 <BlueMatt> if you cant do that, probably stop and make it a bolt pr :) 21:05:36 <BlueMatt> _niftynei: when its gramatically english and not spam :) 21:06:30 <_niftynei> if there's two distinct tracks for merging, seems like a great reason to keep them in a separate repo imo 21:07:09 <cdecker[m]> Yeah, I'd prefer a separate repo as well 21:07:10 <ariard> i agree, and bLIP acceptance might evolve with its own criterias with time and another set of maintainers 21:07:10 <t-bast> I tend to agree 21:07:20 <_niftynei> doesnt seem like this is a controversial opinion either re: separate repo or not, anyway didnt mean to divert the discussion 21:07:26 <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. 21:07:36 <BlueMatt> ack rusty 21:07:58 <rusty> (And there have been mistakes with this process, even, since it's racy). 21:08:24 <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... 21:08:27 <rusty> Oh, BTW, cdecker[m] noticed someone setting feature bit 32,000-something in a node announce... 21:08:50 <cdecker[m]> Yeah that was a 4.1kB node announcement :-) 21:08:54 <rusty> t-bast: painful transition for experimental features though.... 21:09:21 <t-bast> rusty: why? You simply accept two feature bits for a given feature 21:09:31 <t-bast> rusty: and can keep advertizing both for a while 21:09:47 <rusty> t-bast: but now we have the how-do-I-assign-the-first-feature problem... 21:10:02 <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 21:10:07 <rusty> ... leading us to reserve them in the initial PR title? 21:10:26 <_niftynei> i like being able to search the PRs for 'feature bit' to figure out what's been reserved 21:10:31 <_niftynei> fwiw 21:10:54 <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" 21:11:21 <roasbeef> _niftynei: when it gets to the end of the process outlined in the "defining" bLIP doc (re when its merged) 21:11:29 <rusty> t-bast: except we've had experimental options for over two years, e.g. blinded HTLCs :( 21:11:47 <roasbeef> +1 for bits or w/e in one place, can coin flip it as far as I'm concerned tho lol 21:12:00 <BlueMatt> ack roasbeef 21:12:29 <roasbeef> cdecker[m]: heh WTB sparse feature bit encoding :p 21:12:29 <BlueMatt> lets do it by just putting a txt file on a random host we all telnet into 21:12:31 <roasbeef> kek 21:12:32 <BlueMatt> EDIT_THIS_FOR_FEATURE_RESERVATIONS.txt 21:12:39 <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 21:13:55 <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) 21:14:40 <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? 21:15:21 <t-bast> roasbeef: neat, I'd love to chat about all this! 21:15:22 <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. 21:15:29 <_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 ) 21:15:31 <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 21:15:51 <t-bast> _niftynei: agreed! 21:16:07 <rusty> The idea was to reduce roadblocks, and it did that somewhat. 21:16:47 <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 21:17:10 <t-bast> But sorry for hijacking the bLIP thread, let's resume! 21:18:03 <roasbeef> are we struggling w/ it? in the diff it describes what "acceptance" is there 21:18:23 <_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 21:18:23 <roasbeef> basically just some min criteria, "doesn't do anything bad, etc" 21:18:30 <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. 21:18:33 <rusty> Remember kids, features 100+ are for playing with! 1000+ is not to escape onto mainnet please! 21:18:59 <rusty> roasbeef: "don't be stupid" requirement? I like it! 21:19:30 <_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 21:20:38 <ariard> yeah I don't have a strong opinion on blips 1) new BOLT or all-in-BOLT9 21:21:16 <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 21:21:31 <roasbeef> mo repos mo problems 21:22:01 <rusty> blib/ subdir. 21:22:03 <t-bast> I think we'd have more velocity with a separate repo TBH, which is more suited for bLIPs 21:22:17 <roasbeef> rusty: +1 21:22:18 <ariard> roasbeef: mo repos can have different maintainers ? 21:22:18 <rusty> t-bast: naah, we just give ryanthegentry the keys, 21:22:32 <roasbeef> ariard: yeh needs to be boostrapped vs going w/ what's already bootstrapped 21:22:41 <ryanthegentry> 😈 21:22:47 <roasbeef> not like we have some issue w/ too many PRs landing quickly in the BOLT repo as is ;) 21:23:20 <ariard> roasbeef: with that reasoning BIPs could have be used few years ago :) ? 21:23:30 <ariard> instead of starting BOLTs 21:24:29 <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 21:24:29 <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 21:24:30 <roasbeef> bolts have also prob changed more than any existing BIP as well 21:24:57 <_niftynei> ... why are bLIPs not BIPs again?? :P 21:24:59 <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 21:25:42 <roasbeef> they're diff processes tho, bLIPs don't have the "2 impls" rule as an example 21:26:28 <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? 21:26:31 <roasbeef> can just re-use what we have (blip/ subdir as rusty suggested) vs bootstrapping a new repo 21:26:49 <roasbeef> they way I see it, bLIPs are under the BOLT umbrella, so subdir makes sense 21:27:14 <ariard> i'm nack on that, the way I see it bLIPs are a new process of its own 21:27:14 <roasbeef> I guess ppl can mirror in some new one if they really wanna, or something something git sub mobule idk 21:27:16 <_niftynei> what about a ...git submodule 21:27:19 <roasbeef> kek 21:27:36 <t-bast> _niftynei: thinking outside the box 21:28:03 <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 21:28:03 <roasbeef> same repo lets us also keep that git history in place, re something moving from bLIP to BOLT in a single commit 21:28:40 <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) 21:28:52 <cdecker[m]> ..., I vote for separate repos ... (damn mobile keyboard) 21:29:09 <ariard> roasbeef: the reverse argument, it would let a new set of ppl emerge ? 21:29:16 <roasbeef> ok lets go w/ cdecker[m] first statement ;) 21:29:40 <rusty> OK hard timeout for me. Feel free to keep arguing. But roasbeef is right :) 21:29:41 <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 21:30:13 <cdecker[m]> Gotta go too, it's been fun ^^ 21:30:14 <roasbeef> it's like trying to make a new PoV chain ;) 21:30:19 <roasbeef> PoW chain* 21:30:24 <ariard> roasbeef: new folks from the wider LN ecosystem? dunno hard to see them before they show up 21:30:52 <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 ;) ) 21:31:02 <cdecker[m]> roasbeef: wow, that's the overstatement of the year 21:31:36 <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 21:31:47 <roasbeef> gotta go consume calories to keep my meat sack going 21:31:53 <roasbeef> ariard: labels, gg 21:31:58 <harding> It shouldn't count for much, but a vote from me for separate repos (as I mentioned on the ML months ago). 21:32:05 <ariard> okay let's time out 21:32:15 <ariard> #endmeeting