--- Log opened Mon Nov 09 00:00:11 2020
00:20 -!- per [~per@gateway/tor-sasl/wsm] has quit [Ping timeout: 240 seconds]
00:21 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:21 -!- per [~per@gateway/tor-sasl/wsm] has joined #lightning-dev
00:22 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
00:46 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
00:46 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
00:59 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
01:21 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
01:39 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
01:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
01:41 -!- vadorovsky__ [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
01:41 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
01:42 -!- laptop [~laptop@ppp-3-36.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
01:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
02:00 -!- vadorovsky__ [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
02:02 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
02:05 -!- reallll is now known as belcher
02:08 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds]
02:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
02:22 -!- musdom [~Thunderbi@2001:f40:904:b2ca:c039:3335:5a2b:229e] has joined #lightning-dev
02:23 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
02:26 -!- musdom [~Thunderbi@2001:f40:904:b2ca:c039:3335:5a2b:229e] has quit [Client Quit]
02:42 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
02:42 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
02:46 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
03:01 -!- vadorovsky__ [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
03:12 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
03:27 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
03:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
03:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Read error: Connection reset by peer]
03:30 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Write error: Broken pipe]
03:30 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Write error: Connection reset by peer]
03:30 -!- per [~per@gateway/tor-sasl/wsm] has quit [Write error: Connection reset by peer]
03:30 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Write error: Connection reset by peer]
03:30 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
03:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
03:31 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
03:33 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
03:40 -!- per [~per@gateway/tor-sasl/wsm] has joined #lightning-dev
03:59 -!- per [~per@gateway/tor-sasl/wsm] has quit [Ping timeout: 240 seconds]
04:05 -!- per [~per@gateway/tor-sasl/wsm] has joined #lightning-dev
04:09 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
04:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
04:16 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
04:27 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
04:28 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
04:44 -!- doubleqp [~doubleqp@2001:ac8:20:308::a16e] has joined #lightning-dev
05:02 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
05:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Remote host closed the connection]
05:14 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev
05:15 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
05:19 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
05:25 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
05:30 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Remote host closed the connection]
05:31 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev
05:39 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
05:42 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
05:42 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has joined #lightning-dev
06:06 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
06:07 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has quit [Remote host closed the connection]
06:07 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 256 seconds]
06:08 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
06:08 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has joined #lightning-dev
06:09 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
06:09 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
06:12 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has quit [Ping timeout: 258 seconds]
06:18 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
06:19 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
06:21 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
06:23 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
06:23 -!- doubleqp [~doubleqp@2001:ac8:20:308::a16e] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
06:36 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds]
06:47 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has joined #lightning-dev
06:50 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
06:51 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
06:51 -!- doubleqp [~doubleqp@193.27.14.133] has joined #lightning-dev
07:00 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
07:13 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has quit [Remote host closed the connection]
07:13 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has joined #lightning-dev
07:18 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has quit [Ping timeout: 256 seconds]
07:22 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
07:25 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
07:25 -!- doubleqp [~doubleqp@193.27.14.133] has quit [Quit: Textual IRC Client: www.textualapp.com]
07:28 -!- jonatack [~jon@82.102.27.195] has quit [Quit: jonatack]
07:29 -!- nobody123 [~nobody123@ipservice-092-217-103-159.092.217.pools.vodafone-ip.de] has joined #lightning-dev
07:32 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has quit [Ping timeout: 265 seconds]
07:33 -!- jonatack [~jon@88.124.242.136] has joined #lightning-dev
07:37 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]
07:39 -!- jonatack [~jon@213.152.162.5] has joined #lightning-dev
07:41 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds]
07:41 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has joined #lightning-dev
07:44 -!- da39a3ee5e6b4b0d [~textual@cm-171-98-71-231.revip7.asianet.co.th] has joined #lightning-dev
07:45 -!- da39a3ee5e6b4b0d [~textual@cm-171-98-71-231.revip7.asianet.co.th] has quit [Client Quit]
07:47 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
07:48 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
07:51 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
08:23 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
08:24 -!- mol_ [~mol@unaffiliated/molly] has quit [Remote host closed the connection]
08:24 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
08:27 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
08:34 -!- berndj [~berndj@ns1.linksynergy.co.za] has quit [Ping timeout: 240 seconds]
08:38 < ThomasV> !seen t-bast
08:38 < gribble> t-bast was last seen in #lightning-dev 1 week, 6 days, 20 hours, 13 minutes, and 16 seconds ago: <t-bast> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
08:41 -!- berndj [~berndj@ns2.linksynergy.co.za] has joined #lightning-dev
08:48 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
08:49 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #lightning-dev
08:50 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Client Quit]
08:50 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #lightning-dev
08:53 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
08:55 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
09:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
09:00 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
09:01 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
09:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
09:21 -!- kexkey [~kexkey@static-198-54-132-89.cust.tzulo.com] has joined #lightning-dev
09:51 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 265 seconds]
09:52 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
10:07 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
10:07 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
10:29 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
10:47 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
10:48 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
10:50 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
10:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
10:51 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 256 seconds]
10:52 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
10:54 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev
10:59 < niftynei> hi hi
10:59 < ariard> hi
10:59 < rusty> Hello!
10:59 < t-bast> hey!
11:01 < lndbot> <johanth> yo
11:01 < rusty> t-bast: BTW, I realized this week a critical detail with blinded paths.  You must never respond if someone uses an unexpected one:  including either not using one where you expected one, or using one where you didn't.  Otherwise they can probe.
11:02 < niftynei> agenda today is at https://github.com/lightningnetwork/lightning-rfc/issues/813 (h/t t-bast for putting it up)
11:02 < rusty> t-bast: I'm pretty sure that the it's as simple as checking the blinding factor is 1. present or not present, and 2. exactly matches what you expect.
11:03 < t-bast> rusty: I need to dive back into that, I must admit I don't remember the details well enough :D
11:03 < niftynei> should we go ahead and get started? i'm happy to chair if no one else wants the throne
11:03 < rusty> t-bast: yeah, it's a side-effect of my offers work that I had to re-understand it :)
11:03 < t-bast> rusty: I plan to do another pass on it soon, I'll note that
11:03 < t-bast> niftynei to the chair!
11:03 < rusty> Captain on deck!
11:04 < t-bast> ariard mentioned on the issue that it would be good to start with the action items from the previous meeting, and see if some stuff is still pending
11:04 < t-bast> https://github.com/lightningnetwork/lightning-rfc/issues/805 has some unchecked action items
11:04 < niftynei> great.
11:04 < niftynei> #startmeeting
11:04 < niftynei> ... awkward
11:04 < t-bast> looks like he bot still isn't fixed...
11:04 < ariard> yeah I updated #803, notably mentioning you should claim HTLC outputs also with a split-off penalty after a while
11:04 < rusty> I will fix, one sec.
11:05 < t-bast> it's not you niftynei :)
11:05 -!- mode/#lightning-dev [+o rusty] by ChanServ
11:05 < niftynei> hahaha
11:05 -!- mode/#lightning-dev [+v lightningbot] by rusty
11:05 < niftynei> #startmeeting
11:05 <@rusty> niftynei: I think it's already started, try endmeeting?
11:05 < t-bast> ok maybe it's you after all :D
11:05 < niftynei> #endmeeting
11:05 < niftynei> doesn't the ... starter have to end the meeting?
11:05 < niftynei> unclear.
11:06 < niftynei> ok let's get started anyway. if meetingbot shows up, we'll loop them in
11:06 < niftynei> #topic action items from last meeting
11:06 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/issues/805
11:07 <@rusty> #startmeeting
11:07 < niftynei> the first item was rusty to try out #801, https://github.com/lightningnetwork/lightning-rfc/pull/801
11:07 < niftynei> and report success/failure. do you have an update for us rusty?
11:08 <@rusty> niftynei: yes, he revised and I've acked.  Basically, the `tlvs` keyword is now `tlv_stream` which is clearer.
11:09 < t-bast> ACK, I think we can merge that one
11:09 < niftynei> cool. 
11:09 < niftynei> #action merge #801
11:09 < niftynei> moving on. 
11:09 < niftynei> ariad was to address nits in #803
11:09 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/803
11:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
11:10 < lnd-bot> [lightning-rfc] niftynei pushed 3 commits to master: https://github.com/lightningnetwork/lightning-rfc/compare/5afe7028f4eb...5a86adaa7780
11:10 < lnd-bot> lightning-rfc/master 7218822 Corné Plooy: BOLT 4: link to BOLT 1 for tlv_payload format
11:10 < lnd-bot> lightning-rfc/master 13520a0 Corné Plooy: tlvs -> tlv_stream subsitution everywhere
11:10 < lnd-bot> lightning-rfc/master 5a86ada Corné Plooy: tlvs -> tlv_stream in extract-formats.py
11:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
11:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
11:10 < lnd-bot> [lightning-rfc] niftynei merged pull request #801: BOLT 4: link to BOLT 1 for tlv_payload format (master...bolt04_tlv_explanation) https://github.com/lightningnetwork/lightning-rfc/pull/801
11:10 < ariard> rusty: main change is updated with your point on HTLC outputs, even I don't think an attacker can steal them because 2nd-level transactions outputs are also revoked, it's still a kind of DoS
11:10 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
11:11 < niftynei> wow that's noisy. i'll wait to the end to merge anything else then
11:12 < t-bast> #803 looks good to me
11:13 <@rusty> ariard: yes, it was always a bit underspecified.  If you had say 10 HTLC outputs, and tried to use a single penalty tx, your peer could invalidate the tx by using an HTLC tx, repeat 10 times.  But the pinning attack makes it clear sometimes you *have* to do a single tx if it's taking too long, yes.
11:13 <@rusty> Yes, ack #803
11:15 < niftynei> that's two acks on #803
11:15 < ariard> well you can still claim _HTLC_ outputs with one big penalty no matter what is doing your cheating counterparty, because worst-case you claim on 2nd-stage
11:16 < t-bast> johanth had started reviewing it, what are your thought on the latest version?
11:16 < ariard> but if your counterparty maintain the pinning on those HTLC outputs for a while (like 2 weeks mempool default expiration), that's still a timevalue DoS
11:17 < lndbot> <johanth> I can look trhough the latest
11:17 < niftynei> that sounds like an action item to me.
11:17 < lndbot> <johanth> I did start implementing this in lnd, and did not find anything in particular that is not mentioned in the 803, so looks pretty good
11:18 < lndbot> <johanth> Yeah, will def look at the latest and give it an ACK (probably)
11:18 < niftynei> #action #803 ok to merge, pending ACK from johanth
11:18 -!- Guest81 [3344c770@gateway/web/cgi-irc/kiwiirc.com/ip.51.68.199.112] has joined #lightning-dev
11:18 < niftynei> we've got two more items from last meeting
11:19 < niftynei> "make the forumlation more explicit" on #808
11:19 < niftynei> it's got two ACKs since last meeting, but is failing the TravisCI checks
11:20 < t-bast> good catch, I think we need to get it to pass the CI and we should be good to go ariard
11:20 < ariard> ah I mispelling fixing
11:20 < niftynei> if there's no objection, i'd move to have this merged once CI is happy
11:20 < t-bast> niftynei: ack
11:20 < niftynei> #action merge #808 once CI is green
11:21 < niftynei> ok last item.
11:21 <@rusty> niftynei: ack
11:21 < niftynei> add contact details for implementations and details not to report, #772
11:22 < niftynei> ACINQ has posted their GPG pubkey and contact info in an issue comment
11:22 < ariard> Yes I've not done this yet, on my todo, just want to take time write something clear
11:22 < ariard> sorry for delay
11:23 < niftynei> we're missing contact details for clightning, LND, rust lightning...
11:23 < niftynei> anyone else i'm missing?
11:23 < ariard> well for RL, we don't a security disclosure policy _yet_
11:23 < t-bast> is there someone from electrum?
11:23 < ariard> other contact details have been broadcast during last meeting
11:23 < niftynei> ariard, are you missing contact details from anyone?
11:23 <+roasbeef> what PR is up rn? still 83?
11:23 <+roasbeef> is the bot working again? 
11:24 < t-bast> anyway they should be watching the repo and should react to that and post their details
11:24 < niftynei> no the bot is not working.
11:24 < ariard> ThomasV: ^
11:24 < niftynei> we're going through the action items from #805
11:24 < ariard> niftynei: electrum at least
11:25 <+roasbeef> heh, dangling bot, is TheRealTBast to blame? :p 
11:26 < niftynei> it sounds like the action left on this is electrum's contact info
11:26 <+roasbeef> posted the lnd gpg key to the rpeo 
11:26 <+roasbeef> as a comment
11:26 < t-bast> don't know who that guy is :)
11:26 <+roasbeef> hehe
11:26 <+roasbeef> re this we can also start to possilby use the "security" feature/page that github has on each repo now 
11:27 <+roasbeef> we're planning on using it for lnd once we launch our bug bounty program later this year 
11:27 <+roasbeef> also this PR is still makred WIP right? could prob use a bit more body than a few bullet points 
11:27 < t-bast> roasbeef: good idea, it would be nice to integrate with github's security policy stuff
11:28 < ariard> what does this GH security policy consist of ?
11:28 <+roasbeef> yeh, it has a place for a policy, then you can launch advisories that'll notify ppl 
11:28 < niftynei> roasbeef: correct, this is just addressing the action item, which was for collecting contact info
11:28 <+roasbeef> sec lemmie fish the docs 
11:28 <+roasbeef> https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository
11:28 <+roasbeef> will post in the PR as well 
11:29 < niftynei> great. i think we're a bit off topic. if the only contact details ariad is missing are electrum, that seems like the next action item
11:29 <+roasbeef> actually maybe this one is better https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/about-github-security-advisories 
11:30 < ariard> okay I'll have a look on it and integrate it
11:30 < niftynei> #action electrum to provide their security contact info
11:30 < niftynei> #action ariard to investigate github security feature/page
11:31 < niftynei> ok that wraps up "action items from last meeting"
11:31 <@rusty> brb
11:31 < niftynei> next up is the first item on this week's agenda
11:31 < niftynei> #topic Clarify relative order of messages after reestablish
11:31 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/810
11:32 <+roasbeef> yeh so we encountered this a few months ago when we were playing whack-a-mole with force close retranmission bugs in lnd 
11:32 < t-bast> The under-specified section was what happened in case both a rev and a sig where due after a restart
11:32 <+roasbeef> afaict it seems to plug the hole in the example crypt-iq made in the OG issue 
11:33 <+roasbeef> just made a comment re if we need to care about "backwards compat" or not, thinking no since the old way was just underspecified, and everyone prob had some arbitrary ordering they chose 
11:33 < niftynei> nice. yeah
11:33 < t-bast> I believe all other cases were already correctly covered by the spec, I'm hoping with that change we should all agree on future channel_reestablish behavior!
11:33 < niftynei> iirc c-lightning has already implemented this update/does this (sends in same order as original transmission)
11:33 <+roasbeef> on our end, to impl this properly, we'll need to persist a bit more data than we do already 
11:33 <+roasbeef> dunno if y'all noticed, but maybe 2 weeks ro so ago, there was a buncha gossip spam, which ended up creating connection instability (write/read timeouts in sockets) and seemed to trigger this for quite a few ppl 
11:34 < t-bast> re backwards-compat, I'm also leaning towards no, it usually lead to channel closure so at least we're closing that gap now
11:34 <+roasbeef> we identified what was causing it, and will have some more clamps in 0.12 
11:34 <@rusty> Yes, this is my fault for not updating the spec when I finally nailed this in c-lightning...
11:35 <+roasbeef> we also created a cross impl testing harness for stuff like this as well 
11:35 <+roasbeef> it was how we found the CL retranmission of htlcs in non incrementing order 
11:36 <+roasbeef> and by "cross impl harness" I mean some docker containers that get randomly killed during cross-fire lol
11:36 < t-bast> nice. it's a good idea
11:37 <+roasbeef> I think we're planning on publishing it as well, crypt-iq doesn't seem to be here rn tho, will follow up w/ him on that 
11:37 < niftynei> right. ok so concerning this PR, it seems like the outstanding question is backwards compatibility
11:38 < ariard> okay #810 is good for RL, we're already doing this
11:38 < t-bast> I don't think backwards-compatibility is needed, maybe at the implementation-level it makes sense to think about it but probably not at the spec level IMHO
11:39 <@rusty> Agreed.
11:39 <+roasbeef> for us whenever we've fixed issues in this area, we've just rolled out only the new more correct logic, we've seen that it can create some force clsoes when ppl go to bupdate, but better to fix things going forward and also incentivize ppl to upgrade to the latest and greatest 
11:40 < t-bast> agreed
11:40 < niftynei> ok so i think we just need one more PR ACK, then it should be good to merge
11:40 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:29fe:c4d1:ebb5:612a] has joined #lightning-dev
11:41 < niftynei> #action merge #810, pending second ACK
11:41 < niftynei> if there's nothing else on this PR, we can move on to the Issues section
11:41 < t-bast> SGTM
11:42 < niftynei> #topic field report on the high on-chain fee week
11:42 < niftynei> there's no link for this topic
11:42 < niftynei> t-bast did you want to kick off the discussion?
11:42 < t-bast> Regarding the past week, very high on-chain fees and full mempool, we've seen interesting impact on LN channels
11:43 < t-bast> The most important impact was that our node updated channel to match on-chain feerate
11:43 <+roasbeef> t-bast: what conf target do y'all use? also this is no anchors i'm geussing right?
11:43 < t-bast> With such a high feerate, every channel that was less than 150k sat was basically unusable
11:43 < t-bast> Because all the capacity was dedicated to potentially paying the commit tx fee
11:43 < niftynei> oh that is interesting
11:44 < t-bast> The conclusion is two-fold: anchor outputs will be great, if we can agree on a small feerate that's enough to guarantee relay
11:44 < ariard> t-bast: can't you relax the confirmation target when your channel become unusable?
11:45 < t-bast> ariard: yes we could, but if your remote doesn't do it at the same time and cares about the difference in estimated feerate, channels will close
11:45 < t-bast> and we don't want channels force-closing during these high on-chain fee periods...
11:45 <+roasbeef> do we need to *agree* on the fee rate tho? 
11:45 < niftynei> kind of moves the target on the 'feerate' pot to a 'global feerate fund' though, no? in other words, the size of your CPFP account will need to scale with the feerate changes?
11:45 < ariard> t-bast: depend of the update_fee bounds of your counterparty, if it's pretty liberal with lower bound
11:45 <+roasbeef> in 0.12 for lnd (next release) we plan on enabeling anchor by default (with some added fee leak mitigations) and clamping things on teh sender side 
11:45 < t-bast> That's why I think this previous action item is important: "Evaluate historical min_relay_fee to improve update_fee in anchors (@rustyrussell and @TheBlueMatt)"
11:46 < t-bast> even with anchor outputs, if you let your remote raise the feerate, there is ariard's attack that becomes possible
11:46 < niftynei> we'd need to agree on a feerate if we remove the update_feerate, which is what i think t-bast is getting at
11:46 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:29fe:c4d1:ebb5:612a] has quit []
11:46 < t-bast> so you currently still need to bound the feerate you accept from your remote, but how? Still undecided...
11:46 <+roasbeef> t-bast: so we need a ceiling instead? i think we just chose one on our end, but yeah ideally we can communicate this somehow with our feature bits or w/e 
11:47 < t-bast> I think you need both, if the feerate is lowered too much and the tx can't be relayed, you're very screwed too
11:47 <+roasbeef> yep, so something low, but not tooo low
11:47 < ariard> if you bound the feerate announced by your remote that's okay but still this bound might be honest in period of high-fee
11:47 < niftynei> anecdotally, we had a user who's channel closed because the peer's suggested feerate was below the floor on what c-lightning deemed reasonable
11:47 <+roasbeef> iirc stuff below 1.3 sat/byte was evicted w/ the mempool fee gradient of last week?
11:47 < ariard> other said how do you dissociate between a honest high-fee update_fee and a malicious one
11:48 <+roasbeef> ariard: what do you mean by "might be honest"? 
11:48 < lndbot> <johanth> I was just gonna cap it at 20 sat/b for anchor channels for now, as the initiator
11:48 < ariard> roasbeef: I can announce you a high-feerate `update_fee` during mempool-congestion, your node will accept it because it's matching your view of the mempool ?
11:48 < niftynei> roasbeef, what do you  mean by "clamping things on the sender side"
11:49  * rusty hides in case anyone asks him about progress on historical analysis of mempools... BlueMatt?
11:49 < t-bast> johanth: you meant fix it there? And potentially raise it if that becomes unrelayable? I was thinking of something like that too, but not too sure and the fundee behavior
11:49 <+roasbeef> niftynei: so the sender picks a ceiling for how high a fee rate it'll propose 
11:49 <+roasbeef> to like cooperate and clamp down on fee leak, but also do not let the fee estimator commit like 80% of the channel to feees 
11:49 < ariard> rusty: lol we're playing the ball on this with Matt, no progress from our-side...
11:49 < t-bast> rusty: xD. TBH I think we'll start implementing something like this anyway, at least when we're funders...
11:50 <+roasbeef> t-bast: I think what we realy need here is a clear model of how the low water mark eviction in the bitcoind mempool works 
11:50 < niftynei> mmm. iiuc that's gonna cause problems if c-lightning's still using its min fee estimator (and the min goes above the sender's ceiling)
11:50 <+roasbeef> with that we could then compute a worst case scenario, like entire mempool is 500 sat/byte or something, what ends up being not accepted/evicted? 
11:50 < lndbot> <johanth> t-bast: yeah, as the initiator I won’t send update_fee above 20 sat/b (should be enough for relay, also it is configurable)
11:50 < lndbot> <johanth> as a receiver I will accept the same way as for other channel types
11:51 < niftynei> maybe i'm missing something about the 'sender' role? we haven't updated our min-feerate floor logic for anchor output channels
11:51 < ariard> roasbeef: it's the lower package feerate you need to consider, if your whole mempool is 500sat/byte, your package under this mark will be evicted
11:51 < t-bast> I think a potential behavior behavior could be: funder uses 3 * min_relay_fee from his mempool (or another small factor) / fundee accepts whatever still passes the relay bar on his own mempool and isn't too high (implementation-dependent, configurable)
11:52 < t-bast> very handwavy but would probably work okay-ish in practice *as long as other implementations also do something like this*
11:52 < t-bast> this is why I think we need to agree on a rough behavior
11:52 < t-bast> to avoid all channels closing when the mempool becomes full like last week :)
11:53 < lndbot> <johanth> PRFT(tm)
11:53 < lndbot> <johanth> package relay fixes this :slightly_smiling_face:
11:53 <+roasbeef> t-bast: heh I 'member back in the day when a crazy mempool would cause co-op close negotiations to fail between CL+lnd 
11:54 <@rusty> t-bast: how do we tell what min relay fee is: does the 'relayfee' var from bitcoin-cli getnetworkinfo change?
11:54 <+roasbeef> a co-op close revemp is also needed imo, but a discussion for another time... (like how do y'all handle the other party just not budging and refusing to satisfice?) 
11:54 <+roasbeef> rusty: iirc there's a getmempoolinfo call? 
11:54 < ariard> johanth: I want to try pinning scenarios in the wild, before to go forward with package relay
11:54 < ariard> if someone wants to play the victim :)
11:55 <@rusty> roasbeef: ah, thanks!
11:55 < lndbot> <johanth> to me it sounds impossible to agree on a “perfect” relay fee (for now), which is why I think we should clamp around 10-20 range
11:55 < t-bast> I was planning on trying out getmempoolinfo's `minrelaytxfee` and `mempoolminfee`
11:55 <+roasbeef> ariard: really interested in that, as imo there's still a bit of a gap between theory and practicality when it comes to them, like can you really pin something for 2 weeks? 
11:55 <+roasbeef> particulalry if your "attack tree" was dropped from the mewmpol last fee due to being too low fee 
11:55 <+roasbeef> rusty: yeh according to this rando site https://chainquery.com/bitcoin-cli/getmempoolinfo 
11:56 < t-bast> johanth: should it be 10-20 or 10-20 times your node's min_relay_fee?
11:56 < ariard> roasbeef: I've detailed write-ups to close the gap between theory and practice, rn I'm reworking RL sample node
11:56 <@rusty> johanth: I say we should sit on 20 sat/kb all the time, and declare MISSION ACCOMPLISHED.
11:56 < lndbot> <johanth> I meant 10-20 sat/b
11:56 < ariard> and when it's done I'm plannign to test it with the pinning scenarios
11:56 <@rusty> oops, sat/b not sat/kb!  so 80 sat/sipa.
11:57 <+roasbeef> ariard: cool stuff, looking forward to the ultimate findings, personally it's kinda in my "other stuff that's more practical to worry about" bucket, but happy to be proven wrong 
11:57 < lndbot> <johanth> rusty: mhm, I also prefer kicking this can a bit longer down the road
11:57 < ariard> roasbeef: 2 weeks depends of mempool-congestion and committed feerate chosen by counterparty
11:57 <+roasbeef> ariard: yeh there's a lot of variables in it really, it isn't a "deterministic" attack/scenario 
11:58 <+roasbeef> imo
11:58 < ariard> roasbeef: yeah will reach out to you when I feel ready to execute it :)
11:58 < niftynei> time check: we've got 2min til the hour closes
11:58 < ariard> but yeah lot of variables to integrate, can you _predict_ mempool-congestion above channel feerate for more than HTLC delta? this kind of reasoning
11:59 <@rusty> I really would like to Pick A Number, then we can agree on that for anchors, and eventually remove the update_fee logic altogether... Bwahahah...
12:00 < ariard> I would rather pick a common scaling factor * min_relay_fee logic, it's more mempool-congestion fault-tolerant
12:00 < t-bast> what about pick 20 sat/b and watch your own mempool, and if it becomes too low to relay you raise it (and fundee agrees on that raise based on its own mempool view as well and the value at risk)?
12:00 < niftynei> i'm really not very well versed in feerate/mempool logics, but it seems that picking a static number is ... kind of dangerous as a motivated attacker would have a fixed target
12:00 <+roasbeef> ariard: but not all nodes have the same "minrelayfee", IIRC, if you change the size of your mempool then this value is affected 
12:00 <+roasbeef> like some ppl run on rasp pis and constraint their bitcoind mempool accordingly 
12:01 < t-bast> it will never be perfect because no global mempool / different mempool size / etc but if you apply a small factor to it, you're likely ok
12:01 <@rusty> niftynei: but they have to hold above that target for weeks...
12:01 < ariard> roasbeef: the "minrelayfee" is static, the mempool min fee is dynamic (IIRC) but you're right we care about the one which is dynamic
12:01 < lndbot> <johanth> I don’t think we need to pick a number. As initiator you also have a incentive to keep it low, but relayable.
12:01 < t-bast> I'm ok with closing all the channel I have with people running nodes on raspberry pis :D
12:01 < lndbot> <johanth> as a receiver, just do as we always do: check it is not insane
12:02 < niftynei> mmh i see. that does get expensive. but how expensive? 
12:02 <+roasbeef> ariard: ah ok I always forget which one is static and which one is dynamic, but then they don't seem compatible right? given stuff that was above this minrelay value wasn't accepted into the mempool last week? 
12:02 <+roasbeef> as in a node won't relay something it won't accept
12:02 < t-bast> aren't you ok as long as you take the max of the two?
12:02 < t-bast> (it's on my todo list to experiment with those, haven't done it yet)
12:03 < ariard> roasbeef: the relation is minrelayfee > mempool min fee, and it's must but if your package is in-between, it's not accepted
12:03 -!- Guest81 [3344c770@gateway/web/cgi-irc/kiwiirc.com/ip.51.68.199.112] has quit [Quit: Connection closed]
12:03 < ariard> and yeah mempool min fee is function of your node settings
12:03 < ariard> also your implementation version as policy change may affect which kind of package will be accepted
12:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
12:04 < ariard> so we might have a chosen feerate scaling on local view of your mempool min fee
12:04 < niftynei> (so two weeks of paying for full 2MB blocks of 20s/b feerate txs is 8k btc)
12:04 < ariard> and hope for your channel counterparty not having a view too much different
12:04 < harding> niftynei: for each 1 sat/vb increase in the min feerate, each block will have to pay an addition 0.04 BTC fee, times 2,016 block in two weeks, means ~80 BTC.  So 20 s/vb means the upper bound an attacker will have to pay is 1,600 BTC (about $2.4 million at present).
12:05 <+roasbeef> sooo...something something pick sane value for clamps that seem "good enough"? 
12:05 <+roasbeef> harding: interesante...
12:05 < t-bast> harding: interesting, thanks for those numbers
12:05 < ariard> roasbeef: yeah "good enough" without too much margin for an attacker to leak fee
12:06 < ariard> okay let me write a proposal on this for next meeting
12:06 < niftynei> mm my math's off. lol
12:06 <+roasbeef> so 20 s/vb "feels good"? 
12:06 < t-bast> ariard: ack, would be great to have a written proposal we can discuss on
12:06 <+roasbeef> parameterized by the size of the channel I guess 
12:07 -!- fiatjaf [~fiatjaf@2804:7f2:2986:a022:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 264 seconds]
12:07 < ariard> roasbeef: why parameterzied by the size of the channel? because higher-value willingness to spend more in fees
12:07 < lndbot> <johanth> I did some fee leak calculations, can comment on the proposal when you have that up ariard
12:07 <+roasbeef> ariard: yeh like if the chan is 10k btc or something, but prob not something we really need to worry about rn 
12:08 < niftynei> what is a "fee leak"?
12:08 <+roasbeef> a name we coined for the attack ariard desribed where an attacker uses high fees to gain htlc value outside a breach case 
12:08 < ariard> johanth: will post on the ml as usually, but great to have absolute fee leaks range based on channel value/chosen feerate/historical mempool congestion
12:09 <@rusty> Note that if this attack were ongoing, the response would be to increase mempool sizes on lightning-nodes that can, too.
12:09 <+roasbeef> so they use like 500 sat/vbyte, then siphon off the fees in the second level, and use a smaller value to confirm the htlcs, they've gained that diff in fees and the actual amount they signed off on to confirm 
12:09 < ariard> a fee leak is a scenario of punishment escape
12:09 <+roasbeef> rusty: +1
12:09 < lndbot> <johanth> ariard: mhm, at a given feerate and reserve size you can calculate how many HTLCs you can safely accept
12:10 < niftynei> we're ten minutes over time
12:10 < ariard> rusty: I don't follow you there, how increasing the mempool size prevent your counterparty to announce high-feerate update_fee to leak fees?
12:11 < t-bast> rusty: but you still want your txs to propagate through smaller mempools as well if you want to get them to miners
12:11 <@rusty> ariard: different thread, I'm talking about an attacker increasing mempool entry feerates to try to stop txs from propagating.
12:11 < ariard> johanth: yes and you want this given feerate to be fault-tolerance against mempool congestion
12:11 < t-bast> rusty: ok I understand your comment then
12:12 <@rusty> t-bast: if it really hit the fan, I would ask Blockstream to mine them...
12:12 < t-bast> rusty: XD
12:12 <+roasbeef> aight Rusty has our back with Plan C 
12:12 <+roasbeef> just lemmie know where to dump the transactions 
12:12 < lndbot> <johanth> oh, can I have an API?
12:12 <+roasbeef> friend of a miner, friend of the people xD 
12:12 < lndbot> <johanth> `rpc EmwegwncyMine(tx)`
12:12 < t-bast> POST https://rusty.ozlabs.org/mine
12:13 < ariard> so finally cdecker is working on his LN-tx-relay-infrastructure-for-miners ahah
12:13 <+roasbeef> blockStreamTakeTheWheel(tx)
12:13 <@rusty> I think my point is that it's probably easier to respond if and when, than to try to design complexity into the protocol to handle all the cases (along with all the bugs we create along the way)
12:13 < niftynei> roasbeef, lmao
12:13 < t-bast> Agreed, I think we're nearing a good enough solution
12:14 <@rusty> Hmm, we could actually abuse keysend for this...
12:14 < t-bast> Let's see ariard's write-up and comment on it, we're making progress
12:14 < ariard> just congestioning all network mempools to block LN-tx propagation has a defined cost based on default mempool size
12:14 < niftynei> ok sounds like we have an action item for this
12:15 < lndbot> <johanth> is somebody not running their own miner? muh decentralisation
12:16  * roasbeef looks over at the BFL Jalepeño on his desk 
12:17  * roasbeef slaps casing, this baby does 5 GH/s 
12:17 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
12:17 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has joined #lightning-dev
12:18 <+roasbeef> ok g2g on my end, solid meeting y'all 
12:18 <@rusty> Yep, thanks everyone!
12:18 < t-bast> same for me, thanks everyone and thanks niftynei for chairing!
12:18 < niftynei> #action ariard to write up concrete proposal for next meeting
12:18 < niftynei> #endmeeting
12:18 < niftynei> cheers!
12:18 < ariard> see you!
12:18 < t-bast> see you guys!
12:18 < lndbot> <johanth> waves
12:18 -!- t-bast [~t-bast@5.50.145.86] has quit [Quit: Leaving]
12:19 <@rusty> Hmm, lightningbot has really died this time :(  I'll get AJ to take a look again...
12:19 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Quit: Leaving]
12:22 < niftynei> i updated #813 with the action items
12:22 < niftynei> https://github.com/lightningnetwork/lightning-rfc/issues/813
12:22 < niftynei> looks like ariard's got a big two weeks :P
12:25 < ariard> niftynei: lol have you heard about lockdown ? it's like a transaction pinning but for humans and you get a lot of free time ;)
12:34 < niftynei> ariard: lol!
12:35 < harding> Err, my math above was wrong; I confused weight units and vbytes.  Real math (I hope): for every 1 sat/vb increase, total block transaction fees increase 0.01 BTC.  Times 2016 blocks is ~20 BTC.  For 20 s/vb, the most the attacker would have to pay is 400 BTC.  Sorry.
12:43 -!- fiatjaf [~fiatjaf@2804:7f2:2a86:8e94:ea40:f2ff:fe85:d2dc] has joined #lightning-dev
12:50 < niftynei> At $15k USD, that'd be $6M.
12:51 < niftynei> (I think you meant $24M above, for 1600BTC)
12:53 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:29fe:c4d1:ebb5:612a] has joined #lightning-dev
12:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
13:14 -!- ja [janus@anubis.0x90.dk] has joined #lightning-dev
13:32 -!- per [~per@gateway/tor-sasl/wsm] has quit [Remote host closed the connection]
13:32 -!- per [~per@gateway/tor-sasl/wsm] has joined #lightning-dev
14:02 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 272 seconds]
14:03 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
14:05 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Remote host closed the connection]
14:05 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
14:06 -!- arij [uid225068@gateway/web/irccloud.com/x-vmntxcbzpoztbtxt] has joined #lightning-dev
14:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
14:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
14:12 -!- vasild_ is now known as vasild
14:22 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
14:22 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
14:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds]
14:34 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
14:37 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
14:39 -!- yzernik [~yzernik@170.250.112.195] has quit [Quit: ZNC 1.7.5 - https://znc.in]
14:41 -!- yzernik [~yzernik@170.250.112.195] has joined #lightning-dev
14:45 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:29fe:c4d1:ebb5:612a] has quit []
14:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:58 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 272 seconds]
14:59 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
15:12 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 265 seconds]
15:13 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
15:16 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
15:16 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
15:46 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
15:47 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
16:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
16:35 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
16:47 -!- laptop [~laptop@ppp-3-36.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 264 seconds]
17:03 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
17:06 -!- da39a3ee5e6b4b0d [~textual@cm-171-98-91-242.revip7.asianet.co.th] has joined #lightning-dev
17:54 -!- da39a3ee5e6b4b0d [~textual@cm-171-98-91-242.revip7.asianet.co.th] has quit [Ping timeout: 256 seconds]
18:17 -!- da39a3ee5e6b4b0d [~textual@cm-171-98-91-242.revip7.asianet.co.th] has joined #lightning-dev
18:40 -!- da39a3ee5e6b4b0d [~textual@cm-171-98-91-242.revip7.asianet.co.th] has quit [Ping timeout: 256 seconds]
18:58 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
19:02 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
19:52 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 246 seconds]
19:53 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev
19:53 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
19:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
19:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
20:02 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
20:03 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
20:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
20:46 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
20:47 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
20:47 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
20:48 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
20:56 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-91-242.revip7.asianet.co.th] has joined #lightning-dev
21:06 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
21:21 -!- fiatjaf [~fiatjaf@2804:7f2:2a86:8e94:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 244 seconds]
21:21 -!- fiatjaf [~fiatjaf@2804:7f2:2a86:8e94:ea40:f2ff:fe85:d2dc] has joined #lightning-dev
21:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
21:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
21:33 -!- yzernik [~yzernik@170.250.112.195] has quit [Quit: ZNC 1.7.5 - https://znc.in]
21:35 -!- yzernik [~yzernik@170.250.112.195] has joined #lightning-dev
21:38 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
21:42 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
21:43 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection]
22:24 -!- nibbier [~quassel@mx01.geekbox.info] has quit [Quit: No Ping reply in 180 seconds.]
22:24 -!- nibbier [~quassel@mx01.geekbox.info] has joined #lightning-dev
22:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
22:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
23:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:30 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-91-242.revip7.asianet.co.th] has quit [Ping timeout: 240 seconds]
23:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
23:47 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev
23:47 -!- t-bast [~t-bast@5.50.145.86] has quit [Client Quit]
23:49 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
23:49 < lnd-bot> [lightning-rfc] t-bast merged pull request #808: Prevent preimage reveal collision while claiming onchain incoming HTLC (master...2020-10-prevent-htlc-collision) https://github.com/lightningnetwork/lightning-rfc/pull/808
23:49 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
23:49 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
23:49 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/5a86adaa7780...dcf6b0f359c2
23:49 < lnd-bot> lightning-rfc/master dcf6b0f Antoine Riard: Prevent preimage reveal collision while claiming onchain incoming HTLC (#8...
23:49 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
--- Log closed Tue Nov 10 00:00:12 2020