--- Log opened Mon Aug 31 00:00:04 2020
00:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
00:09 -!- marcoagner [~user@2001:8a0:6a45:1900:2fd7:e0f0:d356:dd70] has joined #lightning-dev
00:32 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 244 seconds]
00:51 -!- bluudix [~bluudz@103.108.94.41] has joined #lightning-dev
00:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
01:00 -!- Netsplit *.net <-> *.split quits: cryptapus, ianthius, bluudz, JD2983, CubicEarth
01:00 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
01:05 -!- ianthius [~ianthius@unaffiliated/ianthius] has joined #lightning-dev
01:05 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev
01:05 -!- JD2983 [~jarret@S01069050cacf3d53.ed.shawcable.net] has joined #lightning-dev
01:05 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev
01:46 -!- jonatack [~jon@213.152.161.40] has joined #lightning-dev
01:48 -!- sr_gi [~sr_gi@static-75-213-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
01:49 -!- sr_gi [~sr_gi@static-75-213-224-77.ipcom.comunitel.net] has joined #lightning-dev
01:57 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
02:26 -!- arowser [~arowser1@67.230.166.11.16clouds.com] has quit [Ping timeout: 256 seconds]
02:28 -!- laptop [~laptop@85-195-244-64.fiber7.init7.net] has joined #lightning-dev
02:58 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
03:10 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
03:42 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
03:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
04:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 258 seconds]
04:05 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
04:20 -!- jonatack [~jon@213.152.161.40] has quit [Ping timeout: 240 seconds]
04:38 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
04:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
04:41 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
05:13 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev
05:38 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:05 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:05 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:06 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:06 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:09 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:09 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:10 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:10 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:11 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:11 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:20 -!- laptop [~laptop@85-195-244-64.fiber7.init7.net] has quit [Ping timeout: 256 seconds]
06:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
06:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
06:25 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:25 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:27 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
06:44 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds]
06:47 -!- laptop [~laptop@2001:1711:fa4f:17b0:a139:11a8:17ed:1229] has joined #lightning-dev
06:50 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:51 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:51 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
06:52 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
06:57 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
07:20 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Quit: leaving]
07:24 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined #lightning-dev
07:28 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
07:37 -!- Netsplit *.net <-> *.split quits: waxwing, wraithm
07:37 -!- waxwing [~waxwing@193.29.57.116] has joined #lightning-dev
07:39 -!- Netsplit over, joins: wraithm
07:43 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
07:51 -!- laptop [~laptop@2001:1711:fa4f:17b0:a139:11a8:17ed:1229] has quit [Ping timeout: 244 seconds]
08:07 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
08:08 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
08:30 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host]
08:30 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #lightning-dev
08:43 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
08:44 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
08:47 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
08:47 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
09:08 -!- laptop [~laptop@xdsl-31-164-241-123.adslplus.ch] has joined #lightning-dev
09:10 -!- laptop [~laptop@xdsl-31-164-241-123.adslplus.ch] has quit [Read error: Connection reset by peer]
10:00 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
10:00 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
10:09 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
10:24 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
10:46 -!- vtnerd_ [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 264 seconds]
10:48 -!- vtnerd_ [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
11:26 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev
11:26 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
11:26 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
11:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
11:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
11:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]
11:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
12:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
12:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
12:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
12:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection]
12:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
12:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
12:18 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
12:39 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds]
12:44 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
12:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
13:00 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
13:00 < niftynei> hello hello
13:00 < sstone> hi everyone!
13:00 < niftynei> hi sstone!
13:01 < ariard> hello
13:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
13:03 < rusty> Hello everyone!
13:04 < rusty> Who's chairing today?  cdecker is out today, BTW.
13:04 < sstone> so is t-bast
13:05  * rusty looks at niftynei
13:06  * niftynei looks at bitconner
13:06 < niftynei> i'd be happy to chair, but i will admit that i'm a bit out of the loop on what our priorities are for today
13:07 < rusty> niftynei: heh, I did all the easy ones last time :)
13:09 < niftynei> hah. ok well, i can just go through the things tagged Meeting Discussion
13:09 < niftynei> #startmeeting
13:09 < lightningbot> Meeting started Mon Aug 31 20:09:17 2020 UTC.  The chair is niftynei. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:09 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:09 < rusty> Looking through the list there's nothing urgent.  Might be nice to discuss what people are working on, e.g. dual funding, offers, random routing?
13:10 <+roasbeef> oy
13:10 < niftynei> That sounds like a plan. Open floor then. Does anyone have a topic, PR or issue they'd like to discuss?
13:11 <+roasbeef> thanks for the latest comments on the ML rusty  re dynamic commitments 
13:11 < ariard> right, what's the state of dual-funding?
13:11 < rusty> Oh, yeah, dynamic commitments FTW too!
13:12 < niftynei> sure, i can give a brief dual-funding update. 
13:12 <+roasbeef> i'm working on a stand alone docuemnt describing a protocol extension, trying to get away from editing the spec in-line, as it can be hard to review and also jsut see at a glance what's the "base" version of things 
13:12  * bitconner pulls up a seat
13:12 <+roasbeef> so it would be a more BIP-like stand alone doc, and ppl can say oh I implement "bolt exttension 0002" or w/e it's called  
13:12 <+roasbeef> hopefully should have the initila draft up, then we can go from there to iterate 
13:13 < niftynei> the implementation is in progress, i'm looking to have a draft for the spec out as soon as the impl is done
13:13 <+roasbeef> if no other q's on that, can give niftynei the floor to talk about dual funding 
13:13 < rusty> roasbeef: yeah, cool.  I think it'll be fairy easy to implement, TBH.
13:14 <+roasbeef> def, hoping also it can serve as a possible new template for spec extensions that're more de-sync'd and standalone, as we basically have a buncha if statements in the spec rn that can be hard (imo) for a new implementer to parse 
13:15 < ariard> niftynei: does the spec is ready for another round of review?
13:15 < niftynei> does anyone have a link to the mailing list post on dynamic commitments handy?
13:15 < ariard> roasbeef: does this would scope the recent proposal for skipping channel confirmation
13:15 < ariard> this kind of stuff doesn't have to be part of the "hard" spec IMO
13:16 <+roasbeef> ariard: i think yes and no, imo it should be in the spec given it may have considerations on the invoice, or what's sent in the payload 
13:16 < ariard> niftynei: this https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html ?
13:16 < niftynei> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
13:16 < niftynei> ty!
13:17 <+roasbeef> as rn it may not be explciit in the spec, but nodes out of the box don't allow zero conf channels from the get go 
13:17 < niftynei> #topic dynamic commitments
13:17 <+roasbeef> it may also be a chance to just start to using a pubkey rather than a chan id, since hte pubkey is set in stone, and using tlv we can provide that only to the final hop, then the final and true dest can use w/e protcol to decide which chan to dispatch on 
13:17 < ariard> I read again the spec, it's really fuzzy on this, like doesn't explicitly forbid minimum_depth=0
13:17 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
13:17 < lnd-bot> [lightning-rfc] rustyrussell opened pull request #798: DRAFT: Offers (master...guilt/offers) https://github.com/lightningnetwork/lightning-rfc/pull/798
13:17 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
13:17 <+roasbeef> yeh it doesn't, but in practice I don't think anyone allows it
13:18 < ariard> but also onion payload should be flexible enough to let anyone play with them with all network supporting parsing
13:18 <+roasbeef> but there're nodes out there that use it now for their services like phoenix and breez
13:18 <+roasbeef> ariard: yeh, may just need some new invoice tag 
13:18 < ariard> right, and they would like to standardize their services ?
13:18 < rusty> roasbeef: yeah, for onion messages I allow either scid or pubkey.  Though I've gone for 32-byte pubkeys...
13:19 < rusty> roasbeef: yeah, a new invoice feature bit?
13:19 < ariard> it's mostly a namespace issue post-tlv ?
13:19 <+roasbeef> ariard: yeah, just so ppl know what's supported and expected
13:19 <+roasbeef> ariard: i think so yeh, but has some spec implications as ppl need to know what the standard way of doing it 
13:19 <+roasbeef> and also the risks, etc 
13:19 <+roasbeef> rusty: yeh i think minimally that'd be enough 
13:19 <+roasbeef> simpler, as then there's no need to negotiate a special sid 
13:19 < ariard> roasbeef: does the keysend/spontaneous payment thing should go in this proposed  spec extensible subspace
13:20 <+roasbeef> sci? short channel id lol 
13:20 <+roasbeef> ariard: so i think that's better as a standlone doc, and extension like thing 
13:20 <+roasbeef> since it's just about how to interpret data which you can already transmit on the network now w/ tlv 
13:20 <+roasbeef> but there's also a meta topic here, w.r.t how the best way to evolve the spec in a "scalable" manner is, while also having the opportunity for ppl to document higher level application protocols 
13:21 < ariard> and that's what you've in mind for the BIP-like stand alone doc, a repository of canonical onion payload or looser/stricter policies
13:22 < ariard> we have what 3 level ? core spec, custom payloads/policies and clearly experimentation?
13:22 <+roasbeef> ariard: yeh, which are maybe linked from the main spec depending on the section and what's the "default", etc 
13:22 < rusty> roasbeef: cdecker has thoughts on that.  He wants the separate rationale doc for each one, which I kind of agree with.  Though some stuff still has to be core, esp. if it's planned to obsolete existing stuff.
13:22 <+roasbeef> rn we have of this in the wiki (which versions are used, etc), but it isn't very structured 
13:23 <+roasbeef> rusty: mhmm, like rn when someone goes to implement channel state machine for the first time, they'd presented w/ basically 3 diff ways to do it which can be confusing, not sure but just trying to put myself in the shoes of someone getting into this stuff for the first time 
13:24 <+roasbeef> also in this path there wouldn't just be some like mega doc for stuff like routing/forwarding which is a rather large space 
13:24 <+roasbeef> but i'll kinda loosely propose a format w/ the dynamic commitments spec draft, then we can take feedback from there to arrive on kinda a teplate 
13:24 <+roasbeef> template*
13:25 < rusty> roasbeef: yeah, go for it.  At worst, we end up merging it afterwards, but that's easier than mangling in place anyway.
13:27 < niftynei> sounds like we're really talking about a meta topic here, how to update the RFC structure to accommodate documentation for spec 'extensions'
13:27 < rusty> niftynei: even better, roasbeef just volunteered to do a trial balloon! 
13:29 < ariard> niftynei: wrt to dual-funding, there is a slight issue where a counterparty propagate both a double-spend a dual-funded tx, effectively blocking you to CPFP it
13:29 <+roasbeef> ok let's go to dual funding now? 
13:30 < niftynei> #action roasbeef to trial balloon new 'bip-like' format for spec extensions with dynamic commitments
13:30 < niftynei> sure sgtm
13:30 < niftynei> #topic dual funding :tada:
13:31 < niftynei> im working on the implementation, ive got a few lnprototests done for one half of the protocol stuff, hoping to get the other half done by the next meeting
13:32 < niftynei> ariard, i'm not sure waht you mean by "where a counterparty propagate both a double-spend a dual-funded tx"
13:32 < rusty> Two Weeks(TM)
13:32 <+roasbeef> oooooOOOo, lnprototests
13:33 < niftynei> yeah, there's an accepter + opener "side", the accepter side has two working prototests stuff -- honestly it's much nicer than the first draft of lnprototests that rusty had going
13:33 < rusty> The protocol is important because we can reuse it for shutdown / splice.  It's a generic tx negotiation protocol.
13:34 < ariard> niftynei: Alice commits 1 BTC, Bob commits 0.1 BTC in their dual-funding tx, they exchange signature, Bob propagate a RBF-disabled low-feerate double-spend of his 0.1 BTC
13:34 < niftynei> ok so the dual-funded tx won't get confirmed
13:34 < ariard> niftynie: Alice will broadcast the dual-funding, which would perevent her to double-spend back until it expires from her mempool
13:35 < ariard> niftynei: yes you block dual-funded tx propagation across network mempools
13:36 <+roasbeef> ariard: why's that an issue? w/e gets confirmed first gets confirmed 
13:36 < rusty> ariard: but Alice can also spend her way out when she gets sick of waiting?
13:36 < niftynei> that dual-funded tx is dead-on-arrival then
13:36 <+roasbeef> which is why confs are nice 
13:36 < niftynei> alice just spends her 1btc elsewhere ??
13:37 < ariard> rusty: assuming broadcast the funding tx in her mempool, her honest double-spend back will be rejected by her own mempool if it's not superior to funding_tx feerate/absolute fee
13:37 <+roasbeef> the core thing here seems to be the "back out" shenanigans, so ppl doing set up then just bailing after they get w/e info they're after
13:37 < ariard> assumig she broadcasts
13:37 < rusty> ariard: sure.
13:37 <+roasbeef> but re the pinning or double spend thing, doesn't seem like an issue assuming the channel isn't used til stuff confirms 
13:37 < ariard> roasbeef: it's not a fund-loss risk, more I stuck your funds in mempool for nothing
13:38 <+roasbeef> yeh it's a nuisance thing kinda 
13:38 <+roasbeef> but what does the perpetrator gain? 
13:38 <+roasbeef> they also end up wasting their time and chain fees 
13:38 < niftynei> by stuck you mean subject to RBF, i'd assume
13:38 < ariard> yes a nuisance, better would be to have redundant tx broadcast, to avoid being obstrucated by your own mempool
13:39 <+roasbeef> redundant tx being what? 
13:39 < ariard> roasbeef: they may force you to loose more timevalues on your funds than him, as inputs might not be worth the same
13:39 <+roasbeef> like some intermediate mult-sig output? 
13:39 < niftynei> as long as alice set her sequence to be RBF'albe she'll always be able to spend that utxo input elsewhere
13:39 <+roasbeef> ariard: sure a whale doesn't care I guess lol
13:39 <+roasbeef> the real solution is to just burn all the mempool policy stuff to the ground
13:39 < ariard> roasbeef: sure, but few hours of funds pinned in the mempool is less liquidity in channels :)
13:40 <+roasbeef> and use rbf everywhere
13:40 <+roasbeef> kek
13:40 <+roasbeef> full rbf*
13:40 < rusty> ariard: you can't simultaneously exchange sigs, so there's always a case where only one side can broadcast if malicious, right?
13:41 < ariard> rusty: sure simultaneously exchange sigs doesn't exist, but in fact exchange delta is inferior to tx-relay propagation on base layer
13:41 < ariard> so in practice even if malicious is second, you can beat the honest one by connecting to a lot of nodes
13:42 < ariard> I think that's a slight issue, and not much we can do, just to be aware of
13:42 < niftynei> im not seeing the harm here other than 'a few hours of theoretical liquidity not existing' which seems about the same as a channel peer falling offline, no?
13:42 <+roasbeef> idk how much I'd be worried about something like this myself if I had a dual funded node, I think most implemetnations also have the ability now to preferenttially accept/reject inbound funding requests 
13:42 < rusty> ariard: I don't think we want to require an extra tx for opening everywhere though.
13:42 <+roasbeef> it also isn't costless, tho ofc "cost" is relative 
13:43 <+roasbeef> yeh mo txns mo bad 
13:43 < ariard> a real question is the fee model of dual-funded, IIRC it's only RBF for now, there is no anchor outputs to let non-interactive fee-bumping?
13:43 < niftynei> no there are no anchor outputs on dual-funded open tx, it's all RBF
13:43 <+roasbeef> that could be added, or the protocol sends out diff sig versinos fo bump, but that requires no_input for the commitments 
13:44 < ariard> rusty: sure I agree not worth fees/blockchain space, loosing few hours of liquidity is okay for now, but in the future it might an important channel opening and just break your whole liquidity strategy for the day
13:44 <+roasbeef> so you pre-sign like incrementing fee rate versions (this may already be in the draft, I'm out of date) 
13:44 <+roasbeef> we also def talked about this in adelaide too iirc 
13:44 <+roasbeef> years later....we're still talking about fees lol
13:44 < rusty> ariard: yes, which is why we need mempool to be more adversarial-safe.  In general this statement is true :)
13:44 < ariard> roasbeef: the ability to accept/reject inbounb assumes a key management policy ?
13:45 <+roasbeef> ariard: idk if needs key management, but some sort of heuristics to gate off of 
13:45 < ariard> rusty: I know, for now I'm just trying to inform core devs they should have a stable mempool policy: https://github.com/bitcoin/bitcoin/issues/19820
13:45 < niftynei> multiple feerate bands are not in draft, it's assumed you'd just go back and re-negotiate if the feerate changes (i.e. rbf)
13:45 <+roasbeef> like: only accept from nodes that hav ebeen around for T period of time w/ N btc in chasn or somethign like that 
13:45 < ariard> which is a philosophical change wrt to how they think p2p issues until now
13:45 <+roasbeef> it's p2p, but at the end of the day, these are voluntary actions, and not all nodes are super well managed, tho that's getting better imo w/ better tooling, etc 
13:45 < ariard> well they should have something like a policy, not policies-undocumented-across-versions-which-may-silently-break-LN-nodes
13:46 < niftynei> the 'preprint' (lol) dual funding draft is over here https://github.com/niftynei/lightning-rfc/pull/1, no guarantees it'll be the same in two weeks though lol
13:46 < niftynei> #link zv
13:46 < niftynei> #link https://github.com/niftynei/lightning-rfc/pull/1
13:46 <+roasbeef> guard rails like that, also mitigate certain classes of attacks by making it harder to make wide spread connectiosn to exiting nodes 
13:46 <+roasbeef> you gotta work your way up basically
13:46 < ariard> roasbeed: I was just pointing we should adresss mempool/p2p issues at their level if we can, while minding if we can address at upper layers that might good too
13:46 <+roasbeef> ariard: idk if it breaks nodes, but the error message can be used to explain some of the policy 
13:46 <+roasbeef> ah yeh, hard to keep track of all the convos rn kek
13:47 < niftynei> we'll probably be talking about fees in 2040 still lol
13:47 < ariard> roasbeef: for now we don't have any API stability of something like carve out
13:47 <+roasbeef> yeh....one thing I've learned is never underestimate the complexity of fees w.r.t any sort of off-chain multi-party protocol 
13:47 <+roasbeef> member when we could just ignore it all together? 
13:48 <+roasbeef> those were the days....
13:48 < rusty> roasbeef: yeah, hide "and we ignore fees" in the preamble of your paper, and publish!
13:48 < ariard> niftynei: negotiating back assume interactivity which is not great
13:48 < niftynei> having a channel open assumes interactivity
13:48 < ariard> like your funds might be in a cold wallet, your fee model is wrapping on your key management setup
13:48 <+roasbeef> rusty: lol yeah, "for simplicity of our model..."
13:49 < ariard> niftynei: yes, and that's maybe okay to do back-and-forth with your cold wallet but once it broadcasts, during the wallet round-trip feerate may change again
13:49 <+roasbeef> niftynei: ariard if this is about rbf for fee bumping, why not just pre-sign N versions w/ increasing fee rates? that can be done in a single shot, but needs no_input as mentioned 
13:49 <+roasbeef> also, how are we even talking about rbf dual funding bumping w/o no_input? otherwise you need to sign commitment sigs again 
13:50 < rusty> roasbeef: yeah, you basically start renegotiating to double-spend the first one.
13:50 < rusty> It's simple, and handles fee spikes.
13:50 < niftynei> the v1 of dual funding "rbf" is identical to "let's restart this discussion"
13:50 < ariard> roasbeef: so far, any off-chain multi-party protocols I've looked on has weird fee isssues, LN just opened the way
13:50 <+roasbeef> niftynei: gotcha
13:50 <+roasbeef> ariard: yeh seems to be a given now, something protocol designers need to always keep in mind from here on out 
13:50 < ariard> roasbeef: hmmmm multiple RBF versions you blindly give your counterparty to overshoot in fees
13:51 < ariard> like taking the higher bound when feerare is low, and thus burning 
13:51 < rusty> ariard: "Good news, everyone, we're pioneers!  Also, that's the bad news"
13:51 <+roasbeef> ariard: heh there's that too, you'd basicaly need to decide what the upper bopund is, and if you're splitting, then everyone either pays more or less 
13:51 < ariard> but that's okay if everyone is throwing in the pot the same prorata
13:52 < rusty> Current fees are paid by input and output weights, via simple formula.
13:52 < ariard> roasbeef: you right you need to sign for every commitment, so it's leaking further down in protocol pipeline
13:52 <+roasbeef> leaking what? 
13:52 <+roasbeef> rusty: fsho makes sense 
13:53 < ariard> roasbeef: funding_signed is only one commiment signature?
13:53 < niftynei> we've got about 10 minutes left before the meeting time ends, are there any other topics we should spend time on?
13:53  * rusty changes networks, BRB
13:54 < niftynei> i know rusty's been working on random routing + offers stuff, not sure if any of that is ready for discussion.
13:54 < ariard> in fact we don't need to agree on a anchor output for dual-funding? you can at wish output so just ensure you have one as a local node policy?
13:55 <+roasbeef> other thing to mention on our end is that our 0.11.1 version will include the spec compliant anchors version 
13:55 <+roasbeef> which just means a slight change to the co-op close fee structure, and also using the "official" feature bit 
13:55 <+roasbeef> ariard: the anchor is essentially just your change addr right? 
13:55 < ariard> roasbeef: exact
13:55 <+roasbeef> niftynei: random routing meaning at the client path finding level/ 
13:55 <+roasbeef> ?
13:56 < niftynei> oh. you can add whatever outputs you want to a interactive tx ... if you wanted an anchor output you could just add it
13:56 < ariard> roasbeef: btw, you should propose anchor as a BIP, I mean other protocols are going to re-use it :)
13:56 < ariard> like CoinSwap
13:56 <+roasbeef> ah cool, yeh I can see it being a pattern used depending on the context for most off-chain stuff going forward 
13:57 < ariard> it works for any dual-party protocols ? and I don't see anyone working on N-party protocol before no_input
13:57 < niftynei> roasbeef, yah rusty can say more but the high level is choosing random routes to reach a destination
13:57 < rusty> BTW our next release we decided not to activate anchors (outside --enable-experimental-features), as we don't have any code to CPFP yet, so it's just overhead.  Anyone want to change my mind?
13:58 <+roasbeef> niftynei: gotcha, we _kinda_ do this rn, as we have an internal weighted graph where the weights now are a scaler score dervied from a proability of "success" 
13:58 <+roasbeef> gotcha yeh for us it's still behind a flag rusty 
13:58 <+roasbeef> we want to enabel by default w/ 0.12 hopefully after we add watch tower support and deadline aware fee bumping 
13:58 < niftynei> ariard, the protocol is dual but it's written such that you'd be able to dual-fund multiple opens in the same tx
13:58 < rusty> roasbeef: nice!
13:58 <+roasbeef> rn we also don't yet modify our fee estimate for the comitment trnasaction, but can start to low ball that more once we have the fee bumping in 
13:58 <+roasbeef> oh someoone did some cool analysis on our issue tracker re fee bumping 
13:58 <+roasbeef> sec 
13:59 -!- rdymac [uid31665@gateway/web/irccloud.com/x-dlkdvoardcjzfucx] has quit [Quit: Connection closed for inactivity]
13:59 <+roasbeef> realted to like what "fee function" to use for bumping and other hueritics 
13:59 < niftynei> you'd still be opening 2-party channels tho, so that doesn't really change much
13:59 < rusty> roasbeef: yeah, I figure that mroe than balances the fee increase if done right.
13:59 <+roasbeef> here it is: https://github.com/lightningnetwork/lnd/issues/4215#issuecomment-678177590
13:59 < ariard> niftynei: right, dual-funding is 2-party even if you can run it in parallel with multiple-parties, you only have 2 roles
13:59 <+roasbeef> and a fancy jupyter note book: https://colab.research.google.com/drive/10O0pi_7YR9ZaZB6yUAdcsocFGPpKADER?usp=sharing
14:00 <+roasbeef> w/ 3d graphs n stuff
14:00 < niftynei> #link  https://github.com/lightningnetwork/lnd/issues/4215#issuecomment-678177590
14:00 < niftynei> #link https://colab.research.google.com/drive/10O0pi_7YR9ZaZB6yUAdcsocFGPpKADER?usp=sharing
14:00 < niftynei> faaancy
14:00 <+roasbeef> this is related to the problem of: "when do we bump, how do we target the size of the next bump, how late in the deadline should we bump" 
14:00 < rusty> roasbeef: pretty!!
14:01 <+roasbeef> the initial model is still missing some params, but it is based on looking at historical data of what got into the chain, and then what the fee rate was where "n %" got in, etc 
14:01 <+roasbeef> the top level comment summarizes the initial findings, feel free to dig into the notebook for more info, and you can also fork/edit it I think to poke around more 
14:01 < BlueMatt> roasbeef: it looks like that model doesn't consider any kind of feerate estimator which may change over time?
14:02 <+roasbeef> yeh the limitations are stated at the end
14:02 < BlueMatt> just a pure "well, we guess a fee at the beginning, how should we bump" model? (just checking my understanding)
14:02 <+roasbeef> yeh hard to factor that in right? since ppls fees will impact the estimator right? 
14:02 <+roasbeef> imo i want to live in a future where we almost never look at fee estiamtors, and just low ball then bump up, taking into account past info of attempts 
14:02 < BlueMatt> depends on the estimator....some of them look at the mempool, some less so.
14:02 <+roasbeef> as they're so prone to manipulation 
14:02 <+roasbeef> at least the default type used in bitcoind and elsewhere 
14:03 < BlueMatt> heh, well thats why core's doesnt really look at the mempool :)
14:03 <+roasbeef> orly? has it chagned recently ?
14:03 < BlueMatt> it never (really) did
14:03 <+roasbeef> i thought it looked at the percentile that confirmed at a given fee rate taking into account "wait time" 
14:03 < ariard> darosior is trying to write decent documentation around
14:03 <+roasbeef> which means looking at the mempool w.r.t when it "arrived"
14:03 < BlueMatt> it does, but only marginally at the edge, i believe its about the only fee estimator that tries hard to not look at the mempool
14:04 < BlueMatt> sure, it looks at "things which were in my mempool which got into blocks"
14:04 < BlueMatt> note that last part is what makes it relatively hard to manipulate
14:04 <+roasbeef> BlueMatt: yeh there's an assumption of some starting point (fee guess the fee), fee estimation and historical data coul dbe used as an achor, it assumes we no longer try to thread the needle w.r.t exact conf delays 
14:04 < BlueMatt> (the first is required also to prevent manipulation in a different way)
14:04 < BlueMatt> ok, just checking my understanding, cool work.
14:05 < ariard> core fee estimator is sorting txn across feerate bucket and when a block confirm, kinda score feerates
14:05 < ariard> something something like this
14:05 < ariard> and reorg-safe/mempool-resizing safe
14:05 <+roasbeef> gotcha, seems it's changed a bit since I looked at it last a while ago, will refresh my mental model of it 
14:05 < BlueMatt> (other approaches, eg, whatthefee.io are much more accurate, but of course easier to manipulate)
14:05 < BlueMatt> roasbeef: nah, it *always* avoided looking too hard at the mempool. since first merge iirc.
14:06 <+roasbeef> but my manipulation I mean like the effect we see where someone using really high fes to make some arb play affects everyone else's estimation that blindly targets a short term conf target 
14:06 <+roasbeef> imo it looks at the mempool in sofar as it wathces "delay" 
14:06 <+roasbeef> as it's based on its view of "what got in"
14:06 < BlueMatt> ah, well everything is manipulable if you want to get into the next block, but is it really manipulation if its true :p
14:06 <+roasbeef> but ofc if it never saw something, then it can't use that as a data point 
14:06 <+roasbeef> kek
14:07 < ariard> roasbeef: do you mean network-wise or targeted node manipulation?
14:07 <+roasbeef> I mean like "the observer effect"
14:07 < ariard> we could model the cost of such fee inflation attack and default mempool size (300MB) to know how much it would cost
14:08 < ariard> I see, heisenbug applies to fee-estimation
14:08 < rusty> AFAICT, you can use OOB feepays to drive apparent fees to great heights while not taking a loss (i.e. not having to stuff blocks yourself) and let feerate estimators run wild then profit.   Only real miner decentralization helps against this AFAICT?
14:09 <+roasbeef> cool chat y'all, will follow the rest in logs, off to lunch!
14:09 < rusty> roasbeef: thanks, later!
14:09 < BlueMatt> rusty: I believe in terms of OOB fee attacks, the best you can do is drive *down* estimators (as it appears to outside observers that the prevailing fees are lower)
14:10 < BlueMatt> rusty: *however*, if you allow txn which were not in your mempool when they confirmed to effect your estimator, then, indeed, you could, but this is why core requires both "was in my mempool" and "got confirmed" :)
14:10 < ariard> BlueMatt: but driving them down means relying on what you effectevely see in your local mempool ?
14:10 < rusty> BlueMatt: indeed.
14:11 < BlueMatt> (I do not know what other estimators do, my understanding is that they roughly just look at the current mempool, so, are way more manipulable than this)
14:12 < ariard> rusty: I'm not even sure miner decentralization prevents one power-miner to add huge fees to himself?
14:12 < rusty> BlueMatt: No, wait.  You fill your blocks with OOB txs, plus top 10% from mempool.  This drives core's estimate up.  Keep repeating (assuming demand enough to cause a fee spike)
14:12 < rusty> This is the trivial "reduce blockspace to drive fees" but you don't have to pay as much for it, since you are getting some fees.  Assuming txs with OOB are *not* in mempool.
14:13 < ariard> so it sounds if you want to be secure against manipulation of your local mempool you need background-check against blocks, while minding block feerate can't be trusted
14:13 < BlueMatt> rusty: if the txn were in the mempool, then the attacker runs the risk of paying other miners the fees for said txn (which, my point above stands, you're not manipulating so much as just increasing the fees by paying)
14:14 < BlueMatt> if the oob txn have lower fees, and you're taking oob payments to "virtually increase" the fees, then you're driving the estimator down, but probably not actually working
14:14 < BlueMatt> the current estimator says "at what feerate did transactions take longer than X blocks to get confirmed"
14:14 < ariard> your local fee estimator should discard blockspace not previously seen in local memmpool, that's all?
14:14 < rusty> BlueMatt: not if the txs are not in the mempool. Core ignores them, only sees the expensive ones.
14:14 < BlueMatt> where X is the target you set.
14:15 < BlueMatt> rusty: ah, right, so core isnt looking at what the common/median/whatever feerate is, its looking at what the lowest is.
14:15 < BlueMatt> so even if every block is 95% billion-bitcoin fees, it'll happily pay less as long as lower fee is getting confirmed reliably
14:15 < niftynei> we're 15min over time, i'm going to go ahead and endmeeting
14:15 < rusty> Anyway, we're kinda off-topic.  Anyone have something lightning stuff? :)
14:15 < niftynei> #endmeeting
14:15 < lightningbot> Meeting ended Mon Aug 31 21:15:57 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:15 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-08-31-20.09.html
14:15 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-08-31-20.09.txt
14:15 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-08-31-20.09.log.html
14:16 < BlueMatt> oops, I'm sorry, i thought it was over
14:16 < niftynei> lol. np!
14:16 < rusty> BTW, draft PR for offers https://github.com/lightningnetwork/lightning-rfc/pull/798
14:16 < rusty> Vert very drafty :)
14:19 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
14:20 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
14:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
14:32 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
14:48 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
15:05 -!- nobody123 [~nobody123@dslb-094-216-002-184.094.216.pools.vodafone-ip.de] has quit [Ping timeout: 258 seconds]
15:06 -!- nobody123 [~nobody123@dslb-094-216-002-184.094.216.pools.vodafone-ip.de] has joined #lightning-dev
15:16 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 256 seconds]
15:23 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
15:26 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds]
15:30 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
15:31 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #lightning-dev
15:43 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 265 seconds]
15:46 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
15:56 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
15:57 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
15:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
16:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
16:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 240 seconds]
16:08 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
16:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
16:43 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
16:46 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
16:46 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
16:58 -!- melande11 [~melande@gateway/tor-sasl/melande] has quit [Ping timeout: 240 seconds]
17:05 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has quit [Ping timeout: 240 seconds]
17:11 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has joined #lightning-dev
17:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:17 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
17:19 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 258 seconds]
17:22 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
17:34 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
17:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []
17:47 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
17:47 < lnd-bot> [lightning-rfc] rustyrussell closed pull request #591: Must not filter local gossip (master...never-restrict-local-gossip) https://github.com/lightningnetwork/lightning-rfc/pull/591
17:47 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
17:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
17:58 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
17:59 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 265 seconds]
18:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:02 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
18:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
18:03 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
18:16 -!- ianthius [~ianthius@unaffiliated/ianthius] has quit [Quit: leaving]
18:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
18:31 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
18:31 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
18:38 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
18:38 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 260 seconds]
18:45 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
18:45 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
19:01 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
19:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
19:06 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
19:33 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
19:35 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
19:37 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
19:37 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
19:48 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
19:53 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
19:58 -!- marcoagner [~user@2001:8a0:6a45:1900:2fd7:e0f0:d356:dd70] has quit [Ping timeout: 240 seconds]
20:21 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 258 seconds]
20:37 -!- nobody12_ [~nobody123@dslb-094-216-002-184.094.216.pools.vodafone-ip.de] has joined #lightning-dev
20:39 -!- nobody123 [~nobody123@dslb-094-216-002-184.094.216.pools.vodafone-ip.de] has quit [Ping timeout: 260 seconds]
20:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
21:02 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
21:06 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
21:07 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev
21:07 -!- lndbot1 [~lndbot@138.197.213.35] has quit [Read error: Connection reset by peer]
21:16 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
21:16 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #lightning-dev
21:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
22:17 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
22:17 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
22:37 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
22:37 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
22:47 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
22:54 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
22:57 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
22:58 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
22:58 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
23:03 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
23:07 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
23:10 -!- wullon587 [~wullon@241.243.86.88.rdns.comcable.net] has joined #lightning-dev
23:10 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has quit [Read error: Connection reset by peer]
23:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
23:32 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection]
23:32 -!- arowser [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev
--- Log closed Tue Sep 01 00:00:05 2020