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