--- Log opened Mon Aug 03 00:00:39 2020 00:15 -!- marcoagner [~user@2001:8a0:6a45:1900:2fd7:e0f0:d356:dd70] has joined #lightning-dev 00:48 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 00:57 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 01:00 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 246 seconds] 01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 01:00 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 01:06 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 01:07 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer] 01:08 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 01:10 -!- __gotcha1 is now known as __gotcha 01:38 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 240 seconds] 01:39 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 01:40 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 01:40 -!- arowser_ [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev 01:41 -!- arowser_ [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection] 01:41 -!- arowser_ [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev 01:49 < m-schmoock> cdecker: https://github.com/lightningd/plugins/pull/130 this works better 01:50 < m-schmoock> whoops, wrong channel. sry 01:53 -!- arowser_ [~arowser1@192.69.88.248.16clouds.com] has quit [Ping timeout: 256 seconds] 01:56 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 02:01 -!- wullon5 [~wullon@241.243.86.88.rdns.comcable.net] has quit [Ping timeout: 256 seconds] 02:02 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 02:04 -!- yzernik_ [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev 02:04 -!- yzernik [~yzernik@2600:1700:dc40:3dd0:99b0:ddf5:d822:5fdf] has quit [Ping timeout: 272 seconds] 02:05 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds] 02:05 -!- __gotcha1 is now known as __gotcha 02:06 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #lightning-dev 02:17 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Quit: Pavlenex] 02:21 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev 02:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 02:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 02:33 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 240 seconds] 02:36 -!- jonatack [~jon@134.19.179.235] has joined #lightning-dev 02:37 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 02:37 -!- jonatack [~jon@134.19.179.235] has quit [Read error: Connection reset by peer] 02:39 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 02:43 -!- jonatack [~jon@37.173.224.129] has joined #lightning-dev 02:53 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 02:53 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 03:08 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 03:09 -!- rdymac [uid31665@gateway/web/irccloud.com/x-xfllsnppipgkixjz] has joined #lightning-dev 03:13 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 264 seconds] 03:16 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer] 03:17 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 03:18 -!- wullon5 [~wullon@241.243.86.88.rdns.comcable.net] has joined #lightning-dev 03:27 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex] 03:42 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 03:42 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 03:43 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 03:43 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 03:55 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 03:55 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev 03:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 03:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 03:58 -!- vasild_ is now known as vasild 04:06 -!- jonatack [~jon@37.173.224.129] has quit [Read error: Connection reset by peer] 04:30 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 04:39 -!- yzernik_ [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 240 seconds] 04:50 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 04:51 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 04:54 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 246 seconds] 04:56 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev 05:02 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 05:08 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Remote host closed the connection] 05:08 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 05:10 -!- Bugz [~pi@2600-6c67-8880-0168-c71d-66c8-53c5-9584.res6.spectrum.com] has quit [Quit: WeeChat 2.3] 05:12 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Read error: Connection reset by peer] 05:20 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 05:21 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 05:24 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 05:31 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 05:44 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev 05:44 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 05:44 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 05:45 -!- laptop [~laptop@89.44.42.100] has joined #lightning-dev 05:57 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 246 seconds] 05:57 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:03 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex] 06:06 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:06 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:08 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:08 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:09 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:09 -!- rdymac [uid31665@gateway/web/irccloud.com/x-xfllsnppipgkixjz] has quit [Quit: Connection closed for inactivity] 06:09 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:10 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:10 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:11 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:11 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:13 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:13 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds] 06:13 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:21 -!- slivera_ [~slivera@103.231.88.30] has quit [Remote host closed the connection] 06:41 -!- Bugz [~pi@2600-6c67-8880-0168-c71d-66c8-53c5-9584.res6.spectrum.com] has joined #lightning-dev 06:45 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 06:45 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Remote host closed the connection] 06:52 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:52 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 06:54 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 06:54 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 07:11 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 07:12 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 07:14 -!- t-bast [~t-bast@2a01:e34:efde:97d0:f497:7a0b:e1d9:2f76] has quit [Quit: Leaving] 07:14 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 07:17 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 07:21 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Ping timeout: 264 seconds] 07:29 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 07:29 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 07:29 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex] 07:29 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 07:40 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 07:41 -!- arowser_ [~arowser1@192.69.88.248] has quit [Read error: Connection reset by peer] 07:41 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 07:51 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 08:20 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 08:40 -!- nobody123 [~nobody123@dslb-092-075-080-136.092.075.pools.vodafone-ip.de] has joined #lightning-dev 08:43 -!- rdymac [uid31665@gateway/web/irccloud.com/x-jafeaaoypfzaohfv] has joined #lightning-dev 08:47 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex] 09:08 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 09:08 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 09:19 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev 09:27 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 09:37 -!- laptop [~laptop@89.44.42.100] has quit [Ping timeout: 256 seconds] 09:41 -!- laptop [~laptop@109.175.150.72] has joined #lightning-dev 09:45 -!- laptop [~laptop@109.175.150.72] has quit [Read error: Connection reset by peer] 09:45 -!- laptop [~laptop@109.175.150.72] has joined #lightning-dev 09:46 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Remote host closed the connection] 09:49 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Ping timeout: 240 seconds] 09:52 -!- Pavlenex [~Thunderbi@194.187.251.11] has joined #lightning-dev 10:01 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 10:01 -!- arowser_ [~arowser1@192.69.88.248.16clouds.com] has joined #lightning-dev 10:13 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 10:21 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Remote host closed the connection] 10:22 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 10:32 -!- proofofkeags [~proofofke@2601:280:c280:e500:2dda:95db:aa11:9e17] has joined #lightning-dev 10:33 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds] 10:38 -!- arowser_ [~arowser1@192.69.88.248.16clouds.com] has quit [Remote host closed the connection] 10:38 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 10:38 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 11:01 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds] 11:04 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 11:13 -!- alko89 [~alko89@unaffiliated/alko89] has joined #lightning-dev 11:59 -!- Pavlenex [~Thunderbi@194.187.251.11] has quit [Quit: Pavlenex] 12:16 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.7.5 - https://znc.in] 12:18 -!- alko89 [~alko89@unaffiliated/alko89] has joined #lightning-dev 12:23 -!- Pavlenex [~Thunderbi@194.187.251.11] has joined #lightning-dev 12:33 -!- Pavlenex [~Thunderbi@194.187.251.11] has quit [Quit: Pavlenex] 12:40 -!- Pavlenex [~Thunderbi@194.187.251.11] has joined #lightning-dev 12:40 -!- Pavlenex [~Thunderbi@194.187.251.11] has quit [Client Quit] 12:46 < cdecker> Good morning everyone :-) 12:46 < cdecker> Specification meeting here in 15 minutes, agenda is here https://github.com/lightningnetwork/lightning-rfc/issues/792 12:48 -!- t-bast [~t-bast@2a01:e34:efde:97d0:f497:7a0b:e1d9:2f76] has joined #lightning-dev 12:48 < cdecker> Hey t-bast ^^ 12:51 < t-bast> Hey cdecker! 12:51 < t-bast> How is it going? 12:51 < cdecker> Quite well, how about yourself? 12:51 < t-bast> It's going well, living the remote life close to the sea :) 12:52 < cdecker> Oh, nice 12:52 < cdecker> Looks like I'm not going to be anywhere near the sea this year :-( 12:52 < cdecker> Sailing trip got corona'd 12:53 < t-bast> damn, because it was a big boat? 12:53 < t-bast> In France people are still able to rent mid-size boats and go sailing 12:53 < cdecker> Yep, 26 people on a boat, trying to keep 1.5m distance, like that's going to work xD 12:54 < t-bast> arf yeah, 26 people may be a bit too much...it's really too bad, I think 10-15 people boats are still sailing 12:54 < cdecker> We decided it's not worth the risk, the ship chartering company would have been totally ok with having us on board :-) 12:54 < t-bast> I have a friend of crossed the atlantic and it all went very fine, they didn't see any corona out there xD 12:54 < t-bast> ok, I definitely understand that, we'll have plenty of time to do such things next year(s) 12:54 < cdecker> Uh, yeah, crossing the atlantic still is on my bucket list, still saving up for it 12:55 < t-bast> I'd love to do this too, but choosing the right people to go with can be a challenge... 12:56 < cdecker> My brother was hired for 5 months last year on a traditional sailing ship and I'm envious like hell 12:56 < cdecker> Still trying to convince people it's a good team-building exercise and should be our next offsite :-) 12:56 -!- laptop [~laptop@109.175.150.72] has quit [Ping timeout: 240 seconds] 12:57 < t-bast> hell yeah it's a great team-building! 12:57 < t-bast> Was your brother able to go back to a normal life after that? The risk is that you become addicted to it :) 12:58 < cdecker> He certainly came back changed, now everything he does is to get him back on a boat xD 13:00 < t-bast> that's so cool :D 13:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:01 < ariard> hello 13:01 < bitconner> hola 👋 13:01 < t-bast> hey everyone! 13:02 < niftynei> hello! 13:02 < cdecker> Hey everyone ^^ 13:03 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 13:04 <+roasbeef> oy 13:04 < rusty> Hello all! 13:04 < cdecker> Heya roasbeef ^^ 13:05 < t-bast> good morning roasbeef and rusty 13:06 < lndbot> Hai 13:06 < t-bast> Shall we start the meeting? Does someone want to chair? 13:08 < rusty> I think that's "Yes, and no". :) 13:09 < t-bast> haha, let's go then 13:09 < t-bast> #startmeeting 13:09 < lightningbot> Meeting started Mon Aug 3 20:09:29 2020 UTC. The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:09 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:09 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/792 13:10 < t-bast> Here is the (tentative) agenda for today, don't hesitate to suggest something 13:10 < t-bast> A bunch of small PRs that shouldn't take too long and then the usual long standing issues ;) 13:10 < t-bast> #topic Harden cltv_expiry_delta recommendations 13:10 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/785 13:11 < t-bast> The discussion has made good progress on the PR, IIUC the only thing you'd like me to change is to revert the default back to 9 (instead of 18) in Bolt 11 for backwards-compat? 13:11 < cdecker> Tiny nit on changing the default: that change is redundant if we make the field mandatory, and would automatically make all existing nodes non-compliant 13:11 <+roasbeef> so default and recommened? 13:12 < cdecker> Yep, just for cleanliness' sake, make the field mandatory, but keep the old default if a node doesn't specify it 13:12 < cdecker> (mandatory but not enforced that is) 13:12 <+roasbeef> fwiw lnd always includes our value explicitly, as has for soem time I think 13:12 < t-bast> we now say that implementation MUST specify this field in invoices, so I don't really know what to do with the previous suggestion of a default of 9 13:12 <+roasbeef> isn't it backwards compat to assume a new higher default? 13:12 < rusty> Note that the 18 *is* backwards compatible, since you can always set more than they ask. 13:13 <+roasbeef> in that if they want 9, and we send 18, that should be ok assuming it's in their tolerance 13:13 < cdecker> Oh right, nevermind then ^^ 13:13 < t-bast> I agree with roasbeef, even if nodes accept 9, sending them 18 is always better, right? 13:13 <+roasbeef> but sending a lower would be a no go ofc 13:13 < rusty> roasbeef: snap. 13:13 < bitconner> it's backwards compatible on the sender-side, it's not on the receiver side 13:13 < cdecker> In that case we don't need to make it mandatory either, do we? 13:13 < bitconner> the sender can always use a higher value, the receiver must continue to accept lower values if the sender still uses 9 13:13 < t-bast> it's better to be explicit in the invoice instead of relying on a magic value in the spec IMHO 13:14 < bitconner> agreed, but i always agree with decker that we can't change the assumed default 13:14 < t-bast> exactly like bitconner says 13:14 < ariard> the policy doesn't change on the receiver side, is just a recommendation on the sender-side 13:14 < rusty> bitconner: that's why it's mandatory, for sender though, at least until some magical day... 13:14 < bitconner> rusty: yes i think that's all we can do 13:14 < t-bast> receivers will now have it specified in their invoice so they don't care 13:14 < cdecker> Hm, you're right, there is no clean solution. I'll retract my comments 13:14 < bitconner> t-bast, they have old invoices which don't 13:15 < t-bast> but these old invoices expires after 1 hour 13:15 < t-bast> so it's ok, right? 13:15 < bitconner> they might* 13:15 < bitconner> you can set longer expirations :P 13:15 < t-bast> do you use long expirations? 13:15 < cdecker> c-lightning will also set the field fwiw 13:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 13:16 < bitconner> i personally don't, but there are users that do 13:16 < t-bast> if we all already set this field, then there's probably no need to worry about backwards-compat; in that case we could completely remove the recommended default of 9 from the spec and don't recommend any default? 13:16 < rusty> cdecker: not if it's actually 9... 13:16 <+roasbeef> yeh we also recently had to tighten up our config validation to ensure a user can't set a value lower than the existing default (of 9) 13:16 < rusty> t-bast: no, if someone actually sets it to 9 we will omit it :( 13:16 < bitconner> roasbeef: our validation now requires all user-chosen CLTV values to be at least 18 13:17 < ariard> but really isn't two different things what you write inside the invoice and how do you reject HTLC when they arrive at last hop? 13:17 < t-bast> rusty: daaamn, then I'll just put back 9 in there and it should be good? 13:17 < rusty> t-bast: no, I prefer 18 :) 13:17 < t-bast> I'm lost on who prefers what now :D 13:18 < rusty> I mean, it's not critical, but 18 works too and is more sensible? 13:18 < t-bast> ariard: but this one you reject based on what's in your invoice since you're the recipient 13:18 < rusty> We do need some default value unf. 13:18 < bitconner> imo there's no need to change the assumed default, it can stay at 9 13:18 < t-bast> My preference is to put 18 for future implementers that don't have backwards-compat requirements (for example electrum and rust-lightning) 13:19 < t-bast> So that we don't have an unhealthy recommendation lingering in the spec 13:19 < t-bast> But that's nit TBH so I can settle for 9 if the majority prefers that 13:20 < bitconner> perhaps we can just note that the goal is to ultimately remove the assumed default entirely 13:20 < bitconner> (same should be done for expiry tbh) 13:20 < rusty> bitconner: yeah, we can simply note that you assume X if not specified, for backwards compat with old spec mistakes... 13:21 < t-bast> bitconner: I could do something like that: "Default is 9 if not specified (for backwards-compatibility with old nodes)" 13:21 < ariard> t-bast: but IIRC the spec doesn't require you to reject HTLC as final hop based on invoice non-compliance, it might not even has one (spontaneous payment) 13:22 < t-bast> ariard: true, but it's for your own safety that you want to check that value (but I agree that it may come from your internal configuration instead of the invoice, but having it in the invoice lets the sender know what value they should use) 13:23 < t-bast> ariard: keysend are clearly an issue in that regard: we don't know what final_expiry to use (it should be added to node_announcement in an extension tlv or something) 13:24 < bitconner> for keysends we just check that the final ctlv is greater than our go-to-chain delta 13:24 < ariard> t-bast: really I think that's 2 different parameters, minimum cltv_expiry is a safety measure to avoid someone easily double-spending the HTLC, beyond and what should be in the invoice is an application-specific one on how much block parties let them to come to resolution 13:24 < cdecker> Doesn't accepting payments with the wrong final CLTV open you up to probing for being the last hop? 13:25 < rusty> t-bast: actually, I am swayed by the idea of making 18 the default because keysend. 13:25 < ariard> like delayed HTLC 13:25 < ariard> cdecker: not an issue anymore with payment_secret ? 13:25 < cdecker> Righto 13:26 < t-bast> ariard: I don't understand, we're talking about `min_final_expiry_delta` right? Can you clarify? 13:28 < bitconner> rusty: default on invoices? there are no invoices in keysend? 13:28 < rusty> bitconner: yeah, but it's a nudge in the right direction :) 13:28 < bitconner> if it's just a sender-side default that is easy, but doesn't need to affect BOLT 11 at all 13:29 < rusty> Like, "FFS, just use 18 if you don't know what to use" matches our advice on the recipient side... 13:29 < t-bast> bitconner: I think the goal is that this way senders will use 18 for keysend - for example I believe lnd uses 13 instead of 9 today for keysend 13:29 < t-bast> rusty: YES, the goal is to say: just use a high enough values when in doubt, because it's not harmful in any way 13:30 < ariard> t-bast: right, but why if upgraded nodes just send 18 by default as sender, it's above old minimal cltv_expiry and is going to be accepted by non-upgraded? 13:30 < bitconner> why does 9 vs 13 matter? 13:30 < bitconner> fwiw lnd pads the cltvs in the path with and extra 3 blocks, so 18 -> 21 13:30 < ariard> I agree with bitconner, doesn't need to affect BOLT 11, implementations should reject invoices with values under 18 13:30 < t-bast> ariard: yes they're going to be accepted by non-upgraded since the check is `actual_ctlv_expiry > my_expiry_from_invcoie` 13:32 < cdecker> bitconner as an aside: does lnd also insist on receiving the +1 we add for the case a block is found in the meantime? I found that if I send with a final cltv of 9 (which is the current default) some nodes would reject, but not if I do the courtesy +1 13:32 < t-bast> bitconner: simply that if I try to send you a keysend with the default recommendation of 9, will you accept it? your code makes it look like you won't because you want 13 13:32 < t-bast> bitconner: but I just skimmed through it, I'm probably wrong 13:32 < ariard> cdecker: we do a courtesy +3 blocks, as block processing can be really slow on shitty devices 13:33 < t-bast> interesting, we only do a +1 courtesy on eclair, maybe we should bump that 13:33 < bitconner> cdecker: we add a few blocks in case blocks are found while the htlc is in transit, yes. but it is only done by the sender, nothing changes on the receiver side 13:33 < cdecker> That's on the sender side though ariard, correct? 13:33 < bitconner> ariard: lnd also does +3 13:33 < ariard> cdecker: yes, on the sender-side, you don't have issue on the receiver-side to be in the future? 13:34 < cdecker> Hm, still hunting for the implementation that didn't add a final cltv to its invoices and was insisting on getting a 10 instead of a 9 13:34 < bitconner> t-bast: i'm pretty sure we'll accept it with 9, but i'd have to double check on that 13:34 < rusty> I think we're in bikeshed territory. We need to specify a (deprecated) default, and 9 and 18 are the obv. Can we have a straight up vote? 13:34 < bitconner> sgtm 13:34 < rusty> (TBH I don't really care, it's not worth delaying this PR for either value!) 13:35 < rusty> 18. 13:35 * cdecker votes for 18 being the default, and making the field mandatory for future implementations 13:35 < t-bast> yes let's vote, I vote for 18 13:35 < ariard> rusty: I think people disagree on scope should 18 be both on a) mimimal_cltv_expirty and b) on invoices? 13:35 < cdecker> (i.e., keep it as the PR proposes) 13:35 < ariard> if it just minimal_cltv_expiry, I vote 18 13:35 < bitconner> i'd say 9 because bolt 11 is one of the most widely implemented parts of lightning, and there's no need to change something we're going to delete and is obsoleted by just setting an explicit value 13:36 < bitconner> (which we're already doing anyways) 13:36 < t-bast> but only the encoding/decoding part is what's implemented very widely, not this check which is really when constructing the onion and paying, right? 13:36 < rusty> bitconner: because it's widely implemented I'm not sure we're ever going to be able to remove default... but I mildly prefer a consistent "TL;DR: use 18". 13:37 <+roasbeef> well when we update, all the wallets do essentially 13:37 < ariard> bitconner: why not un-tie final_cltv_expiry verification from invoices matching at HTLC reception ? IIRC lnd does this, but post-payment_secret not an issue anymore ? 13:37 < ariard> or at least removing the cltv_expiry requirement for invoices post-payment_secret? 13:37 <+roasbeef> 18? 13:38 < bitconner> ariard: why so? certain payment might require longer timeouts, like if the payment is composed with external protocols 13:39 < rusty> (yes, I specifically have a Bwahahaha plan for using longer values!) 13:39 <+roasbeef> yeh or if it's been excessively sharded and all needs to be resolvd on-chain 13:39 < cdecker> +1 for keeping the `c` field in the invoice 13:39 < t-bast> I'm seeing only one vote for 9...? 13:39 < bitconner> just doesn't realistic to update the assumed default at the same time we are changing to say you have to set an explicit value without breaking things 13:40 <+roasbeef> bitconner: is it breaking though? ppl that accept and/or are expecting 9 should also accept 18 right? 13:40 <+roasbeef> up to the max cltv limit 13:40 < bitconner> it is breaking if the receiver starts to assume 18 while the sender is still assuming 9 13:40 <+roasbeef> mhmm, so all receivers that assume 18 should also set the value explcitily in the invoice 13:41 < rusty> bitconner: they can't do that, since spec says they *have* to set it? 13:41 < bitconner> rusty: there is still a transition period, the spec doesn't instantly update all deployments :) 13:41 < t-bast> roasbeef: exactly, it's not breaking anyone. If you're before that change, you will accept 9 when receiving. If you're after that change, you will specify a value in your invoice so even old senders will comply. You will send a higher value than necessary to old receivers. The only issue may be with your pending invoices 13:41 <+roasbeef> t-bast: yep 13:41 < ariard> bitconner: you're right that's an application-check, but overall sems to me we should remove this change to require an explicit value 13:42 < rusty> bitconner: no, old deployments will write nothing IFF it's 9. In which case, reader assuming 18 works., 13:42 < bitconner> ariard: agree 100%, it's just a matter of staggering the deployment 13:42 <+roasbeef> there may be some outlier wallets like BLW (idk how active they are anymore), but for the most part we should be able to deploy the change smoothly 13:42 < bitconner> rusty: not if you read your own invoice 13:43 < bitconner> anyway, if people want to change the spec to 18 that's fine 13:43 < t-bast> the only trick in implementation is that if you read your own invoice and it didn't specify anything, you'll want to accept 9 for a while, just until those invoices have expired 13:43 < t-bast> have expired or been paid 13:43 < rusty> bitconner: you mean create an invoice pre-upgrade, read it post upgrade and interpret it differently? I cannot think of a case where that will be a problem (at least, for c-lightning) 13:43 < bitconner> just saying it probably won't land in lnd overnight bc of the rollout 13:44 < t-bast> it takes 2 releases to do it perfectly cleanly, but that shouldn't prevent us from changing it in the spec I think 13:44 < bitconner> t-bast: doesn't that prove that it is not backwards compatible? the fact that you have to wait for them to expire? 13:45 < t-bast> bitconner: no it doesn't! 13:45 < t-bast> bitconner: because it's on the receiver side that you do that trick, the spec specifies this default for the sender side 13:45 < t-bast> bitconner: because as a receiver you now MUST set it explicitly 13:46 < bitconner> i don't see that distinction? the default is being set in the field description, which i assume applies to both parties 13:46 < t-bast> bitconner: you just allow your implementation to carry over some left-over from things created before the release, which is expected 13:46 < bitconner> i see, it is actually specified in two palces 13:46 < bitconner> places* 13:47 < bitconner> like i said, if we want to change to 18 that's fine. it is all moot if we are setting explicit values 13:47 < bitconner> idk how much more time we should spend on this tbh 13:47 < t-bast> great! so are we good to go with the current state of the PR? 13:48 < t-bast> or do we want to have another look and sign-off on github later? 13:48 < rusty> t-bast: approved! Kill me now (or at least get some more coffee...!) 13:48 < bitconner> i'll take a last look on github 13:49 < t-bast> sgtm 13:49 < t-bast> #action bitconner and t-bast to finalize on github 13:49 < t-bast> #topic ChaCha20 RFC correction 13:49 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/763 13:50 < t-bast> So the RFC we've been linking to for ChaCha20-Poly1305 is obsoleted by another one 13:50 < cdecker> lgtm 13:50 < t-bast> There are a few erratas as well 13:50 < rusty> Ack. 13:50 < cdecker> Couldn't find anything that'd impact us 13:50 < t-bast> There's no change in any implementation in the new RFC, so what we're doing today should comply with the new one 13:52 <+roasbeef> yeh prob just best to link to the latest stuff, tho i don't see chacha really changing much at this point given msot ppl have pretty standarized libs 13:53 < t-bast> agreed, it just feels better, we won't have people twitting that LN is using insecure, obsolete crypto xD 13:53 < t-bast> shall we apply? 13:53 < rusty> (They added a third round, it's now ChaChaCha... turns out ChaCha was no more secure than single-cha!) 13:54 < rusty> t-bast: yes. 13:54 < t-bast> roasbeef/bitconner? 13:54 <+roasbeef> oui 13:54 < bitconner> approved 13:55 < t-bast> nice! 13:55 < t-bast> #action merge PR 13:55 < t-bast> #topic Uppercase invoices 13:55 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/677 13:55 < cdecker> ack 13:56 < t-bast> this PR simply makes it explicit that uppercase invoices are ok, since it's more efficient to use in QR codes and wallet usually do that 13:57 < rusty> Yes, more test vectors good. And they pass, so.... 13:57 < t-bast> I believe everyone already does that 13:57 <+roasbeef> hmm yeh dunno we don't have QR code in lnd, but I _think_ wallets on lnd do use upper case? 13:58 <+roasbeef> we also had a PR to lnd to "fix" what we had as a max invoice size given what can be actually encoded in QR code 13:58 < bitconner> why is calling toLowerCase before calling bolt11.decode insufficient/ 13:58 < bitconner> ? 13:58 < bitconner> doesn't seem strictly necessary to have this in the spec but either way works for me :) 13:58 < rusty> bitconner: technically you don't have to handle mixed case? The orig bech32 code enforces only one case at decode time. 13:59 < cdecker> bitconner that's an implementation detail, but you should accept upper case ones 13:59 < rusty> bitconner: yeah, the modified test vector is more important IMHO. 13:59 < bitconner> sgtm 14:00 < t-bast> allright, let's apply! 14:00 < rusty> Yeah, ack from me. 14:00 < bitconner> ACK 14:00 < t-bast> #action Merge #677 14:01 < t-bast> #topic Anchor outputs (landing soon!) 14:01 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/688 14:01 < t-bast> I think we cleared that last outstanding question on anchor outputs regarding closing fees 14:01 < rusty> I've been slack on testing... we also need closure on.... um.. closing? 14:01 < t-bast> johanth are you satisfied with rusty's answer? 14:02 < t-bast> I've been able to test all normal operations and force-close scenario with lnd last week 14:03 < lndbot> Yeah, that makes it clear 14:03 < t-bast> rusty: damn, there's a conflict in #677, could you fix it and re-push? 14:03 < rusty> t-bast: do you have a node I can test against? 14:03 < rusty> t-bast: will fix... 14:04 < rusty> (BTW, 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605 my node is running --experimental-features, so has anchor output support) 14:04 < t-bast> rusty: I can get probably it deployed on our testnet node next week 14:04 < t-bast> rusty: otherwise eclair at that commit has full support: https://github.com/ACINQ/eclair/pull/1501 14:04 < rusty> t-bast: OK, but anyway if you two have interop I'm happy to ack this! 14:04 < t-bast> rusty: but you may not want the JVM near your machines xD 14:05 -!- cfields [~cfields@unaffiliated/cfields] has joined #lightning-dev 14:05 < t-bast> We still have the closing fee to fix, it's the only remaining thing that still doesn't match between eclair and lnd 14:05 < lndbot> Will need to update the feature bit and the coop close fee computation, otherwise it think we are there :) 14:05 < t-bast> johanth do you think you can have something ready soon with that fixed? Once you do I can do interop testing 14:05 < lndbot> Yeah, can have it tmrw probably 14:06 < t-bast> oh great, we'll be able to finalize this quickly, let me know over slack when you have a branch I can use! 14:06 < lndbot> :+1: 14:06 < t-bast> #action johanth and t-bast to finalize interop tests this week 14:07 < t-bast> Do you want to discuss one last topic? Or shall we call it a day? 14:07 -!- slivera [~slivera@103.231.88.10] has joined #lightning-dev 14:08 < bitconner> i have some time 14:08 < bitconner> know it's late for europe folks tho :) 14:08 < ariard> rusty: If you do have a bit of time to laying out your ideas on better RBF/package relay there : https://github.com/bitcoin/bitcoin/issues/14895, that's welcome :) 14:08 < rusty> (Aside #1/2: I found someone to hack on ln.dev, first I'd like to create a spec features vs major releases matrix for my own reference, so features.ln.dev or something...) 14:08 < t-bast> What topic do you want to chat about? 14:08 < ariard> sipa was describing an idea of yours to stagger cheap replacements 14:09 < t-bast> oh yeah doing a bit of package relay is a great idea, let's bridge layers 14:09 < rusty> (Aside #2/2: I am supposed to be giving a live thing on lnprototest in ~24 hours) 14:09 < t-bast> rusty: nice! tweet the link, we'll watch ;) 14:11 < ariard> t-bast: I think we agree on a "few core assumptions that need to remain "loosely true" 14:11 < ariard> like stable policy rules, and being sure they're not changed under our feets 14:12 < t-bast> Yeah, I figured that's what we were both thinking. What do you think of my suggestion of only allowing much smaller packages in mempool? 14:13 < t-bast> I can't see the usecase for allowing very long chains of unconfirmed txs in the mempool, I believe that complexity could shift to clients instead of having nodes take that burden 14:13 < t-bast> But I'm likely missing use-cases 14:13 < rusty> t-bast: ah, we included an upper-case test-vector in another cleanup. So removing from PR. 14:14 < t-bast> rusty: got it, that's why I already had a slightly different uppercase test vector in my test suite! 14:14 < ariard> t-bast: I'm more worried with absolute-fee-but-lower-feerate obstrucating package rather than irreplaceable packages due to limits 14:15 < ariard> and I verify bip 125 rule 5 recently, you will hit first ancestor/descendants limits before to reach 100 descendants case 14:16 < ariard> unless an intentional reorg, where these limits aren't applied 14:16 < t-bast> ariard: I think we need to fix both, but I was under the impression that people felt the absolute-fee-lower-feerate rule would not be too hard to lift, that's why I wanted to mention the other painful rule 14:17 < rusty> t-bast: #677 rebased. 14:17 < t-bast> rusty: great, even more no-brainer to apply, I'll do it right now 14:20 < t-bast> ariard: what scenario uses big unconfirmed packages? 14:20 <+roasbeef> t-bast: potentially ctv type stuff, or anything that uses large transaction trees as part of the protocol, like duplex potentially 14:20 < t-bast> ariard: though big is vague, I only mean in number of distinct txs 14:20 < ariard> t-bast: iterative batching where you reuse a change output to bump new spends but I think no exchange does it 14:20 <+roasbeef> or if ppl start using new crazy commitment schemes after some form of dynamic ocmimtment stuff is rolled out 14:20 < t-bast> roasbeef: but does CTV require these long chains to all be in the mempool? 14:20 <+roasbeef> also not sure what bitmex's withdrawl transaction looks like 14:21 <+roasbeef> t-bast: depends.... 14:21 < t-bast> roasbeef: I was under the impression that the client could get these txs locally and then broadcast batches by batches as some confirm 14:21 < ariard> yeah it's really depends how people design this-not-yet existent things 14:21 < ariard> but you may use the anchor trick of 1 CSV to avoid issue 14:22 < t-bast> airard: this could potentially be long but it will likely only use a few txs, it doesn't need a chain of 100 of them right> 14:22 < ariard> t-bast: wrt to absolute-fee lifting I think it would work, but not the RBF-pinning resolution as proposed by Suhas I think 14:23 < t-bast> you mean the explicit flag he suggests wouldn't work? https://github.com/bitcoin/bitcoin/issues/14895#issuecomment-665969902 14:24 < ariard> t-bast: you can still obstrucate at the commitment-level, like using old commitment with lower-feerate higher absolute-fee 14:24 < t-bast> this proposal requires us to go in the direction of pre-signing both sides of the HTLC outputs (claiming from the remote commitment will need to be done from a pre-signed tx) 14:24 < ariard> so lifting the rules need to apply on oldest ancestor too, not only children 14:25 < ariard> t-bast: no? even a malleable HTLC if low-feerate with such rules would be rejected 14:26 < t-bast> you mean it wouldn't work either way (even if we pre-signed)? 14:27 < t-bast> I didn't realize I forgot to end the meeting, looks like we're the only ones discussing this so let's stop recording 14:27 < t-bast> #endmeeting 14:27 < lightningbot> Meeting ended Mon Aug 3 21:27:29 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 14:27 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-08-03-20.09.html 14:27 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-08-03-20.09.txt 14:27 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-08-03-20.09.log.html 14:27 < t-bast> Thanks everyone for your time, stay safe and see you next time! 14:28 < ariard> t-bast: I think you don't need to pre-sign them, if this rules work as expected, even with malleability an attacker can't obstrucate with an absolute-fee-but-low-feerate 14:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 14:30 < t-bast> ariard: that would be great, it would be nice to avoid going in the direction of pre-signing more txs 14:31 < t-bast> I need to drop off too, I'll monitor the discussion on this issue closely! 14:31 -!- t-bast [~t-bast@2a01:e34:efde:97d0:f497:7a0b:e1d9:2f76] has quit [Quit: Leaving] 14:53 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev 15:02 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 15:03 -!- proofofkeags [~proofofke@2601:280:c280:e500:2dda:95db:aa11:9e17] has quit [Remote host closed the connection] 15:11 -!- proofofkeags [~proofofke@2601:280:c280:e500:2dda:95db:aa11:9e17] has joined #lightning-dev 15:25 -!- Pavlenex [~Thunderbi@194.187.251.11] has joined #lightning-dev 15:27 -!- Pavlenex [~Thunderbi@194.187.251.11] has quit [Client Quit] 15:31 -!- proofofkeags [~proofofke@2601:280:c280:e500:2dda:95db:aa11:9e17] has quit [Remote host closed the connection] 15:50 -!- proofofkeags [~proofofke@2601:280:c280:e500:c9e7:9321:1031:749d] has joined #lightning-dev 15:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 15:55 -!- proofofkeags [~proofofke@2601:280:c280:e500:c9e7:9321:1031:749d] has quit [Ping timeout: 260 seconds] 15:55 -!- marcoagner [~user@2001:8a0:6a45:1900:2fd7:e0f0:d356:dd70] has quit [Ping timeout: 260 seconds] 15:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 15:58 -!- vasild_ is now known as vasild 16:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds] 16:27 -!- proofofkeags [~proofofke@2601:280:c280:e500:c9e7:9321:1031:749d] has joined #lightning-dev 16:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 16:33 -!- proofofkeags [~proofofke@2601:280:c280:e500:c9e7:9321:1031:749d] has quit [Ping timeout: 260 seconds] 16:42 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 16:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 17:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:12 -!- fearbeag [~sseanicid@142.114.183.92] has joined #lightning-dev 17:14 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 17:19 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 264 seconds] 17:27 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 17:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 17:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 17:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 17:51 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 17:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 18:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 18:02 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 264 seconds] 18:02 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 18:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 18:32 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 246 seconds] 18:34 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 18:42 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 18:42 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 18:45 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 18:45 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 18:48 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 18:48 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 18:48 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 264 seconds] 18:49 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev 18:51 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 18:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 18:53 -!- fearbeag [~sseanicid@142.114.183.92] has quit [Quit: Leaving] 19:03 -!- rdymac [uid31665@gateway/web/irccloud.com/x-jafeaaoypfzaohfv] has quit [Quit: Connection closed for inactivity] 19:04 -!- arowser_ [~arowser1@192.69.88.248] has quit [Remote host closed the connection] 19:04 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 19:05 -!- frogar [~frogar_@172.105.92.83] has quit [Remote host closed the connection] 19:12 -!- arowser_ [~arowser1@192.69.88.248] has quit [Ping timeout: 240 seconds] 19:19 -!- arowser_ [~arowser1@192.69.88.248] has joined #lightning-dev 19:28 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 19:30 -!- frogar [~frogar_@172.105.92.83] has joined #lightning-dev 19:32 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 246 seconds] 19:46 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection] 19:58 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Remote host closed the connection] 19:58 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 20:03 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Ping timeout: 240 seconds] 20:04 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 20:08 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds] 21:02 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 21:13 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Remote host closed the connection] 21:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 21:33 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 256 seconds] 21:34 -!- yzernik [~yzernik@2600:1700:dc40:3dd0:2537:722e:487a:68a] has joined #lightning-dev 21:44 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has joined #lightning-dev 21:45 -!- vtnerd [~vtnerd@173-17-206-92.client.mchsi.com] has quit [Ping timeout: 240 seconds] 21:46 -!- vtnerd [~vtnerd@173-17-206-92.client.mchsi.com] has joined #lightning-dev 21:51 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev 21:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 22:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 22:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds] 22:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 22:44 -!- proofofkeags [~proofofke@174-29-8-246.hlrn.qwest.net] has quit [Remote host closed the connection] 22:47 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 22:47 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 22:48 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #lightning-dev 22:51 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds] 22:52 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 22:57 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds] 23:31 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev 23:31 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 23:31 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 23:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 23:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev --- Log closed Tue Aug 04 00:00:40 2020