This message could be used for free messaging by including additional data in the payload for the recipient, lowering the cost to do so as liquidity wouldn't need to be locked up. However, this also increases the spam potential. ZmnSCPxj suggested designing the probe message to be useless for anything other than probing, but it would be challenging due to the difficulty of determining whether there is other meaningful data at the end of the block. One suggestion was to reduce the onion max size for the probe, but this may not work if they want to support longer routes.Joost from the community pointed out that reducing the onion max size may still leave enough space for messaging on real routes, which are generally shorter. He also mentioned that forwarding nodes have an incentive to build channels to popular nodes and shorten the degree of separation. He suggested that something like 10 hops would work reasonably well, as longer routes increase the expected failure rate.The use of a dedicated probe message in the Lightning Network has raised concerns about its potential for free messaging and increased spam. The proposal suggests finding a way to design the probe message so that it can only be used for probing. However, this poses challenges as it is difficult to differentiate between meaningful data and other data within the message. One possible solution is to reduce the onion max size, making it less usable for remote messaging. However, this may not be effective if the network wants to support longer routes. Another topic of discussion within the Lightning Network community is the need for a new liquidity probing protocol message. This message would eliminate the need for upfront payments when routing a payment through multiple channels. By bypassing the channel update machinery and only forwarding the message if the link can carry the htlc, the lock-up period for liquidity can be eliminated. However, there are concerns about distinguishing these probes from real payments and the potential for routing nodes to exploit this by performing channel-jamming attacks or disrupting onion responses. Several solutions have been proposed, including making attackers pay actual satoshis for failed attempts. However, this proposal has received criticism for potentially impacting the user experience for honest users who need to attempt multiple payment routes. One suggestion is to combine the new liquidity probing protocol message with upfront fees for failed payment attempts after a successful probe as a potential solution.In the Lightning Network, there is a proposal to use probe requests without HTLCs to reduce the load on nodes, improve user experience, and avoid locking up liquidity. However, there are concerns about forwarding nodes exploiting this by performing channel-jamming attacks or disrupting onion responses. To address these concerns, a proposal suggests adding a message that indicates when a previous hop lied about its capacity. The sender would still have control over their funds in the channel, allowing them to determine if they have capacity or not. The proposal encourages others to contribute to the development of new messages for the Lightning Network.The Lightning Network community is discussing the use of htlc-less probes to eliminate upfront payments when routing a payment through multiple channels. This approach aims to improve user experience by reducing the load on nodes and eliminating locked-up liquidity. Additionally, it opens up the possibility of charging for failed payments as a deterrent against channel jamming. ZmnSCPxj proposed the idea and is being asked to draft a PR outlining the necessary new messages. The issue of incentives for nodes to lie about their channel capacity is also being discussed, with the recognition that any potential gain from such behavior is likely outweighed by the risk of reputational damage.In a scenario where C realizes that B is lying but faces a dilemma, he can either say no because he knows B is lying or say yes and get some free sats from the failed payment. However, if B cannot forward an HTLC to C later, then C cannot have a failed payment and cannot earn any money from the upfront payment scheme. Despite the positive incentive to continue the lie, C decides to keep it going for his own benefit. The payee, D, cannot detect the lie when she receives it. If C wants to expose the lie, he needs to blame B instead of himself to avoid payers assuming that the liquidity deficit is with C.In a discussion on the Lightning-dev mailing list, ZmnSCPxj proposed a mechanism to prevent forwarding nodes from lying about their capacity. However, Joost Jager's proposal creates a greater incentive for forwarding nodes to lie as they can receive sats for doing so. While ZmnSCPxj suggests accepting "no" from any node along the path, only the payee's "yes" is meaningful and she doesn't have enough information to know if the routers were lying or not. One suggested enforcement mechanism is to fail the channel between nodes if the asking node does not have sufficient capacity towards it. However, this may not align with