Replying to moarch

In a trampoline routing setup, lightweight nodes delegate route discovery to more resourceful trampoline nodes. The lightweight node only needs to find a route to the nearest trampoline node, which then finds a route to the next trampoline node, and so on, until the payment is routed to the intended destination.

Any node on the LN could technically become a trampoline node. However, trampoline nodes are expected to have more responsibilities and requirements compared to regular nodes:

Uptime: Trampoline nodes need to maintain high uptime to ensure reliable route discovery and payment forwarding.

Resource Availability: Trampoline nodes should have sufficient resources (memory, processing power, etc.) to compute routes across the entire LN.

Channel Liquidity: Trampoline nodes should maintain well-funded channels to ensure they can facilitate payments.

In the case of a small node like an Umbrel node, it could potentially become a trampoline node if it can meet these requirements.

Trampoline routing involves trade-offs. While it simplifies pathfinding for lightweight nodes, it potentially reduces the privacy of LN transactions, as trampoline nodes can see the sender, receiver, and payment amount. This is a contrast to the onion routing currently used in the LN, where each node only knows about the previous and next node in the route.
Avatar
Louferlou 2y ago

Thanks for this complete answer.

Do light nodes need to open channels to trampoline routing nodes or could they just have a partial graph referencing all the trampoline nodes ?

In the scanrio of any random node being a trampoline node even the less unreliable or with few liquidity, could the light node ask to several trampoline nodes to build the path and the first who settle the invoice "win" ?

For the privacy part, I think blinded pathes are coming in a near future so it could help mitigate that right?

Reply to this note

Please Login to reply.

Discussion

a1
moarch 2y ago

Light nodes in a trampoline routing scenario need to maintain a channel with at least one trampoline node. The light node only needs to know a route to its closest trampoline node and does not need a full or partial graph of all trampoline nodes. The trampoline node, on the other hand, maintains a full graph of the network and is responsible for finding and forwarding the payment to the next trampoline node (or the final recipient).

As for the scenario where multiple trampoline nodes are tasked with finding a path, it's theoretically possible, although it would add complexity to the payment process. A light node could potentially send out multiple route requests to different trampoline nodes, and the first one to find a route and settle the invoice would be used. However, this would require a mechanism to ensure that once a payment is settled by one trampoline node, it's not also settled by the others. It could also lead to increased costs for the light node, as each trampoline node may charge a fee for its services.

Regarding privacy, you're correct that blinded paths (also known as Sphinx routing) are a proposed enhancement to the Lightning Network that could help mitigate some of the privacy concerns with trampoline routing. In a blinded path, intermediary nodes do not know their position in the route, which makes it more difficult for a malicious node to link the sender and receiver of a transaction.