--- Log opened Mon Sep 13 00:00:06 2021
00:18 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection]
00:18 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev
00:38 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Quit: ZNC - https://znc.in]
00:38 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
00:49 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
00:50 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 276 seconds]
01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:10 -!- ziggie [~ziggie@user/ziggie] has joined #lightning-dev
01:12 < ziggie> Hello lighting devs, I am having trouble track down an error, right now I am trying to send a payment via a route A=>B=>C=>A, so one way everthing works fine, when I try to send the payment in reverse it fails with temporary channel failure and I know for sure there is enough balance on the channels (on both sides)
01:12 < ziggie> so I checked the log file on every node which is involved, but cannot find anything interesting
01:14 < ziggie> so just this one: CRTR: Node=2 reported failure when sending htlc
01:16 < ziggie>  Closed completed FAIL circuit for 351c0fb20888386d2e576b6ac2c35c28a1823eff29714c6b088b28d35932dda2: (0:0:0, 28009) <-> (689724:703:1, 362)
01:16 < ziggie> but how do I actually find the real problem
01:19 < ziggie> is this maybe the problem:
01:19 < ziggie> Setting 0286e50ebeaafdf7dc321f6c8cb7e964e236b03ed67494b6337215c5c3c42252f2->02c296e4517fc6e4a3a32903fd89a98bfe213a43e06790384430bffdc857f84abc range to [500050000 mSAT-1000100000 mSAT]
01:19 < ziggie> why is the range set so high ?
01:19 < ziggie> this is the channel between the two nodes, where the payment is failing
02:04 -!- Flow [~none@salem.informatik.uni-erlangen.de] has quit [Quit: WeeChat 3.2]
02:05 -!- Flow [~none@gentoo/developer/flow] has joined #lightning-dev
02:18 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
02:26 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
02:26 < lnd-bot> [lightning-rfc] m-schmoock opened pull request #911: BOLT 7: add gossip address descriptor type DNS hostname (master...bolt7-hostnames) https://github.com/lightningnetwork/lightning-rfc/pull/911
02:26 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
02:30 < mschmoock> Added https://github.com/lightningnetwork/lightning-rfc/pull/911  for supporting DNS hostnames (i.e. dynamic DNS users that dont like TOR to get throu their firewall)
02:31 < mschmoock> Will try to attend meeting today :)
02:32 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 252 seconds]
03:09 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
03:12 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
03:29 -!- sword_smith is now known as ikke_sword_smith
03:29 -!- ikke_sword_smith is now known as sword_smith
03:30 -!- sword_smith is now known as ikke_sword_smith
03:30 -!- ikke_sword_smith is now known as sword_smith
04:59 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:17 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 268 seconds]
05:35 -!- michaelfolkson2 is now known as michaelfolkson
07:32 -!- kanzure_ is now known as kanzure
08:44 -!- whysthatso [~whysthats@74-206-50-195.sta.estpak.ee] has joined #lightning-dev
08:45 -!- whysthatso [~whysthats@74-206-50-195.sta.estpak.ee] has quit [Client Quit]
08:45 -!- whysthatso [~whysthats@74-206-50-195.sta.estpak.ee] has joined #lightning-dev
09:16 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection]
09:16 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
09:20 -!- AaronvanW [~AaronvanW@190.242.161.186] has joined #lightning-dev
11:26 -!- lndev-bot` [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
12:41 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
12:41 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:fd36:4476:689:b677] has joined #lightning-dev
12:42 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 268 seconds]
12:54 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
12:54 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev
13:00 < rusty> Hello everyone!
13:01 < BlueMatt> hi akll
13:01 < ariard> hi
13:01 < cdecker[m]> Heya
13:01 < mschmoock> hi :D
13:01 < t-bast> hey everyone!
13:01 < ryanthegentry> howdy
13:01 < vincenzopalazzo> Helo helo :)
13:01 -!- crypt-iq [~crypt-iq@71.69.230.255] has joined #lightning-dev
13:02 < t-bast> I put up a tentative agenda in https://github.com/lightningnetwork/lightning-rfc/issues/909, there are a lot of PRs but some of them are really small, the meeting chair can definitely choose a different order than what I suggested based on their preference
13:02 < t-bast> I'm not sure we'll be able to do everything, so don't let me unilaterally choose what should come first ;)
13:03 < niftynei> hi hi hi
13:03 < niftynei> do we have a chair volunteer for today?
13:03 < niftynei> maybe someone who hasn't done it in a while?
13:04 < t-bast> Time to shine, chair volunteers!
13:05 < rusty> OK, I guess that's me then?  I am almost awake...
13:05 < niftynei> no objection here 
13:05 < t-bast> We'll allow the chair to take coffee breaks whenever needed
13:05 < t-bast> That will give us time to actually read the PRs
13:05 < rusty> OK... let me figure out how to start the meeting...
13:06 < rusty> #startmeeting
13:06 < lndev-bot`> rusty: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'
13:06 < lndev-bot> rusty: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'
13:06 < rusty> #startmeeting Not the marketing committee
13:06 < lndev-bot`> Meeting started Mon Sep 13 20:06:20 2021 UTC and is due to finish in 60 minutes.  The chair is rusty. 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 'not_the_marketing_committee'
13:06 < lndev-bot> Meeting started Mon Sep 13 20:06:20 2021 UTC and is due to finish in 60 minutes.  The chair is rusty. 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 'not_the_marketing_committee'
13:06 < niftynei> two bots for the price of one, of this is exciting
13:06 < cdecker[m]> Hurray
13:06 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Quit: Ctrl-C at console.]
13:07 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/834
13:07 < cdecker[m]> Stopped one of them, I think it was trying to make up for last time
13:07 < niftynei> looks like  lndev-botimous prime has been chosen as the survivor lol ;)
13:08 < cdecker[m]> Shouldn't matter, logs and agenda will still work
13:08 < t-bast> Go #834, go! I think it's high time this gets merged, we've seen it being useful many times already in the real world (just found a c-lightning issue today thanks to it)
13:08 < rusty> OK, I can rebase this.  roasbeef mentioned wanting a feature bit, which in this case seems overkill (you can always still send an erorr)
13:08 < BlueMatt> I think the only thing left to resolve on warnings is https://github.com/lightningnetwork/lightning-rfc/pull/834#discussion_r702330608 ?
13:09 < BlueMatt> oh, wait, no, still need to resolve the removal of the all-0s error message
13:09 < BlueMatt> and whether we want to do that
13:10 < BlueMatt> thoughts?
13:10 < roasbeef> see my comment on that other PR: there was a new change that depended on this new warning message, but in that case how is the peer meant to even know to expect the warning message if there's no feature bit? 
13:11 < roasbeef> I don't understand this new aversion to feature bits
13:11 < rusty> BlueMatt: yes, I believe you're the only one to support it, and I think you fail them one at a time as reestablish is sent,
13:11 < roasbeef> unless you always send the warning _and_ error in all scenarios? 
13:11 < t-bast> I'm very neutral on whether we should keep all-0s error message or not, I don't mind either way
13:11 < BlueMatt> the peer cant "expect a warning message", warning messages are required to be "ignored"
13:11 < roasbeef> still as is, I don't really see what this PR does 
13:11 < roasbeef> it's just the old error message w/ a new name 
13:11 < rusty> BlueMatt: but if they don't set the feature, you can ignore errors more.
13:11 < BlueMatt> rusty: ok, let me rephrase, I think we should *add* an all-0s error message :)
13:12 < t-bast> roasbeef: it's an odd message, they've been explicitly created to allow optional things that you don't need to support, there's really 0 reason to have a feature bit for warning messages
13:12 < rusty> BlueMatt: OK, I disagree.  It's another implementation details which won't be implemented.
13:12 < BlueMatt> why wouldn't you implement it?
13:12 < BlueMatt> that's a useful way to say "go away, close the channels, I'm not gonna talk to you anymore"
13:12 < BlueMatt> without having to have a reconnect loop
13:12 < roasbeef> comment re PR: https://github.com/lightningnetwork/lightning-rfc/pull/904#issuecomment-909815114 
13:12 < rusty> BlueMatt: I haven't yet.  I never send such a thing, and I can't see why I would.
13:13 < t-bast> roasbeef: it helped a lot figure out many bugs in the wild already on our side, so I'd say it has already proven its worth as-is
13:13 < roasbeef> so rather than use the explicit feature bit dep system we built in, we now rely on implicit TLV deps? 
13:13 < BlueMatt> roasbeef: I believe your comment there, really, is more about quick close feature bit, less about warning message feature bit
13:13 < rusty> I agree with roasbeef, we should use a feature bit.  And if set, that means errors are *errors*, are genuinely unrecoverable, and you should really drop to chain.
13:13 < roasbeef> BlueMatt: no it's about both, the quick close depends on the warning message the way it's written, and we have a natural way to indicate dependent protocol features: the feature bit deps 
13:14 < niftynei> rusty: "close all channels" is probably more useful if there's more than one channel btw peers :P
13:14 < BlueMatt> rusty: ah, as a backwards compat for the implementations that always ignored errors?
13:14 < rusty> (And we can drop all our "wait, this is a spurious error, reconnec and try again" logic)
13:14 < BlueMatt> roasbeef: outside of the scope of quick close, is there ever a reason why you'd seek out a peer that will send warning messages?
13:14 < rusty> BlueMatt: yeah, e.g. LND used to send an error if you were too slow to handshake, and we used to close channels...
13:14 < t-bast> Agreed with BlueMatt, we can argue about whether quick close needs a feature bits, but warning messages are really optional messages you're free to ignore but that may help you diagnose issues in the wild, and that doesn't need a feature bit at all, that's why we split messages in odd vs even
13:14 < roasbeef> t-bast: bugs related to the warning message? or bugs in new feature that assume the warning message? 
13:15 < BlueMatt> I do think rusty has a point here, though, I would be in favor of a feature bit that means "yes, errors are errors, follow the spec, stop ignoring them"
13:15 < t-bast> roasbeef: bugs in new and old features that now include warning messages which help us figure out what's wrong on the other side
13:15 < rusty> t-bast: I disagree, I'd really like to get rid of the cases where c-lightning ignores errors because implementations used to send them.
13:15 < roasbeef> t-bast: figruing it out is all manual tho right? given you have no way to programmatically handle the new message as it's just a string? 
13:15 < BlueMatt> rusty: re: all-0s, I guess I'm still vaguely of the thinking that reconnect loops absolutely suck, and we should stop throwing our hands up and assuming they're ok.
13:16 < roasbeef> in which cases would the warning message help you uniquely dianose something that the existing error message would't? 
13:16 < BlueMatt> roasbeef: yes, because unlike error messages, warning messages dont close the channel.
13:16 < t-bast> rusty: we still don't ignore errors and don't plan on starting to ignore them
13:16 < BlueMatt> t-bast: do y'all implement the all-0s close-all-channels error logic?
13:17 < rusty> t-bast: ouch, we had several cases we had to, to avoid forced closing.  Maybe safe to remove them now...
13:17 < roasbeef> BlueMatt: re why would seek them out, assuming it has error codes, then yeah as you're able to programtically handle certain denegrate cases, and also know that you have strucutred data in the errors 
13:17 < t-bast> roasbeef: even manual, it's a net improvement compared to what we had before, that's the best argument I can have for a feature - it solves a problem we actually have, not a theoretical one
13:17 < roasbeef> but it's less about seeking them out, and making it explicit that two protocol features are dependent on each other 
13:17 < roasbeef> this is the PR that adds that dep btw: https://github.com/lightningnetwork/lightning-rfc/pull/904 
13:17 < BlueMatt> roasbeef: I'd understand if you added a feature bit for when warnings got a programatic handling support, but that's not what we're talking about here
13:18 < BlueMatt> roasbeef: the warning messages in this pr *MUST* be ignored
13:18 < BlueMatt> roasbeef: we can revisit the feature bit discussion when y'all add the "programatic why we warned" logic in the tlv
13:18 < t-bast> BlueMatt: we did have the close-all-channels on all-0s error, but we may have removed it recently, I'll need to check
13:18 < roasbeef> BlueMatt: which PR #904? 
13:19 < BlueMatt> roasbeef: no, 834. 904 would again be a conversation about quick close feature bits, which seems separate from just warning messages?
13:19 < roasbeef> yeah we're moving forward w/ the TLVs on our end, likely just in the old error message though, given the warning message is identical 
13:19 < BlueMatt> roasbeef: I mean error already has programatic handling assigned to it - close the channel.
13:19 < niftynei> but it's not identical
13:19 < roasbeef> must be ignored? totally confused 
13:19 < BlueMatt> roasbeef: not sure what else you'd want to add?
13:20 < BlueMatt> the current warning message, because it has nothing but a string, must be ignored from a logic perspective. you can go log it, tell the user, whatever, but you can't *do* something
13:20 < roasbeef> the close channel clause is essentially deprecated, no one does it 
13:20 < t-bast> rusty: yeah I think nowadays you shouldn't have too may issues re-activating the logic of force-closing when you receive an error, it's not biting us at all on our node
13:20 < BlueMatt> roasbeef: we do it, eclair does it, and c-lightning is planning on doing it, maybe with a feature bit
13:20 < BlueMatt> so, no, its not deprecated
13:20 < t-bast> rusty: it was an issue at some point and we've had unwanted channel closure, but it's gotten much better in the last 12 months to be honest
13:21 < BlueMatt> I've *never* seen an unwanted channel closure as the result of an error message, fwiw :)
13:21 < roasbeef> it's ill advised imo, which is why it never really caught on 
13:22 < rusty> roasbeef: wait, t-bast just said they're force-closing on all errors.  I double-checked c-lightning, we gave up and are ignoring all errors :(  We reconnect though
13:22 < t-bast> BlueMatt: you arrived on mainnet at the right time, after the nastyness happened xD
13:22 < BlueMatt> t-bast: I'm aware
13:22 < BlueMatt> roasbeef: its ill advised to tell your peer that you're broadcasting the local state? that just seems like an incredibly helpful and nice thing to do.
13:22 < roasbeef> rusty: so then just eclair force closes?
13:22 < t-bast> roasbeef: yes, when we receive an error we do
13:22 < roasbeef> BlueMatt: you can do that w/ an error message, but doesn't mean they need to force close 
13:22 < rusty> roasbeef: and LDK it seems.
13:23 < roasbeef> say "I broadcasted btw, it's in the mempool" is totally useful, but rn we don't have a way to allow nodes to properly handle that, since it's just a string 
13:23 < BlueMatt> roasbeef: sure, I mean they dont have to broadcast, but its a really great way to say "dont try to route over this again, dont expect me to accept anything, you should give up on this channel"
13:23 < roasbeef> lnd doesn't watch the mempool though, so we'll only note that once it hits the chain 
13:24 < roasbeef> yeh that sounds useful, but we don't have a way to do that atm w/ just the string 
13:24 < BlueMatt> yes, we do have a way to tell a node that, the error message!
13:24 < BlueMatt> sending an error message with a channel_id set is *exactly* that, according to the spec, and the way eclair and LDK have implemented it
13:24 < BlueMatt> I understand historically that was not practical, but those nodes hardly exist anymore.
13:24 < rusty> I think warning is still useful, as there are cases which are recoverable (esp since reconnection does reset some state).
13:24 < BlueMatt> now, as an alternative to the current warning message pr, we *could* swap the message types
13:25 < rusty> But yes, you have to avoid looping too hard.
13:25 < BlueMatt> ie define a new "warning" message, with the type of current error, and then add a *new* error message
13:25 < BlueMatt> the new error message would have the semantics of error as-define, but not lnd/c-ln implemented.
13:26 < niftynei> do the msg type support that?
13:26 < BlueMatt> hmm?
13:26 < niftynei> isn't error msg a mandatory msg bit
13:26 < BlueMatt> probably, but its not like there are any implementations that *dont* understand it
13:27 < BlueMatt> like, yes, we'll redefine it to "you must understand how to deserialize this, but also you must then ignore it"
13:27 < niftynei> ah no it's 17
13:27 < BlueMatt> oh, even better
13:27 < niftynei> that sucks though from an implementation/upgrade standpoint
13:27 < BlueMatt> it does
13:28 < BlueMatt> but i suggested it as roasbeef seemed insistent on error messages being ignored going forward
13:28 < BlueMatt> but now roasbeef stopped responding :/
13:28 < rusty> That seems like a backward step.  Here are a short list of where we currently send a warning (and reconnect):
13:28 < niftynei> like .. sometimes warning messages are fatal and other times they aren't, depending on what version of CL you're talking to? idk
13:28 < roasbeef> no not that they should be ignored
13:28 < t-bast> to be fair, I get the feeling that roasbeef you're completely dismissing this PR on principle because you'd like something else (error codes automated *some* scenarios), which feels to me very orthogonal and can be done separately
13:28 < roasbeef> they're useful, we've used them to debug invalid sig issues in the past 
13:29 < roasbeef> no I'm not, I'm just saying I don't find it useful really as is, and we prob won't implement it, ofc ppl can deploy it or w/e 
13:29 < roasbeef> we're following thru w/ our error codes thing, since it solves a buncha problems for us 
13:29 < niftynei> but your reason for finding it "unuseful" is that ... you've never enforced the semantics of errors meaning "close the channel"??
13:29 < roasbeef> maybe we'll bLIP it, since everyone doesn't think error codes are useful 
13:29 < t-bast> it's already been useful for us many times in the wild, and feels like a net improvement that requires like 20 lines of code, so I'd really like to see it happen... 
13:30 < niftynei> i mean honestly, it sounds like LND is in favor of upgrading all their error messages to warnings?
13:30 < niftynei> to match your current behavior to the spec
13:30 < BlueMatt> roasbeef: sheesh, no one is saying error codes are *not* useful
13:30 < BlueMatt> roasbeef: please stop putting words in others' mouths
13:30 < roasbeef> sure, seems you've already implemented it, but the lingering question re the dep w/ it and the quick close thing stands: if nodes don't impl warning, they can't do quick close or the other way around? 
13:30 < rusty> - various experimental things (malformed STFU message, etc).
13:30 < rusty> - short_id mismatch in announcement_signatures
13:30 < rusty> - almost any malformed message (e.g. update_htlc which we can't decode)
13:30 < rusty> - unable to add htlc for any reason
13:30 < rusty> - update_fee from non-opener
13:30 < rusty> - update_fee unreasonable
13:30 < t-bast> I'm interested in the error codes as well, and would love to see a PR for that, but it feels completely additive to warnings to me, if we have both I'd be very happy
13:30 < roasbeef> idk that was said pretty plainly in #834
13:30 < BlueMatt> roasbeef: people have given you *feedback* on error codes, and suggested its a great thing to add as a tlv in a warning message, adding new logic to how you have to handle them
13:31 < roasbeef> maybe we should move onto something else? 
13:31 < BlueMatt> roasbeef: and also said that warnings are useful on their own, and error codes are a nice extension, thus we should move forward with warnings then add stuff on top
13:31 < roasbeef> this has taken up a lot of time
13:31 < t-bast> roasbeef: of course they can do quick close without it, and that's a completely separate discussion...?
13:31 < BlueMatt> I'm not really sure how you have so misinterpreted the feedback given there.
13:31 < roasbeef> t-bast: but then #904 would need to be modified right? since it says send a warning if the quick close fails? 
13:32 < t-bast> roasbeef: no, it's just that it's *nicer* with a warning, it's a small improvement
13:32 < BlueMatt> roasbeef: did you see my comment at https://github.com/lightningnetwork/lightning-rfc/pull/904#issuecomment-911982144 ?
13:32 < t-bast> roasbeef: doesn't *require* it at all
13:32 < BlueMatt> I tried to explain it a bit more verbosely
13:33 < rusty> OK, I think we're in circles now.
13:33 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/906
13:33 < roasbeef> updated to bit 44/45
13:34 < rusty> I agree with roasbeef here, but I think the right semantic is "if you don't negotiate this, don't quickclose, if you do, you must"
13:34 < BlueMatt> rusty: this isnt about quickclose, this is channel type?
13:34 < rusty> Oops.
13:34 < t-bast> xD
13:34 < roasbeef> quick close was merged iirc 
13:35 < roasbeef> this is chan type feature bit 
13:35 < t-bast> I agree that the argument stands for both, you can argue that channel_type needs a feature bit, and you can use the same argument to say that quick close does as well
13:35 < rusty> I agree with roasbeef here, but I think the right semantic is "if you don't negotiate this, ignore channel_type and use default, if you do, you must send and use it"
13:35 < BlueMatt> feature bit for channel type seems like it would make the logic simpler, but I dunno if I get to have an opinion cause I haven't implemented it yet :)
13:36 < t-bast> TBH if you feel strongly about having a feature bit here, I don't mind. If we do, I agree with rusty that the condition must be updated
13:36 < rusty> (I actually think quickclose is a stronger candidate for feature bit, but that's separate)
13:36 < roasbeef> the way I see it, for features like this, we all prob have a config flag or build flag to be able to test versions of the software w/ and w/o it in our integration tests right? so this is just another conjunction there 
13:36 < BlueMatt> tho i guess i dunno i dont care either way, and maybe it is more complicated? whatever.
13:37 < BlueMatt> roasbeef: no, we dont for most of this stuff, we just edit the message being delivered in testing to simulate older peers
13:37 < roasbeef> I think this whole saga has shown also we don't really have a strict criteria of when feature bit or not, maybe has been muddied by newer TLV fields in messages 
13:37 < t-bast> That's really not an area I think is worth fighting for on my end, I don't think it solves what you think it does (because you can't just make it mandatory when you want to migrate to it because you have connected peers with channels that still may not support it)
13:37 < BlueMatt> so thats probably some of why I see these flags as spurious in some cases
13:37 < roasbeef> which is where some of this ambiguitiy is 
13:37 < t-bast> But if it solves an issue for you, I'm happing to add a feature bit
13:37 < roasbeef> BlueMatt: do you then remove the older logic from the client?
13:37 < rusty> roasbeef: yeah, basically we would always send it, we'd just on recv do: if (negotiated(option_channel_feature)) { if (!tlvs->channel_type) fail } else { tlvs->channel_type = NULL' }
13:38 < BlueMatt> roasbeef: no, but we can simulate talking to an old peer whether there is a feature bit or not. so we can test old logic just fine with or without a feature bit
13:38 < BlueMatt> actually, we can test *easier* without a feature bit
13:38 < BlueMatt> one less thing to deal with
13:38 < roasbeef> you do the same even for stuff like ensuring you can open non-anchor channels after that's default? 
13:39 < BlueMatt> of course my or your particular test infrastructure isn't a great reason to have a feature bit or not, imo, but whatever
13:39 < rusty> One nice feature of a feature bit is that when you make it compulsory your logic gets simpler.
13:39 < roasbeef> BlueMatt: not saying that should be the reason, but was a respone to "it's an extra if statement" 
13:39 < roasbeef> rusty: +1
13:39 < t-bast> rusty: it's true that you can remove some code, but only if you also remove the option for your users to switch from mandatory to optional...
13:39 < rusty> t-bast: eventually, yeah.
13:39 < t-bast> rusty: we haven't dared do that yet (even though we'd love to start doing it soonish)
13:40 < BlueMatt> roasbeef: yea, again, all of our tests deal with unencrypted messages to be delivered, so we can do ~whatever we want in our protocol tests.
13:40 < roasbeef> we tried to do it for static remote key, but that didn't really work, hence the need for the chan type stuff in the first place 
13:40 < rusty> Yeah, lnprototest tests this now (it assumes you allow downgrade, which we explicitly will not once static_remotekey becomes compulsory)
13:41 < roasbeef> BlueMatt: ah interesting, but was referring to stuff more like how the chain  handling conditions change for a peer due to diff chan types, stuff like the csv delay as an example changes, but maybe we just have really diff test set ups 
13:41 < roasbeef> or like being able to parse the old onion format 
13:41 < rusty> roasbeef: yes!!  Can we just kill legacy already?
13:41 < t-bast> roasbeef: how do you plan on using a channel_type feature bit if you have channels with a peer that doesn't support it (when you want to start making it mandatory)?
13:42 < roasbeef> rusty: legacy as in non static key? yes pls, I think the eclair version that supports static key is out now?
13:42 < crypt-iq> i think he meant legacy onion
13:42 < t-bast> roasbeef: as usual, not eclair, eclair-mobile only doesn't support it
13:42 < rusty> Anyway, I think there's agreement on this, but I want to reformulate it to:
13:42 < rusty> Sender: - if negotiated:
13:42 < rusty>    - MUST set channel_type.
13:42 < rusty> ... Receiver:
13:42 < rusty> - if negotiated:
13:42 < rusty>   - if channel_type not set, MUST fail
13:42 < BlueMatt> roasbeef: yea, if we force the messages to indicate old channel type, then we're testing an old channel type and then can test all the transactions against that :) I think we do have just very fundamentally different tests as a library that exposes messages vs a whole software program :)
13:43 < rusty> Happy to do that on-issue though.  Shall we move on?
13:43 < roasbeef> t-bast: so i think we'd need to continue to sidestep the issue w/ setting required bits for chan types w/ the old peer, but once they signalled this bit it wouldn't be an issue 
13:43 < BlueMatt> rusty: yes, lets move on
13:43 < roasbeef> rusty: sgtm
13:43 < roasbeef> the feature bit name spacing we have rn is a lot better than the OG, but there're still some leaks like that imo t-bast 
13:44 < t-bast> roasbeef: but if they never do? You'll keep accepting channels that dont use the channel type mechanism...so you'll want to eventually kick them out by making it mandatory and closing channels with them? Otherwise they'll keep opening new channels that don't use the feature
13:44 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/894 and 905
13:44 < roasbeef> t-bast: yeah, so we'd need to reject them, or purposefully downgrade like we do now w/ older eclair nodes -- would rather not downgrade, so we'd prob jsut reject them all 
13:45 < BlueMatt> roasbeef: hwats your thoughts on the options at https://github.com/lightningnetwork/lightning-rfc/issues/905 ?
13:45 < t-bast> roasbeef: ok, I don't really know how to handle the "now we close all channels with a peer because they don't support one of our mandatory features" and communicate it to node operators
13:45 < rusty> Pick a number, please, and I'll implement it :)  I admit I've been absent on this issue
13:45 < BlueMatt> specifically option 2, which t-bast and I suggested, and which I've implemented
13:46 < t-bast> Oh yeah for this dust limit thing, please spend a bit of time reading the issue, and be convinced with option 2 that basically says that while in practice option 1 is cleaner, it's really a lot of unnecessary hassle :D
13:46 < roasbeef> t-bast: not saying close, we just wouldn't let them open any new ones, the way I see it tho, all new types would just use this and we can even add an explicit feature bit dep on it 
13:47 < roasbeef> I think we have an impl of option 1 w/o the bit, as it was just teasing out the changes somewhat 
13:47 < roasbeef> 2 is def easier...and I guess theo nly ppl on the blast radius are those that used a non-segwit addr for upfront shutdown 
13:47 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection]
13:47 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev
13:47 < t-bast> I just wanted to raise awareness on this, and on the fact that I think #894 can be merged as-is independently of #905 (which we can argue on the issue directly, and I'll open a PR once I've gathered enough feedback / rough consensus)
13:47 < BlueMatt> right, that plus happen to close with a very low value
13:47 < BlueMatt> *and* have a low dust limit, which i think basically no nodes use today
13:47 < t-bast> roasbeef: ok, that's a good alternative, I'll think about it
13:48 < BlueMatt> so I'm not sure there's *anyone* in the blast radius for #2, actually
13:48 < rusty> Yeah, let's just ban non-sw closes, and grandfather in non-sw for upfront, iff dust limit high enough?
13:48 < crypt-iq> i think it may be good to explicitly state in the spec that both channel reserves need to be above both dust limits, which i dont think is explicit
13:48 < BlueMatt> rusty: that's basically what option 2 is, except with not just dust limit, but only the payout value at close
13:48 < rusty> Yeah, I'm not sure anyone will notice.  For us, if we do this and you ry to shutdown to non-sw, we'll warning you and hangup, then you can try again
13:48 < t-bast> BlueMatt: I tested on our node, we do have people closing to non-segwit, but none ever ran into that case where it would have lead to a force-close. So I feel pretty safe with option #2
13:48 < rusty> BlueMatt: ack, I misspoke.
13:49 < BlueMatt> t-bast: well, my point here is also that no one currently *sets* a dust limit too low for non-segwit closes
13:49 < BlueMatt> t-bast: in order for a node to get a force-close here they have to (a) have a dust limit at 330, and (b) use non-segwit close
13:49 < BlueMatt> or 354 i guess
13:49 < t-bast> BlueMatt: yes, but I tested even if they did, we never had a shutdown that would have run into this :)
13:49 < BlueMatt> (b) is true, but (a) I think basically isnt
13:50 < BlueMatt> right, and (c) actually close with a <540 sats output
13:50 < BlueMatt> so its ~nothing imo
13:50 < t-bast> Great, so if there's rough consensus about option 2, I'll open a PR for that
13:50 < t-bast> #action t-bast to open a PR for option 2 of issue 905
13:50 < roasbeef> jeremy was right, dust sucks, we should just elminiate it 
13:50 < roasbeef> kek
13:50 < rusty> roasbeef: lol
13:51 < BlueMatt> lol
13:51 < t-bast> Or should I do it in a new commit in #894? Or merge #894 as-is?
13:51 < t-bast> roasbeef: xD
13:51 < ariard> i think #894 is mergable?
13:51 < BlueMatt> if we move forward with #2, I think we should mention in 894 that the dust limit is 354
13:51 < rusty> Yep...
13:51 < BlueMatt> i guess i dont care if its a followup
13:51 < BlueMatt> but it seems a waste
13:51 < BlueMatt> I'll leave it up to the author, the changes themselves there are fine
13:51 < roasbeef> 894 mentions 354 iirc 
13:51 < niftynei> is it 354 or 330?
13:52 < roasbeef> fine w/ 894 as is 
13:52 < BlueMatt> roasbeef: it does not say that the dust limit that nodes *MUST* check for is 354
13:52 < roasbeef> ahh good ol dust arithmetic
13:52 < BlueMatt> it mentions it is a dust limit
13:52 < BlueMatt> niftynei: 354 is anysegwit, 330 is segwit-taproot/v0
13:52 < niftynei> oic you're using the highest of segwit dust options, gotcha
13:52 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/895
13:52 < t-bast> niftynei: 330 is for p2wsh but 354 is the max dust limit for all segwit versions, so it's a safe way to encompass all segwit
13:52 < niftynei> ty for the explanation t-bast!
13:53 < rusty> roasbeef: the self-assignment of fake ids, I don't think it's a problem.  I set my own aliases, so I make sure they don't clash.
13:53 < BlueMatt> rusty: you opened a replacement for this today, no?
13:53 < t-bast> I'll add a commit on #894, no need to rush merging that PR
13:54 < BlueMatt> https://github.com/lightningnetwork/lightning-rfc/pull/910
13:54 < roasbeef> rusty: yeh you can set your down, but unless I'm missing something, a collision can still happen which makes how you act based on info the onion ambiguous right? Alice and Bob both say their scid is 10, you get an HTLC from dave that wants to route thru scid 10, what do you do?
13:55 < rusty> roasbeef: you tell Alice and Bob what their scids are.
13:55 < roasbeef> if we say, you gotta reject any collisions (you force a conneciton recycle?) then it works 
13:55 < BlueMatt> roasbeef: the scid aliases are unidirectional
13:55 < rusty> roasbeef: they tell you what they will use for HTLCs coming *from them*, sure.
13:55 < roasbeef> rusty: only if you're the funder of both? 
13:55 < rusty> roasbeef: both sides give *different* aliases.
13:56 < cdecker[m]> Or we could make them deterministic, i.e., last 8 bytes of the funding txid
13:56 < BlueMatt> B tells A what scids A can put in invoices that B will use to forward from C. B cannot put that same scid in their own invoices as A only uses it for inbound from B, not relaying to
13:56 < rusty> You only need to know what scid they'll use when writing routehints for bolt 11.
13:57 < rusty> I tell Alice to use 10, Bob to use 11.
13:57 < roasbeef> ah ok, I had the like responsibilities flipped 
13:57 < roasbeef> make sense now...I think
13:57 < rusty> Yeah... so BlueMatt wanted this to be a universal alias mechanism, not just a zeroconf open.  That's kinda different enough that I opened a competing PR.
13:57 < roasbeef> ok now 895 vs 910? 
13:58 < t-bast> What exactly is the difference between the two PRs? Only the explicit mention of using the channel for the `push_msat` amount?
13:58 < roasbeef> t-bast: I think 910 carves out the scid thing for more general usage? 
13:58 < BlueMatt> rusty: I have a hard time implementing it as *not* a universal alias mechanism
13:58 < t-bast> ok, interesting
13:58 < BlueMatt> like, I dont think you can implement it without it accidentally being one, so might as well make it explicit
13:58 < roasbeef> t-bast: so like the thing where ppl can use random stuff in the hop hints and not give away on-chain info 
13:58 < BlueMatt> and its kinda cool to have anyway
13:58 < rusty> t-bast: 910 means you *always* get given an alias if you support this, even if you have a public channel, even if you don't intend to use it before conf.
13:59 < t-bast> Great, that sounds cool
13:59 < crypt-iq> now you have to maintain a mapping of all scids for a channel -> channel?
13:59 < rusty> i.e. you "funding locked" (now a misnomer, but whatev) immediately with some alias value.  You probably still fail incoming payments until confirmed, unless you trust.
14:00 < t-bast> I agree with BlueMatt on his comment about the `next_commitment_point` though, it can be misleading: if you send `funding_locked` at any time, what value do you put in here? Especially if you may send `funding_locked` in parallel to commitment updates?
14:00 < rusty> crypt-iq: yes, another alias.
14:00 < BlueMatt> crypt-iq: the sender has to maintain all the mappings they sent. the recipient only has to maintain one.
14:00 < BlueMatt> t-bast: its made a bit clearer in the latest pr, but the text as-is in the spec i think is clear enough, as long as we all agree
14:00 < rusty> t-bast: yeah, we could rename that field to commitment_point_1 or something.
14:00 < rusty> And agreed, it's redundant, but it's also simple.
14:01 < BlueMatt> it says "MUST set `next_per_commitment_point` to the per-commitment point to be used for the following commitment transaction, derived as specified in"
14:01 < BlueMatt> which is reasonably clear
14:01 < BlueMatt> I think
14:01 < BlueMatt> but worth confirming/pointing out
14:01 < crypt-iq> the short channel id field is 8 bytes long, chance of collision is 2^32 ?
14:01 < t-bast> rusty: ok, if it's the first commitment_point then that's all good
14:01 < roasbeef> woah, so 901 lets you just continue to send a new funding_locked to update the alias?
14:01 < roasbeef> like after normal chan operation has started?
14:01 < rusty> roasbeef: yeah, BlueMatt wanted that.  I won't be doing that, since you gotta respect all aliases ou gave out, forever.
14:02 < t-bast> I think what rusty and BlueMatt are saying for the commitment_point here is contradictory? Or am I understanding it wrong?
14:02 < rusty> And ofc I can just keep using the first alias.
14:02 < BlueMatt> t-bast: heh, yes, it seems we are now.
14:02 < t-bast> Rusty you're saying it should always be your initial commitment_point, BlueMatt is arguing the PR says it's the next one (which may be commitment_point N)?
14:02 < rusty> BlueMatt: it's no longer clear if you have sent commitment_signed already, which was previously not possible.
14:02 < BlueMatt> t-bast: to be fair, it doesnt matter which, we just gotta pick :)
14:03 < t-bast> I think always sending the initial one here is the simplest, as you don't actually use it (except for the first `funding_locked` you receive)
14:03 < BlueMatt> I'll let the author of the pr select one and clarify it in the pR :)
14:03 < rusty> t-bast: exactly.
14:03 < t-bast> ACK then
14:03 < t-bast> It needs to be clarified in the PR though, it's easy to misinterpret
14:04 < rusty> t-bast: agreed, good catch BlueMatt
14:05 < rusty> #action Rusty to fix PR to clarify next_per_commitment_point is #1 in #910
14:05 < rusty> OK, so is 910 the winner over the "just for trusted zeroconf" 895?
14:05 < BlueMatt> after thinking about it more, I dont feel super strongly, fwiw, about the ability to send the message over and over with new aliases, I think its cool and we might as well, cause the cost from 1 to many is low and there are use-cases for having many, but I do think we should include the text about always sending an alias cause that's important
14:06 < BlueMatt> the temporal shift over time of the scid alias i think is less useful than just having a pool, but in any case all of those details are up to the sender + recipient, the spec is generic
14:06 < t-bast> At first glance, it does look like a winner IMO. pm47 will review both on our end, I'll ask him to chime in this week.
14:06 < rusty> Yeah, I am tempted to upgrade the "- SHOULD initially set `alias` to value not related to the real `short_channel_id`." to "- MUST initially set `alias` to value not related to the real `short_channel_id`."
14:06 < roasbeef> yeh seems to work, can also ask the breez ppl to take a look at it, but I think it lines up w/ what they already do (they can keep their current scid generation scheme) 
14:06 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:fd36:4476:689:b677] has quit [Quit: Client closed]
14:07 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:fd36:4476:689:b677] has joined #lightning-dev
14:07 < t-bast> good idea to have breez take a look as well, the more reviews the merrier
14:07 < niftynei> does adding aliases here mean that there's other proposals for aliases that are now superceded?
14:08 < rusty> Oops, we need a feature bit for this!
14:08 < t-bast> Are there other proposals for aliases?
14:08 < BlueMatt> yes, feature bit for this is useful :)
14:08 < rusty> *If* you undersand this, we need to *not* route via the real scid for private channels, otherwise probing is still a thing.
14:08 < roasbeef> t-bast: iirc y'all had an older one a few years ago? 
14:09 < rusty> (And if you don't, we need to, since you don't know about the alias)
14:09 < niftynei> yeah this feels similar to something else but i cant remember exactly. it's not important
14:09 < t-bast> roasbeef: on the contrary, I fought against rusty's alias proposal and instead proposed route blinding, which I don't think clashes with this proposal :)
14:09 < BlueMatt> rusty: good point, yea
14:09 < mschmoock> rusty: +1
14:09 < roasbeef> t-bast: ah yeh route blinding 
14:09 < rusty> Yeah, routeblinding is a superset, but more ambitious.  THis is a minfix.
14:10 < rusty> #action rusty update #910 to add feature bit, make routing via non-announcable real scids invalid if negotiated.
14:11 < rusty> Oh, that means it's a channel_type, since we gotta remember whether we negotiated that bit at open...
14:11 < BlueMatt> so we're way over time, are there any short things to tackle?
14:11 < mschmoock> mission creep :D
14:12 < rusty> https://github.com/lightningnetwork/lightning-rfc/pull/898 ?  I think it just needs acks?
14:12 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/898
14:12 < BlueMatt> I've acked, we merged the chnages already
14:13 < rusty> #action rusty to validate https://github.com/lightningnetwork/lightning-rfc/pull/898
14:13 < t-bast> Thanks! And we should be done with Bolt 11 test vectors for a small while 
14:13 < rusty> Actually, with BlueMatt and t-bast, that's enough to merge.
14:13 < t-bast> yay!
14:14 < rusty> I rpropose we merge, and stragglers like me can catch up...
14:14 < rusty> Any objectsion?
14:14 < t-bast> But if you plan on validating the test vectors, no need to rush we can wait to see if you find an issue we missed
14:14 < roasbeef> test vectors good 
14:14 < t-bast> Whatever you'd like
14:14 < rusty> #action t-bast to merge https://github.com/lightningnetwork/lightning-rfc/pull/898
14:14 < rusty> OK, I think we're done!
14:14 < t-bast> Neat, thanks guys!
14:14 < rusty> #endmeeting
14:14 < lndev-bot`> Meeting ended Mon Sep 13 21:14:57 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:14 < lndev-bot`> Minutes:        https://lightningd.github.io/meetings/not_the_marketing_committee/2021/not_the_marketing_committee.2021-09-13-20.06.html
14:14 < lndev-bot`> Minutes (text): https://lightningd.github.io/meetings/not_the_marketing_committee/2021/not_the_marketing_committee.2021-09-13-20.06.txt
14:14 < lndev-bot`> Log:            https://lightningd.github.io/meetings/not_the_marketing_committee/2021/not_the_marketing_committee.2021-09-13-20.06.log.html
14:15 < t-bast> There are a few items we didn't have time to cover, if you have time to review them during the week it would be great ;)
14:15 < cdecker[m]> Yay, thanks everyone
14:15 < BlueMatt> thanks y'all
14:15 < rusty> On a personal note, I've been recently a bit shocked how much this little project of ours has grown.  Thanks for all the hard work you've all put in over the years.
14:16 < roasbeef> LN dun come a looong way :D
14:16 < cdecker[m]> Indiddely deed
14:16 < rusty> I know we engineers tend to always look at the giant pile of shit we still gotta implement/fix/etc, but damn, take a moment to feel the wonder.  We're amazing.
14:17 < ryanthegentry> +1000 (as a non-engineer :D  )
14:17 < roasbeef> speaking of all the shit to implement....something something taproot 
14:17 < t-bast> You're right! It's impressive to see it grow that much!
14:17 < ariard> re zurich to the latest news we should have at least 1 dev from the 5 implem present during the week :)
14:17 < niftynei> dope ariard!
14:18 < niftynei> see u all in 2 weeks 
14:18 < t-bast> I do tend to look at the giant pile of things I really want to get done though :)
14:18 < mschmoock> cu
14:18 -!- crypt-iq [~crypt-iq@71.69.230.255] has quit [Quit: Client closed]
14:18 < t-bast> Like something something taproot which will be such a great thing to work on
14:18 < rusty> roasbeef: you're killing my buzz man :)
14:19 < rusty> https://github.com/lightningnetwork/lightning-rfc/pull/911 BTW... I think it makes sense, mschmoock has offered to implement experimental in C-lightning too
14:20 < mschmoock> Its a very simple addition that may be useful to help people rely less on TOR :)
14:21 < t-bast> Gotta go, see you guys, I hope we get to celebrate what lightning is becoming IRL soon! And thanks again for all the impressive collaboration, it's not always easy to follow so many topics but we're doing great overall
14:21 < roasbeef> rusty: heh I've implemented bech32m so far...now just need to finish drawing the rest of the damn owl
14:21 < t-bast> roasbeef: that's the easy part xD
14:21 < roasbeef> need to just go in a cave for a few weeks and ignore all outside communication 
14:22 < t-bast> rusty: BTW we're starting to get serious on offers, we have thomas starting to work on it (you'll notice some new reviews)
14:25 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving]
14:26 < BlueMatt> lmk when you've consolidated the messages spec and I'll try to implement it again :)
14:33 -!- ziggie [~ziggie@user/ziggie] has quit [Ping timeout: 256 seconds]
14:47 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 268 seconds]
14:54 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
14:56 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev
16:23 -!- rusty [~rusty@tro1759202.lnk.telstra.net] has joined #lightning-dev
16:47 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:fd36:4476:689:b677] has quit [Quit: Client closed]
17:20 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:28 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
17:33 -!- belcher [~belcher@user/belcher] has joined #lightning-dev
17:33 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 276 seconds]
17:36 -!- rusty [~rusty@tro1759202.lnk.telstra.net] has quit [Ping timeout: 265 seconds]
17:47 -!- rusty [~rusty@203.221.41.134] has joined #lightning-dev
17:56 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
19:41 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
20:56 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
22:40 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 265 seconds]
23:31 < plank> thank you devs for all the hard work, its much appreciated :)
23:33 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
--- Log closed Tue Sep 14 00:00:07 2021