From c2c0158c84936d2e96669b1dee476b7e5b9aa3b4 Mon Sep 17 00:00:00 2001 From: Carla Kirk-Cohen Date: Fri, 8 Mar 2024 13:33:10 -0500 Subject: [PATCH] htlcswitch: handle malformed HTLC with invalid onion blinding code This commit adds handling for malformed HTLC errors related to blinded paths. We expect to receive these errors _within_ a blinded path, because all non-introduction nodes are instructed to return malformed errors for failures. Note that we may actually switch back to a malformed error later on if we too are a relaying node in the route, but we handle that case the incoming link. --- htlcswitch/link.go | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/htlcswitch/link.go b/htlcswitch/link.go index 778e78d70..fd87c2f29 100644 --- a/htlcswitch/link.go +++ b/htlcswitch/link.go @@ -2030,6 +2030,19 @@ func (l *channelLink) handleUpstreamMsg(msg lnwire.Message) { failure = &lnwire.FailInvalidOnionKey{ OnionSHA256: msg.ShaOnionBlob, } + + // Handle malformed errors that are part of a blinded route. + // This case is slightly different, because we expect every + // relaying node in the blinded portion of the route to send + // malformed errors. If we're also a relaying node, we're + // likely going to switch this error out anyway for our own + // malformed error, but we handle the case here for + // completeness. + case lnwire.CodeInvalidBlinding: + failure = &lnwire.FailInvalidBlinding{ + OnionSHA256: msg.ShaOnionBlob, + } + default: l.log.Warnf("unexpected failure code received in "+ "UpdateFailMailformedHTLC: %v", msg.FailureCode)