19:08:17 <roasbeef> #startmeeting
19:08:17 <lightningbot> Meeting started Mon Nov 25 19:08:17 2019 UTC.  The chair is roasbeef. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:08:17 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:08:58 <roasbeef> went through some PRs late last week that were marked to be merged, but then incurred rebase conflicts
19:09:04 <t-bast> Do we have updates on base AMP? Implementations making progress?
19:09:48 <joostjgr> yes, we are steadily making progress on base amp
19:09:58 <rusty> t-bast: I implemented the send side yesterday, but not much use without receive.  Still, the pieces seem to fit well so far.
19:10:02 <roasbeef> rusty: I think #513 can be closed?
19:10:15 <roasbeef> #topic #643 (base amp)
19:10:29 <roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/643
19:10:31 <t-bast> great to hear
19:10:59 <rusty> roasbeef: ack, closng now...
19:11:32 <t-bast> On my side, pretty happy with the state of the PR right now
19:11:41 <roasbeef> so where do we stand on the spec PR itself? seems most of the major concerns have been addressed now?
19:11:51 <t-bast> Maybe just on the naming of payment_secret?
19:12:03 <t-bast> There's a comment with some alternative proposals
19:12:10 <roasbeef> also iirc now that the paylaods have been set, we can move forward with #658 as well
19:12:28 <roasbeef> t-bast: what happened to payment_addr? ppl don't like "addr"?
19:12:45 <roasbeef> or payment_nonce or w/e
19:12:50 <t-bast> I like payment_nonce
19:12:57 <t-bast> but the `n` is already taken in the encoding...
19:13:03 <cdecker> Yeah, addr has way too much baggage already
19:13:07 <roasbeef> long lived PRs are kinda hard to follow on github :/
19:13:11 <roasbeef> things can get burried easily
19:13:19 <t-bast> yeah that's true
19:13:36 <t-bast> we need to find both a name and the bech32 letter associated with it
19:13:43 <rusty> What about payment_handle?  It
19:14:00 <rusty> t-bast: not really, we can leave s as the bech32 letter.
19:14:26 <t-bast> yeah but isn't it weird to have 's' for 'payment_handle' for example? I'm probably nitpicking too much
19:14:39 <niftynei> i feel like i'm missing something here. what was wrong with secret?
19:14:39 <roasbeef> an 's'??
19:14:52 <rusty> roasbeef: in the bolt11 spec.
19:14:56 <roasbeef> well it's not really secret, ppl post invoices on twitter or w/e all the time
19:14:56 <t-bast> nitfynei: it's not really a secret...
19:15:12 <t-bast> it's more a nonce (in behavior at least)
19:15:16 <t-bast> or a payment_id
19:15:18 <roasbeef> but if main topic is what this suffix shoudl be, sounds like we're pretty far along lol
19:15:24 <t-bast> haha true
19:15:43 <rusty> it's really a secret, since revealing it is a mistake.  BUt it's also a temp fix until The Glory of Schnorr....
19:16:04 <rusty> (Which, BTW, is why baking it into the same field as amount in onion will be seen as a mistake, but...)
19:16:29 <t-bast> honestly no need to spend too much time on that, I'm even happy with payment_secret for now (unless someone really hates it)
19:16:32 <rusty> (We'll be changing so much I don't think this will be a huge issue)
19:16:48 <t-bast> yeah for Schnorr we're ditching everything and starting from scratch right?
19:16:52 <rusty> Technically, changing the name in the spec is a Spelling issue, as long as there's consensus.
19:16:53 <t-bast> that's what I signed up for
19:17:02 <rusty> t-bast: I like your optimism ;)
19:17:13 <t-bast> yeah then let's not argue too much about the naming and go on with next topics? :)
19:17:33 <t-bast> unless there's something else on AMP people have spotted?
19:19:02 <roasbeef> t-bast: i thought we were talking about #643, not #658?
19:19:03 <rusty> Can we merge 666 first, then this can be rebased, and merge once we have interop testing?
19:19:37 <t-bast> oh yeah, sorry I did mean base AMP
19:19:44 <roasbeef> t-bast: for #643, I haven't been following as closely, so dunno if there're comments buried deep in a thread that haven't been processed, conner isn't here right now but he would know better
19:19:57 <roasbeef> yeh #666 has been cleared for a few weeks, just keeps running into merge conflicts
19:20:23 <t-bast> roasbeef: I think that apart from naming, there's no unaddressed comments in the PR that we didn't discuss (643) but let's wait for conner to chime in
19:20:47 <t-bast> ACK on merging 666, it's on our todo list too
19:22:37 <rusty> OK, I'll rebase and merge now.
19:23:32 <roasbeef> cool, ok for #643 then we want interop mostly, picking a payment_* suffix isn't super critical
19:24:00 <roasbeef> lnd has a "single shot" mode implemented, so you use all the new fields but there's no splitting or combination
19:24:01 <t-bast> agreed with roasbeef
19:24:33 <t-bast> I thought you had no splitting but you had the combine (receive) part?
19:24:40 <roasbeef> but it's possible for several lnd nodes to do a sort of "crowd funding" mode
19:25:21 <rusty> (BTW, I've been playing with minisketch for gossip btw, am on my third revision of proposal now, should have something next mtg)
19:25:47 <t-bast> rusty: that's cool stuff! curious to see that
19:25:52 <roasbeef> t-bast: yeh that's in an open PR, but not yet merged yet
19:26:13 <t-bast> roasbeef: ok, should land soon then ;)
19:26:25 <roasbeef> #action more interop tests for #643 requested
19:27:15 <roasbeef> #666 build failed btw rusty
19:27:34 <rusty> One more force push coming then.... one sec
19:27:36 <roasbeef> other PRs with merge conflicts that are ready: #672
19:27:51 <roasbeef> #topic 682 (add networks to init message)
19:28:06 <roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/682
19:29:21 <roasbeef> i think the final thing here was specifying if there's some partial overlap in advertised chains
19:29:59 <t-bast> Does lnd still support Litecoin?
19:30:17 <roasbeef> yep
19:30:20 <rusty> roasbeef: - SHOULD NOT forward gossip messages to peers who sent `networks` in `init`                          	  and did not specify the `chain_hash` of this gossip message.
19:30:38 <rusty> (The fixup commit adds that phrase to the gossip section)
19:30:41 <roasbeef> nice
19:31:28 <rusty> Everyone in favor?  I haven't actually implemented this one, but we can ack now and apply once compat testing is done?
19:31:54 <cdecker> It doesn't say that we have 32 byte hashes :-)
19:32:27 <roasbeef> I think `chain_hash` is specified elsewhere?
19:32:34 <cdecker> But yeah, looks solid and simple enough
19:32:42 <roasbeef> > chain_hash: a 32-byte chain identifier (see BOLT #0)
19:33:11 <t-bast> ACK #682
19:33:27 <t-bast> haven't implemented either, but looks simple
19:34:06 <cdecker> Ah it's in BOLT01, I was looking in 00 as well, but there it just has the prose
19:34:37 <rusty> #666 merged.  Die  Travis, die...
19:35:01 <t-bast> Hell yeah. BTW do we really need to run 3 CI builds with different python versions? :D
19:35:18 <t-bast> do you even think about those penguins in antartica and stuff?
19:35:52 <roasbeef> #info #682 has been updated to specify how to handle gossip messages
19:36:23 <roasbeef> #action general acceptance, needs basic interop tests, as first tlv extension in the init message
19:36:49 <rusty> I've adde an Awaiting Interop label, will use now.
19:37:07 <t-bast> rusty: you can put that one on 643 as well then
19:37:12 <roasbeef> cool
19:37:32 <rusty> t-bast: done
19:37:43 <roasbeef> #topic #684
19:37:48 <roasbeef> i think there's some context for this one I'm missing?
19:38:55 <rusty> roasbeef: yeah, if you're a badly connected node, and you connect to a big node, it might tell you it doesn't want any gossip (using timestmap filter).
19:39:10 <rusty> roasbeef: we saw failure to propagate channel_announcement in that case.
19:40:00 <roasbeef> whose chan_ann will fail to propagate in that case?
19:40:06 <rusty> So two small node can create a channel, but if all their peers are telling them to STFU with timestamp filtering, it never propagates.
19:40:20 <roasbeef> hmm, but won't they still just announce them in either case?
19:40:35 <roasbeef> since we don't have any request/response, or they can just do so optimistically
19:40:37 <rusty> roasbeef: not if they obey the timestamp_filter which is telling them not to.
19:41:06 <rusty> (which, we used to do).  timestamp_filter shouldn't apply to *your own* gossip,you should push that out regardless (which is what we now do)
19:41:11 <roasbeef> fwiw, lnd may start to just not respond to very old timestamp_filter values
19:41:16 <roasbeef> gotcha
19:41:43 <rusty> I think it's worth adding, since nodes are getting more aggressive at filtering, and this may become problematic.
19:41:59 <cdecker> Well it shouldn't even have really old gossip messages since the suggestion is to prune anything older than 2 weeks
19:42:00 <t-bast> that makes sense, I think sstone should have a look at this too
19:42:22 <roasbeef> ok thanks for the context, will take a look at the PR as a whole now
19:42:44 <sstone> yes I think we do send our own updates no matter what the ts filter is but I'll check
19:43:14 <rusty> sstone: you're smarter than me... we had a few users upset that they couldn't find themselves on 1ml :)
19:44:19 <sstone> mmm yes let's say that :) but it's more like we patched timestamp filter on top of other things and did not think about this check
19:44:24 <rusty> #695 should be a little controversial, at least.
19:44:34 <roasbeef> #info proposed to allow nodes to continue to send their own anns so they'll still propagate them to those that don't send a gossip filter
19:44:55 <roasbeef> safe to move on and we continue in the PR for #684?
19:44:57 <rusty> (or send a gossip filter at UINTMAX)
19:45:06 <rusty> roasbeef: ack
19:45:07 <cdecker> sgtm
19:45:16 <t-bast> roasbeef: sgtm
19:45:35 <roasbeef> #action discussion to continue on PR for #684
19:45:40 <roasbeef> #topic 688
19:45:48 <roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/688
19:45:58 <roasbeef> took a pass throuhg the PR in its current form last week
19:46:11 <roasbeef> one thing that jumped out at me, is how cluttered things start to get with feature bit modifications
19:46:18 <roasbeef> the current format doesn't really seem scalable
19:46:29 <BlueMatt> seems like there's still ongoing mailing list discussion that hasnt concluded, sadly
19:46:32 <roasbeef> a better path imo would be to start tagging hard versions, and assume certain bits to be on my default
19:46:35 <roasbeef> by*
19:46:46 <roasbeef> so then we'd ref the legacy behavior in footnotes or an errata section
19:46:58 <rusty> roasbeef: yeah, at some point we declare feature bankrupcy and have a 'modern' bit.
19:47:01 <roasbeef> just to keep the main document more readable with a single run through
19:47:14 <BlueMatt> i mean can also just fork it in a git sense, no?
19:47:26 <BlueMatt> like, "if you want 'legacy mode, see git tag X"
19:47:36 <roasbeef> yeh taht's one way to do it
19:47:49 <joostjgr> i am also in favor of forking. it gets hard indeed to describe everything using those conditionals
19:48:15 <BlueMatt> and forking in a git sense is way easier practically than moving things to errat or so, but I suppose it doesn't matter *that* much
19:48:16 <joostjgr> maybe for this one we can survive, but at some point it will become too difficult
19:48:42 <t-bast> agreed, but then shouldn't we work harder on deciding what v1.1 is and using a git tag for that? And one for v1.0?
19:48:46 <roasbeef> joostjgr: yeh just imagine the future changes such as dlog htlcs w/ the current format
19:49:08 <roasbeef> t-bast: yeh, things have kinda sprawled tho beyond what was loosely stamped as 1.1 after the last big spec meeting
19:49:37 <t-bast> like agree on a "main" release with a list of big features and coordinate to ship all implementations and then move on
19:49:47 <roasbeef> hard part about that is relative priorities of the impls
19:49:48 <rusty> It's nicer if we can actually remove the old stuff on the network at the same time.  I think tlv-onion will probably be a forcing function here.
19:50:04 <t-bast> roasbeef: that's true, but we can probably agree on the common set
19:50:05 <roasbeef> there're a number of things that were stamped as 1.1 that just haven't really been picked up, as subjectively they may not be high priority
19:50:29 <t-bast> we should feel free to re-visit during the spec meeting what the roadmap is for 1.1, right?
19:50:49 <t-bast> and keep that roadmap somewhat up-to-date to be able to tag important milestones and start deprecating things from the spec
19:50:52 <roasbeef> we never really had a "road map" imo, just some bullet points on a wiki fo things we talked about during the meeting
19:51:23 <t-bast> yeah that's enough of a roadmap for me :)
19:51:28 <joostjgr> we are actively implementing the new anchor outputs commitment tx. today got it running end to end for the first time. highest prio for now is to decide on the outstanding q's: anchor size and remote csv delay value
19:51:32 <roasbeef> hehe, but this is more of a metapoint
19:51:52 <rusty> joostjgr: nice work!!
19:52:00 <t-bast> congrats Joost!
19:52:03 <roasbeef> joostjgr: yeh that sounds aout right on remaining elements, I still need to circle back on your comments in response to my latest review
19:52:09 <t-bast> how hard was the implementation?
19:52:13 <joostjgr> johan did most of the impl work
19:52:15 <t-bast> it looks like a lot
19:52:27 <joostjgr> it wasn't hard, it is mostly work
19:52:34 <roasbeef> lnd has been working towards it for a while t-bast, adding components we surmised would be need for this feature
19:52:56 <roasbeef> t-bast: for example we have a cpfp engine already in place, so after close we just hand off that anchor outputs to that
19:52:58 <t-bast> gotcha, good thinking
19:52:59 <joostjgr> we target v1 as an 'emergency' function. so we do sweep the anchors, but always at a low fee rate. the normal fee mechanism remains unchanged
19:53:15 <joostjgr> a user can manually bump if desired
19:53:44 <sstone> doesn't it make utxo management more complex even if you prepared for it ?
19:53:53 <t-bast> but does it work with Bitcoin core today? I thought there were missing bits in the package relay that would only land in 0.20 (or even later)?
19:53:54 <BlueMatt> joostjgr: I presume you're talking about it in the "lnd" sense, not the "spec" sense.
19:53:56 <roasbeef> sstone: how so?
19:54:17 <joostjgr> sstone: you need a utxo to cpfp indeed
19:54:20 <BlueMatt> as in, its definitely not an "emergency function" in the spec, though if you take it as a implementation step cause you dont trust your rbf/cpfp engine, that makes sense
19:54:23 <roasbeef> t-bast: it doesn't depend on packaged relay, commitment just has a smaller fee now which is a floor, target is "to get into mempool", rather than "to get into block"
19:54:29 <sstone> you need to have "spare" utxo to boost fees
19:54:36 <rusty> Yeah, last I tried to implement it I shied away from the UTXO issues...
19:54:58 <roasbeef> BlueMatt: the spec doesn't need to dictate how it's used really, joost is just saying that our impl atm is lazy in that it only bumps if it really needs to or there's an incoming htlc on another link, etc
19:55:17 <t-bast> roasbeef: thanks for the clarification, I need to dive deeper into that
19:55:22 <BlueMatt> t-bast: and, fwiw, there has been active debate on whether or not to remove update_fee entirely and hard-code the feerate, given that the "min fee to get into mempool" has rarely gone above a relatively low level in bitcoin's entire history.
19:55:42 <roasbeef> sstone: mhmm, I commented that we should maybe have a section to specify wallets keep a pool around, atm the code assumes we have one in place already
19:55:45 <BlueMatt> though it seems like the lnd folks are very very strongly opposed to that idea
19:56:13 <rusty> I'd love to drop update_fee, since it's a *complex*.
19:56:16 <roasbeef> heh, I think you're mischaracterizing BlueMatt, rust-lightning hasn't implemented it at all so understandable that y'all want it removed
19:56:16 <BlueMatt> sstone: I mean dont y'all have some cpfp/rbf-additional-fee-available utxos around anyway?
19:56:17 <niftynei> does removing update_fee need to go in at the same time with the anchor outputs change?
19:56:26 <roasbeef> we want it gone eventually, but that's a much larger change
19:56:39 <niftynei> i think removing update_fee is a good goal, and that anchor updates is the mechanism that it's replaced by
19:56:43 <roasbeef> niftynei: removing it needs packaged relay syupport in the p2p network, which doesn't exist atm
19:56:46 <BlueMatt> roasbeef: heh, we kinda have it implemented, but, totally, we specifically avoided implementing it cause its So. Damn. Busted.
19:57:00 <rusty> roasbeef: that's just not true, AFAICT?
19:57:04 <roasbeef> BlueMatt: sure i think that's an important detail though, as deployed implementations have different constraints
19:57:08 <sstone> roasbeef: our onchain wallet is a bit simpler that yours I think (we don't have a "nursery" to handle delays)
19:57:09 <BlueMatt> roasbeef: it absolutely does *not* need package relay, but I do get the argument that it should be a separate feature bit.
19:57:13 <roasbeef> rusty: why not? if the goal is to have zero fees on the commitment?
19:57:14 <sstone> than
19:57:23 <joostjgr> so initially we aren't even changing anything about the commitment fee rate. it is just an emergency exit. ofc eventually with package relay we'd like to add 0 fee to the commit tx and drop update_fee
19:57:27 <roasbeef> i want to do it eventually as well, I just also favor having smaller deployable items to ensure things don't drag on forever
19:57:31 <rusty> roasbeef: naah, the idea was minimal fees, not zero in last proposal.
19:57:41 <BlueMatt> roasbeef: you can never have zero fees, you have to have *some* fees, and some rather trivial fee (say, 10 sat/byte) isnt all that much anyway.
19:57:48 <roasbeef> rusty: ok but in order to _remove_ update_Fee, yuou need to make sure you can actually get into the mempool
19:58:11 <roasbeef> in order to ensure that you either need to be able to update the commitment, or be sure that you can relay the commtimetn along with its anchor to be accepted as a pair
19:58:12 <BlueMatt> but, I think there was agreement on it being a seaparate feature bit, cause y'all wanted it separate.
19:58:13 <rusty> roasbeef: sure, which you do by picking a feerate like 253 sat / ksipa.
19:58:24 <t-bast> naive question: if you remove udpate_fee does it mean that you'll force your wallet to keep as many UTXOs as the number of open channels that you have to handle their potential closing?
19:58:35 <roasbeef> at that point, then you also need to consider what to do about the coop close fee negotaation, which atm uses the commitment fee as a ceiling, it's really an independent change
19:58:40 <rusty> t-bast: naah, you can thread them, but you have to handle reorg.
19:58:45 <cdecker> t-bast: only as many concurrent closes you expect
19:59:09 <roasbeef> rusty: how can you be sure that's enough? relative high water marks for fee rates can rise
19:59:16 <t-bast> in the worst case you expect an attacker to make you close everything if they somehow detect you don't have enough UTXOs to inject your fees
19:59:20 <t-bast> and they may be able to cheat you
19:59:22 <roasbeef> err as in what nodes will accept at a cerain level of mempool sautration
19:59:46 <BlueMatt> roasbeef: that mark has...never gone *that* high, is the point
19:59:54 <BlueMatt> fees have gone to 1k sat/byte or higher
20:00:00 <niftynei> t-bast, i think you'd need one UTXO, with enough funds to cover all of fees for all outstanding anchored outputs
20:00:06 <roasbeef> i don't know what the future holds, we should design things to be robust against future unexpected behavior
20:00:10 <BlueMatt> but the *mempool fee* has never gotten nearly as high.
20:00:27 <BlueMatt> right, I think the point is if we get to that point we can resolve the issue another way (eg package relay)
20:00:29 <roasbeef> t-bast: splicing can also help out with this, or using stuff like Loop to make utxos from channels
20:00:40 <sstone> what about pending HTLCS ? don't you need utxos for them too ? (though I can you can combine them)
20:00:44 <BlueMatt> like, if fees spike to that extend its really not hard to deploy some package-relay-y nodes or bump the mempool size.
20:01:04 <t-bast> niftynei: good to know...but it still feels dangerous because you need your wallet to be aware of your channels and account for all of them (pessimistic case)...sounds like a nightmare to have a good UX on top of that
20:01:06 <BlueMatt> naive/simple package relay suhas already has a patch for
20:01:09 <rusty> sstone: yeah, you can get clever and combine them and also thread change outputs through the others, but it gets complicated really fast.
20:01:15 <BlueMatt> and in this case especially we need only a trivial form of package relay
20:01:22 <roasbeef> p2p deployments like that don't have very reliable time frames as you know BlueMatt, but this is all an off shoot we want to do it eventually, but there aren't even proposals to do it outright, and that shouldn't block us from improving the current state of things
20:01:40 <joostjgr> dropping update_fee eventually, it is hardly a spec change is it? just don't update the fee anymore. from the perspective of taking small incremental steps, just adding the 2 anchors for now sounds best to me
20:01:54 <roasbeef> can we return to the core discussion itmes here? the two joostjgr mentioned above
20:02:00 <rusty> Yeah, we'll end up witha  feature bit "option_constant_fees" and it'll be pretty clean IMHO
20:02:06 <joostjgr> then we also need to worry yet about having those utxos available etc
20:02:19 <BlueMatt> right, it as a separate feature bit seems fine enough. I thought that was the conclusion anyway. I'm just suggesting it happen in a month, not in two years.
20:02:25 <roasbeef> joostjgr: yeh exactly, there's a very light mode, either you use it or you don't, upon opening a channel you acn already set a fee rate
20:03:05 * rusty lost track of what we were supposed to be arguing about?
20:03:13 <BlueMatt> same
20:03:23 <niftynei> mmh this anchor thing is interesting because it pushes the feerate requirement out to the 'total wallet balance' instead of just 'fees in channel'
20:03:25 <t-bast> let's argue about fee management, that always works
20:03:29 <roasbeef> 14:31 < joostjgr> we are actively implementing the new anchor outputs commitment tx. today got it running end to end for the first time. highest prio for now is to decide on the outstanding q's: anchor size and remote csv delay value
20:03:36 <roasbeef> anchor size and csv selection
20:03:41 <t-bast> niftynei: that's exactly how I see it too
20:03:54 <joostjgr> w/r to the anchor size: we are most comfortable with adding a field for it on the open_channel message (just there) and specifying in the spec 'should set it to 283 sats'. so it is almost a constant, but there is a way out in case something unexpected happens without changing the spec
20:03:55 <niftynei> yeah t-bast it was your comment that made me see this
20:04:08 <t-bast> niftynei: it doesn't make it simpler if you look at the whole picture, it just pushes the complexity to the wallet instead of the lightning spec/node
20:04:08 <roasbeef> niftynei: you can borrow some utxos from a homie to close out a channel
20:04:20 <BlueMatt> Does anyone have a reasonable argument why it needs to be non-static
20:04:25 <roasbeef> t-bast: but gives you more control that right now is an illusion
20:04:31 <niftynei> so every channel closure becomes a 'global wallet consideration'
20:04:40 <niftynei> at least wrt to available funds
20:04:41 <BlueMatt> like, I think we all agree it likely will never *raise*, so unless someone thinks 200 sat is, like, a lot of money, or will be in the near future.....
20:05:17 <BlueMatt> (or am I missing something and someone actually *does* think it needs to be more than 200-whatever sat?)
20:05:22 <roasbeef> BlueMatt: why lock your channel into a configuration that makes strong assumptions about the future? in either case nodes can use a widely agreed upon defualt (200 sat or w/e), but we're not locked in to anything
20:05:27 <niftynei> roasbeef, yeah but ... that's something you have to consider with anchors. whereas before you didn't have that opportunity
20:05:37 <joostjgr> to me, the field sounds like cheap insurance. all implementations can just enforce 283 for now
20:05:40 <roasbeef> my response is idk, so ppl can use a vaule today, but the protocol doesn't epcify one
20:05:41 <rusty> Testing constants is simpler.
20:05:42 <BlueMatt> roasbeef: my point is that you're equally locked in with or without the bit in the message
20:05:50 <niftynei> like right now the reserve kind of acts like the fee reserve reservoir
20:05:54 <BlueMatt> cause you'd want to just say "oh, you didnt send me the number 200-whatever, closing"
20:06:03 <roasbeef> BlueMatt: locked in for one chan is diff than all chans being locked in
20:06:05 <niftynei> the 'homi'e, if you will
20:06:07 <BlueMatt> so you might as well make it a feature bit (in the absurdly unlikely scenario it needs to change)
20:06:09 <niftynei> *'homie'
20:06:20 <BlueMatt> well, if you always error if its not a given value, you *should* use a feature bit
20:06:22 <roasbeef> make what a feature bit? being able to chose?
20:06:26 <BlueMatt> to indicate that you wont reject it
20:06:31 <BlueMatt> changing the value
20:06:33 <rusty> There's no difference between an enforced constant over the wire and an enforced constant not sent.  We can agree and deploy on a new field for this in, like, 30 minutes if we need.
20:07:07 <BlueMatt> I mean the difference is having yet another thing to check in the state machine....a thing that you have to check and track that never changes and that you enforce to always be a constant
20:07:16 <rusty> It would literally be a new odd/even TLV field pairing.
20:07:22 <BlueMatt> it....might as well be a constant, and if, in 10 years, we have to change it, a feature bit is easy enough.
20:07:25 <roasbeef> it's just initial validation, as you shoudl sanity check all the other parameters BlueMatt
20:07:25 <joostjgr> i am not sure about that 30 mins. in theory yes, but who knows what new angles we have then to discuss. if the field is already there, we can upgrade without coordination
20:07:43 <rusty> joostjgr: no you can't because everyone else will reject it once you change it!
20:07:48 <BlueMatt> joostjgr: my point is you cannot do that!
20:07:58 <roasbeef> "everyone else"
20:07:59 <BlueMatt> you can only change the value in that field by corrdination
20:08:14 <BlueMatt> so even if you have the field, you probably want a feature bit if you ever change it anyway
20:08:21 <joostjgr> if you open a channel to a node not supporting a different value, then it won't work indeed. but among nodes that enlarged the range, it does
20:08:23 <BlueMatt> to indicate "I wont reject if the field is something other than 2XX"
20:08:39 <BlueMatt> right, and the way we coordinate that kind of thing is feature bits :p
20:08:41 <rusty> joostjgr: yeah, that's trivial, it's an odd tlv field addition.
20:08:43 <roasbeef> they'll send back and error and you can retry or not, just like all the other fields in OpenChannel BlueMatt
20:08:54 <joostjgr> min channel size also isn't coordinate currently through feature bits
20:09:21 <BlueMatt> joostjgr: and min channel size has cause issues with ux cause its not coordinated ;P
20:09:22 <rusty> joostjgr: good example, and it's terrible UX.  It gets worse for more obscure things than amounts, too.
20:09:39 <BlueMatt> (see recent tweets about lightning app where people sent money in and got vague errors about not having sent enough money in)
20:09:40 <joostjgr> but is the solution a feature bit or a better error?
20:09:57 <BlueMatt> the solution is to fix it so there are less things that go wrong
20:10:11 <BlueMatt> I dont quite understand why "have fewer things that can go wrong" is a weird argument?
20:10:20 <joostjgr> with something like min channel size, idk what the fix would be other than communicating your range
20:10:47 <rusty> Yeah, I'm leaning on 253 as a constant and lack of interop problems.  An error saying "your anchor output is too low" is not very useful for most users, since they don't control it.
20:10:51 <joostjgr> we can't start advertizing desired ranges in feature bits right?
20:10:57 <BlueMatt> sure, in cases where its really clear that different nodes/users/impls really have good reasons for different values today I'm not gonna suggest fixing it
20:11:07 <BlueMatt> but here we definitely do not have such a case
20:11:26 <joostjgr> this is all not about us today wanting to do anything other than 253. it is just about having the field as an fast forward path in case we need it
20:11:42 <BlueMatt> a field is *not* sufficient for a "fast forward path"
20:12:08 <BlueMatt> you need a way to find peers that allow you to change it, and at that point....well a field in open_channel isnt sufficient
20:12:24 <joostjgr> fast forward path as in that implementations can upgrade independently and if there ranges overlap, it works
20:12:26 <BlueMatt> it kinda works, but only kinda mostly, and cuases real ux issues today
20:12:40 <rusty> joostjgr: then you must require a range today, not a constant.
20:12:41 <BlueMatt> ranges?!
20:12:49 <rusty> You cannot have both.
20:12:51 <joostjgr> the range today is 253-254
20:12:54 <joostjgr> 253-253
20:12:55 <roasbeef> we haven't had many issues with it ourselves, just as nodes today can select csv values, conf limits, etc
20:12:57 <BlueMatt> why would anyone ever have a range?
20:13:20 <BlueMatt> if it changes (as in "protocol is changing, must now be a higher value") then it will change to 2000-2000
20:13:22 <BlueMatt> not 253-2000
20:13:27 <rusty> roasbeef: no, we have had massive problems, you've just steamrolled us here, by higher deployment numbers.
20:13:40 <roasbeef> higher numbers for what rusty ?
20:13:55 <rusty> roasbeef: more nodes.... we've had to adjust our ranges to work.
20:14:04 <roasbeef> what ranges?
20:14:10 <joostjgr> i think this is more of a fundamental discussion, or is there anyone who sees difficulty in a hardcoded rejection of anything that is != 253 ?
20:14:11 <rusty> roasbeef: what we accept from LND nodes.
20:15:02 <rusty> joostjgr: we keep making this same mistake IMHO.  We can't decide, so we punt by making it adjustable "just in case".  That's how we got so many tunable knobs which can't really be tuned in the first place.
20:15:24 <rusty> (Since you need to know what all peers will actually accept, to change it)
20:15:32 <roasbeef> i'm mostly afk now btw, we're over
20:15:58 <roasbeef> rusty:  some params are fundamentally dynamic though, like the conf target or a csv values
20:15:59 <rusty> roasbeef: closemeeting?  I think you have to do it?
20:16:04 <roasbeef> #endmeeting