blip-0073: Path Queries

[brh28]

Path queries are three optional peer messages (query_path, reply_path, reject_query_path) that let nodes cooperatively construct payment paths. Responses apply a node's first-hand knowledge of its own channel balances. This reduces node dependence on the gossiped graph, provides an alternative to probing, and lets routing nodes price payment flows per query, free of gossip's currency and expressivity limits.

This is the second version of the proposal, migrated from its original draft against lightning/bolts. Path queries are optional and pairwise. Since adoption can be partial and strategies are locally decided, the proposal does not require universality and is better suited as a bLIP. The revision also reworks the wire format (TLV streams, MPP path parts, query_id correlation, required expiry_ms in both directions) and substantially expands the rationale, privacy, and DoS analyses.

Reserves message types 32769/32771/32773 and feature bits 264/265 via bLIP 2.

[brh28]

Some open design decisions that I'd like to cover in review discussion:

1. Machine readable error codes for the reject_query_path, indicating things like insufficient liquidity, too many attempts, etc
2. amount_range is included in the Additional Fields section, but should arguably be included in the base TLV as a required field
3. part is a fixed struct with no TLV stream, but should likely include a length-prefixed

[TheBlueMatt]

Isn't the old FoF balance (quantile) query somewhat more privacy-preserving than this? Isn't it preferable for the edge node with limited balances to query their LSP for information and then compute paths from that themselves rather than asking for a whole path?

[brh28]

To my understanding, even though both are query-based and are intended to improve payment reliability, it's really comparing apples and oranges. Foaf is a liquidity management tool; nodes share balance information in their locale, so that they can rebalance with each other. Path queries are a path finding mechanism for payment senders and policy distribution for routing nodes.

Regarding privacy, are you referring to the payment details (e.g a downstream node, amount)? If so, I'm curious what queries you have in mind, but generally yes, the more targeted the query, the more it reveals about itself. That said:

1. Privacy cuts both ways - sharing more liquidity state is less private for routing nodes.
2. As mentioned in Privacy of payment details, the querying node is in control of what it reveals. It can blur amounts, query for sub-paths, split payments, or go nuclear and opt out of the feature.

[TheBlueMatt]

No, foaf balance information is exactly the useful information you want to do pathfinding better if your peers have more channels/liquidity than you do (which is common).

[brh28]

My read of the PR is that foaf is designed to improve reliability by changing network state, rather than supplying payment senders with path knowledge. Perhaps you can point me to a more up-to-date document that describes payment senders using it to discover feasible paths?

Either way, foaf replies are explicitly designed not to compose ("MUST NOT be gossiped and forwarded to other peers") and therefore do not have the same reach as path queries. Foaf messages also do not carry routing policy.

If you think this deserves a section in Related Work, let me know.