20:06:56 <t-bast> #startmeeting LN Spec Meeting
20:06:56 <lndev-bot> Meeting started Mon Jul  5 20:06:56 2021 UTC and is due to finish in 60 minutes.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:06:56 <lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:06:56 <lndev-bot> The meeting name has been set to 'ln_spec_meeting'
20:07:04 <BlueMatt> just negotiate it when you connect, and give up.....its really not that expensive to connect and ask, yo.
20:07:06 <t-bast> Starting the meeting to record our discussions ;)
20:07:17 <t-bast> #topic Channel type negotiation
20:07:32 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/880
20:07:37 <roasbeef> t-bast: or just ditch negotiation, and funder sends what type they want, receiver can reject, gg -- much simpler
20:07:45 <ariard> BlueMatt: right, though now you have to probe node by node to assert the features-announced channel types is matching the ongoing, dynamic list of channel types
20:07:57 <BlueMatt> ariard: probing is super-duper-incredibly cheap!
20:08:00 <BlueMatt> just probe, please.
20:08:09 <rusty> roasbeef: wrong, you've just moved negotiation up a level, made it less defined.
20:08:15 <t-bast> roasbeef: but why is it better? It's more round-trips for the same end result then?
20:08:20 <roasbeef> rusty: not any less defined, you already know what they want
20:08:30 <ariard> BlueMatt: depends if you have to authenticate first with the counterparty to listen the channel types allowed
20:08:30 <roasbeef> t-bast: there's no extra round trips, you only need the chan_type field in the open chan message
20:08:31 <t-bast> roasbeef: negotiating supports your use-case and supports others as well
20:08:43 <BlueMatt> roasbeef: if we do that we *at least* need to define exactly how the error process works there, and maybe a new error message, or a new tlv at the end of error.
20:08:46 <roasbeef> t-bast: is it really ncessary though? just another layer of complexity
20:08:49 <t-bast> roasbeef: if the receiver doesn't agree with your first choice, there will be back and forths
20:09:01 <roasbeef> BlueMatt: yeah was thinking the same thing, carla has this proposal to add error codes
20:09:05 <roasbeef> so you can more easily handle the reject
20:09:18 <roasbeef> to the reg error message, or some ppl have suggested add another one just for that
20:09:23 <BlueMatt> ariard: its still dirt cheap! Unless we're talking about like asking the user for a password, but lets not. probing is *cheap*, period.
20:09:29 <roasbeef> t-bast: they should only advertise feature bits they accept
20:09:57 <roasbeef> then you already know what they want
20:10:19 <roasbeef> I also don't really see a case in the future, where the funder doesn't _know_ what theuy
20:10:32 <ariard> BlueMatt: but probing also assumes interactivity and now i can log that your node was interested at X by channel type Y, though we can mitigate on another layer with rotating node pubkey
20:10:33 <t-bast> roasbeef: I disagree, how would you handle different channel types for mobile nodes and routing nodes then?
20:10:38 <ariard> but still ip addr
20:10:38 <roasbeef> they'll want 100%, like if we find some other issue in anchors and you need to upgrade to a new patched type, why would they accept anything else?
20:10:47 <roasbeef> t-bast: how do those cases differ?
20:10:59 <BlueMatt> I mean funder can totally be happy with 10 different channel types, so its more a question of if you want to send 9 open_channel + error, then one accept_channel, or one open_channel_negoatiate, then one accept_channel_type, then an open_channel, IMO
20:11:09 <BlueMatt> they're really pretty similar in terms of feature set, just different message sequences
20:11:47 <t-bast> roasbeef: imagine I want to prefer opening one type of channels with routing nodes and another type with wallets - I need to turn on the feature bits for those, but want to decide after *init* which one I'll propose to each type of node
20:11:57 <BlueMatt> ariard: bleh, ok, now we're getting a ways out on a tangent - you can come up with any amount of edge-cases to anything :p
20:12:10 <roasbeef> t-bast: would you really be able to distinguish them effectively? you can just send the reject and they try again w/ a diff type if they want to
20:12:27 <t-bast> roasbeef: routing nodes will think they can open a channel with type XXX with me whereas I'll reject their channel open because I only do that for wallets
20:12:30 <roasbeef> rn it's an issue independent of this, that channels are rejected and ppl don't know why (min chan size, etc) -- which shows the need for the error message w/ prpoer types here again
20:12:52 <t-bast> roasbeef: so if I reject and they retry with another channel type, why not do it in a single step where they send me their list of channel types?
20:12:57 <roasbeef> t-bast: so they can try again, do you already implement such logic today w/ the existing chan types? how do you finger print a routing node?
20:13:03 <BlueMatt> roasbeef: I dunno if that matters - imo error types are only useful if they specify an exact action to be taken by the sender of the original message in response.
20:13:07 <ariard> t-bast: but that's the point we should disssociate features bit expression from channel types policy, because you might restrain your accepted channel types to a subset of nodes
20:13:15 <BlueMatt> in the case of "not enough money to fund channel", probably you just say "ok, I'll try another node"
20:13:21 <BlueMatt> so I dont really think error types "fix" that.
20:13:23 <rusty> BlueMatt: exactly, and that's hard, at the least.
20:13:29 <t-bast> roasbeef: we fingerprint wallet nodes instead, for example by opening channels to them after a swap
20:13:30 <roasbeef> BlueMatt: rn ppl always complain they can't open channels to ppl because they don't know the accepted min chan size, w/ this they'd at least get that value in an error and can retry
20:13:46 <BlueMatt> at least for the "nope, try next channel type" error type/action you know what to do now :)
20:13:54 <roasbeef> t-bast: ok yeh if you know the wallet is running your software it's diff, but don't see that generically being the case, unless we provide hints w.r.t how to fingerprint nodes or something?
20:13:59 <roasbeef> which would be wierd
20:14:05 <BlueMatt> roasbeef: I mean the error messages I've seen from nodes have always been very clear and understanable
20:14:14 <BlueMatt> roasbeef: and afaik always even provide the minimum funding amount
20:14:25 <BlueMatt> I'm not sure what the issue is aside from being able to include that in gossip (please, no)
20:14:26 <roasbeef> BlueMatt: users that report these issues to me don't think so
20:14:29 <cdecker> Indeed and channel_types can have less information (no threshold associated)
20:15:18 <BlueMatt> roasbeef: maybe the other-node-provided human-readable error message should be more prominently exposed, or we should be filing bug reports against the sender of the error message to make their "human-readable" errors more "human readable" :)
20:15:28 <BlueMatt> I'm not sure "error types" changes this at all
20:15:40 <cdecker> Also these kinds of policy requirements are orthogonal to channel features imho
20:15:40 <roasbeef> ofc it does, it gives feedback where rn there's non
20:15:53 <roasbeef> as there's other reasons today a channel funding can be rejected: bad csv, bad min depth, etc, etc
20:15:59 <roasbeef> but bad in this case is node policy
20:16:02 <ariard> well you could automate channel opening corrective action based on error types, if you're few sats under the min funding amount
20:16:10 <BlueMatt> but more on-topic, one related question here is "if node wants to have a different maximum channel value or different fees for anchor-vs-not, how do you communicate that when negotiating channel type"
20:16:12 <roasbeef> ariard: yeh exactly
20:16:23 <rusty> Got a link to Carla's proposal BTW?  I can't find it...
20:16:25 <BlueMatt> roasbeef: today there's great feedback on why a channel is rejected!
20:16:35 <BlueMatt> at least if you're in a world where you want a human to respond
20:16:44 <roasbeef> BlueMatt: not in my experience, not the experience of all the users that're frustrated w/ it in the wild
20:16:46 <roasbeef> nor*
20:16:47 <BlueMatt> if you wnat a machine to respond (which I dont think you can do in most of the errors you mention here), then you cannot
20:16:48 <ariard> this one https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002964.html iirc
20:17:00 <BlueMatt> roasbeef: right, so the fix for that is to improve the human-readable messages that are being sent
20:17:12 <roasbeef> or give error codes so machines can handle them and send back error messages
20:17:13 <BlueMatt> not to add error codes so that you can then map those to your own human-readable messages that are more clear
20:17:18 <roasbeef> do you really want to string match in a wallet based on an error?
20:17:22 <BlueMatt> but the machine cannot respond to those error codes anyway
20:17:24 <roasbeef> that's backwards
20:17:26 <t-bast> we haven't had this issue with our node, the error messages we receive are more than enough to usually figure out what's wrong with a rejected channel_open
20:17:38 <BlueMatt> if you have an error type that you want a machine to respond in an automated way, then, yes, we agree
20:17:43 <roasbeef> a wallet can take the code, and present an error to the user, as maybe they need to disaply it in a diff langauge even
20:17:52 <BlueMatt> but "not enough value" and "csv delay bad" are not things that a wallet can automatically handle
20:18:03 <rusty> ariard: thx, was looking on GH.
20:18:26 <roasbeef> rusty: yeh that's it above, she started with enumerating common error paths across impls and came up with a proposed initial set
20:18:39 <ariard> BlueMatt: hmmmm  you could have pre-loaded channel acceptance strategies, like beyond csv upper-bound don't open anymore
20:18:56 <BlueMatt> ariard: you're pushing the boundary of reasonable things to actually do :p
20:19:06 <ariard> i mean opening there as the opener is the one receiving error types
20:19:19 <roasbeef> but to the original topic: not clear how you'd even create a negotiation layer to account for all the edge cases that exist, if channel options start to multiply, and there're combinations together that just don't make sense
20:19:19 <BlueMatt> ariard: but, right, the receiving node already decided "is that ok or not"
20:19:37 <rusty> I agree with roasbeef, I would love structured errors.  But BlueMatt is right, it's useless without being able to define actions.  For example, that list is mostly "Your impl fucked up", and there's literally one code for "Funding params unacceptable (eg, channel too small)".
20:19:37 <BlueMatt> roasbeef: but that's for implementations to decide
20:19:48 <roasbeef> the other thing at hand here is the types vs the set of feature bits
20:19:54 <roasbeef> BlueMatt: sounds....undefined :p
20:20:05 <cdecker> So are you proposing having a "negotiation through errors" _after_ the failed opening, because that's how it sounds like :-)
20:20:12 <BlueMatt> roasbeef: but implementations are gonna decide which sets of features make sense together either way
20:20:13 <roasbeef> rusty: don't agree that it's "useless", maybe has less use for certain cases, but it's 100% a value add
20:20:28 <ariard> BlueMatt: yeah but you know at some point i expect Smart Software(tm) to react on mempool congestion/spikes and decide to open as much chan you can, without waiting your node operator to wake up in the middle of the night :p
20:20:33 <BlueMatt> but, point being, roasbeef, do you disagree with my above description of this?
20:20:47 <BlueMatt> "more a question of if you want to send 9 open_channel + error, then one accept_channel, or one open_channel_negoatiate, then one accept_channel_type, then an open_channel, IMO"
20:20:50 <roasbeef> cdecker: I guess I'm of the stance that I don't think negotiation should really exist, the funder either give it a shot or goes somewhere else, seems there'll be sooo many params, particularly as more and more channel types are added
20:21:03 <BlueMatt> also, one related question here is "if node wants to have a different maximum channel value or different fees for anchor-vs-not, how do you communicate that when negotiating channel type"
20:21:22 <roasbeef> feels like there'll also inevitably be weird cases where the funder ends up w/ something they don't want, and maybe turns out to actually be insecure (by don't want here I mean the user)
20:21:23 <cdecker> Right, but then why try to have machine-reactable errors at all? If it's just try-fail-try-somewhere-else
20:21:27 <ariard> i think the question is channel types negotation should be guided in typed errors or a completely different mechanism ?
20:21:42 <BlueMatt> roasbeef: you're still specifying a negotiation structure, just a "open_channel failed, try again with other parameters"
20:21:58 <BlueMatt> which almost certainly means different channel type
20:22:11 <roasbeef> or the just back off /shrug
20:22:14 <BlueMatt> I dont really understand why you'd reasonably try with eg different feerate/csv delay in an automated way
20:22:27 <BlueMatt> so imo either way you're negotiating channel type
20:22:41 <BlueMatt> but in one case you're doing it *with* the channel parameters in the same context
20:22:50 <BlueMatt> in another case you're doing it *without* the channel parameters, but all at once
20:23:14 <roasbeef> t-bast: also re your example in that comment, 1KB I don't think is the extreme, that comes in when someone picks a very far off channel type in the feature bit namespaces (several thousand bits)
20:23:16 <ariard> BlueMatt: let's say you want to open 5 channels best-case scenario and 3 channels in worst-case scenario, you're okay bleeding on feerate, but you want to do this before the mempool start to congestion again?
20:23:45 <ariard> like you give an opening budget holistically and not per-channel
20:24:11 <t-bast> roasbeef: there's no reason to pick a feature bit in the range > 1000 TBH, I don't think that's something we'll reasonably see in practice
20:24:24 <BlueMatt> ariard: you mean you want to basically probe a node to see when it will accept the channel? like you may be willing to "negotiate" a feerate by trying over and over to open? I mean maybe, but you also cannot do that later - an hour later you will go to update the fee and just get the channel closed on you.
20:24:34 <rusty> roasbeef is right that this should be a pre-negotiation, before other parameters, but damn it's easier to implement like this :(
20:24:35 <BlueMatt> ariard: so at least for the feerate example I think it doesnt actually address the issue
20:25:31 <roasbeef> impl wise the send and forget-maybe-they-accept seems 100x simpler to me, it's what happens rn already effectively, as we see w/ the current fee rate "negotiation" (which again is very underspecified and we've had issues w/ in the past) this dynamic stuff is hard to get right in practice
20:25:46 <BlueMatt> rusty: Do you think it *matters* to be able to *also* negotaite the csv delay at the same time as different channel types? eg different csv delay for anchor vs not?
20:25:55 <ariard> BlueMatt: right, with the legacy `update_fee` channel model in mind, but with a future `option_negiotated_fee_commitment` you might have stable feerate, decided once-for-all at opening?
20:26:12 <BlueMatt> ariard: sure, but then you can figure out how to negotiate at open in that spec :)
20:26:31 <roasbeef> also notice that w/ the chan_type tlv, if the other party doesn't support it, then it falls back to the current implicit stuff unless you set that required bit, vs having two different negotiation mechanisms across the protocol
20:26:31 <rusty> BlueMatt: well, feerate def matters.
20:26:57 <roasbeef> t-bast: it can happen in practice /shrug
20:27:17 <ariard> BlueMatt: and i think we're back to an early discussion of channel_types, this fee-sharing scheme might leak across a bunch of other channel types, eltoo/taproot/...
20:27:19 <t-bast> roasbeef: it can happen, because everyone can do dumb things, but why would you though?
20:27:29 <BlueMatt> rusty: right, but I guess I'm not really sure how you negotiate channel types without sending a full open_channel message and let the recipient reject-or-not....if you want to negotiate fee/csv at the same time.
20:27:35 <BlueMatt> (tho note that you cannot today negotiate fee at all)
20:27:40 <ariard> and now you're mechanism isn't specific to *this* spec, so might be better to think about a generic mechanism
20:27:53 <t-bast> roasbeef: and why would you use such a feature bit in a channel type if you want to send a huge list of them? I think it's a bit far-fetched...
20:28:26 <BlueMatt> also, honestly, who cares about sending 1KB? Or even 20KB or 30KB...I mean we're talking 15 packets, who cares?
20:28:52 <roasbeef> BlueMatt: when 4 bytes will do and can encode the same information?
20:28:52 <BlueMatt> (if it were 30KB * 10k messages, sure, but its 30KB per channel open...)
20:28:56 <t-bast> I agree, especially for something that only happens when setting up a channel
20:29:01 <roasbeef> let's just unroll al our integers!!
20:29:04 <rusty> BlueMatt: right.
20:29:11 <BlueMatt> roasbeef: who cares? if its easier for the programmers, better!
20:29:30 <roasbeef> BlueMatt: imo not easier for the programmers, you know need this feature bit intersection code to actually map that down to something you accecpt or not
20:29:30 <t-bast> At least I don't think it's a good enough argument for or against any of the two proposals
20:29:33 <rusty> roasbeef: creating another enumeration requirement *blocks* changes.
20:29:35 <t-bast> We should focus on the other points
20:29:42 <ariard> BlueMatt: well if you have to probe significant part of the graph and you're a mobile ?
20:29:44 <roasbeef> ppl are gonna have a big match/switch statement either way, might as well flatten that down
20:29:45 <BlueMatt> roasbeef: right, well imo first lets agree on the design consierations here.
20:29:55 <BlueMatt> I'm kinda coming back to needing to do basically roasbeef's proposal
20:29:57 <roasbeef> rusty: there isn't one, you just use the feature bit position as the type
20:30:05 <BlueMatt> but we can debate over how to communicate a type later
20:30:09 <roasbeef> so the bit and the type get assigned at the same time basically
20:30:28 <rusty> roasbeef: except there's an intersection.  turbo channels!  simplified commitment update!  etc.
20:30:48 <BlueMatt> eg specifically cause I think its reasonable to negotiate the csv at the same time as the channel type (ie more csv for non-anchor)
20:30:52 <rusty> roasbeef: I don't know how many times I have to repeat this.
20:30:54 <roasbeef> rusty: yeh so you just roll those out, you'd need to be able to handle that intersection anyway, now it's on _one_ dimension
20:30:56 <t-bast> I agree with BlueMatt, let's not focus on how to communicate the type, but on whether we want a negotiation step or just send one channel_type per attempt and handle errors
20:30:57 <BlueMatt> then you basically *have* to do it in an open_channel message
20:31:15 <roasbeef> BlueMatt: yeh you need to know what you're opening before you send the params
20:31:59 <roasbeef> rusty: as it's also feasible those modifiers can't be defined for certain combinations, like simplified commitment w/ eltoo is undefined prob -- since it's an entirely different commitment type
20:32:12 <roasbeef> so it really only applies to certain asymmetric state commitment types
20:32:12 <t-bast> I agree with roasbeef that sending a single channel_type per attempt simplifies the negotiation of the channel parameters. I liked sending multiple channel types to avoid going back and forth, but if in the end we fail because of a channel parameters mismatch we're back to square one.
20:33:02 <rusty> roasbeef: absolutely, but I can tell you immediately what that channel_type will look like.  No need to do a level of indirection, race with different features being implemented at the same time in the spect, etc
20:33:14 <rusty> Frankly, flattening the enumeration is centralizing.
20:33:16 <BlueMatt> rusty: your thoughts on doing it *in* an open_channel/error-tlv negotiation?
20:33:21 <ariard> right, first lock-down the channel_type then try channel_parameters, though in case of failure on step two you can still downgrade to step one hmmmm
20:33:24 <roasbeef> rusty: can you elaborate on the "race w/ diff features?" you mean if someone takes your feature bit?
20:33:30 <roasbeef> ariard: yep....
20:33:42 <t-bast> Let's forget about the flattening for now and first see whether we want to send only one channel_type per attempt or many :)
20:33:42 <rusty> roasbeef: no, someone else takes your flattened channel_types.
20:33:59 <roasbeef> rusty: something something xor? :p
20:34:12 <roasbeef> how can that happen though, that's the same as a feature bit conflict right?
20:35:23 <rusty> roasbeef: there are private feature bits (100+) defined already, it's easy to get an assignment, and the coordination is simple.  The coordination required for a range of channel_types is not.
20:35:46 <roasbeef> rusty: there's no coordination if the type integer is just the feature bit position, right?
20:35:53 <ariard> if you assume a first channel type negotation step, you can also assume the receiver is going to give you a window for channel parameters, so ensure success with 99,999%
20:36:08 <ariard> and then error types, if you're out for some dynamic reasons
20:36:10 <roasbeef> rusty: so mechanically mapping the bit to an integer
20:36:15 <BlueMatt> (imo if we agree that we should be doing the negotiation via open_channel/error mesasges instead of an explicit list then there is no reason to discuss the type-integer-vs-feature-bitset any further, it goes from trivial to even-more-trivial and we can just *definitely* use the feature-bit-set)
20:36:21 <rusty> roasbeef: How do I indicate I want an anchor_outputs turbochannel then?
20:36:25 <cdecker[m]> Can't help but think this discussion would be much easier in person...
20:36:28 <roasbeef> if we have modifier bits and type bits, then use the upper and lower half or something
20:36:45 <ariard> BlueMatt: +1 here, let's decide first on negotiation mechanism before to envision the signaling space itself
20:36:52 <roasbeef> rusty: could do upper is concrete types, and lower is modifiers or something like that
20:36:52 <BlueMatt> roasbeef: now you're reinventing feature bits....
20:36:56 <roasbeef> kek
20:37:01 <rusty> BlueMatt: !
20:37:15 <roasbeef> ariard: sure they're two diff things
20:37:29 <roasbeef> tho related-ish...
20:37:32 <t-bast> cdecker: I agree xD
20:37:48 <rusty> I don't forsee a requirement to do the negotiation, but I defer to others if they can see one?
20:38:57 <cdecker[m]> Well, I still like the ability to offer a couple of types and the other one picking one that suits them
20:38:58 <t-bast> rusty: if the initiator sends a list of channel types, I think it should be negotiated *before* sending the actual parameters as they'll likely be different depending on the channel type chosen by the receiver
20:38:59 <rusty> And if everyone is going to only propose 1 type anyway, it seems weird to put an array in there.
20:39:34 <t-bast> But I think it's overkill to try to pre-negotiate channel parameters, so maybe sending a single channel type is actually simpler in practice
20:39:36 <roasbeef> t-bast: why do they need to send a list, if the feature bits are being re-used? I don't think the "I finger print nodes and offer diff types depending" will be widely implemented, in your context it's your wallet so you know more directly
20:39:43 <cdecker[m]> We can hardly offer only a single type, that'd forever freeze the features since a new feature would immediately result in a net-split won't it?
20:39:43 <rusty> cdecker[m]: it *sounds* good, but I'm trying to think how we'd use it.  The opener, after all, tends to have pretty fixed opinions on what they want.
20:39:44 <BlueMatt> there's pretty strong reason to do different csv values for anchor or not, imo
20:39:54 <roasbeef> cdecker[m]: why would it
20:39:56 <roasbeef> ?
20:40:01 <roasbeef> given feature bits exist
20:40:26 <rusty> Yeah, it'd still be illegal to try to open a type which it doesn't advertize as supported.
20:40:34 <t-bast> cdecker: you would internally have a list and try them in order, starting from your preferred one and then "downgrading"
20:40:34 <cdecker[m]> Well, the first one to implement it adds it to a new channel type and signals only that. No channel between new and old versions can be opened -> split
20:40:35 <ariard> i'm thinking we should let an authentication/compensation step between/before sending channel type
20:40:35 <roasbeef> rn if you have anchors, would you ever want to open another chan type w/ someone? (not saying there's always be one preferred type in the future though)
20:41:09 <roasbeef> cdecker[m]: they have all their connections still though, they just need to find new ppl, we had a diff issue related to this after we signalled required for the static chan key and netsplit w/ eclair (an actual connection level split)
20:41:21 <rusty> cdecker[m]:  that's true today if you set a compulsory bit though?
20:41:23 <roasbeef> in this case, we just wouldn't make new channels w/ them, but would keep the same connections as you wouldn't really make those chan type bits required
20:41:27 <BlueMatt> ariard: auth can do that in its own spec, no need to introduce that to this discussion?
20:41:32 <cdecker[m]> t-bast: right but that's just moving the "negotiation" after the attempt, and we actually have to move through the list in linear order, which we could skip if we just compared the two lists
20:41:42 <ariard> BlueMatt: like one compensation step could be the specified mechanism to buy turbo channels
20:41:51 <ariard> but sure, just lets room
20:41:54 <BlueMatt> ariard: again, lets discuss that when we get to having a spec for that?
20:42:22 <cdecker[m]> rusty: right, that's why we have optional versions though. With types you can't signal optionals afaik
20:42:25 <roasbeef> cdecker[m]: unclear to me how you'd really even define this "comparison" operation, and how it wouldn't lead to weird instances where the funder ends up w/ something they didn't actually want due to the _interpretation_ of the receiver of the feature bits
20:42:25 <BlueMatt> cdecker[m]: but how do you communicate "i support anchor with csv x or non-anchor with csv 5*x"?
20:42:30 <ariard> BlueMatt: i agree, i'm just pointing your reply to a channel_type probe might function of such authentication phase
20:42:51 <rusty> Oh, and re structure error codes (yeah, I'll respond on list): for bolt12 errors we specify (TLV, so optional) "erroneous field", "suggested value" as well as error, so you can at least get an idea of what they didn't like.
20:43:25 <ariard> but easy to reply `please_authenticate` to `open_channel_type` and if the initial sender isn't upgrade/understand authentication drop the channel opening
20:43:48 <cdecker[m]> So JSON array of objects listing features w/ parameters it is then, all agreed? xD
20:43:57 <roasbeef> ok so...single chan_type in open_channel, no negotiation, type and modified feature bits (I can live w/ the wasted space and a larger switch statement)?
20:44:01 <rusty> ariard: I don't udnerstand where this authentication thing is coming from?  Did I miss something.
20:44:24 <rusty> roasbeef: but the important question: are feature bits odd or even?!?!? :)
20:44:43 <rusty> t-bast: your turn to paint the bikeshed.
20:44:52 <BlueMatt> roasbeef: that's where I'm leaning
20:44:53 <t-bast> rusty: xD
20:45:00 <roasbeef> sheep it
20:45:08 <t-bast> rusty: in the end I don't care, I found examples where either choice is confusing
20:45:19 <BlueMatt> roasbeef: with a tlv in the error message that includes type-1 "I want a different channel type"
20:45:22 <rusty> (even makes more sense, I chose odd... because it's one less letter to type?)
20:45:39 <rusty> BlueMatt: see my comment on structured errors above
20:45:55 <ariard> rusty: well authentication could be defined by paying a premium fee, did pop up among discussion with DLC folks about who is bearing the mempool congestion risk in case of unilateral fee-bumping of dual-funded chan
20:45:59 <roasbeef> BlueMatt: +1
20:46:01 <ariard> sorry for the outside context
20:46:02 <BlueMatt> rusty: yea, I'm happy with that, but thats a lot more work to hold up channel types on.
20:46:19 <rusty> BlueMatt: yeah, totally we should untie that.
20:46:32 <roasbeef> and then something implicit that we no longer set required feature bits for channel types?
20:46:38 <rusty> (Initially you'll assume that you should try a diff type if you get some erorr)
20:46:43 <BlueMatt> rusty: but, yea, specify the exact field and the amount I guess I can live with, as much as I think its entirely useless and redundant with human-readable error messages.
20:46:47 <roasbeef> in the innit, as otherwise you lose your connection to a peer if they try to leave behind your channel type
20:47:01 <roasbeef> which is what happened to us, and forces us to downgrade our advertised feature bits for certain eclair nodes
20:47:18 <BlueMatt> rusty: I think you should try another channel type no matter what error you get! If you get a "csv too low error" you could totally just pick another type with the same csv and get a success!
20:47:48 <t-bast> roasbeef: not eclair node, eclair-mobile
20:48:12 <cdecker[m]> So we're really mixing open parameter negotiation with open feature negotiation?
20:48:53 <roasbeef> t-bast: gotcha
20:48:57 <ariard> cdecker[m]: well how do you interpret a "csv too low error" is up to you can purse parameter negotiation or fallback to open feature negotiation?
20:49:12 <roasbeef> cdecker[m]: they're kinda the same, you can't populate the message unless you know what type is being opened
20:49:15 <ariard> where pursuing parameter negotiation means try with a higher csv
20:49:34 <t-bast> rusty: there's one thing about the features included in channel types that came up in discussions I had with sstone and pm47. It's hard to articulate what makes a specific feature bit part of the channel type and what doesn't. Why isnt the wumbo feature bit included in channel type? Or upfront_shutdown_script?
20:49:36 <cdecker[m]> Right, just wanted to make sure I got that right, and that we're no longer "just" talking about features here
20:50:04 <BlueMatt> cdecker[m]: correct
20:50:06 <t-bast> rusty: I have a vague heuristic which is "a feature that somewhat drastically changes how the channel operates"
20:50:11 <roasbeef> t-bast: good q, right now we kinda mix the negotiation on a few diff layers, maybe we should make the "type" and "modifier" designation explicit?
20:50:17 <t-bast> rusty: but it's really hand-wavy
20:50:31 <ariard> t-bast: completely agree with you, the channel type is just an arbitrary bundle of features
20:50:39 <rusty> t-bast: certain bits are explicitly called out in the spec as "sticky": i.e. they depend on negotiation when the channel was opened, not since then!
20:50:40 <t-bast> roasbeef: but we'd have the same issue, what is a modifier and what is a fundamental feature?
20:51:13 <roasbeef> t-bast: one changes the commitment structure and the other changes certain other behavior?
20:51:15 <rusty> t-bast: e.g. you can go wumbo by reconnecting and negotiating wumbo bits.  You cannot do anchor_outputs that way.
20:51:20 <t-bast> rusty: but upfront_shutdown_script is sticky :D
20:51:36 <t-bast> roasbeef: but the "certain other behavior" is really handwavy!
20:52:02 <ariard> roasbeef: maybe we could typify more channels fee-bumping scheme/closing policy/outputs scripts/... at least `update_fee` is conflicting with `anchor` but doesn't say anything about the taprootness of the funding script
20:52:06 <t-bast> I agree that I'm nit-picking, I think it's ok to be hand-wavy here about what features are fundamental enough to be a channel type
20:52:15 <roasbeef> t-bast: yeh, no good way around it...unless we say the modifiers are on the featurebit level and the type is what's explicit as the thing in the msg?
20:52:19 <rusty> t-bast: the value is, the bit really isn't.  Anyway, this is why explicit enumeration is clear.  For future bits, you've got to decide.
20:52:20 <t-bast> But I thought it was worth mentioning, as readers will wonder about that heuristic
20:52:47 <BlueMatt> yea, what rusty said, just make sure its specified in the table when you add a new feature bit!
20:52:49 <rusty> (These days an empty script == no restrictions).
20:52:52 <roasbeef> ariard: yeah true, but I guess you'd need to re-define what the anchor script looked like post taproot?
20:52:56 <BlueMatt> but, agreed, should write it down :)
20:53:29 <t-bast> SGTM, we're all in agreement on that heuristic ;)
20:53:30 <ariard> roasbeef: right we should abstract the fee-bumping mechanism from the script support level
20:54:06 <roasbeef> ariard: yeh makes sense, can all this be tackled in one go though? we started as just being able to open diff channel types across the set of advertised feature bits
20:54:09 <rusty> #action rusty to remove array and negotiation from PR, just "take it or or leave it"
20:54:37 <roasbeef> rusty: +1
20:54:43 <rusty> I'll leave in the "accept_channel mirrors the channel_type" since that tells you it worked, otherwise you need to be using default.,
20:54:53 <roasbeef> do we need to make a decision here w.r.t modifiers vs chan types? or we just deal w/ that later
20:55:05 <t-bast> so IIUC, our current rough consensus is: we send a single channel type in open_channel and let implementations deal with errors however they see fit, we use the existing feature bits (the channel type list defined by rusty) and we can extend that in the future based on real-world feedback. Is that a fair conclusion or did I misunderstand?
20:55:10 <ariard> roasbeef: well i believe we'll get better with time rolling out minimal subtypes components instead of big bundle like `anchor_output` type
20:55:11 <BlueMatt> rusty: :100:
20:55:22 <rusty> t-bast: that's my understanding, yes.
20:55:42 <BlueMatt> t-bast: yep!
20:55:50 <BlueMatt> see? consensus *is* possible!
20:55:57 <t-bast> Yay!
20:56:05 <rusty> Can we move on to turbo channels, or peer backup storage, or onion messages, or trampolines or something cool?
20:56:09 <cdecker[m]> Huzzah :-)
20:56:18 <ariard> yeah SGTM for now
20:56:35 <rusty> (I forgot to buy coffee grounds yesterday, and I am v. grumpy this morning!)
20:56:47 * BlueMatt wont mention anything about australian coffee
20:57:07 <t-bast> I need to do some work on peer backup storage, I have a commit to add before we can discuss it so let's do something else today
20:57:19 <BlueMatt> rusty: yay onion messages?
20:57:32 <BlueMatt> I actually have a hard-out in 5 tho, holiday here and with extended family and all that
20:58:02 <t-bast> Let's do a round of onion messages, and we'll see where it takes us
20:58:06 <t-bast> #topic Onion Messages
20:58:30 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/759
20:59:04 <BlueMatt> aside from the rebase error, concept ack https://github.com/lightningnetwork/lightning-rfc/pull/759/files#diff-c3e160eeb369e80b50a24ceee86928786ae3b67a0687a7aea80e8cefac0145daR43
21:00:21 <BlueMatt> unimplemented ack from me :)
21:00:27 <t-bast> Can you summarize the arguments for or against dropping the `reply_path` rusty? If we drop it, we don't depend on route blinding anymore here, do we?
21:00:38 <roasbeef> how does this deal w/ rate limiting and DoS? at least w/ an HTLC you need to commit funds
21:00:45 <rusty> So I'd really like this to get implemented.  I renumbered the feature bit (since it was from before we just did the assign-in-title thing)
21:00:52 <BlueMatt> roasbeef: you can just....not forward?
21:01:25 <rusty> roasbeef: MAY ratelimit.  I thought about adding a pushback (you tell upstream to stop sending, it can similarly pushback on next msg etc) but it seemed premature.
21:01:40 <rusty> It's trivial to implement, BTW.
21:01:42 <ariard> roasbeef: "MAY rate-limit messages by dropping them" ? though feel free to not accept them if you don't have opened channels with sender?
21:01:53 <ariard> like sounds more an implementation/node policy question
21:02:04 <roasbeef> BlueMatt: before w/ HTLCs you have an actual cost to send a message (the HTLC size and opportunity cost of the worst case CLTV), here there's no cost at all
21:02:09 <BlueMatt> imo dont accept messages unless you have (or have recently had) a channel with the sender
21:02:18 <roasbeef> (and also the future fee you may need to spend when going on chain)
21:02:22 <BlueMatt> roasbeef: right, that's why it says you can rate-limt :)
21:02:31 <BlueMatt> so, ratelimit :)
21:02:32 <roasbeef> BlueMatt: afaict, this is meant to be used for messaging generally e2e across the network
21:02:32 <rusty> t-bast: so, reply-path in onion is good if the contents are unparsable.  But all the contents so far which required a reply could also encode their own reply path anyway.
21:03:03 <rusty> roasbeef: yeah, but OTOH these create far less cost on the intermediates, so...
21:03:18 <roasbeef> BlueMatt: Q is how does that info get back to the sender, do they get a reject or it just goes out into the ether?
21:03:32 <roasbeef> rusty: same CPU cost afaict, but no longer any storage?
21:03:56 <rusty> roasbeef: yeah, and you don't use up an HTLC slot or do a round-trip too.
21:04:02 <BlueMatt> roasbeef: the cpu cost of an htlc is ~0, its the io commit and funds commit thats an actual cost
21:04:06 <rusty> (and ofc don't hit the db)
21:04:41 <rusty> It's about as minimal as I could make it.
21:04:47 <BlueMatt> roasbeef: and, yea, a NAK would be cool, but then you have the same cost to send a NAK as a forward, which is obviously not practical? I dont really see a solution but I agree it'd be nice
21:05:15 <roasbeef> BlueMatt: if we re-use the sphinx single-use-reply-blocks you kinda get the reply path for free (and you still hide the sender)
21:05:24 <t-bast> rusty: ok, this does have a dependency on route blinding then (unless you're directly connected to the recipient), right? I'm asking because that means I really need to spend time on route blinding again and ensuring it gets enough reviews
21:05:49 <rusty> t-bast: yes, it does assume that :)
21:05:50 <roasbeef> BlueMatt: main diff I'm trying to get at is that this is "costless" compared to sending an HTLC
21:06:05 <t-bast> roasbeef: that's interesting, do you have a link to that sphinx feature?
21:06:12 <BlueMatt> roasbeef: right, good! messaging like this shouldn't have cost! I dont see why that isn't just trivially a great thing
21:06:17 <roasbeef> sounds like a good place to make a C&C
21:06:38 <BlueMatt> dont forward if you dont have a channel
21:06:40 <BlueMatt> problem solved :)
21:06:41 <roasbeef> BlueMatt: the costs here are distributed across the network of ppl that're moving these around w/ no offset
21:06:53 <roasbeef> BlueMatt: I think that neuters the proposed use case
21:07:10 <ariard> roasbeef: well you're free to pour a cost on it, like requiring a chan or good-counterparty reputation in your auto-pilot?
21:07:24 <roasbeef> t-bast: non paper link: https://katzenpost.mixnetworks.org/docs/specs/sphinx.html#single-use-reply-block-surb-creation
21:07:25 <BlueMatt> roasbeef: I dont see why you think that's a bad thing? Are you claiming that this will somehow have enough cost to forward a message that people will, like, not want to? or that it'll be "enough" cost that it'll ever show up?
21:07:37 <rusty> The problem is that ppl will do this anyway, they're just using HTLCs.  Blech!
21:07:41 <BlueMatt> roasbeef: honestly this sounds like the old "bitcoin will never work because you dont incentivize full nodes to relay transactions" argument
21:07:46 <BlueMatt> also what rusty said
21:08:02 <roasbeef> just seems super prone to abuse, and at least rn you have a cost w/ something trying to use the feature: "botnets will LOVE this little protocol feature" kek
21:08:16 <t-bast> roasbeef: thanks, that's interesting, that could mean we don't need to reinvent the wheel with route blinding if Sphinx already offers this feature, I'll dive into it
21:08:18 <BlueMatt> require a channel and then you dont have to worry
21:08:33 <BlueMatt> also if the cost ever shows up at more than 2% of your cpu or bandwidth, stop relaying and rate-limit
21:08:35 <BlueMatt> problem solved
21:08:38 <BlueMatt> like, very, very, solved.
21:08:49 <ariard> roasbeef: we might have compensation mechanisms cheaper than HTLC lock-in but costlier than zero?
21:08:51 <roasbeef> t-bast: yep, proposed them in the past, since they give you return traffic and fit into the existing scheme
21:09:04 <BlueMatt> It *is* maybe worth discussing backwards-path, but it sounds like rusty is just saying we can add that later?
21:09:27 <BlueMatt> ariard: please no. the cost on a forwarding node here is exactly zero. we dont need to charge when the cost is zero
21:09:37 <BlueMatt> ariard: again, this sounds like the old "bitcoin will never work because you dont incentivize full nodes to relay transactions" argument
21:09:51 <roasbeef> transaction relay doesn't allow generalized messaging
21:09:54 <ariard> BlueMatt: well you might have a set of watchtowers on your back consuming credits :) ?
21:09:57 <roasbeef> no one makes a botnet that communicates using transaction relay
21:09:59 <BlueMatt> people certainly use it for that :)
21:10:04 <rusty> roasbeef: can revisit: I didn't use SURBs because this is simpler (we already have the pieces).
21:10:08 <BlueMatt> roasbeef: please stop mentioning botnet, I've said 10 times require a channel.
21:10:28 <roasbeef> botnet
21:11:18 <t-bast> rusty: I'll investigate this SURB thing to see if it's similar to route blinding, if it helps make it better or if it replaces it with something more standard
21:11:20 <rusty> BlueMatt: you can't do that, at least today, since you want to be able to connect directly if you can't find an onionmsg path.
21:11:40 <rusty> t-bast: no, it isn't.  It allows a reply, but we still need route blinding.
21:11:49 <BlueMatt> rusty: heh, ok, so limit to channel-or-directly-for-me
21:11:56 <BlueMatt> rusty: or "channel for relay" not "channel for accept" :)
21:11:58 <t-bast> rusty: ok
21:12:10 <roasbeef> t-bast: I think route blinding is used for the rendezvous stuff? the SURB is prepared by the sender, but it increases the size of the packet
21:12:22 <roasbeef> in the OG protocol, it occupies the e2e message space we removed
21:12:23 <rusty> t-bast: SURB basically mean you include a cookie which can be used to send a reply.
21:13:30 <rusty> You encode a secret, the prevhop, and a timeout in there so you know what to do when you get a reply with it, and the timeout means you won't allow replies forever.
21:13:35 <t-bast> roasbeef: route blinding is simpler than rendezvous, it's basically just tweaks on node_ids, but to be honest I'm hazy on the details (even though I wrote it and implemented it...)
21:14:03 <rusty> t-bast: you basically decrypt the blob and use it instead of the normal TLV values.
21:14:20 <BlueMatt> rusty: did we decide concretely that there's no way to allow anonymous-senders + replies + no intermediate state?
21:14:38 <BlueMatt> i kinda thought there was a way to do it, but maybe it was decided there isn't?
21:14:47 <rusty> BlueMatt: no, SURBs + blinding gives us that.
21:15:03 <BlueMatt> ah, ok, i misunderstood your above comment, then.
21:15:07 <rusty> BlueMatt: but, so does the "give blinded route in payload" so I just did that.
21:15:45 <t-bast> thanks, that's clearer
21:16:02 <BlueMatt> rusty: ah, ok, i misread that a tiny bit, but, yea, ok, I mean I think this pr is great, aside from not having implemented it!
21:16:18 <rusty> roasbeef: IIRC, SURBs don't give an intermediary a way to reply though, which is the real problem with "I ratelimited you"
21:18:04 <rusty> So for ratelimiting, I think we end up ratelimiting in incoming, then sending a "stop sending pls for 10 seconds" msg.  The next time the sender wants to send it sends a "stop sending pls for 10 seconds" to where the to-be-dropped msg came from, etc.  It should stop naive flooding attacks, at least.
21:18:19 <rusty> (But someone needs to actually model this and think about it...)
21:19:08 <roasbeef> rusty: yeh it's only for the destination
21:19:18 <roasbeef> unless you add one for each hop, which blows up the message size
21:19:55 <rusty> roasbeef: yeah, which is why I just stuck a blinded reply path in there (which in theory allows a diff reply path, but probably would never be done)
21:20:36 <t-bast> Ok I skimmed through the link about SURB, I think route blinding offers a cheaper way to provide a reply path without intermediate storage - it does take up space in the message, but not that much
21:22:51 <ariard> rusty: hmmmm the "stop sending pls for 10 seconds" aren't sent by congestioned hop ? like it's the sender doing it
21:23:16 <rusty> ariard: yeah, congested hop I was thinking?
21:23:41 <ariard> rusty: yeah was unclear from "The next time the sender wants to send it sends a..."
21:24:09 * BlueMatt -> family time
21:24:13 <BlueMatt> anything else before we call time?
21:24:40 <rusty> https://github.com/lightningnetwork/lightning-rfc/pull/847 seems to have interop success?
21:25:19 <t-bast> Yes, IIRC roasbeef wanted to take a stab at implementing https://github.com/lightningnetwork/lightning-rfc/pull/847 in lnd?
21:25:20 <rusty> I know roasbeef has been wanting to kill close fee negotiation since forever, and this does that.  Seems to work?
21:25:41 <t-bast> rusty: did you notice I remove the `MAY disconnect` part in favor of sending a warning?
21:25:44 <roasbeef> yeh still need to carve out some time for an impl, looks pretty straight forward though
21:26:06 <ariard> let's start next meeting with 847?
21:26:12 <rusty> roasbeef: yeah, was easy.  Be nice to make compulsory and rip out the old stuff.
21:26:47 <t-bast> ACK, let's discuss #847 next time, it makes the negotiation code much simpler and more predictable, I really like it.
21:27:17 <rusty> (Eventually: I am thinking proposing bits 62/63 as "Modern Implementation" which implies lower bits and can let us recycle them in future...)
21:27:26 <rusty> Great!  Thanks everyone!
21:27:30 <t-bast> Enjoy your 4th of July murica people ;)
21:28:01 <t-bast> Thanks everyone for the discussions, I'm happy we got some progress on channel types!
21:28:09 <t-bast> #endmeeting