Onion Message Jamming in the Lightning Network

The proposed e-cash mechanism for onion traffic offers a nuanced approach to managing fees and rate limiting in network communications, particularly enhancing the privacy aspect of transactions. This optional system allows onion message forwarding without directly relying on channel liquidity, creating a flexible interaction model among network peers. By issuing e-cash tokens, which are redeemable only with the issuer, the mechanism enables Alice to send messages through a network chain—for instance, from Bob to Carol, and then on to Dave—without needing direct channels between all parties involved.

The use of e-cash minimizes the total balance required, intentionally kept at or below the dust threshold to not significantly alter the existing threat model. These tokens are designed as utility tokens, meaning they cannot be converted back into channel funds, thereby mitigating risks associated with custodial balances. The flexibility of this system is highlighted by its ability to manage liquidity efficiently; tokens can be acquired just in time along the transaction route and leftover tokens can be used retroactively for other transactions within the network.

Two primary cryptographic approaches are considered for implementing this e-cash protocol: blind signatures (or blind Diffie-Hellman) and anonymous credentials with homomorphic value commitments. The first option focuses on simplicity and reduced latency, where each token, representing a single message, is fully redeemed upon use without additional verification delays. The second approach, although more complex, offers advantages in dynamic pricing and minimal latency through the use of homomorphic value-based e-cash denominations. This method also supports enhanced privacy protections against balance tracking, potentially making it suitable for broader applications beyond just message forwarding, such as encrypted storage or blockchain queries.

Ultimately, the choice between these cryptographic methods involves balancing complexity, privacy, usability, and broader application potential. While both methods address core needs of the proposed e-cash system, the specific selection may depend on the network's particular requirements and the desired level of sophistication in handling transactions and privacy considerations.