Fat Errors

Summary:

In an email exchange, Joost Jager discussed with Bastien the issue of gaps in error attribution in Lightning Network. The problem is that nodes on a payment route can hide themselves by returning random data as the failure message, leading to senders penalizing all nodes that were part of the route instead of the actual offending node. To address this issue, Jager proposed a new failure message format that allows each node to commit to the failure message when passing it back by adding an HMAC. This makes it impossible for any node to modify the failure message without revealing their involvement.The new failure message format consists of three parts: `message`, `payloads`, and `hmacs`. `Message` is the standard onion failure message without the HMAC, while `payloads` is a fixed-length array that contains space for each node on the route to add data to return to the sender. `Hmacs` is a fixed-length array where nodes add their HMACs as the failure message travels back to the sender. Each HMAC corresponds to a presumed position in the path, where `hmac_0_2` is for the longest path (2 downstream hops) and `hmac_0_0` for the shortest (node is the error source). Before a hop adds its HMACs, it first deletes some of the previous HMACs to keep the failure message at a fixed length.Overall, Jager's proposed failure message format addresses the issue of gaps in error attribution by allowing each node to commit to the failure message when passing it back, making it impossible for any node to modify the message without revealing their involvement. This will help avoid situations where senders penalize all nodes that were part of the route instead of the actual offending node.The Lightning Network is a system for off-chain bitcoin transactions that allows for faster and cheaper transfers. However, it suffers from a vulnerability in the handling of failed payments that can be exploited by a malicious node to reveal information about the sender's route and potentially deanonymize them. To address this issue, a proposal has been made to add a new failure message format that includes a chain of HMACs (Hash-based Message Authentication Codes) to verify the integrity of the message.The proposal covers the next and final hops, as well as the corresponding HMAC positions for those nodes. This information enables the sender to verify the longest chain of HMACs until it encounters a hop_payload with is_final set. If a node modifies any byte of the failure message, the sender can always determine a pair of nodes that the offending node is part of, which has been confirmed through testing.The downside of the proposed scheme is its size. Given a maximum of 27 hops, the HMACs block contains 378 HMACs of 32 bytes each, making for a total size of 12 KB. However, the proposed solution is seen as justified to fix the vulnerability in Lightning. If failures are expected to become more rare going forward, the size becomes less relevant to the overall operation of the network. Another option to reduce the size is to lower the maximum number of hops, which would also contribute to reducing latency and capital lock up.For backwards compatibility, nodes need to know what algorithm they should run to generate or transform the failure message, which can be signaled by the sender via a tlv onion field. Intermediate nodes also need to advertise their capability to transform the new format through a feature bit.It is not just failures that can be delayed; successes can too. In that case, adding the same payloads and HMACs blocks to the update_fulfill_htlc message could be an option. Links to various implementations of the Lightning Network are provided in the context.

Updated on: 2023-06-03T10:25:37.665592+00:00