Onion Message Jamming in the Lightning Network

Different implementations have adopted varied approaches to rate limiting: Core Lightning uses a token bucket allowing four messages per second per peer, Eclair implements a hard cap of ten messages per second, LDK prioritizes other channel messages over onion messages, and LND plans to implement a sophisticated two-tier token bucket system following its next update.

The existing strategies for handling onion messages are susceptible to flooding attacks, where attackers craft messages that cause network nodes to hit their rate limits and drop legitimate traffic. Proposed mitigations include upfront fees to make attacks economically impractical, a reduction in maximum allowable hops to limit the reach of an attack, bandwidth metered payments to control the resource usage per session, and backpropagation-based rate limiting to trace spam back to its source. Each of these solutions presents trade-offs between effectiveness, complexity, and the impact on network behavior and user experience.

In response to the challenges posed by onion message spam, several complex mitigation strategies are being proposed. These include using economic measures like upfront fees, which could deter spam by imposing a cost on message transmission. Additionally, technical limitations such as hop limits or proof-of-work requirements could directly restrict the ability to flood the network. Moreover, new payment systems like blinded tokens or e-cash might offer innovative ways to manage network resources without compromising privacy or adding excessive overhead.

Ultimately, the community continues to explore these options, balancing the potential benefits against the drawbacks of each approach. The goal is to enhance the robustness of the Lightning Network against spam while maintaining efficiency and user privacy. Discussions and feedback from the community are crucial in shaping the future direction of these developments.