Onion Message Jamming in the Lightning Network

The debate regarding the design and operational mechanics of onion messages in networking highlights a tension between maintaining lightweight operations and implementing measures to prevent denial-of-service (DoS) attacks. Originally, onion messages were designed to avoid the necessity of writing to disk with each message, which facilitates a more streamlined and efficient network operation. However, this design choice has been questioned in light of potential DoS attacks, suggesting that perhaps these messages should not be as lightweight if integrating a monetary solution could effectively mitigate such risks.

Onion messages differ significantly from Hash Time-Locked Contracts (HTLCs) despite both being vulnerable to spam-type attacks. HTLCs incentivize nodes to forward payments with the prospect of earning a fee upon successful transaction completion, whereas onion messages do not offer direct future benefits for forwarding messages, which might encourage nodes to drop messages after collecting initial fees. Nevertheless, nodes consistently dropping messages risk being bypassed in future routing decisions, potentially reducing their long-term fee earnings. This dynamic creates a natural deterrent against dropping messages too frequently.

Furthermore, the discussion extends to the practicality and feasibility of using batching approaches for processing onion messages. Although batching could theoretically reduce the complexity and state management required in the protocol, it might not align well with the operational characteristics of HTLCs, especially when considering the inclusion of unconditional fees in update_add_htlc. The conversation also touches on the broader implications for network liquidity and resource usage, noting that paths incapable of supporting onion message traffic due to low liquidity or limited resources are unlikely to support more demanding payment traffic either.

Ultimately, the proposal suggests that rather than relying on static fees or pushing the burden onto end-users, fees for onion messages should dynamically adjust based on current network load and capacity. This would allow the system to self-regulate more effectively, raising fees as needed to manage demand and lowering them when excess capacity is available, thus maintaining efficiency without compromising on robustness against potential network abuse.