Can failed Transactions figure out which Channel is exhausted?

Question

According to information in this LND PR the sender of an TemporaryChannelFailure can be determined:

In many cases it is impossible for the sender to determine which of the two nodes in a pair is responsible for the failure. In this situation, we now penalize bidirectionally. This does not hurt the good node of the pair, because only its connection to a bad node is penalized.

So my understanding of this comment is, the channel, or at least the node next to one of the exhausted channels can be identified quite easily. Is it really that easy? Can TemporaryChannelFailure and therefore channel exhaustions always be assigned to two nodes or one channel?

I always assumed, the error cannot be assigned to a node or channel at all.

This might simplify the work of some papers, such as On the Difficulty of Hiding the Balance of Lightning Network Channels by J Herrera-Joancomarti et al., or open new attack vectors.

Edit: more links for further research

In case someone wants to give a more in-depth answer or do research on top of this, here are some links to the code in the lnd client github code base:

• In lightningnetwork/lightning-onion crypto.go, function DecryptError, the client cycles through the secrets to unwrap the error and identify the sender index.

• In lightningnetwork/lnd htlcswitch/switch.go, function parseFailedPayment this DecryptError function is used to access the failure.

• Later this value will be accessed e. g. in missioncontrol.go or result_interpretation.go as FailureSourceIdx, failureSourceIdx or failureSrcIdx.

Answer 1

As far as I understand (but I did not double check the code) the answer is yes. The error messages in the onion seem to be encrypted in a way so that only the origanal sender of the onion can decrypt it. Since the error also had to be padded to keep the error onion of constant length the key derivation scheme for sending onions is kind of reused. In that sense the receiver of the error message unwraps all the envelopes and thus should know from which node the error arose.

Answer 2

When an intermediate or the final node (intended recepient) wants to send an error message they create an error packet which contains the (1) error message; (2) padding to conceal length and (3) HMAC that authenticates the packet using key um. This erring node then generates a key ammag that is used to generate a pseudo-random stream which in turn is applied to the error packet using XOR to obfuscate it. This error packet is then sent using the error message update_fail_htlc which includes the failure message temporary_channel_failure (this failure message is used in case of lack of channel funds or too many htlcs in flight).

This erring node will then forward this error packet to the node that forwarded the htlc to it. Intermediate nodes store the shared secret from the forward path and reuse it to obfuscate any corresponding return packet during each hop. The obfuscation step is repeated by every hop along the return path which generates its own ammag, generates the pseudo-random byte stream, and applies the result to the return packet before return-forwarding it. The error messages includes an id to let the peer know the htlc to which the error message is being referred.

When the error message arrives at the origin node, it is able to detect that this error message is intended of itself using the id as it was the one that created it. When an origin node receives an error message matching a transfer it initiated it generates the ammag and um keys for each hop in the route. It then iteratively decrypts the error message, using each hop's ammag key, and computes the HMAC, using each hop's um key. The origin node can hence detect the sender of the error message by matching the hmac field with the computed HMAC of the error packet.