lightning-dev

In-protocol liquidity probing and channel jamming mitigation

In-protocol liquidity probing and channel jamming mitigation

Original Postby ZmnSCPxj

Posted on: October 21, 2021 15:01 UTC

ZmnSCPxj, a member of the Bitcoin Lightning Network community, raised concerns about the potential downside of a dedicated probe message.

While it could be used for free messaging on Lightning by including additional data in the payload for the recipient, it would lower the cost to do so because the sender wouldn't need to lock up liquidity for it, increasing spam potential. ZmnSCPxj wondered if it was possible to design the probe message so that it is useless for anything other than probing but noted that it would be challenging since nodes can't see whether there is other meaningful data at the end of the obfuscated 1300 bytes block with the remaining part of the route in it.ZmnSCPxj suggested reducing the size of the onion max for the probe to make it less useful for remote messaging, but Joost from the community pointed out that if they want to support 27 hops like they do for payments, quite some space will still be left for messaging on real routes, which are mostly much shorter. In addition, Joost speculated that forwarding nodes have an incentive to shorten the degree of separation, at least to popular nodes, by building channels to those, and he expects something like 10 hops would work reasonably well, as longer routes greatly compound their expected failure rate as well.