Attributable errors

[joostjager]

Error attribution is important to properly penalize nodes after a payment failure occurs. The goal of the penalty is to give the next attempt a better chance at succeeding. In the happy failure flow, the sender is able to determine the origin of the failure and penalizes a single node or pair of nodes.

Unfortunately it is possible for nodes on the route to hide themselves. If they return random data as the failure message, the sender won't know where the failure happened.

This PR updates the failure encryption mechanism so that the failure source can always be determined.

References:

• https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html
• https://github.com/lightning/bolts/pull/1044

[Roasbeef]

cc @bitromortac

[lightninglabs-deploy]

@joostjager, remember to re-request review from reviewers when ready

[joostjager]

!lightninglabs-deploy mute

[joostjager]

If we have b bits (say 8000) available for the HMACs and security of s bits in the HMACs (HMAC chopped off after s bits, as you suggested out of band)

Yes, I think this would be a useful optimization. You could argue that attributing failure isn't the most critical thing in lightning. Even with a relatively high chance of an attacker forging an hmac that is considered valid (let's say 21 bits, 1 in 2,000,000), game theory is still very much against them. If they guess wrong, they'll be penalized and will have to wait for their reputation to be restored before they'll receive new traffic from that sender.

[joostjager]

Feedback from lnd dev call:

• Hard-code max_hops to 27 to avoid fingerprinting. Perhaps it could be one or two hops less also because the max hops goes down when we signal attributable errors.
• Reduce hmac bits to keep failure message reasonably small (bits tbd, maybe divisible by 8, maybe 32 bits?)

For the payload that each node adds, we could for now just go for the minimum size. No tlv also. Especially because we don't even have concrete ideas what to add besides the timestamp. If this changes in the future, we can invent another signal in the forward onion.

This would eliminate all parameters from the forward onion and leave just a zero-length tlv record to signal sender support for attributable errors.

[joostjager]

Added a parameter in the attributable error structure struct for the size of the hmac.

The other changes mentioned above can happen in the lnd pr.

[joostjager]

Test vector updated to 20/4/4 structure in line with https://github.com/lightning/bolts/pull/1044#issuecomment-1669510607