--- Log opened Mon Jun 21 00:00:44 2021
00:31 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 258 seconds]
00:39 -!- bitromortac [bitromorta@gateway/vpn/protonvpn/bitromortac] has quit [Quit: leaving]
01:19 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has joined #lightning-dev
01:45 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
01:46 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev
01:52 -!- jackielove4u [uid43977@user/jackielove4u] has quit [Quit: Connection closed for inactivity]
02:07 -!- belcher_ is now known as belcher
02:19 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has quit [Ping timeout: 268 seconds]
02:27 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
02:27 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
02:30 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #lightning-dev
02:33 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
02:50 -!- jackielove4u [uid43977@user/jackielove4u] has joined #lightning-dev
03:14 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has joined #lightning-dev
04:16 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has quit [Ping timeout: 272 seconds]
04:16 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has joined #lightning-dev
04:23 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:00 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has quit [Quit: Leaving...]
05:05 -!- AaronvanW [~AaronvanW@71pc74.sshunet.nl] has joined #lightning-dev
05:49 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Quit: Konversation terminated!]
05:52 -!- cryptapus [~cryptapus@user/cryptapus] has joined #lightning-dev
08:06 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
08:07 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev
10:51 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
11:59 -!- crypt-iq [~crypt-iq@71.69.230.255] has joined #lightning-dev
12:39 -!- roasbeef [~roasbeef@172.92.21.52] has joined #lightning-dev
12:42 -!- wilmer53 [~wilmer@cpe-172-250-19-6.socal.res.rr.com] has joined #lightning-dev
12:42 -!- wilmer53 [~wilmer@cpe-172-250-19-6.socal.res.rr.com] has left #lightning-dev []
12:44 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev
12:54 < niftynei> spec meeting is scheduled to start in 5 min; t-bast so graciously posted an agenda for us https://github.com/lightningnetwork/lightning-rfc/issues/879
12:54  * t-bast waves at niftynei
12:54 < niftynei> hello hello!
12:55 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
12:55 < t-bast> I saw you got allergic to my closing fee proposal and handed it over to rusty xD
12:55 < ariard> hi
12:55 < t-bast> hey ariard
12:56 < ariard> t-bast: hey t-bast :)
12:57 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev
12:58 < niftynei> t-bast: achoo
12:59 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
12:59 < niftynei> i've been bogged down in other stuff, didn't want it to get buried under my mountain of todos
12:59 < rusty> Hi everyone!
12:59 < niftynei> do we have a chair volunteer for this week?
13:00 < t-bast> niftynei: no worries I was just kidding, I still have interactive-tx on my todo list of reviews
13:00 < t-bast> hey rusty!
13:00 < niftynei> hellllo rusty!
13:00 < t-bast> before we even start, what about merging https://github.com/lightningnetwork/lightning-rfc/pull/852 which has an ack from CL and an ack from RL? Or shall we discuss it during the meeting?
13:00 -!- wpaulino [~root@2604:a880:400:d0::205d:a001] has joined #lightning-dev
13:01 < roasbeef> t-bast: do eet
13:01 < t-bast> hey roasbeef!
13:01 < rusty> +1!
13:01 < niftynei> fastest spec meeting action i've ever 
13:01 < roasbeef> the diff looks kinda weird tho, trait of the current format of the vectors tho I guess 
13:02 < t-bast> yeah, it's hard to look at the diff on these...
13:02 < t-bast> hopefully we won't touch them much now and will just append or change the format entirely at some point
13:03 < rusty> hopefully future test vectors will be all JSON/YAML in separate files, but yeah, this is the minimal fix.
13:04 < t-bast> does someone want to chair or should I? I've missed a few meetings, I can make up for it by chairing
13:04 < ChristianDecker[> Heya, good evening everyone ^^
13:04 < roasbeef> I'm mega behind myself, still catching up w/ things from my week off lol 
13:04 < t-bast> This is a brand new cdecker with a long nick, I'm not used to that :)
13:05 < t-bast> roasbeef: you managed to really take a week off? no twitter, no github, no bitcoin?
13:05 < jkczyz> hey
13:05 < niftynei> +1 to t-bast chairing, as penance for his long absence
13:05 < ariard> well you can still draw bitcoin data structs if you have a pen and a pencil...
13:05 < ariard> a paper
13:05 < roasbeef> t-bast: heh yeh, and was timed w/ even more bitcoin news craziness than usual 
13:06 < t-bast> #startmeeting LN Spec Meeting
13:06 < lndev-bot> Meeting started Mon Jun 21 20:06:12 2021 UTC and is due to finish in 60 minutes.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:06 < lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:06 < lndev-bot> The meeting name has been set to 'ln_spec_meeting'
13:06 < t-bast> roasbeef: it's always when we're away that the best things happen!
13:06 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/879
13:06 < t-bast> #topic BIP69 must die
13:06 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/876
13:07 < t-bast> I think we have agreement on this PR
13:07 < cdecker> ack
13:07 < rusty> ack (again)
13:08 < BlueMatt> can i ack my own pr? seems like its me + 2 impls, so thats good?
13:08 < roasbeef> t-bast: what about the inputs? 
13:08 < BlueMatt> there are no cases in lightning where you need to sort inputs
13:08 < roasbeef> as in it removes bip 69, but then only specifies output ordering 
13:08 < BlueMatt> (today)
13:08 < roasbeef> dual funding? 
13:08 < roasbeef> (dunno what it specifies there tho) 
13:08 < BlueMatt> yes, with dual funding presumably that will change. iirc thats still a pr.
13:09 < t-bast> we don't need it now, but not sure if we'll need it later
13:09 < BlueMatt> tho we *should* be randomizing things
13:09 < t-bast> we can probably address it later when we add multiple inputs that need sorting?
13:09 < t-bast> or don
13:09 < t-bast> 't
13:09 < rusty> roasbeef: df uses explicit enumeration for sorting, which gives each side some control (or, more commonly, random)
13:09 < BlueMatt> if niftynei agrees to randomize inputs then we dont need to specify :)
13:09 < niftynei> dual-funding intros its own ordering mechanics
13:09 < BlueMatt> yay
13:09 < roasbeef> no strong pref, but imo weird to say bip 69 is underspecified, then replace it w/ something that specifies even list w.r.t the tx data structure 
13:09 < roasbeef> even less*
13:10 < roasbeef> I guess remove "Input and" from the top header there? 
13:10 < roasbeef> > Transaction Input and Output Ordering 
13:11 < rusty> +1, but I think that comes under the "spelling" rule :)
13:11 < BlueMatt> done
13:11 < t-bast> ack on the latest
13:12 < rusty> BlueMatt: sorry, can you fix ToC ?
13:12 < BlueMatt> ToC?
13:12 < BlueMatt> oh contents
13:12 < rusty> Table of Contents :)  Then I will ack :)
13:12 < rusty> BLUE I WANT THE BIKESHED BLUE I WILL DIE ON THIS HILL
13:12 < BlueMatt> fine, done
13:13  * t-bast is looking for something else to change to see how much BlueMatt can take...
13:13 < rusty> Acked on issue,thanks BlueMatt
13:14 < t-bast> Let's merge this :)
13:14 < t-bast> #topic (Obsolete?) HTLC amount restriction
13:14 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/877
13:15 < roasbeef> ah I realize the github bot is still on freenode 
13:15 < BlueMatt> *which* freenode, tho
13:15 < t-bast> This PR removes what seems like an obsolete restriction on htlc amounts
13:15 < roasbeef> t-bast: not caught up on this, but from our PoV this went away after wumbo (impl wise) 
13:15 < t-bast> roasbeef: ok, that's what I thought, we'd have noticed it earlier if you didn't remove it
13:16 < rusty> t-bast: ack.  Turns out c-lightning only ever restricted what we send, not receive.  So once Electrum (who actually do restrict receive) rolls out their new version, we can simply remove requirement and bingo.
13:16 < t-bast> electrum said they'd just remove it on their end as well, which is the simplest way to deploy a fix
13:16 < rusty> (We should get someone from Electrum at these meetings, this stuff is only going to come up more often)
13:16 < t-bast> It's already removed from their master branch: https://github.com/spesmilo/electrum/commit/f52c0fd571d35c1287b29712c61f58f1174d2e97
13:17 < t-bast> and it looks like they even made a release: https://github.com/spesmilo/electrum/releases/tag/4.1.4
13:18 < rusty> Hmm, is anyone tracking versions on the network?  EVen ad-hoc measures would be nice.  Gah, drop that, we'd be in User-Agent hell again...
13:18 < roasbeef> we track feature bits 
13:18 < BlueMatt> lol, was just gonna ask if you had a user agent field pr handy :p
13:18 < roasbeef> alias is basically user agent
13:18 < t-bast> I'll need to revert the second commit on the PR, I think we should only keep the first one, right?
13:18 < BlueMatt> so....pr to require alias not be configurable and just be treated as a user-agent? :p
13:18 < roasbeef> but also maybe not a good idea to make what you're running explicit 
13:19 < BlueMatt> roasbeef: I'd put really good money on it being observable in one way or another for ~every node.
13:19 < roasbeef> yeh w/ poking ofc, that's diff that just being able to do an easy scan tho 
13:19 < roasbeef> many ppl use it as a user agent already as is tho (they tag lnd or w/e) 
13:19 < BlueMatt> any vuln that would come to bear probably takes about as much effort to exploit as it does to build a scanner to know *who* to exploit
13:19 < BlueMatt> I'd be *astounded* if it mattered
13:20 < rusty> Yeah, it's mainly for issues like this, and CVE reveal.  I'm happy with an active scan, I just don't want to write the code :)
13:21 < ariard> yeah, nmap for lightning network, just scan node and fingerprint on accept_channel policy
13:22 < t-bast> I pushed the branch to keep only the first commit, should be easier to review
13:24 < rusty> t-bast: I know "everyone knows" but maybe we should merge the removal of the *receiving* restriction now, and the sending restriction in 3-6 months time?
13:25 < cdecker> Meh, doesn't really matter does it?
13:25 < roasbeef> yeh everyone already does it 
13:25 < t-bast> I think it would be cleaner, but since we're in a state where a big chunk of the network already ignores the sending restriction, maybe just going with it makes more sense?
13:26 < rusty> ... except Electrum got it wrong.  t-bast OK, I'm a bit nervous but I guess there's a natural delay between fixing spec and updating the impl's anyway.
13:26 < t-bast> I'm curious whether rust-lightning implemented that restriction or not by the way?
13:26 < rusty> ("wrong" meaning right here!)
13:27 < BlueMatt> t-bast: we haven't bothered turning on wumbo currently, the mainnet testing that exists is still "testing"-level stuff, or close enough to it that we're in no rush. 
13:27 < roasbeef> in terms of what's widely used in the wild, the limits basically don't exist anymore already, and if an impl supports mpp then it was already masked from the user when sending 
13:27 < BlueMatt> so it doesn't paply
13:27 < BlueMatt> apply
13:27 < t-bast> BlueMatt: thanks
13:28 < rusty> (Side note: this did find us an issue, where for historical reasons we still refused to issue an invoice for more than 2^32 msat!  Fixed in coming release)
13:28 < t-bast> rusty: but since we want to remove this restriction, I'd remove it right now to avoid other new implementations from following the current rule while the network doesn't :)
13:28 < BlueMatt> well with bitcoin price where it is maybe its time to un-wumbo cause, like, dont need it anymore :)
13:29 < rusty> t-bast: agreed.  Ack from me.
13:29 -!- jarthur [~jarthur@2603-8080-1540-002d-f1a7-3092-c6c9-daa4.res6.spectrum.com] has joined #lightning-dev
13:29 < t-bast> Let me all know if we should merge this PR or wait for a round of review / github acks after the meeting
13:30 < roasbeef> t-bast: do eet
13:30 < rusty> Ah, apparently just causes disconnect, not channel loss.  Though I'm pretty sure it'll get stuck if you've sent commitment_signed (we'd just re-xmit, for example).
13:31 < roasbeef> in the routing context, impls should be setting their max_htlc field on edges anyway, since that guides path finding 
13:31 < t-bast> rusty: yes, we'd retransmit so the channel is quite unusable...but since one needs to upgrade anyway to unblock (either the sender to add the restriction or the receiver to lift it, since electrum already shipped the removal, it's the quickest way!)
13:31 < rusty> t-bast: true@!
13:31 < rusty> OK, you've convinced me.  
13:32 < t-bast> roasbeef: agreed, we have max_htlc limits for that one, and I think node operators should correctly tweak those (and at some point we should make them dynamic!)
13:32 < t-bast> rusty: yay!
13:33 < cdecker> They are dynamic in the spec, but I guess no impl allows runtime tweaking yet
13:33 < roasbeef> cdecker: of the channel update level parm? 
13:33 < roasbeef> param* 
13:33 < rusty> roasbeef: good point, we set that to 2^32-1, probably can up that now...
13:33 < cdecker> (with the usual caveat that updates are not instantaneous thus both policies need to be accepted in the transition)
13:33 < t-bast> cdecker: yeah, actually tweaking them at runtime is in fact harder than it looks, what do you do if it becomes actually invalid when you receive it? close the channel?
13:33 < cdecker> roasbeef: yep
13:34 < roasbeef> (we do allow ppl to update the channel update param at runtime fwiw)
13:34 < cdecker> Ah very nice 👍
13:34 < roasbeef> t-bast: same w/ diff fees right? 
13:34 < roasbeef> either you have a grace period, or you reject it, then send the latest version to the sender 
13:34 < rusty> You can define it easily if you use quiescence, FWIW.  Or, y'know, the simplified update mechanism :)
13:35 < t-bast> yes, I'd do it with quiescence to make sure it cannot cause channel closing regardless of the remote node's policy
13:35 < crypt-iq> t-bast: why can't you just accept the add and fail back with a channel update?
13:35 < crypt-iq> t-bast: why close the channel?
13:36 < cdecker> The max htlc only applies to the outgoing edge, so accepting and erroring is sufficient imho
13:36 < roasbeef> same thing applies to any sort of policy violation triggered by an inconseistnecy 
13:36 < t-bast> crypt-iq: if my current limit is 50mBTC and I want to lower it, but we're currently almost at 50mBTC, what should I do?
13:37 < crypt-iq> t-bast: what do you mean by "currently almost at 50mBTC"?
13:37 < t-bast> true, I can start failing HTLCs right after adding them
13:37 < roasbeef> t-bast: what limit, max_htlc? that's just the largest single htlc 
13:37 < t-bast> instead of relaying
13:37 < rusty> It's always a q of "why are you restricting it".  If it's because you never ever want it to happen, you need your peer to not send it, since they can get you to hold it for one cycle in your commitment tx.
13:37 < t-bast> I meant max_htlc_value_in_flight_msat
13:37 < t-bast> To reduce exposure to pending HTLCs in high fee environment for example
13:38 < rusty> t-bast:  in that case, you only check when adding and you're good (you can be over, you just can't *go* over).
13:38 < roasbeef> t-bast: ok we're talking about diff things, you can't change that rn anyway 
13:38 < rusty> But needs to be carefully defined and implemented, true.
13:38 < cdecker> Right, I was talking about the channel_update gossipped max single HTLC
13:38 < roasbeef> cdecker: yeh same
13:38 < t-bast> sorry for the confusion! I didn't realize that :)
13:38 < crypt-iq> t-bast: I thought you had meant the max_htlc not the sum, my mistake.  Though you do have exposure to that pending HTLC 
13:39 < t-bast> we're all in agreement then ;)
13:39 < roasbeef> lol @ irc
13:39 < t-bast> for something like max_htlc_value_inflight_msat I think using quiescence or something like it is the safest way to update
13:39 < rusty> t-bast: yes :)
13:39 < cdecker> Definitely
13:40 < t-bast> Shall we merge the PR and move to the next topic?
13:41 < rusty> t-bast: Please!
13:41 < cdecker> Yep
13:42 < t-bast> #topic Explicit channel type negotiation
13:42 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/880
13:42 < t-bast> Thanks rusty for posting that PR, it was long due and very useful!
13:42 < roasbeef> so we have a version of this that just uses integers for channel types, rather than feature bits 
13:42 < t-bast> roasbeef: similar to https://github.com/lightningnetwork/lightning-rfc/pull/880#discussion_r655197765 ?
13:42 < roasbeef> since feature bits aren't sparsely encoded, you can end up w/ a pretty large byte slice there just to communicate you want to use some fringe channel type 
13:42 < rusty> Yeah, don't do that.
13:43 < roasbeef> sending over multiple feature bits doesn't make things explicit, don't see what it attempts to achieve 
13:43 < roasbeef> t-bast: yeh basically exactly that 
13:43 < BlueMatt> do we care *that* much if open_channel gets big(ish)?
13:43 < rusty> We're pretty good at assigning feature bits.  Now you have to assign another thing, too.  I've already doubled the size with option_simplified_update, for example!
13:43 < roasbeef> t-bast: https://github.com/lightningnetwork/lnd/pull/5373 
13:44 < roasbeef> rusty: seems like a pretty light lift 
13:44 < t-bast> rusty: but what's the behavior when you don't receive exactly the set of feature bits you expect? just consider that this is a channel type you don't know?
13:44 < roasbeef> this is just ambiguous as is 
13:44 < rusty> t-bast: yes, of course.
13:44 < BlueMatt> t-bast: yes.
13:44 < roasbeef> and doesn't make things explicit 
13:44 < t-bast> rusty: ok, I can live with that, but probably worth making it explicit that it's this exact set of feature bits that is expected
13:44 < roasbeef> vs just sending the type you want (based off their advertised feature bits) and them rejecting or not 
13:45 < BlueMatt> roasbeef: if your concern is that open_channel gets too big, do you have a concrete size in mind that would/does make it too big?
13:45 < roasbeef> BlueMatt: see above, this is just ambiguous as defined, and isn't explicit negotiation 
13:45 < rusty> I mean, you can treat it as a weird enumeration, but it's easy to know how to extend this to your boutique thing you want.
13:45 < BlueMatt> roasbeef: or are you worried about combinatorial explosion if people are willing to implement that?
13:45 < rusty> roasbeef: it seems very concrete to me?  
13:45 < BlueMatt> roasbeef: I dont get how it isn't concrete?
13:46 < roasbeef> what if I send static key bit set and anchors bit set, what happens then? 
13:46 < rusty> Technically, we could halve it by only having one bit (not even odd) per feature, but that seems like too much work for too little gain.
13:46 < roasbeef> all you need is a single type 
13:46 < rusty> roasbeef: you mean, as defined in the table?
13:46 < roasbeef> this just kinda moves around the current implicit negotiation 
13:47 < rusty> roasbeef: it fits neatly in the existing implementation, in that it's trivial to define "channel_type" for old channels which didn't use this.
13:47 < cdecker> roasbeef: so you'd have a separate document that maps a single type to a set of featurebits?
13:47 < roasbeef> cdecker: just a single type to the channel type, feature bits are then just used to advertise what you understand 
13:47 < cdecker> seems like that'd just be a shorter encoding of this PR
13:48 < roasbeef> cdecker: yeh that and it's actually explicit 
13:48 < rusty> roasbeef: that's what this is, but it's just not compactly encoded?
13:48 < roasbeef> this also seems to leave in the downgrade stuff we had to work around, when we made the static key bit required 
13:48 < t-bast> I started implementing it and what irked me a bit was whether I should allow receiving `mpp + static_remotekey + anchor_output` and ignore the `mpp` part as an (harmless) implementation mistake, but if we're strict on the exact features that map to each channel_type, that works for me
13:48 < cdecker> Adds the overhead of maintaining that document, and ultimately everybody will self-assign an experimental type ID?
13:48 < roasbeef> if we go w/ what they send in accept, I just bail if I don't like it? 
13:49 < rusty> t-bast: yep, don't open.
13:49 < roasbeef> cdecker: maintainence of the BOLTs is already weird as is, we have a lot of in-line if statements, and not really clear where a new implementor is meant to start 
13:49 < roasbeef> docs have grown to pretty massive sizes 
13:49 < rusty> roasbeef: you bail if they don't exactly mirror one you offered, yes./
13:49 < cdecker> True, so why add to that load?
13:49 < roasbeef> rusty: yeh that's not explicit, vs just saying "I want to use this type" 
13:49 < roasbeef> me sending a set of bits and you choosing one isn't explicit 
13:49 < rusty> roasbeef: opener: here are the types are support.  accepter: this is the one I choose.
13:50 < roasbeef> me just sending the type I want to open is
13:50 < rusty> roasbeef: sure, then only send one?
13:50 < roasbeef> rusty: sure, then why not just sent a single int at that ppoint? 
13:50 < roasbeef> rusty: the acceptor clause means the downgrade stuff like the static key required thing we had to work around still exists 
13:50 < rusty> roasbeef: no, don't offer that!
13:50  * roasbeef sighs
13:51 < rusty> Using a different enumeration does not change this.
13:51 < rusty> And if you only offer anchors, then that's the only thing they can accept.  I don't see what we're missing here?
13:51 < cdecker> Agreed, the list of featurebitsets enables a superset of the functionality of a type enumeration imho
13:52 < roasbeef> cdecker: no it isn't, it doesn't give the channel opener control of what type of channel is there if multiple bits are advertised and the acceptor chooses 
13:52 < rusty> Sure, the enumeration is built from feature bits.  That makes it trivial to extend in future, though a bit verbose.  It makes it easy to implement.
13:52 < roasbeef> why send bits again if they already exist in the node ann, and using the node ann I can see what you support? 
13:52 < roasbeef> then you only need to specify in open_chan, the responder can take it or leave it 
13:52 < niftynei> arent bits just an 'exploded number' anyway? you could condense them to a single value if you wanted to....
13:53 < rusty> roasbeef: it's not an arbitrary bitset.  It's an enumeration built out of feature bits.
13:53  * niftynei realizes this is extremely besides the point
13:53 < roasbeef> niftynei: yeh exactly, and they already also follow a clear orderong, so no extra overhead to say ok this is 0, 1, 2, 3, etc 
13:53 < BlueMatt> sorry, got distracted by process servers 🎉
13:53 < cdecker> Ok, we seem to have a major misunderstanding here: the PR offers a list of selections [ [ANCHOR, STATIC], [STATIC]] and the acceptor choses 0, or 1
13:53 < roasbeef> cdecker: why send it again? 
13:53 < t-bast> roasbeef: just to make sure, have you seen that the PR doesn't send just a features bits array in the open message, but actually an *array* of features bits array (one per channel type proposed)?
13:53 < roasbeef> we already know the feature bits and their types, so you just need to send a single integer 
13:53 < cdecker> Roasbeefs enum variant says: offer channel [0, 1], and acceptor looks into the enum doc and selects 0
13:53 < roasbeef> this does implciit negotiation at basically 2 places 
13:54 < BlueMatt> I dont see how your proposal changes that?
13:54 < cdecker> Yeah, plus it adds a lookup in a table which needs maintaining
13:54 < roasbeef> BlueMatt: it leaves the node advertisement and send a single type at funding negotiation time 
13:54 < roasbeef> we already have look up tables for this stuff, as we all map the feature bits into an actual channel type at the impl level 
13:54 < niftynei> well the nice thing about using bits to derive the number, so to speak, is that there's no enumeration required for what the numbers *mean*
13:55 < cdecker> The PR doesn't change the node_announcement does it?
13:55 < crypt-iq> It only changes open/accept channel iirc
13:55 < roasbeef> cdecker: no, but it sends the same feature bit information at the chan open level, when I already know what you support, so I can just send the type 
13:55 < cdecker> Right, which is functionally equivalent to roasbeef's thing
13:55 < BlueMatt> roasbeef: I dont see why you'd need to always use lookup tables at an impl level, and even if you did, its easy to map
13:55 < roasbeef> BlueMatt: feature bit -> actual type for the channel in codebase? 
13:56 < cdecker> But you also send a list of types in the open, don't you?
13:56 < crypt-iq> Since it is a TLV field (which is optional?), I don't see why any other impl's need to care if they don't understand it?
13:56 < BlueMatt> roasbeef: sure, but, like, can I not implement it as "features X and Y" at the impl level, if the impl of X and Y are wholly separate things?
13:57 < rusty> I don't want YA pinchpoint. in the spec.  I don't want to ahve to assign a new channel_type.
13:57 < roasbeef> BlueMatt: dunno what you mean 
13:57 < roasbeef> rusty: it's pretty simple, use the feature bit position number if you want to, no extra selection needed
13:57 < BlueMatt> like, I dont see why its relevant that you want to implement this as an enum of channel types
13:58 < rusty> roasbeef: option_simplified_update is *additive* to the others though!
13:58 < BlueMatt> I may not want to, and especially for two features which are in separate parts of the code, why would I want to enum that?
13:58 < BlueMatt> sure, for some parts, yes, but others no
13:58 < rusty> So now you want a bitset, OOPS.
13:58 < cdecker> Well, we can just make the enum use large numbers that happen to have the corresponding bits set, done
13:58 < roasbeef> rusty: yeh you need to unroll, yuo'd need to impl that anew for any channel type that makes a drastic departure 
13:58 < cdecker> :-)
13:59 < cdecker> (thanks niftynei for that idea )
13:59 < roasbeef> like that simplified update protocol may need to be defined for new channel types in teh future, so that would add a new channel type iteslf for each iteration 
13:59 < rusty> roasbeef: yeah, well defining values by reusing feature bits avoids this problem.
13:59 < roasbeef> otherwise you have the same feature bit incompat again 
13:59 < t-bast> I think the option_simplified_update being additive is a good argument in favor of rusty's version, it can easily be added on top and is orthogonal to commitment format (which is impacted by the choice of static_remotekey / anchor / anchor-0-fees)
13:59  * BlueMatt -> time out, sorry, y'all. thanks for the time
13:59 < roasbeef> t-bast: I g2g, but please re-read what I wrote above, it doesn't achieve explicit feature bit negotiation, and maybe take a glance at that PR of ours I linked above 
13:59 < rusty> (option_simplified_update was my motivation here: you may want to advertize support for it, but not have it your preferred methd)
13:59 < rusty> roasbeef: sure, but you're completely wrong.
13:59 < BlueMatt> roasbeef: can you write up your objection more full-form?
14:00 < BlueMatt> I dont think anyone here understood your points
14:00 < t-bast> roasbeef: will do, I'll keep working on it this week 
14:00 < rusty> Yeah, I think we got our wires crossed :(
14:00 < cdecker> Sorry, a go PR is not a spec PR that can be understood without spending loads of time to get the context
14:00 < roasbeef> rusty: sure, we've implemented it and it achieves the goals we set out, but what you've described doesn't, I guess you can use whichever 
14:00 < rusty> roasbeef: I disagree :)
14:00 < BlueMatt> roasbeef: please write up, in long-form english, why that is.
14:00 < BlueMatt> roasbeef: and post it on the pr :)
14:00 < roasbeef> cdecker: yeh we've been prototpying to make sure nothign weird comes up
14:01 < cdecker> That's fine, but here we have an explicit PR that achieves the goal, vs experimental code that is far too spread apart to really get the gist of
14:01 < rusty> FWIW, this channel_type idea gets into splice, too, so we can update to a taproot channel.  It's a pretty neat encapsulation (thanks roasbeef for the idea)
14:01 < rusty> cdecker: I also have an implementation, FWIW, but I'm still writing lnprototests for it.
14:03 < t-bast> I'll do more work on the eclair implementation this week and keep in mind both approaches and will report back on the spec PR
14:03 < rusty> I should probably make it v. clear in the PR, that this is not some arbitrary feature bits, but reusing their values for convenience.  I am happy to switch from odd -> even, too...
14:03  * cdecker is also reaching timeout. Thanks everyone ^^
14:03 < BlueMatt> se y'all.
14:03 < t-bast> Alright it looks like we're at the limit and many are dropping off, maybe we should call it a day?
14:03 < rusty> Thanks!  I think we've fallen below quorum, but happy to chat for a whil longer.
14:04 < t-bast> crypt-iq: we'll put your two issues at the top of the agenda next time
14:04 < crypt-iq> t-bast: sounds good to me
14:04 < t-bast> #endmeeting
14:04 < lndev-bot> Meeting ended Mon Jun 21 21:04:16 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:04 < lndev-bot> Minutes:        https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-06-21-20.06.html
14:04 < lndev-bot> Minutes (text): https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-06-21-20.06.txt
14:04 < lndev-bot> Log:            https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-06-21-20.06.log.html
14:04 < t-bast> Thanks everyone for your time!
14:04 < rusty> t-bast: sorry for teh delay in implmenting the closing stuff: I really wanted channel_types before the mtg.
14:04 < t-bast> rusty: no worries, there's no rush there
14:04 -!- crypt-iq [~crypt-iq@71.69.230.255] has quit [Quit: Connection closed]
14:05 < t-bast> rusty: I meant to review all the PRs related to splicing and didn't find the time yet, so I'm late on some stuff as well!
14:05 < cdecker> Logs should be up in a sec (GH pages needs to regen)
14:05 < t-bast> I think we should have something like channel_types deployed sooner than later, it's going to be very handy
14:06 < rusty> t-bast: the spec itself is nice, I've got that part working great.  I just found some places we can do better internally with estimates for closing, and also some random other drive-by cleanups.
14:06 < rusty> t-bast: agreed, it's a pretty nice idea.  It works well for channel_upgrade too.
14:06 < t-bast> I'm very late on implementing warning messages as well, got caught up in RBF-land for anchor outputs...
14:07 < t-bast> Yeah the work on closing made me do some clean-up in eclair as well, and it fixed a few non-critical issues we had, that's why I'm hoping to make it land soon
14:09 < t-bast> I gotta go as well, have a good day/evening/night!
14:10 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving]
14:10 < rusty> t-bast: nice :)
14:11 < rusty> I guess I'm talking to the logs now:  sorting out proper handling of anchor outputs is top of my TODO for the next c-lightning release (say 3 months), and it looks like we're playing catchup with Eclair and LND here.    But I'm delighted that it'll basically lift the entire network out of fee-guessing hell...
14:13 < rusty> cdecker, niftynei: BTW Note I'm taking a couple of days off, starting after this meeting.  Hoping to ignore twitter and catch up on sleep.
14:14 < ChristianDecker[> Do that absolutely ^^
14:14 < cdecker> Sorry, matrix chat client vs plain-old-irc :-)
14:15 < niftynei> sg, enjoy your vacation!
14:19 -!- wpaulino [~root@2604:a880:400:d0::205d:a001] has quit [Quit: WeeChat 3.0.1]
14:30 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.]
14:36 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 265 seconds]
15:33 -!- smartin [~Icedove@88.135.18.171] has quit [Quit: smartin]
16:48 -!- roasbeef [~roasbeef@172.92.21.52] has quit [Remote host closed the connection]
17:07 -!- belcher_ [~belcher@user/belcher] has joined #lightning-dev
17:10 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 258 seconds]
18:06 -!- roasbeef [~roasbeef@172.92.21.52] has joined #lightning-dev
18:07 -!- roasbeef [~roasbeef@172.92.21.52] has quit [Read error: No route to host]
18:07 -!- roasbeef [~roasbeef@172.92.21.52] has joined #lightning-dev
18:13 -!- roasbeef [~roasbeef@172.92.21.52] has quit [Remote host closed the connection]
18:14 -!- roasbeef [~roasbeef@172.92.21.52] has joined #lightning-dev
21:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
22:18 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
22:24 -!- smartin [~Icedove@88.135.18.171] has joined #lightning-dev
22:39 -!- bitromortac [bitromorta@gateway/vpn/protonvpn/bitromortac] has joined #lightning-dev
22:59 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 252 seconds]
23:18 -!- roasbeef [~roasbeef@172.92.21.52] has quit [Remote host closed the connection]
23:27 -!- jarthur [~jarthur@2603-8080-1540-002d-f1a7-3092-c6c9-daa4.res6.spectrum.com] has quit [Ping timeout: 252 seconds]
23:41 -!- jarthur [~jarthur@2603-8080-1540-002d-f9cc-6895-8b3d-e0f4.res6.spectrum.com] has joined #lightning-dev
23:53 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
23:58 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 265 seconds]
--- Log closed Tue Jun 22 00:00:45 2021