--- Log opened Mon Aug 30 00:00:53 2021 00:02 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 01:00 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 01:30 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #lightning-dev 01:31 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 240 seconds] 01:32 -!- lukedashjr is now known as luke-jr 03:22 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev 03:55 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.] 04:07 -!- nathanael [~nathanael@user/nathanael] has quit [Quit: connection reset by purr] 04:07 -!- nathanael [~nathanael@user/nathanael] has joined #lightning-dev 05:07 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection] 05:07 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #lightning-dev 05:21 -!- bitdex_ [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:26 -!- smartin [~Icedove@88.135.18.171] has joined #lightning-dev 06:10 -!- plankster is now known as plank 06:10 -!- plank is now known as plankton 06:59 -!- smartin [~Icedove@88.135.18.171] has quit [Ping timeout: 244 seconds] 07:17 -!- smartin [~Icedove@88.135.18.171] has joined #lightning-dev 07:28 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 07:36 -!- jarthur [~jarthur@2603-8080-1540-002d-55ae-d7d8-7bcf-ce25.res6.spectrum.com] has joined #lightning-dev 08:06 -!- AaronvanW [~AaronvanW@190.86.109.168] has joined #lightning-dev 09:09 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has quit [Quit: The Lounge - https://thelounge.chat] 09:16 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has joined #lightning-dev 09:17 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 09:26 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has quit [Quit: The Lounge - https://thelounge.chat] 09:28 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev 09:29 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 09:29 < lnd-bot> [lightning-rfc] t-bast merged pull request #902: BOLT 7: remove 2^32 restriction from channel_update as well. (master...gossip-wumbo-too) https://github.com/lightningnetwork/lightning-rfc/pull/902 09:29 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 09:29 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 09:29 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/07c7caed516f...d892c318af3b 09:29 < lnd-bot> lightning-rfc/master d892c31 Rusty Russell: BOLT 7: remove 2^32 restriction from channel_update as well. (#902) 09:29 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 11:51 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 252 seconds] 12:38 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev 12:56 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev 12:59 < BlueMatt> meeting time? 13:00 < t-bast> Hey guys! I'm catching up on the comments on the PRs from the last 10 minutes :) 13:00 < ariard_> hi, still reviewing fews 13:01 < t-bast> looks like review time is allocated 30 minutes before the meeting :D 13:01 < rusty> Hello all! 13:01 < vincenzopalazzo> t-bast: Right ahhaha 13:01 < vincenzopalazzo> rusty: Hello Rusty 13:01 < BlueMatt> t-bast: lol clearly 13:01 < rusty> For me it's Tuesday stupid-o-clock, so Monday is my "um, what did I promise last meeting" time... 13:02 < t-bast> haha, it happens to everyone 13:03 < BlueMatt> lets start? 13:03 < t-bast> yep! 13:03 < t-bast> roasbeef should be around, he's reviewing stuff right now :) 13:03 < t-bast> #startmeeting LN Dev Meeting 13:04 < niftynei> #link agenda https://github.com/lightningnetwork/lightning-rfc/issues/901 13:04 < t-bast> #ZeBotIsDed? 13:04 < ariard_> again 13:04 < BlueMatt> cdecker[m]: ? 13:04 < BlueMatt> well lets go anyway 13:04 < t-bast> let's do without, thanks niftynei for the link 13:04 < BlueMatt> already late 13:04 < niftynei> :thumbs_up: 13:05 < t-bast> #topic channel type 13:05 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/880 13:05 < t-bast> Are we good to go with that one? 13:05 < t-bast> roasbeef: on that one, regarding your comment for empty feature bits, don't forget the different between having the tlv present with empty feature bits and having the tlv missing 13:06 < t-bast> TLV present with empty feature bits = default channel (pre-static_remotekey) 13:06 < t-bast> TLV absent = old negotiation based on each node's init feature bits 13:06 < roasbeef> t-bast: what about a node that sets explicit to static remote key as a required bit? 13:06 < roasbeef> those nodes (like us) no longer support pre static remote key funding 13:07 < rusty> Looks like it's acked, needs typo fix 13:07 < roasbeef> but yeh I think lets land it 13:07 < t-bast> roasbeef: then just don't accept this channel type, people shouldn't try it anyway since you require static_remotekey 13:07 < roasbeef> t-bast: since otherwise, you'd force a downgrade? 13:07 < roasbeef> yeh sure 13:08 < t-bast> great then rusty I'll let you fixup the typos and we can merge! 13:08 < t-bast> #action rusty to fix the tiny typos 13:08 < t-bast> #action merge PR 13:08 < t-bast> #topic Peers should check remote dust limit 13:08 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/894 13:09 < BlueMatt> mostly need feedback from roasbeef on https://github.com/lightningnetwork/lightning-rfc/pull/894#discussion_r697111408 13:09 < BlueMatt> rusty: noted we could just do "mutual close must be segwit" in 847 to resolve it 13:09 < rusty> (Can be put 824 on the Agenda pls too... merging this would help kill the previous anchor, and light a fire under me to handle complex tx deps properly so we can properly CPFP) 13:09 < BlueMatt> and then we can just say dust limit below 354 is not allowed 13:09 < t-bast> What I'd like to discuss now is the comment BlueMatt mentioned, about shutdown and non-segwit outputs 13:10 < ariard_> yeah looking on 824 rn if we have forgot nothing 13:10 < roasbeef> rusty: +1, totally forgot about that one lol 13:11 -!- smartin [~Icedove@88.135.18.171] has quit [Quit: smartin] 13:11 < t-bast> Let's do 824 right after #894? 13:11 < roasbeef> BlueMatt: is that linking to the right comment? 13:11 < BlueMatt> mostly, roasbeef are you ok with requiring segwit shutdown scripts? 13:12 < roasbeef> ah sure, makes sense 13:12 < roasbeef> why'd you do anything else tbh 13:12 < BlueMatt> yea, basically 13:12 < roasbeef> would* 13:12 < BlueMatt> roasbeef: yes, I linked to the correct comment 13:12 < BlueMatt> roasbeef: its all interrelated cause the dust limit set in the channel impacts how cooperative-close outputs are included or not 13:12 < rusty> Yes, let's burn the boats... it's been years, anyway. 13:12 < t-bast> So just to be sure: shall we remove the option to do non-segwit in shutdown from the spec directly in #894? 13:12 < BlueMatt> so dust limit on the channel can interact with cooperative close 13:13 < BlueMatt> t-bast: I dont care how it lands 13:13 < BlueMatt> rusty: suggested in 847 13:13 < roasbeef> BlueMatt: gotcha, makes sense 13:13 < BlueMatt> which we should also disucss 13:13 < BlueMatt> t-bast: I'd say put it in 894 cause 847 is already delayed enough 13:13 < BlueMatt> then we can Just Merge 894 with a "dust limit below 354 is not allowed" 13:14 < t-bast> Can you share after the meeting how you got to 354, in a gist or something? My calculations and bitcoind tests didn't get this value anywhere 13:14 < roasbeef> ahh the elusive dust derivation 13:14 < BlueMatt> I'd rather you calculate it fresh and tell me if you agree :p 13:14 < roasbeef> lmao 13:14 < ariard_> t-bast: maybe we should precise if the scriptpubkey is unknown SegWit v1+, allow any dust limit 13:14 < t-bast> Ok I will push to #894 to remove the non-segwit option 13:15 * roasbeef summons crypt-iq 13:15 < t-bast> BlueMatt: I did, I found 294 sats and 330 sats detailed in the PR ;) 13:15 < BlueMatt> t-bast: oh, i missed that, I'll follow you. t-bast did you test for maximum-size segwit v-X 13:15 < BlueMatt> t-bast: which IIRC is like 42 byte sPKs or so 13:15 < ariard_> 330 sats for p2wsh match my calculations iirc 13:15 < BlueMatt> what about p2-witness-v2-length-40-bytes? 13:16 < t-bast> BlueMatt: I just took bitcoind's code for calculating a dust value, even though some choices there are arbitrary, they're the default rule of the network so I went with it 13:16 < BlueMatt> t-bast: yes, did you calculate it for max-length witness output which is a future witness version? 13:16 < BlueMatt> t-bast: cause those are standard and allowed today 13:16 < t-bast> ariard_: good point for segwit v1+, I'll think about that and amend the PR 13:17 < t-bast> BlueMatt: not yet, I indeed should add that 13:17 < BlueMatt> alright, moving on? 13:17 < t-bast> #action t-bast to remove non-segwit option in shutdown and clarify dust for segwit v1+ 13:17 < t-bast> #topic anchor_output_htlc_zero_fees 13:18 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/824 13:18 < roasbeef> also wait remove non-segwit w/o addition of a feature bit (y'all know how much I love feature bits) 13:18 < BlueMatt> roasbeef: yes, without a feature bit, but i think that's why rusty was suggesting it in 847 13:18 < ariard_> just one remark on 824, i would make it clearer HTLC-success/timeout must be zero fees for trimmed outputs computation 13:19 < BlueMatt> roasbeef: does anyone send non-segwit outputs for closing by default (i assume most will allow user-specified, but still) 13:19 < roasbeef> idk, we don't do it by default, but maybe another impl like BLW (I think that's still around?) does 13:19 < roasbeef> in theory someone could set it using a manaul up front shutdown addr, and we'll accept it and store it 13:19 < BlueMatt> sure, but you aren't re-negotiating the dust fee on that channel either 13:20 < BlueMatt> but, worst case you force-close while closing 13:20 < BlueMatt> which isn't exactly the worst thing in the world 13:20 < roasbeef> but an existing channel can advertise it and we'd either need to accept it or deny 13:20 < t-bast> ariard_: yes the only thing I'm doubting where we may have incompatibilities is trimmed outputs computation for this PR 13:20 < roasbeef> there's potential to handle it more gracefully tho 13:20 < rusty> Yeah, we'll have to go through a deprecation cycle where we stop people trying to close to non-segwit, and probably immediately stop them from making them upfront... 13:20 < roasbeef> force close may not be the worst thing to you, but ofc users hate it 13:21 < roasbeef> rusty: so something something optional feature bit turning into required? 13:22 < BlueMatt> I mean you currently allow counterparties to create unbroadcastable shutdowns 13:22 < rusty> roasbeef: we could, but if nobody every notices, is it worth the hassle? 13:22 < BlueMatt> so you gotta force-close anyway :) 13:23 < t-bast> I'm mostly of the opinion here that this isn't worth the hassle indeed...at the implementation level you can choose to keep accepting non-segwit scripts for a while if you want 13:23 < roasbeef> idk, it's a weird move imo to make previously co-op closeable channels now uncloseable w/o a force close 13:23 < roasbeef> analogous (but ofc not the same) to making prior spendable outputs now unspendable onchain 13:23 < BlueMatt> but, indeed, you can/should accept them for some time yet 13:23 < BlueMatt> the feature bit doesn't really change anything 13:23 < BlueMatt> you accept them until you dont 13:23 < BlueMatt> and at that point you dont accept them 13:23 < roasbeef> tho as t-bast mentions that might be a side effect of some of the newly proposed dust smenatics? 13:23 < BlueMatt> a feature bit doesn't change that process realy 13:24 < roasbeef> yes it does, it makes it explicit 13:24 < BlueMatt> you can send an error message which is pretty explicit :) 13:24 < roasbeef> kek 13:24 < t-bast> roasbeef: not really because right now lnd doesn't validate the remote dust, so you let people close to dust which is an issue... 13:24 < t-bast> roasbeef: the issue there is that you accept a closing_tx that won't be able to relay, so you will have to force-close (with the current code in lnd/c-lightning at least) 13:25 < BlueMatt> but, seriously, I dont see how its any more or less explicit with a feature bit 13:26 < BlueMatt> roasbeef: ? 13:26 < roasbeef> BlueMatt: w/ a bit, you know not to send me non-segwit close, sending a non-segwit addr in a chan open is explcitily invalid 13:26 < roasbeef> chan open as part of an upfront shutdown 13:26 < BlueMatt> presumably you'll not send them starting tomorrow 13:26 < BlueMatt> so it doesnt change your behavior at all 13:27 < BlueMatt> if someone sends you an old script, you know they are old 13:27 < BlueMatt> call it an implicit feature bit :) 13:27 < roasbeef> so from an API perspective, we need to start to reject chan open attempts that use a non-segwit upfront shutdown addr? 13:27 < t-bast> roasbeef: that's an implementation detail, for channels created before you change this code that have a non-segwit upfront, you would keep allowing it (a feature bit wouldn't make it simpler, would it?) 13:27 < BlueMatt> you can even calculate an implied feature bit after you get a channel open :) 13:27 < roasbeef> vs allow it now, signal to users, add the bit, then depecrate it over time w/ a quired bit? 13:27 < BlueMatt> roasbeef: that's up to you. you either reject them or don't reject them as you see fit, the spec will say SHOULD, and you can do it on the timeline you like 13:28 < BlueMatt> you can deprecate it over time whether there's a bit or not 13:28 < roasbeef> t-bast: ok I see what you're saying, yeah you need to allow them to keep using it 13:28 < t-bast> roasbeef: exactly, we should in the next releases prevent people from closing to non-segwit scripts, and in the one after that (or N releases later) reject non-segwit in shutdown 13:28 < BlueMatt> in fact, I'd say, your code should probably be on the same schedule either way 13:28 < t-bast> roasbeef: with the exception of already existing upfront channels 13:28 < roasbeef> idk just feels like we're ignoring some tools here that make updates like this easier, and w/ the way the spec is someone could have an older impl, boot it up and now need to pay a ton of fees to force close everything that they could've just co-op closed before w/ their peers 13:29 < t-bast> roasbeef: on the contrary, it would be worse with a feature bit 13:29 < roasbeef> if it's just us tho, then yeah we can prob just do this, and let ppl decide how to handle it on the API perspective 13:29 < BlueMatt> aren't you the one who hates adding bits on the wire cause it makes messages larger :p 13:29 < rusty> roasbeef: I wonder if anyone has upfront shutdown scripts which are non-segwit today? They'll be the real losers. 13:29 < t-bast> roasbeef: an old node waking up and seeing a required feature bit it doesn't about will brick everything, whereas they're likely using segwit which means everything would be fine to just continue as it went before 13:29 < roasbeef> BlueMatt: not bits generally, just very high ones in the 10s of thousands, but we know how to solve that if we want to (sparse encoding) 13:30 < roasbeef> since as is the "experimental" bit section, means a few KB of zeros at times 13:30 < roasbeef> t-bast: true 13:30 < roasbeef> rusty: good q, idk, but in theory there may be lnd nodes in the wild w/ that, guess they'll have to eat the fees or w/e, hopefully they aren't too angry about that lol 13:31 < roasbeef> ok I guess the old ppl will just have to deal w/ it 13:31 < rusty> ... actually, none of my peers atm have set upfront_shutdown_script, so maybe it's not normal 13:31 < t-bast> since lnd implemented shutdown script recently, I'd be surprised if there were many of them using non-segwit 13:32 < t-bast> same for eclair, we implemented it recently, and I think none of our peers use it yet 13:32 < BlueMatt> we had been setting it aggressively, but bluewallet got mad and wanted it off 13:32 < BlueMatt> so I guess many users actively dislike it :p 13:32 < ariard_> well someone might have a weird use-case, closing to an OP_RETURN output flag 13:32 < t-bast> That's probably because it's not a very good protection against anything... 13:33 < t-bast> Because if your node gets hacked, upfront shutdown script will not save you 13:33 < BlueMatt> no, it doesn't do very much 13:33 < roasbeef> t-bast: recently? we've had it for a while now: https://github.com/lightningnetwork/lnd/pull/3655 (2 years ago) 13:33 < BlueMatt> anyway, so it sounds like roasbeef agrees, should we move on? 13:33 < rusty> roasbeef: t-bast is showing his age :) 13:34 < roasbeef> our main use case in the servies we run is to avoid an extra sweep transaction into another wallet when somethign gets co-op closed 13:34 < t-bast> roasbeef: it's 2 years ago already??? I remembered that carla implemented that, and I thought she joined...somewhat recently...damn time flies! 13:34 < roasbeef> yeah we're all old now.... 13:34 < roasbeef> 824 now? 13:34 < BlueMatt> yea 13:35 < t-bast> I'll add a commit to #894 where I'll mention everything we discussed here and we can review that on github 13:35 < BlueMatt> thanks, t-bast sounds like we agreed on no feature bit 13:35 < t-bast> :+1: 13:35 < rusty> +1 13:35 < t-bast> Let's go for #824 13:36 < roasbeef> so 824 is pretty old, totally forgot about it, has an approval from rusty, an impl for a while in lnd, and is linked in the chan_type PR 13:36 < t-bast> Does anyone have a working implementation? As ariard_ mentioned, I think the only place where we may have a misunderstanding is the trimmed to dust calculation 13:36 < roasbeef> johan doesn't really work on LN stuff anymore, but I can take over the PR (I see it has a fixup commit), tho maybe I can ping him to rebase it if needed 13:36 < t-bast> roasbeef: can you do a quick check about this trimmed to dust case? 13:36 < ariard_> Not yet, on my todo once we're done with 0.0.101 on the LDK side 13:36 < roasbeef> sure, you have a link to the comment? 13:37 < rusty> Yeah, while we don't have a second impl, it's deployed, trivial and helps kill the anchor-with-fees previous one. 13:37 < t-bast> roasbeef: or you can just use the `squash and merge` github option :) 13:37 < roasbeef> ahh I see 13:37 < roasbeef> t-bast: ayee true 13:37 < roasbeef> I think we already to that in our impl, can double c heck sec 13:37 < t-bast> roasbeef: https://github.com/lightningnetwork/lightning-rfc/pull/824#pullrequestreview-742028638 13:38 < t-bast> I'm ok with merging it if we're sure the trimming to dust works as we'd expect (not including HTLC 2nd-stage fees) 13:38 < ariard_> I think lnd is already implementing the 0-fees on trimming-or-not HTLC outputs 13:38 < roasbeef> ok yeh confirmed we do it as zero 13:39 < ariard_> and I intend to implement it that way for LDK, though would be nice to clarify 13:39 < roasbeef> https://github.com/lightningnetwork/lnd/blob/master/lnwallet/commitment.go#L286 13:40 < t-bast> I intend to implement it that way as well for eclair, so LGTM 13:40 < roasbeef> ok, so just need to make that explicit in this PR? 13:40 -!- crypt-iq [~crypt-iq@2603-6080-8f06-6d01-c534-15e3-2e3d-d67a.res6.spectrum.com] has joined #lightning-dev 13:40 < roasbeef> ok no that's already there: https://github.com/lightningnetwork/lightning-rfc/pull/824/files#diff-6bed824879b760d329ec379b16a1d0e78ffba034fdfa13b95cf0480e09fa7c4bR421 13:40 < roasbeef> so we're g2g on this one? 13:41 < ariard_> yeah this section is just coming *after* the trimmed outputs ones and might confuse the reader 13:41 < ariard_> see also the point on "MAY combine the HTLC transaction with other transactions" which I would recommend not to do 13:41 < t-bast> There's a comment by rusty about the fact that it doesn't depend on static_remotekey...? 13:42 < t-bast> https://github.com/lightningnetwork/lightning-rfc/pull/824#discussion_r579892815 13:42 < rusty> Oh yeah, it's gotta depend on static_remotekey. I mean, in practice ofc it will, but let's make it clear. 13:42 < roasbeef> t-bast: I think that's an artifact of the way we impl'd it, given that we always have a non-static key for anything anchor based, since felt natural to build on top of it 13:42 < roasbeef> I can add that 13:43 < rusty> non-static for anchors? Is that a typo? 13:43 < roasbeef> err yeh static 13:43 < rusty> Phew!! 13:43 < roasbeef> anchors means static 13:43 < roasbeef> requires it 13:43 < t-bast> roasbeef: I see what you mean, that's something that kinda bothered me as well but since anchor_outputs depends on static_remotekey anchor_outputs_zero_fee should to 13:44 < roasbeef> I guess it's kinda transitive as written rn 13:44 < roasbeef> since: https://github.com/lightningnetwork/lightning-rfc/pull/824/files#diff-c3e160eeb369e80b50a24ceee86928786ae3b67a0687a7aea80e8cefac0145daR46 13:44 < roasbeef> and above that, anchors mentions static key? 13:44 < ariard_> ad that's already assumed in #880 i think 13:44 < roasbeef> yeh so that's ok if we like that added definition at the end there 13:45 < roasbeef> tho on second glance, not sure what it's trying to do there... 13:45 < rusty> It's just not in the table. Used to be transient when option_anchors_zero_fee_htlc_tx depended on option_anchor_outputs, but we rightly killed that. 13:45 < rusty> s/transient/transitive/ damn more coffeee... 13:46 < t-bast> I think it would be clearer if the table of features in Bolt 9 clearly mentioned `option_static_remotekey` in the `Dependencies` of `option_anchors_zero_fee_htlc_tx` 13:46 < roasbeef> gotcha yeh, looking at the rendered version it's blank rn in that spot 13:46 < roasbeef> t-bast: yeh def 13:46 < t-bast> Ok so I think we can just clear these comments on Github this week, re-ACK and merge? 13:47 < roasbeef> t-bast: sgtm 13:47 < ariard_> yeah sgtm 13:47 < t-bast> #action roasbeef to fix last comments, others to ACK and merge 13:48 < t-bast> #topic new closing_signed is awesome 13:48 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/847 13:48 < roasbeef> ok merge now, then I made a new branch adding the table thing? 13:48 < t-bast> roasbeef: ACK for me if others are ok 13:48 < roasbeef> since the chan_type PR also mentions it 13:48 < ariard_> yeah do a follow-up PR if you think it's easier 13:48 < t-bast> We can indeed submit a follow-up small PR to address the comments to unblock the early merge 13:49 < roasbeef> cool 13:49 < t-bast> #action merge 824 and address latest comments in a follow-up PR 13:49 < BlueMatt> ok, 847 is another one of these 6+month old prs, we need to land this. 13:50 < BlueMatt> we went ahead and shipped an 847 implementation cause it was an excuse to solve several existing issues and it had acks and cross-impl tests from > 2 implementations 13:50 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 13:50 < lnd-bot> [lightning-rfc] Roasbeef merged pull request #824: feature: define option_zero_htlc_tx_fee (feature 22/23) (master...zero-fee-second-stage) https://github.com/lightningnetwork/lightning-rfc/pull/824 13:50 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 13:50 < BlueMatt> it seems the only thing holding it up is roasbeef 13:50 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 13:50 < lnd-bot> [lightning-rfc] Roasbeef pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/d892c318af3b...fdc078f845e1 13:50 < lnd-bot> lightning-rfc/master fdc078f Johan T. Halseth: feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) 13:50 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 13:51 < BlueMatt> roasbeef: can you explain your concern with no feature bit here? 13:51 < BlueMatt> and, specifically, what you will implement differently with or without a feature bit in lnd 13:51 < t-bast> roasbeef: IIUC regarding 847, your current objection is whether we should add a feature bit right? There's nothing else? 13:51 < t-bast> I can understand in theory the argument to allow nodes to explicitly seek it (I don't want to open channels to nodes that use only the old negotiation) 13:52 < t-bast> But I'm not sure it's actually useful in practice 13:52 < rusty> Yeah, I've been calling 847 quick close internally in the implementation BTW. 13:52 < BlueMatt> well, I think someone would have to speak up and say that they plan on implementing that behavior 13:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 13:52 < lnd-bot> [lightning-rfc] Roasbeef pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/d892c318af3b...fdc078f845e1 13:52 < lnd-bot> lightning-rfc/master fdc078f Johan T. Halseth: feature: define option_zero_htlc_tx_fee (feature 22/23) (#824) 13:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 13:52 < t-bast> If everyone ships that soon (because it's quite simple to implement), since nodes must upgrade lightning often at the moment (we're constantly fixing important bugs), I don't think this scenario is worth handling 13:52 < roasbeef> t-bast: is there a downside tho? 13:53 < BlueMatt> yes, complexity and more code and cases to check 13:53 < BlueMatt> the shutdown fee negotiation stuff is already a big if tree 13:53 < roasbeef> I have an impl that's like 80%of the way there, but then i realized that if the behavior wasn't gated it broke a buncha tests since we exercised the prior behavior to make sure it terminates, etc 13:53 < BlueMatt> you can chose to implement, or not, the relaxed cases, and presumably you wont for some time 13:53 < t-bast> yes, I'd say the downside is more code and conditional branches, whereas without a feature bit it's really simple, you just look at whether a TLV is here or not 13:54 < crypt-iq> Any implementation needs to have a branch here already, a feature bit just makes it explicit up-front and is IMO nicer to have 13:54 < roasbeef> I don't understand how it's meant to behave if one side sends it and the other doesn't understand it, if one side had the feature bit and the other didn't, then the sender would know just _not_ to send it and fall back to the normal behavior right? 13:54 < roasbeef> yeh since you need to handle that fall back any way right? 13:54 < t-bast> crypt-iq: the issue is that you then have two different `if`, it doesn't replace the existing one 13:55 < BlueMatt> roasbeef: you can always calculate an implicit feature bit locally :p 13:55 < niftynei> i mean the diff is in one case you know not to send it, in the other you send it and then wait and see what they respond, no? 13:55 < t-bast> it's much simpler to always send it (it's an odd tlv), less code and be done with it 13:55 < BlueMatt> if (tlv is present) { node.featurebits |= internal_flag } 13:55 < roasbeef> niftynei: yeh that's my understanding 13:55 < t-bast> with a feature bit you need to handle the non-compliant cases (the feature bit is set but not the tlv, or the other way around) 13:55 < niftynei> "where is the if" 13:55 < roasbeef> but I don't understand what happens w/ the "wait and see" 13:56 < t-bast> so with feature bit there's more `if`s than without it... 13:56 < roasbeef> at that point, you don't know if htey could parse it or not (right?), so you need to be able to handle them not using your guidelines? so it insta falls back to the existing behavior? 13:56 < crypt-iq> t-bast: Oh I see what you mean, then you'd just bail 13:56 < crypt-iq> I think it's easier to reason about changes with a feature bit, and they're cheap 13:56 < BlueMatt> roasbeef: you can still enforce the guidelines 13:56 < niftynei> roasbeef: what happens is you have an if stmt later, not earlier?? 13:56 < BlueMatt> (we do, in fact) 13:57 < BlueMatt> crypt-iq: after implementing it I think it'd be much more complicated to have to check the feature bits :) 13:57 < roasbeef> niftynei: not sure if I understand the context here, but i'm just confused w.r.t what type of expectations both sides can have 13:57 < BlueMatt> its rather easy to just implement the old negotiation as a function of the new negotiation parameters 13:57 < t-bast> crypt-iq: yes, it's just boring, additional code that can be avoided and would likely be implemented differently by each impl, leading to some inconsistencies and users opening issues...if I were to add a feature bit to the implementation in eclair, I'm pretty sure I'd keep all the current code and add more code, which I consider a loss 13:57 < roasbeef> seems if I know they support it, I know I can pay lower closing fees, if I don't then I go in blind 13:58 < BlueMatt> roasbeef: the expectation is "always send new tlv, if old node doesn't use old negotiation". if you add a feature bit, then you have a 2x2 matrix to handle 13:58 < t-bast> I agree with BlueMatt, checking the feature bit is purely additive to the code required to make this work without it 13:58 < BlueMatt> like, if you wanted to add a feature bit, I'd take the existing code we have, and add a additional if statement and return a force-close if you did something dumb 13:59 < t-bast> exactly 13:59 < BlueMatt> its purely added complexity 13:59 < crypt-iq> Are feature bits then only used in the case something requires explicit negotiation like option_zero_htlc_tx_fee? 13:59 < roasbeef> from my pov it isn't about the force close case, it's about how well this new state machine is defined 13:59 < roasbeef> crypt-iq: imo they should be used to gate new behavior, and also let peers seek out others that understand that behavior 13:59 < rusty> roasbeef: I assumed you can lowball the close with anchors already, since only lnd currently supports it really? 14:00 < BlueMatt> roasbeef: do you have a specific question about the state machine? 14:00 < BlueMatt> I found it quite well-defined 14:00 < ariard_> I agree it's nice to be able to find new closing_signed peers if you expect to have lower closing fees in average 14:01 < ariard_> though it's more a deployment question, once all nodes are upgraded that's a behavior you expect from everyone 14:01 < roasbeef> rusty: yeah, then users needs to just CPFP or w/e if they really care about it 14:01 < t-bast> ariard_: but everyone will offer this very soon, so you don't need to find them, all the network will support it before you actually really need it 14:01 < roasbeef> ariard_: yeh I can't think of any downsides.... 14:01 < BlueMatt> ariard_: someone would have to want to actually *implement* that 14:01 < roasbeef> if that's the case t-bast why do we ever use feature bits at all? 14:01 < BlueMatt> ariard_: I'm not. and no one seems to actually want to do that 14:01 < ariard_> t-bast: that's the point i trying to do, feature bit could be reserved when the feature usage isn't expect to happen in every channel lifecycle 14:02 < t-bast> roasbeef: exactly like ariard_ says, when it's a feature that you wouldn't expect to see everywhere 14:02 < rusty> I originally wanted a feature bit too, FWIW. But "try and see" also technically *works*, so I don't really mind. 14:02 < BlueMatt> roasbeef: we use feature bits to negotiate things where we need backwards compat and need additional negotiation. 14:02 < roasbeef> BlueMatt: what does the sender do if the receiver appears (since no bit?) to not understand it, force close or continue along? what if the channel responder includes it but then the initiator sends something outside the range (they don't understand the new values) 14:02 < BlueMatt> negotiation here is explicit 14:02 < BlueMatt> roasbeef: you continue the negotiation? 14:02 < rusty> (We will eventually have a "modern shit" feature, which will eventually become compulsory and imply all the older ones, freeing up those feature bits for eventual reuse... one day...) 14:03 < roasbeef> so you just have no guarantee at all if the new stuff will be used BlueMatt ? 14:03 < BlueMatt> roasbeef: if the non-initiator sends something out of range then you force-close, it says that. 14:03 < t-bast> rusty: YES to lightning v1.1 14:03 < BlueMatt> roasbeef: what do you mean? you use it, opportunistically, it doesn't make a difference materially except that its simpler to implement 14:03 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has joined #lightning-dev 14:03 < crypt-iq> roasbeef: I think then you fall-back to old negotiation since they didn't send a fee_range TLV 14:04 < BlueMatt> just really means the negotiation happens quicker 14:04 < t-bast> crypt-iq: exactly 14:04 < niftynei> not to curtail the discussion too much, but it feels like a lot of your questions roasbeef would be worked out in the process of implementing it? but i thought LND already had it? 14:04 * niftynei is out of the loop on this clearly 14:04 < roasbeef> niftynei: yeh I got to the point of implementing it, then stopped once these questions popped up 14:04 < t-bast> crypt-iq: and at one point, in X years, when everyone does that or we've shipped the "Modern shit" feature bit, you completely remove the old negotiation code and enjoy seeing your codebase shrink for once xD 14:04 < BlueMatt> I dont get which questions arent answered in the doc 14:05 < roasbeef> impl is here: https://github.com/lightningnetwork/lnd/pull/5644 14:05 < BlueMatt> like, all of your above questions are explicitly answered in the spec pr 14:05 < niftynei> ok if there's specific ques can you put them on the PR? 14:05 < BlueMatt> honestly I dunno how much longer we can delay this 14:05 < niftynei> are roasbeef's questions a blocker for merging the PR seems like the bigger ques here 14:05 < rusty> Implementation wise, it's actually nice to have (if option_quickclose) .... else {old crufty code}, TBH. At the moment they're intermingled, and it's a bit meh. 14:06 < BlueMatt> its been six months, we have acks from multiple implementations, including cross-compat testing. 14:06 < rusty> But IMHO it's transient, so I can live with it. 14:06 < BlueMatt> rusty: but then you have a 2x2 matrix of possible states 14:06 < BlueMatt> instead of just one branch 14:06 < niftynei> +1 to what rusty says fwiw, i did the initial impl in CL and it isn't amazing 14:07 < BlueMatt> We largely merged the impls, it makes them quite simple 14:07 < BlueMatt> use the min/max in both impls 14:07 < niftynei> yeah, they're intermingled 14:07 < BlueMatt> makes the old-style negotiation much simpler :) 14:07 < niftynei> ok so by the 'rules of the spec' it sounds like we've got consensus (3impl and cross-compat) testing for this 14:07 < BlueMatt> so are we merging or is this gonna sit forever? 14:07 < roasbeef> I think from my PoV, this would be easier to understand if it was just like a standalone thing describing the way new things happen vs all the inline if statements in the spec, like it says "SHOULD set `max_fee_satoshis` to at least the `max_fee_satoshis` received" but in the section about the sending node, what about when the responder initaites it, `max_fee_satoshis` isn't defined right? 14:08 < roasbeef> idk maybe I'm just over thinking it 14:08 < roasbeef> in my mind it was simple till I sat down to impl it 14:08 < BlueMatt> huh, can you provide specific questions? 14:08 < ariard_> roasbeef: yeah we all agree that the way we write the spec rn isn't great but that's different from open questions on this specific PR? 14:08 < BlueMatt> cause I found it simple while implementing :) 14:08 < roasbeef> ariard_: yeh that's totally independent, but this is just where I have a hard time understanding what the specified behavior _should_ be 14:09 < t-bast> I think all the inline statements in the spec are mostly because I tried to "factorize" it with existing requirements, I could have separated them cleanly but would have needed some duplication on the requirements (but I agree it may have been easier to read) 14:09 < roasbeef> BlueMatt: the quesiton there is how is `max_fee_satoshis` defined there? in the case where the responder kicks things off 14:09 < roasbeef> here: https://github.com/lightningnetwork/lightning-rfc/pull/847/files#diff-ed04ca2c673fd6aabde69389511fa9ee60cb44d6b2ef6c88b549ffaa753d6afeR589 14:09 < BlueMatt> what do you mean "responder kicks things off"? 14:10 < BlueMatt> the non-channel-initiator never starts the fee negotiation, never has 14:10 < roasbeef> the responder sends a closing_signed message before the initiator does (or it just didn't receive it from the initiator) 14:10 < niftynei> (t-bast: fwiw i typically end up in favor of duplication, esp where documentation is concerned as it decouples processes a lil bit more) 14:10 < roasbeef> any side can send a shutdown message 14:10 < BlueMatt> this is not a shutdown message, its a closing_signed message 14:10 < BlueMatt> the channel initiator always sends first closing_signed 14:10 < BlueMatt> that didng change in this pr 14:11 < t-bast> niftynei: that's what I'll do in next PRs, I really hesitated for that one... 14:11 < t-bast> what BlueMatt says, remember that the initiator starts 14:12 < roasbeef> ahh yeh that's right 14:12 < t-bast> that's a bit hard to remember when only reading the requirements because they're separated as "sender/receiver" 14:12 < niftynei> i think someone (t-bast.?) noticed me duping stuff in the v2 opens PR :P 14:12 < t-bast> but since there's an order, it actually simplifies things 14:12 < t-bast> niftynei: xD 14:12 < ariard_> i think we can merge the PR, and if the wording is found confusing, from proposed suggestions we can always amend, add footnote, extend the rational...? 14:14 < t-bast> that's actually something I think we should be able to greatly simplify in the spec whenever we dump the old negotiation, instead of "sender" and "receiver" requirements we'll be able to have "initiator" and "non-initiator" requirements which will make the flow simpler to read 14:14 < BlueMatt> alright, we've been over time for a while. 14:14 < rusty> ariard_: I think what actually happens is that in 12 months we remove the old scheme, and it's now "A: send shutdown B: reply. A: if reply != send, reply again.". 14:15 < t-bast> rusty: I can't wait to see that happen 14:15 < rusty> Everyone please note https://github.com/lightningnetwork/lightning-rfc/pull/902 where we need to remove channel_update (we missed this, got a bug report) 14:16 < rusty> Quick time to discuss LN summit? 14:16 < roasbeef> I g2g, but will revisit my impl to update it, feel free to merge this as is, tho I still think you want a feature bit there 14:16 < t-bast> roasbeef: in light of the fact that the initiator starts, can you have another look at the state machine and let us know on the PR if you're ok with no feature bits for that one? 14:16 < t-bast> rusty: yay LN summit! 14:16 < roasbeef> t-bast: I still think one should be there, but I think this just exposed that we don't really have a set of consistent rules to use feature bits vs not, when new behavior or functinality is added 14:17 < t-bast> roasbeef: yep, I think we never will be able to have a completely consistent set of rules for that though, it will be on a case-by-case basis and depend on rough agreement :) 14:18 < t-bast> roasbeef: my simple rule of thumb is that if adding a feature bit is actually more complicated and doesn't solve any compelling use-case, we shouldn't add one 14:18 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has quit [Quit: Leaving] 14:18 < t-bast> But let's not re-do the conversation again! 14:18 < roasbeef> t-bast: I think one issue there is "compliacted" as I've seen it defined is pretty langauge/impl dependent: "an extra if statement, oh noes" 14:18 < roasbeef> but yeh I think let's just go ahead w/ it, and we'll catch up eventually 14:19 < t-bast> Great let's go with that version then, thanks! 14:19 < BlueMatt> rusty: do you want to chat about https://github.com/lightningnetwork/lightning-rfc/pull/834#discussion_r698140878 14:19 < t-bast> #action t-bast to merge #847 14:19 < BlueMatt> while we're here 14:19 < BlueMatt> post-meeting 14:19 < BlueMatt> cause I wanna see warnings merged :) 14:19 < t-bast> Good idea, I want to see warnings merged as well :) 14:20 < t-bast> But let's do a bit of LN Summit first? 14:20 < t-bast> And warnings can be discussed after that in IRC or Github outside of the spec meeting? 14:20 < BlueMatt> seemed like there was agreement on the email thread to have a meetup, and not a formal spec summit that can decide on prs in dependently 14:20 < BlueMatt> which seems like a great idea 14:20 < BlueMatt> there may also be people in el salvador who would do the same, presumably 14:20 < t-bast> #topic LN Summit / Meetup / Something 14:21 < rusty> Yeah, I can't make it but I will be pining from my desert island. 14:21 < BlueMatt> is there anything to discuss? 14:21 < roasbeef> is this the zurich thing or something else? 14:21 < BlueMatt> roasbeef: well, I guess both zurich and el salvador at the conference if that happens 14:21 < roasbeef> oh el salvador 14:22 < roasbeef> don't have any plans for el salvador myself atm 14:22 < BlueMatt> i doubt I'll go to either 14:22 < roasbeef> I think i'll be at the other one tho 14:22 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has joined #lightning-dev 14:23 < BlueMatt> soooo....discussion over? 14:23 < BlueMatt> sounds like there was nothing to discuss 14:23 < t-bast> BlueMatt & rusty: if you can't attend either, we definitely need a third one, it would be great to meet soon(ish) it really does speed up agreement on some priorities 14:23 < roasbeef> t-bast: seems like y'alla re going to both? 14:23 < ariard_> well zurich on the coredev side, is moving well, location for the 3 days has been booked 14:23 < t-bast> roasbeef: yeah I think we'll be going to both 14:23 < t-bast> roasbeef: you gotta come to at least one of these, it's been too long 14:24 < BlueMatt> t-bast: I mean you can have high bandwidth movement on lots of things without actually hitting merge in person :) 14:24 < BlueMatt> t-bast: but, anyway, we'll have a more formal one once rusty and folks can/want to travel a ton 14:24 < roasbeef> yeh I'll think I'll be at the europe one t-bast 14:24 < t-bast> BlueMatt: sure, but there are a lot of things I'd like to discuss in a higher-bandwidth environment with most of you 14:24 < roasbeef> the el salvaor thing is also around thanksgiving for the americans 14:25 < t-bast> roasbeef: oh good point, I don't know if they took that into account 14:25 < roasbeef> maybe better not to lol 14:25 < crypt-iq> BlueMatt: I agree with dust_limit that t-bast calculated and not 354 or which was mentioned before. It may be that < 354 is not economical to spend, but Core and btcd will still accept it if >= 330 for P2WSH, >= 294 for P2WPKH 14:25 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has quit [Quit: Leaving] 14:25 < roasbeef> but yeh some LL ppl will be at the zurich one, looking forward to seeing those in meatspace again that'll be there 14:25 < BlueMatt> crypt-iq: the point was segwit-v2-40-bytes, not existing script forms 14:25 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has joined #lightning-dev 14:26 < BlueMatt> crypt-iq: cause with shutdown_anysegwit nodes will accept things that aren't the standard types 14:26 < t-bast> crypt-iq: yes, I suspect BlueMatt has calculated what's economical to spend, where you and I have just checked what bitcoind allows :) 14:26 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has quit [Client Quit] 14:26 < BlueMatt> t-bast: no, I did not. I checked what bitcoind allows 14:26 < BlueMatt> max size segwit output is bigger than p2wsh :p 14:26 < t-bast> BlueMatt: interesting, I'll need to dive back into that rabbit hole then xD 14:27 < crypt-iq> segwit v2, not taproot right? 14:27 < BlueMatt> well, any segwit that is bigger than p2wsh 14:27 < crypt-iq> oh got it 14:27 < BlueMatt> which could be v1, but not taproot 14:27 < crypt-iq> there's this pr for those who haven't seen: https://github.com/bitcoin/bitcoin/pull/22779 14:27 < BlueMatt> meeting over 14:28 < BlueMatt> rusty: you around? 14:28 < BlueMatt> still 14:28 < t-bast> #endmeeting 14:29 < rusty> Half... making kids' lunches... 14:29 < BlueMatt> rusty: ok, no rush, was hoping to form agreement on https://github.com/lightningnetwork/lightning-rfc/pull/834#discussion_r698140878 and then we can get warnings over the line 14:29 < t-bast> Thanks guys, I'll have a last look at the PRs we agreed to merge and press the merge button tomorrow if no-one screams before that :) 14:29 < BlueMatt> question was just whether to remove the text that says "on all-0 errors, force close all channels" 14:29 < t-bast> Good luck with the kids rusty ;) 14:29 < rusty> BlueMatt: I'm surprised you implemented universal close... 14:30 < BlueMatt> rusty: well, we implemented the spec :p 14:30 < BlueMatt> rusty: and, it turns out, no one sends those things anymore 14:30 < BlueMatt> so its actually no issue except maybe some ancient unmaintained nodes that we dont want to connect to anyway 14:31 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 14:31 < lnd-bot> [lightning-rfc] Roasbeef opened pull request #903: anchors: follow up changes after initial zero fee anchors merge (master...anchors-zero-fee-fixups) https://github.com/lightningnetwork/lightning-rfc/pull/903 14:31 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 14:31 < rusty> Yeah, I think it's a corner case not worth implementing TBH. I mean, you can always error out one channel at a time... 14:31 < BlueMatt> rusty: not if we don't know what channels the counterparty thinks we have :p 14:32 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving] 14:32 -!- crypt-iq [~crypt-iq@2603-6080-8f06-6d01-c534-15e3-2e3d-d67a.res6.spectrum.com] has quit [Quit: Client closed] 14:35 < rusty> Do you ever send such a thing? 14:36 < BlueMatt> i think we do 14:36 < BlueMatt> or can 14:36 < BlueMatt> if we decide we are in a state that indicates not only we broke, but that we can never communicate with this peer again 14:36 < BlueMatt> then we'll send it 14:36 < BlueMatt> anyway, lunch now 14:36 < BlueMatt> gotta run 14:38 < rusty> I'm really thinking unused code is broken code. Nobody will implement it right. In practice, nodes will reestablish and boom, they get an error back for that channel. 14:53 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.] 15:32 -!- plankster [~plankster@user/plankers] has joined #lightning-dev 15:38 -!- gene [~gene@gateway/tor-sasl/gene] has joined #lightning-dev 16:17 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene] 17:01 -!- rusty [~rusty@203.221.41.134] has joined #lightning-dev 17:15 -!- belcher [~belcher@user/belcher] has quit [Read error: Connection reset by peer] 17:24 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 17:29 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 276 seconds] 17:31 -!- AaronvanW [~AaronvanW@190.86.109.168] has quit [Quit: Leaving...] 17:32 -!- belcher [~belcher@user/belcher] has joined #lightning-dev 17:32 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 17:32 < lnd-bot> [lightning-rfc] rustyrussell merged pull request #880: BOLT 2: send channel_type in open/accept (master...channel-types) https://github.com/lightningnetwork/lightning-rfc/pull/880 17:32 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 17:32 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 17:32 < lnd-bot> [lightning-rfc] rustyrussell pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/fdc078f845e1...4372f9d53800 17:32 < lnd-bot> lightning-rfc/master 4372f9d Rusty Russell: BOLT 2: define channel_type, make negotiation explicit. 17:32 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 18:03 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 244 seconds] 19:09 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection] 19:09 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #lightning-dev 21:35 -!- gnusha [~gnusha@user/gnusha] has joined #lightning-dev 21:35 -!- Topic for #lightning-dev: Bitcoin Lightning Network Development: Be Excellent To Each Other! Logging at http://gnusha.org/lightning-dev/ 21:35 -!- Topic set by rusty [~rusty@203.221.41.134] [Tue Jun 8 23:04:01 2021] 21:35 [Users #lightning-dev] 21:35 [ _0x0ff ] [ Flow ] [ koolazer ] [ RubenSomsen ] 21:35 [ _aj_ ] [ freesprung ] [ ksedgwic ] [ rusty ] 21:35 [ achow101 ] [ ghost43 ] [ lightningbot ] [ sandipndev ] 21:35 [ ariard_ ] [ gleb7 ] [ livestradamus ] [ scalability-junk] 21:35 [ belcher ] [ glix ] [ luke-jr ] [ stick ] 21:35 [ berndj ] [ gnusha ] [ merkle_noob[m]] [ stick[m] ] 21:35 [ bitromortac_] [ greypw ] [ michaelfolkson] [ sword_smith ] 21:35 [ BlueMatt ] [ greypw2 ] [ momus ] [ td001 ] 21:35 [ bw ] [ harding ] [ moneyball_ ] [ tinova2 ] 21:35 [ cdecker[m] ] [ hex17or ] [ mrjumper[m] ] [ valwal ] 21:35 [ commmon ] [ inara ] [ mschmoock ] [ vincenzopalazzo ] 21:35 [ cryptapus ] [ Jackielove4u ] [ nathanael ] [ warren ] 21:35 [ darosior ] [ jarthur ] [ Nebraskka ] [ waxwing ] 21:35 [ DeanGuss ] [ jkczyz ] [ niftynei ] [ whysthatso ] 21:35 [ dergoegge ] [ johnzweng ] [ nsh ] [ willcl_ark ] 21:35 [ devrandom ] [ jonasschnelli] [ pigeons ] [ yakshaver123 ] 21:35 [ dongcarl ] [ jonatack ] [ plankster ] [ yonson ] 21:35 [ dr-orlovsky ] [ kalle ] [ plankton ] [ zkao ] 21:35 [ emcy ] [ kanzure ] [ rachelfish ] 21:35 [ emzy ] [ Keele ] [ roasbeef ] 21:35 [ Enki[m] ] [ Kiowa_ ] [ robertspigler ] 21:35 -!- Irssi: #lightning-dev: Total of 81 nicks [0 ops, 0 halfops, 0 voices, 81 normal] 21:36 -!- Channel #lightning-dev created Wed May 19 07:21:41 2021 21:38 -!- Irssi: Join to #lightning-dev was synced in 132 secs 22:15 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 22:15 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 22:16 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 22:38 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 252 seconds] 22:55 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has joined #lightning-dev 23:04 -!- emcy [~emcy@user/emcy] has quit [Remote host closed the connection] 23:07 -!- emcy [~emcy@user/emcy] has joined #lightning-dev 23:19 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev 23:59 -!- fch [~myname87@mob-5-90-227-40.net.vodafone.it] has quit [Remote host closed the connection] --- Log closed Tue Aug 31 00:00:53 2021