Onion messages rate-limiting

Summary:

During the Oakland Dev Summit, lightning engineers discussed DoS protection for onion messages. Rusty proposed a simple rate-limiting scheme that statistically propagates back to the correct sender. Nodes apply per-peer rate limits on incoming onion messages, allowing more onion messages from peers with whom they have channels. The proposal doesn't make any recommendations about relaying onion messages for anonymous third parties.Instead, it allows nodes to adapt policy and rate-limit no-channel third parties before they rate limit any peer they have a channel with. Requiring a channel to relay onion messages puts a nontrivial cost to getting an onion messaging channel. The proposal to charge for onion messages does not solve the problem at hand since users may legitimately want to send a bunch of payments in bulk, and it doesn't impact the system's usability.Ultimately, what we have here is a networking problem that has to be solved with networking solutions, not a costing problem, which can be solved with payment. If anyone were proposing rate-limits which would allow enough bandwidth usage to cause "lightning is turning into Tor and has Tor's problems" to be a legitimate concern, then it would be reasonable to charge for its use. Ultimately, paying suffers from the standard PoW-for-spam issue, and no reasonable cost scheme will work.The Lightning Network has introduced a new mechanism for relaying onion messages between nodes. Nodes keep track of the node_id of the peer who sent the message, ensuring the memory footprint is small and the data doesn't need to be persisted. An example is given to illustrate this mechanism, showing how Bob receives onion messages from Alice and Eve, storing their node_ids in its per-connection state with Carol.A new message type (onion_message_drop) is introduced when an incoming onion message reaches rate limits. The receiver sends this message to the sender, halving their rate limits with that peer. If the sender doesn't overflow the rate limit again, the receiver should double the rate limit after 30 seconds until it reaches the default rate limit again. The shared_secret_hash field contains a BIP 340 tagged hash of the Sphinx shared secret of the rate-limiting peer, which will allow the creator of the onion message to know which part of the route is congested if onion_message_drop propagates all the way back to them. However, when there is some latency between nodes and many onion messages, onion_message_drop may be relayed to the incorrect incoming peer.This scheme will statistically penalize the right incoming peer, depending on the volume of onion messages generated by spammers compared to legitimate onion messages. Researchers are encouraged to evaluate the efficiency of this scheme against various types of spam and come up with formulas for those probabilities. To increase the accuracy of attributing onion_message_drop, more data could be stored in the future if necessary.It still seems to be an open question if the same network can be both a reliable micro-payment system and also a reliable arbitrary message transport layer.

Updated on: 2023-06-03T09:25:38.836760+00:00