20:13:12 <cdecker> #startmeeting
20:13:12 <lightningbot> Meeting started Mon Sep 28 20:13:12 2020 UTC.  The chair is cdecker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:13:12 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:13:45 <cdecker> ariard am I correct in assuming the CPFP logic is for the anchors?
20:14:05 <ariard> cdecker: I'm trying to support both the commitment and 2nd-stage HTLCs
20:14:37 <ariard> but yes it is in the context of RL support of anchors
20:15:22 <ariard> I think there is maybe a concern if you're aggregating revoked outputs justice inputs
20:16:00 <cdecker> How so?
20:16:05 <ariard> because the new malleability lets someone pin 2nd-stage transaction and thus obstrucating you're claim of the `to_local` output
20:16:30 <ariard> let say you see a revoked commitment, you want to claim all revoked output in one justice transaction
20:16:39 <cdecker> Ah, I should have guessed pinning is the answer :-)
20:16:52 <ariard> it's a never ending bad joke
20:17:02 <cdecker> I'm afraid so
20:17:14 <ariard> the thing even if the 2nd-stage transaction are encumbered by 1-block CCSV
20:17:17 <ariard> *CSV
20:17:38 <ariard> in practice if both the cheating party and you are using the anchor slots
20:17:51 <ariard> your justice txn are going to be bounce off by the mempool due to descendant limit
20:18:05 <ariard> thus canceling the 1-block CSV advantage you should have
20:18:31 <ariard> and then the cheating party broadcast stuffed 2nd-stage txn
20:18:56 <ariard> if your broadcast logic aggregates your justice on `to_local` output is going to be rejected
20:19:35 <ariard> IMO possible exploitation is really dependent of implementation
20:19:55 <cdecker> I see, the attacker can't self-punish and frontrun you because he's missing the signature from the remote end
20:20:05 <ariard> cdecker: I think CL is okay because you claim a revoked `to_local` output without aggregating with revoked HTLC outputs
20:20:31 <cdecker> Yeah, but aggregating them has been on our todo-list for some time
20:20:48 <ariard> cdecker: not exactly, it's a revoked commitment broadcast so you may broadcast HTLC-timeout/HTLC-success after the fact
20:21:17 <ariard> I think it's okay to aggregate justice claims on revoked HTLC outputs but not blurring with a revoked `to_local`
20:21:44 <ariard> to prevent any pinning which would let a cheating party expires the `to_local` CSV delay
20:22:05 <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
20:22:37 <ariard> how do you self-punish without the revocation key ?
20:23:40 <cdecker> Yes, that's what I figured as well xD
20:24:04 <roasbeef> wow, why do I keep missing this thing
20:24:12 <cdecker> Welcome roasbeef :-)
20:24:33 <roasbeef> kek
20:24:42 <roasbeef> ok i'm only kinda late ;)
20:25:45 <jkczyz> it twas a slow start
20:25:45 <cdecker> I think the only pending topic is the routeblinding proposal, but t-bast may not be here
20:26:08 <ariard> roasbeef: btw see conversation above, I think LND has the same issue than RL with aggregation+bad pinning
20:26:10 <sstone> no he won't be joining us today, I'll try and fill in for him
20:26:11 <ariard> post-anchor
20:26:28 <cdecker> Thanks sstone
20:26:59 <cdecker> #topic Route Blinding
20:27:20 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/765/files
20:27:41 <cdecker> If I remember correctly t-bast was mainly looking for feedback on the soundness of the cryptography
20:28:54 <sstone> yes, that's why a few details are not fully specced out yet
20:30:12 <ariard> sstone: what new cryptographic primitives it's introducing?
20:30:42 <m-schmoock> mm
20:31:07 <sstone> ariard: I don't think they're "new" per se, it's more about how existing ones are reused
20:31:54 <roasbeef> not super caught up, but how does it handle forwarding errors and client retries?
20:32:01 <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)
20:32:58 <cdecker> Client retries are possible from what I can see, but errors should not be forwarded imho, other than a generic "it failed somewhere"
20:33:53 <cdecker> But that probably needs to be specced out
20:34:28 <roasbeef> but then wouldn't that drastically degrade the experience for senders?
20:34:33 <cdecker> The main advantage over rendez-vous routing is the added flexibility of changing CLTVs and other params
20:34:54 <cdecker> It would indeed, but a detailed error may leak more information than we want
20:35:51 <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?
20:36:23 <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?
20:36:27 <roasbeef> simple*
20:37:12 <cdecker> Yes, it's a tradeoff, not sure which way I tend tbh
20:38:14 <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 ?
20:39:37 <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"
20:39:41 <roasbeef> yeh zooming out fundamentally there's a privacy/reliability tradeoff here as well, obvs one single central path findiner would solve all issue
20:40:07 <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
20:40:32 <BlueMatt> do we not get at least "which of the source-selected hops failed to get the payment to the next source-selected hop"?
20:40:41 <BlueMatt> (I may be misunderstanding what the design is here entirely, forgive me)
20:41:44 <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...
20:41:50 <BlueMatt> I'll shut up
20:42:15 <cdecker> The sender will get normal errors back up to the introduction point for the blinding
20:42:30 <cdecker> After that we need to summarize the errors somehow
20:42:49 <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
20:43:38 <roasbeef> cdecker: yeh taht's teh thing right, and we have no bi-di communication stream w/o somethin glike hornet
20:43:47 <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...
20:44:20 <BlueMatt> well even with hornet if the recipient wants to be anonymous and the issue is one of its introdcution points went offline...
20:44:34 <cdecker> BlueMatt: the blinded route and introduction point are passed to the sender via the invoice (like rendez-vous would have)
20:44:50 <BlueMatt> right, I'm saying ideally you'd be able to pass 2/3, though it ends up with a lot of data
20:45:27 <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.
20:45:58 <cdecker> Unless the recipient provides multiple blinded routes any permanent failure in the blinded route will result in the payment failing
20:46:04 <BlueMatt> right, exactly
20:48:26 <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
20:49:03 <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
20:49:20 <sstone> * if
20:52:09 <cdecker> Right, it came out of the whole encrypt the short-channel-ids discussion
20:55:24 <cdecker> Anyway, I'll give it another poke for next time
20:55:40 <cdecker> Anything we should address in the last couple of minutes?
20:57:22 <sstone> Is there an update on the analysis of historical min relay fee data ?
20:58:25 <BlueMatt> not from my end, sorry, it slipped
21:00:12 <cdecker> Ok, let's call it a day then :-)
21:00:21 * cdecker is falling asleep on his feet :-)
21:00:31 * jkczyz scurries out
21:00:31 <cdecker> #endmeeting