--- Log opened Mon Nov 25 00:00:18 2019 00:01 -!- jonatack_ [~jon@37.170.7.180] has joined #lightning-dev 00:04 -!- jonatack [~jon@37.164.37.175] has quit [Ping timeout: 265 seconds] 00:30 -!- arij [uid225068@gateway/web/irccloud.com/x-jeczeytlfamplirv] has quit [Quit: Connection closed for inactivity] 01:07 -!- marcoagner [~user@bl11-16-162.dsl.telepac.pt] has joined #lightning-dev 01:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 01:27 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev 01:36 -!- marcoagner [~user@bl11-16-162.dsl.telepac.pt] has quit [Ping timeout: 276 seconds] 01:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 01:49 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 02:46 -!- Amperture [~amp@65.79.129.113] has quit [Read error: Connection reset by peer] 02:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 02:51 -!- jungly [~quassel@79.8.200.97] has quit [Ping timeout: 250 seconds] 02:58 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds] 03:02 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 03:15 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #lightning-dev 03:16 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 03:17 -!- nibbier [~quassel@mx01.geekbox.info] has quit [Quit: No Ping reply in 180 seconds.] 03:18 -!- nibbier [~quassel@mx01.geekbox.info] has joined #lightning-dev 03:39 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 03:44 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Quit: No Ping reply in 180 seconds.] 03:44 -!- cfields [~cfields@unaffiliated/cfields] has quit [Remote host closed the connection] 03:48 -!- jungly_ [~quassel@79.8.200.97] has joined #lightning-dev 03:48 -!- cfields_ [~cfields@unaffiliated/cfields] has joined #lightning-dev 03:48 -!- izak [~user@196.189.57.96] has joined #lightning-dev 03:49 < izak> hi is there a remote testnet rpc server which i can use to test c-lightning ? 03:52 < buZz> lol 03:52 < buZz> just install your own :) 03:54 < izak> thanks, i thought there is another way other than installing the full node and sync. :) 04:08 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 245 seconds] 04:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:21 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has quit [Ping timeout: 240 seconds] 04:29 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has joined #lightning-dev 04:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 04:35 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 04:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:49 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev 04:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 05:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 05:11 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection] 05:14 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:21 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 05:21 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds] 05:35 -!- tinova [~tinova@lemoncat.org] has joined #lightning-dev 05:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 05:40 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 276 seconds] 05:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 05:57 -!- Amperture [~amp@65.79.129.113] has joined #lightning-dev 05:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 06:18 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has quit [Quit: Leaving] 06:35 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev 06:40 -!- izak [~user@196.189.57.96] has left #lightning-dev ["Killed buffer"] 06:50 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds] 06:59 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 06:59 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 07:24 -!- aqquadro [~name@unaffiliated/aqquadro] has joined #lightning-dev 07:35 -!- aqquadro [~name@unaffiliated/aqquadro] has quit [Ping timeout: 252 seconds] 07:46 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 07:48 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 08:50 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 08:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 08:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 09:32 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 09:41 -!- jonatack_ [~jon@37.170.7.180] has quit [Quit: jonatack_] 09:42 -!- jonatack [~jon@37.170.7.180] has joined #lightning-dev 10:02 -!- marcoagner [~user@2001:8a0:6a55:8f00:81e3:c539:c514:2d18] has joined #lightning-dev 10:10 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 10:55 -!- t-bast [~t-bast@2a01:e34:ec2c:260:b0a2:cdf:c92e:417e] has joined #lightning-dev 10:57 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev 11:00 -!- hiroki_ [77f50162@119.245.1.98] has joined #lightning-dev 11:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:01 < t-bast> Hi everyone 11:01 < rusty> Hello! 11:01 < cdecker> Hi ^^ 11:02 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving] 11:03 -!- sstone253 [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev 11:03 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 11:03 < t-bast> Are any of you doing the Taproot review? 11:03 * rusty is just cheering from the sidelines 11:04 < t-bast> haha 11:04 < cdecker> Yep, I'm following along, just trying to get a better understanding myself 11:05 < t-bast> So only reviewing? Or are you trying to write prototype code? 11:05 <+roasbeef> too early for prototype code imo 11:05 < t-bast> But just as a means for giving a thorough review? 11:05 < cdecker> Just reviewing it, and making sure that noinput/anyprevout doesn't get into a conflict 11:05 <+roasbeef> it's also gonna be quite involved, imo it's a much larger change for wallets+nodes than segwit was 11:05 < t-bast> At least that was my intention at first, easy for schnorr, but for Taproot it's quite involved 11:06 < t-bast> cdecker: oh yeah can we do something to help on the anyprevout front? 11:06 <+roasbeef> imo ppl are underestimating how long it'll take for it to reach wide deploymetn compared to segwit, which already took a while and only really changed (from a wallet's pov) spending slightly w/ a new sighash and a new field 11:06 <+roasbeef> t-bast: prob just wait really :p 11:06 < t-bast> heh ;) 11:06 < t-bast> true that even when shipped in Core it will take a huge amount of time to be used by wallets and users 11:07 < cdecker> Yep, that's my feeling as well. 11:07 < t-bast> but Lightning can start using it probably faster than other projects (especially the schnorr part) 11:07 <+roasbeef> the whole point of version bits was to allow parallel soft-fork deploymnets, but so far, turns out social ceremoney/conventions limit that 11:07 < cdecker> Prototypes using signet might be a good thing though and rmyers has done an eltoo PoC 11:07 < t-bast> Even though it's going to be long and involved changes on Lightning too 11:07 < rusty> Especially since we need a new encoding... bech33? :) 11:07 < cdecker> Nah, bech32.5 :-) 11:07 -!- sstone253 [~sstone@112.ip-51-68-199.eu] has quit [Client Quit] 11:07 < t-bast> X) 11:08 <+roasbeef> #startmeeting 11:08 < lightningbot> Meeting started Mon Nov 25 19:08:17 2019 UTC. The chair is roasbeef. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:08 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:08 <+roasbeef> went through some PRs late last week that were marked to be merged, but then incurred rebase conflicts 11:09 < t-bast> Do we have updates on base AMP? Implementations making progress? 11:09 < joostjgr> yes, we are steadily making progress on base amp 11:09 < rusty> t-bast: I implemented the send side yesterday, but not much use without receive. Still, the pieces seem to fit well so far. 11:10 <+roasbeef> rusty: I think #513 can be closed? 11:10 <+roasbeef> #topic #643 (base amp) 11:10 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/643 11:10 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 11:10 < t-bast> great to hear 11:10 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev 11:10 < rusty> roasbeef: ack, closng now... 11:11 < t-bast> On my side, pretty happy with the state of the PR right now 11:11 <+roasbeef> so where do we stand on the spec PR itself? seems most of the major concerns have been addressed now? 11:11 < t-bast> Maybe just on the naming of payment_secret? 11:12 < t-bast> There's a comment with some alternative proposals 11:12 <+roasbeef> also iirc now that the paylaods have been set, we can move forward with #658 as well 11:12 <+roasbeef> t-bast: what happened to payment_addr? ppl don't like "addr"? 11:12 <+roasbeef> or payment_nonce or w/e 11:12 < t-bast> I like payment_nonce 11:12 < t-bast> but the `n` is already taken in the encoding... 11:13 < cdecker> Yeah, addr has way too much baggage already 11:13 <+roasbeef> long lived PRs are kinda hard to follow on github :/ 11:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev [] 11:13 <+roasbeef> things can get burried easily 11:13 < t-bast> yeah that's true 11:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:13 < t-bast> we need to find both a name and the bech32 letter associated with it 11:13 < rusty> What about payment_handle? It 11:14 < rusty> t-bast: not really, we can leave s as the bech32 letter. 11:14 < t-bast> yeah but isn't it weird to have 's' for 'payment_handle' for example? I'm probably nitpicking too much 11:14 < niftynei> i feel like i'm missing something here. what was wrong with secret? 11:14 <+roasbeef> an 's'?? 11:14 < rusty> roasbeef: in the bolt11 spec. 11:14 <+roasbeef> well it's not really secret, ppl post invoices on twitter or w/e all the time 11:14 < t-bast> nitfynei: it's not really a secret... 11:15 < t-bast> it's more a nonce (in behavior at least) 11:15 < t-bast> or a payment_id 11:15 <+roasbeef> but if main topic is what this suffix shoudl be, sounds like we're pretty far along lol 11:15 < t-bast> haha true 11:15 < rusty> it's really a secret, since revealing it is a mistake. BUt it's also a temp fix until The Glory of Schnorr.... 11:16 < rusty> (Which, BTW, is why baking it into the same field as amount in onion will be seen as a mistake, but...) 11:16 < t-bast> honestly no need to spend too much time on that, I'm even happy with payment_secret for now (unless someone really hates it) 11:16 < rusty> (We'll be changing so much I don't think this will be a huge issue) 11:16 < t-bast> yeah for Schnorr we're ditching everything and starting from scratch right? 11:16 < rusty> Technically, changing the name in the spec is a Spelling issue, as long as there's consensus. 11:16 < t-bast> that's what I signed up for 11:17 -!- hiroki_66 [77f50162@pl99426.ag2001.nttpc.ne.jp] has joined #lightning-dev 11:17 < rusty> t-bast: I like your optimism ;) 11:17 < t-bast> yeah then let's not argue too much about the naming and go on with next topics? :) 11:17 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #lightning-dev 11:17 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 11:17 < t-bast> unless there's something else on AMP people have spotted? 11:19 <+roasbeef> t-bast: i thought we were talking about #643, not #658? 11:19 < rusty> Can we merge 666 first, then this can be rebased, and merge once we have interop testing? 11:19 < t-bast> oh yeah, sorry I did mean base AMP 11:19 -!- hiroki_ [77f50162@119.245.1.98] has quit [Ping timeout: 260 seconds] 11:19 <+roasbeef> t-bast: for #643, I haven't been following as closely, so dunno if there're comments buried deep in a thread that haven't been processed, conner isn't here right now but he would know better 11:19 <+roasbeef> yeh #666 has been cleared for a few weeks, just keeps running into merge conflicts 11:20 < t-bast> roasbeef: I think that apart from naming, there's no unaddressed comments in the PR that we didn't discuss (643) but let's wait for conner to chime in 11:20 < t-bast> ACK on merging 666, it's on our todo list too 11:22 < rusty> OK, I'll rebase and merge now. 11:23 <+roasbeef> cool, ok for #643 then we want interop mostly, picking a payment_* suffix isn't super critical 11:24 <+roasbeef> lnd has a "single shot" mode implemented, so you use all the new fields but there's no splitting or combination 11:24 < t-bast> agreed with roasbeef 11:24 < t-bast> I thought you had no splitting but you had the combine (receive) part? 11:24 <+roasbeef> but it's possible for several lnd nodes to do a sort of "crowd funding" mode 11:25 < rusty> (BTW, I've been playing with minisketch for gossip btw, am on my third revision of proposal now, should have something next mtg) 11:25 < t-bast> rusty: that's cool stuff! curious to see that 11:25 <+roasbeef> t-bast: yeh that's in an open PR, but not yet merged yet 11:26 < t-bast> roasbeef: ok, should land soon then ;) 11:26 <+roasbeef> #action more interop tests for #643 requested 11:27 <+roasbeef> #666 build failed btw rusty 11:27 < rusty> One more force push coming then.... one sec 11:27 <+roasbeef> other PRs with merge conflicts that are ready: #672 11:27 <+roasbeef> #topic 682 (add networks to init message) 11:28 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/682 11:29 <+roasbeef> i think the final thing here was specifying if there's some partial overlap in advertised chains 11:29 < t-bast> Does lnd still support Litecoin? 11:30 <+roasbeef> yep 11:30 < rusty> roasbeef: - SHOULD NOT forward gossip messages to peers who sent `networks` in `init` and did not specify the `chain_hash` of this gossip message. 11:30 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 11:30 < rusty> (The fixup commit adds that phrase to the gossip section) 11:30 <+roasbeef> nice 11:31 < rusty> Everyone in favor? I haven't actually implemented this one, but we can ack now and apply once compat testing is done? 11:31 < cdecker> It doesn't say that we have 32 byte hashes :-) 11:32 <+roasbeef> I think `chain_hash` is specified elsewhere? 11:32 < cdecker> But yeah, looks solid and simple enough 11:32 <+roasbeef> > chain_hash: a 32-byte chain identifier (see BOLT #0) 11:33 < t-bast> ACK #682 11:33 < t-bast> haven't implemented either, but looks simple 11:34 < cdecker> Ah it's in BOLT01, I was looking in 00 as well, but there it just has the prose 11:34 < rusty> #666 merged. Die Travis, die... 11:34 -!- ueser64755 [3344c770@112.ip-51-68-199.eu] has joined #lightning-dev 11:35 < t-bast> Hell yeah. BTW do we really need to run 3 CI builds with different python versions? :D 11:35 < t-bast> do you even think about those penguins in antartica and stuff? 11:35 <+roasbeef> #info #682 has been updated to specify how to handle gossip messages 11:36 -!- ueser64755 [3344c770@112.ip-51-68-199.eu] has quit [Remote host closed the connection] 11:36 <+roasbeef> #action general acceptance, needs basic interop tests, as first tlv extension in the init message 11:36 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev 11:36 < rusty> I've adde an Awaiting Interop label, will use now. 11:37 < t-bast> rusty: you can put that one on 643 as well then 11:37 <+roasbeef> cool 11:37 < rusty> t-bast: done 11:37 <+roasbeef> #topic #684 11:37 <+roasbeef> i think there's some context for this one I'm missing? 11:38 < rusty> roasbeef: yeah, if you're a badly connected node, and you connect to a big node, it might tell you it doesn't want any gossip (using timestmap filter). 11:39 < rusty> roasbeef: we saw failure to propagate channel_announcement in that case. 11:40 <+roasbeef> whose chan_ann will fail to propagate in that case? 11:40 < rusty> So two small node can create a channel, but if all their peers are telling them to STFU with timestamp filtering, it never propagates. 11:40 <+roasbeef> hmm, but won't they still just announce them in either case? 11:40 <+roasbeef> since we don't have any request/response, or they can just do so optimistically 11:40 < rusty> roasbeef: not if they obey the timestamp_filter which is telling them not to. 11:41 < rusty> (which, we used to do). timestamp_filter shouldn't apply to *your own* gossip,you should push that out regardless (which is what we now do) 11:41 <+roasbeef> fwiw, lnd may start to just not respond to very old timestamp_filter values 11:41 <+roasbeef> gotcha 11:41 < rusty> I think it's worth adding, since nodes are getting more aggressive at filtering, and this may become problematic. 11:41 < cdecker> Well it shouldn't even have really old gossip messages since the suggestion is to prune anything older than 2 weeks 11:42 < t-bast> that makes sense, I think sstone should have a look at this too 11:42 <+roasbeef> ok thanks for the context, will take a look at the PR as a whole now 11:42 < sstone> yes I think we do send our own updates no matter what the ts filter is but I'll check 11:43 < rusty> sstone: you're smarter than me... we had a few users upset that they couldn't find themselves on 1ml :) 11:44 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 11:44 < sstone> mmm yes let's say that :) but it's more like we patched timestamp filter on top of other things and did not think about this check 11:44 < rusty> #695 should be a little controversial, at least. 11:44 <+roasbeef> #info proposed to allow nodes to continue to send their own anns so they'll still propagate them to those that don't send a gossip filter 11:44 <+roasbeef> safe to move on and we continue in the PR for #684? 11:44 < rusty> (or send a gossip filter at UINTMAX) 11:45 < rusty> roasbeef: ack 11:45 < cdecker> sgtm 11:45 -!- rh0nj [~rh0nj@88.99.167.175] has joined #lightning-dev 11:45 < t-bast> roasbeef: sgtm 11:45 <+roasbeef> #action discussion to continue on PR for #684 11:45 <+roasbeef> #topic 688 11:45 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/688 11:45 <+roasbeef> took a pass throuhg the PR in its current form last week 11:46 <+roasbeef> one thing that jumped out at me, is how cluttered things start to get with feature bit modifications 11:46 <+roasbeef> the current format doesn't really seem scalable 11:46 < BlueMatt> seems like there's still ongoing mailing list discussion that hasnt concluded, sadly 11:46 <+roasbeef> a better path imo would be to start tagging hard versions, and assume certain bits to be on my default 11:46 <+roasbeef> by* 11:46 <+roasbeef> so then we'd ref the legacy behavior in footnotes or an errata section 11:46 < rusty> roasbeef: yeah, at some point we declare feature bankrupcy and have a 'modern' bit. 11:47 <+roasbeef> just to keep the main document more readable with a single run through 11:47 < BlueMatt> i mean can also just fork it in a git sense, no? 11:47 < BlueMatt> like, "if you want 'legacy mode, see git tag X" 11:47 <+roasbeef> yeh taht's one way to do it 11:47 < joostjgr> i am also in favor of forking. it gets hard indeed to describe everything using those conditionals 11:48 < BlueMatt> and forking in a git sense is way easier practically than moving things to errat or so, but I suppose it doesn't matter *that* much 11:48 < joostjgr> maybe for this one we can survive, but at some point it will become too difficult 11:48 < t-bast> agreed, but then shouldn't we work harder on deciding what v1.1 is and using a git tag for that? And one for v1.0? 11:48 <+roasbeef> joostjgr: yeh just imagine the future changes such as dlog htlcs w/ the current format 11:49 <+roasbeef> t-bast: yeh, things have kinda sprawled tho beyond what was loosely stamped as 1.1 after the last big spec meeting 11:49 < t-bast> like agree on a "main" release with a list of big features and coordinate to ship all implementations and then move on 11:49 <+roasbeef> hard part about that is relative priorities of the impls 11:49 < rusty> It's nicer if we can actually remove the old stuff on the network at the same time. I think tlv-onion will probably be a forcing function here. 11:50 < t-bast> roasbeef: that's true, but we can probably agree on the common set 11:50 <+roasbeef> there're a number of things that were stamped as 1.1 that just haven't really been picked up, as subjectively they may not be high priority 11:50 < t-bast> we should feel free to re-visit during the spec meeting what the roadmap is for 1.1, right? 11:50 < t-bast> and keep that roadmap somewhat up-to-date to be able to tag important milestones and start deprecating things from the spec 11:50 <+roasbeef> we never really had a "road map" imo, just some bullet points on a wiki fo things we talked about during the meeting 11:51 < t-bast> yeah that's enough of a roadmap for me :) 11:51 < joostjgr> we are actively implementing the new anchor outputs commitment tx. today got it running end to end for the first time. highest prio for now is to decide on the outstanding q's: anchor size and remote csv delay value 11:51 <+roasbeef> hehe, but this is more of a metapoint 11:51 < rusty> joostjgr: nice work!! 11:52 < t-bast> congrats Joost! 11:52 <+roasbeef> joostjgr: yeh that sounds aout right on remaining elements, I still need to circle back on your comments in response to my latest review 11:52 < t-bast> how hard was the implementation? 11:52 < joostjgr> johan did most of the impl work 11:52 < t-bast> it looks like a lot 11:52 < joostjgr> it wasn't hard, it is mostly work 11:52 <+roasbeef> lnd has been working towards it for a while t-bast, adding components we surmised would be need for this feature 11:52 <+roasbeef> t-bast: for example we have a cpfp engine already in place, so after close we just hand off that anchor outputs to that 11:52 < t-bast> gotcha, good thinking 11:52 < joostjgr> we target v1 as an 'emergency' function. so we do sweep the anchors, but always at a low fee rate. the normal fee mechanism remains unchanged 11:53 < joostjgr> a user can manually bump if desired 11:53 < sstone> doesn't it make utxo management more complex even if you prepared for it ? 11:53 < t-bast> but does it work with Bitcoin core today? I thought there were missing bits in the package relay that would only land in 0.20 (or even later)? 11:53 < BlueMatt> joostjgr: I presume you're talking about it in the "lnd" sense, not the "spec" sense. 11:53 <+roasbeef> sstone: how so? 11:54 < joostjgr> sstone: you need a utxo to cpfp indeed 11:54 < BlueMatt> as in, its definitely not an "emergency function" in the spec, though if you take it as a implementation step cause you dont trust your rbf/cpfp engine, that makes sense 11:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #lightning-dev 11:54 <+roasbeef> t-bast: it doesn't depend on packaged relay, commitment just has a smaller fee now which is a floor, target is "to get into mempool", rather than "to get into block" 11:54 < sstone> you need to have "spare" utxo to boost fees 11:54 < rusty> Yeah, last I tried to implement it I shied away from the UTXO issues... 11:54 <+roasbeef> BlueMatt: the spec doesn't need to dictate how it's used really, joost is just saying that our impl atm is lazy in that it only bumps if it really needs to or there's an incoming htlc on another link, etc 11:55 < t-bast> roasbeef: thanks for the clarification, I need to dive deeper into that 11:55 < BlueMatt> t-bast: and, fwiw, there has been active debate on whether or not to remove update_fee entirely and hard-code the feerate, given that the "min fee to get into mempool" has rarely gone above a relatively low level in bitcoin's entire history. 11:55 <+roasbeef> sstone: mhmm, I commented that we should maybe have a section to specify wallets keep a pool around, atm the code assumes we have one in place already 11:55 < BlueMatt> though it seems like the lnd folks are very very strongly opposed to that idea 11:56 < rusty> I'd love to drop update_fee, since it's a *complex*. 11:56 <+roasbeef> heh, I think you're mischaracterizing BlueMatt, rust-lightning hasn't implemented it at all so understandable that y'all want it removed 11:56 < BlueMatt> sstone: I mean dont y'all have some cpfp/rbf-additional-fee-available utxos around anyway? 11:56 < niftynei> does removing update_fee need to go in at the same time with the anchor outputs change? 11:56 <+roasbeef> we want it gone eventually, but that's a much larger change 11:56 < niftynei> i think removing update_fee is a good goal, and that anchor updates is the mechanism that it's replaced by 11:56 <+roasbeef> niftynei: removing it needs packaged relay syupport in the p2p network, which doesn't exist atm 11:56 < BlueMatt> roasbeef: heh, we kinda have it implemented, but, totally, we specifically avoided implementing it cause its So. Damn. Busted. 11:57 < rusty> roasbeef: that's just not true, AFAICT? 11:57 <+roasbeef> BlueMatt: sure i think that's an important detail though, as deployed implementations have different constraints 11:57 < sstone> roasbeef: our onchain wallet is a bit simpler that yours I think (we don't have a "nursery" to handle delays) 11:57 < BlueMatt> roasbeef: it absolutely does *not* need package relay, but I do get the argument that it should be a separate feature bit. 11:57 <+roasbeef> rusty: why not? if the goal is to have zero fees on the commitment? 11:57 < sstone> than 11:57 < joostjgr> so initially we aren't even changing anything about the commitment fee rate. it is just an emergency exit. ofc eventually with package relay we'd like to add 0 fee to the commit tx and drop update_fee 11:57 <+roasbeef> i want to do it eventually as well, I just also favor having smaller deployable items to ensure things don't drag on forever 11:57 < rusty> roasbeef: naah, the idea was minimal fees, not zero in last proposal. 11:57 < BlueMatt> roasbeef: you can never have zero fees, you have to have *some* fees, and some rather trivial fee (say, 10 sat/byte) isnt all that much anyway. 11:57 <+roasbeef> rusty: ok but in order to _remove_ update_Fee, yuou need to make sure you can actually get into the mempool 11:58 <+roasbeef> in order to ensure that you either need to be able to update the commitment, or be sure that you can relay the commtimetn along with its anchor to be accepted as a pair 11:58 < BlueMatt> but, I think there was agreement on it being a seaparate feature bit, cause y'all wanted it separate. 11:58 < rusty> roasbeef: sure, which you do by picking a feerate like 253 sat / ksipa. 11:58 < t-bast> naive question: if you remove udpate_fee does it mean that you'll force your wallet to keep as many UTXOs as the number of open channels that you have to handle their potential closing? 11:58 <+roasbeef> at that point, then you also need to consider what to do about the coop close fee negotaation, which atm uses the commitment fee as a ceiling, it's really an independent change 11:58 < rusty> t-bast: naah, you can thread them, but you have to handle reorg. 11:58 < cdecker> t-bast: only as many concurrent closes you expect 11:59 <+roasbeef> rusty: how can you be sure that's enough? relative high water marks for fee rates can rise 11:59 < t-bast> in the worst case you expect an attacker to make you close everything if they somehow detect you don't have enough UTXOs to inject your fees 11:59 < t-bast> and they may be able to cheat you 11:59 <+roasbeef> err as in what nodes will accept at a cerain level of mempool sautration 11:59 < BlueMatt> roasbeef: that mark has...never gone *that* high, is the point 11:59 < BlueMatt> fees have gone to 1k sat/byte or higher 12:00 < niftynei> t-bast, i think you'd need one UTXO, with enough funds to cover all of fees for all outstanding anchored outputs 12:00 <+roasbeef> i don't know what the future holds, we should design things to be robust against future unexpected behavior 12:00 < BlueMatt> but the *mempool fee* has never gotten nearly as high. 12:00 < BlueMatt> right, I think the point is if we get to that point we can resolve the issue another way (eg package relay) 12:00 <+roasbeef> t-bast: splicing can also help out with this, or using stuff like Loop to make utxos from channels 12:00 < sstone> what about pending HTLCS ? don't you need utxos for them too ? (though I can you can combine them) 12:00 < BlueMatt> like, if fees spike to that extend its really not hard to deploy some package-relay-y nodes or bump the mempool size. 12:01 < t-bast> niftynei: good to know...but it still feels dangerous because you need your wallet to be aware of your channels and account for all of them (pessimistic case)...sounds like a nightmare to have a good UX on top of that 12:01 < BlueMatt> naive/simple package relay suhas already has a patch for 12:01 < rusty> sstone: yeah, you can get clever and combine them and also thread change outputs through the others, but it gets complicated really fast. 12:01 < BlueMatt> and in this case especially we need only a trivial form of package relay 12:01 <+roasbeef> p2p deployments like that don't have very reliable time frames as you know BlueMatt, but this is all an off shoot we want to do it eventually, but there aren't even proposals to do it outright, and that shouldn't block us from improving the current state of things 12:01 < joostjgr> dropping update_fee eventually, it is hardly a spec change is it? just don't update the fee anymore. from the perspective of taking small incremental steps, just adding the 2 anchors for now sounds best to me 12:01 -!- jonatack_ [~jon@37.173.132.239] has joined #lightning-dev 12:01 <+roasbeef> can we return to the core discussion itmes here? the two joostjgr mentioned above 12:02 < rusty> Yeah, we'll end up witha feature bit "option_constant_fees" and it'll be pretty clean IMHO 12:02 < joostjgr> then we also need to worry yet about having those utxos available etc 12:02 < BlueMatt> right, it as a separate feature bit seems fine enough. I thought that was the conclusion anyway. I'm just suggesting it happen in a month, not in two years. 12:02 <+roasbeef> joostjgr: yeh exactly, there's a very light mode, either you use it or you don't, upon opening a channel you acn already set a fee rate 12:03 * rusty lost track of what we were supposed to be arguing about? 12:03 < BlueMatt> same 12:03 < niftynei> mmh this anchor thing is interesting because it pushes the feerate requirement out to the 'total wallet balance' instead of just 'fees in channel' 12:03 < t-bast> let's argue about fee management, that always works 12:03 <+roasbeef> 14:31 < joostjgr> we are actively implementing the new anchor outputs commitment tx. today got it running end to end for the first time. highest prio for now is to decide on the outstanding q's: anchor size and remote csv delay value 12:03 <+roasbeef> anchor size and csv selection 12:03 < t-bast> niftynei: that's exactly how I see it too 12:03 < joostjgr> w/r to the anchor size: we are most comfortable with adding a field for it on the open_channel message (just there) and specifying in the spec 'should set it to 283 sats'. so it is almost a constant, but there is a way out in case something unexpected happens without changing the spec 12:03 < niftynei> yeah t-bast it was your comment that made me see this 12:04 < t-bast> niftynei: it doesn't make it simpler if you look at the whole picture, it just pushes the complexity to the wallet instead of the lightning spec/node 12:04 <+roasbeef> niftynei: you can borrow some utxos from a homie to close out a channel 12:04 < BlueMatt> Does anyone have a reasonable argument why it needs to be non-static 12:04 <+roasbeef> t-bast: but gives you more control that right now is an illusion 12:04 < niftynei> so every channel closure becomes a 'global wallet consideration' 12:04 < niftynei> at least wrt to available funds 12:04 < BlueMatt> like, I think we all agree it likely will never *raise*, so unless someone thinks 200 sat is, like, a lot of money, or will be in the near future..... 12:05 -!- jonatack [~jon@37.170.7.180] has quit [Ping timeout: 276 seconds] 12:05 < BlueMatt> (or am I missing something and someone actually *does* think it needs to be more than 200-whatever sat?) 12:05 <+roasbeef> BlueMatt: why lock your channel into a configuration that makes strong assumptions about the future? in either case nodes can use a widely agreed upon defualt (200 sat or w/e), but we're not locked in to anything 12:05 < niftynei> roasbeef, yeah but ... that's something you have to consider with anchors. whereas before you didn't have that opportunity 12:05 < joostjgr> to me, the field sounds like cheap insurance. all implementations can just enforce 283 for now 12:05 <+roasbeef> my response is idk, so ppl can use a vaule today, but the protocol doesn't epcify one 12:05 < rusty> Testing constants is simpler. 12:05 < BlueMatt> roasbeef: my point is that you're equally locked in with or without the bit in the message 12:05 < niftynei> like right now the reserve kind of acts like the fee reserve reservoir 12:05 < BlueMatt> cause you'd want to just say "oh, you didnt send me the number 200-whatever, closing" 12:06 <+roasbeef> BlueMatt: locked in for one chan is diff than all chans being locked in 12:06 < niftynei> the 'homi'e, if you will 12:06 < BlueMatt> so you might as well make it a feature bit (in the absurdly unlikely scenario it needs to change) 12:06 < niftynei> *'homie' 12:06 < BlueMatt> well, if you always error if its not a given value, you *should* use a feature bit 12:06 <+roasbeef> make what a feature bit? being able to chose? 12:06 < BlueMatt> to indicate that you wont reject it 12:06 < BlueMatt> changing the value 12:06 < rusty> There's no difference between an enforced constant over the wire and an enforced constant not sent. We can agree and deploy on a new field for this in, like, 30 minutes if we need. 12:07 < BlueMatt> I mean the difference is having yet another thing to check in the state machine....a thing that you have to check and track that never changes and that you enforce to always be a constant 12:07 < rusty> It would literally be a new odd/even TLV field pairing. 12:07 < BlueMatt> it....might as well be a constant, and if, in 10 years, we have to change it, a feature bit is easy enough. 12:07 <+roasbeef> it's just initial validation, as you shoudl sanity check all the other parameters BlueMatt 12:07 < joostjgr> i am not sure about that 30 mins. in theory yes, but who knows what new angles we have then to discuss. if the field is already there, we can upgrade without coordination 12:07 < rusty> joostjgr: no you can't because everyone else will reject it once you change it! 12:07 < BlueMatt> joostjgr: my point is you cannot do that! 12:07 <+roasbeef> "everyone else" 12:07 < BlueMatt> you can only change the value in that field by corrdination 12:08 < BlueMatt> so even if you have the field, you probably want a feature bit if you ever change it anyway 12:08 < joostjgr> if you open a channel to a node not supporting a different value, then it won't work indeed. but among nodes that enlarged the range, it does 12:08 < BlueMatt> to indicate "I wont reject if the field is something other than 2XX" 12:08 < BlueMatt> right, and the way we coordinate that kind of thing is feature bits :p 12:08 < rusty> joostjgr: yeah, that's trivial, it's an odd tlv field addition. 12:08 <+roasbeef> they'll send back and error and you can retry or not, just like all the other fields in OpenChannel BlueMatt 12:08 < joostjgr> min channel size also isn't coordinate currently through feature bits 12:09 < BlueMatt> joostjgr: and min channel size has cause issues with ux cause its not coordinated ;P 12:09 < rusty> joostjgr: good example, and it's terrible UX. It gets worse for more obscure things than amounts, too. 12:09 < BlueMatt> (see recent tweets about lightning app where people sent money in and got vague errors about not having sent enough money in) 12:09 < joostjgr> but is the solution a feature bit or a better error? 12:09 < BlueMatt> the solution is to fix it so there are less things that go wrong 12:10 < BlueMatt> I dont quite understand why "have fewer things that can go wrong" is a weird argument? 12:10 < joostjgr> with something like min channel size, idk what the fix would be other than communicating your range 12:10 < rusty> Yeah, I'm leaning on 253 as a constant and lack of interop problems. An error saying "your anchor output is too low" is not very useful for most users, since they don't control it. 12:10 < joostjgr> we can't start advertizing desired ranges in feature bits right? 12:10 < BlueMatt> sure, in cases where its really clear that different nodes/users/impls really have good reasons for different values today I'm not gonna suggest fixing it 12:11 < BlueMatt> but here we definitely do not have such a case 12:11 < joostjgr> this is all not about us today wanting to do anything other than 253. it is just about having the field as an fast forward path in case we need it 12:11 < BlueMatt> a field is *not* sufficient for a "fast forward path" 12:12 < BlueMatt> you need a way to find peers that allow you to change it, and at that point....well a field in open_channel isnt sufficient 12:12 < joostjgr> fast forward path as in that implementations can upgrade independently and if there ranges overlap, it works 12:12 < BlueMatt> it kinda works, but only kinda mostly, and cuases real ux issues today 12:12 < rusty> joostjgr: then you must require a range today, not a constant. 12:12 < BlueMatt> ranges?! 12:12 < rusty> You cannot have both. 12:12 < joostjgr> the range today is 253-254 12:12 < joostjgr> 253-253 12:12 <+roasbeef> we haven't had many issues with it ourselves, just as nodes today can select csv values, conf limits, etc 12:12 < BlueMatt> why would anyone ever have a range? 12:13 < BlueMatt> if it changes (as in "protocol is changing, must now be a higher value") then it will change to 2000-2000 12:13 < BlueMatt> not 253-2000 12:13 < rusty> roasbeef: no, we have had massive problems, you've just steamrolled us here, by higher deployment numbers. 12:13 <+roasbeef> higher numbers for what rusty ? 12:13 < rusty> roasbeef: more nodes.... we've had to adjust our ranges to work. 12:14 <+roasbeef> what ranges? 12:14 < joostjgr> i think this is more of a fundamental discussion, or is there anyone who sees difficulty in a hardcoded rejection of anything that is != 253 ? 12:14 < rusty> roasbeef: what we accept from LND nodes. 12:15 < rusty> joostjgr: we keep making this same mistake IMHO. We can't decide, so we punt by making it adjustable "just in case". That's how we got so many tunable knobs which can't really be tuned in the first place. 12:15 < rusty> (Since you need to know what all peers will actually accept, to change it) 12:15 <+roasbeef> i'm mostly afk now btw, we're over 12:15 <+roasbeef> rusty: some params are fundamentally dynamic though, like the conf target or a csv values 12:15 < rusty> roasbeef: closemeeting? I think you have to do it? 12:16 <+roasbeef> #endmeeting 12:16 < lightningbot> Meeting ended Mon Nov 25 20:16:04 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:16 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-11-25-19.08.html 12:16 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-11-25-19.08.txt 12:16 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-11-25-19.08.log.html 12:16 < lndbot> What if I want to set my Bitcoin node's dustlimit higher? The suddenly the ln implementation is incompatible with a static anchor size 12:17 < rusty> johanth That was kind of Matt's point, you can't actually do this since there are an increasing number of things built on bitcoin which have to make P2P assumptions/ 12:17 < lndbot> Sorry, just jumped in now, will reread the beginning of the discussion 12:17 < cdecker> Thanks roasbeef for chairing ^^ 12:18 < t-bast> Thanks guys, very interesting to see the discussion on anchor outputs, I need to dive deeper in the details and current threads 12:19 < joostjgr> Yes, to be continued. But I definitely get a safe feeling when I see those anchors on my commitment txes 12:19 < t-bast> :P 12:19 * BlueMatt has a feeling this will not be resoloved until a meeting happens with a higher-bandwidth communication mechanism 12:20 < BlueMatt> too much cross-talk on irc 12:20 < t-bast> I totally agree 12:20 < t-bast> We can setup a hangout meeting to continue the discussion 12:20 < t-bast> And focus specifically on anchor outputs 12:20 < t-bast> That would be helpful 12:21 < lndbot> :+1: 12:25 < niftynei> +1 12:35 < t-bast> I tagged you in https://github.com/lightningnetwork/lightning-rfc/issues/706 12:35 < t-bast> Let's organize on Github to find a time where most of us can attend 12:37 -!- t-bast [~t-bast@2a01:e34:ec2c:260:b0a2:cdf:c92e:417e] has quit [Quit: Leaving] 12:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 12:38 -!- arij [uid225068@gateway/web/irccloud.com/x-iktopjqurnlqaqou] has joined #lightning-dev 12:40 -!- mattcruzz [~mattcruzz@tm.84.52.146.243.dc.cable.static.telemach.net] has joined #lightning-dev 12:41 -!- mattcruzz [~mattcruzz@tm.84.52.146.243.dc.cable.static.telemach.net] has left #lightning-dev [] 12:41 < mattcruzz> . 12:41 < mattcruzz> clear 12:46 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 12:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 12:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 12:56 -!- mattcruzz [~mattcruzz@tm.84.52.146.243.dc.cable.static.telemach.net] has joined #lightning-dev 12:57 -!- mattcruzz [~mattcruzz@tm.84.52.146.243.dc.cable.static.telemach.net] has left #lightning-dev [] 13:10 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #lightning-dev 13:46 -!- _jerry [~jerry@142.134.28.200] has joined #lightning-dev 13:46 -!- bitbanger [~jerry@142.134.28.200] has joined #lightning-dev 13:47 -!- bitbanger [~jerry@142.134.28.200] has quit [Client Quit] 13:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 13:56 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving] 14:15 -!- diogosergio [~diogoserg@176.24.23.243] has joined #lightning-dev 14:20 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving] 14:36 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 268 seconds] 15:06 -!- diogosergio [~diogoserg@176.24.23.243] has joined #lightning-dev 15:17 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 15:21 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 15:22 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 260 seconds] 15:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 15:34 -!- captjakk [~captjakk@174-16-221-137.hlrn.qwest.net] has joined #lightning-dev 15:46 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 15:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 15:53 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 16:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 16:19 -!- hiroki_66 [77f50162@pl99426.ag2001.nttpc.ne.jp] has quit [Remote host closed the connection] 16:21 -!- marcoagner [~user@2001:8a0:6a55:8f00:81e3:c539:c514:2d18] has quit [Ping timeout: 246 seconds] 16:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 17:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 17:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 17:47 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 246 seconds] 18:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 18:28 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has joined #lightning-dev 18:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 18:44 -!- nobody123 [~nobody123@194.36.108.68] has quit [Ping timeout: 250 seconds] 19:26 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev 19:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 19:57 -!- jonatack_ [~jon@37.173.132.239] has quit [Read error: Connection reset by peer] 20:00 -!- captjakk [~captjakk@174-16-221-137.hlrn.qwest.net] has quit [Remote host closed the connection] 20:08 -!- captjakk [~captjakk@174-16-221-137.hlrn.qwest.net] has joined #lightning-dev 20:37 -!- captjakk [~captjakk@174-16-221-137.hlrn.qwest.net] has quit [Remote host closed the connection] 20:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 21:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 21:30 -!- yaslama_ [~yaslama@bzq-218-78-150.red.bezeqint.net] has quit [Read error: Connection reset by peer] 21:30 -!- yaslama [~yaslama@bzq-218-78-150.red.bezeqint.net] has joined #lightning-dev 21:45 -!- _jerry [~jerry@142.134.28.200] has quit [Ping timeout: 265 seconds] 21:59 -!- dr-orlovsky [~dr-orlovs@91.240.140.128] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 22:28 -!- jonatack_ [~jon@37.173.132.239] has joined #lightning-dev 22:28 -!- jonatack_ [~jon@37.173.132.239] has quit [Client Quit] 22:28 -!- jonatack [~jon@37.173.132.239] has joined #lightning-dev 23:10 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 23:11 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Quit: %bye%] 23:12 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 23:20 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev --- Log closed Tue Nov 26 00:00:19 2019