Introduction

When Alice pays Bob through the Lightning Network, her node will find a route to pay Bob based on its current knowledge of the network. This is known as source-based onion routing. When a new payment channel is opened, closed, or updated, a message is broadcasted to the network, informing nodes about the change. Alice’s node must store the relevant information to construct payment routes accurately. Otherwise, Alice won’t be able to pay Bob, as her node wouldn’t know how to route the payment. The task of finding a route for payment is known as “pathfinding.”

Lightning Nodes running on infrastructure like Voltage Nodes, with plenty of hardware resources have no issues with that. But for those running on mobile devices such as smartphones, challenges arise. Since mobile nodes are often offline, they miss updates about the payment channels network. Also, their limited storage and computing power make tracking the network’s structure increasingly difficult as it grows.

Running a Lightning Node on specialized hardware may be costly and cumbersome. Thus, innovating to enable Lightning use on mobile devices, without relying on custodial solutions, is appealing. This is the role that trampoline payments can play.

What Are Trampoline Payments

Trampoline payments are a proposed solution to simplify the payment process, particularly useful for mobile nodes and underpowered devices. They work by allowing spenders to outsource the pathfinding task for a given payment to one or more nodes. These nodes, known as Trampoline Nodes, handle the payment calculation to the final receiver, thus relieving the spender’s device of this complex task.

This means that trampoline-enabled Lightning Nodes don’t need to keep track of the entire network’s structure. These nodes usually only track their surrounding neighbors on the network. With trampoline payments, they only need to reach the nodes that do this “pathfinding-as-a-service”, since those specialized nodes handle the rest of the routing task.

However, trampoline nodes usually charge for the pathfinding service. Therefore, these payments are usually more expensive in terms of fees when compared to regular source-based route payments.

Certain upgrades are necessary among the parties involved for trampoline payments to function. Receivers must provide trampoline hints to guide the routing process. On the other hand, Senders shouldn’t expect to generate the entire route end-to-end but rely on trampoline nodes. These trampoline nodes must be equipped to assist users in routing their transactions and completing the process smoothly. All other nodes in the route don’t need to upgrade; from their perspective, they’re just routing a regular payment.

How Trampoline Payments Work

A node that wants to use trampoline payments selects trampoline-compatible routing nodes capable of calculating partial routes. These nodes broadcast their ability to handle trampoline payments to the network, and in doing so, they can also charge additional fees for their pathfinding service.

Next, the sender of the payment chooses one or more trampoline nodes and creates a “trampoline onion.” This is much like standard routing onions, but the target nodes are identified by their full IDs rather than their “short channel IDs.” It’s akin to calling someone by their full name instead of a nickname. Besides that, trampoline onions also may contain nodes that are not direct peers amongst themselves. The gaps will be filled later by the trampoline nodes.

Let’s go through a practical example:

Imagine Alice wants to pay Carol using a Trampoline payment. Alice must first select a trampoline node to reach Carol. Carol may leave this task all for Alice if she is reachable via public nodes. If that’s not the case then Carol can embed “trampoline hints” on the invoice, signaling Alice which trampoline node she can select for the payment to reach Carol, similar to how routing hints work in a regular invoice. For the sake of simplicity of this example, we’ll only be using one trampoline node, Bob, although she could use more.

After choosing Bob as the trampoline node, Alice finds a route to him. She doesn’t need to figure out the complete path to Carol; instead, she only needs to locate Bob. The responsibility for finding the route between Bob and Carol falls to Bob himself.

Upon receiving the trampoline onion from Alice, Bob discovers that the next destination is Carol. He then finds a route to Carol, constructs a new payment onion, and incorporates the partially revealed trampoline onion in the final payload. This process may continue through multiple trampoline hops until it reaches the final recipient, Carol.

Alice and Carol assume connectivity between their respective areas, a necessity that aligns with the default source-routing scheme, so trampoline payments don’t introduce new restrictions.

Privacy of Trampoline Payments

Trampoline payments simplify transactions for lightweight Lightning Nodes without compromising privacy. These nodes only sync with their local neighborhood. Therefore, they can add extra hops before reaching the Trampoline Node. From there, the Trampoline Node can’t determine the payment’s origin or final destination. It only constructs a path to the next specified node. Whether this is, another trampoline or the final recipient remains unknown. If there are two trampoline nodes in the route, the second one can even know that there was a previous trampoline before.

Trampoline Payments can also be combined with route-blinding or rendezvous to increase payment privacy further.

Concluding

Trampoline payments present a promising innovation for the Lightning Network, particularly for mobile and underpowered devices that face challenges in tracking the network’s complex structure. By outsourcing the pathfinding task to specialized Trampoline Nodes, these payments simplify the transaction process without sacrificing privacy or security. Though they may incur higher fees, the increased accessibility and flexibility offered by trampoline payments open new doors for users across varying devices.

The technology’s ability to work in conjunction with other privacy features like route-blinding or rendezvous further enhances its appeal. It aligns well with the ongoing need for decentralized, secure, and efficient payment solutions in a rapidly growing digital economy. The development and widespread adoption of trampoline payments mark a significant step towards making the Lightning Network more user-friendly, robust, and adaptable to diverse needs and applications.

Read the documentation:

• https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001939.html