--- Log opened Mon Aug 16 00:00:39 2021 00:23 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has joined #lightning-dev 00:29 -!- darosior [~darosior@194.36.189.246] has quit [Quit: ya vps net disruption] 00:29 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev 00:30 -!- darosior [~darosior@194.36.189.246] has quit [Client Quit] 00:30 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev 00:38 -!- darosior [~darosior@194.36.189.246] has quit [Quit: darosior] 00:38 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev 00:39 -!- darosior [~darosior@194.36.189.246] has quit [Client Quit] 00:40 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev 00:40 -!- darosior [~darosior@194.36.189.246] has quit [Client Quit] 00:40 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev 00:41 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds] 00:41 -!- darosior [~darosior@194.36.189.246] has quit [Client Quit] 00:42 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev 01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 02:35 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 02:58 -!- emzy [~quassel@user/emzy] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 03:25 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection] 03:25 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev 03:57 -!- belcher_ is now known as belcher 04:21 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 06:13 -!- gene [~gene@2a0a:3840:1337:127:0:b9c1:7fec:1337] has quit [Quit: drained and gutted] 06:13 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 258 seconds] 06:14 -!- emzy [~quassel@user/emzy] has joined #lightning-dev 06:15 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev 06:21 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 245 seconds] 06:38 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev 06:42 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #lightning-dev 06:43 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 240 seconds] 06:47 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev 06:47 -!- lukedashjr [~luke-jr@user/luke-jr] has quit [Ping timeout: 258 seconds] 06:53 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #lightning-dev 06:53 -!- lukedashjr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer] 06:54 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #lightning-dev 06:56 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 245 seconds] 06:57 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev 06:59 -!- lukedashjr [~luke-jr@user/luke-jr] has quit [Ping timeout: 240 seconds] 07:02 -!- emcy [~emcy@user/emcy] has quit [Quit: Leaving] 07:15 -!- emcy [~emcy@user/emcy] has joined #lightning-dev 08:03 -!- aechu [~major@gateway/tor-sasl/major] has quit [Remote host closed the connection] 08:44 -!- _niftynei [~niftynei@2600:1700:d0e:284f:1b33:1445:2689:f9da] has quit [Ping timeout: 245 seconds] 09:22 -!- niftynei [~niftynei@2600:1700:d0e:284f:c4f5:5ae0:b243:f2c8] has joined #lightning-dev 09:38 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed] 09:53 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 10:06 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [] 10:09 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 10:24 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection] 10:24 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev 10:37 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed] 10:43 -!- gene [~gene@gateway/tor-sasl/gene] has joined #lightning-dev 10:43 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 244 seconds] 10:50 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 11:00 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:e0d1:24f:1e78:945b] has joined #lightning-dev 11:26 -!- AaronvanW [~AaronvanW@190.150.148.22] has joined #lightning-dev 11:32 -!- gene_ [~gene@gateway/tor-sasl/gene] has joined #lightning-dev 11:32 -!- gene_ [~gene@gateway/tor-sasl/gene] has quit [Client Quit] 11:33 -!- gene_ [~gene@gateway/tor-sasl/gene] has joined #lightning-dev 11:34 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Remote host closed the connection] 11:38 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 11:52 -!- common [~common@096-033-221-075.res.spectrum.com] has joined #lightning-dev 12:02 -!- gene_ is now known as gene 12:07 -!- abetusk [~abe@68.175.128.91] has joined #lightning-dev 12:48 -!- Crypt-iq [~Crypt-iq@2603-6080-8f06-6d01-b508-bccd-d0ec-ab17.res6.spectrum.com] has joined #lightning-dev 12:48 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev 12:52 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev 12:53 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev 12:56 < t-bast> Hey everyone! 12:56 < niftynei> hello t-bast! 12:56 < niftynei> oh hey, what's this?? 12:56 < niftynei> an agenda for today's meeting? 12:56 < niftynei> https://github.com/lightningnetwork/lightning-rfc/issues/893 12:56 < t-bast> :D 12:56 < niftynei> wow check that out!! 12:56 < t-bast> And it's quite packed! 12:56 < niftynei> 👀 12:57 < ariard> yoooooooo! 12:57 < t-bast> And I even found the time to review both of your big PRs (but I haven't read your answers yet...)! 12:57 < niftynei> good thing we're here a little before the meeting starts, and can check it out 12:57 < ryanthegentry> wassup wassup wassup 12:57 < ariard> damn, the agenda is packed as hell 12:58 < niftynei> t-bast: yes, thank you! i'm halfway thru the first one 🙈 12:58 < niftynei> hello ariard + ryanthegentry ! 12:58 < t-bast> but a lot of these PRs have been long standing, there's probably not much to add apart from "ACK, I'll implement and test" 12:58 < t-bast> so they should be quick :) 12:58 < niftynei> ok so we're T-minus two minutes from meeting start, should we start nominating ppl for the chair in absentia? 12:59 < t-bast> if BlueMatt is around, I'm not sure I 100% understood this comment: https://github.com/lightningnetwork/lightning-rfc/pull/894#issuecomment-899744941 13:00 < cdecker[m]> Heya ^^ 13:00 < t-bast> IIUC, BlueMatt is suggesting to fix this issue in #847 by adding a requirement to respect each output type's dust threshold even if a lower dust_limit was negotiated for the channel 13:00 < BlueMatt> hey 13:01 < BlueMatt> t-bast: my comment is more general about the current spec - it talks about how you can unilaterally skip your own output, but I don't think it really lets you fully 13:01 < t-bast> niftynei: good idea, let's nominate chair, I won't hijack the meeting by jumping to topics right now! 13:01 < BlueMatt> like, it says you can, but then also talks about "if fee is the same, broadcast the transaction, you're done" not "if fee is the same *and* the same set of otputs is included..." 13:02 < niftynei> i need to head out a bit early today, so i'm going to graciously remove myself from the chair-candidate list 13:02 * niftynei looks at valwal 13:02 < valwal> lol hey 13:02 < t-bast> BlueMatt: ok, that makes sense, then using #847 which makes changes to closing_signed to also clarify these dust threshold would probably be a good idea, I'll append a commit for that 13:02 < valwal> i'm not the most up-to-date but i don't mind 13:03 < BlueMatt> t-bast: thanks. its gonna require some thinking about the negotiation if removing an output, i think. 13:03 < t-bast> hey valwal! happy to see you chair ;) 13:03 < BlueMatt> t-bast: actually, I dunno if I'm a fan of doing it in that pr, on second though 13:03 < BlueMatt> its an existing issue, and i want to just fricken land that pr 13:03 < BlueMatt> so maybe we can do it in a new pr based on that pr? 13:03 < valwal> alright alright 13:03 < valwal> do we have quorum? 13:04 < t-bast> BlueMatt: I may be missing something then, I was thinking that we'd just both use as dust limit for the outputs of the mutual close min(channel_dust_limit, spec_dust_limit_for_this_type), wouldn't that work? 13:04 < t-bast> I'll stop hijacking the meeting start, let's discuss that when we get to that topic :) 13:04 < ariard> just before starting, we have discusssed on the LDK-side to attach 2-days of LN spec meeting ahead of the scheduled coredev 13:04 < t-bast> ariard: that sounds great! 13:04 < ariard> as many of us should attend or have been invited to coredev 13:04 -!- Lucas62 [~Lucas@2804:431:c7d8:1f99:c34:4c48:1fa8:2a5f] has joined #lightning-dev 13:04 < niftynei> we've got Crypt-iq and ryanthegentry from labs; ariard, valwal + BlueMatt from LDK; niftynei + cdecker[m] from cl; t-bast from eclair... 13:04 < jkczyz> valwal: hit the gavel 13:04 < valwal> #startmeeting meeting-name 13:04 < lndev-bot> Meeting started Mon Aug 16 20:04:59 2021 UTC and is due to finish in 60 minutes. The chair is valwal. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:04 < lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:04 < lndev-bot> The meeting name has been set to 'meeting_name' 13:05 < valwal> #topic warnings 13:05 < ariard> t-bast: yeah and i've discussed with other coredev orgas and they're okay to distribute more LN-invits :) 13:05 < BlueMatt> valwal: you gots to startmeeting 13:05 < BlueMatt> with the #s 13:05 < niftynei> she did! lol 13:06 < niftynei> i think we're on topic "warnings" 13:06 < BlueMatt> I left a number of comments on the pr 13:06 < BlueMatt> so waiting on those to be responded to 13:06 < BlueMatt> t-bast: commented as well, and i think we agreed on some proposed changes 13:06 < t-bast> Sounds like rusty needs to rebase and address comments 13:06 < BlueMatt> further, the pr needs to be rebased 13:06 < t-bast> But generally it's a concept ACK, right? 13:06 < BlueMatt> so i think its basically a "waiting on rusty to respond" thing 13:06 < valwal> ok 13:07 < valwal> #topic channel_type s 13:07 * rusty wakes up 13:07 < valwal> oh hey rusty! 13:07 < t-bast> hey rusty! 13:07 -!- Lucas62 is now known as ldecferreira 13:07 < BlueMatt> yea, def concept ack here, iirc lnd even has a pr to implement it 13:08 < rusty> OK, I will respond on PR. I basically plastered advice over everywhere we said you MUST erorr, wherever it was theoretically psosible to recover, said you MAY send warning. 13:08 < rusty> (You can still send error! And if you've closed, of course you should) 13:08 < BlueMatt> yea, the LDK implementation of the warnings message stuff that I pr'd largely ignored half of the error -> warning changes, since I'm not a fan of them and needs discussion on the pr :) 13:08 < niftynei> is it correct to say that "error -> close channel"/ "warning -> disconnect" or is that too broad a generalization 13:09 < BlueMatt> niftynei: no, you shouldnt even disconnect on warning 13:09 < t-bast> niftynei: usually it's even better to send a warning without disconnecting 13:09 < t-bast> niftynei: to avoid reconnect loops where your peer resends the same problematic message 13:09 < roasbeef> guess depends on what bleeds over to this new message, imo we should just have a new one that replaces all usage of the prior error message w/ richer context 13:09 < rusty> niftynei: error is "I have closed the channel, you should too", basically. 13:10 < roasbeef> most valuable error I've seen in the wild so far is the error when you get an invalid sig, have used that to find a bunch of state machine divergences within lnd, and most recently that HTLC ordering issue 13:10 < niftynei> the dual-funding impl in c-lightning uses warnings pretty much entirely; it fails the connection also tho as a sign to restart the negotiation. but that's maybe a niche case 13:10 < t-bast> roasbeef: true, that's the error that helped figure out many real bugs in the wild 13:11 < BlueMatt> roasbeef: that seems like a wholly separate discussion 13:11 < BlueMatt> roasbeef: the current warning pr is all about "how to tell the counterparty that you're *not* closing the channel but something happened 13:11 < rusty> BlueMatt: true, but it'd be a nice discussion to have. Fortunately both warning and error are extensible. 13:11 < t-bast> niftynei: gotcha, disconnecting makes sense in that case, it's probably a case-by-case basis whether you should disconnect after sending a warning or not 13:11 < BlueMatt> roasbeef: if you want rich errors or whatever, we can do that in a new message. 13:11 < BlueMatt> or extending error/warning, as rusty notes 13:11 < niftynei> since "establishing a channel" you can safely restart the negotiation etc, yeah ok seems like a niche rather than a broad rule 13:12 < BlueMatt> rusty: indeed, its maybe a good thing to do, but I do feel like it needs at least a strawman proposal before we have a live discussion, otherwise we go in circles forever :) 13:12 < roasbeef> how useful will this warning message be if there's no new strucutred information? means we just all need to string match again... 13:13 < roasbeef> there's an ML thread where carla and rusty have started to work out a more structutred approach, I thought that was meant to be a part of this? 13:13 < BlueMatt> roasbeef: it allows you to implement error messages properly again :p 13:13 < t-bast> roasbeef: it's really useful in closing negotiation for example 13:13 < BlueMatt> ie, actually close the channel 13:13 < t-bast> roasbeef: and when using channel_type to open a new channel with a non-default type 13:13 < ariard> niftynei: afaict your usage of the warnings in the dual-funding context to rollback your negotiation matches the richer error context intent of roasbeef? 13:13 < roasbeef> t-bast: yeh I can see that being the case, but will it be if ppl send diff error strings vs having structured records? (using TLV) 13:13 < BlueMatt> roasbeef: yep, we can extend these messages with tlvs when there's a spec for it :) 13:13 < roasbeef> and the chan_type case is one that can be programtically handled most of the time 13:13 < t-bast> roasbeef: I agree it's still just a string that the node operator needs to understand, but it's a good thing to start with! 13:14 < rusty> roasbeef: nah, this predates that, it's old... 13:14 < BlueMatt> in the mean time, just *adding* the warning message is nice, cause we can use it in places where we dont want to close the channel but want to notify an error 13:14 < BlueMatt> cause its actually nice that we have the error messages which close channels imo 13:14 < BlueMatt> or notify counterparties we've closed 13:14 < roasbeef> if there's no new structured data, then how's this imrpove on the other error at all? 13:14 < roasbeef> given you can also use that to send out message, and most impls don't auto force close on it anymore 13:14 < t-bast> I agree with BlueMatt, it's already helpful in practice so let's roll it out, and improve later by adding more structure as we discover what we often need 13:14 < ariard> roasbeef: not force-closing the chan 13:15 < BlueMatt> roasbeef: yep, so we should *start* force closing on errors again :) 13:15 < ariard> which we already do quite liberally in LDK 13:15 < BlueMatt> cause, like, that's what the spec does 13:15 < roasbeef> that was always a dubious requirement imo 13:15 < BlueMatt> roasbeef: if you feel strongly, I suppose we could change the *current* error message message type to "warning" and add a new error message :) 13:15 < BlueMatt> roasbeef: its more "I've closed the channel, you should too, cause its gone" 13:15 < roasbeef> caused a lot of force closes early on when ppl disgareed on fees 13:16 < roasbeef> BlueMatt: yeh carla is working on that, there's a thread on the ML tracking the latest discussion (either new message or just extend prior w/ TLV data to be parsed) 13:16 < BlueMatt> roasbeef: no again thats separate 13:16 < BlueMatt> adding a tlv to indicate a type is something we can do *on top* 13:17 < niftynei> ariard: not exactly, it's still "string messages that need to be parsed", but you could definitely codify the errors via a TLV in the warnings! 13:17 < BlueMatt> roasbeef: do you have a specific suggestion for the warning message prs aside from "I dont care about this"? 13:17 < BlueMatt> because otherwise I think we can just go forward with it 13:17 < roasbeef> BlueMatt: agree we can do on top, but don't see what just another error message delivers 13:17 < niftynei> there's probably a nice set of error states in the open to encode too, channel-type being one of them 13:18 < ariard> niftynei: gotcha, it's still seems a in-the-middle solution where you're parsing human-readable destinaed output to have machine-level automatic reactions 13:18 < BlueMatt> roasbeef: other people here seem to think its valuable to be able to communicate that a channel is closed. I tend to agree 13:18 < roasbeef> niftynei: yeh see this mail: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-July/003142.html 13:18 < BlueMatt> roasbeef: if you dont, that's ok, we can still do it and you can just log that the channel is closed and make your users do more work. 13:18 < niftynei> like that's (channel opens) are probably the highest value place to add codified errors 13:18 < roasbeef> why can't the erorr be used for that? particularluy if the channel is closed, then the chan_id isn't really a thing anymore 13:19 < BlueMatt> roasbeef: it can be, it can be added on top if it! 13:19 < BlueMatt> because that error (a) requires more discussion, (b) isn't broadly implemented, (c) isnt even a spec pr 13:19 < roasbeef> so then the same meessage can just be used and we don't need a new one...? 13:19 < BlueMatt> "i want to delay to add more stuff" is generally not a valid objection unless "more stuff" is quick and easy :) 13:19 < BlueMatt> roasbeef: yes, you can always add tlvs at the end of any message 13:19 < BlueMatt> to provide more context 13:19 < niftynei> well, you definitely have errors in the open that are distinct from warnings 13:20 < roasbeef> rather than delay, I don't see the motivation here given error already exists, and this is just that w/ a diff type 13:20 < ariard> roasbeef: yeah i think that's matt proposal to merge the future carla's richer-context-error proposal in the warning message thanks to TLV 13:20 < niftynei> e.g. once the channel commitments have been exchanged, you error to signal you're going to chain 13:20 < BlueMatt> you want more context in errors/warnings, great! lets add warnings and then we can slap the tlv on the end! everyone gets what they want and y'all dont hold up progress for perfection :) 13:21 < t-bast> TBH the current state sounds really simple to me: errors and warnings are two different things (should be obvious), it's good to have both, currently it's just an unstructured string, later we can add structure in tlv to automate reactions. That's it! 13:21 < niftynei> if you're RBF'ing an extant open attempt, you still want warnings to signal you're failing the re-negotiation, not closing the channel 13:21 < roasbeef> as is, the warning says it should be text based again, so you can't add a TLV there 13:21 < roasbeef> since it inherits the ascii req afaict 13:21 < BlueMatt> yes you can 13:21 < BlueMatt> its length-delimited 13:21 < t-bast> as all lightning messages it has a trailing tlv stream 13:21 < BlueMatt> you can trivially add anything to the message end 13:22 < roasbeef> t-bast: as I've always said, traliling tlv infront of var sized field doesn't really work imo 13:22 < BlueMatt> #action rusty to rebase and respond to comments on warning 13:22 < BlueMatt> next topic 13:22 < roasbeef> since you can run out of space there 13:22 < BlueMatt> you can run out of space in any message 13:22 < BlueMatt> come on man 13:22 < valwal> #topic channel_type negotiation 13:22 < BlueMatt> lets move on 13:22 < valwal> we can circle back if we finish everything else (lol) 13:23 < roasbeef> BlueMatt: no...open channel as is doesn't have var sized fields as an example 13:23 < t-bast> roasbeef: just send an empty string when you want to put tlvs then, there's nothing complicated here...please le'ts move to other topics, feel free to comment on the PR to elaborate? 13:23 < BlueMatt> where are we on channel_type negotiation, are you happier with where it went, roasbeef? 13:24 < t-bast> I've got channel_type ready in eclair, and found a few issues when testing compatibility with c-lightning 13:24 < roasbeef> t-bast: I think should be continued in that ML thread, will reply there, as there's till more to explore there and even just motivation for adding a new message that's exactly the same as another one w/ no added benefit 13:24 < t-bast> rusty did you have time to check my comments on your c-lightning PR? 13:24 < roasbeef> we have an impl of chan type now, need to do interop testing 13:24 < roasbeef> t-bast: anything you ran into that you think may bleed over to othe rimpls? 13:25 < t-bast> roasbeef: it really looks like simple bugs in the implementation, nothing spec-related AFAICT 13:25 < t-bast> roasbeef: if you have an lnd branch to share I can test it against eclair tomorrow! 13:25 < rusty> t-bast: sorry, will have to rebase and get back to this. 13:25 < roasbeef> t-bast: it's here: https://github.com/lightningnetwork/lnd/pull/5373 13:26 < t-bast> rusty: no worries, just ping me when it's ready and I'll run my test scripts 13:26 < t-bast> roasbeef: cool thanks, I'll test it 13:26 < BlueMatt> cool 13:26 < BlueMatt> #action t-bast and roasbeef to do cross-impl testing 13:26 < BlueMatt> next topic? 13:26 < roasbeef> the PR let us simplify our integration tests a good bit too, since we can just add the type vs the build tag, etc, etc 13:26 < valwal> #topic Updated closing_signed fee requirements #847 13:26 < BlueMatt> even nicer, roasbeef! 13:26 < roasbeef> who's driving the bot rn? isn't it tied to a single person? 13:27 < BlueMatt> roasbeef: valwal is, but i thought anyone could action? 13:27 < roasbeef> ah maybe, idk 13:27 < gene> hi 13:27 < roasbeef> guess we'll find out at the end kek 13:27 < cdecker[m]> Valwal is chairing 13:27 < BlueMatt> it seems there's rough agreement on 847, at least no objections on the pr 13:27 < BlueMatt> t-bast: and I need to do cross-impl testing, I think, and then it can land? 13:27 < BlueMatt> any objections? 13:28 < BlueMatt> and/or with c-lightning folks, who've also mayne implemented it? 13:28 < t-bast> I'd love to land this one! 13:28 < roasbeef> t-bast: do you expose the knob to users (picking a chan type in the open chan API)? and if so, is it a type or do you let them flip each of teh bits? just curious from an API perspective as that came up in ours during review 13:28 < BlueMatt> there's also a number of dust concerns related to closing-transactions exposed today, looks like everyone except eclair currently allows nodes to set a dust limit which causes closing tx to be unspendable 13:29 < BlueMatt> but i think that needs a larger closing_signed change 13:29 < BlueMatt> so would propose it happen in a new pr 13:29 < t-bast> roasbeef: yes, I've defined a string enum of channel_types that the user can chose in the `open` API, and then we communicate back whether it was rejected by the other side or not 13:29 < roasbeef> BlueMatt: why would it cause to to be unspendable? assuming impls to verification that rejects bad dust values that is 13:29 < BlueMatt> roasbeef: well right now lnd doesn't (as far as I can tell) verify the counterparty-set dust limit at all, despite the spec saying you must :p 13:29 < ariard> BlueMatt: i think we allow p2pkh/p2sh closing outputs on the ldk side, our max dust_limit_satoshis is 660 13:29 < roasbeef> or I guess unbroadcastable? q still stands 13:29 < ariard> sats 13:29 < BlueMatt> roasbeef: but, more broadly, read your email! 13:30 < t-bast> BlueMatt: ACK on fixing these dust issues in a separate PR, to allow #847 to land sooner 13:30 < roasbeef> it does, but it can be improved ;) 13:30 < t-bast> ariard: the issue is not your max dust_limit but rather your min 13:30 < roasbeef> yeh dust is a can of worms 13:30 < BlueMatt> roasbeef: can you point to where? The only thing I found looking for it was checking an upper-bound, not a lower-bound, and eugene appeared to confirm that was the case. 13:30 < t-bast> roasbeef: yes, it's just unbroadcastable 13:30 < ariard> t-bast: yeah let's fix dust separate from 846 13:30 < ariard> *847 13:31 < rusty> Yes, ack 847. 13:31 < BlueMatt> ok, so no objections to (a) cross-impl testing then merging 847, (b) fixing dust in closing transactions in a new pr. 13:31 < BlueMatt> next topic? 13:31 < t-bast> rusty: BTW on #847 my latest tests against c-lightning were green, nothing weird came out 13:31 < t-bast> BlueMatt: ACK 13:31 < Crypt-iq> so coop closing doesn't take into account output type dust limits roasbeef 13:31 < rusty> t-bast: thans! 13:31 < valwal> #topic BLIPs 13:31 < BlueMatt> t-bast: have y'all done cross-imppl testing? I think in that case we can land now? 13:31 < Crypt-iq> ie spending to a p2pkh < 546, p2sh < 540 13:32 < ryanthegentry> so on bLIPs first ty BlueMatt, ariard, t-bast for the comments 13:32 < ariard> t-bast: does the spec mandates to enforce dust_limit_satoshis at coop closing? 13:32 < ryanthegentry> Helped a lot with reframing the proposal here around feature bits, message types and TLVs assignments rather than be so generic 13:32 < t-bast> BlueMatt: I've successfully tested against c-lightning - if that means we can land it now (or whenever rusty confirms that they're ready) I'm all for it ;) 13:32 < t-bast> ariard: I think so, yes 13:32 < BlueMatt> I think the Real (tm) question about bLIPs is "what is allowed to be a bLIP, and what MUST go in the BOLTs" 13:32 < rusty> t-bast: yep, ack! 13:33 < BlueMatt> t-bast: land it! (imo) 13:33 < BlueMatt> 🎉 13:33 < ariard> t-bast: we do on the LDK-side, like enforcing the holder-side but not checking the counterparty, that's really confusing i admit 13:33 < roasbeef> answer to #1 is basically anything imo 13:33 < roasbeef> #2 is the grey area, prob something that everyone must to do have a working network, like same htlc format 13:33 < ryanthegentry> BlueMatt: one thing that seems low-hanging fruit is Message Types "32768-65535 are set aside for experimental and application-specific messages" per BOLT #1 13:34 < ryanthegentry> but nothing similar exists for feature bits or TLVs 13:34 < ariard> yeah we could still host best practices in the bolt as long as it's not mandatory 13:34 < ryanthegentry> could have a suggested sandbox area for all three, and encourage experimenters to document + ask for review in bLIPs 13:34 < t-bast> ariard: good point, I thought it made sense to check all txs so it seemed obvious to also do it for the closing tx, but in fact it's debatable...worth clarifying! 13:34 < ariard> the ietf do this with a lot of documents, for e.g dnssec best practices : https://www.rfc-editor.org/rfc/rfc6781.html 13:34 < t-bast> #action t-bast to clarify dust limits in closing txs 13:34 < roasbeef> ryanthegentry: what's all 3 here? 13:34 < BlueMatt> I dunno, I feel like if you're just doing random testing, it doesnt need to be a bLIP - it should be constrained to your impl cause its "random testing" 13:34 < ryanthegentry> Feature Bits, Message Types, TLVs 13:34 < roasbeef> ariard: yeh could have a lot of stuff like that re fee bumping, etc 13:35 < BlueMatt> if its something you want to include in eg the state machine, it should be a bolt? 13:35 < cdecker[m]> Definitely 13:35 < ariard> ryanthegentry: my point was about for the bolt process to formalize first the namespace attribution 13:35 < BlueMatt> tho i guess maybe one example is rusty's turn-based-htlc thing, like, maybe thats only done in c-lightning but still others could implement it so could be a bLIP? I dunno, its all grey areas 13:35 < ariard> to let blip devs reused without any conflicts 13:35 < roasbeef> BlueMatt: yeh sure, re random testing, someone could modify the state machine tho, and add say DLC related stuff, imo that's bLIP territory since eveyrone doens't need to do it as it suger on top of everything else 13:36 < ariard> like message types/tlvs types 13:36 < BlueMatt> roasbeef: right, def dont want DLC in BOLTs (tho arguably not even in bLIPs either, but maybe just enough to claim message ids or whatever) 13:36 < roasbeef> ariard: agree they meet re namespacing claims to prevent collisions, etc 13:36 < ryanthegentry> ariard: understood 13:36 < cdecker[m]> The round based protocol should be a bolt imho 13:36 < ariard> BlueMatt: i can say the DLC process is working quite nicely and we would prefer to stay on our own though referrencing blips if they're good :) 13:36 < BlueMatt> cdecker[m]: but what if no one but c-lightning ever implements it? 13:37 < rusty> IMHO: best practices, pre-widespread testing, weird ideas are all great as BLiPS. Some may become BOLTs, sure... 13:37 < BlueMatt> cdecker[m]: we cant get consensus on it in a bolt, should it still be written up as a bLIP? 13:37 < roasbeef> cdecker[m]: could be, one benefit ofr the bLIP style is that it'll be a contained document to provide additional context, etc, etc -- vs being an if statement in a much larger doc 13:37 < rusty> I think ppl find BOLTs intimidating. 13:37 < cdecker[m]> It still touches the state machine and is negotiated during setup 13:37 < ryanthegentry> rusty: sad that they do but agree 13:38 < t-bast> rusty: but they may find a huge collection of bLIP very intimidating as well... 13:38 < BlueMatt> maybe the criteria should be "who implements this"-based? 13:38 < ariard> rusty: yeah we might even run out of review bandwidth for best practices even if they're deepily bolt-oriented fee-bumping, timelocks settings 13:38 < BlueMatt> eg "if you seek broad implementation of this as a core part of lightning, it must be a bolt, if you do not, a bLIP"? 13:38 < BlueMatt> i mean its fuzzy but at least decent guidance? 13:38 < rusty> ariard: true, but if we have an easy entree into the spec, maybe long term we get more qualified reviewers ? 13:39 < roasbeef> ariard: yeh agreed re review bandwidth, there's just so much stuff given the wide design space of LN, something like schnorr integration is BOLT territory since we all need to do it and it already has braod buy in 13:39 < roasbeef> BlueMatt: I like something along those liens 13:39 < rusty> If everyone needs to implement it, it needs to be a BOLT? 13:39 < BlueMatt> rusty: define "needs" 13:39 < BlueMatt> i think it needs to be a bit broader than "needs" 13:39 < ariard> rusty: yeah i'm willingly to test the experiment though for any safety/operational best practices we're going to fetch the already-under-water same people 13:39 < rusty> BlueMatt: vagueness is sometimes a feature. 13:39 < BlueMatt> indeed 13:39 < ariard> like the risk of introducing security theater in a ref document 13:39 < BlueMatt> but I think "needs" isnt vague enough :p 13:40 < t-bast> "If it could benefit the whole network it should be a BOLT"? 13:40 < roasbeef> there's a lot of end-to-end behavior stuff that can be bLIP'd, given you just need the sender+receiver to understand it, like ppl adding podcast metadata to TLVs 13:40 < BlueMatt> but eg i think keysend *should* have been a bolt 13:40 < ariard> roasbeef: yeah and please think about the few L2s devs like darosior/me also keeping the pace with mempool changes to be sure the base layer doesn't break us :/ 13:40 < roasbeef> also feasible something starts as a bLIP, then gets broad buy in and becomes "prompted" somehow 13:41 < BlueMatt> so it cant just be "if its end-to-end, bLIP" 13:41 < roasbeef> BlueMatt: maybe the case, the history of keysend is that it started out as a small thing devs were into within the context of lnd (didn't even have a feature bit), then grew beyond that 13:41 < BlueMatt> yes, I'm aware, not criticizing 13:41 < michaelfolkson> Any chance of just using BOLT 100+ for what would be bLIPs and avoiding months/years of discussions on what should be a bLIP and what should be a BOLT? Or has that ship sailed? 13:41 < ariard> BlueMatt: i disagree here and i think keysend is good enough as a blip 13:41 < BlueMatt> just using it as an example of something that I think we'd want to fit into the "this should be a bolt" 13:42 < BlueMatt> michaelfolkson: it has nothing to do with the numbers 13:42 < ariard> like not risk of channel-closure if you fucked up a keysend implem 13:42 < roasbeef> so bLIPs can be an incubation space of sorts for new things before the get more widely adopted 13:42 < t-bast> michaelfolkson: I think that's orthogonal 13:42 < niftynei> is adding this grey area better than not having a grey area? e.g. is having a set of documents that aren't BOLTS worthwhile if it introduces more surface area for debate? 13:42 < BlueMatt> ariard: i dunno, users expect it to work broadly, there's a lot of real UX issues caused by keysend not being universal 13:42 < BlueMatt> so i think it *def* fits under "this really needs to be universal" 13:42 < roasbeef> even w/ keysend at the time, some ppl wanted to do it a diff way, iirc using the shared secret of the onion instead, view diverged and keysend was just implemented as is in lnd 13:42 < ariard> BlueMatt: sure but solving the UXissuess that's done with a spec document, be it blip or bolt :) 13:43 < BlueMatt> ariard: its solved by things being universal 13:43 < niftynei> i think i just said the same thing as michaelfolkson 13:43 < BlueMatt> which I think is *precisely* the difference between blip and bolt 13:43 < niftynei> :P 13:43 < ariard> BlueMatt: right and things can become universal by either blip, bolt or bip 13:43 < roasbeef> niftynei: does it introduce more surface area? imo BOLT is prespriptive (you gotta do this), bLIP is descriptive (here's how thing things works and what we use it for) 13:43 < ariard> that's a communication-towards-devs issue 13:43 < michaelfolkson> This discussion will run and run. There will always be grey area with between BOLT and bLIPs. I just find this the least interesting thing to discuss with minimal payoff (but maybe that's just me) 13:43 < BlueMatt> ariard: if they are universal, they can/should migrate from blip to bolt (which is fine!) but if its intended to be, or is universal, it should be a bolt, not remain a blip 13:44 < roasbeef> michaelfolkson: it's progressing pretty well in the spec PR... 13:44 < ryanthegentry> I really like the concreteness of looking at how valwal adjusted BOLT #9 in her Keysend bLIP 13:44 < ryanthegentry> https://github.com/lightningnetwork/lightning-rfc/blob/2ce13ef01a17de1ccefa615072b4bee8f13e4ca0/09-features.md 13:44 < t-bast> I think bLIPs can be useful because otherwise we're currently either using PRs-that-dont-get-reviewed or unspecified-things-in-implementations for it - at least having things documented centrally is an improvement 13:44 < ariard> BlueMatt: and what if in the future the dlcspec start to implement chan_type? 13:44 < ryanthegentry> with the "bLIP Reserved Feature Bits" and a link to the descriptive doc 13:44 < roasbeef> t-bast: +100 13:44 < BlueMatt> so, i guess, to make it concrete, if we put text in the blip 1 doc that says something like "if its intended to become universal or near universal, it must be a bolt", is that ok? 13:44 < ariard> should it also mo ved as a bolt 13:44 < BlueMatt> ariard: DLC is never intended to be universal? so it can reamian a blip 13:45 < roasbeef> BlueMatt: yeh something like that could work as a quick heuristic 13:45 < BlueMatt> dlc is a specific thing that some people will implement, but certainly isn't required 13:45 -!- mschmoock [~will@schmoock.net] has joined #lightning-dev 13:45 < ariard> BlueMatt: what do you mean exactly by "universal" ? 13:45 < BlueMatt> ariard: as in "all lightning nodes should implement this in order to keep reasonable compatibility between lightning nodes and clients" 13:45 < niftynei> roasbeef: i think you're using prescriptive in a way that i'd disagree with; ideally any spec is descriptive (procedural) 13:45 < ariard> BlueMatt: i think in previous discussions we had the idea that a blip could be promoted to a bolt it's widely adopted by LN implems 13:46 < roasbeef> it's kinda an emergent trait imo, keysend wasn't really in that bucket a year ago, but it's more universal these days as devs view it as a sort of standard feature an impl should have 13:46 < BlueMatt> ariard: yes, if something starts as "we're doing this, and dont really expect others to" and then others do it, users start expecting it, and it becomes something that everyone does/has to do, then it can migrate 13:46 < ariard> BlueMatt: yeah but reality, is that LN universality is and will always be a moving target 13:46 < rusty> michaelfolkson: true, but I think trying an area with a lower barrier to entry may encourage more participation. 13:46 < BlueMatt> ariard: i dont think anyone disagrees that migration is an option? 13:46 < BlueMatt> roasbeef: more importantly, i think, *users* expect it to be universal :p 13:47 < ariard> BlueMatt: so i think the migration path is solving both our concern 13:47 < roasbeef> niftynei: yeh I guess we differ there w.r.t definition, another take is bitcon consensus rules are prescriptive, policy is discriptive -- the set of things all LN implementation need to agree on is smaller in comparison, so there's a lot of free energy to be used for new ideas/concepts 13:47 < niftynei> what if we just let spec authors decide how to propose their stuff and see what happens 13:47 < BlueMatt> ok, so do we have consensus, niftynei what say you? are there other concerns you have? 13:47 < t-bast> ryanthegentry: on the contrary, I'm wary of bLIPs modifying directly bolts, because that will require more review from more people - I'd rather have bLIPs only update other bLIPs to avoid needing more review from people who already spend a lot of time reviewing stuff 13:47 < ariard> BlueMatt: note, i think we won't agree all on what should become universal and the really long-term direction of lighnining, it's an evolutionary process 13:47 < BlueMatt> niftynei: do you have specific objection to, or think its uneccessary, to specify things based on a "universal implementation" heuristic? 13:48 < BlueMatt> ariard: yes, of course, its vague, and we'll disagree, but at least its the heuristic. 13:48 < roasbeef> niftynei: that's teh case rn, now they have another option 13:48 < michaelfolkson> The thing with new acronyms and processes is they seem exciting, glitzy and solve the problems of previous acronym at the beginning. But then after a while they suffer from exact same challenges ;) 13:48 < ariard> roasbeef: and Core's policy is prescriptive for LN :/ 13:48 < ryanthegentry> t-bast: touché :) 13:48 < roasbeef> one that's a bit more defined, and may be interpreted to carry less weight 13:48 < BlueMatt> michaelfolkson: I think everyone here agrees that blips solve a specific issue, and have been proposing similar ideas since before it had a time or felt exciting 13:49 < cdecker[m]> Well having things documented is definitely the right thing to do. When combined with a migration to bolt once it becomes central to LN also seems ok 13:49 < niftynei> i feel like we're trying to solve a problem that exists but isn't really the purview of this chat idk 13:49 * michaelfolkson goes back to lurking 13:49 < BlueMatt> niftynei: can you elaborate? 13:50 < ariard> michaelfolkson: that's quite true from xp, the dlcspecs was quite fast at first, then slows down considerably now you have multiple implems 13:50 < niftynei> more documentation of how things work is always a good thing, the scope of who else you expect/intend to also adopt them is a function of the level of interoperability you expect the application to have with others, no? and which application that is exactly 13:51 < ariard> i've a doubt on such "universal implementation" heuristic to solve issues with long-term economic consequences for the network, like channel jamming 13:51 < t-bast> ryanthegentry: maybe it's just my personal opinion, but I'd rather have a few common bLIPs that may get updated frequently (e.g. to list feature bits / message types / tlv fields used by all bLIPs) that don't really need to be looked at by all LN devs than updating BOLTs for that 13:51 < cdecker[m]> I guess the slowdown is the cost of maintaining compatibility and avoid a netsplit :-) 13:51 < ariard> the best approach might be just to let different solutions compete and see with time which one is the better 13:52 < ariard> cdecker[m]: note, a netsplit is a security concer for all of us as we all share the same mempool/blockspace :) 13:52 < roasbeef> ok, something something universal, ship it! 13:52 < BlueMatt> i've a doubt on such "universal implementation" heuristic to solve issues with long-term economic consequences for the network, like channel jamming <-- huh? 13:52 < BlueMatt> I'm *really* confused by what this means 13:52 < niftynei> if you're working on a lightning node implementation and want it to talk to other lightning nodes then you'd want to look at the BOLTs, no? 13:52 < ariard> BlueMatt: i mean to survive any issue with economic or lot-of-context 13:52 < roasbeef> I think he means we'd want a network wide solution to stuff like that BlueMatt 13:52 < cdecker[m]> Yeah, was thinking more of incompatible end-to-end things that just get rejected 13:53 < BlueMatt> more documentation of how things work is always a good thing, the scope of who else you expect/intend to also adopt them is a function of the level of interoperability you expect the application to have with others, no? and which application that is exactly <-- I'm *really* confused if you're disagreeing with anything I'm saying or not. 13:53 < roasbeef> niftynei: yeh for the every base level of functionality, lots of added stuff you may not need to impl just to get a basic payment working 13:53 < ariard> roasbeef: yeah that 13:53 < roasbeef> the very base* 13:53 < ariard> and for channel jamming we might need a step-by-step process, spread on many standalone documents 13:53 < niftynei> oof i gotta go i'm sorry. i'll catch up on the logs after the fact! 13:54 * t-bast waves goodbye at niftynei 13:54 < niftynei> BlueMatt: "universal implementation" sounds fine?? sure. ship it. 13:54 < valwal> *waves* bye lisa! 13:54 < niftynei> tchauuu 13:54 < cdecker[m]> C ya 13:54 -!- niftynei [~niftynei@2600:1700:d0e:284f:c4f5:5ae0:b243:f2c8] has quit [Quit: Leaving] 13:54 < BlueMatt> BlueMatt: i mean to survive any issue with economic or lot-of-context <-- ok, maybe lets chat about this further later, i still dont quite know what you mean and we're running out of time to discuss other things? 13:54 < roasbeef> me gusta 13:55 < BlueMatt> do we want to fit another topic in? 13:55 < BlueMatt> or are we outta time? 13:55 < t-bast> yes please mandatory payment_secrets! 13:55 < ariard> BlueMatt: each implem moves on their own with a blip 13:55 < t-bast> it's very quick 13:55 < roasbeef> I can hang for another 5 mins 13:55 < t-bast> just say ACK 13:55 < roasbeef> +1 to mandatory secrets, we already do it, ACK 13:55 < valwal> #topic mandatory payment secrets 13:55 < cdecker[m]> Got to drop off soon too 13:55 < BlueMatt> t-bast: i already ack'd the pr :p 13:55 < BlueMatt> it has two acks, ship it. 13:55 < t-bast> Great, and c-lightning has verified the test vectors, so merge? 13:55 < BlueMatt> (I havent verified the vectors, tho) 13:56 < t-bast> #action t-bast to merge #887 13:56 < roasbeef> approved, need to add the test vectors, but looks good 13:56 < t-bast> Awesome 13:56 < cdecker[m]> Wow, that was a quick one 13:56 < ariard> re ln-spec-meetings-attached-to-coredev, if i can have a volontary from each orga to see invits/formats/online attendances/etc that would be nice 13:56 < ariard> s/each orga/each implem/g 13:56 < ariard> :) 13:56 < t-bast> ariard: count me in 13:57 < ariard> t-bast: goooood 13:57 < valwal> #endmeeting 13:57 < lndev-bot> Meeting ended Mon Aug 16 20:57:13 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:57 < lndev-bot> Minutes: https://lightningd.github.io/meetings/meeting_name/2021/meeting_name.2021-08-16-20.04.html 13:57 < lndev-bot> Minutes (text): https://lightningd.github.io/meetings/meeting_name/2021/meeting_name.2021-08-16-20.04.txt 13:57 < lndev-bot> Log: https://lightningd.github.io/meetings/meeting_name/2021/meeting_name.2021-08-16-20.04.log.html 13:57 < cdecker[m]> Happy to do it (if I get more details about what to do) 13:57 < BlueMatt> ariard: I dont believe I'll go, no 13:57 < BlueMatt> ariard: and rusty still cant leave au iirc 13:57 < BlueMatt> ariard: so I'm pretty dubious of the value. 13:57 < t-bast> That was intense! Thanks everyone for the meeting, we covered a lot really fast ;) 13:57 < ariard> BlueMatt: that's your choice, online attendance? 13:58 < gene> are there any specs dealing with standards for channel selection for routing? 13:58 < cdecker[m]> Yep, good meeting ⚡ 13:58 < ariard> cdecker[m]: yeah will do a signal chat/mail or whatever 13:58 -!- Crypt-iq [~Crypt-iq@2603-6080-8f06-6d01-b508-bccd-d0ec-ab17.res6.spectrum.com] has quit [Quit: Client closed] 13:58 < BlueMatt> BlueMatt: each implem moves on their own with a blip <-- ok, following up on this - you mean that people will go off on their own with the way they handle closes or not? 13:58 < cdecker[m]> gene: that'd be a good blip 13:58 < BlueMatt> ariard: I dont think its a great use of everyone's time to do a f2f meeting in person if we're missing major contributors imo 13:58 < rusty> BlueMatt: that is true, but I'm just one person and I think a F2F is really important. I have full faith in all of your ability to make good decisions, too. 13:59 < BlueMatt> ariard: we can do video chat for everyone if we prefer. 13:59 < roasbeef> gene: like during path finding? not really, lots of renwed discussion in that area and it's something that ppl can experiment w/ as there's a lof of options there 13:59 < t-bast> rusty: don't think we'll let you rest easily in AU, we'll be waiting for you in a few video meetings ;) 13:59 < ariard> BlueMatt: we'll have a coredev and a good chunk of LN devs are invited and desirous to attend, let's just join a meeting ahead 14:00 < gene> ok, have been thinking about something along the lines of a logarithmic drop-off in channel amount, to encourage smaller channels 14:00 < roasbeef> meatspace ftw 14:00 < t-bast> gene: that's not something that needs to be standardized, every node can do it differently depending on what trade-offs they want to make 14:00 < ariard> BlueMatt: 20:58 < BlueMatt> BlueMatt: each implem moves on their own with a blip <-- ok, following up on this - you mean that people will go off on their own with the way they handle closes or not? 14:00 < t-bast> gene: that sounds like a good candidate for a message on the mailing list 14:00 < ariard> well you can solve jammming without forcing your direct counterparty to force-close ? 14:01 < gene> t-bast: right, I was just thinking that having a base-line would be good for impls to refer 14:01 * cdecker[m] waves and drops off to sleep 14:01 < BlueMatt> ariard: well i mean i guess i still think the "universal implementation" thing is still the right heuristic - if you are doing your own thing and dont think anyone else need be doing the same, writing it up as a blip is better than nothing. 14:01 * t-bast waves at cdecker 14:01 < BlueMatt> ariard: if you expect others to do the same thing, it would be a bolt under the same criteria? 14:02 < ariard> BlueMatt: as usual comes with "universal implementation" and i'll find the holes :) 14:02 < BlueMatt> ariard: no wordig is perfect 14:02 < BlueMatt> its the right spirit, trying to language lawyer it is gonna break, i agree :) 14:02 < gene> it could be cool to have sim nets setup to run different models of X channels of Y amount produces Z outcome in channel selection 14:03 < t-bast> regarding meeting before the coredev, if many contributors are missing, we can just call it a "hanging out IRL to casually chat about all things lightning" instead of a spec meeting, drink more beers and I'm sure it will still be very useful! 14:03 < ariard> BlueMatt: i concede it might be good for 80% but we're going to conflict on the remaining issues 14:03 < BlueMatt> ariard: yea, i mean if you have better wording I'm all ears :p 14:03 < BlueMatt> ariard: in any case, we can discuss it on the pr too 14:04 < t-bast> and we can then feed that back into video chats / github PRs / IRC meetings to share the outcomes 14:04 < BlueMatt> once au people can leave, I still think we should do a full spec meeting somewhere, new york remains easy 14:04 < gene> gene: that sounds like a good candidate for a message on the mailing list <-- will think about the idea some more, and post something 14:04 < BlueMatt> would also love aj and maybe harding to join 14:04 < ariard> BlueMatt: man your country is still banning folks :p 14:04 < ariard> to casually enter 14:05 < BlueMatt> ariard: meh. I assume that'll change by the time au changes their tune 14:05 < t-bast> BlueMatt: that works for me too, after all this time without any event I'm all for as many occasions as possible to meet IRL 14:05 < BlueMatt> lol, you aren't doing the "making up for lost time" thing yet, t-bast? :p 14:05 < t-bast> BlueMatt: could be, could be xD 14:06 < ariard> we can do a LN spec meeting when coredev and another one in nyc in 6months 14:06 < BlueMatt> I personally dont want to add more work travel unless its very useful, cause have lots of *other* travel anyway 14:06 < BlueMatt> t-bast: btw, re: closing_signed fee requirement, your latest changes do mention sending warning messages, which makes it awkward to merge before the warning message pr 14:06 < ariard> have to go, late on mempool/ldk reviews :p 14:06 < BlueMatt> t-bast: I'd be ok with landing it without that requirement and then adding warnings in a separate pr, which should be easy 14:07 < BlueMatt> t-bast: you can also stick with the meeting consensus and just hit merge lol 14:07 < t-bast> BlueMatt: yeah, I was hoping we'd agree on warning and merge them soon, but I can definitely remove it for now and re-add it after warnings have been merged 14:07 < BlueMatt> but thats even more awkward 14:07 < BlueMatt> yea, I think just remove it and hit merge 14:07 < BlueMatt> and we'll add it in a separate pr 14:08 < t-bast> Excellent I'll do that tomorrow ;) 14:08 < t-bast> Gotta go, see you all! 14:08 < BlueMatt> see ya! 14:09 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving] 14:16 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 258 seconds] 14:32 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 258 seconds] 14:33 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev 14:46 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 248 seconds] 14:48 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev 14:56 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.] 14:57 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev 15:14 -!- niftynei [~niftynei@2600:1700:d0e:284f:c4f5:5ae0:b243:f2c8] has joined #lightning-dev 15:23 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 268 seconds] 15:41 -!- ldecferreira [~Lucas@2804:431:c7d8:1f99:c34:4c48:1fa8:2a5f] has quit [Quit: Client closed] 15:47 -!- td00 [~td00@172.245.134.58] has joined #lightning-dev 15:51 -!- td00 [~td00@172.245.134.58] has quit [Client Quit] 15:51 -!- td001 [~td001@172.245.134.58] has joined #lightning-dev 15:54 -!- niftynei [~niftynei@2600:1700:d0e:284f:c4f5:5ae0:b243:f2c8] has quit [Quit: Leaving] 16:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:03 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev 17:20 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene] 17:24 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection] 17:24 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev 17:26 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 17:27 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 244 seconds] 18:00 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 18:02 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.] 18:14 -!- rusty [~rusty@203.221.41.134] has joined #lightning-dev 18:17 -!- belcher_ [~belcher@user/belcher] has joined #lightning-dev 18:21 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 256 seconds] 18:37 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 18:37 < lnd-bot> [lightning-rfc] Roasbeef merged pull request #887: Make payment secret mandatory and update Bolt 11 test vectors (master...bolt11-test-vectors-payment-secret) https://github.com/lightningnetwork/lightning-rfc/pull/887 18:37 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 18:37 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 18:37 < lnd-bot> [lightning-rfc] Roasbeef pushed 3 commits to master: https://github.com/lightningnetwork/lightning-rfc/compare/84213f45c05a...07c7caed516f 18:37 < lnd-bot> lightning-rfc/master 42bd71d t-bast: Add payment secret to Bolt 11 test vectors 18:37 < lnd-bot> lightning-rfc/master ec1d4dc t-bast: Make s field mandatory in invoices 18:37 < lnd-bot> lightning-rfc/master 07c7cae Olaoluwa Osuntokun: Merge pull request #887 from lightningnetwork/bolt11-test-vectors-payment-... 18:37 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 19:21 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 245 seconds] 19:25 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev 19:30 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:e0d1:24f:1e78:945b] has quit [Quit: Client closed] 20:48 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 20:48 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 21:03 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 21:03 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 21:24 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 21:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 21:38 -!- AaronvanW [~AaronvanW@190.150.148.22] has quit [Remote host closed the connection] 22:08 -!- abetusk [~abe@68.175.128.91] has quit [Quit: Leaving] 22:10 -!- reallll [~belcher@user/belcher] has joined #lightning-dev 22:11 -!- belcher_ [~belcher@user/belcher] has quit [Ping timeout: 245 seconds] 22:12 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 245 seconds] 22:24 -!- AaronvanW [~AaronvanW@190.150.148.22] has joined #lightning-dev 22:54 -!- AaronvanW [~AaronvanW@190.150.148.22] has quit [Ping timeout: 248 seconds] 23:10 -!- reallll is now known as belcher 23:32 -!- AaronvanW [~AaronvanW@190.150.148.22] has joined #lightning-dev 23:49 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 23:49 < lnd-bot> [lightning-rfc] t-bast deleted 0 commit to bolt11-test-vectors-payment-secret: https://github.com/lightningnetwork/lightning-rfc/compare/ec1d4dc66519...000000000000 23:49 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] --- Log closed Tue Aug 17 00:00:41 2021