Let’s suppose you just installed Phoenix. Your balance is zero, you have no channels. How can you receive your first payment? It’s easy: just go to the receive tab and display a LN payment request.
Wait, what just happened? How was the sender able to route a payment to you if there was no channel to route to? Let’s see what happened.
The way Lightning works, payments are routed through channels, which could be public or private. Public channels are announced as part of the gossip between Lightning nodes. Private channels are not announced and only known by their initiators, but information about them can be attached to Lightning invoices as routing hints. For example, all channels created by Eclair Mobile are private, and a Lightning invoice created on Eclair Mobile will contain routing hints for your existing private channels.
Phoenix uses those routing hints to tell the sender how to find a route, even if there are no channels — public or private — in the first place. To do that, we leverage the fact that Phoenix is only connected to the ACINQ node. This makes things very simple: Phoenix Wallet just needs to make up a fake channel between the ACINQ node and itself, with a specially crafted identifier, and add it to the invoice. The sender won’t notice anything, it will build a route that goes to a certain number of nodes, then ACINQ, then through the fake channel to Phoenix Wallet.
Now when the ACINQ node receives the payment onion, it will unwrap it and see that it needs to forward it to a fake channel. Because of the way fake channel identifiers are built, the ACINQ node will know that this isn’t a real channel, and will also be able to know what the actual node identifier of the Phoenix user is. Then two things can happen:
- ACINQ already has existing channels with the target Phoenix Wallet: then it’s business as usual, and ACINQ will forward the payment through those channels.
- There is no channel to this node, or there is not enough liquidity available in the existing channels. That’s where Pay-to-Open comes into play.
The Pay-to-Open feature works like this:
- ACINQ tells Phoenix that it has a pending incoming payment and it proposes to open a channel and push the amount corresponding to the payment on Phoenix Wallet’s side. There is a fee, essentially to cover the cost of the funding transaction for this new channel.
- Phoenix displays a pop-up asking the user whether they agree or not.
- If the user says “yes”, then Phoenix will send the payment preimage to the ACINQ node.
- The ACINQ node will use the preimage to pull funds from the sender, and will fund a new channel to Phoenix, with an initial balance for Phoenix set to the amount they agreed upon. Done!
Note also that with this scheme, the ACINQ node is the funder. In the current version of Lightning, it means that ACINQ will have to pay the on-chain fees for the commitment transaction if the channel closes unexpectedly.
This effectively solves the inbound liquidity issue on the wallet’s side. Instead of having to a priori manage channel liquidity to make sure you can receive a payment of a certain amount, you don’t have to do anything and channels will be created when needed.
This article is part 2 of a series of articles introducing Phoenix. Other articles in this series:
