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.
This commit is contained in:
Carla Kirk-Cohen 2024-03-08 13:33:10 -05:00
parent 2089a88f4b
commit c2c0158c84
No known key found for this signature in database
GPG key ID: 4CA7FE54A6213C91

View file

@ -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)