Let’s imagine that you’re using Lightning to pay for your morning coffee. Every morning when you open your Lightning wallet, you need to sync network updates. This consumes bandwidth, drains your battery and takes time. Then you need to find a payment route to your coffee place’s Lightning node. This also drains your battery and takes time. Meanwhile, customers are queuing behind you, waiting to pay for their own coffee and wondering why this is taking forever.
Phoenix uses trampoline payments to get rid of these UX issues and provide faster payments. With trampoline, your wallet doesn’t need to know every node in the network. It only needs to know nodes that are close and some remote trampoline nodes. As long as you can find a (short) route to a first trampoline node, you can let that node calculate a route to the next one. And so on and so forth until the payment reaches its destination. This allows the network to scale without making it impractical to run a node on a phone. And of course, payments are still trustless.
However, the trampoline specification is still a work-in-progress. As a result our node is the only one currently supporting it, which means that we know the destination of payments, just like if you were using a custodial wallet (but payments are trustless, which is not the case with custodial wallets). When you send a payment with Phoenix, here is what happens:
- Phoenix looks at all of your channels, splits the payment accordingly and sends a multi-part trampoline payment to the ACINQ node.
- The ACINQ node aggregates the incoming partial payments, unwraps the trampoline onion and forwards the payment to its final recipient.
Two things can happen when the ACINQ node forwards the payment:
- The recipient is another Phoenix: this is business as usual, ACINQ forwards the payment or uses pay-to-open.
- The recipient isn’t another Phoenix (and thus doesn’t support trampoline): ACINQ will find a route to that recipient and forward the payment “the old way”.
Let’s briefly talk about fees. Fee estimation is hard, because the ACINQ node needs to be able to forward your payment to any node in the network and collect a small fee for its route calculation work. At the moment, Phoenix estimates the total fee to 10 times the routing fee applied by ACINQ (which is 1 sat + 0.01% of the amount sent). We will improve this by offering more accurate fee estimation on the ACINQ node, along with a retry-by-raising-fee mechanism in some failure cases.
EDIT: as of version 1.2.0, Phoenix starts with a low fee and then retries on failures, raising the fee for each attempt. This results in much lower fees in common cases.
And now for the most interesting part, the privacy trade-offs. As we said before, ACINQ learns both the payer and recipient of those trampoline payments (just like custodial wallets). We view this as a liability and we want to get rid of it.
Today, trampoline payments work like this:
Tomorrow, we want them to work like that:
You can clearly see that with such a route, ACINQ doesn’t learn who the payer or the recipient are: we get the same privacy as “normal” payments. Privacy on the Lightning Network is a subtle, multi-layer problem though, and there is still room for improvement. That’s why we’re actively contributing to the specification to work towards that goal.
This vision only works if other people run Trampoline nodes. We believe that will be the case because there’s a healthy incentive to run a trampoline node: you contribute to the network by providing route calculation services for wallets and receive extra fees for that. Everyone wins.
If you want to help with that ongoing effort, head over to the specification to contribute!
This article is part 4 of a series of articles introducing Phoenix. Other articles in this series:
Correction: An earlier version of this post said that Phoenix used a factor of 5 to estimate the fee, it’s actually a factor of 10. Meaning that Phoenix assumes that in the worst case scenario, the route will be 10 hops. This will be deprecated by the retry-by-raising-fee mechanism, scheduled for january 2020.
