Onion Message Jamming in the Lightning Network

In the discussion about managing communication of fee policies within a blockchain network, particularly focusing on taproot gossip and onion messages, several key points emerge regarding the effectiveness and implementation of these strategies. It is acknowledged that relying solely on one update per block may not be sufficient to handle sudden increases in traffic effectively, given this method's lack of reactivity. Instead, there's a suggestion that fees should be communicated through channel update messages, similar to how upfront fees for channels are currently managed. This approach could potentially mitigate issues without requiring frequent updates, assuming the baseline fees are appropriately set.

Further examination reveals concerns regarding the ability to dynamically adjust fees in response to network activities like jamming. The static nature of fee setting might limit the capability to respond swiftly to attacks, although if an attacker chooses to pay the fees, their actions might not necessarily pose a significant threat. This leads to considerations about whether rapid reactions to such attacks are essential or if a more measured response would suffice, especially when considering the potential benefits from the fees paid by attackers attempting to jam the network.

Moreover, there are complexities related to interpreting onion message failures and the implications for network liquidity and node behavior. The discussion highlights uncertainties about whether failures should always be seen as liquidity issues or if they could also indicate other problems, such as insufficient fees. This raises questions about the incentives for nodes to remain honest and the potential consequences of integrating onion message data into pathfinding algorithms, which could introduce new vulnerabilities. There is a proposal suggesting a nuanced use of onion message outcomes in pathfinding, where successful messages might prioritize certain paths without penalizing failures harshly, thereby avoiding undue punishment for nodes with reasonable policies. However, the benefits of this approach must be weighed against the added complexity it would introduce to the system.