Path Queries: Addressing Payment Reliability and Routing limitations

This proposal suggests a mechanism whereby nodes can discover reliable payment paths through a single round-trip of path_query and path_reply, which is a stark contrast to the three round-trips required by traditional HTLC setups. The primary goal here is to reduce communication overhead and eliminate the need for constant probing of the network's dynamic liquidity, addressing the challenges of payment infeasibility that have been widely discussed. Furthermore, this approach encourages a shift in how routing node behavior is perceived, especially regarding channel fee adjustments based on perceived liquidity desirability. It posits an advantage in allowing routing nodes to selectively share their liquidity information, thus enhancing privacy and operational flexibility akin to trampoline routing mechanisms, albeit with differences in complexity and initial path feasibility requirements.

The conversation around this proposal expands into the area of dynamic policy adjustments for balancing channel liquidity, drawing parallels with rate cards to highlight the flexibility it offers routing nodes in modifying fees according to their current liquidity situations. This negates the need for payment senders to speculate on rates and addresses concerns over scalability, suggesting that network growth isn't necessarily capped by onchain constraints. Instead, it proposes a broader view of scalability that encompasses establishing payment channels across various settlement layers, indicating a rich area for future exploration in network enhancements and protocol developments.

A critical evaluation presented in another email highlights concerns regarding the practical implications of cascading path queries for payment routing, including potential communication overhead due to the dynamic nature of liquidity states. It points out the limitations of liquidity in affecting payment feasibility, referencing a study indicating that a substantial percentage of payments could not exceed a certain amount regardless of liquidity certainty. The critique extends to questioning the proposed benefits such as eliminating the need for a fully synced channel graph and facilitating more dynamic routing policies. Despite acknowledging the elegance of the proposed approach compared to existing methods, there's skepticism about its potential to significantly improve the Lightning Network's reliability and efficiency. A suggestion for a simple flag in channel updates to indicate liquidity positioning is offered as a potentially more effective solution.

Privacy considerations emerge as a significant theme, especially concerning the exposure of sensitive information through path_query and path_reply. These mechanisms compromise sender anonymity to some degree and pose nuanced implications for receiver anonymity and the privacy of channel balances. While sender anonymity is challenged by the potential narrowing down of the query origin from accumulated queries, strategies like incorporating trampoline hops could mitigate this risk. Receiver anonymity remains contingent on routing decisions, with options like blinded routes and sub-path constructions via trampolines enhancing privacy. The conflict between payment reliability and channel balance privacy is noted, suggesting that while probing remains a challenge, path queries offer a more controlled method for revealing liquidity information. This indicates a move towards a more balanced approach to managing privacy in relation to channel balances and network dynamics.