Author: Joost Jager 2022-10-20 15:45:16
Published on: 2022-10-20T15:45:16+00:00
Joost Jager, a Lightning Network developer, has proposed a new method for error attribution in the network. The Lightning Network has had a long-standing issue with gaps in error attribution, which makes it possible for nodes on the route to hide themselves and return random data as the failure message. This makes it difficult for senders to determine the origin of the failure and penalize the right node(s). To address this, each node on the route can append a timestamp and HMAC to the failure message, making it impossible for any node to modify the message without revealing that they might have played a part in the modification.The proposed solution is designed to fix the vulnerability in the Lightning Network and improve error attribution. The idea behind the proposal is to prevent nodes on a route from hiding themselves by adding an HMAC to the failure message that each node passes back. The sender will verify all HMACs upon receipt of the failure message, and pinpointing a pair of nodes would be good enough to penalize them. The new failure message format consists of three parts: `message`, `payloads`, and `HMACs`. The payloads contain the data of each node on the route while the HMACs contain the HMAC added by each node as the failure message travels back to the sender. Previous HMACs are deleted before new ones are added to keep the failure message at a fixed length.The proposed method still needs to be reviewed by other developers before it can be implemented. The penalty gives the next attempt a better chance at succeeding. Besides, delays in the path can be addressed by adding the same `payloads` and `hmacs` blocks to the `update_fulfill_htlc` message. For backwards compatibility, nodes need to know what algorithm they should run to generate or transform the failure message, signaled via a tlv onion field. Intermediate nodes also need to advertise their capability to transform the new format through a feature bit.The downside of the current scheme is the size due to a maximum of 27 hops, which contains 378 HMACs of 32 bytes each and a total size of 12 KB. However, reducing the maximum number of hops could drop the total number of HMACs from 378 to 55, making it more compact and efficient for the network operation. Eclair's code does not penalize nodes for future payment attempts when they return random data as the failure message; it only ignores them for retries of that particular payment.The Lightning Network has been updated with a new failure message format to fix a vulnerability in the system. The new format includes `payloads` and `hmacs` blocks that contain information about the route the payment took. The `payloads` block signals the contents and size of `hop_payload`, which is a fixed length array containing space for each node on the route to add data to return to the sender. The `hmacs` block contains hmacs for all possible positions, added by nodes as the failure message travels back to the sender. Nodes delete some of the previous hmacs to keep the failure message at a fixed length. The removed hmacs are the ones that cannot be useful anymore. If any of the nodes messes with any byte in the failure message, the sender is always able to determine a pair of nodes that the offending node is part of.The obvious downside of this scheme is the size, given a maximum of 27 hops, the `hmacs` block contains 27+26+25+...+1=378 hmacs of 32 bytes each, making for a total size of 12 KB. 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's not just failures that can be delayed, successes can too, and the new `payloads` and `hmacs` blocks could be added to the `update_fulfill_htlc` message.Additionally, the context provided is a link to a code repository on GitHub for the Lightning Network project. The specific file being linked is a plugin called "libplugin-pay.c", and the specific line being referenced is line 1461. There is also a separate link provided to a Rust implementation of a payment module, with the specific line being referenced as line 682. The context appears to be related to development work being done on the Lightning Network, with discussion potentially taking place on a mailing list called "lightning-dev" hosted by the Linux Foundation. No further information is provided.
Updated on: 2023-06-03T10:29:37.604990+00:00