--- Log opened Mon Feb 01 00:00:32 2021 00:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 00:21 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Remote host closed the connection] 00:22 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 01:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 01:14 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined #lightning-dev 01:15 -!- laptop [~laptop@ppp-0-143.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev 02:05 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 246 seconds] 02:20 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev 03:19 -!- Setherson [~Setherson@108-255-110-61.lightspeed.tukrga.sbcglobal.net] has quit [Ping timeout: 240 seconds] 03:29 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] 04:45 -!- johnzweng [~johnzweng@212-186-86-234.static.upcbusiness.at] has joined #lightning-dev 04:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 04:59 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Remote host closed the connection] 05:14 -!- kloinka [~quassel@220.233.177.223] has joined #lightning-dev 05:24 -!- rdymac [uid31665@gateway/web/irccloud.com/x-cnchuvzpidkousuh] has joined #lightning-dev 05:41 -!- Xaldafax [~Xaldafax@cpe-104-34-193-119.socal.res.rr.com] has joined #lightning-dev 06:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds] 06:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 06:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds] 06:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 07:24 -!- kexkey [~kexkey@static-198-54-132-124.cust.tzulo.com] has joined #lightning-dev 08:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 08:05 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 08:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 08:21 -!- johnzweng [~johnzweng@212-186-86-234.static.upcbusiness.at] has quit [Ping timeout: 272 seconds] 08:39 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 08:41 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 08:42 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev 08:45 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection] 08:45 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Ping timeout: 268 seconds] 08:46 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev 08:55 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 264 seconds] 08:56 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev 09:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 09:57 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 09:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 10:01 -!- lukedashjr is now known as luke-jr 10:10 -!- _flow_ [~none@salem.informatik.uni-erlangen.de] has quit [Ping timeout: 244 seconds] 10:11 -!- lucen[m] [lucenmshrm@gateway/shell/matrix.org/x-nmbmpelmuugwohua] has quit [Ping timeout: 244 seconds] 10:21 -!- _flow_ [~none@salem.informatik.uni-erlangen.de] has joined #lightning-dev 10:22 -!- lucen[m] [lucenmshrm@gateway/shell/matrix.org/x-twbvauwlhnmwgeoy] has joined #lightning-dev 10:33 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds] 10:44 -!- laptop_ [~laptop@ppp-0-143.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev 10:47 -!- laptop [~laptop@ppp-0-143.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds] 10:54 -!- bmancini55 [9a1516ee@154.21.22.238] has joined #lightning-dev 10:56 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev 11:00 < cdecker> Good evening everybody :-) 11:00 < BlueMatt> hi cdecker 11:00 -!- johnzweng [~johnzweng@80-108-14-34.cable.dynamic.surfer.at] has joined #lightning-dev 11:00 < t-bast> Hey guys, good evening 11:01 < jkczyz> hey 11:05 < lndbot> good evening :slightly_smiling_face: 11:06 < ariard> hey 11:08 < t-bast> Agenda suggestion is here: https://github.com/lightningnetwork/lightning-rfc/issues/838, if someone else would like to chair tonight (does someone know what we could do to get the meeting bot back?) 11:10 < ariard> jkczyz: coin toss ? 11:10 < jkczyz> sure 11:11 < jkczyz> tails 11:11 < ariard> sorry you lost :p 11:11 < ariard> you chair 11:11 < t-bast> xD 11:12 < t-bast> that sounds verifiable enough 11:12 < jkczyz> great! so I guess I need to hash tag something? 11:12 < ariard> I didn't say it would be a cryptographically fair coin toss ;) 11:12 < t-bast> The meetbot commands are here: https://wiki.debian.org/MeetBot 11:12 < t-bast> Not sure the bot works, but at least using those make it easy to then parse the meeting logs :) 11:13 < jkczyz> #startmeeting 11:13 < cdecker> Nope doesn't work, I'll set one up for next time 11:14 < jkczyz> will just use them for ease of parsing then 11:14 < jkczyz> #topic rustyrussell to validate #539 test vectors in c-lightning 11:15 < cdecker> rusty isn't joining today, so let's skip that one 11:15 < jkczyz> ok! 11:15 < jkczyz> #topic: all implementations to correctly set sync_complete as per #826 11:16 < jkczyz> How's the progress on this? 11:16 <+roasbeef> lnd already does it, and has this the start 11:16 < t-bast> On that front, I have a PR for eclair, it just depends on another PR related to gossip queries so it's not integrated yet, but will be done soon 11:16 <+roasbeef> as the prior usage of this field wasn't really used, and didn't add much 11:16 < ariard> still on the todo list on the RL side 11:16 <+roasbeef> since the start* 11:17 <+roasbeef> we just need to update newer nodes to start reading the value again 11:17 < jkczyz> cdecker: How about c-lightning? 11:19 < jkczyz> going to presume cdecker stepped away. Shall we move on to the next topic or is there more to discuss here? 11:20 < cdecker> Had to check 11:20 < jkczyz> ah, sorry for the rush :) 11:20 < cdecker> c-lightning still uses the "are we queriable for all gossip" meaning. Will fix that up these days 11:20 < cdecker> Sorry for the delau 11:20 < cdecker> s/delau/delay/ 11:21 < jkczyz> ok, let's move on then 11:21 < jkczyz> #topic second implementation of #672 for compatibility testing with c-lightning 11:21 < jkczyz> This is for BOLT 2 opt_shutdown_anysegwit 11:22 < jkczyz> Looks like cdecker and roasbeef were looking into this for their impls? 11:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 11:23 < t-bast> No progress on this one for eclair, we'll do this at some point but not sure when 11:24 < cdecker> Should be really trivial to implement 11:25 <+roasbeef> we accept it already, just need to add the feature bit 11:26 < cdecker> Excellent 👍 11:28 < jkczyz> should we add an action item to follow-up? or is there a better way to go about completing this? 11:29 < t-bast> I think we can keep this item in the pending list until we've had cross-compatibility between implementations tested? 11:29 < ariard> just to test interops CL/lnd ? 11:29 < t-bast> Once we do we can merge the PR 11:30 < jkczyz> #action follow up 11:30 < jkczyz> let's move on then 11:30 < jkczyz> #topic second implementation of #824 for compatibility testing with lnd 11:31 < jkczyz> defining option_zero_htlc_tx_fee 11:31 < jkczyz> ACKs from ariard and t-bast 11:32 < jkczyz> Any implementations have this ready for iterop testing? 11:32 < t-bast> Not yet for eclair, it should be ready in a few weeks (hopefully) 11:33 < cdecker> I see the definition of option_anchors has been added, very good 👍 11:33 < ariard> once I'm done with LDK sample, should be easy to tweak my anchor implem to test interops 11:33 <+roasbeef> lnd is ready at 0.12, you toggle it w/ a flag --protocol.anchors 11:33 < ariard> but same few weeks 11:34 < jkczyz> great, let's follow-up on progress next meeting then 11:34 < cdecker> cl doesn't have a nursery yet, so we'll need to implement that first before we can implement `option_anchors_zero_fee_htlc_tx` 11:34 < jkczyz> cdecker: nursery? 11:36 < cdecker> Tracking (partial) transactions, recombining them when needed, and bumping fees if needed 11:36 < jkczyz> ah, thanks for explaining 11:37 <+roasbeef> yeh we've been working on our version of that in lnd for a while, it's pretty advanced now and the API is just "yo sweep this, lemmie bump it, dont' include this one w/ that one, etc" and it batches+aggregates+republishes in the background 11:38 < ariard> cdecker: think about reorg or remote side confirming first and thus unlocking bumping utxo 11:38 < cdecker> Yep, that's pretty much what we aspire to as well 11:38 <+roasbeef> yeh we watch for all spends, and then update what we're doing accordingly 11:38 <+roasbeef> negative confs, etc 11:38 < cdecker> That's not a problem ariard, we support reorgs and races, just not re-arranging transactions, or bumping fees 11:41 < jkczyz> ok, I move that we go onto pending PR reviews unless there is more to discuss here 11:41 < jkczyz> #action follow up 11:41 < jkczyz> #topic Compression algorithm gossip #825 11:42 < jkczyz> seems like most are happy with the state of this? 11:42 < t-bast> I think only RL commented on this PR, right? 11:42 < t-bast> It would be worth having another implementation look into it IMO 11:43 < jkczyz> t-bast: ah right! you were the one who proposed it :P 11:43 < t-bast> :D 11:44 < jkczyz> cdecker roasbeef, any input from your sides? 11:44 <+roasbeef> on the lnd side we've been interested in something like this for sometime now, but haven't impl'd it yet 11:45 <+roasbeef> what happens if there's a non overlap? 11:45 <+roasbeef> so you have the bit set, they have the bit set, but you both want diff algos 11:45 <+roasbeef> so intersection of algos is the empty set 11:45 < cdecker> Sounds good to me, the only point of contention was how we can signal we don't support zlib, and in that case we just kill the connection if the peer asks for it and we don't 11:45 < cdecker> roasbeef: empty intersection = no gossip exchange, easy 11:46 < t-bast> exactly 11:46 < bitconner> one q i had: how do you indicate support for both raw _and_ zlib if there's only a bit assigned to zlib? 11:46 < bitconner> or is raw just assumed? 11:46 < t-bast> cdecker: now you can signal you don't support zlib (if you have that feature bit activated and in `init` don't send support for zlib) 11:46 < jkczyz> t-bast: no lingua franca 11:46 < t-bast> bitconner: yes I assumed raw 11:47 < bitconner> does it not make sense to have the option to disable raw? 11:47 < cdecker> t-bast: I know, but nodes that don't understand the feature bit will still ask for it 11:48 < t-bast> cdecker: yes that's right, hopefully this will be temporary and people will upgrade soon-ish because of all the other goodies that are coming 11:48 < t-bast> bitconner: maybe, it could be reasonable to want to only allow compressed if you're worried about bandwidth 11:49 < t-bast> bitconner: I could use one of these bits to indicate raw, what do the others think? 11:49 < cdecker> Nah, raw MUST be supported imho 11:49 < bitconner> i think that makes sense, since we are trying to rectify the mistake of assuming some default encoding support. if we're implementing encoding negotiation imo it makes sense to have all encoding treated quially 11:50 < bitconner> equally* 11:51 <+roasbeef> oh so you're saying uncompressed isn't explicit? 11:51 <+roasbeef> ahh I see what you're saying, being able to signal support for both in an explicit manner? 11:51 < bitconner> yeah, raw isn't opt-in 11:52 < t-bast> cdecker: why do you think it can't be opt-out? 11:52 < t-bast> to ensure we have something that allows all nodes to communicate? 11:52 < t-bast> and avoid splitting based on incompatible encoding support? 11:52 < t-bast> (splitting the network) 11:53 < cdecker> That for one, but it is also trivial to opt out if you don't want to support it: don't ask for it, and if asked return an empty one 11:53 < bitconner> if you don't want to split, then you'd signal both? but if you are actually constrained then idk if it makes sense to force the fallback 11:54 < cdecker> But I don't really care that much, it's just weird to have raw as a "compression algorithm" :-) 11:54 < bitconner> cdecker: that would break some assumptions, bc the node is execpting to get all the updates 11:54 <+roasbeef> no compression is best compression 11:54 < bitconner> maybe encoding algorithm would be more appropriate :P 11:55 <+roasbeef> ^ 11:55 < bitconner> you're telling others that "i know nothing" when in reality you just don't want to tell them 11:55 < t-bast> TBH there are pros and cons for both, I'm not sure which solution I'd prefer 11:56 < t-bast> No opt-out of uncompressed format ensures there's always an intersection between two nodes (a way to exchange gossip queries) which is good 11:56 <+roasbeef> yep 11:57 <+roasbeef> so bit 0 is uncompressed, bit 1 is zlib? 11:57 < cdecker> Ok 11:57 < cdecker> Let's make it explicit then :-0 11:57 < cdecker> :-) 11:58 < t-bast> okay let's do this 11:58 < cdecker> Gotta run in a couple of minutes btw 11:58 < t-bast> #action t-bast to add uncompressed as an explicit option 11:58 < bitconner> yay cipher suite negotiation 😂 11:58 <+roasbeef> ok just commented thaton the spec 11:58 < t-bast> :+1: 11:58 < jkczyz> great, let's move on 11:58 < jkczyz> #topic Warning message #834 11:59 < t-bast> If rusty isn't there, maybe we'll wait for him before we discuss this warning message since he created the PR? 11:59 < jkczyz> yeah, that seems reasonable given the discussion on the PR 11:59 < cdecker> Sure that works as well, he should be here for the extended discussion 12:00 < jkczyz> #action follow-up when rusty is here 12:00 < cdecker> But we think this is really an important improvement, since it makes soft failures explicit (the ones that don't panic and go to chain) 12:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 12:00 < cdecker> lnd had a couple of them, and we needed to work around them by special casing, so making this explicit removes that under-definedness from the spec 12:01 < t-bast> I agree, it's desirable 12:02 < cdecker> Implementing it is really just adding the message, and then going through all the error cases and deciding whether to kill or not the underlying channel and switching to the appropriate message variant 12:02 < t-bast> that sounds really boring though xD 12:02 < t-bast> but it's quite useful 12:03 < ariard> we already have soft-errors on the RL-side, good move 12:03 <+roasbeef> yeh next step is to add in error codes so we can all handle them more programmatically 12:03 <+roasbeef> then the payloads can have more structure as well 12:04 <+roasbeef> like "error code 5 is invalid sig, there're 3 tlv of the past state, htlcs, etc" 12:04 < BlueMatt> what can an implementation do with any of that data? 12:04 <+roasbeef> debug? 12:04 < ariard> apart of helping debug 12:04 <+roasbeef> just an example 12:04 < BlueMatt> if we add explicit error codes, we should have clear definitions of exactly what an implementation should do in response to each 12:04 < BlueMatt> otherwise it can just be a string. 12:04 <+roasbeef> other stuff is when you reject an incoming funding req, you can tell them what your actual min amt is, etc 12:05 < ariard> but yeah that sounds more like dyna m mic negotation 12:05 <+roasbeef> string parsing isn't really helpful as ppl then all have diff strings 12:05 <+roasbeef> this is just abotu structure errors for debugging and also to give more insight into disconnects, funding rejections, etc 12:05 < BlueMatt> right, my point is if you want to impose the effort of something more than strings, there needs to be a clear "if you get error code 1, you should do X" 12:05 <+roasbeef> like rn, we prob all send diff errors when we recv an invalid commitment sig or htlc sig 12:05 < BlueMatt> otherwise its all debugging anyway and debugging requires humans which can use strings. 12:06 <+roasbeef> might as well have better/standardized input to your debugging, but that's just one class of errors 12:06 < ariard> we might inject structure and then let implementation experiment a bit with it 12:06 <+roasbeef> yeh low cost, tangible benefit 12:06 < ariard> I def can see errorr codes about funding rejecct being consumed to do a step-by-step negotation 12:06 <+roasbeef> ppl are free to structure their errors or not lol 12:06 < ariard> where only one side adjust its opening offer 12:06 < BlueMatt> if 'what you do in response' is loose you just end up with a bunch of random return values which are buggy and dont line up with exactly what a counterparty should do. 12:06 < ariard> I mean something cross-implem 12:07 < BlueMatt> I'm not saying it has to be super well-defined, but lets not add some loose categorization of errors which dont mean anything cause we have humans processing it anyway 12:07 <+roasbeef> I think we're talking past each other here, there're diff classes of errors and hard to argue that we couldn't benefit from them being more structured, up to the impl what they do w/ that structure, certain errors can be programatically handled w/ more context 12:07 < BlueMatt> that just adds complexity and a ton of "wait, which category is this?" for nothing. 12:07 < cdecker> No, I think we shouldn't impose structure on the error message, since by definition they cannot be enumerated, and therefore we'll always have some that are undefined 12:07 <+roasbeef> if you think it's complex, ok don't impl it 12:07 < BlueMatt> what cdecker said 12:08 <+roasbeef> cdecker: a pre-req is adding _error codes_ 12:08 < cdecker> We can talk about adding metadata, for specific ones, but not mandate a fix structure 12:08 <+roasbeef> which allows them to be enumerated 12:08 < BlueMatt> unless there's a structure for exactly how to handle the error code, dont send it 12:08 <+roasbeef> by structure I mean tlv values here, which are malleable 12:08 < cdecker> Yeah, and 99% will be `ERROR_OTHER` with a string repr :-) 12:08 <+roasbeef> things aren't that black and white.... 12:08 < ariard> class of errors are easy, in case of doubt send $UNDEFINED 12:08 <+roasbeef> idk we've gone thru lnd and have about 15 or so errors we'll start making more defined w/ error codes 12:08 < BlueMatt> cdecker: right, at which point we might as well not add the error flags anyway 12:09 < BlueMatt> if there's something we can do with them, then, yea, lets define errors, I'm just saying lets say what you can/may want to do with them when we define the error flags 12:09 < bitconner> what's wrong with error code + description? 12:09 < t-bast> but shouldn't those well-defined errors instead inspire new dedicated protocol messages instead? 12:09 < BlueMatt> bitconner: nothing, as long as what action should be taken on each error code is well-defined 12:10 < BlueMatt> we already have a mess of error codes with htlc forwarding 12:10 < t-bast> in your example of funding being rejected, it looks to me we should just better define a renegotiation of parameters in that case 12:10 < BlueMatt> parsing those things to figure out who is to blame and who blames who and what to do in response is a mess. 12:10 <+roasbeef> t-bast: lnd in the past just used the first byte for the error code, very easy to re-add that and standardize it, then the payload after that can be a TLV, really easy to roll out 12:10 < bitconner> gotcha, iiuc the goal would be to enumerate as many of them as possible, and really minimally on the actual description 12:10 < bitconner> that makes sense 12:11 < BlueMatt> I'm just saying dont over-impose structure unless we have something specific we want to do with it, otherwise we end up back where we are with htlc error codes. 12:12 < BlueMatt> so, like, impose structure on the basis of what we expect a counterparty to (maybe) do in response, not on the basis of what category of error it is 12:12 < ariard> maybe we should come first with a list of cases where more defined errors would provide values for a error-parsing implem 12:12 < cdecker> Isn't using the first byte as type a violation of bolt2, or at least preventing it from being printed? 12:12 <+roasbeef> ariard: yeh we have those to publish soon 12:12 < BlueMatt> I guess I'm just suggesting a different way to categorize errors which I think is more useful in general. 12:12 < cdecker> Rather add a TLV with the type byte at the end, that's backward compatible 12:12 < t-bast> ariard: ACK 12:12 <+roasbeef> cdecker: is it? ppl have handled it fine for years, this was our error before we did the bolt stuff 12:12 < ariard> roasbeef: okay let's hold on the conv until then 12:13 <+roasbeef> adding a tlv to a variable length field can't really work, I've pointed it out a few times in the past... 12:13 <+roasbeef> to the end 12:13 <+roasbeef> ariard: def, idk what's even being talked about rn lol 12:13 < cdecker> roasbeef: the spec says not to print it verbatim if there are non-ASCII chars, which couldmean escape them, but that'll mangle the printed message 12:13 < ariard> roasbeef: something something error codes :p 12:13 <+roasbeef> kek 12:13 <+roasbeef> g2g, peace y'all 12:13 < cdecker> roasbeef: the message is length-prefixed, so it is clear where the TLV starts 12:14 <+roasbeef> cdecker: but what if the length exceeds the full msg size? 12:14 <+roasbeef> just like w/ the init message, in theory there could be so many feature bits it takes up the entire message 12:14 < BlueMatt> then its invalid, throw it away? 12:14 < cdecker> Exactly 12:15 < cdecker> Then fill it up to the end and don't add a TLV, or don't be so verbose and have a TLV 12:15 <+roasbeef> that req isn't spelled out anywhere afaik, just pointing out the inconsistency 12:15 < cdecker> I don't see the issue 12:15 < jkczyz> ok, for sake of time I'd say we should move on. is there an action item here? 12:16 < BlueMatt> it sounds like roasbeef to propose more concrete error codes and structure so we can have a more concrete discussion 12:16 < t-bast> Carla KC said she'd post something to the ML soon 12:16 < cdecker> Yep, but let's look at that as a later extension to the existing proposal 12:16 < t-bast> let's wait for that to discuss further 12:17 < jkczyz> #action follow up discussion after more concrete proposal is available 12:17 < jkczyz> #topic Funding expiry #839 12:17 < cdecker> Ok, got to run off. Nice seeing you all again (can't wait for a real-life meeting again...) 12:17 < t-bast> jkczyz: if people are dropping off, we can keep this one for next time, there's no rush 12:18 < t-bast> Or people can have a look at it directly on Github 12:18 < ariard> yeah we can start by this one next time 12:18 < jkczyz> t-bast: sure, looks like you were looking for more feedback 12:18 < t-bast> Damn right I missed real-life events 12:18 < jkczyz> #action follow up in GH 12:18 < ariard> t-bast: overall i'ts just a gentlemann agreement on the fundee-side 12:18 < ariard> no way to make it chain enforceable ? 12:18 < t-bast> ariard: yes exactly, but at least it makes it known to the funder what deadline he should enforce 12:19 < t-bast> so the funder can do its CPFP accordingly 12:19 < ariard> right, if you're a nice fundee yoou might even give a grace period of few blokcs past the deadline 12:19 < ariard> fee-bumping is a best effort :D 12:20 < bitconner> it's not clear to me what this adds exactly? 12:20 < t-bast> exactly, I planned for eclair to be a nice fundee and give a few blocks of leeway 12:20 < t-bast> bitconner: it helps avoid paying for two on-chain transactions for nothing in case funding times out... 12:21 -!- sword_sm1th [sword_smit@bitcoinfundamentals.org] has joined #lightning-dev 12:21 < ariard> bitconner: AFAICT, double-spend the funding after the deadline 12:21 < t-bast> I laid out that scenario in the PR description, we have a few users that try to optimize funding fees and ran into it a few times 12:21 < bitconner> why not just double spend the coins? 12:21 < t-bast> because they can't know the deadline is met right now 12:21 < t-bast> they only discover it after funding tx confirms and the other party doesn't react 12:21 < ariard> it's a way for both counterparties to clean their states nicely 12:22 < bitconner> i see, so after funding_expiry the funder could make the descision to double spend if CPFP fails? 12:23 < ariard> yeah and if your counterparty did have a push_msat, don't count on it anymore 12:23 < t-bast> yes exactly, it lets both sides know what the timeout should be instead of a value hidden in the implementation 12:24 < bitconner> what should the sender do if the fundee says 10 years? 12:24 < bitconner> funder* 12:24 < t-bast> the fundee doesn't say anything 12:24 < bitconner> i.e. does the funder need to also propose 12:24 < bitconner> ? 12:24 < t-bast> that's covered in the PR, isn't it? 12:24 < t-bast> only the funder proposes 12:24 < ariard> jkczyz: don't forget to call endmeeting, otherwise you will have bad kharma until next meeting ;) 12:24 < bitconner> ah okay, i had them mixed up 12:24 < t-bast> if the fundee is not ok with the timeout proposed by the funder, he just rejects 12:25 < bitconner> gotcha 12:25 < jkczyz> ariard: finger is on the button 12:25 < t-bast> I might need to dive into the details of what "reject" means at that point in the channel's lifetime 12:25 < bitconner> sounds useful to me :) 12:25 < t-bast> we have at least one user who'd really love to have it :D 12:25 < ariard> it might be used as signaling with towers to cancel a watching period 12:26 -!- Netsplit *.net <-> *.split quits: sword_smith 12:26 < t-bast> I gotta go, but thanks everyone for the meeting and thanks jkczyz for chairing! 12:26 < jkczyz> #endmeeting 12:26 < bitconner> depends on if the tower is ever aware of when a channel is created ;) 12:26 < jkczyz> t-bast: thanks the hand holding! 12:26 < bitconner> thanks everyone! 12:26 < ariard> thanks, see you! 12:27 < t-bast> jkczyz: you did great ;) 12:27 -!- johnzweng [~johnzweng@80-108-14-34.cable.dynamic.surfer.at] has quit [Ping timeout: 260 seconds] 12:27 -!- t-bast [~t-bast@5.50.145.86] has quit [Quit: Leaving] 12:29 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 240 seconds] 12:34 -!- bmancini55 [9a1516ee@154.21.22.238] has left #lightning-dev [] 12:57 -!- sword_sm1th [sword_smit@bitcoinfundamentals.org] has left #lightning-dev [] 12:58 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has joined #lightning-dev 12:59 < cdecker> Definitely, well done jkczyz 👍 12:59 < jkczyz> cdecker: thanks! 13:01 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev 13:07 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 240 seconds] 13:10 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev 13:35 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 13:35 -!- laptop [~laptop@ppp-0-79.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev 13:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 13:37 -!- laptop_ [~laptop@ppp-0-143.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds] 13:39 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 240 seconds] 13:41 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 13:41 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev 13:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 13:46 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Ping timeout: 264 seconds] 13:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 13:51 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 13:56 -!- lukedashjr is now known as luke-jr 13:57 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev 13:58 -!- arshbot [~arshbot@c-71-56-28-55.hsd1.ga.comcast.net] has quit [Ping timeout: 264 seconds] 14:07 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!] 14:08 -!- arshbot [~arshbot@c-71-56-28-55.hsd1.ga.comcast.net] has joined #lightning-dev 14:16 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev 14:18 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev 14:19 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has quit [Ping timeout: 268 seconds] 14:19 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Ping timeout: 256 seconds] 14:27 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 15:10 -!- arshbot [~arshbot@c-71-56-28-55.hsd1.ga.comcast.net] has quit [Ping timeout: 264 seconds] 15:16 -!- arshbot [~arshbot@c-71-56-28-55.hsd1.ga.comcast.net] has joined #lightning-dev 15:27 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev 15:36 < lndbot> how can i interact with c-lighting's commitment transactions? i think they are stored in ~/.lightning/bitcoin/lightningd.sqlite3 15:36 < niftynei> they're the last_tx field in the channels table 15:36 < lndbot> ok, i'll have a look 15:42 -!- arshbot [~arshbot@c-71-56-28-55.hsd1.ga.comcast.net] has quit [Ping timeout: 240 seconds] 15:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:47 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev 15:49 -!- arshbot [~arshbot@c-71-56-28-55.hsd1.ga.comcast.net] has joined #lightning-dev 16:01 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev 16:05 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Ping timeout: 268 seconds] 16:31 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev 16:35 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] 16:35 -!- belcher_ is now known as belcher 16:45 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 16:54 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 256 seconds] 16:58 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev 17:10 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 17:17 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev 17:25 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 17:36 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] 17:38 -!- laptop [~laptop@ppp-0-79.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 264 seconds] 17:42 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 18:03 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 264 seconds] 18:03 -!- knocte [knocte@booster.qnetp.net] has quit [Ping timeout: 265 seconds] 18:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds] 18:04 -!- kamyl [~user@unaffiliated/kamyl] has quit [Ping timeout: 272 seconds] 18:04 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds] 18:14 -!- knocte [knocte@booster.qnetp.net] has joined #lightning-dev 18:15 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has joined #lightning-dev 18:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 18:18 -!- rdymac [uid31665@gateway/web/irccloud.com/x-cnchuvzpidkousuh] has quit [Quit: Connection closed for inactivity] 18:20 -!- kamyl [~user@unaffiliated/kamyl] has joined #lightning-dev 18:35 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev 18:37 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 18:38 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Remote host closed the connection] 18:38 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 19:50 -!- kexkey [~kexkey@static-198-54-132-124.cust.tzulo.com] has quit [Ping timeout: 256 seconds] 20:17 -!- kexkey [~kexkey@static-198-54-132-140.cust.tzulo.com] has joined #lightning-dev 20:18 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds] 20:49 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 20:51 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 21:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 21:55 -!- fiatjaf2 [~fiatjaf@2804:7f2:2a8b:8a99:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 265 seconds] 21:57 -!- fiatjaf2 [~fiatjaf@2804:7f2:298a:709b:ea40:f2ff:fe85:d2dc] has joined #lightning-dev 22:02 -!- Xaldafax [~Xaldafax@cpe-104-34-193-119.socal.res.rr.com] has quit [Quit: Bye...] 22:15 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye] 22:17 -!- achow101 [~achow101@unaffiliated/achow101] has joined #lightning-dev 23:51 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev 23:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev 23:59 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] --- Log closed Tue Feb 02 00:00:33 2021