--- Log opened Mon Sep 28 00:00:31 2020
00:11 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
00:28 -!- jonatack [~jon@37.167.90.115] has quit [Ping timeout: 265 seconds]
00:30 -!- sr_gi [~sr_gi@static-80-160-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
00:30 -!- sr_gi [~sr_gi@static-80-160-230-77.ipcom.comunitel.net] has joined #lightning-dev
00:30 -!- marcoagner [~user@bl11-17-219.dsl.telepac.pt] has joined #lightning-dev
00:39 -!- jonatack [~jon@37.167.90.115] has joined #lightning-dev
00:51 -!- jonatack [~jon@37.167.90.115] has quit [Quit: jonatack]
00:51 -!- jonatack [~jon@213.152.180.5] has joined #lightning-dev
01:06 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
01:19 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
01:21 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
02:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
02:32 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
02:39 -!- musdom [~Thunderbi@202.186.37.216] has quit [Quit: musdom]
03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
03:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
03:19 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev
03:19 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
03:19 -!- __gotcha1 is now known as __gotcha
03:23 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
03:33 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
03:39 -!- yzernik [~yzernik@12.203.56.101] has quit [Ping timeout: 240 seconds]
03:47 -!- jonatack [~jon@213.152.180.5] has quit [Ping timeout: 240 seconds]
03:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
03:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection]
04:17 -!- jonatack [~jon@37.167.111.11] has joined #lightning-dev
04:33 -!- jonatack [~jon@37.167.111.11] has quit [Ping timeout: 256 seconds]
04:57 -!- laptop [~laptop@ppp-2-75.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
05:06 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
05:23 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev
06:00 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
06:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]
06:04 -!- lukedashjr is now known as luke-jr
06:49 -!- lndbot [~lndbot@138.197.213.35] has quit [Remote host closed the connection]
06:50 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev
07:04 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ubhruimvbnukjsur] has joined #lightning-dev
07:17 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
07:22 -!- fearbeag [~sseanicid@bras-base-clwdon2201w-grc-18-216-209-44-240.dsl.bell.ca] has quit [Ping timeout: 240 seconds]
07:33 -!- proofofkeags [~proofofke@174-29-30-112.hlrn.qwest.net] has quit [Ping timeout: 246 seconds]
07:40 -!- oas346 [~oas346@45.87.215.62] has joined #lightning-dev
07:43 -!- oas346 [~oas346@45.87.215.62] has quit [Client Quit]
08:01 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 240 seconds]
08:04 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
08:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
08:33 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
08:50 -!- sr_gi [~sr_gi@static-80-160-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
08:51 -!- sr_gi [~sr_gi@static-80-160-230-77.ipcom.comunitel.net] has joined #lightning-dev
09:00 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
09:21 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
09:30 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
09:32 -!- lndbot [~lndbot@138.197.213.35] has quit [Remote host closed the connection]
09:32 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev
09:37 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
09:53 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #lightning-dev
09:57 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
10:08 -!- proofofkeags_ [~proofofke@2601:280:c280:e500:14cd:7d6b:2ea1:78e0] has joined #lightning-dev
10:11 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
10:32 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
10:43 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
10:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
10:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
11:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds]
11:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
11:09 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
12:00 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
12:04 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Client Quit]
12:14 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has quit [Ping timeout: 246 seconds]
12:16 -!- vtnerd [~vtnerd@50-81-138-206.client.mchsi.com] has joined #lightning-dev
13:00 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
13:02 < cdecker> Good evening
13:03 < sstone> Hi everyone!
13:06 < jkczyz> hi
13:06 < bitconner> hey y'all!
13:06 < ariard> hello
13:08 < m-schmoock> hi
13:10 < cdecker> So what's everybody up to?
13:11 < bitconner> struggling with peripherals lol
13:11 < bitconner> whats new
13:12 < cdecker> Not too much, we're in a post-release lull
13:12 < ariard> debugging CPFP logic
13:12 < cdecker> Shall we start the meeting with that?
13:13 < cdecker> #startmeeting
13:13 < lightningbot> Meeting started Mon Sep 28 20:13:12 2020 UTC.  The chair is cdecker. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:13 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:13 < cdecker> ariard am I correct in assuming the CPFP logic is for the anchors?
13:14 < ariard> cdecker: I'm trying to support both the commitment and 2nd-stage HTLCs
13:14 < ariard> but yes it is in the context of RL support of anchors
13:15 < ariard> I think there is maybe a concern if you're aggregating revoked outputs justice inputs
13:16 < cdecker> How so?
13:16 < ariard> because the new malleability lets someone pin 2nd-stage transaction and thus obstrucating you're claim of the `to_local` output
13:16 < ariard> let say you see a revoked commitment, you want to claim all revoked output in one justice transaction
13:16 < cdecker> Ah, I should have guessed pinning is the answer :-)
13:16 < ariard> it's a never ending bad joke
13:17 < cdecker> I'm afraid so
13:17 < ariard> the thing even if the 2nd-stage transaction are encumbered by 1-block CCSV
13:17 < ariard> *CSV
13:17 < ariard> in practice if both the cheating party and you are using the anchor slots
13:17 < ariard> your justice txn are going to be bounce off by the mempool due to descendant limit
13:18 < ariard> thus canceling the 1-block CSV advantage you should have
13:18 < ariard> and then the cheating party broadcast stuffed 2nd-stage txn
13:18 < ariard> if your broadcast logic aggregates your justice on `to_local` output is going to be rejected
13:19 < ariard> IMO possible exploitation is really dependent of implementation
13:19 < cdecker> I see, the attacker can't self-punish and frontrun you because he's missing the signature from the remote end
13:20 < ariard> cdecker: I think CL is okay because you claim a revoked `to_local` output without aggregating with revoked HTLC outputs
13:20 < cdecker> Yeah, but aggregating them has been on our todo-list for some time
13:20 < ariard> cdecker: not exactly, it's a revoked commitment broadcast so you may broadcast HTLC-timeout/HTLC-success after the fact
13:21 < ariard> I think it's okay to aggregate justice claims on revoked HTLC outputs but not blurring with a revoked `to_local`
13:21 < ariard> to prevent any pinning which would let a cheating party expires the `to_local` CSV delay
13:22 < cdecker> Yes, I was just wondering if the attacker could self-punish if we remove the CSV 1 on HTLCs, stuffing that TX and pinning the self-punishment
13:22 < ariard> how do you self-punish without the revocation key ?
13:23 < cdecker> Yes, that's what I figured as well xD
13:24 <+roasbeef> wow, why do I keep missing this thing 
13:24 < cdecker> Welcome roasbeef :-)
13:24 <+roasbeef> kek
13:24 <+roasbeef> ok i'm only kinda late ;)
13:25 < jkczyz> it twas a slow start
13:25 < cdecker> I think the only pending topic is the routeblinding proposal, but t-bast may not be here
13:26 < ariard> roasbeef: btw see conversation above, I think LND has the same issue than RL with aggregation+bad pinning
13:26 < sstone> no he won't be joining us today, I'll try and fill in for him
13:26 < ariard> post-anchor
13:26 -!- proofofkeags__ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
13:26 < cdecker> Thanks sstone
13:26 < cdecker> #topic Route Blinding
13:27 < cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/765/files
13:27 < cdecker> If I remember correctly t-bast was mainly looking for feedback on the soundness of the cryptography
13:28 < sstone> yes, that's why a few details are not fully specced out yet
13:29 -!- proofofkeags_ [~proofofke@2601:280:c280:e500:14cd:7d6b:2ea1:78e0] has quit [Ping timeout: 244 seconds]
13:30 < ariard> sstone: what new cryptographic primitives it's introducing?
13:30 < m-schmoock> mm
13:31 < sstone> ariard: I don't think they're "new" per se, it's more about how existing ones are reused
13:31 <+roasbeef> not super caught up, but how does it handle forwarding errors and client retries?
13:32 < cdecker> As far as I can see the only thing that isn't already used in the sphinx construction is the tweaking of the public key (the node's identity is hidden via that tweak)
13:32 < cdecker> Client retries are possible from what I can see, but errors should not be forwarded imho, other than a generic "it failed somewhere"
13:33 < cdecker> But that probably needs to be specced out
13:34 <+roasbeef> but then wouldn't that drastically degrade the experience for senders? 
13:34 < cdecker> The main advantage over rendez-vous routing is the added flexibility of changing CLTVs and other params
13:34 < cdecker> It would indeed, but a detailed error may leak more information than we want
13:35 <+roasbeef> hmm, yeh but if these payments just have a much worse success rate, since senders can update their memory/view (what we call mission control in lnd), would it actually get any uptake? 
13:36 <+roasbeef> and if it only gets uptake for "siple known" path slike between w/e major merchant thing, then does it add anything significant given the other timing/path constraint leaks? 
13:36 <+roasbeef> simple* 
13:37 < cdecker> Yes, it's a tradeoff, not sure which way I tend tbh
13:38 < sstone> roasbeef: why would payment failure rate be correlated to this ? or do you mean that it's worse than what we have when payments fail ?
13:39 < cdecker> I think the only errors that we could actually react to in a reasonable way are "amount too high" (only if we have another route via a second blinded route and can split), "cltv too low" or "fee too low"
13:39 <+roasbeef> yeh zooming out fundamentally there's a privacy/reliability tradeoff here as well, obvs one single central path findiner would solve all issue
13:40 < cdecker> All others would basically prevent us from retrying since we can't change the part that is being blinded, other than asking the recipient for another one
13:40 < BlueMatt> do we not get at least "which of the source-selected hops failed to get the payment to the next source-selected hop"?
13:40 < BlueMatt> (I may be misunderstanding what the design is here entirely, forgive me)
13:41 < BlueMatt> or, i guess they just get it to the "entry point" and then its up to the receiver to make sure they get good entry points...
13:41 < BlueMatt> I'll shut up
13:42 < cdecker> The sender will get normal errors back up to the introduction point for the blinding
13:42 < cdecker> After that we need to summarize the errors somehow
13:42 < cdecker> t-bast actually mentioned this in the proposal (my bad for not seeing it before): https://github.com/lightningnetwork/lightning-rfc/blob/6d8166e2c3215ee051c6492033023784e850a893/proposals/route-blinding.md#unblinding-channels-via-fee-probing
13:43 <+roasbeef> cdecker: yeh taht's teh thing right, and we have no bi-di communication stream w/o somethin glike hornet 
13:43 < BlueMatt> i mean i guess the solution is the recipient needs to actively monitor its introduction points and make sure it can provide a few of them, which is a lot of data...
13:44 < BlueMatt> well even with hornet if the recipient wants to be anonymous and the issue is one of its introdcution points went offline...
13:44 < cdecker> BlueMatt: the blinded route and introduction point are passed to the sender via the invoice (like rendez-vous would have)
13:44 < BlueMatt> right, I'm saying ideally you'd be able to pass 2/3, though it ends up with a lot of data
13:45 < BlueMatt> like, the "solution" isnt to try to force the old style of sender tracking bad nodes but instead to force the receiver to do that and for the receiver to provide a few options for the sender to address temporary issues.
13:45 < cdecker> Unless the recipient provides multiple blinded routes any permanent failure in the blinded route will result in the payment failing
13:46 < BlueMatt> right, exactly
13:48 < cdecker> That being said, route blinding could be useful for offers as well, since they are not payment related, they don't incur in that many errors
13:49 < sstone> blinded hops would typically be the last hop to a node that uses small number of private channels, so it that hops fails permanently it would not be able to do much anyway
13:49 < sstone> * if
13:52 < cdecker> Right, it came out of the whole encrypt the short-channel-ids discussion
13:55 < cdecker> Anyway, I'll give it another poke for next time
13:55 < cdecker> Anything we should address in the last couple of minutes?
13:57 < sstone> Is there an update on the analysis of historical min relay fee data ?
13:58 < BlueMatt> not from my end, sorry, it slipped
14:00 < cdecker> Ok, let's call it a day then :-)
14:00  * cdecker is falling asleep on his feet :-)
14:00  * jkczyz scurries out 
14:00 < cdecker> #endmeeting
14:00 < lightningbot> Meeting ended Mon Sep 28 21:00:31 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-09-28-20.13.html
14:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-09-28-20.13.txt
14:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-09-28-20.13.log.html
14:00 < cdecker> Thanks everyone, I promise I'll write an agenda for next time again :-)
14:02 < sstone> thanks cdecker!
14:12 -!- m-schmoock [~will@schmoock.net] has quit [Remote host closed the connection]
14:14 -!- m-schmoock [~will@schmoock.net] has joined #lightning-dev
14:47 -!- proofofkeags_ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
14:47 -!- proofofkeags__ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer]
14:49 -!- proofofkeags__ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
14:52 -!- proofofkeags_ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds]
14:55 -!- marcoagner [~user@bl11-17-219.dsl.telepac.pt] has quit [Ping timeout: 260 seconds]
14:56 -!- proofofkeags__ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 256 seconds]
14:57 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
15:01 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
15:02 -!- proofofkeags_ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
15:04 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
15:07 -!- proofofkeags_ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Quit: Leaving]
15:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
15:14 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
15:16 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
15:18 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ubhruimvbnukjsur] has quit [Quit: Connection closed for inactivity]
15:30 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
15:42 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
16:22 -!- yzernik [~yzernik@12.203.56.101] has joined #lightning-dev
16:46 -!- fearbeag [~sseanicid@bras-base-clwdon2201w-grc-18-216-209-44-240.dsl.bell.ca] has joined #lightning-dev
16:49 <+roasbeef> sstone: missed this initially, hopefully you reads scrollback, but I mean that if senders aren't able to easily retry due to w/e thing happening, and they can't easily dynamically fetch new routes from teh receiver, then the receiver's route would need to be a "one shot golden one" 
16:54 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds]
17:34 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
17:41 -!- arij [uid225068@gateway/web/irccloud.com/x-luxsyzmdaarpmdhp] has joined #lightning-dev
17:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
17:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
17:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
18:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
18:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
18:44 -!- laptop [~laptop@ppp-2-75.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
18:52 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
18:54 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
19:20 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Remote host closed the connection]
19:21 -!- alko89 [~alko89@unaffiliated/alko89] has joined #lightning-dev
19:39 -!- IPGlider [~IPGlider@45.76.34.219] has quit [Quit: Ping timeout (120 seconds)]
19:46 -!- IPGlider [~IPGlider@45.76.34.219] has joined #lightning-dev
19:56 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
19:56 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #lightning-dev
20:40 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
21:28 -!- buZz [~buzz@unaffiliated/buzz] has quit [Ping timeout: 260 seconds]
21:29 -!- buZz [~buzz@joint.ro.lt] has joined #lightning-dev
21:30 -!- buZz is now known as Guest43461
23:17 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev
23:17 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
23:17 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
23:48 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
23:56 -!- yzernik [~yzernik@12.203.56.101] has quit [Ping timeout: 240 seconds]
23:57 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
--- Log closed Tue Sep 29 00:00:32 2020