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