lightning-dev

In-protocol liquidity probing and channel jamming mitigation

In-protocol liquidity probing and channel jamming mitigation

Original Postby Joost Jager

Posted on: October 21, 2021 12:55 UTC

In a discussion between ZmnSCPxj and Joost, the potential downside of using a dedicated probe message in Lightning Network was brought up.

The concern was that users could potentially use this message for free messaging by including additional data in the payload for the recipient. Although free messaging is already possible through htlcs, the probe message would lower the cost to do so as the sender wouldn't need to lock up liquidity for it, increasing the spam potential. ZmnSCPxj wondered if it was possible to design the probe message so that it was useless for anything other than probing, but Joost pointed out that it would be difficult as there is still an obfuscated 1300 bytes block with the remaining part of the route in it, making it hard for nodes to determine whether there is other meaningful data at the end. They suggested reducing the onion max size to make it less usable for remote messaging, but Joost noted that this may not work if they want to support 27 hops like they do for payments, as there will be quite some space left for messaging on real routes which are mostly much shorter.