Phoenix implements trusted swaps for users' convenience (to allow easy onboarding and offboarding). But it's not a satisfying solution for the following reasons:
- It uses two on-chain transactions for swap-in where one should be sufficient (one transaction from the user to Acinq followed by a channel open)
- Swap-out feerates are unpredictable (because we may fund the swap-out with unconfirmed previous outputs) which is frustrating for users
- It forces Acinq to use its own utxos, which doesn't scale well and is an operational burden
- If Acinq doesn't have any utxos available and the mempool is completely full, swaps are stuck which is also frustrating for users
Fortunately, the recent work on dual funding and splicing paves the way for much better solutions. A big thanks to niftynei and rustyrussell for their early work on these protocols.
Let's imagine that we have an existing 100 mBTC channel and want to add 10 mBTC to it (most likely because we don't have sending liquidity).
The flow would look like:
Bitcoin Cold Wallet Phoenix Acinq
| | |
| | <1> |
| | can I haz splice plz? |
| |------------------------------->|
| |<-------------------------------|
| <2> | go for it! |
| can I haz bitcoins? <PSBT> | |
|<-------------------------------------| |
|------------------------------------->| |
| here you go: <PSBT> | |
| | <3> |
| | can I haz sig plz? |
| |------------------------------->|
| |<-------------------------------|
| | <tx_complete> |
| | |
Here is a more detailed breakdown of each step (fees are omitted for simplicity):
- Phoenix tells Acinq that it wants to splice
10 mBTCin the channel. Phoenix creates a PSBT with one input (the channel output in the funding tx) and one110 mBTCoutput (the new funding output). This PSBT goes through thecreatorandupdaterroles, but has no signatures yet. - Phoenix sends this PSBT to its cold wallet, requesting it to contribute
10 mBTC. The cold wallet adds inputs and optionnally a change output. Then the cold wallet signs its inputs (withSIGHASH_ALL). - Phoenix adds its partial signature for the 2-of-2 funding output to the PSBT and sends it to Acinq. The peer verifies the PSBT and adds its partial signature for the 2-of-2 funding output. It should then be able to finalize the PSBT and broadcast the resulting splice tx.
Voilà, the wallet user has been able to swap some funds in and Acinq didn't have to contribute any utxo. The transactions look like this:
+------------+ +-----------+
| funding tx |-------+------->| commit tx |
+------------+ | +-----------+
|
| +-----------+ +-----------+
+------->| |------->| commit tx |
| splice tx | +-----------+
+------->| |----+
+-------------+ | +-----------+ | change +-------------+
| cold wallet |------+ +---------->| cold wallet |
+-------------+ +-------------+
This makes the process much more predictable for wallet users: they decide the feerate and can use coin control in their cold wallet. The UX flow is simple enough as well:
- The user clicks
Receive -> On-Chainand chooses the amount - A QR code is displayed containing a PSBT
- The user scans this QR code from his cold wallet and instructs it to add
10 mBTC - The user obtains a new QR code with the PSBT signed by the cold wallet
- The user scans that QR code inside Phoenix and this will complete the flow
Getting funds out is even easier. Let's imagine again that we have an existing 100 mBTC channel and want to send 10 mBTC back on-chain.
The user simply needs to create a receiving address from his cold wallet, and start a splice that sends 10 mBTC to this address:
+------------+ +-----------+
| funding tx |-------+------->| commit tx |
+------------+ | +-----------+
|
| +-----------+ +-----------+
+------->| |------->| commit tx |
| splice tx | +-----------+
| |----+
+-----------+ | 10 mBTC +-------------+
+---------->| cold wallet |
+-------------+
Note that this shrinks the capacity of the channel. This can be an issue compared to the legacy swap-out, which didn't change the channel capacity and provided incoming liquidity to the user. But we can add the option to request liquidity (against a fee) and Acinq will in that case add utxos to the splice. We would simply need to use a custom TLV to transfer the fee directly to the initial main outputs of the new commit tx.
An interesting side-note is that it means we only need one channel (c-lightning was right 😅). It's much better than having multiple channels for a whole lot of reasons:
- Smaller graph, less gossip
- Smaller backups
- More intuitive balance: combined with trampoline, it means we know exactly how much we can send/receive (no MPP surprises)
Note however that there are still reasons to have multiple channels, but they don't apply to wallets:
- The number of pending HTLCs in a channel is limited; you may need multiple channels for better throughput on congested paths
- Are there others?
Whenever the user splices some funds in, it can pay some fees to the Acinq node and the Acinq node will also add funds to provide incoming liquidity.
Whenever the user receives an HTLC for which is doesn't have enough receiving liquidity, the Acinq node can splice additional funds in to carry this HTLC. If the user trusts that Acinq will not double-spend this splice, they can consider it complete without confirmation and the HTLC can be relayed. That operation is trusted: a trustless alternative is to hold the HTLC until the splice is confirmed (at the cost of keeping liquidity locked downstream).
- When adding funds, can we avoid choosing the amount before-hand? It would either require the cold wallet to sign with something else than
SIGHASH_ALLwhich is dangerous, or more back-and-forth between the cold wallet and Phoenix which provides a terrible UX... - We need to be able to cancel a splice (if the user stops in the middle of the flow or realizes that he doesn't have funds left on his cold wallet): is that supported?
No, don't worry, that's not the case, the diagram is a simplification but this will be using dual funding so commit tx will always be signed before we complete the funding tx.
You're replacing the splicing protocol by the payjoin protocol, and Acinq would act as a coordinator between Phoenix and the bitcoin cold wallet, is that right?
Does that means the cold wallet needs to support payjoin? If that's the case, it will be unlikely (especially if we want to add an encryption step to avoid Acinq learning anything it shouldn't learn), isn't it? Whereas the current protocol only needs the cold wallet to have PSBT support and all the splicing logic is implemented in Phoenix.
I really want to avoid having to ping every bitcoin wallet maintainer for payjoin support and potential bug fixes. I want this to require the most minimal feature set it needs from bitcoin wallets, otherwise there's no way this will be useful to enough Phoenix users. But once there is wide enough payjoin support in the bitcoin wallet ecosystem we can definitely revisit this (and I urge you to ask bitcoin wallets to implement this support if that's important to you).