--- Log opened Mon Dec 21 00:00:53 2020 00:59 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 01:30 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev 01:30 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 01:30 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 01:54 -!- jeremyrubin [~jr@c-24-4-205-116.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 01:59 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 02:04 -!- kexkey [~kexkey@static-198-54-132-106.cust.tzulo.com] has quit [Ping timeout: 260 seconds] 02:18 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer] 02:18 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 02:20 -!- __gotcha1 is now known as __gotcha 02:29 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 02:31 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 268 seconds] 02:31 -!- __gotcha1 is now known as __gotcha 04:08 -!- Sajesajama [Salsa@gateway/vpn/protonvpn/sajesajama] has joined #lightning-dev 04:26 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds] 04:31 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 04:53 -!- seberm [~seberm@ip4-83-240-4-221.cust.nbox.cz] has quit [Ping timeout: 256 seconds] 05:09 -!- seberm [~seberm@ip4-83-240-4-221.cust.nbox.cz] has joined #lightning-dev 05:14 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Ping timeout: 265 seconds] 05:14 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev 05:27 -!- seberm [~seberm@ip4-83-240-4-221.cust.nbox.cz] has quit [Quit: Leaving] 05:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 05:43 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 06:15 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 06:17 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 272 seconds] 06:17 -!- __gotcha1 is now known as __gotcha 06:24 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 272 seconds] 06:26 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 06:27 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer] 06:27 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 06:29 -!- __gotcha1 is now known as __gotcha 06:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 06:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 06:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 06:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 07:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 07:04 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 07:05 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 07:08 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:29 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 07:32 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 07:45 -!- Sajesajama [Salsa@gateway/vpn/protonvpn/sajesajama] has quit [Ping timeout: 240 seconds] 07:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev 08:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] 08:01 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 246 seconds] 08:01 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 08:12 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 08:39 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Remote host closed the connection] 08:39 -!- lightningbot [~supybot@cerulean.erisian.com.au] has joined #lightning-dev 09:13 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds] 09:20 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer] 09:21 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 09:22 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 09:25 -!- kexkey [~kexkey@static-198-54-132-138.cust.tzulo.com] has joined #lightning-dev 09:43 -!- cloudflare [~cloudflar@unaffiliated/cloudflare] has quit [Ping timeout: 246 seconds] 09:44 -!- cloudflare [~cloudflar@unaffiliated/cloudflare] has joined #lightning-dev 09:44 -!- Anduck [~Anduck@unaffiliated/anduck] has quit [Ping timeout: 246 seconds] 09:44 -!- deusexbeer [~deusexbee@080-250-077-163-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 246 seconds] 09:45 -!- tlev [~tlev@li120-195.members.linode.com] has quit [Ping timeout: 264 seconds] 09:45 -!- rachelfish [~rachel@unaffiliated/itsrachelfish] has quit [Ping timeout: 264 seconds] 09:45 -!- tlev1 [~tlev@li120-195.members.linode.com] has joined #lightning-dev 09:45 -!- rachelfish [~rachel@unaffiliated/itsrachelfish] has joined #lightning-dev 09:50 -!- jeremyrubin [~jr@2601:645:c200:14:d16a:4949:3622:4cc0] has joined #lightning-dev 09:56 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 10:16 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 272 seconds] 10:42 -!- belcher_ is now known as belcher 10:53 -!- t-bast [~t-bast@2a01:e0a:24a:7d0:412e:3d6a:45b3:279a] has joined #lightning-dev 10:53 -!- bmancini55 [9c923ad3@156.146.58.211] has joined #lightning-dev 10:55 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 10:55 < niftynei> Looks like a great agenda for today's meeting today https://github.com/lightningnetwork/lightning-rfc/issues/827 10:55 < cdecker> Yep, should be a good one ^^ 10:55 < niftynei> Should mention that rusty's out on holiday, so we might want to table offers til next time 10:57 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 10:57 < t-bast> hey! 10:57 < t-bast> No worries, we'll probably only have time for the PRs :) 10:58 < niftynei> hello hello! 10:58 < niftynei> two minutes til meeting start, let's see if i can get a snack that fast :P 10:59 < t-bast> sharing is caring, don't forget ours 11:00 < niftynei> ok bag (of chips) secured 11:00 < t-bast> OP_SECURETHECHIPS 11:00 < niftynei> t-bast: i think this is where i post that Texas "come and take it" flag meme 11:01 < t-bast> xD 11:01 < bitconner> 👋 11:02 < niftynei> it looks like it's meeting time now, any chair volunteers? 11:02 < t-bast> I'll pass, gotta leave a bit early this time 11:02 < niftynei> cdecker? 11:03 < niftynei> bitconner? 11:03 < cdecker> Dunno how long I'll stick around either, we have visitors tonight 11:04 < t-bast> IRL visitors? Who does that in 2020? 11:04 < niftynei> that's a big visitor list cdecker ;) 11:04 < cdecker> It's switzerland, our lockdown is as light as they come (unfortunately) 11:05 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Ping timeout: 256 seconds] 11:05 < niftynei> niftynei chairs again it is! 11:05 < niftynei> #startmeeting 11:06 < niftynei> if you haven't seen the agenda yet, please see https://github.com/lightningnetwork/lightning-rfc/issues/827 11:06 < cdecker> Beep boop, meeting starting :-) 11:06 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/issues/827 11:07 < niftynei> is there any old business from last meeting that we should address first? 11:07 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev 11:07 < t-bast> I don't think so, I think we'd covered everything 11:07 < niftynei> great. 11:07 < bitconner> sorry forgot to mention i'm also technically ooo so mainly lurking today :) 11:08 < niftynei> #topic #672, OP_SHUTDOWN_ANYSEGWIT 11:08 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/672 11:09 < t-bast> Did someone run some taproot tests and play with early non-zero witness programs? 11:09 < niftynei> so this is proposing to allow "any segwit version" script addresses for closing 11:09 < t-bast> Or is this PR only preparing for the future early enough to have this deployed before we actually start lveraging it? 11:09 < cdecker> Yep, it's only preparation so we can upgrade rigt away 11:10 < niftynei> do the latest bitcoin-core mailing list discussions around 'future segwit' version's bech being different relevant here? 11:10 < niftynei> *are the 11:11 < bitconner> the feature bit assingment may need to change, 22/23 is being deployed in lnd0.12 as anchor_zero_fee_htlc 11:11 < cdecker> I don't think the address encoding matter for script acceptance 11:11 < cdecker> Good catch bitconner 11:11 < t-bast> Agree with bitconner, it would be nice to have anchor-0-fee grab 22/23 11:12 < t-bast> At this point I guess we're pretty confident this will cover at least witness programs version 1, but do we have any guarantee for future versions? 11:12 < cdecker> Ok, I'll bump the featurebits of #672 then, since Rusty is afk for some more days 11:12 < t-bast> I don't know if the bech32 changes will impact that at all TBH 11:13 < t-bast> But we can always roll out a different set of feature bits later for `op_shutdown_anysegwit_revisited` if needed, it's quite a cheap change :) 11:13 < cdecker> The phrasing seems pretty relaxed, and I don't think we're going to have >40byte output scripts in future segwit versions 11:14 < niftynei> sounds like the only point of concern here is the version bit numbers 11:14 < t-bast> And we should be quite lax with this since it's really the owner of the output who chooses where to send the funds 11:14 < cdecker> Currently not sure if OP_16 is defined in segwit versioning at all tbh 11:15 < cdecker> Just checked: OP_16 matches what is covered by BIP 141 "If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions." So no weird discrepancy here 11:16 < niftynei> great, thanks for checking 11:16 < t-bast> Great, once the feature bits are bumped it LGTM 11:16 < cdecker> Ok 11:16 < cdecker> #action cdecker to bump featurebits due to collision :-) 11:16 < niftynei> (#824 does in fact have the bit collision) 11:17 < niftynei> moving on then. 11:17 < niftynei> #topic cltv tie-breaker test vector 11:17 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/539 11:17 < cdecker> Yeah, we seem to not be very good at avoiding collisions (#819 collides with the BOLT for offers) 11:18 < t-bast> This PR is particularly relevant now that MPP has rolled out, and such collisions do happen in production 11:19 < cdecker> Hm, too bad Rusty isn't here, since he checked the vector iirc 11:19 < t-bast> If you think this is worth adding to the spec, the PR only contains a test vector for the 1.0 commitment format, but we have the corresponding vectors for static_remotekey and anchor_outputs in eclair, I can update the PR to add them as well 11:19 < niftynei> Has anyone else verified the vector? 11:19 < t-bast> We have them in eclair, don't know about rust-lightning and lnd 11:19 < cdecker> ccccccfnijgigfhitrrdkhnninueehnngtikbcnnrtet 11:20 < cdecker> Hello yubikey :-) 11:20 < cdecker> Sorry about that 11:20 < t-bast> Oh so that wasn't your cat :D 11:20 < cdecker> Very heavy on the `c` that cat ^^ 11:20 < cdecker> Anyway, seems we need confirmation that the vectors work as expected 11:21 < niftynei> i think t-bast said they've incorporated them into their test suite 11:21 < t-bast> I'll add the ones for anchor_outputs and static_remotekey then 11:21 < cdecker> That'd be great 11:21 < t-bast> It would be great to have another implementation confirm 11:21 < t-bast> #action t-bast to add other commitment formats test vectors 11:21 < t-bast> #rusty to test them in c-lightning 11:21 < t-bast> #action rusty to test them in c-lightning 11:22 < t-bast> I just promoted rusty to a keyword :facepalm: 11:22 < niftynei> #action lnd/rust lightning/electrum to also test 11:22 < niftynei> lol 11:22 < jkczyz> will look into rust-lightning 11:23 < cdecker> Great, thanks jkczyz 11:23 < niftynei> being promoted while you're on vacation is a nice surprise to come back to :P 11:23 < niftynei> let's keep moving then 11:23 < t-bast> the #rusty keyword is a cheat code in lightning 11:23 < niftynei> #action jkczyz to test on rust-lightning 11:23 < niftynei> #topic 0 sat/byte anchor htlc txs 11:24 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/824 11:24 < niftynei> oof this one's long 11:24 < t-bast> heh but it's basically just replacing an "if" in several places 11:25 < cdecker> What I stumbled over was that we now have two options with the `option_anchor_*` prefix, but then you talk about `option_outputs` as if it were a separate option 11:25 < cdecker> Is it a combination of the two (if yes how?) or how should we read the semantics? 11:25 < t-bast> yes it's defined in bolt 9 in the PR as the OR of the two 11:26 < t-bast> We define `option_anchors` as `option_anchor_outputs || option_anchors_zero_fee_htlc_tx` 11:26 < cdecker> I see 11:26 < cdecker> At some point I'll have to draw a flowchart of the various options xD 11:27 < t-bast> The PR looks good to me, but I'd like to have at least one other implementation do interop testing; we had some surprises when doing interop testing for the previous anchor outputs and found issues 11:27 < niftynei> so eventually this would deprecate the opt_anchor_outputs flag, in favor of flagging for oazfht 11:28 < niftynei> t-bast, right, sounds like lnd has this implemented, needs a 2nd to be eligible for merging 11:28 < t-bast> niftynei: yes, even though it can be handy to keep the opt_anchor_outputs for a while (we'll use it in Phoenix where we don't have any utxo management for now) 11:29 < t-bast> the fact that it makes the htlc txs impossible to relay if you don't add an input can be painful to handle on mobile wallets 11:29 < t-bast> where you likely won't have many utxos available 11:31 < t-bast> I'm still unsure what's the best strategy will be for those small mobile wallets, maybe the current anchor_output with a fixed feerate (and potential CPFP from a different wallet) will be better there 11:31 < t-bast> TL;DR: I quite like the fact that we have both options :) 11:33 -!- bmancini55 [9c923ad3@156.146.58.211] has quit [Ping timeout: 245 seconds] 11:33 < niftynei> Sounds like the space for anchor output design is still a bit of an open question? 11:34 < t-bast> yes, clearly, and until we know what package relay will look like in bitcoin things may keep changing a bit 11:34 < niftynei> Maybe worth noting that this is being done in response to a "funds loss vector" ariard identified 11:34 -!- bmancini55 [9c9236e3@156.146.54.227] has joined #lightning-dev 11:34 < cdecker> Yep, the PR has a sidenote to that effect 11:35 < niftynei> i'm not really adding new info here. is there anything else worth discussing? 11:35 < t-bast> I think we can mark this as mostly waiting for interop? 11:35 < niftynei> #action wait for interop 11:35 < cdecker> Sounds like we need a second implementation for interop testing before merging? 11:35 < t-bast> But we can choose to really reserve the feature bits since lnd ships with those 11:35 < niftynei> Good point. 11:36 < cdecker> Yep, can we split out the featurebits change and apply those already? That'd at least prevent future collisions 11:36 < t-bast> I think it would make sense, let's ping halseth for that 11:36 < niftynei> #action ask halseth to break out featurebit change into separate PR 11:36 < niftynei> ok. let's move on 11:36 < niftynei> #topic advertize zlib support via feature bits 11:36 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/825 11:37 < t-bast> Even though I'm the author, I'm not sure at all we want to do that (or how we want to do it) 11:37 < t-bast> This is really fishing for comments :) 11:38 < t-bast> rust-lightning would like to avoid adding a dependency on zlib 11:38 < niftynei> this is addressing an issue that was raised by rust lightning? 11:38 < t-bast> exactly 11:38 < t-bast> the spec assumes all implementation would add zlib support 11:39 < t-bast> defining a feature bit to say I support zlib is a bit ugly, as we could need one feature bit per compression algorithm we'd support, which is horrible 11:39 < bmancini55> yes, the primary issue is that as a query initiator, there is no way to signal that we would like reply_channel_range in raw format 11:39 < cdecker> Yeah, it's a bit weird to introduce an optional bit after assuming everybody had it already 11:39 < t-bast> the alternative suggested by matt and ariard is to instead have a kind of "subtractive" feature bit to say "I only support raw format" 11:39 < cdecker> Whatever we do the signal is going to be hit r miss for some time 11:40 < t-bast> this `format_raw` alternative would allow backwards-compatibility 11:40 < t-bast> I'm not a big fan of feature bit that advertize that we *don't* support features though 11:40 < cdecker> But hey, anything that allows us to be more specific, even if it takes some time 11:41 < cdecker> Yeah, let's opt-in whenever possible, and keep opt-outs in the form of mandatory flags, otherwise this gets really confusing 11:43 < t-bast> bmancini55: we can also take the problem differently: instead of my approach of adding a feature bit, we can re-work a bit the queries to let the query initiator signal what format it wants 11:43 < niftynei> ok that was going to be my question 11:44 < t-bast> and this would provide us more flexibility on the formats, and could be an even tlv field so that rust-lightning only connects to nodes who have added support for this 11:44 < niftynei> it seems like what we actually want here is the ability to specify the type of response that we expect 11:44 < t-bast> niftynei: exactly, and the approach of a `zlib_support` feature bit is probably not the best way of achieving that 11:44 < niftynei> you could still add a feature bit for *supports gossip query type signaling*? 11:45 < t-bast> it's a better direction indeed 11:45 < t-bast> I'll re-work the PR (or offer a competing one) 11:45 < niftynei> sweet 11:45 < cdecker> Sounds good 11:45 < bmancini55> a tlv on query_channgel_range would certainly solve the problem we have. inbound query_scids queries would might be an issue though 11:45 < t-bast> #action t-bast to try a different approach with query initiator tlv field 11:46 < t-bast> bmancini55: I'll dive a bit into that rabbit hole and will send a PR :) 11:46 < bmancini55> sounds good 11:46 < niftynei> ok, sounds like we have a new direction on this. 11:46 < niftynei> moving on. 11:47 < niftynei> i think this might be the last item we have time for today -- seems like most need to head out early 11:47 < niftynei> and i'm running out of snacks 11:47 < t-bast> OP_SECURE_MORE_CHIPS 11:47 < niftynei> #topic gossip queries: sync complete is back 11:47 < niftynei> #linkhttps://github.com/lightningnetwork/lightning-rfc/pull/826 11:47 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/826 11:48 < t-bast> The TL;DR for that one is: I still don't understand why we went for implicit end of sync (to save a couple bytes after exchanging KBs worth of data???) 11:49 < t-bast> If we add an explicit signal for end-of-sync, we can easily split blocks across multiple responses which is more flexible 11:49 < t-bast> The only open question in my opinion is whether we want to re-use the `full_information` field that no-one uses because it's weird AF, or introduce a new tlv field 11:50 < niftynei> what does it mean 'not to maintain up-to-date channel information' 11:50 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev 11:51 < niftynei> it seems equivalent to saying "go ask other nodes, my data's unreliable"? 11:51 < t-bast> ¯\_(ツ)_/¯ 11:52 < bmancini55> That's my understanding of it. "I'm still syncing" perhaps. 11:52 < t-bast> that's why I lean towards removing it, I don't see how it's really actionable (and it would be fully trusted anyway) 11:52 < t-bast> your peer can lie on that field anyday 11:52 < bmancini55> I think I prefer to reuse `full_information` to signal completion. 11:52 < t-bast> :+1: 11:52 < bitconner> +1 11:52 < bmancini55> I believe legacy LND still uses that field to signal multipart replies 11:53 < bitconner> that's correct 11:53 < bmancini55> My question is whether it's worth adding a TLV to signal a failure. 11:53 < niftynei> c-lightning sends back 'full-information' true iff you've requested blocks from a chain we don't know 11:53 < niftynei> :s/true/false/ 11:54 < niftynei> sorry, i mean to say we signal we don't know 'full-information' if you've asked us for queries on an unknown chain 11:54 < t-bast> niftynei: but you only really support one chain, right? That's probably a usecase we can ignore? 11:54 < t-bast> and we advertize it in `init` 11:55 < t-bast> bmancini55: can you detail? what kind of failure? 11:55 < t-bast> oh you mean instead of silently dropping a request and not responding to it? 11:55 < bmancini55> wrong chain, or even "I don't want to reply" 11:56 < bmancini55> @tbast: yep 11:56 < t-bast> since we advertize the chains we support in `init`, I think that a sender asking us for a chain we don't support doesn't really deserve a nice error, we can just drop it 11:57 < niftynei> or send an error back in reply? 11:57 < t-bast> maybe it makes sense for throttling though, responding with `sorry, I have that information, but you're asking too much, retry later` 11:58 < t-bast> but that's probably a separate change, isn't it? 11:58 < niftynei> i think so 11:58 < bmancini55> yeah I think it could addressed at another time if there was a need/desire 11:59 < t-bast> sgtm 11:59 < niftynei> feels like the 'full-information' bit is standing in where an error message might be more appropriate 11:59 < bmancini55> agreed 12:00 < niftynei> i might be missing some nuance here around error message etiquette though 12:00 < niftynei> ok. what actions do we have outstanding here? 12:01 < t-bast> TBH we haven't really felt the need for an error here, sync is some kind of a best effort / partial information mechanism anyway where you regularly ask different peers to try to get a good enough view of what's happened in the network 12:01 < t-bast> I'd simply wait for now for rusty's opinion on the PR since he opened the issue 12:01 < niftynei> #rusty opine on issue 12:01 < niftynei> :s/issue/pr 12:01 < t-bast> It looks like we're ok with re-using the `full_information` field for now, and maybe later add explicit errors if we feel it's worth it 12:02 < niftynei> in terms of implemenation, is this something you've done for ACINQ yet t-bast? 12:02 < t-bast> Not yet, but that's going to be my next step :) 12:02 < niftynei> or are we at the 'draft and comment' stage still 12:02 < niftynei> ok cool. 12:02 < niftynei> #action t-bast implementing first draft in ACINQ 12:02 < t-bast> just waiting to see if I get a big nack from someone, but otherwise I'll implement 12:03 < niftynei> alright. that's all we have time for today, unfortunately[ 12:03 < niftynei> i'm 100% out of chips now, so i'm going to be abdicating the meeting chair. 12:03 < t-bast> haha thank you for chairing! 12:03 < t-bast> great, right on time on my side 12:03 < niftynei> happy holidays to everyone! 12:03 < niftynei> #endmeeting 12:04 < t-bast> thank you all, happy holidays! 12:04 < bmancini55> thanks, happy holidays! 12:04 -!- t-bast [~t-bast@2a01:e0a:24a:7d0:412e:3d6a:45b3:279a] has quit [Quit: Leaving] 12:04 < niftynei> (our next meeting is jan 4th) 12:07 < cdecker> Thanks niftynei for chairing, and thanks everyone for a good year of spec meetings :-) 12:07 < cdecker> Happy holidays and a happy new one ^^ 12:15 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 12:33 -!- bmancini55 [9c9236e3@156.146.54.227] has quit [Remote host closed the connection] 13:14 -!- proofofkeags_ [~proofofke@174-29-3-187.hlrn.qwest.net] has joined #lightning-dev 13:30 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer] 13:31 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 13:32 -!- arij [uid225068@gateway/web/irccloud.com/x-raxwzvzfjkidaprc] has quit [Ping timeout: 258 seconds] 13:32 -!- junderw [sid43070@gateway/web/irccloud.com/x-qnoodlvfldmuqnzb] has quit [Ping timeout: 258 seconds] 13:34 -!- arij [uid225068@gateway/web/irccloud.com/x-zoxganoteavxkuan] has joined #lightning-dev 13:34 -!- junderw [sid43070@gateway/web/irccloud.com/x-ytneqqleilqeaikv] has joined #lightning-dev 13:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 14:05 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 240 seconds] 14:08 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 14:21 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:23 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Remote host closed the connection] 14:23 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:27 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Remote host closed the connection] 14:28 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:39 -!- jessepos_ [~jp@2601:645:200:162f:c80:1b9c:6dcc:7fac] has joined #lightning-dev 14:40 -!- jesseposner [~jp@2601:645:200:162f:30e7:b32e:18ab:9a91] has quit [Ping timeout: 260 seconds] 14:41 -!- jesseposner [~jp@c-73-15-111-74.hsd1.ca.comcast.net] has joined #lightning-dev 14:44 -!- jessepos_ [~jp@2601:645:200:162f:c80:1b9c:6dcc:7fac] has quit [Ping timeout: 260 seconds] 14:48 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Ping timeout: 272 seconds] 14:58 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 15:00 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 15:04 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Remote host closed the connection] 15:04 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 15:09 -!- Madars [~null@unaffiliated/madars] has quit [Quit: WeeChat 1.9.1] 15:19 -!- nobody123 [~nobody123@dslb-094-216-007-055.094.216.pools.vodafone-ip.de] has quit [] 15:21 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-xpdkkmqnrtcjkded] has quit [Ping timeout: 260 seconds] 15:21 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-yvkrhcmnpcotzlkv] has quit [Ping timeout: 264 seconds] 15:49 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 15:52 -!- proofofkeags_ [~proofofke@174-29-3-187.hlrn.qwest.net] has quit [Read error: Connection reset by peer] 15:53 -!- proofofkeags [~proofofke@174-29-3-187.hlrn.qwest.net] has joined #lightning-dev 17:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 17:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:32 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 264 seconds] 18:03 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 18:05 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds] 18:31 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 18:32 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev 19:12 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 19:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds] 19:14 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 19:17 -!- lukedashjr is now known as luke-jr 20:35 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 20:36 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 23:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 23:41 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev 23:43 -!- t-bast [~t-bast@2a01:e0a:24a:7d0:412e:3d6a:45b3:279a] has joined #lightning-dev 23:50 -!- t-bast [~t-bast@2a01:e0a:24a:7d0:412e:3d6a:45b3:279a] has quit [Quit: Leaving] --- Log closed Tue Dec 22 00:00:52 2020